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

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 28 Feb 2002 18:02:43 +0100

Hi folks,

reading the officiall issue of ID RFC2916bis very carefully, I recognized
that the authors added the part on the blank flag, which indicates a
non-terminal rule

So we have now three and a half ways for redirection:
CNAME
no flag
tel with and without flag (if tel with flag U is considered terminal)

There are of course some subtle differences (please enlighten me if
something is wrong or missing)

1. CNAME allows no other NAPTRs and therefore redirects the whole zone.
2. no flag redirects only the one NAPTR record, if it already decided to use
that NAPTR record, so it redirects only one service?
3. Tel with U flag terminates, that is I SHALL use this number to make a
phone call
4. Tel without flag is like 2., it redirects the tel service (hopefully not
in a monday loop, Lawrence)

Is this correct?

As already stated, I am not an expert with ERE, what happens with the AUS in
all this cases?

regards
Richard

Richard STASTNY
OeFEG
Arsenal Objekt 24
P.O. Box 147
A-1103 Vienna, Austria

Tel: +43 664 420 4100
Fax: +43 1 79780 13
[email-masked]
[email-masked]

> -----Original Message-----
> From: Patrik Fältström [mailto:[email-masked]]
> Sent: Thursday, February 28, 2002 5:29 PM
> To: Brandner Rudolf; [email-masked]
> Cc: Conroy Lawrence
> Subject: 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?
> 
> > 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
> 
> 
> _______________________________________________
> enum mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/enum
> 

_______________________________________________
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:37:13 -0500

> that the authors added the part on the blank flag, which indicates a

Nice, isn't it? :-)

> tel with and without flag (if tel with flag U is considered terminal)

tel without a flag?

You talk about no flag, but with E2U+TEL as the service?

> 1. CNAME allows no other NAPTRs and therefore redirects the whole zone.

Redirects the domain name. You imply that the zone has the same owner as
the record, and that is not good. I would say impossible, as a zone have
always by definition an SOA record.

> 2. no flag redirects only the one NAPTR record, if it already decided to
> use that NAPTR record, so it redirects only one service?

Only that NAPTR. Other NAPTR might have the same service.

> 3. Tel with U flag terminates, that is I SHALL use this number to make a

U is terminal. Correct.

> 4. Tel without flag is like 2., it redirects the tel service (hopefully
> not in a monday loop, Lawrence)

Yes.

> Is this correct?

Yes, modulo that the terminology issues about redirection with CNAME.

   paf