Subject: [Enum] a suggestion re: using flags to distinguish post-ENUM signaling f lows

From: "Stafford, Matthew" <[email-masked]>
Date: Sat, 4 Feb 2006 17:07:04 -0600

I strongly agree with the following statement from
draft-lendl-sip-peering-policy (lifted verbatim from section 6.2):

=>   RFC 3263 builds on that.  Quote:

=>      If a SIP proxy, redirect server, or registrar is to be contacted

=>      through the lookup of NAPTR records, there MUST be at least three

=>      records - one with a "SIP+D2T" service field, one with a "SIP+D2U"

=>      service field, and one with a "SIPS+D2T" service field.

=>

=>   This "MUST" needs to be reconsidered in this context, as it forces

=>   VSP to accept calls over unsecured SIP transports.

In fact, I would go further, as explained below.

The "u" flag defined in RFC 3761 doesn't say how to interpret the domain
name in the returned URI. In the case of a SIP URI, RFC 3263 signaling (in
particular, an additional layer of dereferencing embodied in a second NAPTR)
makes perfect sense to me in a situation where you know nothing about the
domain.

But should RFC 3263 be "universally normative" for SIP URIs? It seems to me
that the entity that provisions an ENUM NAPTR will in many cases already
know something useful about the target domain. As a simple for-instance,
suppose "transport=tcp" is included in the sip URI (as allowed by RFC 3261).
In this case, there would be an efficiency advantage if the ENUM response
could be followed directly by an SRV query.

So I have argued that there will be circumstances where the second NAPTR
doesn't buy you much. Of course there will also be circumstances where RFC
3263 signaling is warranted. I'm cross-posting to the ENUM working group for
the following reason: flags could be used to distinguish the two kinds of
signaling flows. Say a "g" flag (mnemonic for Gateway) that tells the
recipient of the ENUM NAPTR that there is an SRV record (w/domain in the
ENUM NAPTR as key) pointing to the gateway.

I think the example just described is worthwhile. Moreover, I think the
Lendl draft suggests that there are additional scenarios that might be
facilitated by via new ENUM flags. I'm not clear whether this sort of thing
would end up in "3761bis", so to speak, or in another document. Either way,
I'd like to float the idea and see if there's interest.

Best,

Matt Stafford

Vice Chair of Addressing Task Force, GSM North America

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

Matthew Stafford 

Principal Member of Technical Staff 

Cingular Wireless, Inc. 

9505 Arboretum Blvd Austin TX 78759 

[email-masked]

Voice : +1(512)372-5623 

Fax : +1(512)372-5891 

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

This email and any files transmitted with it are property of Cingular
Wireless, are confidential, and are intended solely for the use of the
individual or entity to whom this email is addressed. If you are not one of
the named recipient(s) or otherwise have reason to believe that you have
received this message in error, please notify the sender at 512/372-5623 and
delete this message immediately from your computer. Any other use,
retention, dissemination, forwarding, printing or copying of this email is
strictly prohibited.

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

---

From: lconroy <[email-masked]>
Date: Sun, 5 Feb 2006 12:32:25 +0000

Hi Matt, Otmar, folks,
  This is an interesting posting for several reasons.
The first is the process issue - what group (if any) coordinates
between the different DDDS applications and their uses; this topic
covers D2x NAPTRs (natural territory for SIP/SIPPING), E2U NAPTRs
(natural territory for ENUM), and their use for peering (welcome,
SPEERMINT). If it's useful to add clarifications for DDDS itself
then who or what does that?

To the substance of the post:
I'm sure Otmar was not suggesting that D2x NAPTRs MUST be available
for all domains before a SIP exchange can occur. For Service Providers
it's fine, but...
There are a number of individuals who do not need or use an intermediary
provider for their SIP exchanges, so adding D2U NAPTRs is "overkill"
I, for example, do not have D2x NAPTRs in my zone; there's no target
domain redirection, so the NAPTRs would not be useful. I only have one
SIP proxy so one could even argue that SRVs are excessive - it's not
exactly a load balanced system.

