Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch-domain-registration

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Oct 2009 13:06:54 -0600

The SIP Forum has recently sent us the draft

http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt

This draft is pretty close to what several vendors are doing in some  
existing deployments. In my AD roll I have been trying to figure out  
how to progress this draft. Some people have asked me to AD sponsor  
it. I see the ways this draft could more forward are:

1) AD sponsor. I'm willing to do this if there is consensus in  
dispatch that this is a good way to move forward.

2) Use the dispatch WG to spin up a new WG to deal with this.

3) remove the options tag and go to the independent stream

I expect that with both #1 and #2, the document will get roughly the  
same review and #1 is less work for me and the IESG. What's your  
thoughts on how we should move this forward?

Thanks, Cullen <RAI AD>

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 13 Oct 2009 15:31:58 -0400

+1 on #1 please. 

This is important to existing deployments in the field. 

The function of this draft is to enhance interoperability and remove any
ambiguities about what this procedure is. IMHO it is essentially non
controversial. 

>  -----Original Message-----
>  From: [email-masked] [mailto:[email-masked]] On
>  Behalf Of Cullen Jennings
>  Sent: Tuesday, October 13, 2009 3:07 PM
>  To: [email-masked]
>  Subject: [dispatch] Domain Registration Draft draft-kaplan-dispatch-
>  domain-registration
>  
>  
>  _______________________________________________
>  dispatch mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/dispatch

---

From: "Spencer Dawkins" <[email-masked]>
Date: Tue, 13 Oct 2009 14:37:42 -0500

Hi, Cullen,

Well, obviously, I hope that "AD sponsored" is the right answer - we're 
hoping that this is a very minor amount of work, but it's not something that 
seems appropriate to specify in a SIP Forum specification, so it needs to be 
reviewed in the IETF.

"Removing the option tag" - my understanding here is that the reason for 
using a SIP option tag is so that the decision to perform domain 
registration is part of normal SIP capability exchange, and that if we don't 
use a SIP option tag, we're going to end up with some SIP header field that 
advertises a capability and confirms whether or not it was used - so it 
should have been a SIP option tag in the first place.

Other thoughts?

Spencer

> existing deployments. In my AD roll I have been trying to figure out  how 
> to progress this draft. Some people have asked me to AD sponsor  it. I see 
> the ways this draft could more forward are:
>
> 1) AD sponsor. I'm willing to do this if there is consensus in  dispatch 
> that this is a good way to move forward.
>
> I expect that with both #1 and #2, the document will get roughly the  same 
> review and #1 is less work for me and the IESG. What's your  thoughts on 
> how we should move this forward?
>
> Thanks, Cullen <RAI AD>

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 14 Oct 2009 09:13:32 +0200

I would very much like to see this draft progress quickly, and if #1 is the best way to do this, then let's do it.

Concerning the option tag, normally a SIP service provider would be provisioned to support a SIP-PBX, so it would know from provisioning whether a REGISTER request is for domain registration or normal registration. However, we all know that mistakes in provisioning are often made, and the option tag provides some protection against this. So my preference would be to proceed with the option tag.

John 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 13 October 2009 20:07
> To: [email-masked]
> Subject: [dispatch] Domain Registration Draft 
> draft-kaplan-dispatch-domain-registration
> 
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 14 Oct 2009 13:41:52 -0400

I'm for Option 1 (AD sponsor it) as well. :)

-hadriel

> Behalf Of Spencer Dawkins
> Sent: Tuesday, October 13, 2009 3:38 PM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [dispatch] Domain Registration Draftdraft-kaplan-dispatch-
> domain-registration
> 
> Hi, Cullen,
> 
> how
> same

---

From: Dean Willis <[email-masked]>
Date: Wed, 14 Oct 2009 14:36:04 -0500

Cullen Jennings wrote:
> to progress this draft. Some people have asked me to AD sponsor it. I
> see the ways this draft could more forward are:
> 

I prefer option 2, given that the WG would take the requirements and not
the solution mechanism from SIP Forum.

This is our one chance to fix REGISTER, and at the same time fix the
request-URI/parameter delivery problem. Let's not waste it on an
incomplete solution.

I think that we can reasonably deliver on the domain-registration
requirement and at the same time solve (for devices that use the new
technique) the problem of URI and parameter delivery during SIP routing.
The "RUPDATE" approach I recently circulated (and that I would like to
call ROUTEUP instead of RUPDATE) appears to achieve this goal. yeah, I
should send a draft.

Let's not be bashful. What we're talking about here is a replacement for
the now-known-to-be-broken SIP REGISTER mechanism (and the
registered-contact routing mechanism that depends on it). While not all
that hard, getting it right is still beyond the scope of an AD-sponsored
draft.

--
dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 14 Oct 2009 14:37:33 -0500

> ambiguities about what this procedure is. IMHO it is essentially non

Non-controversial? It's a clever hack built on a broken mechanism. It
ought to be very controversial.

--
Dean

---

