Re: [dssa] RE: Revised Draft Confidentiality Guidelines

[Don Blumenthal <dblumenthal@xxxxxxx>]

Mikey,

I see your point and agree that the situation is unlikely. It just strikes
me that the work of a subgroup could be affected by this constant
probationary status. If a voucher's (I wish that OARC had used a term
other than "vouch") trust was well-placed, the situation shouldn't change
if the person leaves. If it was misplaced, the situation is fouled
regardless of whether that person remains. The last phrase is part of the
reason that I focused on the "repudiation" interpretation.

Don



On 1/26/12 8:03 AM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:

>
>hi Don,
>
>i'm still going to push back.  remember -- the goal of this process is to
>protect information, not the feelings of the people handling it.  a key
>facet of the vouching process is that in addition to a chain of *trust*
>that's extended to the people vouched-in to the group, there's also a
>chain of *accountability* that stretches back to the people doing the
>vouching.
>
>so let's say that i vouch for Person 1, they vouch for Person 2, they in
>turn vouch for Person 3.  i'm in some way accountable for the actions of
>all three of those people because it's on that initial vouch that all
>three of them got into the group.  if Person 2 in my chain goes away, i
>really don't want to be accountable for Person 3.  i want them either to
>reestablish the chains of accountability *and* trust or drop out of the
>subgroup.
>
>i don't think that the "dropping out" scenario will come up very often,
>because i imagine these secured sub-groups will have a pretty short,
>pretty targeted life -- after they're done, i'm expecting them to be
>disbanded and other groups formed to handle different questions.
>
>the reason the this is such an "anti" feeling thing is because the cost
>of a failure is so high.  i'm quite cheerful about that, because it also
>opens the door to some really useful analysis which in turn may have a
>positive impact for lots of people.  but i myself wouldn't vouch anybody
>if i knew that i could be creating "islands" in the chain -- and if i
>were an info-provider i probably wouldn't share my data with such a group.
>
>sorry to be such a grouch.  :-)
>
>mikey 
>
>
>On Jan 25, 2012, at 6:58 PM, Don Blumenthal wrote:
>
>> 
>> Mikey,
>> 
>> I'm OK with all of your thoughts except on the last point. I understand
>> the reasoning but the dynamics concern me.
>> 
>> The approach seems to put the vouched-for person in a constant state of
>> probation if he or she has to be concerned about getting another sponsor
>> each time a previous one might leave. If someone is trusted enough to be
>> added, I think that the person should stay until demonstrating an abuse
>>of
>> the trust. Of course, that should apply to us originals as well as
>> newcomers.
>> 
>> Don
>> 
>> 
>> 
>> 
>> 
>> On 1/25/12 6:54 PM, "Mike O'Connor" <mike@xxxxxxxxxx> wrote:
>> 
>>> 
>>> hi all,
>>> 
>>> i'm pulling the questions into the email flow and taking a crack at my
>>> understanding of where we're at.  in the order they appear in the
>>>draftŠ
>>> 
>>> Don -- "Will subgroup involvement be required of all members? If so,
>>>this
>>> point couold be problematic if all of the groups need to handle
>>> confidential information."
>>> 
>>> My thoughts -- no, sub-group involvement is definitely not required.
>>> we're imagining that just as there are the "regulars" on the
>>> teleconferences, there will be a subset of the DSSA who will want to
>>> participate in the subgroups.  and conversely, it may turn out that we
>>> need subgroups to do work on NON-confidential information -- in which
>>> case this document does not apply.
>>> 
>>> 
>>> Don and Jacques -- regarding the separate email-distribution system --
>>> "use of PGP encryption?   Can ICANN provide a secure system for this
>>> purpose? I see the need for email security but PGP does not work in any
>>> reasonable fashion with some email systems and clients "
>>> 
>>> My thoughts -- we left this open in this stage of the draft.  we
>>>decided
>>> to treat that puzzle as an implementation detail if and when we got
>>> closer to the point of needing it.  we figured that the members of the
>>> subgroup might have some ideas (or resources) regarding this as well.
>>> but we left that undecided for now.
>>> 
>>> 
>>> Don -- speaking to the kind of information that sub-group members might
>>> receive -- "I would remove 'technical.' I can imagine situations where,
>>> for example, the information might involve business processes."
>>> 
>>> My thoughts -- i agree, good catch
>>> 
>>> 
>>> Jacques -- speaking to the "highest standard of protection" attribute
>>>of
>>> Type1 information -- "this should be furthered defined in this document
>>> or another, information storage and access, encryption, etcŠ"
>>> 
>>> My thoughts -- this was intended to a relative term, on the range of
>>> lowest-protection to highest-protection.  again, we left the details of
>>> the implementation to another day and presumed that when we got closer
>>>to
>>> actually using this framework we would have a better idea of what the
>>> requirements might be.
>>> 
>>> 
>>> Don -- commenting on the removal of a sub-group member (very last
>>> paragraph) -- "This could happen two ways: a repudiation or one of the
>>> vouching members dropping out. I suggest clarifying that it apply only
>>>to
>>> the first case."
>>> 
>>> My thoughts -- we discussed this very question and came to the opposite
>>> conclusion, i think mostly based on the way OARC does stuff but i can't
>>> remember.  the notion here is that we're trying to maintain an
>>> actively-affirmed level of trust for all members of the sub-group.  the
>>> risk is that a member could become an "island" in the trust chain if
>>>one
>>> or both of their "vouch" people leave the group, thus making
>>> info-providers uncomfortable with sharing.  so our thought was that if
>>>a
>>> person lost one or both of their endorsers, they'd probably find it
>>> fairly easy to recruit a few more -- but that if they didn't, we avoid
>>> potential embarrassment (or worse) by simply having a matter-of-fact
>>>rule
>>> that removes them from the sub-group until they do.
>>> 
>>> 
>>> great comments!  thoughts?
>>> 
>>> mikey
>>> 
>>> 
>>> On Jan 25, 2012, at 12:37 PM, Don Blumenthal wrote:
>>> 
>>>> Some thoughts on top of the document from Jacques. As he said, the
>>>> document is very good.
>>>> 
>>>> Don
>>>> 
>>>> 
>>>> From: Jacques Latour
>>>> <jacques.latour@xxxxxxx<mailto:jacques.latour@xxxxxxx>>
>>>> Date: Wed, 25 Jan 2012 13:10:55 -0500
>>>> To: Julie Hedlund
>>>> <julie.hedlund@xxxxxxxxx<mailto:julie.hedlund@xxxxxxxxx>>
>>>> Cc: "dssa@xxxxxxxxx<mailto:dssa@xxxxxxxxx>"
>>>> <dssa@xxxxxxxxx<mailto:dssa@xxxxxxxxx>>
>>>> Subject: [dssa] RE: Revised Draft Confidentiality Guidelines
>>>> 
>>>> Hi,
>>>> 
>>>> I just have a few comments/questions in the document, mostly around
>>>>how
>>>> we handle sensitive information within the sub-groups.
>>>> 
>>>> Other than that, it looks good.
>>>> 
>>>> Jacques
>>>> 
>>>> 
>>>> From: owner-dssa@xxxxxxxxx<mailto:owner-dssa@xxxxxxxxx>
>>>> [mailto:owner-dssa@xxxxxxxxx] On Behalf Of Julie Hedlund
>>>> Sent: January-25-12 10:40 AM
>>>> To: dssa@xxxxxxxxx<mailto:dssa@xxxxxxxxx>
>>>> Subject: [dssa] Revised Draft Confidentiality Guidelines
>>>> 
>>>> Dear DSSA-WG members,
>>>> 
>>>> Based on the comments received here are revised draft guidelines with
>>>> tracked changes.  It will be helpful if you could let us know as soon
>>>>as
>>>> possible if you have any further changes.
>>>> 
>>>> Best regards,
>>>> 
>>>> Julie
>>>> 
>>>> Julie Hedlund, Policy Director
>>>> <DSSA - WG Confidentiality Guidelines v1 Rev 25 Jan 2012  J.LATOUR -
>>>> dmb.doc>
>>> 
>>> - - - - - - - - -
>>> phone       651-647-6109
>>> fax                 866-280-2356
>>> web         http://www.haven2.com
>>> handle      OConnorStP (ID for public places like Twitter, Facebook, Google,
>>> etc.)
>>> 
>>> 
>> 
>> 
>
>- - - - - - - - -
>phone  651-647-6109
>fax            866-280-2356
>web    http://www.haven2.com
>handle OConnorStP (ID for public places like Twitter, Facebook, Google,
>etc.)
>
>