ICANN ICANN Email List Archives

[dssa]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [dssa] RE: Revised Draft Confidentiality Guidelines

  • To: "Mike O'Connor" <mike@xxxxxxxxxx>
  • Subject: Re: [dssa] RE: Revised Draft Confidentiality Guidelines
  • From: "James M. Galvin" <jgalvin@xxxxxxxxxxxx>
  • Date: Sun, 29 Jan 2012 11:01:19 -0500


Thanks Mikey. I too, am interested in what info-providers think about the proposed guidelines.

Jim



On Jan 29, 2012, at 8:09 AM, Mike O'Connor wrote:


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







<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy