Subject: RE: [ietf-provreg] FYI: EPP implementation by the Polish registry

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 3 Mar 2003 09:01:53 -0500

> I suppose this isn't the concise message you were hoping for, but I'd 
> rather the WG figure this out rather than have me spoon feed it to 
> you.  E.g., the comment that we don't meet the requirement above was 
> answered by me in a thread with an IESG member that ultimately went 
> no where.  (Maybe someone else needs to try.)

I sent a private message about the DCP requirement to Patrik last Thursday
or Friday.  He hasn't yet responded.

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 10:47:52 -0500

> why do domain/contact/.. not have granular information about privacy?

Asked and answered.

1. Because operationally, policing at the session level is sufficient to
support persistent policing across multiple distinct objects, or support
single-object-session policing.

2. Because syntactically, if epp is to remain extensible, and xml-based,
adding attributes to elements is either pervasive, or specific. As this
WG lost the technical/social distinction with the expiry of Ross' draft,
we don't have a handy hook for being "specific", and "pervasive" makes
conditionally "private" even the data the registrants who have standing
to "privacy" under EU framework UNCONDITIONALLY SEEK TO PUBLISH.

3. Because semantically, it isn't simply contemporanious publication via
954 that is of issue, particularly in the EU, but also in the OEDC, and
potentially even the US. Also required is some mechanism to identify the
repurposing of registrant (and registrar) data, as bulk-access is a real
practice, with abuses. Also required is some mechanism to identify the
availability of collected registrant (and registrar) data for correction.
Also required is some mechanism to identify the duration that data is
held by the collector.

Adding these semantics to complexType elements would be complex, and has
no benefit over attaching the same semantics to aggregations of elements
that are NEVER DISAGGREGATED, aka "objects". There is little observed or
hypothetical inter-object disaggregation of policy that cannot be reasonably,
and scalably met, by bounding sessions by policy discontinuity.

See #1, above.

Ops, syn, sem, all covered.

> In a later discussion with Patrik, I was told that the EPP proposal 
> did not meet the requirement in Section 8.4 of RFC 3375. ("See the 
> MUST part of [1].")

I wrote the requirement. The mechanism is the <dcp>, and it is provided by
the protocol.

The requirement does not state:

  The protocol MUST NOT provide services if data collection policies
  are not identified.

If it had, then we'd have had <dcp> (or some other mechanism(s)) as
MANDITORY-TO-IMPLEMENT, rather than OPTIONAL. There was WG consensus that
the <dcp> is in the core schema (epp-1.0.xsd), optional to implement, and
not an optional extension.

> There are three other inputs. 

> One from Jaap - a look at how privacy concerns with .nl impact the issue.

I sent a public message about the .nl requirement to Jaap not long after
his note on the subject, that the EU residency requirement for registrars
provided a contractual equivalent to a <dcp> element, and a simpler form
(for a hypothetical deployment of epp, as .nl wasn't yet epp-operational)
of whois-token, while sufficient for endpoints within the EU, would not be  
capable of allowing non-EU endpoints to register .nl domains.

He hasn't responded.

> The second is a report and discussion on the .pl work in this area. 

I send a public message about the decision of this particular implementor
not to use the <dcp>.

I seem to have missed the response.

> The third is a message describing the EU perspective on why this must
> be solved.

Oh thank heavens! A live EU national who is a self-described "newbie" and
neither an implementor, nor an operator, nor an author, nor apparently a
specification reader. Now I can stop thinking.

Note Bene Chair:
	1. IESG (Randy or Allison) asked and answered
	2. IESG (Patrick) asked and answered
	3. .NL asked and not responsive
	4. .PL asked and not responsive
	5. Newbie noises

What part of IETF process did I miss in IETF grade school back in the
mid-80s?

I don't actually mind if folks creatively craft into "privacy" some form
of market protection, Europe for the Europeans, Africa for the Africans,
Circumpolar Regions for the Very-Well-Dressed. I simply find it amusing
that on the one hand we've people in the IAB/IESG kicking Chinese Butt
big time for attempting to fix Unicode [1], arguing "minimum astonishment"
as if it were an end-to-end principle, and people with the same, or very
similar drinking buddies, arguing that the semanitcs of "{0,1} are context
dependent.

Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0?

I'm always astonished that packets even make it anywhere.

Eric

[1] Yes Virginia, the new IRTF activity specifically BARS the work by the
Joint Engineering Team (.tw/.cn/.kr/.jp) registries and the Chinese Domain
Name Consortium (.tw/.hk/.ma/.cn) on intermediate mappings in particular,
and constructive mechanism in general. I've asked. Twice. Not for IPR reasons
either.

---

From: Edward Lewis <[email-masked]>
Date: Mon, 3 Mar 2003 11:39:56 -0500

>	4. .PL asked and not responsive

I should respond to earlier parts of the mail, but I'll pick on this first.

As far as 1 & 2, the IESG has taken the first step the responsible 
guardian.  I have to admit, however, that the detail I have obtained 
from them has been insufficient to evaluate any proposed solution as 
being "the right one."  I do not dispute the spirit of the IESG 
comments, I just wish that the comments were supported by more 
substance, as could be provided by 3 & 4.

I cannot speak as to why 3 & 4 were not responsive.  But these 
categories represent an important voice that I think needs to be 
heard.  I was looking to such a constituency to give more information 
on what the IESG is hinting we need, but I haven't been able to 
introduce any discussion in this way.

(I should add that I am not so disappointed that 3 and 4 haven't 
responded, I am more disappointed that there haven't been other 
organizations of similar ilk saying anything at all.  Yes, that's a 
generalization - and the IETF is supposed to be individual 
participation, but the list needs to hear folks with knowledge of 
other environments to help pound out a solution to this issue.)

The latter case - "newbie" is rather derogatory term.  Whether or not 
any one person agrees/disagrees with the words uttered, comments of 
this ilk (when on topic) are good to hear.  The IETF isn't about 
making protocols that implementors agree to - it's about making 
interoperable useful protocols.

>Does ((dnp==1 at .nl) == (dnp==1 at .com)) semantically evaluate to 1, or 0?

The answer to this is a determining factor (to me at least) of 
whether $dnp is in the base specification or in an extension.

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

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 12:49:20 -0500

> The latter case - "newbie" is rather derogatory term.

From <[email-masked]> 

> I am a newbie of this group and of the IETF WGs in general (please
> pardon me for anything inappropriate I might unvoluntarily do).
> However, I have been discussing DNS privacy issues extensively in the
> last years, so please allow me to give my point of view on the ongoing
> privacy discussion.

Note.

> Not addressing the privacy issue in the base protocol would likely
> imply that the service would often be deployed in real life without
> any means to achieve privacy protection.

Agree.

>                                           Unfortunately, the present
> lack of privacy protection in the WHOIS system is plainly illegal in
> many countries, and I don't think it's reasonable to think that this
> situation can go on for long without actual lawsuits starting to
> happen, both towards ccTLD and gTLD registries and registrars. 

Not relevant for a provisioning protocol. Specific to a particular
post-provisioned publication protocol, and none of us should be playing
lawyer on the net.

Its mechanism, mechanism, mechanism, mechanism, mechanism, mechanism and
once more for emphesis, mechanism.

Now I'll go back to my screw driver and duct tape, cause three years
working http-state, onward-transport, and provisioning just haven't
left me with clue parity with jrandom Euros.

I'll send a write up of where we are to the P3P list, we (I've now got
a spiffy "P3P hat" on) have a meeting this Friday. At this point though,
it looks as if the W3C is going one way, and the IETF is going another.
XML on the one hand, and a binary token on the other.

Eric

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 03 Mar 2003 19:30:08 +0100

He hasn't responded.

I don't recall the question, at least I don't recognize it. The
basic answer is no.  There is no requirement for EU residency for
registars nor registrants. All contracts are under dutch law. To
force this, there should be a dutch adress to which papers can be
presented.  But that has nothing to do with privacy apart from the
fact that the dutch privacy law should be followed by .nl.

	jaap

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 13:52:28 -0500

> fact that the dutch privacy law should be followed by .nl.

See "Deelnemers categorie I", below.

------- Forwarded Message

Delivery-Date: Tue Jan 21 19:48:52 2003
To: Edward Lewis <[email-masked]>
cc: "Hollenbeck, Scott" <[email-masked]>, [email-masked],
   brunner
Subject: Re: [ietf-provreg] where are we with privacy 
Date: Tue, 21 Jan 2003 19:48:51 -0500
From: Eric Brunner-Williams in Portland Maine <[email-masked]>

> I would also like others to comment on Jaap's message and assessment that:

OK, part 2.

> At 13:43 +0100 1/10/03, Jaap Akkerhuis wrote:
> ...
> >So yes, the non-disclose attribute will work for us without any
> >problem. It is possible that we might do extensions to aid with the
> ...
> >
> >	jaap

\begin{quote}
Deelnemers
...
Deelnemer worden
...
Deelnemers categorie I
	Voor het deelnemerschap categorie I komen in aanmerking
	bedrijven in instellingen die zijn gevestigd op het grondgebied
	van de Euorpese Unie.

	[Category I participation Category I participation is open
	to businesses and institutions based within the European Union.] 

	...

	Het deelnemerschap geeft recht tot:

		o het verzorgen van de registratie van domeinnamen ten
		  behoeve van klanten;

	[Category I participants have the following rights:

		o To apply to register domain names on behalf of
		  clients;]
\end{quote}

The "us" (parties having the capacity to register domain names on behalf
of clients) for which "the non-disclose attribute will work" appears to
be a scoped set of (eventual) EPP participants. The charter for this WG
is not to create a registry-specific, or regime-specific, or jurisdiction-
specific, or object-specific protocol.

How can a registrar signal in-band to a registry that it accepts the general
Data Protection framework, and any specific terms and conditions?

More generally, how can any two (or more) participants in the onward-transport
of customer data signal in-band their data collection practices, and automate
the management of onward-transport?

Eric

------- End of Forwarded Message

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 03 Mar 2003 20:13:16 +0100

Oh that. I thought that it was lifted. But it is still completely
irrelevant for the privacy discussion.

I'm not bringing this up. You are.

    How can a registrar signal in-band to a registry that it accepts
    the general Data Protection framework, and any specific terms
    and conditions?

It doesn't need to. It should first abide to the contract. That is
not-in band.
    
    More generally, how can any two (or more) participants in the
    onward-transport of customer data signal in-band their data
    collection practices, and automate the management of onward-transport?
    
That's not question this group has to answer. The only question is,
what is the proper element in the protocol which help to implement
a policy as been spelled out in the legal framework.

	jaap

---

From: Andrew Newton <[email-masked]>
Date: Mon, 03 Mar 2003 14:50:24 -0500

>>last years, so please allow me to give my point of view on the ongoing

I think it was the use of the words "newbie noises"... "noise" sometimes 
referencing an engineering term for signal ignored or unwanted.

-andy

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 14:53:28 -0500

try lack of signal.

would it have been more polite to suggest a low s/n ratio?

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 14:57:46 -0500

>irrelevant for the privacy discussion.

OK. What, if anything, is relevant?

>I'm not bringing this up. You are.

Correct.

So there no semantic consequence to the registrar being, or not being,
"based within the European Union."

The registrar may (hypothetically) provision some datum to the .nl registry,
with some (equally hypothetical) binary toggle set to ZERO, or to ONE, with
out difference, independent of the registrar's location. Is this correct?

I was totally mislead by the .nl registry's Dutch page on the subject of
registrar requirements. Fine. I can live with being stupid. I don't have
a lot of choice in the matter anyway.

>It doesn't need to. It should first abide to the contract. That is

What contract?

Better still, if a registrar doesn't need to signal in-band it accepts
anything, then it doesn't need to even know whatever that useless thing
is.

8.4 has a MUST in it, which appears to have no meaning at all if I
finally understand you. Everything is in the contract -- Scott's opening
position, that bilateral out-of-band mechanism (contract) covered the
requirement.

>a policy as been spelled out in the legal framework.

Well, you're a co-chair, so I guess we're finnished with

   The protocol MUST provide services to identify data collection policies.

and are on to

   "the proper element in the protocol which help to implement a policy"

Gosh this is such fun. Not.

Eric

---

From: Jaap Akkerhuis <[email-masked]>
Date: Mon, 03 Mar 2003 21:32:57 +0100

Correct.

Not with respect of the privacy issues. That is under Dutch regulation,
as I have said before.

Yup, see above.

    What contract?

Between registry and registrar.

You are twiting words. See my earlier response how this might work.

A MUST in a requirement document might work out differently in practice.

    
    and are on to

I was not talking as co-chair.

	jaap

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Mon, 03 Mar 2003 16:03:58 -0500

I'm not twisting your words, I'm not doing anything but try to get to the
bottom of something.
    
> Not with respect of the privacy issues. That is under Dutch regulation,

OK.
http://www.nic.nl/sidn/flat/Deelnemers/Deelnemer_worden/index.html
is garbage, in this context.

>     out difference, independent of the registrar's location. Is this correct?

Good.

> You are twiting words. See my earlier response how this might work.

Really? It seems that Scott (ages ago, London-context) said "contracts" as
the mechanism. I'm sorry but I don't know which earlier response you are
referring to. Could you provide a date? I'll read it.

> A MUST in a requirement document might work out differently in practice.

In theory ... Yeah. Patrick's quote.

> I was not talking as co-chair.

These two sentences mean very different kinds of things.

One attempts to describe a non-trivial policy space, without knowing a priori
the constraints. A mechanism of description. A "what".

One attempts to select from a set of elements (generally) the one(s) which can
effect a particular policy (possibly pluralized). A mechanism of effectation.
A "how".

Usually "how" comes after "what" (except in cowboy and indian movies), not
as an alternative to "what".

Eric

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 04 Mar 2003 10:57:36 +0100

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html    

	jaap

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 04 Mar 2003 07:22:16 -0500

>	    http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00049.html    

It appears I did read that. I replied with about 60 lines of comment in

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00062.html

and a one character correction in

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

and followed up with 

http://www.cafax.se/ietf-provreg/maillist/2003-01/msg00063.html

Well, my baby wants pick-up, and she won't wait 9 weeks until I get
around to paying attention to her needs.

Eric

---

From: Jaap Akkerhuis <[email-masked]>
Date: Tue, 04 Mar 2003 16:31:02 +0100

and followed up with 

Two followups for a charater change.

You said:

    1. Application of the IESG proposal to "technical" data.
    
    The .NL registry defines (hypothetically of course) a dnp==true value for
    one or more elements as an error condition, and presumably returns some
    error code.
    
    Someone, Scott if my memory serves, mentioned a registry which defines a
    dnp==true value for one or more elements as a non-error, and presumably
    returns something other than an error code.
    
    Is using EPP with dcp==true for technical data a good thing? I see it as
    an operation to modify the string-space, with no external manifestation,
    other than error upon query or transform. I can't imagine an application
    to an address registry's operational practices, but I don't have direct
    knowledge of address registry or registrar operational art.

That shows. Note I said, that this was a hypothetical case.
    
    2. Application of the IESG proposal to "social" data at a registry.
    
    The .NL registry anticipates (effective 29 Jan 2003) operating under the
    general framework of a European Union member state's Data Protection Act.
    
    Consistent with the general framework of EU's Data Protection Directives,
    the access, purpose, recipient, and retention are all contractually defined.
    
    This is not generally the case for registries operating outside of the EU,
    nor for registrars and resellers operating outside of the EU.
    
    It would be helpful if the details of data protection between a non-EU
    resident .NL regsitrar and the .NL registry were available, assuming any
    exist.

Note that we do this under dutch law. If registrars and registrations
doesn't want to confirm to that, there is no point in registrting
in .NL.
    
    3. Existance of the PROVREG proposal, in the presence of the IESG proposal.
    
    Would the .NL registry operator use both the session-level <dcp> data, and
    the element-level opt-{in|out} data? If the answer is "no", as I suspect
    it is, then <dcp> use either a) is error, or b) is silently discarded.

