To:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>
From:
janusz sienkiewicz <janusz@libertyrms.info>
Date:
Tue, 11 Feb 2003 11:57:05 -0500
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] FYI: EPP implementation by the Polish registry
Please see my comments below: "Hollenbeck, Scott" wrote: > > 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. 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_. > > > 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- Janusz Sienkiewicz