Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration

From: "David Hancock" <[email-masked]>
Date: Tue, 20 Oct 2009 12:28:06 -0600

I would like to add my voice to the chorus supporting the domain registration draft. I also support Cullen's "AD sponsored" option to progress it to RFC status. 

The lack of a common standard in this area is costing operators that deploy SIP-PBXs time and money - time in testing each new SIP-PBX version to identify interworking issues, and money in deploying fix-up boxes to make things work in the field. Domain registration is a relatively small increment from what most SIP-PBXs do today, so I expect (hope) it will quickly gain wide adoption. If we abandon the domain-registration approach and go back to square one, then I'm afraid it will unnecessarily delay adoption of a standard in this area. First, there's the risk that it'll take a long time to agree on and document a standard way of doing this. Second, there's the risk that the eventual solution will be sufficiently divergent from what is supported in the (growing) installed base that adoption will be slow. Meanwhile, operators will have to continue bearing the cost of deploying SIP-PBXs in the current "non standard" environment.

David

________________________________________
From: "Brian Lindsay" <blindsay at nortel.com>
To: "Richard Shockey" <richard at shockey.us>, "Hadriel Kaplan" <HKaplan at acmepacket.com>, <dispatch at ietf.org>
Date: Mon, 19 Oct 2009 12:43:40 -0400
Hi,

   Would like to chime in and express support for
standardization/formalization of a REGISTER-based solution to this
problem, to address the SIP PBX problem space in a timely fashion by
building on currently deployed approaches, rather than inventing
something new. The draft should be DISPATCH'ed in a manner to best
facilitate that.

  Thanks.

-----Original Message-----
From: dispatch-bounces at ietf.org [mailto:dispatch-bounces at ietf.org] On
Behalf Of Richard Shockey
Sent: Monday, October 19, 2009 12:34 PM
To: 'Paul Kyzivat'; 'Hadriel Kaplan'
Cc: dispatch at ietf.org
Subject: Re:
[dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registrati
on

Paul please remember ..we are trying to fix something that is in the
field right now and widely deployed that is causing interoperability
problems.  

There are probably better ways to approach the bindings between PBX's
and SSP's and the larger issues of provisioning but that is not what the
draft is trying to accomplish and there is a substantial community here
that is trying to do the right thing. 

>  -----Original Message-----
>  From: dispatch-bounces at ietf.org [mailto:dispatch-bounces at ietf.org] On

> Behalf Of Paul Kyzivat
>  Sent: Monday, October 19, 2009 10:01 AM
>  To: Hadriel Kaplan
>  Cc: dispatch at ietf.org
>  Subject: Re: [dispatch] DomainRegistrationDraftdraft-kaplan-dispatch-
>  domain-registration
>  
>  I continue to sit on the fence about this one:
>  
>  I understand and agree with what Hadriel is saying about this 
> behavior  falling within the latitude given to proxies on how they
route things.
>  Thus I think it is *conforming* for SIPForum or some other group to  
> make  an agreement about a convention that does things this way.
>  
>  But it is a hack. It is not a *clean* way to do it. I expect more 
> from  IETF approved documents. Maybe we are to the point with SIP 
> where  there  is too much inertia to afford "clean", and that hacks 
> are now the way  forward. But if so, that is at least sad.
>  
>       Thanks,
>       Paul
>  
>  Hadriel Kaplan wrote:
>  >> -----Original Message-----
>  >> From: Dean Willis [mailto:dean.willis at softarmor.com]
>  >> Sent: Saturday, October 17, 2009 12:08 PM  >>  >> I think you've 
> got a hold of an absolutely critical, core piece of  SIP  >> 
> functionality. You're either revising or replacing one of the  >> 
> fundamental SIP methods, dating to before RFC 2543. That says  SIPCORE

> to  >> me.
>  >
>  > We're not updating 3261, 3262, or 3263.  We're not revising or  
> replacing REGISTER.  We're extending, using an options-tag to indicate

> it.  Otherwise what you're saying is every extension that needs an  
> options-tag for any request Method name documented in 3261 needs to be

> in sipcore - including any applying to INVITE.  I don't think you want

> that.
>  >
>  >
>  >> I believe that the same objections that might prevent you from  
> making a  >> "standards track" solution would also keep you from 
> making an  >> informational solution. You might not notice, but we've 
> held even  the  >> info track documents to a high level of review.
>  >
>  > There would be nothing to discuss.  It wouldn't require an  
> informational draft to even be published.  There's enough wiggle room

> in 3261 routing procedures and Registration procedures to avoid any  
> need - the draft would effectively be an "FYI".  Effectively it would

> be something along the lines of the older draft-kaplan-dispatch-sip-  
> implicit-registrations-00.
>  >
>  > We would register an AoR in a REGISTER transaction - for requests 
> to  that specific AoR things would follow 3261 as is.  For all 
> intents,  it's a fake AoR.  Internally, in the Registrar DB, that 
> AoR's  reachability information (contact/path) would just not-so-  
> coincidentally happen to be used for Route header fields for that  
> domain.  Since that routing portion is effectively up to local policy

> (ie, implementations), it would comply with 3261 as well.  Nothing in
>  3261 demands that local policy routing results follow any prescribed

> data, so we'd just document that it happens to be data populated from

> that AoR's reachability data.
>  >
>  > There isn't even a need for a new header.  We'd just try for one to

> help troubleshooting and avoiding erroneous manual configuration.
>  >
>  > -hadriel