From: "Bharrat, Shaun" <[email-masked]>
Date: Wed, 14 Oct 2009 20:59:55 -0400

All:

We also would like to see a timely specification and
would support either #1 or #3. The solution at hand
is essentially what we see in the wild and though not
the complete rework of register that some hope for,
it is a workable solution.

Cheers,
Shaun

-----Original Message-----
From: [email-masked] on behalf of Elwell, John
Sent: Wed 10/14/2009 3:13 AM
To: Cullen Jennings; [email-masked]
Subject: Re: [dispatch] Domain RegistrationDraft	draft-kaplan-dispatch-domain-registration

John

---

From: "Scott Lawrence" <[email-masked]>
Date: Wed, 14 Oct 2009 23:01:43 -0400

> that hard, getting it right is still beyond the scope of an AD-sponsored

REGISTER is already abused more than enough.  

I agree with Dean that this certainly should be controversial, and that
a fast-track approval would not be appropriate.

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 15 Oct 2009 08:22:09 +0200

I think one step at the time. Hadriel's draft fixes the urgent problem of domain registration.

John

> [mailto:[email-masked]] On Behalf Of Dean Willis
> Sent: 14 October 2009 20:36
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [dispatch] Domain Registration Draft

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Oct 2009 09:49:20 -0500

On Oct 14, 2009, at 10:01 PM, Scott Lawrence wrote:

[...]

> a fast-track approval would not be appropriate.

+1

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Thu, 15 Oct 2009 10:15:23 -0500

I support Option 1 as well.  The draft is moving us in the right
direction and should not be delayed to cover additional concerns.

David

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of ext Hadriel Kaplan
Sent: Wednesday, October 14, 2009 1:42 PM
To: Spencer Dawkins; Cullen Jennings
Cc: [email-masked]
Subject: Re: [dispatch] DomainRegistration
Draftdraft-kaplan-dispatch-domain-registration

-hadriel

> hoping that this is a very minor amount of work, but it's not
something
> that
> seems appropriate to specify in a SIP Forum specification, so it needs
to
> be
> see
dispatch

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 11:23:23 -0400

This is not our "one chance to fix REGISTER".  This draft isn't trying to "fix REGISTER".  What's broken about REGISTER that needs a fixin'?

-hadriel

> Behalf Of Dean Willis
> Sent: Wednesday, October 14, 2009 3:36 PM
> To: Cullen Jennings
> Cc: [email-masked]
> Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-dispatch-
> domain-registration
> 
> Cullen Jennings wrote:
> >

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 11:57:39 -0400

Scott/Ben,
Can you describe what is controversial about the draft for you personally?
Is it the idea of using a REGISTER request for something other than just a single AoR?
Is it that a REGISTER updates a different logical local database on the Registrar?
Is it the idea of allocating an option-tag?

-hadriel

> Behalf Of Scott Lawrence
> Sent: Wednesday, October 14, 2009 11:02 PM
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 15 Oct 2009 12:11:25 -0400

John is perfectly correct here. 

We are trying, in a responsible manner, to fix what is clearly and widely
deployed in the field right now.

>  Behalf Of Elwell, John
>  Sent: Thursday, October 15, 2009 2:22 AM
>  To: Dean Willis; Cullen Jennings
>  Cc: [email-masked]
>  Subject: Re: [dispatch] Domain Registration Draft draft-kaplan-
>  dispatch-domain-registration
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Oct 2009 15:18:13 -0500

> Is it the idea of allocating an option-tag?

At a high level, it is that you propose using REGISTER as to carry a  
very specific piece of otherwise provisionable data. This piece seems  
more "hard-state" rather than "soft-state" It is not obvious to me  
that REGISTER is the right way to do this. Additionally, I am  
concerned about applying _any_ new semantics to REGISTER, as I think  
the method is fundamentally broken.

So, I think there is considerable room for discussion on the following  
(I'll make my own list, thank you :-)  ):

1) Is SIP the right protocol for this?
2) Is REGISTER the right method for this? Maybe PUBLISH would be  
better? Isn't this sort of like the bulk registration mechanism that  
was _always_ controversial whenever it came up?
3) Are we building specific applications (i.e. a way to provision  
virtual domains for IP-PBXs) vs providing flexible primitives (a way  
to dynamically self-provision hard-state routing info)
4) Are we getting the security aspects right?

Don't get me wrong--I am not saying that the draft necessarily does  
these things wrong--I am saying that I expect there to be a variety of  
opinions on the matter--thus Richard's assertion that they are "non- 
controversial" seems off base. If we are going to _standardize_ such a  
mechanism, I think it deserves the same level of discussion as other  
things we put through the DISPATCH process.

---

From: Dean Willis <[email-masked]>
Date: Thu, 15 Oct 2009 16:45:28 -0500

On Oct 15, 2009, at 10:23 AM, Hadriel Kaplan wrote:

>
> This is not our "one chance to fix REGISTER".  This draft isn't  
> trying to "fix REGISTER".  What's broken about REGISTER that needs a  
> fixin'?

That is a deeply disingenuous response, as you've been there for most  
of the last several years debate on contact-routing, URI passing, and  
parameter passing.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 17:53:08 -0400

Well I really didn't mean for it to be disingenuous. (honest)
The three things you mentioned, for example, do not mean to me the REGISTER transaction mechanism is broken whatsoever.  They have to do with how to route to the entity that Registered, which is after the fact.  In the Domain Registration mechanism we side-step that whole issue, since we're not replacing the request-uri, but are just doing loose-routing.

-hadriel

> From: Dean Willis [mailto:[email-masked]]
> Sent: Thursday, October 15, 2009 5:45 PM
>

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Thu, 15 Oct 2009 17:06:03 -0500

Hadriel,

With respect to the text in 4.3.1:

   If a matching SIP Domain Name is found and the Contact URI being 
   Registered matches one already in the DRT, the REGISTER updates the 
   entry.

I suggest that the user portion of the REGISTER To: URI be used to
determine whether to update an existing entry or add a new entry.  This
avoids errant multiple entries in case a changed contact URI is received
(i.e. with a different IP Address) and the previous entry was not
de-registered as might happen in the case of a network failure.  In
doing this, it should be stated that the user info portion MUST remain
the same for a given connection path unless changed via manual
configuration.  While the problem I mentioned can happen for single user
type UAs, the problem is magnified when it happens for a PBX so we
should try to prevent it.

Lastly, nothing is mentioned in the draft about Call-ID and CSeq (Ref.
RFC 3261 Section 10.3) being used to determine if DRT entries should be
removed or updated.  Since REGISTER is being reused, an explicit
statement is warranted.

David

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Oct 2009 18:29:27 -0400

Inline...

> From: Middleton, David (NSN - US/Boca Raton)
> [mailto:[email-masked]]
> Sent: Thursday, October 15, 2009 6:06 PM
> 
> Hadriel,
> 

Yeah we've debated that one, and I think the consensus was: use sip-outbound if you want to avoid that.  Because really what it's asking for is reg-id and such, and we wouldn't want to conflict with sip-outbound's own mechanisms for doing that stuff.  So while you're right of course that you'll end up with two entries until the expires times out, it's not going to fail.  What I could do is say "for the same given q-value, use the most recently registered/updated one first".  How about that?
 
> removed or updated.  Since REGISTER is being reused, an explicit

Hmmm.  I was kinda trying to avoid including an update for or copy of section 10.3 in its entirety, and only do the "diff" part.  Are you thinking the Call-ID/CSeq checking of 10.3 should be different, or instead maybe that I wasn't clear in the draft that it's only a "diff" of it?

-hadriel

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Fri, 16 Oct 2009 06:53:28 -0500

Inline

-----Original Message-----
From: ext Hadriel Kaplan [mailto:[email-masked]] 
Sent: Thursday, October 15, 2009 6:29 PM
To: Middleton, David (NSN - US/Boca Raton)
Cc: [email-masked]
Subject: RE: [dispatch] Domain Registration Draft

Inline...

> should try to prevent it.

Yeah we've debated that one, and I think the consensus was: use
sip-outbound if you want to avoid that.  Because really what it's asking
for is reg-id and such, and we wouldn't want to conflict with
sip-outbound's own mechanisms for doing that stuff.  So while you're
right of course that you'll end up with two entries until the expires
times out, it's not going to fail.  What I could do is say "for the same
given q-value, use the most recently registered/updated one first".  How
about that?
<DM> I don't like the q-value distinction.  My thinking is that a
distribution of traffic across all registered contacts with the same
q-value should be allowed and that distinction would prevent that.
Also, reg-id can't be guaranteed to be unique when multiple CPEs (e.g.
PRI to SIP GW) register on behalf of the same PBX.

> removed or updated.  Since REGISTER is being reused, an explicit

Hmmm.  I was kinda trying to avoid including an update for or copy of
section 10.3 in its entirety, and only do the "diff" part.  Are you
thinking the Call-ID/CSeq checking of 10.3 should be different, or
instead maybe that I wasn't clear in the draft that it's only a "diff"
of it?
<DM> It isn't clear to me what the relationship with 10.3 is.  My
assumption was that Call-ID/Cseq checking were excluded because the
draft only talks about comparing the Domain Name and Contact URI.

-hadriel

---

From: Francois Audet <[email-masked]>
Date: Fri, 16 Oct 2009 06:59:54 -0700

I believe the best course of action is option 1.

The whole point of this is not to re-invent REGISTER. As others said,  
this may be something for SIP 3.0. The idea with option 1 is to  
formalize and harmonize a widely implemented (and useful) practice.

---

From: Dean Willis <[email-masked]>
Date: Fri, 16 Oct 2009 10:25:43 -0500

