Frank, I'm still trying to understand the points you are trying to make. I'm not sure if I've been successful, so I'll try instead to respond to specific points in the hope that it all makes sense when taken as a whole. Comments inline below. -Scott- > -----Original Message----- > From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On > Behalf Of Frank Thompson > Sent: Monday, October 25, 2004 2:21 PM > To: iesg@xxxxxxxx > Cc: ietf@xxxxxxxx > Subject: objections: draft-ietf-enum-epp-e164-06.txt > > > Hi All, > > I would like to raise an issue with this draft which is > currently in "Last > Call" in regards to the storage of the <e164:natpr> extension element: [snip] > Objection: > > The mandatory inclusion of one or more <e164:naptr> elements is > the major point of contension. By way of using the current > epp schema for > domain mapping, <ns> elements may be used to point to > external DNS servers > which will host the owning NAPTR records. Thus creating a > "thin" enum > registry while still accepting and generating "referral" e164 > domains. > This allows the registry to host the native NAPTR records and > all the > personal details that come along with that data or allow an > external name > service to host these dynamic NAPTR records. Mandatory inclusion of the <e164:naptr> elements is the whole point of the extension. If you only want <domain:ns> elements, you don't use the extension. Please note, too that <domain:ns> elements are OPTIONAL. It is already a supported feature of the specifications to allow <e164:naptr> elements without name server delegation information, and vice-versa. > As a further extension to the current support for > <e164:naptr> is > the ability to allow <e164:cname> or <e164:dname> support. > These would > work much like the above <ns> approach, in that the zone generated > by the registry would point to an external DNS that would > then resolve > the actual NAPTR records for public use. While these are > more experimental > additions, they are a valuable addition to the draft, while > enum trials > are taking place to see how usability case studies perform in > the real world. There is no mention of CNAME or DNAME provisioning requirements in RFCs 3403 or 3761. That being the case, I don't agree that they should be included in this extension. If someone is using them for some experimental purpose, they should write their own extension describing their use. > To ensure the integrity of the e164 domain, only one of > the four > types may be associated with an e164 domain at a time. The > four types are > <ns>, <e164:naptr>, <e164:cname> and <e164:dname>. This way the zone > generated for the e164 domain names will have a deterministic > output each > and every time. As I said above, I disagree with the <e164:cname> and <e164:dname> assertion. I also disagree that <domain:ns> elements and <e164:naptr> elements are mutually exclusive. If a particular operational scenario requires use of one while excluding the other, the current specs already support that. -Scott- _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf