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


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


Home | Date list | Subject list