Re: [dssa] RE: Revised Draft Confidentiality Guidelines

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

hi Jim,

sorry about the tardy reply.  i'm completely distracted by this "frac sand" 
issue that has overwhelmed my tiny rural county here in Wisconsin -- read more 
at www.FracSandFrisbee.com  

thanks for your comments.  we did have a fairly long discussion abut this on 
one of the Ops calls, but i can't recall whether you were on that one.

i think the thing to do is turn to the information *providers* on this one.  
i'm much less concerned about collegiality than i am about the comfort level of 
the info-providers and would ask folks like Keith Drazek, Edmon Chung, the 
ccNSO registry representatives to weigh in on this.  

our goal with this process is to make sure that info-providers are absolutely 
comfortable that highly sensitive information that they share is protected.  if 
they're comfortable, i'm comfortable.  but if the process doesn't provide 
sufficient safeguards in their view, i think that trumps the collegiality goal 
because it seems likely to me that info-providers then won't share the 
information we need in order to do our analysis.

my two cents -- but i totally defer to those of you who are going to be asked 
to share info.  thoughts?

mikey


On Jan 27, 2012, at 10:05 AM, James M. Galvin wrote:

> 
> I'll add one more voice to Don's comments and say that I agree with him.
> 
> If I understand the concern, Mikey, it's about accountability.  Frankly, I 
> think we're creating process that is overly pejorative for an infrequently 
> occurring event.
> 
> It seems to me that if someone is part of the group then they are part of the 
> group and they are accountable to the group as a whole.  In other words, all 
> this tracking and record keeping to see who "vouched" for who and when and 
> why can be straightforwardly replaced by a "process for entry" and then 
> "maintenance by the group".
> 
> If take this line of thinking to its logical extreme, if a person becomes 
> "fouled", we should be examining all decisions and activities of this person 
> to date, not just their chain-of-trust that got them in the group or the 
> chains-of-trust of which they might be a party.  Why are we calling out this 
> one actionable decision of a "foul" person.
> 
> I believe that a person in the group, any person, stands on their merit.  
> Once you are in the group gets to manage whether you are "foul" or not.
> 
> Otherwise, again reaching to a logical extreme, you're suggesting that if I 
> vouch for someone I have to watch them carefully, with continuous oversight, 
> because my standing and credibility is at risk for having invited them to 
> participate.  Similarly, as a "vouched for" person, I have to watch carefully 
> and continuously the person(s) who vouched for me to make sure they function 
> on the straight and narrow.
> 
> Such a set of circumstances does not feel collegial to me.
> 
> I apologize if this point was made and "out-voted" in the prior discussion, 
> but I don't recall the prior discussion which suggests to me that I missed 
> it.  This is a common issue insofar as I've seen it before in other groups 
> and I have always held this position about it and I wanted to make sure it 
> was part of the discussion.
> 
> Jim
> 
> 
> 
> 
> On Jan 26, 2012, at 9:04 AM, Don Blumenthal wrote:
> 
>> 
>> 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.)
>>> 
>>> 
>> 
>> 
> 
> 

- - - - - - - - -
phone   651-647-6109  
fax             866-280-2356  
web     http://www.haven2.com
handle  OConnorStP (ID for public places like Twitter, Facebook, Google, etc.)