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

Lawrence- Thanks for your comments... good discussion points here! Inline.

Best,
Matt

-----Original Message-----
From: lconroy [mailto:lconroy@insensate.co.uk] 
Sent: Sunday, February 05, 2006 6:32 AM
To: Stafford, Matthew; Otmar Lendl
Cc: speermint@ietf.org; enum@ietf.org
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

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?

==> Agree that this is not a trivial question.

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.

==> The way I read (this portion of) the Lendl draft is as follows (correct
==> me if I misinterpret):
==> *If* you want to dereference SIP URIs using D2x NAPTRs *but* you will
==> not accept SIP signaling over UDP, then RFC 3263 is telling you to do
==> something that doesn't make much sense (namely, post a D2U NAPTR
==> anyway).

==> My reading of RFC 3263 doesn't seem to say you MUST dereference SIP URIs
==> via D2x NAPTRs. But AFAICT, nothing systematic is specified re: other
==> signaling flows for resolving SIP URIs. BTW, strongly agree with your
==> suggestion that other signaling flows make sense in many cases.

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?

==> Another interesting point.

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.

==> I take your point regarding the headaches w/changes to clients.
==> However, I'm not sure I agree that this is limited to carrier/infra-
==> ENUM, at least if we think of that in terms of traditional telcos/
==> cellcos. For example, does this discussion really bear no relevance
==> to enterprise applications (e.g., I want to call into my company's
==> IP PBX while I'm on the road?) 

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)?

==> That would have a similar effect to the flag proposal, in the sense
==> that the contents of the ENUM NAPTR offer guidance on what to do next
==> (which is really what I'm after)

==> For the sake of discussion, here's a similar example using the
recently-==> standardized Enumservice mms:mailto... an 'm' flag indicating
that the ==> NAPTR recipient should now look for an MX Resource Record.

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):
>
> =>   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