Subject: [Enum] re: teluri-e212 - example of a general case?

From: lconroy <[email-masked]>
Date: Fri, 23 Feb 2007 13:06:04 +0000

Hi again folks,
  Joking apart, I like this draft. Otmar has explained why it's useful.

This ENUMservice talls the client/RRset recipient that this URL holds
"extra" data that MAY be for information only - if one wanted to route
on it (this RRset is associated with B-party number) then a voice:tel
Enumservice might well suffice. We have CIC and the rest of the tel
parameters, so why on earth not have e212 elements as well?

However ...
I do wonder whether this is a special case of a more general use.
Some of the use cases Otmar has elucidated are not always intended
purely (or at all) for routing.
So far, what we don't have as an Enumservice for "auxiliary info".
Maybe it would be useful to specify an Enumservice called be "aux- 
info:tel",
and this e212 case would be subsumed within that. With such an aux-info,
the URL would contain data that was auxiliary to other NAPTRs - normally
one would not route on it. Thus if a client picked up an RRSet and  
one of
the NAPTRs held that Enumservice, one would ignore it and choose another
one when trying to route the call.

Just a thought. Comments welcome.

all the best,
   Lawrence

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

---

From: Edward Lewis <[email-masked]>
Date: Tue, 27 Feb 2007 11:27:46 +0800

>  Joking apart, I like this draft. Otmar has explained why it's useful.

I apologize for being silent the last week, after submitting the 
draft.  I just haven't had cycles to respond.  I have read and 
appreciate the comments to date and am grateful for the help.

>parameters, so why on earth not have e212 elements as well?

As Otmar mentioned too, for the application that motivated me to 
submit the drafts I really only need the MCC and MNC.   But from my 
experience engineering other protocols it is always wise to include 
the "full" piece of data.  I tried to add a sparse statement in the 
security considerations mentioning that the full data may be 
something used only in "private" environments.

>However ...
...
>So far, what we don't have as an Enumservice for "auxiliary info".

This is true, in discussions about what has motivated the drafts what 
we wanted to store is auxiliary information but noticed there was no 
"standard" place to put them.

>Maybe it would be useful to specify an Enumservice called be "aux-info:tel",
>one would not route on it. Thus if a client picked up an RRSet and one of

Being a relative novice in these discussions, I will say that this 
seems to "work for me."  My one caution is that I once tried 
something similar in DNS, that is defining a general category for 
some value.  That effort failed to get a definition made because we 
(the DNS community) felt being non-specific was bad in DNS.  This is 
of course not a rule that must be followed in ENUM despite the 
relationship between ENUM and DNS, there were extenuating 
circumstances.

I would be happy to write a draft for an aux-info ENUM service, with 
a subtype of tel for starters.  Are there any other subtypes that 
might be included?
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."