To: "Hollenbeck, Scott" <email@example.com>
Cc: "'Joe Abley'" <firstname.lastname@example.org>, "'Edward Lewis'" <email@example.com>, "'firstname.lastname@example.org'" <email@example.com>
From: Edward Lewis <firstname.lastname@example.org>
Date: Thu, 10 Apr 2003 11:27:41 -0400
Subject: RE: [ietf-provreg] References for Today's Host Object Discussion
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...