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

From: "DOLLY, MARTIN C, ATTLABS" <[email-masked]>
Date: Mon, 19 Oct 2009 12:39:02 -0400

This the right solution(period) that will result in more IP deployments .

This IETF debate only emphasize its place?

----- Original Message -----
From: [email-masked] <[email-masked]>
To: 'Paul Kyzivat' <[email-masked]>; 'Hadriel Kaplan' <[email-masked]>
Cc: [email-masked] <[email-masked]>
Sent: Mon Oct 19 12:33:36 2009
Subject: Re: [dispatch]DomainRegistrationDraftdraft-kaplan-dispatch-domain-registration

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: [email-masked] [mailto:[email-masked]] On
>  Behalf Of Paul Kyzivat
>  Sent: Monday, October 19, 2009 10:01 AM
>  To: Hadriel Kaplan
>  Cc: [email-masked]
>  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:[email-masked]]
>  >> 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
>  > _______________________________________________
>  > dispatch mailing list
>  > [email-masked]
>  > https://www.ietf.org/mailman/listinfo/dispatch
>  >
>  _______________________________________________
>  dispatch mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/dispatch

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