No, it is not discarded. Reread. And I din't mentioned both elements
at all.

    If the answer is "yes", which takes precidence in the event of conflict?

    Trying to keep concrete, data originates from a registrant and is collected
    by a US-Reseller, and in turn provisioned to a CA-Registrar, and in turn is
    provisioned to a .EU-Registry. Is the mechanism that provides the guidance
    for operational art at each onward-transport entity out-of-band (contract),
    or is it in-band, and if in-band, did the IESG proposal provide the same
    policy at each collector/onward-transporter as the European Union member
    state's Data Protection Act?
    
    I don't think so.
    
    I could be wrong.
    
    A p|np toggle is fine if purpose/recipient/retention/access are already
    taken care of (the Data Protection case). Where they are not, (OEDC and
    US cases), a p|np toggle may solve the 954 problem. How it can be applied
    to non-954 (and 954bis) is not stated.
    
Deliver text.

	jaap

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 04 Mar 2003 10:56:32 -0500

Jaap,

The third URL should have a value one greater than the second, it was
cut and paste, and I only noticed after send.

Eric

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 04 Mar 2003 11:34:41 -0500

> Two followups for a charater change.

Covered in my prior reply.

...
> That shows. Note I said, that this was a hypothetical case.

OK. We're past technical issues, and on to list dysfunction.

