RE: [ietf-provreg] References for Today's Host Object Discussion

[Edward Lewis <edlewis@arin.net>]

Apologies to the group - I was in a "ARIN member meeting black-out" 
for a few days...

At 13:56 -0400 4/8/03, Hollenbeck, Scott wrote:
>Ed: so when can we move forward with document edits for this and the privacy
>proposal?

I've got one question about the below, and I would like to hear Jörg 
Bauer's thoughts on making the MX registration an extension as you 
(Scott) suggest.

My question - do you want these to be MUSTs or SHOULDs?  I understand 
the desire that a server (operator) be consistent, but is this vital 
to the protocol?

As far as the MX RR issue, as a protocol person, I think that I can 
see why you would limit the EPP core spec to doing just the A 
records.  IMO, the A record - and I should point out that we have to 
be IP version fair according to our requirements - or the AAAA or any 
other experimental/future address record is a special case here. 
Only address records are eligible to be glue in DNS, MX's and others 
aren't.

Using MX records and others for registry debugging is fine, but it is 
a registry policy to do so and therefore out of scope for the core of 
EPP.

So, as a chair I'm urging the group to consider the issue Jörg raised 
in the context of:
     1) From a generic protocol design perspective, there is a reason to
        treat DNS data eligible to be glue (A RR) differently from those
        that are not (MX).
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.  (Not all registries will want to deal with 
client-provided data...)  The difference between the 'privacy' (sorry 
EBW) and the MX issue is that the umbrella issues are different. 
'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.)

>Text:
>
>"Name server hosts for domain delegation can be specified as either
>references to existing host objects or as domain attributes that describe a
>host machine.  A server operator MUST use one name server specification form
>consistently.  A server operator that announces support for host objects
>MUST NOT allow domain attributes to describe a name server host machine.  A
>server operator that does not announce support for host objects MUST allow
>domain attributes to describe a name server host machine."
>
>The idea here is that it's a bad idea to allow some domain objects in a
>repository to reference host objects and others to use domain attributes
>that describe a host machine.  Using one form consistently will make
>implementation and server management easier.

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

   ...as rare as a fire at a sushi bar...