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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 11 Feb 2003 08:30:20 -0500

> At the DNR-forum at RIPE-44 last week, the polish registry presented
> their implementation of EPP. They had to make extensions to implement
> the somewhat draconian Polish privacy rules. One of the things they
> mentioned was that they were more severe then the European ones,
> so when they join the EC, they might change. Anyway, I don't have
> the presentation on line yet, but they have piblished a document
> about the things they did with the protocol. It can be found as
> ascii (http://www.dns.pl/NASK-EPP%202.01.txt) or pdf
> (http://www.dns.pl/NASK-EPP%202.01.pdf) on the web.

While at the CENTR technical forum I listened intently to these and other
presentations to see how they relate to our ongoing discussion of privacy
specification and the unresolved comment from the IESG.  The extensions
described by the folks from NASK include an element that directly relates to
the IESG comments: their <consentForPublishing> element is described as "it
specifies whether a private person gives its permission to publish personal
details in WHOIS database".

We now have two ccTLD registry operators (.pl (above) and .nl (via Jaap))
who've noted that having a "do not disclose" flag is something that they
need and can use.  In the case of .pl, where they claim to have very strict
privacy rules, implementers found that a single high-level element was
sufficient to mark the content appropriately.  If we had a "do not disclose"
element in the contact mapping they probably wouldn't have had to add this
extension.

In the spirit of "rough consensus and running code", maybe this is a
reasonable compromise.  We have registries implementing privacy policies
that need some sort of "do not disclose" marker, but maybe we don't really
need to mark every element -- maybe having an optional <doNotDisclose>
element in the various <create>, <info>, and <update> structures is all
that's really needed in the real world.  I'd like to ask the WG members and
the IESG to consider this possibility.

The WG should note that implementers of real-world privacy policies are
finding it necessary to add a "do not disclose" element.

The IESG should note that implementers  of real-world privacy policies are
finding it sufficient to flag a higher-level structure instead of flagging
individual elements.

Is this a possible way forward?

-Scott-

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 11 Feb 2003 11:02:10 -0500

> finding it necessary to add a "do not disclose" element.

Could someone, possibly an implementor, comment on the design choice that
did not utilize the <dcp> element, and disclose its deficiencies? I can
guess, but it would be nice to hear from someone else who considered it
and found it failed to meet a requirement.

Eric

---

From: janusz sienkiewicz <[email-masked]>
Date: Tue, 11 Feb 2003 11:57:05 -0500

Please see my comments below:

> the IESG to consider this possibility.

I would suggest going even further. <doNotDisclose> could be restricted to
social data only. That practically would restrict the element to contact
mapping only. <doNotDisclose> applied in domain or host mapping could lead to
ambigous usage. For example:

<doNotDisclose>
    <host:name>
</doNotDisclose>

may not be necessary be a privacy statement. It could be a DNS policy statement
as well.

I don't see any problem with handling very unlikely and potentially ambigous
privacy statements (domain or host object mapping) within EPP extensions. The
protocol would still offer reasonable level of _INTEROPERATIBILITY_.

> Is this a possible way forward?

Janusz Sienkiewicz

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Tue, 11 Feb 2003 12:23:16 -0500

> social data only. 

We all know what social data is, but do we? Ross had a definitial ID on this
earlier, it has been let lapse, because we'd currently no mechanism which is
dependent upon this. So, I suggest a definition of SD is useful (again).

>               ... That practically would restrict the element to contact
> mapping only. 

It makes no sense to speak of "privacy" or "data protection" of domain or
host objects. Nor of contacts that aren't persons (not legal fictions). Not
in 95/46/EU, nor OEDC Guidelines, nor FTC lack-of-rules frameworks.

>           ... <doNotDisclose> applied in domain or host mapping could lead to

Correct. This has nothing to do with privacy, it has everything to do with
secret-buys, a product. You can buy "secret-product-name.foo" and only your
registrar and registry will know, until you "go public".

> protocol would still offer reasonable level of _INTEROPERATIBILITY_.

They should return errors. EPP provisions 1034/35 publication systems, and some
possible other publication systems. If someone wants a string-space management
protocol, with secret-exhaustion semantics, let them go somewhere else, its a
distraction from the real issue, publication via 954 and 954bis.

Eric

---

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

Posting the schema diff wouldn't hurt either.

---

From: Edward Lewis <[email-masked]>
Date: Wed, 12 Feb 2003 13:44:22 -0500

This is a good request.  This is one of the missing pieces of the 
converstation.

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