It is a small matter. 

Eric

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 06 Mar 2003 10:06:02 +0100

>specification reader. Now I can stop thinking.

Just for the sake of precision... I am an ICT engineer, I've been
reading and using RFCs for the last 8 years, and I am sufficiently
geek to often use e-mail by telnet 25/110 :-) I do not work in the
domain name business and I am a newbie in this working group, and this
is why I don't want to make suggestions about the technicalities,
given that you all here have been discussing them for years. So I'm
just lurking the list as often as I can. But the CRISP group has found
my suggestions useful enough to include them in the latest CRISP
requirements draft.

>	4. .PL asked and not responsive

My intention was not to produce "noise" but just to help the group
understanding the issues at stake from a different perspective. Please
pardon me if I failed in this.

(However this thread is going off topic, so please consider replying
in private.)
-- 
vb.                  [Vittorio Bertola - vb [at] bertola.eu.org]<---
-------------------> http://bertola.eu.org/ <-----------------------

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 06 Mar 2003 08:12:33 -0500

CRISP, WHOISFIX, NOT43, ... deal with publication protocols.
DNSOP, DNSSEC, ... also deal with publication protocls.

Generally, they start with some authoritative instance of some datum,
and unconditionally replicate non-authoritative copies of that datum.

The access and persistence properties of these do not subset the
maximums for both generally.

