Subject: [Enum] draft-ietf-enum-e164-dns-02.txt: E2U and URI

From: Hong Liu <[email-masked]>
Date: Sun, 23 Jul 2000 22:21:29 -0400

Patrik,

I noticed the following changes made in draft-enum-e164-dns-02.txt, as
compared to draft-enum-e164-dns-00.txt:
(1) A new service type, E2U, is defined for ENUM, instead of using "N2R"

(2) The URIs returned are now in the regexp field of NAPTR, instead of
in the replacement field.

I see these are good changes that have addressed the two concerns I
raised regarding draft-enum-e164-dns-00.txt in an earlier email. I still
have some questions regarding these changes:
(A) What is the guideline for defining a new service type in NAPTR? What
I am trying to find out is whether there will be coordinations between
what we try to do in ENUM and what the URN group try to do in evolving
NAPTR. Is IANA involved in this process at all?
(B) The use of regexp field is a two-sided sword. It is powerful but is
also error prone if not used with care. It would help if you can
enumerate some well-defined templates in the document for the common
cases when using this mechanism .

Cheers,

--Hong

_______________________________________________
enum mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/enum

---

From: Patrik Fältström <[email-masked]>
Date: Sun, 23 Jul 2000 19:39:57 -0700

>(1) A new service type, E2U, is defined for ENUM, instead of using "N2R"

Correct. That was because this wg wanted to have that.

>in the replacement field.

It must be according to the NAPTR spec. I missed that in early 
revisions. Michael Mealling pointed that out to me.

>NAPTR. Is IANA involved in this process at all?

Specified in RFC 2483.

>cases when using this mechanism .

You can always do misspellings in all different kind of RRs, which 
all point to catastrophic results. What do you think the impact is 
when someone at NSI misspelled the hostname of a nameserver for a 
ccTLD? Pretty bad that aswell...

    paf

---

From: Hong Liu <[email-masked]>
Date: Tue, 25 Jul 2000 20:46:51 -0400

Patrik,

I have a couple of comments regarding your reply.

Cheers,

--Hong

> Correct. That was because this wg wanted to have that.

I am for it. I just did not recall any discussions on the mailing list until
I saw it in the 01 draft. Again, I may miss the discussion.

> ccTLD? Pretty bad that aswell...

It is assumed that DNS administrators shall be versed in populating DNS RRs.
They are expected to do it right, though I would argue that they do not have
to deal with regexps RRs until NAPTR. I assume that NSI has a well-defined
QMO rules in place concerning the changes made to their database.

ENUM is somewhat different, since individual subscribers may be able to
update his/her own RRs by themselves (see my email on this issue regarding
self service provisioning.). Even for average DNS administrators, the chance
of making a mistake with regexp is still quite high and these mistakes are
not easy to catch. That is why I suggest that your document provide some
templates for well-defined cases so that people can just cut and paste. Or
other DNS tools may be needed for simulating the substitution before it gets
into the database.

---

From: Patrik Fältström <[email-masked]>
Date: Tue, 25 Jul 2000 18:19:34 -0700

>I saw it in the 01 draft. Again, I may miss the discussion.

It was a proposal on the mailing list to change the service, which 
Michael backed up (as creator of the NAPTR). I had some discussion 
with him which resulted in me being convinced that the only really 
good thing to do was to define the whole E.164->URI algorithm which 
uses NAPTRs. Remember that some other (URN-like) service might store 
NAPTRs with the same owner which you are not supposed to use when you 
do E.164->URI resolution, and you as the one querying DNS need to 
know which one of the NAPTRs you should use.

>other DNS tools may be needed for simulating the substitution before it gets

I thought the examples were enough, but to be honest, I expect people 
not to run their own DNS servers. They do not do that today even. 
I.e. the large masses let their ISP handle the domain for them, and 
the ISPs have DNS servers aswell as tools which makes it possible for 
a customer to change the content of DNS.

I expect such tools at the service providers of DNS services, which 
can be ISPs, telcos, or redirection services, and if I were them, I 
would have a web based interface which helps the user construct the 
correct NAPTR.

    paf