Hadriel Kaplan wrote:
> Well I really didn't mean for it to be disingenuous. (honest) The
> three things you mentioned, for example, do not mean to me the
> REGISTER transaction mechanism is broken whatsoever.  They have to do
> with how to route to the entity that Registered, which is after the
> fact.  In the Domain Registration mechanism we side-step that whole
> issue, since we're not replacing the request-uri, but are just doing
> loose-routing.
> 

Exactly: the extension you have requires the node using the REGISTERed
contact information to behave differently from how it would do it with
"regular" contacts, yet does not AFAIK give that node a really clear way
to know the difference.

The proposed ROUTEUP (was RUPDATE) mechanism eliminates this. An
exchanged route is something very clearly different from a registered
contact. It has different content, different behavior at the
storage-point (former registrar, where as you have noted it goes into a
different table from Contacts), different behavior at the route-sourcing
user agent or intermediary (both in sending the route and in handling a
received message routed via the mechanism) and different behavior at the
routing proxy that uses/inserts the route (requiring "loose routing",
which does not change the contact URI rather than "contact routing"
which does change the contact URI).

It's almost completely totally different from REGISTER.

We have no shortage of method namespace, so let's call it something
besides REGISTER.

While we're fixing the name, let's add a couple of needful things:

1) The ability to store multi-hop, rather than single-hop, routes. This
makes the whole "outbound" problem immensely easier to deal with.

2) The ability to route to tel:URI target URIs as well as sip: target URIs.

3) The ability to send more than one route in a single request.

4) The ability to express an aggregation policy (prefix/postfix
wildcards) in a route. This lets us target a range of phone numbers or
all or part of a domain or subdomain with a single URI.

5) The ability to selectively respond from the route-receiving end (the
"registrar") about authorization failures among multiple received routes.

6) Optionally, the ability for an upstream routing proxy to add itself o
the route set. This could replace Service-Route, Path, and I think most
of Outbound. The neat part is that once the basic mechanism is done,
this whole line item could be added in another RFC, so it doesn't have
to be in the base (we just have to not prevent it).

Once its done, I see new installations using this mechanism as a
replacement for REGISTER in all cases where there upstream path (former
registrar, possibly also a former "outbound" proxy) supports it.

The really neat thing about this is that this mechanism can be used in a
fully backward compatible way (as far as a UA is concerned) between a
proxy/registrar and a "further upstream" routing proxy like a telephony
service provider proxy. Where the new mechanism is used all the way to
the UA (and in some cases even without it) we also have a 100% solution
to the target-URI and target-parameter problems, because we've gotten
loose-routing rather than contact-routing on the whole path.

It's simple, I think it fixes a large part of what is wrong with SIP, it
doesn't require moving to SIP 3.0, and we pretty much know how to do it.
And your draft is a pretty good start on getting it done.

--
dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 16 Oct 2009 12:18:13 -0400

> Sent: Friday, October 16, 2009 11:26 AM
> To: Hadriel Kaplan
> 
> Hadriel Kaplan wrote:

Yes there is: the options-tag.  Without that, it would just be based on configuration; i.e., the SSP Registrar would be provisioned to know that for domain "enterprise.com", it uses loose-routing (and the rest of the mechanism).

> We have no shortage of method namespace, so let's call it something

We have no shortage of method namespace, but we also have no shortage of option-tag namespace.  There is nothing about a "REGISTER" method name string that ties it intrinsically with how the routing to the contact/path is performed.  Nor to which specific local database table its contact/path info is stored into.  

We chose to document a separate logical database in the draft just to make it crystal clear that its behavior is something different, and to make it part of the 3263 lookup process instead of the 3261 AoR resolution lookup process.  That was done on purpose, because the ownership/authority model for the AoR's of the Enterprise belong to the Enterprise - vs. belong to the SSP.  And that's the same reason we chose to Register a different Domain Name, rather than do the implicit-registration hack of 3gpp.  Thus, it follows the same model as routing from one domain (the SSP's) to another (the Enterprise's).

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 16 Oct 2009 12:45:16 -0400

I think there is a little more to the "use an option, or not" discussion:

If you use an optional header, or just provisioning, rather than an 
option, then the registrar is bound to handle the REGISTER in a manner 
compliant with 3261. That means it must allow multiple contacts, update 
the location service, return all the registered contacts present in the 
location service, etc.

It can *in addition* do other behavior that is optional based on whether 
or not it has the provisioning and/or understands the header.

When it comes to routing of subsequent requests, it is again to be 
compliant with 3261. But there you have more wiggle room because 3261 
gives broad latitude to a proxy about how to make its routing decisions. 
So if you choose to maintain this extra table, and check it first, 
before looking at the location service, then I think you can still be 
compliant.

With an option tag, I *think* you can alter the basic behavior of the 
REGISTER. Whether that is good in this case is debatable. (As it is now 
being debated.)

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Oct 2009 09:31:52 -0400

