Re: [dssa] RE: Revised Draft Confidentiality Guidelines

["Mike O'Connor" <mike@xxxxxxxxxx>]

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.)