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

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> 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?

I think the MUSTs make life more predictable from a client perspective.  If
host object support is announced, you use host objects to do domain
delegations.  If host object support isn't announced you use attributes.
There's no situation where the client is sending something that the server
doesn't explicitly support.

-Scott-

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