Subject: RE: [Enum] sipping-e164 comments

From: "Stastny, Richard" <[email-masked]>
Date: Thu, 14 Feb 2002 17:31:57 +0100

Hi,

first I would like to congratulate the authors for this execellent paper on
sip AND enum, and here I agree fully with Lawrence, that we need such a
paper.

And of course, its too much concentrated on telephony and SIP issues, as the
title suggests.
Here I also agree with Lawrence with his comments to:
> *	A general sip service should be used, not separate entries 
> for different
> 	media types ...
IMHO opinion it should be the users choice, if he wants to have all services
behind SIP or if he wants separate services (providers). Guidance should be
given for both cases.

I also see SG16 jumping up and down, but that may be resolved easily:
First, many statements regarding SIP are also valid for h323,
Second, its up to SG16 to write a similar paper, or even better, to upgrade
this paper to a generic paper dealing with both (this would be a nice job
for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever)

Taking the volume of the paper, there will be a lot of discussions
necessary, on the first reading I have the follwing main issues:

1. Policy:
ENUM can only operate on full numbers, no private dialling plans ...
I fully understand (and this is also (now) the understanding in SG2 and
ETSI), that ENUM according to RFC2916 (currently) only is e164.arpa and full
E.164 numbers. In ETSI we start to call this public ENUM.

But nobody prevents my company to implement a private ENUM within our
Intranet. I can also imagine a client (Outlook?, Messenger?) to recognize a
prefix. So if I enter 12345, I query 5.4.3.2.1.telekom.inside, if I enter 0
00441794833666, I query ...e164.arpa and get Lawrence (if he is not in a
blue monday loop ;-).

Also nobody prevents my company to implement within our network an IN-like
ENUM-like service, which is totally separate from the public ENUM (called
operator ENUM), eventually running in an extranet with other operators.

Although both implementations are not in scope of RFC2916, most of the
applications will be the same, so some standardisation or guidance may be
needed.

2. Private dialing plans
Back to private dialling (and numbering) plans. Many private numbering plans
can be reached from the outside (e.g. DDI, especially in Europe). This leads
on one hand to the introduction of a Tier 3, where Tier 2 points to the NS
of a company, hosting the NAPTR records of the private extensions and are
also administrated by the company. Since the company may have her private
ENUM (see above), a link to the private ENUM may be nice (eventually hiding
some of the internal records?).

3.Incomplete E.164 numbers
In addition to the comments from Lawrence, I have a serious problem with
section 5.1:
"Before a starting string (the telephone number to be reversed) can be
   constructed in the manner described in RFC2916, the originator of the
   query SHOULD make sure that the telephone number it intends to
   resolve is a complete E.164 address.  Network elements SHOULD have
   some means of determining whether an address is complete in the E.164
   system, especially when interworking with networks that use overlap
   PSTN signaling."
There is no way currently to make sure that the telephone number is a
complete E.164 number, especially on a global scale with a lot of countries
having open numbering plans and no fixed number length. Also networks may
have no way of determining whether an address is complete. 

The only way I see is, that the client returns a "incomplete number
indication", if no NAPTR records are found in a query of an ENUM domain. The
example Lawrence brought up is common with most companies in Germany and
Austria. I like the proposal he made with the NAPTR record to the pilot
number in Tier 1, but this raises a whole new issue in the administration
theater. I would prefer this on Tier 2.

4. "Tel" URLs

I always had some problems with the "tel" URLs. In my understanding up to
this point I could use "tel" URLs only if I had an operator providing a
gateway to the GSTN. To use the tel: to make another lookup to ENUM for that
number in ENUM was new for me. (Remark: I fully agree, that ENUM is not a
system to change your forwardings every hour). So the "tel" URL is used in
this case to point from your secondary number to your primary number, e.g.
you have 2 E.164 numbers, but you want to put your NAPTRs only in the
primary number, and in the other you have only permanetely the "tel" URL to
the primary.

When I talked with Patrik last week on this issue, he confirmed, that this
can be done (should be done?) also with CNAME Records.

If this is the case, than I would propose only to use CNAME for this
purpose. I also propose the following for "tel:"
If a "tel:" is selected as the outcome of a query by the client on what
preference ever, NO additonal ENUM query SHALL be done, the "Tel: Number"
SHALL be used to set up a connection to this E.164 number, where ever it is
(contact address in SIP terminology). Do not forget, a E.164 number may also
terminate on IP (especially with h.323 ;-).

Having said this, I will start reading the draft over again ;-)

best regards

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: Lawrence Conroy [mailto:[email-masked]]
> Sent: Wednesday, February 13, 2002 9:15 PM
> To: Jon; Rudi
> Cc: [email-masked]
> Subject: [Enum] sipping-e164 comments
> 
> 
> 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
> 

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

---

From: Richard Shockey <[email-masked]>
Date: Sun, 17 Feb 2002 11:07:59 -0500

>for TIPHON, hehe, coming up with a draft-ietf-meta-e164-whatever)

Personally I totally agree ... I think we'd welcome any document that looks 
at the issues surrounding ENUM and H.323 from SG16, TIPHON or any other 
source especially in light of SG16's work on the URL

http://www.ietf.org/internet-drafts/draft-levin-iptel-h323-url-scheme-04.txt

>operator ENUM), eventually running in an extranet with other operators.

Correct ...

>theater. I would prefer this on Tier 2.

This is a good point for many reasons.  One additonal note that we all 
should keep in mind is that since 2916 is a global service using DNS all 
records will be esposed to the global internet ..therefore it is worth 
noting that only the minimal set of records necessary to set up a call 
should be exposed in the NAPTR records.

>primary number, and in the other you have only permanetely the "tel" URL to

I dont like this either ... using tel URL's for call forwarding exposed 
personal preferences to the global internet ant those functions should be 
executed by either the SIP proxy.

Using Tel URL's for gateway location is also a bad idea since there may be 
N companies offering gateway services and that could increase the number of 
NAPTR records by an order of magnitude and create complexities for Client 
UA's on how to select a GW, not to mention pushing the DNS query into TCP.

Richard Shockey, Senior Manager, Strategic Technology Initiatives
NeuStar Inc.
45980 Center Oak Plaza   Bldg 8     Sterling, VA  20166
1120 Vermont Ave NW Suite 400 Washington DC 20005
Voice +1 571.434.5651 Cell : +1 314.503.0640,  Fax: +1 815.333.1237
<mailto: [email-masked]> or
<mailto: [email-masked]>
<http://www.neustar.biz>
<http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<