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

[Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>]

> >I'm not convinced that the issue of contention is technical.
> 
> Then I've failed in my description of the problem.

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.

Requirement by assertion is more popular than I recall.

> As we sit, EPP requires the registrar to make decisions on whether 
> the submission of a piece of data will be accorded the proper 
> handling with regards to privacy.  The issue is that EPP forces the 
> registrar into this posture, there is no choice.

There are a lot of restrictions. RRP doesn't have this one (it has
others). SRS doesn't have this one (it too has others). Etcetera.

Its a nuance that may be lost on some, but the evaluation possible
by the registrar isn't necessarily prospective (forward looking),
it can be of the announced policy at the moment of transactional
evaluation, with some explicit temporal guarantees. Mind, all of
the evaluation is either optional (epp-07), manditory (epp-08), or
irrelevant (iesg-any).

> What the IESG has asked of us is to make EPP possible to support a 
> scenario in which a registrar gives the data and policy request to 
> the registry and then let the registry decide what to do. 

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?

> Furthermore, a basic framework for this is desired to be part of the 
> base protocol.

As the formal specification of this protocol is in XML, this is more
than it appears.

In eppcom-1.0.xsd we have this:

<!--
Non-empty token type.
-->
  <simpleType name="minTokenType">
    <restriction base="token">
      <minLength value="1"/>
    </restriction>
  </simpleType>

We use it to define type ofthe element "email". Now how does a "data
structures 101" compatible tag fit into that? 

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

> >The registry announces a session-policy. Implementors are free
> >to evaluate the registry-announced policy, and implement local policy,
> >e.g., accept the policy and propogate policied data, or decline.
> 
> 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.

> >To me, it _was_ just distributed read and write access mechanisms to
> >shared store, with a specific syntax. If someone claims read-on-43
> >exhaustively defines "privacy", I don't care. It doesn't exhaustively
> >define _read_.
> 
> I don't think anyone is trying to link privacy to what's on port 43 
> (whois to most of us).  The goal isn't to tie privacy to any 
> publication mechanism.  This is done with the intent that during the 
> phase of reaching towards DS, we will have more tools for dealing 
> with privacy.  Features are more easily removed from PS to DS than 
> added.

This is where the non-technical bit lives. Let's go back:

> >I'm not convinced that the issue of contention is technical.

Just how complex is "privacy"? Is it a property that a tag is a useful
mechanism to encode it?

If "privacy" is simple, something that fits in a tag, then we have one
technical issue.

If "privacy" is not simple, then we have another technical issue.

It is my sense that "privacy" is not simple.

> >Enforcement is a whole different can of worms, unless this is just a
> >techno-fiction.
> 
> Enforcement is part of policy and we are making every effort to sidestep it.

To avoid non-sensicalness however, an enforcable mechanism needs to be
capable of violation detection. No spitting when I'm not looking is not
impressive.

> >Nope. Seems technically flawed to me, and worse than what we had.
> 
> I don't see how.

Cheers,
Eric