To:
Edward Lewis <edlewis@arin.net>
cc:
"Hollenbeck, Scott" <shollenbeck@verisign.com>, "'Joe Abley'" <jabley@isc.org>, "'ietf-provreg@cafax.se'" <ietf-provreg@cafax.se>, brunner@nic-naa.net
From:
Eric Brunner-Williams in Portland Maine <brunner@nic-naa.net>
Date:
Fri, 11 Apr 2003 19:41:28 -0400
In-Reply-To:
Your message of "Thu, 10 Apr 2003 11:27:41 EDT." <a05111b04babb3a18bc67@[192.136.135.238]>
Sender:
owner-ietf-provreg@cafax.se
Subject:
Re: [ietf-provreg] References for Today's Host Object Discussion
... > Well, I was going to make other statements, but writing an ironclad > rule would be foolish. I was going to say something about only > including what is generic to all registry policies, but then the > client-provided "privacy" meta-data (with apologies to EBW) would > fail the test. Just for clarity, the <dcp> still is for a registry (server) mechanism for data collection policy announcement, whether MANDITORY or OPTIONAL. The directionality could be reversed, and a registrar (client) mechanism for data donor policy constructed, again, MANDITORY or OPTIONAL. > ... (Not all registries will want to deal with > client-provided data...) And not all registrars will want to deal with server policies either. Some will want the current CNO rules (none, or ICANN). > ... The difference between the 'privacy' (sorry > EBW) and the MX issue is that the umbrella issues are different. Actually "privacy" can't apply to an MX record under the 96/46/ec framework, and it is hard to see how anything other than "non-disclosure" could apply in the US or OECD set of frameworks. There is no "individual" in an MX record. > 'Privacy' (sorry EBW) is further reaching through the realm of > registry operations (and registrar operations) than the use of the MX > record for the health of registrations. (Not all > registries/registrars will perform such thorough testing, but all > will deal with, sorry EBW, privacy.) This is a good point, regardless of the policies associated with "privacy" (sorry EL) or MX records (and publication via 1034/35 generally), the mechanism that provisions an MX record to a zone file (any format) is more narrowly constrained that the mechanism that generally provisions data, some of which will end up in a zone file, or on the floor, to a registry. Imagine a registry that did not publish data via 1034/35, but only via 954. Solving for MX does not solve for the whole problem. Yes, there are registries that only publish via 1034/35, and not by 954. I don't think I've ever seen my initials so ... exhuberently frequent in a single piece of mail. ...as rare as sushi at a forest service fire fighter's bar ... Cheers, Eric