From fot(_at_)ca(_dot_)afilias(_dot_)info Mon Nov  1 08:46:19 2004
Date: Wed, 27 Oct 2004 16:24:43 -0400 (EDT)
From: Frank Thompson <fot(_at_)ca(_dot_)afilias(_dot_)info>
To: "Hollenbeck, Scott" <shollenbeck(_at_)verisign(_dot_)com>
Cc: "'iesg(_at_)iesg(_dot_)org'" <iesg(_at_)iesg(_dot_)org>, "'ietf(_at_)ietf(_dot_)org'" <ietf(_at_)ietf(_dot_)org>,
     enum(_at_)ietf(_dot_)org
Subject: RE: objections: draft-ietf-enum-epp-e164-06.txt

On Wed, 27 Oct 2004, Hollenbeck, Scott wrote:

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

Scott,

I have read your comments and I can see now that the current draft will 
support both the NS delegation model and NAPTR delegation model with no 
changes needed.  If one chooses to use NS delegation, they simply do not 
include the <e164...> extension and likewise if they choose to use NAPTR 
delegation include the <e164...> extension.  The grounds for my argument 
were the result of the implementation I was asked to support which 
included at the time <domain:ns>, <e164:naptr>, <e164:cname> and 
<e164:dname>.  Since <e164:cname> and <e164:dname> have no clear 
direction in the context of this draft, the optional <e164:naptr>  
support I was looking for can easily be found in the base epp 
standard by default as <extension>'s are already optional.

Thank you for making what should have been an obvious observation clear in 
your comment below, it became apparent as soon as I read your comment that 
the current EPP and the E164 draft could work without modification. 

Therefore, at this time I would like to formally withdraw the objection to 
the draft, sorry for the confusion this may have caused and thanks for 
taking the time to comment on my objection.

frank

> 
> > -----Original Message-----
> > From: ietf-bounces(_at_)ietf(_dot_)org [mailto:ietf-bounces(_at_)ietf(_dot_)org] On 
> > Behalf Of Frank Thompson
> > Sent: Monday, October 25, 2004 2:21 PM
> > To: iesg(_at_)iesg(_dot_)org
> > Cc: ietf(_at_)ietf(_dot_)org
> > 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-
>