PROVREG and its anticeedents, the DOMREG BoF(s) and the authors
of RRP, ... deal with provisioning protocols. 

Generally, they start with some non-authoritative instance of some
datum, and conditionally allocate an authoritative instance of that
datum.

The access and persistence properties of these subset the maximums
for both generally.

OTHER PUBLICATION PROTOCOLS EXIST.

Bulk copy, with "sale", "lease" and "rent" of mailing lists, postal
and electronic, exists. Some implementations use "sneaker net".

Other technical mechanisms, which exploit properties of domain name
data in particular, the nameserver, technical and administrative
contact, even the character space properties of a domain name (marks,
soundex, Hamming Distrance from, ...) which REPURPOSE data, also exist.

Data provisioned via protocol (RRP, SRS, EPP, ... NEXT) may be merged
with data acquired by other means.

Since the beginning of this Working Group, there have been contributors
who want to "solve" the 954 problem within EPP. This approach does not
solve for other publication mechanisms, nor does it solve for the user
informed portion of the informed consent meta-requirement placed on all
data collectors by 95/46/EC and related texts that address directories,
and related tools for the management of endpoint identifiers which may
identify individual persons.

If the better reading of 95/46/EC et seq. is that it applies to port 43,
and originators need only (may only) make port-specific negative assertions,
then a "publication" framework (yours and others, e.g., the IESG) may be
sufficient.

Having done this twice before, I don't think so. Besides, I don't know
that EPP can't be used for keyword systems, that may not use :43, and
for anything similar.

It would work for the US, and anywhere else where the IAB (the other one,
the Internet Advertising Board) and the DMA (Direct Marketing Association)
and similar trade groups control the "opt-in vs opt-out" policy issue.

I now know it would work in Holland also. I don't understand this, but
the European Data Commissioners I've communicated with over the past three
years are French and German, so I've obviously missed something.

Pointing out a specific defect in the <dcp> element's sub-schema would be
really useful.

Eric

---

From: Edward Lewis <[email-masked]>
Date: Thu, 6 Mar 2003 11:14:32 -0500

>WG lost the technical/social distinction with the expiry of Ross' draft,

What parts of the material in Ross' draft need to be added (as 
terminology definitions) in the base spec (or base spec-bis)?

>954 that is of issue, particularly in the EU, but also in the OEDC, and

What is OEDC?