Subject: [Enum] Common Issues with ENUM and enumservices

From: Brandner Rudolf <[email-masked]>
Date: Wed, 27 Feb 2002 19:57:07 +0100

There seems to be a missing element to the documents as proposed in 2916bis. Maybe there's room for another document, giving general issues that are common either to the use of existin DNS features or to all enumservices.
This SHOULD NOT discuss which tree within the DNS forest should hold ENUM NAPTRs. 

Single question to the list -  should there be another document tied with these others that describes these items?

Background:
While writing the tel enumservice draft, we realized, that there were some possible uses of DNS that were related. For example, a CNAME could be used to represent a forwarding service. However, some issues with the use of a CNAME RR within e164.arpa are not really tied to the tel enumservice at all. Instead, they are common to all enumservices (and potentially general to all uses of NAPTRs).

Also, while looking at the overall service that could be provided, we considered data to be held in other trees of the DNS (please note - this is NOT intended to trigger another "use my TLD" blast of hot air, my air-conditioning bill for reading this list has already exceeded this year's budget).

For example, a NAPTR (*not* using the ENUM service) could store useful data, which could also be used by a client of ENUM when dealing with the returned enumservice. An example we gave were for storage of service provider contact info (e.g. phone number) or prefix dial string. In addition, we considered how to report a broken listing and CLI my not give an immediately useful identifier.

Finally, we wondered about priority/preference and order. A suggestion was made, that a particular enumservice should have precedence over another, or there should be only one NAPTR.
What is the resolution process if more than one enumservice document makes the same stricture?

All of these issues are not unique to the tel enumservice and they haven't to do with the base procedures of 2916bis or the proceures described in the DDDS documents, hence the question.

Rudi

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

---

From: Patrik Fältström <[email-masked]>
Date: Thu, 28 Feb 2002 11:28:38 -0500

--On 2002-02-27 19.57 +0100 Brandner Rudolf
<[email-masked]> wrote:

> There seems to be a missing element to the documents as proposed in
> 2916bis. Maybe there's room for another document, giving general issues
> that are common either to the use of existin DNS features or to all
> enumservices. This SHOULD NOT discuss which tree within the DNS forest
> should hold ENUM NAPTRs. 

I have some comments / questions...because I don't really get it. Sorry.

> these others that describes these items?

Maybe.

> Background:
> While writing the tel enumservice draft, we realized, that there were
> some possible uses of DNS that were related. For example, a CNAME could
> be used to represent a forwarding service. However, some issues with the
> use of a CNAME RR within e164.arpa are not really tied to the tel
> enumservice at all. Instead, they are common to all enumservices (and
> potentially general to all uses of NAPTRs).

If you have a CNAME with one owner, you can not at the same time have NAPTR
with the same owner. Instead, you can have a NAPTR which reference to a
different owner where the final NAPTR resides, by having an empty flag
field.

So, already today, you _can_ have a pointer from one record in one zone to
a record in a different zone. Different zones, different administrative
entities.

Is your point the need for different entities for different NAPTR records?

> Also, while looking at the overall service that could be provided, we
> considered data to be held in other trees of the DNS (please note - this
> is NOT intended to trigger another "use my TLD" blast of hot air, my
> air-conditioning bill for reading this list has already exceeded this
> year's budget).

:-)

> For example, a NAPTR (*not* using the ENUM service) could store useful
> data, which could also be used by a client of ENUM when dealing with the
> returned enumservice. An example we gave were for storage of service
> provider contact info (e.g. phone number) or prefix dial string.

Possible with specific enumservices from my point of view. Maybe them will
also use tel: URI schemes?

> In
> addition, we considered how to report a broken listing and CLI my not
> give an immediately useful identifier.

Ok.

> Finally, we wondered about priority/preference and order. A suggestion
> was made, that a particular enumservice should have precedence over
> another, or there should be only one NAPTR. What is the resolution
> process if more than one enumservice document makes the same stricture?

The priority/preference must be calculated over all NAPTR records with the
same owner. I.e. it is calculated as part of the DNS resolution, and not
the NAPTR resolution.

> All of these issues are not unique to the tel enumservice and they
> haven't to do with the base procedures of 2916bis or the proceures
> described in the DDDS documents, hence the question.

I have not described the priority/preference issues, and I have not
described the (in-)ability of using CNAME, empty flag fields for NAPTR
records etc because those are DNS issues, and not ENUM issues.

Not saying I don't want to write about them. Just as an explanation.

   paf