[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


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

Home | Date list | Subject list