Subject: AW: [Enum] Common Issues with ENUM and enumservices

From: Brandner Rudolf <[email-masked]>
Date: Thu, 28 Feb 2002 21:07:38 +0100

Comments inline.

> -----Ursprüngliche Nachricht-----
> Von: Patrik Fältström [mailto:[email-masked]]
> Gesendet: Donnerstag, 28. Februar 2002 17:29
> An: Brandner Rudolf; [email-masked]
> Cc: Conroy Lawrence
> Betreff: Re: [Enum] Common Issues with ENUM and enumservices
> 
> 
> --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.
> 
> > Single question to the list -  should there be another 
> document tied with
> > 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?
> 

Not quite, we know that a CNAME is a complete redirection. This is transparent to DDDS, so there are some impacts on RegExp matching.

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

Interesting, maybe a specific enumservice for prefix dial string. Good idea.

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

I see, you mean in the same zone?

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

Yes, that is strictly true, however, the 'ENUM environment' includes those and they are admin issues.

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

So I look forward to reading this ;^)

>    paf

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

---

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

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

> Not quite, we know that a CNAME is a complete redirection. This is
> transparent to DDDS, so there are some impacts on RegExp matching.

What impacts? Can you give an example?

> I see, you mean in the same zone?

The priority/preference is calculated over all NAPTR with the same owner.
If two sets of NAPTR are in the same zone, but with different owners, the
two sets are used separated from each other.

Example: If I have a.example.com and two NAPTR for that owner, the priority
and preference is calculated over both records, regardless of the service
or flag fields. If also have b.example.com in the same zone, that is not
included in the calculation.

I _think_ you with "zone" mean same "owner", i.e. same domain name?

> So I look forward to reading this ;^)

Hmmm....there are nice books about how DNS works ;-)

  paf