> From: Dean Willis [mailto:[email-masked]]
> Sent: Saturday, October 17, 2009 2:22 AM
> To: Hadriel Kaplan
> 
> > Yes there is: the options-tag.  Without that, it would just be based on
> configuration; i.e., the SSP Registrar would be provisioned to know that
> for domain "enterprise.com", it uses loose-routing (and the rest of the
> mechanism).
> 
> I think you misunderstand the OPTIONS tag. It's presence in Supported:
> says the sender of the request supports the extension. In Require:, it
> requires the receiver to support the extension. It NEVER says "I am
> using this extension for this specific request". There needs to be
> something "different" about the contact (or other parts of the request)
> itself so that the registrar can handle it differently.

While that may have been the semantic intention of that header field, some option-tags clearly mean more than that - they mean "you must use this extension for this request".  For example, rfc3262 100rel has that meaning:

   The UAS MUST send any non-100 provisional response reliably if the
   initial request contained a Require header field with the option tag
   100rel.  If the UAS is unwilling to do so, it MUST reject the initial
   request with a 420 (Bad Extension) and include an Unsupported header
   field containing the option tag 100rel.

Ergo, it does not just mean "you gotta support the reliable response concept to accept this request", but rather "you gotta USE reliable responses for this transaction to accept this request".

You're right that the current Domain Registration draft doesn't say that as explicitly as rfc3262 did, so I gotta go fix that - but that was the intention... do what I mean not what I say ;)

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 10:08:59 -0500

Hadriel Kaplan wrote:
.  For example, rfc3262 100rel
> has that meaning:
> Ergo, it does not just mean "you gotta support the reliable response
> concept to accept this request", but rather "you gotta USE reliable
> responses for this transaction to accept this request".

3262 is badly, badly worded. Please don't use it as "the rule".

The intent is that if the UAS is aware that the UAC supports 100rel, and
the UAS supports 100rel, then the UAS will use 100rel.

This is probably worth filing an errata on 3262. If the UAS supports
100rel, it should use it if the UAC indicated support for it in the
request. The support should have been indicated in Supported. The
difference is that if it is Require, then the UAS MUST reject the
request if it does not support the extension, whereas if it is only in
Supported, then the UAS may, if it does not support 100rel, respond
non-reliably.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 17 Oct 2009 11:20:28 -0400

Too late methinks - there are already devices out there that will fail the transaction if the UAS does not actively use reliable responses for the INVITE request. (ie, they demand PRACK)  I hate it myself, and think they're nuts to prefer actually failing calls instead, but they're deployed.

Regardless, if you'd prefer, we can add a uri-param to the To-URI to indicate "this is a Domain being registered, not an AoR" and then the option-tag would require support to understand that param.
Acceptable?

-hadriel

> Sent: Saturday, October 17, 2009 11:09 AM
> To: Hadriel Kaplan
> Cc: Dean Willis; [email-masked]; Robert Sparks; Richard Shockey; Cullen
> Jennings; [email-masked]

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Oct 2009 11:04:45 -0500

Hadriel Kaplan wrote:

> 
> Regardless, if you'd prefer, we can add a uri-param to the To-URI to
> indicate "this is a Domain being registered, not an AoR" and then the
> option-tag would require support to understand that param. 
> Acceptable?

That would be better.

The real question is what happens when a domain-registration request
that is not marked with a Require for the option lands at a registrar
that does not understand the extension.

Will the non-domain registrar try to execute the REGISTER? What happens
when it does?

While you could say "If you are doing domain-registration, you must
Require the option tag for this feature in every domain-registering
request", this is inconsistent with the way we've traditionally used
Require.

It would be better yet to use something besides REGISTER as the request
method name, or to put the registered routes into something that is not
Contact and put only "safe" values in Contact. Or both -- this
absolutely prevents the uncertainty condition.

--
Dean

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 19 Oct 2009 10:25:37 +0200

I think this discussion is going down the rat hole of trying to find a way of using "correctly" a mechanism that current practice already uses "incorrectly" in other contexts. It seems easier to go with the tide and use an option tag in Require, as proposed in the draft.

John

> Sent: 17 October 2009 17:05
> To: Hadriel Kaplan
> Cc: [email-masked]; Dean Willis

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 19 Oct 2009 17:00:53 -0400

> http://www.ietf.org/id/draft-kaplan-dispatch-domain-registration-00.txt

Is there any way we can get the name of the activity changed to be
something other than "domain registration"?  "Domain registration"
already has a well-defined meaning -- registering one's domain with the
DNS system -- and this mechanism is intended only for situations where
that is *not* being done.

In addition, there is the SIP concept of registering the contact for an
AOR, which adds a second meaning to "registration".

Dale

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 19 Oct 2009 16:33:37 -0500

Without speaking for the draft author, I think "domain" is open for 
suggestions. The SIPconnect working group has gone through "registration" 
with no qualifier, "implicit registration", and I think "bulk registration" 
was also tossed in but sank without a ripple, so we're obviously not wedded 
to "domain".

"registration" is harder for me to think of alternatives for, because we 
think we're achieving roughly the same end-game as per-AOR registration, and 
we're currently using the REGISTER method. But please make suggestions - my 
problem could easily be my own lack of imagination!

