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-
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf