Subject: [Enum] sipping-e164 comments

From: Lawrence Conroy <[email-masked]>
Date: Wed, 13 Feb 2002 20:14:34 +0000

Hi Folks,
    taking Richard at his word that ENUM is an appropriate place to discuss
the sipping-enum document (and avoiding the wrath of Brian Rosen by not
cross-posting), I have a few comments; these are not (to my knowledge)
regulatory issues, so most of the group can resume its horizontal posture.

First, I must say that I like this work. I'm not quite sure of the scope,
and have some concerns that it is looking at the scenarios current for
the use in public telecommunications systems only - i.e. it may have more
to say than the purely technical. However, we need this in order to give
information that is (correctly) lacking in 2915/2916. My comments are put
inside square braces. From my reading of the draft::

--------------------------
It has a number of recommendations and disrecommendations.

My initial scan of these comes up with:
*	Use SIP registration services to differentiate
-	NAPTR content should show address of record, not current 
contact address
-	Use a single SIP identity, and let the SIP system disambiguate between
	multiple concurrent contacts (e.g. work and home)
[That's fine *for SIP* but may complicate and/or restrict the applicability
  of ENUM to reference only from IP-based devices. I can at least envisage
  ENUM being used to list my "steam" telephone for use from a hybrid (or
  non-IP based) telephone -- if only as part of a directory system. Using
  a SIP registration service may not be appropriate in all cases.]

*	SIP should be the service of choice.
-	Use 'SIP+E2U' rather than a putative 'TEL+E2U' service field
-	Use 'sip:' rather than 'tel:' scheme within 'SIP+E2U' service
-	If records including tel: URIs are present in the NAPTR resource record
	set, then they should be at a lower priority than 'pure' sip: URI.
[Brave...(this risks SG16 jumping up & down on your collective heads :).
  The arguments for sip: and against tel: are well put. I'll duck the sip:
  versus h232: issue. However...
There may be scenarios in which ENUM is used to identify a GSTN-connected
  device for use when dialing out from another GSTN-connected device. In
  such a scenario, indicating a sip: scheme may automatically direct the
  client to dial out to an MGC/MG combination, only for that to "bounce
  back" to the PSTN again. I may consider my SipPhone to be a different
  service from my "steam" phone, and I'm afraid to admit that the sip
  service pointing at the AoR known to the registrar with which my SipPhone
  is associated may not be listed as the highest order. Maybe in a year...
Disambiguation using a single SIP AoR is a good idea IFF there is *a* SIP
  service provider with which I have (a) registration{s}. However, even if
  I do use SIP service, I may have more than one provider - I have more than
  one email account, and (even for SIP systems) the text in the draft reflects
  only one view of the future.]

*	Although NAPTRs use regexp, the examples in 2916 all use the "throw
	it away and replace with" form. This SHOULD be used.
[Absolutely agree. One could argue that alternatives SHOULD NEVER be used,
  if only as they represent a nightmare for validation prior to populating
  the domain space, and can easily lead to unintended mappings. Fuzzy matching
  is useful for URN resolution, but fuzzy replacement is totally inappropriate
  for many other uses; not only the e164.arpa hierarchy.]

*	The contents of any tel: URI must not refer to the zone in which it
	is placed (i.e. there should not be a 'tight loop', with a phone number
	mapping to itself).
[This is well put. There should be some specification for expected Client
  treatment of looping behaviour in ENUM queries, or in recursive recursive
  recursive ENUM queries on telephone numbers. However...
I may want to indicate that this is a "final" telephone number, and that
  even though other records exist within the e164.arpa hierarchy for which
  I am authoritative, I do not wish this particular traversal to continue.
An easy way of doing this is to force a tight loop. The expected client
  behaviour in this circumstance might be to use the current zone as the
  number to dial out. It's inelegant (and occupies space in the database)
  so perhaps enabling an "outer" recursion stopper in the ENUM system using
  a cleaner (and more compact) format is a candidate for the proposed update
  to RFC2916. Note that this deals with re-submission of tel: URIs to the ENUM
  hierarchy, and so does not affect RFC2915.
A client MUST be ready to handle loops, not only this tight loop.
For example, I might have two zones; one associated with my cell phone with
  the other associated with my work phone.
  Given the genius of our architects, the building in which I work has no cell
  phone coverage. Thus I have been known to forward calls to my cell phone to
  my work number. Also given that some people are unaware of the concept of
  time zones, I have been known to forward my work calls to my cell phone.
  Yes, I have forgotten and left a loop in place, notably on Monday morning.
  This is bound to happen within the ENUM system, so I'd suggest that there
  should be some text proposing expected behaviour in the face of such a loop.
  Whilst servers should be ready to handle such looping behaviour on the part
  of clients, it SHOULD be at least SHOULD strength on clients, and ideally
  such expanded text is a candidate for the RFC2916 update Patrik proposed.]

*	A general sip service should be used, not separate entries 
for different
	media types. Thus, a basic sip URI is MUCH preferred to 
separate entries
	specifying different media types (e.g. an entry for SIP+E2VOICE, with
	another for SIP+E2VIDEO). This argument extends to a disrecommendation
	of IM+E2U and PRES+E2U (or SIP+E2IM and SIP+E2PRES).
[I am not happy completely with this proposal. Whilst I fully agree that
  partitioning entries for real-time media service with separate NAPTR records
  is not a good idea, there may well be a separation between real-time media
  service (using SIP), and non-real time service such as presence or IM
  -- I for one may not use the same service provider for my multimedia service
  and my "non-real-time" IM or presence service.]

*	DNS returns common (or public) information, and SIP can be 
used to avoid
	some of the privacy issues by requiring authentication. However, it may
	be a bad idea to put identifiable information into a SIP+E2U 
NAPTR record
	so <sip:[email-masked]> may have unintended 
consequences. The
	DNS system will return this information to anyone sending the query and
	exhaustive search of the e.164.arpa space could easily extract it.
[Very good point - if only as the ENUM server operators will be unamused at
groups of people doing exhaustive queries of the domain space.]

--------------------------

The draft also includes some limitations of ENUM, as described in RFC2916.
This list is interesting, and seems to reflect the intended use of 2915 and
2916 for public telecommunications based resources. Thus:

*	Arbitrary strings are not used.
[this is certainly true for the e164.arpa domain space.]

*	Private number spaces cannot be used.
[Strictly, this is because ENUM as currently envisaged, operates using E.164
  number space. I can use a full ENUM system that is unconnected with the
  rest of the world for my enterprise; I may not interconnect any private
  ENUM-like directory service with the public one and expect it to work.
  Does anyone use unregistered IP addresses within internal (unconnected)
  IP networks? Yes, it is a pain when migrating, but it happens.]

*	National (or origin-dependent) numbers cannot be used without 
conversion
	to E.164 number form.
[ENUM operates using E.164 number space; I'm not sure that unqualified
  national (or local) numbers are within this space.]

*	Incomplete E.164 numbers cannot be indicated as such by ENUM
[Actually, this is may be a parochial view; ENUM deals with a number space
  that "descends" from a global E.164 root.
  In some regions, there are variable length numbers, even within a given
  number block. It is perfectly possible to phone +498938450, or to phone
  +498938452525 -- one reaches the "pilot number" for the Munich Park Hilton
  whilst the other reaches the reservation desk.
  Although each of these, *in the current public telephone network* will be a
  leaf zone, this need not be the case for all future systems.
Thus, a particular zone within a hierarchy akin to ENUM Tier1 might, in the
  future, include a NAPTR record referring to a "pilot number", as well as a
  set of sub-zones referring to extensions within an enterprise; a query may
  not be incomplete but target the parent zone within which an enterprise's
  DDI sub-zones are stored - this could result in a "pilot number" being
  returned. Whilst this would not be used in the current infrastructure, it
  is perfectly valid within the DNS (e.g. cnn.com returns a valid A record),
  and I'm not happy that we exclude this for all time - It's a GSTN limitation.

As an aside, it's a goal to specify the operation of the currently envisaged
  public telecommunications ENUM system - that's one of the charter items for
  the IETF ENUM WG, I believe. Perhaps this text reflects that goal, in which
  case I wonder if it should be extracted and placed in another draft?

Conversely, a particular number block within the ENUM hierarchy may have no
  NAPTR records but instead consist solely of NS records pointing to Tier2
  leaf zone servers. The absence of such a NAPTR record should be indication
  to a client that either the authoritative server has no appropriate entry
  or that the query zone is a parant only (e.g. they have entered an incomplete
  number).]

*	The reason for E.164 prefix entries and expected behaviour on receipt
	of a query for them is not specified.
[Strictly, it is perfectly valid to query within the e164.arpa domain space
  for a "non-leaf" zone. One can send a query for the NS resource record
  associated with a non-leaf zone (rather than the NAPTR), for example.
  Equally, one may query the SOA resource record for a parent zone.
As suggested above, it may even be valid to have a NAPTR associated with a
  parent zone. Thus the comment that it is not meaningful to create records
  at non-leaf zones, or to send a query on such a zone (with an "incomplete"
  number) is too strong. They may be the exception within the normal operation
  of ENUM, but there may be valid reasons for entering the records and
  performing some queries on non-leaf zones.]

--------------------------

best regards,
   Lawrence
-- 
[email-masked]: +44 1794 833666::<my opinions>:

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

---

From: "Peterson, Jon" <[email-masked]>
Date: Thu, 14 Feb 2002 22:09:42 -0600

I'm glad you enjoyed the draft, Lawrence. A couple of comments below.

Jon Peterson
NeuStar, Inc.

> -----Original Message-----
> From: Lawrence Conroy [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 12:15 PM
> To: Jon; Rudi
> Cc: [email-masked]
> Subject: sipping-e164 comments
> 
[snip]
>   a SIP registration service may not be appropriate in all cases.]

Well, this is pretty obviously a SIP-specific draft - not all of this will
serve as general recommendations for ENUM. To be clear, though, ENUM is a
system that turns E.164 numbers into URIs - if it were designed to point to
individual devices then the feature-richness of a URI wouldn't be required
(we could define an 'E24' resolution service for IPv4 addresses). Also, as
I'm sure you know the draft recommends the one-record model for SIP-based
records alone. For example, I've read that this sort of one-record model
isn't appropriate for VPIM.

[snip]
>   is associated may not be listed as the highest order. Maybe in a year...

We do include a proviso for a tel URL so that ENUM can call out to the GSTN
if necessary. I agree with what I think to be your core proposition here -
that even an SS7 switch could be equipped with an ENUM interface, and it
could use it for its own number routing functions.

>   only one view of the future.

This is really a tough question - I expect this to be the most controversial
SIP issue in the draft. I really believe that the problem of possessing
multiple AoRs is a pseudo-problem.

The issue here is really the way that ENUM would decide which one of many
SIP addresses-of-record to use. As an author of ENUM records, you would
probably have to decide 'this is my priority one AoR, and this is my
priority two AoR'. Presumably what will happen when prospective users get
this information is that they will try to call you at the first AoR, and if
there are no devices registered there, or the call fails for whatever
reason, they'll try to call at you at the second AoR. This information is
static - as an author of a record set, you aren't going to update your ENUM
records every time you go from work to home, so your first AoR will always
be attempted first, and your second second. I suppose if you really didn't
care about preference you could also just give them equal preference and let
chance decide on a per-call basis.

Ultimately, this strikes me as a little forced, and contrary to the SIP
model. A SIP AoR isn't a device - it's an identity under which devices
register. Registration allows dynamism that is responsive to the needs that
motivate having multiple AoRs - that you communicate in different contexts,
and that you are available from different places at different times. A user
has a prerogative to register devices (and other AoRs) under the AoR of
their choosing. Even if there are specific devices that you cannot move out
from under a particular AoR (thanks to walled-garden service deployments) as
your context changes, clearly the above flow would resolve much more smooth
if you registered the AoR that isn't under your control under another AoR
which is, and composed your communications there. AoRs, I think, will never
be a scarce commodity - they are just identities, like email addresses
today. I foresee no technical, political or economic issues that might
discourage this view in the future - this is a great deal of the core value
of SIP. 

For these reasons, we do strongly that you have one AoR in ENUM, and let SIP
do the rest. If you still disagree after reading the above (and re-reading
section 3.5 of the doc), then by all means follow your own counsel - we
won't hold it against you. Our primary goal in the draft is bring these
issues to your attention.

> 
> *	A general sip service should be used, not separate entries for
different
> 	media types. Thus, a basic sip URI is MUCH preferred to separate
entries
>   and my "non-real-time" IM or presence service.]

I believe IM and presence are very much real-time services. As an aside,
note that we do say that non-real-time services (like HTTP and SMTP) could
probably best be managed by ENUM rather than SIP. And incidentally, even if
you do use different service providers for voice and IM, pursuant to my
point in the previous section, I still believe the two could be composed
under a single AoR if necessary.