Thanks,

Spencer

---

From: Dean Willis <[email-masked]>
Date: Mon, 19 Oct 2009 23:34:17 -0500

> AOR, which adds a second meaning to "registration".

Indeed. REGISTER also has yet another meaning in the mobile phone  
world. It's a seriously overloaded term.

What we are really talking about doing is dynamic route exchange,  
where the targets of the routes involved are "domains".

We could call it "dynamic SIP domain routing", "SIP domain route  
exchange"',  or, as I proposed, "SIP routing updates", which fits  
nicely with the proposed ROUTEUP method.

The thing that the proponents of Hadriel's draft are missing is that  
the hacky part is not the registration of the routes. It's not even  
how the routes are used. The hacky part of the proposal is the way the  
routes are constructed so that they look like AORs, which allows them  
to be conveyed in a syntactically (but not semantically) correct  
REGISTER. This is a big hack. If we are taking this to a "standard",  
we need to make something that is less hacky, more regular, and  
possible to get "right".

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 20 Oct 2009 10:38:50 -0400

> Sent: Tuesday, October 20, 2009 12:34 AM
> 

Huh.  I assumed the part some folks thought was a "hack" was the fact we were using a REGISTER method.  But you raise an interesting point - perhaps we should make the To-URI just the domain name without a user@ portion.  The From-URI would still be an AoR, namely one of the PBX itself.  i.e., it would be like a third-party registration - "[email-masked]" is registering the domain "enterprise.com".

-hadriel

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 20 Oct 2009 13:37:37 -0400

Hi Hadriel,

   I think leaving that aspect "as is" would be preferable in that it
would be more compatible with in-the-wild implementations (and
potentially some other standards) that support an "implicit"
registration to accomplish exactly the same thing. 

   Thanks

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Hadriel Kaplan
Sent: Tuesday, October 20, 2009 10:39 AM
To: Dean Willis; Worley, Dale (BL60:9D30)
Cc: [email-masked]
Subject: Re: [dispatch] DomainRegistration Draft
draft-kaplan-dispatch-domain-registration

> we need to make something that is less hacky, more regular, and 

Huh.  I assumed the part some folks thought was a "hack" was the fact we
were using a REGISTER method.  But you raise an interesting point -
perhaps we should make the To-URI just the domain name without a user@
portion.  The From-URI would still be an AoR, namely one of the PBX
itself.  i.e., it would be like a third-party registration -
"[email-masked]" is registering the domain "enterprise.com".

-hadriel

---

From: Dean Willis <[email-masked]>
Date: Tue, 20 Oct 2009 22:36:32 -0500

On Oct 20, 2009, at 9:38 AM, Hadriel Kaplan wrote:

> Huh.  I assumed the part some folks thought was a "hack" was the  
> fact we were using a REGISTER method.  But you raise an interesting  
> point - perhaps we should make the To-URI just the domain name  
> without a user@ portion.  The From-URI would still be an AoR, namely  
> one of the PBX itself.  i.e., it would be like a third-party  
> registration - "[email-masked]" is registering the domain  
> "enterprise.com".
>

Yes, I do like this approach better.

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 23 Oct 2009 10:01:23 -0400

BTW, with regards to being able to use an option-tag in a Require header to mean more than just "I require you to support the following extension", but to in fact mean "I require you to USE the following extension"... I have been doing some digging, and it appears RFC 3262 is not the only one to do that.

RFC 3329 SIP Security Agreement does the following for the sec-agree tag:
   A server receiving an unprotected request that contains a Require or
   Proxy-Require header field with the value "sec-agree" MUST respond to
   the client with a 494 (Security Agreement Required) response.  The
   server MUST add a Security-Server header field to this response
   listing the security mechanisms that the server supports.  The server
   MUST add its list to the response even if there are no common
   security mechanisms in the client's and server's lists.  The server's
   list MUST NOT depend on the contents of the client's list.

And in Draft-sip-outbound-20 (the latest rev, soon to be RFC):
   If outbound registration succeeded, as indicated by the presence of
   the outbound option-tag in the Require header field of a successful
   registration response, the UA begins sending keep alives as described
   in Section 4.4.

There is a counter-example: RFC 4488 has a norefersub option-tag but created a header just to say "do it" (that being: "Refer-Sub: false").  Although one could argue that's not quite analogous to the case being done here, since it was useful in a Supported header.  In the domain-registration case, it would actually be illogical to say "I require you to support me registering a domain in order to process this REGISTER request, but I'm not actually registering a domain in this register request".

-hadriel

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 26 Oct 2009 16:31:56 -0400

I think the proposal can be improved and controversy avoided by making
three rather small changes:

1. Restrict (at least in principle) the domain name involved to be one
that is properly owned or controlled by the SSP or PBX.

2. Replace the REGISTER method with a new method name.

