To: Eric Brunner-Williams in Portland Maine <firstname.lastname@example.org>
Cc: Edward Lewis <email@example.com>, Eric Brunner-Williams in Portland Maine <firstname.lastname@example.org>, Ted Hardie <email@example.com>, "'firstname.lastname@example.org'" <email@example.com>, firstname.lastname@example.org
From: Edward Lewis <email@example.com>
Date: Thu, 17 Apr 2003 15:47:49 -0400
Subject: Re: [ietf-provreg] legal entity vs individual person
At 14:04 -0400 4/17/03, Eric Brunner-Williams in Portland Maine wrote: >Ed, > >At Pittsburg Fred said from the podium that his side of the table (the IESG) >did not have all the clue. Here we have assertion without justification for >novel functional requirements -- which is different from the prior IESG dicta >on manditory mechanisms, e.g., congestion control. It appears that I have failed to relate all of the story from the meeting in SF. During the face to face meeting, Randy Bush proceeded to explain the basis of his comment in such a way that it became clear to those of us in attendance that there was an operational consideration here. I submitted the notes from the meeting based on the Jabber log, without having the scribe notes. Here are what lines I see as relevant (editing to save space here, the message was on the list recently): # now on to privacy # ted: addressing privacy brought up by randy bush # ted: describing registry/registrar/registrant use case # ted: dcp tells the registrar from registry about privacy # ted: if registrant has privacy parameters, the registrar checks against # the registry and rejects the registration # ted: in this model, the registrar is handling the intersection between # the registrant and registry # ted: what randy has asked for is a case where the registry handles this. # ted: in this case, randy wants a mechanism where this is possible. # ted: mechanism allows registrar to give registrants parameters to registry # ted: randy wants it at the per element granularity on social data ... # ed: this is the first time I've heard this argument clear enough to # understand the issue The group then formulated a problems statement from this which was put on the mailing list the next week. As far as I can tell, the comment started out from the IESG, got hammered out in a in-person meeting, and resulted in an additional requirement accepted by the WG (on the list). In my opinion, this is a far more reaching (and formal) acceptance of the IESG comment than happened for the congestion control comment you mention. >Now is it sensible? If the ends justify the means. OTOH, given that it took 6 months from the handing down of the IESG comments until my statement above, I'd say the IESG:WG interface could have been smoother. >Since London we seem to have been in agreement that some policy required a >mechanism to disclose some operational practice -- "data protection", and >"privacy" were the rationales. > >This week, these rationals seem to be abandoned. There is no "protection" >no privacy, only a non-specific access mechanism. > >Mind, this is only for the client-side mechanism. I suppose that you are unhappy that with server-side statement (dcp) the protocol is saying "the registry says how is works" and for the client-side statement (don't disclose) the protocol has the client saying "you figure it out" - as opposed to "the registrar says how it works." Is that your issue? Are you suggesting that there should be a requirement that either of the client and server declare their privacy policies? Barring WG feedback, I don't think that such a suggestion (which are words I am putting in your keyboard) would pass. I don't think the issue is what policies are being followed, but rather what happens to the data sent to the registry - which means that the asymmetric "servers says policy or client says what" is appropriate. >Still, did Randy want the same technical specification for his personal >registration as Verisign has for its corporate registration? I don't know >that he did. Maybe that is all he ever wanted. > >It concerns me, no it irks me, that IESG clowns blow in with personal opinions >and fob them off as professional opinions. Yes, we must make less-than-best >choices to actually have something multiply independently implemented, but it >does not strictly follow that we must do what Fred would not dare -- assert >that better knowledge is always on the IESG side of the table. Reconsider this section of your message in the light of the WG's acceptance of the IESG statement. >It is not sensible to assert the non-existance of "personal data". There is >a set of references that specify, partially, incoherently, but not negatively, >some semantic that attaches to datagram, circuit, postal, and other network >endpoints, as well as to names, when associated with individual persons. > >Ed, where is the call for consensus on the IESG fiat? http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00104.html The very next post is your answer to this. The 'declaration' of consensus appears in: http://www.cafax.se/ietf-provreg/maillist/2003-03/msg00128.html >I still don't think chair-hats have interesting opinions on technical issues, >ever. My comments to you are based on focusing the solutions and discussion to stay within the bounds of the problem to be solved. >This could have been so much easier if the drive-by shooters had stopped to >find out if their aim was in fact perfect. Maybe so, but in this case the drivers-by eventually stopped, backed up, reloaded and shot repeatedly until the problem statement was clearly something the WG could address. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-703-227-9854 ARIN Research Engineer "I'm sorry, sir, your flight is delayed for maintenance. We are pounding out the dents from the last landing."