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