Re: [ietf-provreg] Our "Privacy Issue"

[Edward Lewis <edlewis@arin.net>]

At 13:21 -0500 3/25/03, Eric Brunner-Williams in Portland Maine wrote:
>False. It is a requirement not in 3375. It is a new requirement, one that
>modifies some functionality.

Yup.  The issue isn't whether something is new or not.  The issue is 
whether it is a good idea.  Recall that in the IETF process, an RFC 
is just that, a request for comments.  I've stated in the past that 
there is never a deadline for getting it right - so long as we get it 
timely.

We can "debate" forever on the merits of late requirements and 
concerns late in the game - but if you care about that, 
problem-statement seems to be the place.  Let's focus on this problem 
statement and not worry about whether or not the process is a problem.

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

Basically, yeah.

>We don't know it is a good idea, we do know that it is the IESG's idea. So,

Okay, let's get over this.  Forget who suggested it.  Apparently you 
are not happy with requiring the protocol let the client include 
privacy meta-data to achieve the goal of allowing enforcement to 
happen at the server.

Others have thought this is a good idea, mostly in the room and Scott 
so far as agreed that the statements in the room amounted to what I 
wrote.

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

Once again - worry about this in problem-statement.  I ain't about to 
debate the role of the document editor here - the topic is EPP, not 
the IETF.  Scott is recording the consensus of the WG, along with 
much of the material he originally brought to the WG in 2000.  (See 
the charter, it hasn't changed.)

>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 don't think that there's much support for writing 3375bis at this 
time.  Perhaps when a WG comes along to advance to Draft Standard it 
would be good to have a document that rolls in operationally derived 
experience, but it's way too premature to consider this now.

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

With the high bandwith of voice-over-soundwave (a cutsy name for 
face-to-face meetings) I think we were able to get deeper into the 
issue.

>I wasn't thrilled with the congestion issue either, or the ordering issue,
>but those are damp spots under prior bridges.

I suppose you are referring in some way to the statement that we 
aren't pursuing SMTP or other transports over TCP (or other 
transports at all).

One reason we are not pursuing them is that 1) no one has maintained 
a document on this for a prolonged period of time and 2) no second 
person has cared enough to present an interoperability-motivated 
reason for this to be brought into the group.

I know you have had documents that discussed SMTP.  My reading of 
them was that they were never fully developed enough to trigger me 
into personal action.

As a WG chair, admittance of documents is based in part on a reason 
to use the WG's resources - i.e., the members.  Without voluntary 
member motivation to review the documents, there's not a sufficient 
reason for the WG to expand its horizons.

I.e., although our charter says we will investigate alternate 
transports - it doesn't mean we will develop an alternate transport. 
So far the result of the investigation is that there's been no 
popular support for other transports.

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

You've lost me again here.

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

There may be a better form of saying "owie" but the cost-benefit of 
finding this seems to be discouraging to the group.  (I.e., we've 
been running around just trying to figure out how to spell pirvayc at 
that point.)

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

Valid concern, but as I said before - implementation detail.

>Are there any success or failure semantics? Is the transaction atomic and
>unitary, or is a partial write success?

It's all policy as far as we can tell.

>Is the new semantic capable of test by any in-protocol means?

Well, we want to be able to set, check, change and define the meaning 
of absence.

>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

Details, implementation details...

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                            +1-703-227-9854
ARIN Research Engineer

I've had it with world domination.  The maintenance fees are too high.