3. Clarify that the RFC defines a mechanism for maintaining a "route to
this domain" database, which may be used in various ways which are not
specified by the RFC.  (In particular, the SSP might use it to apply
Route headers to requests, or it might use it to populate a DNS server,
and then use RFC 3263 to route requests.)  This loses no functionality
and ensures that the database-updating remains uncoupled from the users
of the database.

Justifications for items 1 and 2:

1. Allowing arbitrary domain names leads to the alt-root controversy,
etc.  In addition, if the domain name is used only between the SSP and
the PBX, and within the PBX's services, it is essentially arbitrary, in
which case it might as well be a properly owned domain name.  If the
domain name is visible outside this region, it will have to be properly
owned if we expect external elements to utilize it in accessing the PBX.
In neither case is a private name space particularly useful.

Of course, in practice, people will do whatever they want, but we avoid
committing to support private name spaces in the future.

2. This change has more complex consequences, but I think the balance of
facts is in its favor:

a. It reduces the compatibility problems relative to the ad-hoc
mechanisms currently deployed, since the new method makes it clear that
the new, standardized mechanism is to be used.  Conversely, elements
wishing to remain compatible with a current ad-hoc use of REGISTER for
this purpose can continue to do so.

b. It avoids having to define an option-tag, as the *effect* of using a
new method is the same as using an old method with a new option-tag:
UASs that are unaware of the new mechanism will reject the request.
(Thus demonstrating that the opinion that a new method is more radical
than a new option-tag has no substance.)

c. Specific mechanisms that are now defined for use with REGISTER can be
recycled for use with the new method by simply referencing them in the
RFC.  And mechanisms that are now defined for use with REGISTER that are
of no value with domain-registration (e.g., GRUU) are explicitly
omitted.

d. Using a new method avoids the dangerously ill-structured process of
using one method for requesting multiple activities that are
almost-but-not-quite the same.

Let us compare the situation with that of REFER.  At last count, there
were five distinct uses of the REFER method.  Each is distinguished by
specific combinations of header fields and features of the context
within which the REFER is received.  This leads to several undesirable
consequences:

- The code at the UAS is no simpler, as there need to be five different
code paths, one for each version of REFER.  Currently, the dispatching
is done by examining the context of the REFER, whereas if there were
five methods, dispatching could be done by method name.

- Because the rules for distinguishing the five cases are not explicit,
implementers may easily make mistakes coding the dispatching.

- Because the function of a REFER is determined by context, a REFER that
is accidentally sent in a different context than which was intended may
not be detected as an error and may cause inadvertent actions.

- If there were separate method names, then each of the five code paths
could continue to examine the context of the request, but as a validity
check rather than as a dispatching decision.

- Different uses of REFER have subtly different constraints on valid
values for the various header fields.

In the case of domain-registration REGISTERs, we are already discussing
what the To-URI should be, which shows that the domain-registration
REGISTER isn't really the same beast as the AOR REGISTER.  And some
extensions of REFER (e.g., GRUU) aren't to be used with
domain-registration.  We can expect further subtle differences to be
discovered.

e. The new method is freed from having to resemble REGISTER in aspects
that are unnatural for the function of the new method.

f. The claim that the new method is exactly like the old REGISTER except
for the database that is populated is true in a psychological sense, but
not in a coding sense -- Various details are different (the To/From
headers do not have exactly the same format or interpretation, multiple
Contacts are forbidden, and it's unlikely that the query formats are
supported).  And I doubt that there will be *any* implementation that
will process the two functions with the *same* code, only with a
differing parameter-value indicating the database to be updated.

g. Using a new method puts the new mechanism beyond a large set of
"ideological" arguments.  (But most of the ideological arguments are
abstract versions of the above practical considerations.)

(This new method may actually *be* the RUPDATE proposed by Dean, but I
haven't read into that, so I don't know.)

Dale

---

From: "Dale Worley" <[email-masked]>
Date: Mon, 26 Oct 2009 16:35:40 -0400

> problem could easily be my own lack of imagination!

Perhaps "routing registration"?

Dale

---

From: Dean Willis <[email-masked]>
Date: Mon, 26 Oct 2009 19:34:08 -0500

> Perhaps "routing registration"?

Route update -- using a different request method than REGISTER, like  
maybe ROUTEUP. Or given the overload on UPDATE, maybe call it a "route  
advertisement", which is terminology that seems to have worked well in  
the routing world.

Why do we think we're the first ones to encounter this design pattern?

--
Dean

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 26 Oct 2009 22:27:11 -0400

Hi Dale,
Inline...

> Behalf Of Dale Worley
> Sent: Monday, October 26, 2009 4:32 PM
> 

Already done - see version 01 of the draft (submitted today).

> 2. Replace the REGISTER method with a new method name.

This has already been discussed, and I tried to better summarize the reasons why REGISTER is necessary in the draft-01 rev.

> and ensures that the database-updating remains uncoupled from the users

