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

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

> I would suggest going even further. <doNotDisclose> could be restricted to
> 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
> 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.

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

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

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