However, for Service Providers, we enter new territories. Do you know
that your customers will want *every* insecure SIP invite to fail (i.e.
those customers have said to you explicitly that a _sip transaction is
not acceptable)? Is is a regulatory requirement that you at least tell
the caller that this call has failed though a terminating service like
UCB, rather than not even accept the attempt?

Lastly, adding a new flag for ENUM *in general* is going to cause some
problems for application developers like me - ALL of my ENUM clients
will have to support this, or else these will be non-compliant to any
3761bis. It seems that your proposal is purely for Carrier/ 
Infrastructure/
Private ENUM; in this case, changing 3761 has unintended consequences  
for
Public/User ENUM applications.

It appears that the proposed 'g' flag is appropriate only for SIP use  
within
Carrier ENUM, so one could WELL argue that this is an issue for the  
SIP URI
- I don't see how it can be used for other Enumservices (like  
email:mailto,
for example). Perhaps adding a SIP parameter (akin to ;user=phone)  
would be
more appropriate, or adding a new Enumservice to run alongside the  
existing
SIP one (i.e. to develop a new Enumservice definition RFC to specify  
a SIP
Gateway service)?

all the best,
   Lawrence

On 4 Feb 2006, at 23:07, Stafford, Matthew wrote:
> I strongly agree with the following statement from draft-lendl-sip- 
> peering-policy (lifted verbatim from section 6.2):
>
> The "u" flag defined in RFC 3761 doesn't say how to interpret the  
> domain name in the returned URI. In the case of a SIP URI, RFC 3263  
> signaling (in particular, an additional layer of dereferencing  
> embodied in a second NAPTR) makes perfect sense to me in a  
> situation where you know nothing about the domain.
>
> But should RFC 3263 be "universally normative" for SIP URIs? It  
> seems to me that the entity that provisions an ENUM NAPTR will in  
> many cases already know something useful about the target domain.  
> As a simple for-instance, suppose "transport=tcp" is included in  
> the sip URI (as allowed by RFC 3261). In this case, there would be  
> an efficiency advantage if the ENUM response could be followed  
> directly by an SRV query.
>
> So I have argued that there will be circumstances where the second  
> NAPTR doesn't buy you much. Of course there will also be  
> circumstances where RFC 3263 signaling is warranted. I'm cross- 
> posting to the ENUM working group for the following reason: flags  
> could be used to distinguish the two kinds of signaling flows. Say  
> a "g" flag (mnemonic for Gateway) that tells the recipient of the  
> ENUM NAPTR that there is an SRV record (w/domain in the ENUM NAPTR  
> as key) pointing to the gateway.
>
> I think the example just described is worthwhile. Moreover, I think  
> the Lendl draft suggests that there are additional scenarios that  
> might be facilitated by via new ENUM flags. I'm not clear whether  
> this sort of thing would end up in "3761bis", so to speak, or in  
> another document. Either way, I'd like to float the idea and see if  
> there's interest.
>
> Best,
>
> Matt Stafford
>

---

From: Richard Shockey <[email-masked]>
Date: Sun, 05 Feb 2006 11:25:44 -0500

lconroy wrote:
> 3761bis. It seems that your proposal is purely for Carrier/Infrastructure/
> Private ENUM; in this case, changing 3761 has unintended consequences for
> Carrier ENUM, so one could WELL argue that this is an issue for the SIP URI
> - I don't see how it can be used for other Enumservices (like email:mailto,
> for example). Perhaps adding a SIP parameter (akin to ;user=phone) would be
> more appropriate, or adding a new Enumservice to run alongside the existing
> SIP one (i.e. to develop a new Enumservice definition RFC to specify a SIP
> Gateway service)?

Larry I agree with your view.

If there were a general requirement for this form of tag its better done 
as an extension to a Enumservice field.

