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

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Apr 2003 07:31:15 -0400

> So, if we are going to change the protocoll I would like to 
> have something 
> like:
> 
> <domain:ns>
>    <domain:hostAttr>
>      <domain:hostName>myhost.example.com</domain:hostName>
>      <domain:hostType>A</domain:hostAddr>
>      <domain:hostRHS>192.0.2.2</domain:hostAddr>
>    </domain:hostAttr>
>    <domain:hostAttr>
>      <domain:hostName>*.example.net</domain:hostName>
>      <domain:hostType>MX</domain:hostAddr>
>      <domain:hostRHS>10 mail.example.net</domain:hostAddr>
>    </domain:hostAttr>
> </domain:ns>

While I can understand Jörg's historical reasons for suggesting this, this
is a prime example of a feature that should be added via an extension -- I
even have an XML schema set aside for provisioning MX records as a result of
a conversation I had a while back with some folks from .au.  I'll share it
off-list to anyone who asks.

I've already documented mappings for other resource records, including NAPTR
and DS records, that use the extension mechanism.  MX is just another RR
that fits the same way.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 9 Apr 2003 07:33:37 -0400

> > Example domain attributes that describe host machines:
> > 
> > <domain:ns>
> >   <domain:hostAttr>
> >     <domain:hostName>ns1.example.com</domain:hostName>
> >   </domain:hostAttr>
> 
> Here there is a missing <domain:hostAttr> or I'm misunderstanding
> something ?
> 
> >     <domain:hostName>ns1.example.net</domain:hostName>
> >     <domain:hostAddr ip="v4">192.0.2.2</domain:hostAddr>
> >   </domain:hostAttr>
> > </domain:ns>

Ooops, you're right, Fred.  There's a <domain:hostAttr> element missing.
I'll catch and fix those sorts of errors when I fix the documents, schemas,
and examples.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Apr 2003 07:19:37 -0400

> In an attempt to focus the discussion, however, I'd lean towards 
> restricting ourselves towards concentrating on the NS & glue case and 
> not on the MX case.  (MX might not be the only one that could be 
> added.)  It's not that I want to suffocate new ideas in the WG, but 
> it is better to meet the original goal first before expanding the 
> mission.

I concur.  We already have a mechanism for general resource record
provisioning.  Adding another increases the risk of interoperability
incompatibility.

-Scott-

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Apr 2003 07:35:00 -0400

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