Re: wildcards and n-send NAPTRs

Hi Jim, Ray, folks,
(i) Sod. The experiences draft (and 3761bis) talk about non-terminal  
NAPTR loop detection and recovery,
but the loop they describe is inside a single ENUM lookup.

It is NOT the result of an ENUM application doing a "same player play  
again" after a terminal result,
as described for send-n.
=> the text currently in Experiences/3761bis doesn't cover this  
scenario. Nor does it cover an ENUM application looking up a telephone  
number, getting a voice:tel NAPTR back with the same number, and doing  
the lookup again.
You can't legislate for complete stupidity (even in Washington D.C. :).

I don't think that 3761bis is an appropriate place to add such text,  
as there has been no discussion there of individual misbehaving ENUM  
applications. To do so now would be a sisyphean task.


However, in the send-n case, looping/spiralling a sequence of  
individual ENUM lookups seems expected behaviour for the send-n  
application, so it must be covered somewhere.

Might I suggest that the Bellis Enumservice spec MUST document this?

Things to cover in that document include (off the top of my head) are:
in a single send-n number processing call, how long a sequence of ENUM  
lookups is valid
is there ever a reasonable case where two ENUM lookups can be done in  
the same ENUM zone by the same device,
is there a reasonable case where identical ENUM lookups can be done  
for the same ENUM zone by different entities in the routing chain,
...

(ii) Also in the document, it would be good to see an estimate of the  
number of DNS queries made for all send-n number processing calls  
needed to route a number, for a known number plan.
It would also be good to see a listing the assumptions about whether  
this is intended to be done by every local switch, or what, and why it  
would be done, and the implications with some given "erlang-level"  
models for a global system (as that seems to be part of the business  
plan for this scheme), ...

(iii) I recall one of the major reasons why ENUM was intended for  
numbers that were reasonably expected to be complete was to avoid  
hammering the DNS - it will get hammered anyway with the number of  
(PSTN) Busy-Hour Call Attempts worldwide. Thus I'm pretty sure that  
the DNS crowd will need to be convinced that this scheme, apparently  
supporting the majority of "steam phones" out there, will not swamp DNS.


(iv) BTW:
Clive said earlier:
>    * IN NAPTR ( 100 10 "u" "E2U+pstndata:send-n"
>                            "!.*!pstndata:send-n/2!" . )
I'm sure there's a good reason why the Enumservice is harris about  
apex in Clive's example.

On 27 Jun 2008, at 13:58, Jim Reid wrote:
> Now it's one thing having applications playing in this nsend world  
> perform loop detection. [How? And where is this documented?]

all the best,
   Lawrence

_______________________________________________
enum mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/enum