Those fields are quite extensible you can add as many sub-types as you 
want so long as they are properly defined in a RFC.

E2U+sip:gw

strikes me as the right way to do this.

The purpose of the flag field is not to hint at describe or the nature 
of endpoint after the rewrite but to define how to process the reg exp 
under certain defined conditions. This went to our past issue of how to 
use the replacement field, should someone find a way to use it properly.

BTW we have realized we have a bit of a mess with the Enumservice 
registry in general and we will shortly have a WG draft addressing the 
problem

>> embodied in a second NAPTR) makes perfect sense to me in a situation 
>> where you know nothing about the domain.
>>
>> But should RFC 3263 be "universally normative" for SIP URIs? It seems 
>> to me that the entity that provisions an ENUM NAPTR will in many cases 
>> already know something useful about the target domain. As a simple 
>> for-instance, suppose "transport=tcp" is included in the sip URI (as 
>> allowed by RFC 3261). In this case, there would be an efficiency 
>> advantage if the ENUM response could be followed directly by an SRV 
>> query.
>>
>> NAPTR doesn't buy you much. Of course there will also be circumstances 
>> where RFC 3263 signaling is warranted. I'm cross-posting to the ENUM 
>> working group for the following reason: flags could be used to 
>> distinguish the two kinds of signaling flows. Say a "g" flag (mnemonic 
>> for Gateway) that tells the recipient of the ENUM NAPTR that there is 
>> an SRV record (w/domain in the ENUM NAPTR as key) pointing to the 
>> gateway.
>>
>> might be facilitated by via new ENUM flags. I'm not clear whether this 
>> sort of thing would end up in "3761bis", so to speak, or in another 
>> document. Either way, I'd like to float the idea and see if there's 
>> interest.
>>
>> Best,
>>
>> Matt Stafford
>>

-- 

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Tony Rutkowski <[email-masked]>
Date: Sun, 05 Feb 2006 11:41:58 -0500

Hi Lawrence,

>between the different DDDS applications and their uses; this topic
...
>3761bis. It seems that your proposal is purely for Carrier/ Infrastructure/
>for Public/User ENUM applications.

These are great understatements.  The use of
E.164 identifiers, internationally and
domestically, is subject to more statutory,
regulatory, national security, and industry
practice requirements than any identifier
space in existence - not to mention well
established institutional jurisdiction.

The following list is a current tabulation
of E.164 resolver-directory capability
requirements, parsed into three categories,
currently in play in various industry NGN
forums.  The recently enacted EC Data
Retention Directive, and the U.S. Prevent
Cyberstalking law, add further complexity
to the mix. ;-)

best,
--tony

>basic resolver capability
>
>supplementary capability
>         Number Portability
>         Priority Access
>         Roaming
>         Quality of Service
>         Directory Assistance
>         CallerID
>         Disability Assistance
>         Language preference
>         Personal emergency (E112/911)
>         Public emergency alerts
>         Law enforcement assistance
>         DoNotCall
>         Payment Methods
>         Intercarrier Compensation
>         Profile Management
>         Presence
>         Availability
>         Location
>         Push Management
>         Digital Rights Management
>         Device Management
>         Authentication Credentials
>         Information verification level
>
>protocol feature
>         Authentication
>         Auditing
>         Multiple Syntax Support
>         Mutiple Language Support
>         Extensibility and Localisation Mechanisms

---

From: "Henry Sinnreich" <[email-masked]>
Date: Mon, 6 Feb 2006 09:32:51 -0600

The information provided by Tony Rutkowski are a welcome reminder that phone
numbers are not only a crippled addressing system but a huge trap with
legacy telecom regulatory issues and big legal staffing costs.

Let's use the Internet and the DNS for what they were designed: URIs

The other alternative are the name spaces in P2P systems.

Sincere apology to all my friends working on ENUM: 
Keep it within strict bounds, simple and use with caution.

