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

["Stafford, Matthew" <[e-mail]>]

Richard- I'm interested to see what will happen with ENUMservices; thanks
for the info. The only problem I see is that sometimes (e.g., the
recently-standardized E2U+mms:mailto) the subtype is already used to specify
a URI scheme. So, for instance, that would not allow use of the subtype to
indicate that the recipient of the ENUM NAPTR should look for an MX RR as a
next step.

Best,
Matt

-----Original Message-----
From: Richard Shockey [mailto:[e-mail]] 
Sent: Sunday, February 05, 2006 10:26 AM
To: lconroy
Cc: Stafford, Matthew; Otmar Lendl; [e-mail]; [e-mail]
Subject: Re: [Enum] a suggestion re: using flags to distinguish post-ENUM
signaling f lows

lconroy wrote:
> 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.
> 
>
> 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)?


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




> 
> 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
> 
> _______________________________________________
> enum mailing list
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/enum
> 


-- 


 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
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 [phone]
PSTN Office +1 571.434.5651 PSTN Mobile [phone]
Fax: [phone]
<mailto:richard(at)shockey.us> or
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

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