To:
Edward Lewis <edlewis@arin.net>
cc:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>, ietf-provreg@cafax.se, jaap@sidn.nl, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Tue, 25 Mar 2003 13:21:40 -0500
In-Reply-To:
Your message of "Tue, 25 Mar 2003 09:51:16 EST." <a05111b00baa61928857c@[192.149.252.108]>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] Our "Privacy Issue"
Hi Ed, Long and interlinear. > At 18:33 -0500 3/24/03, Eric Brunner-Williams in Portland Maine wrote: > >It had one error. The assertion that to function (at all) some delta > >is required. The correct statement is to function (as required post > >rfc3375) some delta is required. > > Eric, help me here. What is your point? You wrote: What is desired is a mechanism that will let EPP support thick registries, in which social data is held by the registry. No new mechanism is required by this sentence. In such situations, the registrar needs to inform the registry of restrictions on the redistribution of the data submitted to the registry. False. It is a requirement not in 3375. It is a new requirement, one that modifies some functionality. OK, so neither of us writing or grading english compositions. EPP "works" as is (-02, -04, -06, ... for some value of "works"), and some new thing is desired by someone in -0N, for some value of N. Fair enough. > >Requirement by assertion is more popular than I recall. > > I'm still not getting your point. I'm not sure if you are unhappy > that someone wants to add client-sent statements on privacy or that > the someone is the IESG. I'm not sure I see a reason from you > explaining why adding this is a bad idea. Any requirement not in the req doc is either a) previously rejected, or b) a failure of the process that created the req doc, or c) neither a) nor b). Suppose c. We don't know it is a good idea, we do know that it is the IESG's idea. So, when we say that Scott is the editor of documents under the change control of the IETF, what we are really saying is that the actual change control is held, not by the contributors, acting in concert, under 2026, et alia, to create some specification, but by institutional authority figures other than the I-D administrator, who may add/delete/modify the text, without undertaking the corresponding action on the requirements doc, which has already had WGLC, and IETF-LC. If someone wants to modify 3375 and delete the manditory announcement clause, let them. It is possibly deficient. If someone wants to modify 3375 and add a manditory enforcement clause, let them. It is possibly sufficient. I'm "unhappy" about what I see as the technical difficulty of the proposal, the inability of the authors of the proposal to make a technical case for a mechanism that doesn't rely upon an appeal to authorty, or exhaustion, and the process to effect change control of the provreg work product. I wasn't thrilled with the congestion issue either, or the ordering issue, but those are damp spots under prior bridges. > >Question #1: If the client originated a <c-dcp> as part of session > >init, and the server responded with a <s-dcp>, and the evalution > >algorithm (tbd) was simple, e.g., equality, would that meet their > >requirement? > > Initially, this might be, but as an outcome of the discussion in the > meeting we felt that finer granularity was desirable and achievable. > We talked about this as being a session-granular thing, but that was > discarded. I thought so, which is why I asked. Even if sizeof(server(dcp-space) > BIGNUM, and function(client(dcp-select) is unrestricted, _this_isn't_what_the_iesg_wants_. On the bright side, this means that all two-step discovery kludges of the form Edmon proposed are as KIA as the <dcp>. On the dim side, this seems to mean that the issue is syntax or religion, as there's a heck of a lot of values less than BIGNUM (or a full DOM tree), and a baroque richesse of choices when one is unrestricted. So semantics is possibly _not_ the issue. > > >In eppcom-1.0.xsd we have this: > > You're getting into an implementation detail. At this point, we are > hashing out the problem statement. I could be wrong, but the authors of the document offering guidance on the use of xml in IETF protocols may have failed to mention an edge case. If a type is inextensible, and is used to type a datum that cannot be semantically conditioned by any means other than extension, for reasons that are non-sytactic in nature, an "owie" occurs. I'm sure there is a better form of expressing this than "owie". The point of the implementation detail is that I think (I'd prefer to be wrong) that we need to put a layer between the syntax of EPP extensions to XML, and the basic types of XML, so that "policy" can be hidden in the syntax, which I don't see a way to do with the "mail" element's "token" type. Eventually all this garbage, mine and anyone else's, gets tossed into a validating parser. What comes out may come as a surprise to me. > >> The IESG is doing this through the role of protocol design engineer > >> review - recognizing functionality that oughta be in a protocol but > >> isn't. > > > >3375 is the requirements statement. > > Yeah, it is. Obviously, you mean something by saying that, but it is > not clear. See above. *-LC are not meaningless, and should not be "worked around". > >> But the only option available to users of the client is to decide > >> whether or not to make the registration. We want more of an option > >> than that. > > > >Please explain. > > We want the registrar to be able to say, here's the phone number but > don't send it anywhere. What is meant by 'anywhere' is policy > specific, hence outside the WG's concern. Are there any success or failure semantics? Is the transaction atomic and unitary, or is a partial write success? Is the new semantic capable of test by any in-protocol means? > >It is my sense that "privacy" is not simple. > > Then it's not privacy we are concerned about. It's about tagging > data with something called 'privacy.' How large is the policy value space? Taking the phone number example above, the value space appears to encode neatly into a single bit. If so, while I'm typing this I've found one solution to the "email" element qustion I thought was awkward. Suff one extra bit, like NeuStar's proposal to pun the size type and signal directionality, into an octet. Violate some rule about octets in mail addrs, e.g., set a high bit in the domain name. If high-bit on, semantic one flag set and unset bit before store. If high-bit off, semantic one flag not set. mail="brunner@nic-naa.ne(eval((0x164+0x177)" Wierd. I guess the same could be done to the e164 type too. Of course, if the value space doesn't encode neatly into one bit, then this won't work, unless applied iteratively. Eric