Thanks, Henry

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Tony Rutkowski
Sent: Sunday, February 05, 2006 10:42 AM
To: lconroy; Stafford, Matthew; Otmar Lendl
Cc: [email-masked]; [email-masked]
Subject: [Speermint] Re: [Enum] a suggestion re: using flags to distinguish
post-ENUM signaling f lows

Hi Lawrence,

...

best,
--tony

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

---

From: Tony Rutkowski <[email-masked]>
Date: Mon, 06 Feb 2006 13:53:58 -0500

Henry,

The primary purpose of test implementations of new
technology as public infrastructure is to establish
test suites that provide real-world performance data
under various use stress levels and failure scenarios.
For ENUM, this would include alternative architectures.

Has anyone developed ENUM test suites or data?  ETSI
did some plug-tests some time ago, but the focus
seemed primarily on demonstrating interoperability.

--tony

---

From: Jim Reid <[email-masked]>
Date: Mon, 6 Feb 2006 19:11:12 +0000

On Feb 6, 2006, at 18:53, Tony Rutkowski wrote:

> Has anyone developed ENUM test suites or data?

Yes. Lawrence Conroy and I came up with some for the ETSI ENUM  
Plugtest last summer. The infrastructure to support that -- name  
servers and SIP server connected to a PBX -- was torn down after the  
event. It all ran on borrowed equipment. I was also a little bit  
naughty because the testbed used some UK drama numbers (equivalents  
of 555 numbers in the USA) that shouldn't have been delegated, let  
alone used for these tests.

There's an action on me from the RIPE ENUM WG to try and get a semi- 
permanent testbed established. The first thing is to get the  
requirements documented. Contributions welcomed. Funding is even more  
welcome. :-)

> ETSI did some plug-tests some time ago, but the focus

Not really. The prime focus of those tests was to find out how  
implementations behaved under wierd or unusual inputs: lame  
delegations, malformed NAPTR records, tel: URIs that pointed at bogus  
or illegal numbers, truncated responses, etc, etc.

---

From: Adrian Georgescu <[email-masked]>
Date: Mon, 6 Feb 2006 20:18:02 +0100

Hi Tony,

The ENUM plugtest  provided exactly the scenarios where things could  
go wrong and interested people learned how to deal with those  
situations. The test scenarios were quire comprehensive, thanks to  
Jim Reid and Lawrence Conroy excellent program.

See the report from:
http://www.etsi.org/plugtests/History/2005ENUM.htm

Regards,
Adrian

---

From: lconroy <[email-masked]>
Date: Tue, 7 Feb 2006 01:32:50 +0000

Hi Tony, Jim, folks,
  as the other half of that particular double act, I can chime in here.

Tony - you should know better :). There was a VSGN chap at the plugtest
and he therefore has the final report, in which the tests we ran are  
listed.

I should point out that these broke everyone's implementations, but the
clueful fixed theirs during the tests. We didn't go to the South of  
France
to sun ourselves - we were stuck in a concrete dungeon, as Otmar can  
attest.
As with all real plugtests(tm), whilst Interoperation is important,  
getting
it right is better.

There was a similar issue with the first ROHC tests - everyone had  
read the
spec in the same wrong way (bit/byte order issue, as I recall), and they
all interoperated, but were all wrong. That was fixed, IIRC, during the
frantic last day of that test.

all the best,
   Lawrence

On 6 Feb 2006, at 19:11, Jim Reid wrote:
> servers and SIP server connected to a PBX -- was torn down after  
> the event. It all ran on borrowed equipment. I was also a little  
> bit naughty because the testbed used some UK drama numbers  
> (equivalents of 555 numbers in the USA) that shouldn't have been  
> delegated, let alone used for these tests.
>
> requirements documented. Contributions welcomed. Funding is even  
> more welcome. :-)
>
> delegations, malformed NAPTR records, tel: URIs that pointed at  
> bogus or illegal numbers, truncated responses, etc, etc.
>