That said, I am secretly somewhat sympathetic to 'PRES+E2U', because you
would probably send a SUBSCRIBE to the URI it identifies rather than an
INVITE. Admittedly, if there were only a 'SIP+E2U' URI, you'd still just
send a SUBSCRIBE to that if you wanted presence. But this is a story for
another day.

[snip]
>   and I'm not happy that we exclude this for all time - It's a GSTN
limitation.

Okay. Personally, I'm not really sure how one handles zones, number ranges,
partial E.164 numbers, etc. in ENUM. I've heard a number of pepole talk
about potential interpretations for a query that targets a partial number,
as well as various roles for records that represent only partial E.164
numbers. I think it might be helpful in 2916bis to provide some guidelines
for these sorts of query and records if there are valid reasons for using
them.

>   case I wonder if it should be extracted and placed in another draft?

I'd be glad if any of the text in the draft can find a happy home. I'll
leave that to the discertion of the organizer of any future work on that
problem.

---

From: Kevin McCandless <[email-masked]>
Date: Tue, 19 Feb 2002 07:28:38 -0800

comments in line

-----Original Message-----
From: Patrik Fältström [mailto:[email-masked]]
Sent: Saturday, February 16, 2002 2:14 AM
To: Kevin McCandless; [email-masked]'
Subject: Re: [Enum] SIpping-e164 comments

--On 2002-02-15 11.33 -0800 Kevin McCandless <[email-masked]>
wrote:

> 4.4 Provisioning multiple NAPTR records ENUM records are not designed to
> be updated in real time, 
> and therefore ENUM is not a good mechanism for managing particular
> devices.

.The idea behind this was really about "real time" updates because of the
.caching mechanism in DNS. I didn't want to bring in a tutorial of DNS in
.this document ;-)

> Comment:  This makes an assumption oh how ENUM will be
> deployed.  There is no reason that ENUM
> could not be updated by a user in real time and the zone files updated
> more frequency then the usual 24 hours.

.It all depends on what you mean by Real Time. My definition is that if a
.user at time N updates his records, at time N+1 (seconds) a client
.somewhere should be guaranteed to have the new data.

.That can never happen with DNS.

.Nothing in DNS says the update should be "usual 24 hours". I have never
.heard anything like that. Where have you got that information from? (I am
.just curious.)

It is caching that I am refering to here for the 24 hour updates.  This can
be greatly reduced as I mentioned previously. 

> There has been discussion of zone file updates as often as every fifteen
> minutes.  Lets leave the provisioning of NAPTR 
> records to the market place to decide how real time the records can be.

.It is important to in some way mention that instant update (or some other
.word) will _not_ be possible because of how DNS works.

.Exactly how often is up to the DNS, and maybe new inventions in DNS. If you
.use dns-notify then the authoritative servers are up to date. If you use
.short TTL, then the records themselves will be updated often.

.But, the time can not be zero.

The time may never reach zero but the ENUM is no longer static and can be
updated in a timely manner and viewable for the universe.  Now, what the
acceptable delay time is is an issue for the market place and not for this
forum or draft.  That was my point.

.I appreciate suggestions on new wording.

> 5. Processing ENUM records 
> Ideally, the recommendations above for authoring NAPTR records will be
> followed to the letter; each NAPTR
>  record set will contain a SIP URI (and if possible nothing else).   
> Comment:  Once again we are making the assumption for the market place.
> ENUM is not just for SIP.  
> ENUM can be a DNS directory service.  It could easily contain, in the
> correct format, all of the usual contact information
> that is listed on a business card.

.I agree completely.

I am glad we agree on somethings ;-)

Kevin

  paf

---

From: Dave Crocker <[email-masked]>
Date: Tue, 19 Feb 2002 09:01:18 -0800

At 07:56 AM 2/19/2002 -0800, Kevin McCandless wrote:
>You all missed the point and instead nit picked the words.

On the contrary, the point was to pay attention to long-standing and 
pervasive usage in the real world.  That pervasive usage has constantly 
shown a use of the word directory to refer to a broader set of functions 
than is present in the DNS.

Most notably, the term is used to imply that a generic searching function 
is present.  The distinction between searching and mapping, as done by the 
DNS, is fundamental.  Confusing them prevents meaning dialogue about the DNS.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464