Subject: Re: [Iptel] comments on draft-ietf-iptel-tel-enumdi-00.txt

From: "Stastny Richard" <[email-masked]>
Date: Mon, 7 Mar 2005 03:10:03 +0100

Juha,

>1) is it now a common/allowed practise that an enum query can result a tel
>uri containing another e.164 number so that enum query on that can result
>a third e.164 number, etc? 
 
Who is the authority allowing an end-user what he is entering in his domain?
 
>i thought that at some point it was
>recommended that enum query on an e.164 number should return the final
>result.

If a tel: URI is allowed in in ENUM, it may point to a different number,
since this number may also be in ENUM, an ENUM query makes sense.
I agree with you that this may result in an endless loop. There is
two ways to break this. See below.

>2) if so, how can the draft help in preventing loops a -> b -> a?  i
>didn't see any mentioning about that, because according to the draft,
>enumdi indicator is only added if enum query doesn't produce any result or
>produces the same e.164 as result.

>3) should there also be an indicator telling that an enum query was made
>that resulted in this tel uri, which would allow a proxy, for example, to
>implement a non-looping policy?

This is exactly what enumdi does if provided with a tel URI in ENUM,
see my second answer:

My first answer is of course politically incorrect at this list,
because it is using language considered offensive ;-)
One way to break the loop is not documented in IETF because this
is client behaviour, it is instead documented in ETSI TS 102 172
"Minimum Requirements for Interoperability of ENUM Implementations"
http://enum.nic.at/documents/ETSI/Drafts/05TD142r3%20DTS_102172v020006.pdf

It says basically that a client should do only 5 such quireies, e.g in Section 10.3.1

Full citation:

A gateway from the PSTN to the Internet may be ENUM enabled to route 
calls to destinations potentially "published" in ENUM. This gateway MAY 
support only a limited range of ENUMservices, which can be accessed by the PSTN..  

After processing the information retrieved from ENUM according to 
section 10.1., the ENUM enabled application client looks for the specific 
ENUMservices it supports. This MAY be e.g. "sip", "h323", "voice:sip", 
"voice:h323", "voice:tel", "ifax:mailto", ... 

If a "voice:tel" is chosen, and the E.164 contained in the "tel" URI is 
different from the number originally queried, the ENUM enabled application 
client SHALL launch another ENUM query for the number given (as if it had 
received a NAPTR containing the 'enum' Enumservice, as described in 
section 9.4.1.7). To prevent endless loops, the client SHALL make only a 
maximum of 5 such redirections. In the subsequent queries only "voice", 
"sip" or "h323" ENUMservices SHALL be considered. 

If any of these queries returns any "voice" ENUMservice except "voice:tel", 
this ENUMservice SHALL be used. 

If any of these queries returns a "voice:tel" with the same number as queried 
or an NXDOMAIN, the call SHOULD be processed further by querying infrastructure 
ENUM, another database or by routing the call directly to the PSTN, if the gateway 
is providing this. If the gateway is not providing this functionality, "no such service" 
SHALL be indicated. 

If the call is passed on to another network element, the "enumdi" parameter SHALL be set. 

End of citation.

The second way to prevent an end-less loop is descibed in the draft itself
in Section 4.2 in the second bullet point:

Citation

When a VoIP network element accesses ENUM in e164.arpa for a given
   E.164 number and either:
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      that has the same E.164 number, or
   o  the result of the query includes a NAPTR RR containing a "tel" URI
      with the "enumdi" parameter set,

   then if that retrieved "tel" URI is chosen to be passed to the next
   network element, the sending VoIP network element MUST pass on the
   retrieved URI with the "enumdi" parameter set.

End of citation

I hope this answers your questions

-richard

>-- juha

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

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

---

From: "Juha Heinanen" <[email-masked]>
Date: Tue, 8 Mar 2005 12:21:55 +0200 (EET)

> Who is the authority allowing an end-user what he is entering in his

no authority is needed.  if someone enters an enum entry that results in
e.164 number that is not the final one, then that final one will never be
reached if only one enum query is done by other parties.

> It says basically that a client should do only 5 such quireies, e.g in

where does number 5 come from?  looks like someone just made it up.  i
argue that 1 is better than 5.

>       with the "enumdi" parameter set,

this makes sense, but the 5 thing doesn't.

-- juha

---

From: lconroy <[email-masked]>
Date: Tue, 8 Mar 2005 12:46:26 +0000

Juha
  whilst I'm glad that you noticed this and have finally decided to
comment, please could you discuss ENUM issues on the ENUM list.
The loop detection and recovery text has been in the ENUM experiences
draft - since 2003.

Now, if your application chooses not to do only one lookup, that's fine.
It's your program logic, not the ENUM client.

However, that ENUM client will need to be resilient to misconfiguration
of the DNS zone content. That's what the loop detection is about. That's
a "pure" ENUM topic, not one for IPTEL.

We return you to your normal program.

atb,  L

> this makes sense, but the 5 thing doesn't.
---------------------------------------
lawrence conroy    |tel:+44-1794-833666

---

From: Juha Heinanen <[email-masked]>
Date: Tue, 8 Mar 2005 18:25:22 +0200

> It's your program logic, not the ENUM client.

i'm not getting your point.  draft-ietf-iptel-tel-enumdi-00.txt does not
allow the entity that makes enum query to add ;enumdi param whenever
enum query was done.  it can only be done, if the same e.164 number was
returned or if dns gave negative answer.  even if enum query was done 5
times, it still does not allow addition of ;enumdi param.  so the next
entity has again needs to do its query or queries, etc.

-- juha