I'm not sure what that buys us.  I don't think there's any controversy over the "how to use the database" part.  But more importantly, for interoperability to be achieved I think it's critical we explain how it's used, since it affects what requests routed by it look like to the party that Registered. 

-hadriel

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 28 Oct 2009 09:03:20 -0500

Dale Worley wrote:

(/me hesitantly jumps into the fray)

> values for the various header fields.

I agree with Dale's points here rather strongly; when writing the UAS
code to handle requests, it is much more logical and straightforward to
inspect option tags and header fields when the purpose of doing so is
sanity checking and for subtly adjusting the behavior of the request.
When the option tags and/or header field values are used to cause a
different operation to be performed, the code gets much more complex and
harder to maintain.

On the UAC side, I can't see how the need to take the existing
(pre-standard) code and modify it to use a new method name is going to
be any more burden than modifying that same code to conform to the
standard... since there are very few (if any) existing implementations
that already conform to the proposed standard. The UAC side of this
proposal is very easy to implement in either case.

I haven't seen any comments in this thread about how the re-use of
REGISTER for a different purpose would affect proxies in the route path;
if a proxy has to inspect option tags and header values to decide how to
route a request, that increases complexity as well, which is avoided if
the request uses a different method.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 28 Oct 2009 15:38:01 +0100

> [mailto:[email-masked]] On Behalf Of Kevin P. Fleming
> Sent: 28 October 2009 14:03
> Cc: DISPATCH
> Subject: Re: [dispatch] 
> draft-kaplan-dispatch-domain-registration should use a 
> different method
> 
> Dale Worley wrote:
> 
[JRE] This is a very good point. If we use REGISTER, then proxies on the path can behave exactly as they would for a normal registration, e.g., w.r.t. Path and Outbound processing. Is that what we want? I believe so, because the different behaviour required is at the registrar/proxy. If proxies along the path need to behave differently, that might support the argument for using a different method, but if they need to behave the same as for REGISTER, I think this is a very strong (perhaps compelling) argument for keeping REGISTER.

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Oct 2009 11:15:13 -0400

Hi Kevin, 
The intent of the draft, and part of the rationale for using REGISTER in fact, is that it's processing is NOT different.  It's not different on Proxies, and it's not different on UAC's other than adding that tag string.  It's not even actually that different on UAS's - it's real "difference" to the UAS/Registrar is the logical Database it updates, and the key it uses to lookup in that database.

The "routing" portion of the draft, which uses the database and uses loose-routing to reach the IP-PBX, is different than how 3261 routes to the AoR database populated by REGISTER.  But that's not tied to the REGISTER request method name, obviously.

It's true that affecting a different database is a change for REGISTER.  But if using a option-tag or header to indicate that is "more complex and harder to maintain" than using a new method name, then we're in real trouble.  Because PUBLISH and SUBSCRIBE effectively do that with every different event package, without changing the method name, afaict. 

-hadriel

> Behalf Of Kevin P. Fleming
> Sent: Wednesday, October 28, 2009 10:03 AM
> Cc: DISPATCH
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 28 Oct 2009 10:40:04 -0500

> The intent of the draft, and part of the rationale for using REGISTER in fact, is that it's processing is NOT different.  It's not different on Proxies, and it's not different on UAC's other than a…

While I can't claim to speak authoritatively on this, I would strongly
suspect that an actual SSP accepting domain registration requests
*would* want to route them differently through their proxies. I can also
envision cases where SBCs and other network elements would enforce
different policies for domain registrations vs. normal AoR registrations.

> It's true that affecting a different database is a change for REGISTER.  But if using a option-tag or header to indicate that is "more complex and harder to maintain" than using a new method name,…

I believe the difference is because for PUBLISH/SUBSCRIBE, the
proxy/SBC/UAS/etc. processing the request is less likely to need to
enforce different security/authorization policies based on the event
package requested than it would be for domain registrations vs. AoR
registrations.

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 28 Oct 2009 12:28:07 -0400

>  proposal is very easy to implement in either case.

There are LOTS of implementations of the REGISTER procedure in place right
now. The purpose of the proposed draft is to fix the interoperability
problems in the field right now while permitting a larger investigation how
the larger issues can be addressed.

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 28 Oct 2009 12:43:37 -0400

> Sent: Wednesday, October 28, 2009 11:40 AM
> 

Sure, some functions a B2BUA may do for domain-registrations may be different than for aor-registrations, which is why it would be nice to get an option-tag (and possibly header), instead of just defining this as an implementation agreement outside of the IETF without any changes on the wire from aor-registrations. 

> package requested than it would be for domain registrations vs. AoR

I can't speak for others, but as just one data-point, at least for my company's SBC's the event-packages in PUB/SUB/NOT do or can affect processing in several ways.  And I'm pretty sure that indeed the domain-registration draft will require changes on our product for some features.  That's one of the reasons I have the option-tag be in a Require header, so it fails if the UAS or B2BUA (being a UAS) doesn't support it.

But a "Proxy", i.e a 3261 Proxy, would not afaik.

-hadriel