Subject: [martini] draft-roach-martini-up-00

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jan 2010 10:04:25 -0600

I have put together a draft that demonstrates several mechanisms that 
can be used to achieve MARTINI's goals while avoiding the pitfalls that 
occur with some of the currently deployed mechanisms and proposals.

There is still some room for additional fleshing out and other 
improvements, but the current document contains enough information to 
convey the basic ideas, and demonstrate feasibility of the proposed 
mechanisms:

http://www.ietf.org/id/draft-roach-martini-up-00.txt

/a

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 6 Jan 2010 20:56:38 +0100

Adam,

In your proposal, there is no consideration of proxies between the PBX and the SSP's domain proxy/registrar, and the need for the proxy/registrar to know the path through these proxies back to the PBX. In other words, it provides contact information without path information. Using the REGISTER method, the Path header field solves this problem.

John

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Adam Roach
> Sent: 06 January 2010 16:04
> To: [email-masked]
> Subject: [martini] draft-roach-martini-up-00
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: "David Hancock" <[email-masked]>
Date: Wed, 6 Jan 2010 13:30:14 -0700

I agree with John -- having to provision this routing information
manually would be a big burden for operators serving large numbers
(potentially tens of thousands) of IP-PBXs. Having a dynamic way to
discover this routing info makes IP-PBX deployments a lot more scalable.

Outbound is another useful SIP extension available with the
register-based approach. In addition to providing a NAT-traversal
solution, its multiple-flow capability could be part of the
high-availability solution for the IP-PBX.

David

> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Elwell, John
> Sent: Wednesday, January 06, 2010 12:57 PM
> To: Adam Roach; [email-masked]
> Subject: Re: [martini] draft-roach-martini-up-00
> 
> Adam,
> 
> In your proposal, there is no consideration of proxies between the PBX
and
> the SSP's domain proxy/registrar, and the need for the proxy/registrar
to
> know the path through these proxies back to the PBX. In other words,
it
> provides contact information without path information. Using the
REGISTER
> method, the Path header field solves this problem.
> 
> John
> 
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 06 Jan 2010 20:01:08 -0600

> In your proposal, there is no consideration of proxies between the PBX and the SSP's domain proxy/registrar, and the need for the proxy/registrar to know the path through these proxies back to the…

In some rather important ways, that's a feature, not a bug. 
Intermediaries may choose how to handle Path and Service-Route based on 
the user being registered. In the case of implicit registrations for 
multiple users, such intermediaries will actually make incorrect policy 
decisions, since they'll be basing such decisions on the "To:" header 
field (representing the PBX), not the implicit AORs (representing the 
users). Because intermediaries know what REGISTER means in RFC 3261, and 
we're proposing to change that meaning, the only way around this 
particular issue is adding a "Proxy-Require" to implicit registrations, 
which is probably not the direction we want to take this.

In terms of how to solve this class of problems with the mechanism I 
propose: it takes a decided lack of imagination not to be able to 
envision how Path and Service-Route could be applied to PUBLISH 
requests. You can get just over 95% of the way there by loading RFCs 
3327 and 3608 into a text editor and globally replacing the string 
"REGISTER" with "PUBLISH".

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 08:42:36 +0100

Adam,

Sure you could specify the use of Path and Service-Route with PUBLISH, but that is yet another aspect for the entities concerned to support. We seem to be getting further and further from the objective of fixing the problem that exists in the field today: lots of implementations based around REGISTER (+ Path etc.), but differing in details such that interoperability is impaired. We need to nail down the details so that, with relatively minor changes to the entities involved, interoperability can be achieved. The more major the changes, the longer it will take for vendors to implement, and in fact the less likely it will be that vendors do implement.

Furthermore, a simple nailing down of details of how the REGISTER-based mechanism works might even avoid changes to intermediate proxies, or at least minimise those changes. A change to PUBLISH with its entirely new syntax, together with the use of things like Path and Service-Route with PUBLISH, would represent substantial changes for those intermediaries. An intermediary would need to behave differently for a PUBLSIH in accordance with this event package (e.g., add a Path header field), compared with a PUBLISH for other event packages. Not very clean.

Finally, I re-iterate that the perceived benefits that the PUBLISH proposal gives are not requirements. A PBX will generally be configured or scripted with rules to apply to requests inbound to one if the AORs it is responsible for, which might include parallel or serial delivery to multiple contacts, eventual forwarding to voicemail, or in some cases outright rejection. This information needs to be in the PBX, so that requests originating in the PBX (or from some other source not arriving via the SSP) can be handled correctly. Requests arriving from the SSP should be handled the same (notwithstanding the fact that the rules concerned might be impacted by the source of the request). The idea is to deliver requests to the domain that is able to handle them, i.e., the PBX, and for the PBX to deal with issues of nomadicity etc., e.g., by redirection if the required contact happens to be off-PBX. The so-called feature of the SSP being able to fork is in my opinion a disadvantage, and results in split responsibility for an AOR, something which surely is contrary to the principles of RFC 3261.

Note that the multiple registrations capability in the shaken-implicit draft is intended for resilience purposes, not for being able to register different contacts for different AORs.

John

> From: Adam Roach [mailto:[email-masked]] 
> Sent: 07 January 2010 02:01
> To: Elwell, John
> Cc: [email-masked]
> > In your proposal, there is no consideration of proxies 
> between the PBX and the SSP's domain proxy/registrar, and the 
> need for the proxy/registrar to know the path through these 
> proxies back to the PBX. In other words, it provides contact 
> information without path information. Using the REGISTER

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 09:27:21 +0100

Question about P-Asserted-Identity handling.

There are configurations where the asserion of an identity is performed by an edge/outbound proxy (e.g. P-CSCF in case of an IMS). This requires the edge/outbound proxy to be aware of the list of valid values. The PAU provides means to convey this information to the edge/outbound proxy. What would be the alternative mechanism to use if the PUBLISH-based solution described in this I-D were implemented.

/BC

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Adam Roach
> Envoyé : mercredi 6 janvier 2010 17:04
> À : [email-masked]
> Objet : [martini] draft-roach-martini-up-00
> 
> I have put together a draft that demonstrates several 
> mechanisms that can be used to achieve MARTINI's goals while 
> avoiding the pitfalls that occur with some of the currently 
> deployed mechanisms and proposals.
> 
> There is still some room for additional fleshing out and 
> other improvements, but the current document contains enough 
> information to convey the basic ideas, and demonstrate 
> feasibility of the proposed
> mechanisms:
> 

*********************************
This message and any attachments (the "message") are confidential and intended solely for the addressees. 
Any unauthorised use or dissemination is prohibited.
Messages are susceptible to alteration. 
France Telecom Group shall not be liable for the message if altered, changed or falsified.
If you are not the intended addressee of this message, please cancel it immediately and inform the sender.
********************************

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 08:48:09 -0600

John:

The problem with the approach you espouse below is that it is a point 
solution for a very specific architecture. The general approach that 
we've taken with SIP in the past is to standardize general tools that 
can be combined to accommodate varying services and varying architectures.

This is, for example, why we selected draft-ietf-sip-refer over 
draft-dean-handoff (http://tools.ietf.org/id/draft-dean-handoff-00.txt) 
-- we recognized that defining a service-enabling tool was infinitely 
more flexible than defining a service.

In terms of "perceived benefits," I'll point out that the PUBLISH 
proposal eliminates the vast majority of the problems described in the 
martini-mixing-problems draft not by solving them, but by sidestepping 
them altogether.

Do I care about that? Not very much. It's not why I'm here.

What's important to me is that my proposal also doesn't materially 
change the semantics of a core SIP method -- because such changes can 
result in potential policy violations, like the one I describe in my 
message below. My horse in this race is "don't screw up the core SIP 
protocol." I understand that you have a very specific problem you're 
trying to solve, and that the least-effort approach would be to define a 
laser-focused point solution that addresses precisely one architectural 
model, with little regard for how it interacts with other architectures 
or other parts of the protocol.

I'm here to make sure there's no collateral damage.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 16:27:08 +0100

> Sent: 07 January 2010 14:48
> To: Elwell, John
> Cc: [email-masked]
> draft-dean-handoff 
> (http://tools.ietf.org/id/draft-dean-handoff-00.txt) 
[JRE] I understand that, but it is not clear to me why we can't come up with a REGISTER-based proposal that is not fundamentally broken. I believe the PUBLISH proposal is even more broken, if intermediaries have to be aware of the specific event package and take special action to do with Path, for example.

John

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 7 Jan 2010 10:55:29 -0500

>  martini-mixing-problems draft not by solving them, but by sidestepping

Adam you are not listing to some of us. 

>  protocol." 

Good grief Adam we are not screwing up the core SIP protocol. What a
preposterous statement. That was done by others a long time ago. You have
not convinced me or some us that going off into an entirely different
direction, as you propose, fixes the relatively simple problem in the field
we are collectively encountering. Nor does your solution fix the larger
issue of provisioning between PBX's and SSP. That larger issue is a question
for another day.

I understand that you have a very specific problem you're
>  trying to solve, and that the least-effort approach would be to define
>  a  laser-focused point solution that addresses precisely one
>  architectural  model, with little regard for how it interacts with other
>  architectures  or other parts of the protocol.
>  

IMHO you have not made your case that martini-shaken would cause any damage
at all especially since the REGISTER method is very very widely deployed now
and actually works ..if somewhat inconsistently which is the simple problem
we are trying to solve without having to force a major revision to existing
code bases. 

Ok I understand why some people do not like martini-shaken but once and a
while duct tape and baling wire actually works. Some of us have looked at
this problem for nearly 16 months and we came to the inevitable conclusion
that the martini-shaken solution was in fact the best way to proceed.

What I want to make sure is that there is no collateral damage to the SIP
industry as a whole. If we ( IETF ) continue to make it difficult, if not
impossible to address very simple interoperability problems in a timely
fashion with the DISPATCH process what vendors and SSP's will ultimately do
is run off on their own with even more damage to SIP than has already been
done.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 10:02:00 -0600

On 1/7/10 09:27, Jan 7, Elwell, John wrote:
>> ...
> [JRE] I understand that, but it is not clear to me why we can't come up with a REGISTER-based proposal that is not fundamentally broken.

Because using REGISTER to talk about multiple users is fundamentally 
broken. It's not what REGISTER means. And there are SIP implementations 
out there that do know what REGISTER means. You are changing a 
fundamental property of a core SIP construct -- the operation no longer 
applies to just the user indicated in the "To" header field; it applies 
to myriad disparate users. Intermediaries assuming it means what RFC 
3261 says it means will be mislead, and make potentially incorrect 
policy decisions as a consequence.

> I believe the PUBLISH proposal is even more broken, if intermediaries have to be aware of the specific event package and take special action to do with Path, for example.
>    

We *want* intermediaries to be aware of what's going on. It would be an 
error to let them continue to operate as if this were a REGISTER request 
for a single user. Without a "Proxy-Require," the only way to do this is 
not to use REGISTER.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 10:25:30 -0600

> Adam you are not listing to some of us.

That's funny -- I get the impression that the key issue I'm raising 
isn't being listened to either. At least, no one has addressed how 
intermediaries are going to know that this is not an ordinary REGISTER 
request in a way that doesn't effectively make the output of MARTINI a 
mandatory-to-implement part of the core SIP protocol.

> preposterous statement. That was done by others a long time ago.

"Well, he appears to have a contusion on his leg. Certainly it's okay 
break his arm, since he's already injured."

> Nor does your solution fix the larger issue of provisioning between PBX's and SSP.

If you've read something that you think implied that it did, I assure 
you that you've missed the point of whatever you were reading at the 
time. Go back and find the intended meaning.

> IMHO you have not made your case that martini-shaken would cause any 
> damage at all especially since the REGISTER method is very very widely 
> deployed now and actually works ..

The fact that it works in a specific architecture says nothing about how 
it interacts with other architectures. The proposed changes to REGISTER 
are simply not backwards compatible with the protocol as it has already 
been defined. A change in semantics without an indicator that will alert 
all interested parties of the change in semantics is a recipe for 
disaster. And intermediaries are a party to REGISTER transactions, for 
better or for worse.

/a

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 17:28:14 +0100

I'm not sure I understand why using REGISTER for the PBX case is fundamentally broken. Is there a fundamental difference between a small PBX and a SIP-aware Home/Residential Gateway serving a couple of lines/numbers/users in one house? Or would you also argue that such a HGW should also use the PUBLISH method?

/BC

> Envoyé : jeudi 7 janvier 2010 17:02
> À : Elwell, John
> Cc : [email-masked]
> Objet : Re: [martini] draft-roach-martini-up-00
> 
> > [JRE] I understand that, but it is not clear to me why we 
> can't come up with a REGISTER-based proposal that is not 
> fundamentally broken.
> 
> Because using REGISTER to talk about multiple users is 
> fundamentally broken. It's not what REGISTER means. And there 
> are SIP implementations out there that do know what REGISTER 
> means. You are changing a fundamental property of a core SIP 
> construct -- the operation no longer applies to just the user 
> indicated in the "To" header field; it applies to myriad 
> disparate users. Intermediaries assuming it means what RFC
> 3261 says it means will be mislead, and make potentially 
> incorrect policy decisions as a consequence.
> 
> > I believe the PUBLISH proposal is even more broken, if 
> intermediaries have to be aware of the specific event package 
> and take special action to do with Path, for example.
> >    
> 
> We *want* intermediaries to be aware of what's going on. It 
> would be an error to let them continue to operate as if this 
> were a REGISTER request for a single user. Without a 
> "Proxy-Require," the only way to do this is not to use REGISTER.
> 
> /a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 10:42:34 -0600

On 1/7/10 10:28, Jan 7, [email-masked] wrote:
> I'm not sure I understand why using REGISTER for the PBX case is fundamentally broken.

Consider the case in which the intermediary is making policy decisions 
based on the user being registered. If it uses the RFC 3261 definition 
of REGISTER, then it knows that the user under discussion is the user 
indicated in the "To" header field, and that policies should be applied 
accordingly.

Once we change the semantics of REGISTER so that the user -- or users -- 
under discussion no longer appear in the "To" header field, then this 
intermediary will be relying on incorrect information for its policies.

> Is there a fundamental difference between a small PBX and a SIP-aware Home/Residential Gateway serving a couple of lines/numbers/users in one house? Or would you also argue that such a HGW should also use the PUBLISH method?
>    

I would argue that a small home gateway servicing two users would 
generally maintain two independent registrations using the REGISTER method.

However, if they wanted to consolidate these into a single operation, 
then yes, the idea is that the unified way to update rendezvous 
information for multiple users would be using PUBLISH.

/a

---

From: Alan Johnston <[email-masked]>
Date: Thu, 07 Jan 2010 10:47:43 -0600

Adam,

A question and a comment below.

- Alan -

Adam Roach wrote:
>> [JRE] I understand that, but it is not clear to me why we can't come 
>> up with a REGISTER-based proposal that is not fundamentally broken.
>
> broken. It's not what REGISTER means. And there are SIP 
> implementations out there that do know what REGISTER means. You are 
> changing a fundamental property of a core SIP construct -- the 
> operation no longer applies to just the user indicated in the "To" 
> header field; it applies to myriad disparate users. Intermediaries 
> assuming it means what RFC 3261 says it means will be mislead, and 
> make potentially incorrect policy decisions as a consequence.

What kinds of sensible things could an intermediary proxy do with such a 
REGISTER?  And what problems would this cause?

I could only imagine a proxy which is part of either the service 
provider domain or the enterprise domain doing anything sensible with 
the REGISTER, and both of these would recognize it as as what it is.

A proxy which is not part of either of these domain *might* be subject 
to the confusion you point out, but I would argue this proxy should not 
do anything to this request except do Section 16 of RFC 3261 routing on 
it, and I don't believe anything will break based on what is being proposed.

>
>> I believe the PUBLISH proposal is even more broken, if intermediaries 
>> have to be aware of the specific event package and take special 
>> action to do with Path, for example.
>>    
>
> We *want* intermediaries to be aware of what's going on. It would be 
> an error to let them continue to operate as if this were a REGISTER 
> request for a single user. Without a "Proxy-Require," the only way to 
> do this is not to use REGISTER.
>
> /a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 17:48:01 +0100

> Sent: 07 January 2010 16:26
> To: Richard Shockey
> Cc: Elwell, John; [email-masked]
[JRE] It is not clear to me why intermediaries need to know - it is the SSP's domain proxy that needs to know.

John

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 10:50:29 -0600

> [JRE] It is not clear to me why intermediaries need to know - it is the SSP's domain proxy that needs to know.

So they can make appropriate policy-related decisions.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 17:52:00 +0100

> Sent: 07 January 2010 16:50
> To: Elwell, John
> Cc: Richard Shockey; [email-masked]
> > [JRE] It is not clear to me why intermediaries need to know 
> - it is the SSP's domain proxy that needs to know.
> >    
> 
[JRE] I think Alan just answered that.

John

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jan 2010 10:59:44 -0600

John,

Do you consider the use of REGISTER to be a _requirement_ for this effort? That seems like the direction people are going, but I'm not comfortable with the solution choice being a requirement.

I'm not sure I buy the idea that a non-REGISTER solution is necessarily that much harder to deploy. Face it, even if we end up with a REGISTER approach, it's going to be somewhere between subtly different and very different than the approach taken by any particular existing implementation. At _best_, a small number of implementations luck out in that their variation gets chosen.

It's my experience that implementors will be no more willing to make small changes than to make bigger ones. Touching anything is the expensive part, everything else is just work.

Also, I don't see how it is any harder for an intermediary device to recognize it needs to take certain actions with a PUBLISH request with a certain event header value than it is to recognize it needs to take certain actions with REGISTER based on a proxy-require, require, or (heaven-forbid) implicit knowledge of some magic AoR.

Adam is correct that bulk register changes the semantics of REGISTER. The semantic of REGISTER is to bind one or more contacts to a single AoR. PUBLISH OTOH, was designed with the idea of pushing arbitrary, but well-defined, state into the network. Bulk-register seems a lot more like the latter than the former.

Full discloser: If I had my druthers, I'd deprecate REGISTER _entirely_, and replace it with PUBLISH for reg-event or some similar package. REGISTER is broken even when used according to 3261 (overloaded use of To, From, and r-URI, pseudo-dialogs, poor concurrency properties, etc.) We certainly should not be defining _new_ uses of it.

On Jan 7, 2010, at 1:42 AM, Elwell, John wrote:

> Furthermore, a simple nailing down of details of how the REGISTER-based mechanism works might even avoid changes to intermediate proxies, or at least minimise those changes. A change to PUBLISH with its entirely new syntax, together with the use of things like Path and Service-Route with PUBLISH, would represent substantial changes for those intermediaries. An intermediary would need to behave differently for a PUBLSIH in accordance with this event package (e.g., add a Path header field), compared with a PUBLISH for other event packages. Not very clean
> 
> Finally, I re-iterate that the perceived benefits that the PUBLISH proposal gives are not requirements. A PBX will generally be configured or scripted with rules to apply to requests inbound to one if the AORs it is responsible for, which might include parallel or serial delivery to multiple contacts, eventual forwarding to voicemail, or in some cases outright rejection. This information needs to be in the PBX, so that requests originating in the PBX (or from some other source not arriving via the SSP) can be handled correctly. Requests arriving from the SSP should be handled the same (notwithstanding the fact that the rules concerned might be impacted by the source of the request). The idea is to deliver requests to the domain that is able to handle them, i.e., the PBX, and for the PBX to deal with issues of nomadicity etc., e.g., by redirection if the required contact happens to be off-PBX. The so-called feature of the SSP being able to fork is in my opinion a disadvantage,
>  and results in split responsibility for an AOR, something which surely is contrary to the principles of RFC 3261.
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 12:02:47 -0500

I don't understand this argument.  If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method.  It'll be a Proxy-Require no matter what method name.

-hadriel

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Adam Roach
> Sent: Thursday, January 07, 2010 11:26 AM
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 7 Jan 2010 11:19:47 -0600

> I don't understand this argument.  If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method.  It'll be a Proxy-Require no matter what method name.

I think that's the point Adam is was originally tyring to make--the issue of intermediaries (possibly) needing to know the difference between normal registers and bulk-registers is made no worse by the use of PUBLISH than it would be with REGISTER.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:23:48 -0600

> I don't understand this argument.  If intermediate proxies need to know, they'll need to know whether we use a REGISTER or a PUBLISH method.  It'll be a Proxy-Require no matter what method name.

The key difference is:

    * With REGISTER, intermediaries unaware of this extension will think
      they know what the transaction means, and they will be wrong.

    * With PUBLISH, intermediaries unaware of this extension will either
      correctly know that the transaction is updating state in the
      network (if they understand PUBLISH), or they will simply treat it
      as an unknown transaction type. In both cases, the behavior will
      be correct.

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Jan 2010 11:25:11 -0600

As a participant...

>> I don't understand this argument.  If intermediate proxies need to know, 
>> they'll need to know whether we use a REGISTER or a PUBLISH method. 
>> It'll be a Proxy-Require no matter what method name.
>>
>
> I think that's the point Adam is was originally tyring to make--the issue 
> of intermediaries (possibly) needing to know the difference between normal 
> registers and bulk-registers is made no worse by the use of PUBLISH than 
> it would be with REGISTER.

So, as a reality check ... deployed systems today are using implicit 
registration with no indication that this is happening in the signaling, but 
the fact that this isn't visible to intermediaries today wasn't listed in 
Hadriel's problem statement draft.

Is this an oversight? Is anyone encountering problems with intermediaries in 
deployed systems using implicit registration today?

Thanks,

Spencer

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:27:11 -0600

On 1/7/10 11:25, Jan 7, Spencer Dawkins wrote:
> registration with no indication that this is happening in the 
> signaling, but the fact that this isn't visible to intermediaries 
> today wasn't listed in Hadriel's problem statement draft.
>
> Is this an oversight? Is anyone encountering problems with 
> intermediaries in deployed systems using implicit registration today? 

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Jan 2010 11:37:17 -0600

Hi, Adam,

I'm sorry, I wasn't clear. I was asking if it DOES work in a specific 
architecture :-)

Thanks,

Spencer

>> registration with no indication that this is happening in the signaling, 
>> but the fact that this isn't visible to intermediaries today wasn't 
>> listed in Hadriel's problem statement draft.
>>
>> Is this an oversight? Is anyone encountering problems with intermediaries 
>> in deployed systems using implicit registration today?
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 11:40:51 -0600

> I'm sorry, I wasn't clear. I was asking if it DOES work in a specific 

Ah, okay. In that case, I'd reiterate pointing out the sipchange 
prohibition against point solutions.

/a

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 18:42:01 +0100

Ben,

> From: Ben Campbell [mailto:[email-masked]] 
> Sent: 07 January 2010 17:00
> To: Elwell, John
> Cc: Adam Roach; [email-masked]
> Do you consider the use of REGISTER to be a _requirement_ for 
> this effort? That seems like the direction people are going, 
> but I'm not comfortable with the solution choice being a requirement.
[JRE] Personally I would say it is a requirement, but it would be difficult to convince everybody. So in that case it is a question of showing that REGISTER is as good a solution as any.

> 
> I'm not sure I buy the idea that a non-REGISTER solution is 
> necessarily that much harder to deploy. Face it, even if we 
> end up with a REGISTER approach, it's going to be somewhere 
> between subtly different and very different than the approach 
> taken by any particular existing implementation. At _best_, a 
> small number of implementations luck out in that their 
> variation gets chosen.
> 
> It's my experience that implementors will be no more willing 
> to make small changes than to make bigger ones. Touching 
> anything is the expensive part, everything else is just work.
> 
> Also, I don't see how it is any harder for an intermediary 
> device to recognize it needs to take certain actions with a 
> PUBLISH request with a certain event header value than it is 
> to recognize it needs to take certain actions with REGISTER 
> based on a proxy-require, require, or (heaven-forbid) 
> implicit knowledge of some magic AoR.
[JRE] Nobody has convinced me that an intermediary needs to take special action beyond what it would do with REGISTER anyway, so the use of Proxy-Require or whatever should not be necessary.

> 
> Adam is correct that bulk register changes the semantics of 
> REGISTER. The semantic of REGISTER is to bind one or more 
> contacts to a single AoR. PUBLISH OTOH, was designed with the 
> idea of pushing arbitrary, but well-defined, state into the 
> network. Bulk-register seems a lot more like the latter than 
> the former.
[JRE] I don't think binding a contact to multiple AORs is a big leap from binding a contact to a single AOR.

> 
> Full discloser: If I had my druthers, I'd deprecate REGISTER 
> _entirely_, and replace it with PUBLISH for reg-event or some 
> similar package. REGISTER is broken even when used according 
> to 3261 (overloaded use of To, From, and r-URI, 
> pseudo-dialogs, poor concurrency properties, etc.) We 
> certainly should not be defining _new_ uses of it.
[JRE] Yes, perhaps REGISTER is broken anyway, but it is still a fundamental part of SIP. I believe we can easily fix it to accomplish the present task.

John

> > Sure you could specify the use of Path and Service-Route 
> with PUBLISH, but that is yet another aspect for the entities 
> concerned to support. We seem to be getting further and 
> further from the objective of fixing the problem that exists 
> in the field today: lots of implementations based around 
> REGISTER (+ Path etc.), but differing in details such that 
> interoperability is impaired. We need to nail down the 
> details so that, with relatively minor changes to the 
> entities involved, interoperability can be achieved. The more 
> major the changes, the longer it will take for vendors to 
> implement, and in fact the less likely it will be that 
> vendors do implement.
> > 
> > Furthermore, a simple nailing down of details of how the 
> REGISTER-based mechanism works might even avoid changes to 
> intermediate proxies, or at least minimise those changes. A 
> change to PUBLISH with its entirely new syntax, together with 
> the use of things like Path and Service-Route with PUBLISH, 
> would represent substantial changes for those intermediaries. 
> An intermediary would need to behave differently for a 
> PUBLSIH in accordance with this event package (e.g., add a 
> Path header field), compared with a PUBLISH for other event 
> packages. Not very clean
> > 
> > Finally, I re-iterate that the perceived benefits that the 
> PUBLISH proposal gives are not requirements. A PBX will 
> generally be configured or scripted with rules to apply to 
> requests inbound to one if the AORs it is responsible for, 
> which might include parallel or serial delivery to multiple 
> contacts, eventual forwarding to voicemail, or in some cases 
> outright rejection. This information needs to be in the PBX, 
> so that requests originating in the PBX (or from some other 
> source not arriving via the SSP) can be handled correctly. 
> Requests arriving from the SSP should be handled the same 
> (notwithstanding the fact that the rules concerned might be 
> impacted by the source of the request). The idea is to 
> deliver requests to the domain that is able to handle them, 
> i.e., the PBX, and for the PBX to deal with issues of 
> nomadicity etc., e.g., by redirection if the required contact 
> happens to be off-PBX. The so-called feature of the SSP being 
> able to fork is in my opinion a disadvantage,
> >  and results in split responsibility for an AOR, something 
> which surely is contrary to the principles of RFC 3261.
> > 
> > Note that the multiple registrations capability in the 
> shaken-implicit draft is intended for resilience purposes, 
> not for being able to register different contacts for different AORs.
> > 
> > John
> >

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 07 Jan 2010 12:49:47 -0500

> [JRE] I don't think binding a contact to multiple AORs is a big leap from binding a contact to a single AOR.

To an extent I agree with John here.
IMO the implicit registration that IMS is doing is a larger violation of 
the semantics of REGISTER. But nobody ever asked if that was ok, and now 
it seems that everyone considers it to be grandfathered in even though 
there no IETF spec defining it.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Thu, 7 Jan 2010 18:58:47 +0100

> De : Adam Roach [mailto:[email-masked]] 
> Envoyé : jeudi 7 janvier 2010 17:43
> À : CHATRAS Bruno RD-CORE-ISS
> Cc : [email-masked]; [email-masked]
> Consider the case in which the intermediary is making policy 
> decisions based on the user being registered. If it uses the 
> RFC 3261 definition of REGISTER, then it knows that the user 
> under discussion is the user indicated in the "To" header 
> field, and that policies should be applied accordingly.
> 
> Once we change the semantics of REGISTER so that the user -- 
> or users -- under discussion no longer appear in the "To" 
> header field, then this intermediary will be relying on 
> incorrect information for its policies.
==>BC: I don't see any concrete issue here. Policy decisions made by an intermediary would typically depend on the SLA between the SIP Service Provider and the enterprise (hence the identity in the To header of the REGISTER request) rather than on individual enterprise members.

> 
> 
> > Is there a fundamental difference between a small PBX and a 
> SIP-aware Home/Residential Gateway serving a couple of 
> lines/numbers/users in one house? Or would you also argue 
> that such a HGW should also use the PUBLISH method?
> >    
> 
> I would argue that a small home gateway servicing two users 
> would generally maintain two independent registrations using 
> the REGISTER method.
> 
> However, if they wanted to consolidate these into a single 
> operation, then yes, the idea is that the unified way to 
> update rendezvous information for multiple users would be 
> using PUBLISH.
==>BC: I believe a Home Gateway conforming to the Home Gateway Initiative specifications would use a REGISTER message in all cases.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 12:00:59 -0600

On 1/7/10 11:58, Jan 7, [email-masked] wrote:
>>> I'm not sure I understand why using REGISTER for the PBX
>>>        
>> case is fundamentally broken.
>>

For the specific architecture you have in mind, yes. I'm concerned about 
the broader picture.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Jan 2010 19:04:54 +0100

At the point we are talking about, any policy decisions should be on the PBX operator as a whole - applying them to individual users on the PBX is fundamentally broken. If nothing else because you are going to get outgoing calls appearing across this interface that are not normally hosted on this interface where one has a network of PBXs routing internally before sending to the public network.

regards

Keith 

> Sent: Thursday, January 07, 2010 4:43 PM
> To: [email-masked]
> Cc: [email-masked]

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 7 Jan 2010 13:15:04 -0500

Below ..

>  from binding a contact to a single AOR.

Right ..

>  IMO the implicit registration that IMS is doing is a larger violation
>  of the semantics of REGISTER. But nobody ever asked if that was ok, and
>  now it seems that everyone considers it to be grandfathered in even
though
>  there no IETF spec defining it.

Paul that is a reasonable summary of how we got here.  It slipped through
several layers of cracks in the IETF and 3GPP process.  It's there in the
field, in large deployments and pretty well entrenched especially in smaller
systems.  The preference of some of us is to make the technique a bit more
defined in order to deal with some of the interoperability issues its
caused.

IMO trying to define an entirely new registration procedure using PUBLISH
could cause serious disruption in the market place and may not even be
adopted due the existing grandfathered base. 

Sure ..there is a reasonable technical case for using a PUBLISH methodology
for this class of AOR registration but the business case for using REGISTER
with a option tag is overwhelming.

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 12:26:27 -0600

> with a option tag is overwhelming.

So, you're pretty much saying that we should have chartered as 
"Retroactively Updating Bygones By Extending REGISTER So That 
Architectures gEt Pulverized", or "RUBBERSTAMP"?

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 12:29:52 -0600

On 1/7/10 10:47, Jan 7, Alan Johnston wrote:

> What kinds of sensible things could an intermediary proxy do with such 
> a REGISTER? And what problems would this cause?
>

Yes, for the large part, the architectures people are _currently_ 
looking at will be limited to these two situations. And, for those 
architectures, your assertion holds.

Here's the issue I have: SIP is designed to be an extensible, flexible 
protocol that can be used for arbitrary architectures. That design is 
intended to foster innovation, instead of locking down the network 
architecture into a small set of blessed configurations.

If we take actions that preclude certain architectures -- even if we 
can't design those architectures right now -- then we limit SIP's 
flexibility. We constrain innovation.

Certainly we're not hubristic enough to think that we can predict all 
possible useful architectures. But we can at least identify where 
inherent aspects of the protocol are being modified, and avoid doing 
them in an incompatible fashion.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 13:38:26 -0500

> Of Spencer Dawkins
> Sent: Thursday, January 07, 2010 12:25 PM
> 
> but

Umm, yes I did.  The lack of an explicit indication is listed in the doc, as is the issue that intermediaries need one.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 13:41:37 -0500

________________________________
From: Adam Roach [mailto:[email-masked]]
Sent: Thursday, January 07, 2010 12:24 PM
To: Hadriel Kaplan
Cc: Richard Shockey; [email-masked]
Subject: Re: [martini] draft-roach-martini-up-00

The key difference is:

 *   With REGISTER, intermediaries unaware of this extension will think they know what the transaction means, and they will be wrong.
No they won't.  Draft shaken and stirred both ask for a new option-tag.  Right now they only mention putting them in the Require, but if the WG decides it's necessary in Proxy-Require too that's not exactly a big leap.

 *   With PUBLISH, intermediaries unaware of this extension will either correctly know that the transaction is updating state in the network (if they understand PUBLISH), or they will simply treat it as an unknown transaction type. In both cases, the behavior will be correct.
If I'm a "proxy" today with specific policies tied around Registrations, I don't necessarily need to understand anything special about PUBLISH today.  So just using the PUBLISH method does not automagically work.  We'll need a proxy-require.

---

From: "Spencer Dawkins" <[email-masked]>
Date: Thu, 7 Jan 2010 12:42:34 -0600

Hi, Hadriel,

Sorry I missed it! I apparently jumped from the first paragraph to the third 
paragraph in 4.1 of the problem statement. The second paragraph answered my 
question.

And thanks for pointing it out.

Spencer

----- Original Message ----- 
From: "Hadriel Kaplan" <[email-masked]>
To: "Spencer Dawkins" <[email-masked]>; "Ben Campbell" 
<[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, January 07, 2010 12:38 PM
Subject: RE: [martini] draft-roach-martini-up-00

> Hadriel's problem statement draft.

Umm, yes I did.  The lack of an explicit indication is listed in the doc, as 
is the issue that intermediaries need one.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Jan 2010 19:47:14 +0100

That will also be one of my questions on the call.

IMS has been using implicit registration since 2002. No one has identified any interoperability issues in the fora I attend with this.

So I would like some specifics as to what interoperability issues the use of implicit registration is understood to cause, becuase it does not seem to be in the drafts.

Keith 

> [mailto:[email-masked]] On Behalf Of Spencer Dawkins
> Sent: Thursday, January 07, 2010 5:25 PM
> To: Ben Campbell; Hadriel Kaplan
> Cc: [email-masked]
> >> I don't understand this argument.  If intermediate proxies need to 
> >> know, they'll need to know whether we use a REGISTER or a 
> PUBLISH method.
> > I think that's the point Adam is was originally tyring to make--the 
> > issue of intermediaries (possibly) needing to know the difference 
> > between normal registers and bulk-registers is made no worse by the 
> > use of PUBLISH than it would be with REGISTER.
> 
> So, as a reality check ... deployed systems today are using 
> implicit registration with no indication that this is 
> happening in the signaling, but the fact that this isn't 
> visible to intermediaries today wasn't listed in Hadriel's 
> problem statement draft.
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 12:49:51 -0600

On 1/7/10 12:41, Jan 7, Hadriel Kaplan wrote:
>
> ------------------------------------------------------------------------
>
> *From:* Adam Roach [mailto:[email-masked]]
> *Sent:* Thursday, January 07, 2010 12:24 PM
> *To:* Hadriel Kaplan
> *Cc:* Richard Shockey; [email-masked]
> *Subject:* Re: [martini] draft-roach-martini-up-00
>
>     * With REGISTER, intermediaries unaware of this extension will
>       think they know what the transaction means, and they will be wrong.
>
> No they won't.  Draft shaken and stirred both ask for a new 
> option-tag.  Right now they only mention putting them in the Require, 
> but if the WG decides it's necessary in Proxy-Require too that's not 
> exactly a big leap.
>

Honestly, a Proxy-Require would solve this problem from my perspective. 
And, now that I think about it more, it's not as bad a decision as it 
usually would be, since REGISTER isn't going end-to-end. One can 
reasonably expect this to work (unlike, say, 'Proxy-Require' in an INVITE).

>     * With PUBLISH, intermediaries unaware of this extension will
>       either correctly know that the transaction is updating state in
>       the network (if they understand PUBLISH), or they will simply
>       treat it as an unknown transaction type. In both cases, the
>       behavior will be correct.
>
> If I'm a "proxy" today with specific policies tied around 
> Registrations, I don't necessarily need to understand anything special 
> about PUBLISH today.  So just using the PUBLISH method does not 
> automagically work.  We'll need a proxy-require.
>

I'm not claiming it will automagically work with PUBLISH -- only that 
proxies will merely not take action (versus taking a potentially 
incorrect action) when such PUBLISH messages traverse them.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 13:56:04 -0500

I don't understand why you think using a REGISTER transaction makes it any more or less architecture-specific than a PUBLISH one.  

No matter what, we're talking about providing reachability information for a group of AoR's, and the routing rules associated with that provided information.  We already have a means of providing reachability information (Path), subsequent request routes (Service-Route), and NAT traversal (outbound) through a REGISTER transaction, just not for multiple AoR's.  We can either update REGISTER to handle that latter issue, or modify PUBLISH to handle the former issues.  The advantages of using a REGISTER are fairly obvious I would think:
	1) People already use them for this purpose today.
	2) We *are* actually registering something.
	3) My guess is it's less code changes.  I know that's not an objective condition, but I bet it's true.  Just imagine the features people have for controlling REGISTER storms, using them as keepalives, tying their state to policies, counting them and providing their stats, etc.  Heck, I bet it's even easier for test equipment, since I know some of them have specific mechanisms for REGISTER generation that wouldn't need to change to test this thing.

-hadriel

> Sent: Thursday, January 07, 2010 12:27 PM
> To: Spencer Dawkins
> Cc: Ben Campbell; Hadriel Kaplan; [email-masked]

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 7 Jan 2010 14:04:55 -0500

Actually, my mixing-draft issues were based on both IMS and non-IMS real-world deployment experiences.  I know it's a myopic view since it's just my list (it is only an individual draft after all - no one else posted one though).  I don't know of any interoperability issues forum for IMS deployments.  I only know what I see from TAC tickets, enhancement requests, manipulation rules to fix it, etc.  

-hadriel

> From: DRAGE, Keith (Keith) [mailto:[email-masked]]
> Sent: Thursday, January 07, 2010 1:47 PM
> To: Spencer Dawkins; Ben Campbell; Hadriel Kaplan
> Cc: [email-masked]
> IMS has been using implicit registration since 2002. No one has identified
> any interoperability issues in the fora I attend with this.
> 
> So I would like some specifics as to what interoperability issues the use
> of implicit registration is understood to cause, becuase it does not seem
> to be in the drafts.
> 
> Keith
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 16:23:05 -0600

> I don't understand why you think using a REGISTER transaction makes it any more or less architecture-specific than a PUBLISH one.

That's not what I'm saying. There's been a lot of back-and-forth on this 
topic that amounts to the same exchange over and over (not just with 
you; with several parties). I'm going to replay the dialog in simplified 
form, because I think something is getting lost with the flood of email 
messages:

A: "Changing REGISTER in this way can break intermediaries."
B: "But in the architecture MARTINI is considering, it breaks nothing."
A: "The fact that it works in one place does not mean it works everywhere."

Changing the established meaning of REGISTER can cause problems unless 
all parties to the transaction understand the changes. The fact that no 
such problem arises in one specific architecture seems to be held out as 
proof that it must work everywhere. Which is the logical equivalent to: 
"this particular swan is white, therefore all swans must be white." (cf 
http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inference)

What I'm proposing with PUBLISH isn't a change to established semantics. 
In fact, it aligns precisely with established semantics: as I said on 
the phone, the basic concept of using PUBLISH to update a Location 
Service database could be a BCP, since it requires no new protocol 
mechanism. Nothing breaks, since the meaning of everything remains the same.

Everything else I've proposed so far is properly negotiated SIP protocol 
extensions using established extension mechanisms. You could do the same 
thing with REGISTER, if you really wanted to, by using both Require and 
Proxy-Require.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 7 Jan 2010 23:39:17 +0100

Hi,

I think one of the reason we go over the same thing over and over is because we don't have a common view on the "user" concept.

Adam talks about multiple users, and that using a single REGISTER for those breaks things. Keith (and maybe others) seems to be arguing that we are still talking about a SINGLE SIP user. What happens inside the PBX is irrelevant. The PBX users have a relation with the PBX - the PBX has a relation with the SIP network.

So, from Keith's perspective things would not be broken, and intermediates in the SIP network do not (at least not by default) need to be aware of individual users behind the PBX.

But, I may have missunderstood, and in that case I appologize :)

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 8. tammikuuta 2010 0:23
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] draft-roach-martini-up-00

> I don't understand why you think using a REGISTER transaction makes it any more or less architecture-specific than a PUBLISH one.

That's not what I'm saying. There's been a lot of back-and-forth on this topic that amounts to the same exchange over and over (not just with you; with several parties). I'm going to replay the dialog in simplified form, because I think something is getting lost with the flood of email
messages:

Changing the established meaning of REGISTER can cause problems unless all parties to the transaction understand the changes. The fact that no such problem arises in one specific architecture seems to be held out as proof that it must work everywhere. Which is the logical equivalent to: 
"this particular swan is white, therefore all swans must be white." (cf
http://en.wikipedia.org/wiki/Falsifiability#Inductive_categorical_inference)

What I'm proposing with PUBLISH isn't a change to established semantics. 
In fact, it aligns precisely with established semantics: as I said on the phone, the basic concept of using PUBLISH to update a Location Service database could be a BCP, since it requires no new protocol mechanism. Nothing breaks, since the meaning of everything remains the same.

Everything else I've proposed so far is properly negotiated SIP protocol extensions using established extension mechanisms. You could do the same thing with REGISTER, if you really wanted to, by using both Require and Proxy-Require.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 07 Jan 2010 16:48:36 -0600

You're spot on in describing the differences in perspectives. I think it 
comes down to whether you see an application for SIP outside of IMS 
architectures.

In IMS-derived architectures, you can make the assumptions Keith has. In 
the general case, I don't think they hold.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 8 Jan 2010 00:01:24 +0100

Hi, 

>You're spot on in describing the differences in perspectives. I think it comes down to whether you see an application for SIP outside of IMS architectures.
>
>In IMS-derived architectures, you can make the assumptions Keith has. In the general case, I don't think they hold.

Well, that is what we need to decide, before discussing SIP methods and protocol details :)

Regards,

Christer

On 1/7/10 16:39, Jan 7, Christer Holmberg wrote:
> Behalf Of Adam Roach
> That's not what I'm saying. There's been a lot of back-and-forth on 
> this topic that amounts to the same exchange over and over (not just 
> with you; with several parties). I'm going to replay the dialog in 
> simplified form, because I think something is getting lost with the 
> flood of email
> messages:
>

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 8 Jan 2010 11:28:47 +0100

I think Christer's summary is good. The architecture that Keith and others are talking about is applicable outside IMS too - that is what the SIP Forum is trying to achieve with SIPconnect - a means for a PBX to register. This was probably a lot clearer with the earlier domain registration draft ("stirred"), but it is still the same principle with the current implicit registration draft ("shaken").

John

> Sent: 07 January 2010 22:49
> To: Christer Holmberg
> Cc: [email-masked]; Hadriel Kaplan
> > I think one of the reason we go over the same thing over 
> and over is because we don't have a common view on the "user" concept.
> >
> > Adam talks about multiple users, and that using a single 
> REGISTER for those breaks things. Keith (and maybe others) 
> seems to be arguing that we are still talking about a SINGLE 
> SIP user. What happens inside the PBX is irrelevant. The PBX 
> users have a relation with the PBX - the PBX has a relation 
> with the SIP network.
> >
> > So, from Keith's perspective things would not be broken, 
> and intermediates in the SIP network do not (at least not by 
> default) need to be aware of individual users behind the PBX.
> >
> >> I don't understand why you think using a REGISTER 
> transaction makes it any more or less architecture-specific 
> than a PUBLISH one.
> >>
> >>      
> > That's not what I'm saying. There's been a lot of 
> back-and-forth on this topic that amounts to the same 
> exchange over and over (not just with you; with several 
> parties). I'm going to replay the dialog in simplified form, 
> because I think something is getting lost with the flood of email
> > messages:
> >
> > Changing the established meaning of REGISTER can cause 
> problems unless all parties to the transaction understand the 
> changes. The fact that no such problem arises in one specific 
> architecture seems to be held out as proof that it must work 
> everywhere. Which is the logical equivalent to:
> > In fact, it aligns precisely with established semantics: as 
> I said on the phone, the basic concept of using PUBLISH to 
> update a Location Service database could be a BCP, since it 
> requires no new protocol mechanism. Nothing breaks, since the 
> meaning of everything remains the same.
> >
> > Everything else I've proposed so far is properly negotiated 
> SIP protocol extensions using established extension 
> mechanisms. You could do the same thing with REGISTER, if you 
> really wanted to, by using both Require and Proxy-Require.
> >
> > /a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 09:18:15 -0500

> Sent: Thursday, January 07, 2010 5:23 PM
> 

Right, and you and I are in agreement on that point.

> thing with REGISTER, if you really wanted to, by using both Require and

Right, and my point was that PUBLISH would need a Require/Proxy-Require too.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 08:51:35 -0600

> Right, and my point was that PUBLISH would need a Require/Proxy-Require too.

I don't think it does, because we're not changing the semantics of PUBLISH.

I believe that the only need for option-tags at all is for the Path and 
Service-Route handling, and we simply copy that behavior from RFCs 3327 
and 3608.

/a

---

From: Alan Johnston <[email-masked]>
Date: Fri, 08 Jan 2010 08:52:24 -0600

Adam,

You missed my point.

My point was that an intermediary "proxy" should not try to infer any 
semantics from a REGISTER - not that one can not imagine an architecture 
where this could break things.    The REGISTER method is between the UA 
and the Registrar, and I don't recall anything in Section 16 of RFC 3261 
behavior (which defines a SIP proxy) that is REGISTER specific.

If this "proxy" is trying to infer semantics from a REGISTER, then it is 
effectively no longer a proxy (per RFC 3261) but instead is acting a 
Registrar.  If so, then, it must understand the option tag in order to 
infer correct semantics from the REGISTER.

In some of your other posts, you seem to be arguing that we should not 
and can not make any changes to a method semantics since this might 
break intermediaries.  However, we have done this in the past - take 
everyone's favorite method REFER.  With RFC 4488, we used a header field 
and option tag to indicate that there will be no NOTIFY to the REFER.  
This could potentially break an intermediary which sees the REFER, only 
understands RFC 3515 which defines REFER, and expects to see NOTIFYs.  
However, again, this is another case where an intermediary is trying to 
infer semantics from a method, and as such, it is effectively no longer 
a proxy and is now behaving like a UA and must understand things like 
option tags, etc.

- Alan -

Adam Roach wrote:
>> What kinds of sensible things could an intermediary proxy do with 
>> such a REGISTER? And what problems would this cause?
>>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 09:58:35 -0500

Yeah this is why the stirred/shaken drafts only have an option-tag in Require right now.
-hadriel

> Of Alan Johnston
> Sent: Friday, January 08, 2010 9:52 AM
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 10:02:50 -0500

> I don't think it does, because we're not changing the semantics of PUBLISH.

You're not changing the semantics of the PUBLISH, because it has almost no semantics to begin with.  Everything "important/unique" about it is tied to the event package name and body.  So you need a Req/P-Req to say "you must understand this event package to process this PUBLISH".

In other words, if the argument against using REGISTER without a Req/P-Req is "but that breaks things that expected REGISTER to work differently", then presumably those things need to understand this specific PUBLISH usage too for whatever reasons they needed to understand REGISTER semantics.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 09:16:15 -0600

On 1/8/10 8:52 AM, Alan Johnston wrote:
> semantics from a REGISTER - not that one can not imagine an 
> architecture where this could break things.    The REGISTER method is 
> between the UA and the Registrar, and I don't recall anything in 
> Section 16 of RFC 3261 behavior (which defines a SIP proxy) that is 
> REGISTER specific.
>
> If this "proxy" is trying to infer semantics from a REGISTER, then it 
> is effectively no longer a proxy (per RFC 3261) but instead is acting 
> a Registrar.  If so, then, it must understand the option tag in order 
> to infer correct semantics from the REGISTER.

Ideally, this would all be true. In practice, with the introduction of 
the Service-Route and Path mechanisms, we have invited proxies into the 
REGISTER transaction. And, for better or for worse, those particular 
cats are both well out of the bag and marking the furniture.

> everyone's favorite method REFER.  With RFC 4488, we used a header 
> field and option tag to indicate that there will be no NOTIFY to the 
> REFER.  This could potentially break an intermediary which sees the 
> REFER, only understands RFC 3515 which defines REFER, and expects to 
> see NOTIFYs.  However, again, this is another case where an 
> intermediary is trying to infer semantics from a method, and as such, 
> it is effectively no longer a proxy and is now behaving like a UA and 
> must understand things like option tags, etc.

The situation is somewhat different, in several important aspects. REFER 
is certainly not as fundamental to SIP as REGISTER is; and the change 
you're talking about was implemented to address a flaw in the original 
design of REFER. The consequence of intermediaries misinterpreting the 
new kind of REFER as the old kind was simply a timeout situation (which 
they would have code for), not potentially incorrect policy decisions. 
So, while there are some parallels, the key details are different.

Finally, note that including a "Proxy-Require" in a request that has to 
travel across multiple domains of control -- like REFER -- is pretty 
much a guarantee that it won't ever work. Including it in something that 
is all within the same realm of control (e.g., that shared by an SSP and 
its customers) is far more tractable. So adding it to REFER would have 
been a poison pill. Adding it to REGISTER is simply prophylactic.

But I agree with your analysis that the change to REFER that you cite 
has the potential to break intermediaries. It was chosen as a "least 
evil" compromise path.

/a

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 09:18:27 -0600

On 1/8/10 9:02 AM, Hadriel Kaplan wrote:
>>> Right, and my point was that PUBLISH would need a Require/Proxy-Require
>>>        
>> too.
>>

But that's true of every PUBLISH. It's inherent in the very definition 
of the PUBLISH method. To process any PUBLISH, you must understand the 
event package. There are several event packages, many of which are used 
with PUBLISH, and none of which make use of option tags.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 11:34:21 -0500

> Sent: Friday, January 08, 2010 10:18 AM
> To: Hadriel Kaplan
> >>
> > You're not changing the semantics of the PUBLISH, because it has almost
> no semantics to begin with.  Everything "important/unique" about it is
> tied to the event package name and body.  So you need a Req/P-Req to say
> "you must understand this event package to process this PUBLISH".
> >
> 

Sure, but I was talking about for the case of the "intermediary" proxy-ish devices you were concerned about - i.e., devices which shall not be named.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 08 Jan 2010 10:45:21 -0600

> Sure, but I was talking about for the case of the "intermediary" proxy-ish devices you were concerned about - i.e., devices which shall not be named.

We're talking about different things.

I'm talking about the behavior of intermediaries who don't have the 
first foggy clue about any of the extensions that come out of MARTINI, 
and who don't need to. When they see this NOTIFY, they have no chance of 
doing the wrong thing -- hence no backwards-compatibility issues.

You're talking about the things that are hip-deep in this mess, and need 
to do MARTINI-ish things to work. And for them, all that's necessary is 
the ability to recognize what's going on. The combination of "PUBLISH" 
and "Event: reg" gets you 100% of the way there.

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Fri, 8 Jan 2010 13:24:25 -0500

Hi Hadriel / John / David,
 
   Regarding the martini-shaken-implicit-registrations draft, currently
the draft has the following requirement regarding support of
P-Associated-URI:
 
 The Registrar SHOULD indicate all of the implicitly Registered AoRs in
a P-Associated-URI header field(s) in the 200 response to the REGISTER,
if it supports [RFC3455].  [OPEN ISSUE: should we mandate PAU support?
Should we document a legal/compliant means of indicating AoR username
"wildcards"?] 

    As worded, this is a conditional SHOULD requirement (conditional on
whether RFC 3455 is supported by the Registrar), but there is a question
about whether PAU should be mandated.
 
   My suggestion would be to remove this requirement altogether:

*	PAU is not widely utilized outside of IMS and hence is likely
not part of most currently deployed SIP PBX registration-based solutions
today
*	There haven't been any proposed requirements tabled to date that
would drive inclusion of this
*	In a very early draft of SIP Connect 1.1 ( > 1.5 years ago),
there was a suggestion of making this optional, but I believe none of
the enterprise vendors ever saw any strong value case for doing anything
with the header, hence it was promptly removed and never re-surfaced as
a requirement in subsequent drafts of the spec
*	There are diffferences between RFC 3455 definitions of PAU and
IMS usage of the header that would need to be resolved in the draft
*	The assigned numbers for the SIP PBX already need to be
communicated via other means oout of scope of the draft
*	There are other technical issues/considerations that would be
resolved/considered if it was included, as articulated in Hadriel's
summary slide package of the draft

     Making mandatory would raise a large number of questions and
considerations, and the potential for implementing something in the
network that would never be used by recipiants. It would seem prudent to
simply remove from the draft altogether at this point.
 
    Thanks
        Brian

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 8 Jan 2010 13:30:13 -0500

Fine by me.
I was thinking about this some as well, that if a PBX really did want this info (for example for troubleshooting or whatever), it could get it from a reg-event subscription if it supported that. (though I don't think I've ever seen a registering PBX subscribe for reg-event)
-hadriel

________________________________
From: Brian Lindsay [mailto:[email-masked]]
Sent: Friday, January 08, 2010 1:24 PM
To: Hadriel Kaplan; Elwell, John; David Hancock
Cc: [email-masked]
Subject: martini-shaken-implicit-registrations : propose P-Associated-URI be removed

   Regarding the martini-shaken-implicit-registrations draft, currently the draft has the following requirement regarding support of P-Associated-URI:

 The Registrar SHOULD indicate all of the implicitly Registered AoRs in a P-Associated-URI header field(s) in the 200 response to the REGISTER, if it supports [RFC3455].  [OPEN ISSUE: should we mandate PAU support?  Should we document a legal/compliant means of indicating AoR username "wildcards"?]
    As worded, this is a conditional SHOULD requirement (conditional on whether RFC 3455 is supported by the Registrar), but there is a question about whether PAU should be mandated.

 *   PAU is not widely utilized outside of IMS and hence is likely not part of most currently deployed SIP PBX registration-based solutions today
 *   There haven't been any proposed requirements tabled to date that would drive inclusion of this
 *   In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there was a suggestion of making this optional, but I believe none of the enterprise vendors ever saw any strong value case for doing anything with the header, hence it was promptly removed and never re-surfaced as a requirement in subsequent drafts of the spec
 *   There are diffferences between RFC 3455 definitions of PAU and IMS usage of the header that would need to be resolved in the draft
 *   The assigned numbers for the SIP PBX already need to be communicated via other means oout of scope of the draft
 *   There are other technical issues/considerations that would be resolved/considered if it was included, as articulated in Hadriel's summary slide package of the draft
     Making mandatory would raise a large number of questions and considerations, and the potential for implementing something in the network that would never be used by recipiants. It would seem prudent to simply remove from the draft altogether at this point.

    Thanks
        Brian

---

From: "Middleton, David (NSN - US/Boca Raton)" <[email-masked]>
Date: Fri, 8 Jan 2010 12:42:22 -0600

The statement ...

> We already have a 
> means of providing reachability information (Path), 
> subsequent request routes (Service-Route), and NAT traversal 
> (outbound) through a REGISTER transaction

... speaks volumes with respect to the capabilities that are built
around REGISTER and the work that would be needed to use PUBLISH for
reachability information.  Redoing all of this (and future
REGISTER-oriented enhancements) for PUBLISH does not make sense.

Some security appliances (e.g. SBCs) protect the SP core by not allowing
requests through from unregistered UAs.  Applying security policies
selectively based on the type of the PUBLISH is very expensive since the
message must be parsed to the point of learning whether it is for
reachability information or not.  Opening the door to all PUBLISH
messages would be very undesirable.  Either way, it makes protection
against DoS attacks more difficult.

David

> [mailto:[email-masked]] On Behalf Of ext Hadriel Kaplan
> Sent: Thursday, January 07, 2010 1:56 PM
> To: Adam Roach; Spencer Dawkins
> Cc: [email-masked]
> I don't understand why you think using a REGISTER transaction 
> makes it any more or less architecture-specific than a PUBLISH one.  
> 
> No matter what, we're talking about providing reachability 
> information for a group of AoR's, and the routing rules 
> associated with that provided information.  We already have a 
> means of providing reachability information (Path), 
> subsequent request routes (Service-Route), and NAT traversal 
> (outbound) through a REGISTER transaction, just not for 
> multiple AoR's.  We can either update REGISTER to handle that 
> latter issue, or modify PUBLISH to handle the former issues.  
> The advantages of using a REGISTER are fairly obvious I would think:
> 	3) My guess is it's less code changes.  I know that's 
> not an objective condition, but I bet it's true.  Just 
> imagine the features people have for controlling REGISTER 
> storms, using them as keepalives, tying their state to 
> policies, counting them and providing their stats, etc.  
> Heck, I bet it's even easier for test equipment, since I know 
> some of them have specific mechanisms for REGISTER generation 
> that wouldn't need to change to test this thing.
> 
> -hadriel
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 13:43:26 -0500

I agree. This info can be learned more reliably using the reg event 
package. The PBX is probably going to want that anyway.

	Thanks,
	Paul

Brian Lindsay wrote:
>     * PAU is not widely utilized outside of IMS and hence is likely not
>       part of most currently deployed SIP PBX
>       registration-based solutions today
>     * In a very early draft of SIP Connect 1.1 ( > 1.5 years ago), there
>       was a suggestion of making this optional, but I believe none of
>       the enterprise vendors ever saw any strong value case for doing
>       anything with the header, hence it was promptly removed and never
>       re-surfaced as a requirement in subsequent drafts of the spec
>     * There are diffferences between RFC 3455 definitions of PAU and IMS
>       usage of the header that would need to be resolved in the draft
>       resolved/considered if it was included, as articulated in
>       Hadriel's summary slide package of the draft
>

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 8 Jan 2010 10:51:25 -0800

+1.  

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Friday, January 08, 2010 10:43 AM
To: Brian Lindsay
Cc: David Hancock; Hadriel Kaplan; [email-masked]
Subject: Re: [martini] martini-shaken-implicit-registrations : propose
P-Associated-URI be removed

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 8 Jan 2010 15:29:46 -0500

+1 

>  Behalf Of Bernard Aboba
>  Sent: Friday, January 08, 2010 1:51 PM
>  To: 'Paul Kyzivat'; 'Brian Lindsay'
>  Cc: 'Hadriel Kaplan'; 'David Hancock'; [email-masked]
>  not
>  there
>  IMS

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 16:19:24 -0500

> cats are both well out of the bag and marking the furniture.

Yes. IMS is the poster child here. The P-CSCF and I-CSCF are heavily 
coupled to REGISTER. They typically are B2BUAs rather than proxies I 
think, but they try to pretend to be proxy-like.

In any case, everybody and his brother seem to think that intermediate 
devices should be able to make decisions about who can and can't receive 
traffic based on whether they are registered or not. IMO that is a 
terrible concept, but still it is there.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 16:20:19 -0500

> I think Christer's summary is good. The architecture that Keith and others are talking about is applicable outside IMS too - that is what the SIP Forum is trying to achieve with SIPconnect - a mean…

Yes, it is certainly an approach that has popularity beyond IMS.

	Thanks,
	Paul

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 01:19:28 +0100

At the moment, from the IMS perspective, both mechanisms are there and can be used FOR THE APPROPRIATE PURPOSE. From the IMS perspective, the only mechanism which will tell you which URIs are currently registered is reg-event.

Because IMS always works in association with authentication, if URIs are deregistered, then other things are going to stop working as well, so for example outgoing requests from a deregistered URI may well not work. Also note that because the implicit registration set is a whole, it is unlikely individual URIs from the implicit registration set will disappear. You will either lose them all or none of them. Because of this I can envisage that a perfectly workable solution uses neither of these mechanisms.

Note that IMS does intend that certain reg event values do cause the UA to recognise a failure and initiate a reregistration. In the absence of this, the interconnect will be broken in both directions, because the IMS has taken away its support for those URIs at that point.

How many registrars outside IMS support reg event? Is it common?

I would note also that none of John's current list of requirements needs such a mechanism at all. So if people see the need for any such mechanism to be mandated, they need to start exploring what the requirements would be.

regards

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Brian Lindsay
Sent: Friday, January 08, 2010 6:24 PM
To: Hadriel Kaplan; Elwell, John; David Hancock
Cc: [email-masked]
Subject: [martini] martini-shaken-implicit-registrations : propose P-Associated-URI be removed

    Thanks
        Brian

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 19:38:36 -0500

DRAGE, Keith (Keith) wrote:
> At the moment, from the IMS perspective, both mechanisms are there and 
> can be used FOR THE APPROPRIATE PURPOSE. From the IMS perspective, the 
> only mechanism which will tell you which URIs are currently registered 
> is reg-event.
>  
> Because IMS always works in association with authentication, if URIs are 
> deregistered, then other things are going to stop working as well, so 
> for example outgoing requests from a deregistered URI may well not work. 
> Also note that because the implicit registration set is a whole, it is 
> unlikely individual URIs from the implicit registration set will 
> disappear. You will either lose them all or none of them. Because of 
> this I can envisage that a perfectly workable solution uses neither of 
> these mechanisms.

That makes sense for phones. But I can imagine it wouldn't work so well 
for PBXes. E.g. suppose I requested that some of my lines be removed. (I 
had a layoff and don't need and can't afford them any longer.) At some 
point in time that request will take effect. Those lines should no 
longer be available to my PBX. That should be reflected as an indication 
that those particular lines are no longer registered.

> Note that IMS does intend that certain reg event values do cause the UA 
> to recognise a failure and initiate a reregistration. In the absence of 
> this, the interconnect will be broken in both directions, because the 
> IMS has taken away its support for those URIs at that point.

With a PBX it is much more important that there be no break in service 
than is the case with a single phone. There is a good chance there will 
be no time when the reregistration can be done without tearing down 
somebody's call. (If you insist on that "no calls unless registered" 
requirement.)

	Thanks,
	Paul

> I would note also that none of John's current list of requirements needs 
> such a mechanism at all. So if people see the need for any such 
> mechanism to be mandated, they need to start exploring what the 
> requirements would be.
>  
> regards
>  
> Keith
> 
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of *Brian Lindsay
>     *Sent:* Friday, January 08, 2010 6:24 PM
>     *To:* Hadriel Kaplan; Elwell, John; David Hancock
>     *Cc:* [email-masked]
>     *Subject:* [martini] martini-shaken-implicit-registrations : propose
>        Regarding the martini-shaken-implicit-registrations draft,
>     currently the draft has the following requirement regarding support
>     of P-Associated-URI:
>      
>      The Registrar SHOULD indicate all of the implicitly Registered
>     AoRs in a P-Associated-URI header field(s) in the 200 response to
>     the REGISTER, if it supports [RFC3455].  [OPEN ISSUE: should we
>     mandate PAU support?  Should we document a legal/compliant means of
>     indicating AoR username "wildcards"?]
>         As worded, this is a conditional SHOULD requirement (conditional
>     on whether RFC 3455 is supported by the Registrar), but there is a
>     question about whether PAU should be mandated.
>      
>           not part of most currently deployed SIP PBX
>           there was a suggestion of making this optional, but I believe
>           none of the enterprise vendors ever saw any strong value case
>           for doing anything with the header, hence it was promptly
>           removed and never re-surfaced as a requirement in subsequent
>           drafts of the spec
>     network that would never be used by recipiants. It would seem
>     prudent to simply remove from the draft altogether at this point.
>      
>         Thanks
>             Brian
> 
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Sat, 9 Jan 2010 02:17:26 +0100

I don't think there is anything particularly IMS specific about what I was saying. 

I can take you back to ISDN days and point you at the work there as well. DSS1 T reference point procedures assume that the functionality for dealing with specific extensions is on the PBX side of the interface. 

Put that functionality back on the public network side of the interface, and you have an access concentrator and Centrex, not a PBX.

I don't see how a lot of that model (which is essentially a business relationship model at the start) changes with VOIP.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Elwell, John
> Sent: Friday, January 08, 2010 10:29 AM
> To: Adam Roach; Christer Holmberg
> Cc: Hadriel Kaplan; [email-masked]
> I think Christer's summary is good. The architecture that 
> Keith and others are talking about is applicable outside IMS 
> too - that is what the SIP Forum is trying to achieve with 
> SIPconnect - a means for a PBX to register. This was probably 
> a lot clearer with the earlier domain registration draft 
> ("stirred"), but it is still the same principle with the 
> current implicit registration draft ("shaken").
> 
> John
> 
> > In IMS-derived architectures, you can make the assumptions 
> Keith has. 
> > In the general case, I don't think they hold.
> > 
> > /a
> > 
> seems to be 
> > arguing that we are still talking about a SINGLE SIP user. What 
> > happens inside the PBX is irrelevant. The PBX users have a relation 
> > with the PBX - the PBX has a relation with the SIP network.
> > >
> > transaction makes it any more or less architecture-specific than a 
> > PUBLISH one.
> > >>
> > >>      
> > back-and-forth on this topic that amounts to the same exchange over 
> > and over (not just with you; with several parties). I'm going to 
> > replay the dialog in simplified form, because I think something is 
> > getting lost with the flood of email
> > > messages:
> > >
> > problems unless all parties to the transaction understand 
> the changes. 
> > The fact that no such problem arises in one specific architecture 
> > seems to be held out as proof that it must work everywhere. 
> Which is 
> > the logical equivalent to:
> > I said on the phone, the basic concept of using PUBLISH to update a 
> > Location Service database could be a BCP, since it requires no new 
> > protocol mechanism. Nothing breaks, since the meaning of everything 
> > remains the same.
> > >
> > SIP protocol extensions using established extension mechanisms. You 
> > could do the same thing with REGISTER, if you really wanted to, by 
> > using both Require and Proxy-Require.
> > >
> > > /a

---

From: <[email-masked]>
Date: Mon, 11 Jan 2010 09:30:00 +0100

I accept that the PBX may not need the P-Associated-URI. However I believe that sending the PAU by the registrar is required in architectures where the edge proxy is the entity responsible for asserting calling party identities (i.e. P-Preferred-Identity to P-Asserted-Identity conversion). 

> [mailto:[email-masked]] De la part de Richard Shockey
> Envoyé : vendredi 8 janvier 2010 21:30
> À : [email-masked]
> Objet : Re: [martini] martini-shaken-implicit-registrations: 
> propose P-Associated-URI be removed
> 
> +1
> 
> [mailto:[email-masked]] On  
> > Behalf Of Bernard Aboba
> >  Subject: Re: [martini] martini-shaken-implicit-registrations : 
> > propose  P-Associated-URI be removed
> >  
> >  +1.
> >  
> >  Subject: Re: [martini] martini-shaken-implicit-registrations : 
> > propose  P-Associated-URI be removed
> >  
> >  currently
> >  > the draft has the following requirement regarding support of  > 
> > P-Associated-URI:
> >  >
> > AoRs  in  > a P-Associated-URI header field(s) in the 200 
> response to 
> > the  REGISTER,  > if it supports [RFC3455].  [OPEN ISSUE: should we 
> > mandate PAU  support?
> >  > Should we document a legal/compliant means of indicating AoR  
> > username  > "wildcards"?]
> >  on
> >  > whether RFC 3455 is supported by the Registrar), but there is a  
> > question  > about whether PAU should be mandated.
> >  >
> >  >       was a suggestion of making this optional, but I 
> believe none
> >  of
> > prudent to  > simply remove from the draft altogether at this point.
> >  >
> >  >     Thanks
> >  >         Brian
> >  >
> >  >
> >  >

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Jan 2010 09:47:24 +0100

I agree.

John 

> Sent: 08 January 2010 18:43
> To: Brian Lindsay
> Cc: Hadriel Kaplan; Elwell, John; David Hancock; [email-masked]
> Subject: Re: [martini] martini-shaken-implicit-registrations 
> : propose P-Associated-URI be removed
> 
> believe none of

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 10:15:10 +0100

Hi, 

>>>architecture where this could break things.    The 
>>>REGISTER method is between the UA and the Registrar, and I don't recall anything in 
>>the Service-Route and Path mechanisms, we have invited proxies into 
>>the REGISTER transaction. And, for better or for worse, those 
>>particular cats are both well out of the bag and marking the furniture.
> 
>Yes. IMS is the poster child here. The P-CSCF and I-CSCF are 
>heavily coupled to REGISTER. They typically are B2BUAs rather 
>than proxies I think, but they try to pretend to be proxy-like.
> 
>In any case, everybody and his brother seem to think that 
>intermediate devices should be able to make decisions about 
>who can and can't receive traffic based on whether they are 
>registered or not. IMO that is a terrible concept, but still 
>it is there.

IF the PBX is seen as a single user from the SIP network perspective, I don't think "proxies" will make decisssion on which PBX users will be allowed to receive traffic or not. Intermediates have no knowledge of those.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 10:16:46 +0100

Hi, 

>Yes, it is certainly an approach that has popularity beyond IMS.

I agree. I was going to mention SIPConnect in my initial e-mail, but I forgot.

But, in that case, there is no need for the SIP network intermediates to have knowledge about individual PBX users, since the PBX is seen as a single user.

Regards,

Christer

> seems to 
> >> be arguing that we are still talking about a SINGLE SIP user. What 
> exchange over 
> update a 
> mechanisms. You

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 11 Jan 2010 11:07:17 +0100

Bruno,

But this does not mean there is a requirement for the edge proxy to send it to the PBX.

John 

> [mailto:[email-masked]] On Behalf Of 
> [email-masked]
> Sent: 11 January 2010 08:30
> To: [email-masked]; [email-masked]
> Subject: Re: [martini] martini-shaken-implicit-registrations: 
> I accept that the PBX may not need the P-Associated-URI. 
> However I believe that sending the PAU by the registrar is 
> required in architectures where the edge proxy is the entity 
> responsible for asserting calling party identities (i.e. 
> P-Preferred-Identity to P-Asserted-Identity conversion). 
> 
> > >  >     * There haven't been any proposed requirements 
> tabled to date
> > >  that
> > >  >       anything with the header, hence it was promptly 
> removed and
> > >  never
> This message and any attachments (the "message") are 
> confidential and intended solely for the addressees. 
> If you are not the intended addressee of this message, please 
> cancel it immediately and inform the sender.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 14:53:07 +0100

Hi, 

>I can take you back to ISDN days and point you at the work there as well. DSS1 T reference point procedures assume that 
>the functionality for dealing with specific extensions is on the PBX side of the interface. 
> 

I am not an expert of PBXs, but I talked to some people and they told me more or less what Keith also says.

I also see no reason why we should change that concept for VoIP. I don't think that is even in the scope of MARTINI to do so.

Regards,

Christer

> > I think Christer's summary is good. The architecture that Keith and 
> > others are talking about is applicable outside IMS too - 
> that is what 
> > the SIP Forum is trying to achieve with SIPconnect - a 
> means for a PBX 
> > to register. This was probably a lot clearer with the 
> earlier domain 
> > registration draft ("stirred"), but it is still the same principle 
> > with the current implicit registration draft ("shaken").
> > 
> > John
> >

---

From: Adam Roach <[email-masked]>
Date: Mon, 11 Jan 2010 09:09:49 -0600

On 1/11/10 3:15 AM, Christer Holmberg wrote:
> IF the PBX is seen as a single user from the SIP network perspective...

I don't think this predicate holds in the general case. I think it is 
specific to a fairly narrow set of network architectures.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 11 Jan 2010 10:21:35 -0500

This seems to be a scoping issue for the work.
Certainly it is an assumption that works for "stirred".

I would be willing to accept this as a scope limitation on the work.

Getting agreement on the scope here might resolve some of the other issues.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 11 Jan 2010 16:38:40 +0100

Hi,

>I don't think this predicate holds in the general case. I think it is specific to a fairly narrow set of network >architectures.

My understanding is that it applies for PBXs in general, and is not specific to the core network architecture.

Regards,

Christer

---

From: Francois Audet <[email-masked]>
Date: Mon, 11 Jan 2010 07:35:22 -0800

I agree

On Jan 11, 2010, at 5:53, Christer Holmberg <[email-masked] 
 > wrote:

>> I can take you back to ISDN days and point you at the work there as  
>> well. DSS1 T reference point procedures assume that
>> Put that functionality back on the public network side of the  
>> interface, and you have an access concentrator and Centrex, not a  
>> PBX.
>>
>> I don't see how a lot of that model (which is essentially a  
>> business relationship model at the start) changes with VOIP.
>
> I am not an expert of PBXs, but I talked to some people and they  
> told me more or less what Keith also says.
>
> I also see no reason why we should change that concept for VoIP. I  
> don't think that is even in the scope of MARTINI to do so.
>
> Regards,
>
> Christer
>
>
>
>
>

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 12 Jan 2010 11:20:21 -0500

Hi,

  One comment on this and shaken vs stirred:

  For the registration-based approaches there are several clear
interface principles that have emerged:

- The SIP PBX REGISTERs using an explicit AoR, assigned by the Service
Provider, that represents the SIP PBX

- For requests sent to the SIP PBX, the Request-URI is not overwritten
with the contact provided at registration. However, the domain in the
SIP URI in the Request-URI would contain the domain associated with the
SIP PBX. This provides equivalency to RFC3263 peering approaches for
signalling.

- The drafts also propose some additional signalling information to
explicitly identify in the REGISTER request/response that this behavior
is requested/provided.

  The IMS-style implicit registration approach described in
Martini-shaken describes one possible network implememntation for
registration. By this I mean there is the concept of an implicit
registration set, which in this case would contain AoRs representing
E.164 numbers or ranges, and likely also a wildcarded AoR for the SIP
PBX domain. There is a location service database containing all of these
AoRs which is updated with the contact info provided at registration.

  I think it should also be possible to implement something quite
different on the network side which still satisfies the same interface
requirements but does not technically/formally use IMS-style "implicit
registration" as the basis of the network implementation.

  For example, one might have a network implementation which includes a
separate database that effectively maps E.164 numbers/ranges to domains
(e.g. an ENUM type approach). In such an approach, the E.164
numbers/ranges are technically not part of an IMS-style implicit
registration set per se, and the E.164 numbers wouldn't be in the formal
location service database as AoRs. From this perspective, the actual
internal network implementation starts to look a lot more like "domain"
registration.

  There is a section in Martini-shaken which actually allows for
alternate implementations as long as the external interface behavior is
satisfied:

 " 4.4. Registrar Behavior 
    
   This document uses the same logical location service database 
   concept of [RFC3261] residing in the Registrar, for the purpose of 
   describing the behavior of the mechanism in this document.  Specific 
   implementations need not follow this data structure, so long as they 
   maintain the same logical external behavior. "

  So I believe we need a clear set of interface/behavioral requirements
for registration/routing, but we do not need to necessarily dictate or
assume what is technically an IMS-like implicit registration
implementation in the network. Is this generally agreed? If so, does
"implicit" registration carry too much "baggage" in this context?
Thoughts?

   Thanks
       Brian

-----Original Message-----
Behalf Of Elwell, John
Sent: Friday, January 08, 2010 5:29 AM

I think Christer's summary is good. The architecture that Keith and
others are talking about is applicable outside IMS too - that is what
the SIP Forum is trying to achieve with SIPconnect - a means for a PBX
to register. This was probably a lot clearer with the earlier domain
registration draft ("stirred"), but it is still the same principle with
the current implicit registration draft ("shaken").

John

> In IMS-derived architectures, you can make the assumptions Keith has. 
> REGISTER for those breaks things. Keith (and maybe others) seems to be

> problems unless all parties to the transaction understand the changes.

> seems to be held out as proof that it must work everywhere. Which is

---

From: Adam Roach <[email-masked]>
Date: Tue, 12 Jan 2010 11:20:27 -0600

On 1/12/10 10:20, Jan 12, Brian Lindsay wrote:
> with the contact provided at registration.

While I agree that this is in the nature of the solutions that have been 
proposed, I believe it is a major flaw in them, and the source of over 
half of the problems described in the mixing-problems document.

>   However, the domain in the

Given the context of what has been discussed so far, what you say here 
is too vague for me to figure out whether it is correct. When you say 
"the domain associated with the SIP PBX," do you mean:

   1. A domain that doesn't exist in a domain name registry anywhere
   2. A domain that, while properly registered with a domain name
      registry, does not exist in DNS
   3. A domain that exists in the global DNS, and which routes to the
      SSP if someone applies 3263 procedures
   4. A domain that exists in the global DNS, and which routes to the
      PBX if someone applies 3263 procedures

Each of these has its own set of issues; however (as we were discussing 
yesterday and last week), I think that #3 has a set of particularly 
intractable issues that make it infeasible for deployment in the Internet.

> internal network implementation starts to look a lot more like "domain"

In fact, what you've described starts to look an awful lot like a 
simplified version of RFC 3219. ;-)

> "implicit" registration carry too much "baggage" in this context?

I think that the implicit approach pursued so far does suffer from some 
significant shortcomings that go away once the URIs being registered are 
explicit in the request. This is true regardless of the request method 
we use.

/a

---

From: "Brian Lindsay" <[email-masked]>
Date: Tue, 12 Jan 2010 22:31:53 -0500

Hi,
 
   Comments inline below....

From: Adam Roach [mailto:[email-masked]] 
Sent: Tuesday, January 12, 2010 12:20 PM
To: Lindsay, Brian (CAR:AR00)
Cc: Elwell, John; Christer Holmberg; Hadriel Kaplan; [email-masked]
Subject: Re: [martini] draft-roach-martini-up-00

	
	...
	
	- For requests sent to the SIP PBX, the Request-URI is not
overwritten
	with the contact provided at registration.

	 However, the domain in the
	SIP URI in the Request-URI would contain the domain associated
with the
	SIP PBX. This provides equivalency to RFC3263 peering approaches
for
	signalling.

	

[Lindsay, Brian]  More than one of these might be possible, but I was
basically refering to the principle illustrated in David's "Flow-2" in
the following post from last week:
 
http://www.ietf.org/mail-archive/web/martini/current/msg00166.html

Each of these has its own set of issues; however (as we were discussing
yesterday and last week), I think that #3 has a set of particularly
intractable issues that make it infeasible for deployment in the
Internet.

	For example, one might have a network implementation which
includes a
	separate database that effectively maps E.164 numbers/ranges to
domains
	(e.g. an ENUM type approach). In such an approach, the E.164
	numbers/ranges are technically not part of an IMS-style implicit
	registration set per se, and the E.164 numbers wouldn't be in
the formal
	location service database as AoRs. From this perspective, the
actual
	internal network implementation starts to look a lot more like
"domain"
	registration.

[Lindsay, Brian]  Ah Interesting. My example here was just to show that
there could be multiple possible network implementations which can
support the same interfaces as proposed in Martini-Shaken, but don't
actually require the E.164 numbers/ranges associated with the SIP PBX /
enterprise to be part of an implicit registration set and included in an
RFC3261 local service data database. 

	  So I believe we need a clear set of interface/behavioral
requirements
	for registration/routing, but we do not need to necessarily
dictate or
	assume what is technically an IMS-like implicit registration
	implementation in the network. Is this generally agreed? If so,
does
	"implicit" registration carry too much "baggage" in this
context?
	Thoughts?

/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Jan 2010 07:47:42 -0600

On 1/12/10 21:31, Jan 12, Brian Lindsay wrote:
> **

In that message, Flow-2 is very ambiguous with regards to the 
relationship between "pbx1.sp.com" and DNS. Are there any DNS records 
that point to "pbx1.sp.com?" If so, where do they resolve? The PBX 
itself? And, if they *do* point to the PBX, why can't the SP just apply 
normal 3263 rules?

/a

---

From: "Spencer Dawkins" <[email-masked]>
Date: Wed, 13 Jan 2010 11:49:26 -0600

Adam, 

I might have misunderstood, but I thought that the point was that the DNS records would point to the service provider, not directly to the SIP-PBX. If you have DNS records that point directly to the SIP-PBX, I don't know how you can NOT do 3263 (the caller gets the DNS results and decides to send the call to someplace else, based on ??? :-)

Ignoring policy, of course, but if the caller has policy at that level, you don't need 3263 OR any of the bulk registration mechanisms we've been talking about (and I'm pretty sure you don't need REGISTER, either :-).

Spencer
  ----- Original Message ----- 
  From: Adam Roach 
  To: Brian Lindsay 
  Cc: [email-masked] ; Hadriel Kaplan 
  Sent: Wednesday, January 13, 2010 7:47 AM
  Subject: Re: [martini] draft-roach-martini-up-00

----------------------------------------------------------------------------
    From: Adam Roach [mailto:[email-masked]] 

    Given the context of what has been discussed so far, what you say here is too vague for me to figure out whether it is correct. When you say "the domain associated with the SIP PBX," do you mean:

      1.. A domain that doesn't exist in a domain name registry anywhere

      2.. A domain that, while properly registered with a domain name registry, does not exist in DNS 
      3.. A domain that exists in the global DNS, and which routes to the SSP if someone applies 3263 procedures

      4.. A domain that exists in the global DNS, and which routes to the PBX if someone applies 3263 procedures 
    [Lindsay, Brian]  More than one of these might be possible, but I was basically refering to the principle illustrated in David's "Flow-2" in the following post from last week:

  In that message, Flow-2 is very ambiguous with regards to the relationship between "pbx1.sp.com" and DNS. Are there any DNS records that point to "pbx1.sp.com?" If so, where do they resolve? The PBX itself? And, if they *do* point to the PBX, why can't the SP just apply normal 3263 rules?

  /a

------------------------------------------------------------------------------

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Jan 2010 15:18:22 -0600

On 1/13/10 11:49 AM, Spencer Dawkins wrote:
> Adam,
> I might have misunderstood, but I thought that the point was that the 
> DNS records would point to the service provider, not directly to the 
> SIP-PBX.

That leads to the looping problem we've discussed a number of times.

> If you have DNS records that point directly to the SIP-PBX, I don't 
> know how you can NOT do 3263 (the caller gets the DNS results and 
> decides to send the call to someplace else, based on ??? :-)
> Ignoring policy, of course, but if the caller has policy at that 
> level, you don't need 3263 OR any of the bulk registration mechanisms 
> we've been talking about (and I'm pretty sure you don't need REGISTER, 
> either :-).

Exactly. If 3263 takes you there, then we're done. Shut down MARTINI, 
the problem has been solved. ;-)

Here's the thing -- each of the 4 approaches I mentioned has serious 
flaws with it. And without nailing down which one people think they're 
talking about (and I think various people are talking about different 
things), then I don't think we can come to agreement on how we can 
address these flaws. So far, people seem to be intentionally evasive 
about what they actually mean when they talk about how this URL gets 
rewritten, and what it gets rewritten into.

With the URL rewriting rules being proposed, exactly one of the 
following four properties must be true regarding the domain in the URL; 
it is either:

   1. A domain that doesn't exist in a domain name registry anywhere,
   2. A domain that, while properly registered with a domain name
      registry, does not exist in DNS,
   3. A domain that exists in the global DNS, and which routes to the
      SSP if someone applies 3263 procedures, or
   4. A domain that exists in the global DNS, and which routes to the
      PBX if someone applies 3263 procedures.

If I've missed out a valid permutation somewhere, we should introduce it 
into the equation. But, with these four approaches, there is at _least_ 
one relatively major hurdle to clear:

Approach number 1 leads to potential domain name collisions. It probably 
won't clear the IESG.

Approach number 2 raises the "alternate root" specter we discussed on 
the call.

Approach number 3 has a problem with creating routing loops.

Approach number 4 makes the entire MARTINI effort unnecessary.

Some of these problems are bigger than others, and most of them (except 
number 3) are political in nature. It would be good to know which set of 
problems we're taking on. But until we can get people to explain what 
they mean by "3263-like handling," we're kind of poking at shadows.

Alternately, the whole mess goes away if we use normal proxy/registrar 
behavior for request routing, and associate a different contact with 
each of the extensions on the PBX. My draft shows one way this can be 
done. There are certainly others.

/a

>     *From:* Adam Roach <mailto:[email-masked]>
>     *To:* Brian Lindsay <mailto:[email-masked]>
>     *Cc:* [email-masked] <mailto:[email-masked]> ; Hadriel Kaplan
>     <mailto:[email-masked]>
>     *Sent:* Wednesday, January 13, 2010 7:47 AM
>>     Given the context of what has been discussed so far, what you say
>>     here is too vague for me to figure out whether it is correct.
>>     When you say "the domain associated with the SIP PBX," do you
>>     mean:[Lindsay, Brian]  More than one of these might be possible,
>>     but I was basically refering to the principle illustrated in
>>     David's "Flow-2" in the following post from last week:
>     relationship between "pbx1.sp.com" and DNS. Are there any DNS
>     records that point to "pbx1.sp.com?" If so, where do they resolve?
>     The PBX itself? And, if they *do* point to the PBX, why can't the
>     SP just apply normal 3263 rules?
>
>     /a
>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jan 2010 10:48:37 +0100

Adam,

What I have in mind is approach 3. Anyone outside the PBX's domain could do a DNS look-up, and it would get to the SP, which would then get it to the PBX.  Within the PBX, policy would override the DNS look-up, such that the PBX would regard itself as responsible for the domain.

Concerning approach 1, I can accept your view.

Concerning approach 2, I did not fully grasp the "alternate root" concept discussed in the call, and there is nothing in the minutes (I was one of the note-takers, but I got left behind at that point). Please explain.

Concerning approach 4, reasons are given in the problem-statement draft as to why this is not feasible, and hence the need for MARTINI.

John

> Sent: 13 January 2010 21:18
> To: Spencer Dawkins
> 	I might have misunderstood, but I thought that the 
> point was that the DNS records would point to the service 
> provider, not directly to the SIP-PBX.
> 
> 
> 	If you have DNS records that point directly to the 
> SIP-PBX, I don't know how you can NOT do 3263 (the caller 
> gets the DNS results and decides to send the call to 
> someplace else, based on ??? :-)
> 	 
> 	Ignoring policy, of course, but if the caller has 
> policy at that level, you don't need 3263 OR any of the bulk 
> registration mechanisms we've been talking about (and I'm 
> pretty sure you don't need REGISTER, either :-).
> 
> 
> Exactly. If 3263 takes you there, then we're done. Shut down 
> MARTINI, the problem has been solved. ;-)
> 
> Here's the thing -- each of the 4 approaches I mentioned has 
> serious flaws with it. And without nailing down which one 
> people think they're talking about (and I think various 
> people are talking about different things), then I don't 
> think we can come to agreement on how we can address these 
> flaws. So far, people seem to be intentionally evasive about 
> what they actually mean when they talk about how this URL 
> gets rewritten, and what it gets rewritten into.
> 
> With the URL rewriting rules being proposed, exactly one of 
> the following four properties must be true regarding the 
> domain in the URL; it is either:
> 
> 
> 
> 2.	A domain that, while properly registered with a domain 
> name registry, does not exist in DNS, 
> 3.	A domain that exists in the global DNS, and which 
> routes to the SSP if someone applies 3263 procedures, or
> 	
> 4.	A domain that exists in the global DNS, and which 
> routes to the PBX if someone applies 3263 procedures. 
> 
> 
> If I've missed out a valid permutation somewhere, we should 
> introduce it into the equation. But, with these four 
> approaches, there is at _least_ one relatively major hurdle to clear:
> 
> Approach number 1 leads to potential domain name collisions. 
> It probably won't clear the IESG.
> 
> Approach number 2 raises the "alternate root" specter we 
> discussed on the call.
> 
> Some of these problems are bigger than others, and most of 
> them (except number 3) are political in nature. It would be 
> good to know which set of problems we're taking on. But until 
> we can get people to explain what they mean by "3263-like 
> handling," we're kind of poking at shadows.
> 
> Alternately, the whole mess goes away if we use normal 
> proxy/registrar behavior for request routing, and associate a 
> different contact with each of the extensions on the PBX. My 
> draft shows one way this can be done. There are certainly others.
> 
> /a
> 
> 
> 
> 	 
> 	Spencer
> 
> 		From: Adam Roach <mailto:[email-masked]>  
> 		To: Brian Lindsay <mailto:[email-masked]>  
> 			Given the context of what has been 
> discussed so far, what you say here is too vague for me to 
> figure out whether it is correct. When you say "the domain 
> associated with the SIP PBX," do you mean:[Lindsay, Brian]  
> More than one of these might be possible, but I was basically 
> refering to the principle illustrated in David's "Flow-2" in 
> 		In that message, Flow-2 is very ambiguous with 
> regards to the relationship between "pbx1.sp.com" and DNS. 
> Are there any DNS records that point to "pbx1.sp.com?" If so, 
> where do they resolve? The PBX itself? And, if they *do* 
> point to the PBX, why can't the SP just apply normal 3263 rules?
> 		
> 		/a
> 		
>

---

From: Adam Roach <[email-masked]>
Date: Thu, 14 Jan 2010 09:50:11 -0600

> What I have in mind is approach 3. Anyone outside the PBX's domain could do a DNS look-up, and it would get to the SP, which would then get it to the PBX.  Within the PBX, policy would override the…

Unless it doesn't, and then  you've got a loop. What's being designed 
here is a perfect storm of bad decisions.

There is a contingent of people who think we don't need an explicit 
indicator for these procedures. Combined with approach #3, this leads to 
situations in which non-MARTINI UAs register at the SSP; the SSP invokes 
MARTINI procedures (without an indicator, how would he know not to?); 
and then any incoming calls end up looping.

Even without that, the lack of an explicit list of domains that the PBX 
is claiming authority for leads to a very, very easy mis-provisioning in 
which the SSP thinks the PBX should handle a specific domain, but the 
PBX doesn't think it should. Looping again.

> Concerning approach 2, I did not fully grasp the "alternate root" concept discussed in the call, and there is nothing in the minutes (I was one of the note-takers, but I got left behind at that poi…

Both approaches 2 and 3 suffer from this issue, by the way. I just think 
the technical problems with approach 3 are sufficiently damning that we 
don't even need to explore the political ramifications. But they're 
real, and they can torpedo our work late in the process.

The general idea is that resolution of domain names to IP addresses is 
inherently something that must be stable for the Internet to operate 
correctly. That means that attempts to turn a name into an IP address 
need to yield the same results no matter who is asking or where they are 
in the network. To ensure this property, we have a single, unique, 
unified, and Internet-wide domain name system. It is a single 
hierarchical tree, with a "single root."

Any design for turning names into IP addresses that yields different 
results than the global DNS runs contrary to this "single root" 
approach. It is highly likely that members of the IESG and/or IAB are 
willing to light themselves on fire to prevent any kind of beachhead 
that can be interpreted as sanctioning of such a design. Concerned 
members of the IETF community at large are likely to be sufficiently 
concerned as to file an appeal to attempt block publishing the MARTINI 
documents as RFCs.

In short, it's a political minefield. We're better off choosing a 
different patch of land for our dance floor.

> Concerning approach 4, reasons are given in the problem-statement draft as to why this is not feasible, and hence the need for MARTINI.

I think we're pretty much in agreement on this point. At least, if we 
accept the stated conditions that led to the formation of MARTINI, then 
it's clear that approach 4 is not a solution to the problems.

/a

>> 		From: Adam Roach<mailto:[email-masked]>
>> 		To: Brian Lindsay<mailto:[email-masked]>

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 14 Jan 2010 21:25:06 +0100

> Sent: 14 January 2010 15:50
> To: Elwell, John
> Cc: Spencer Dawkins; Hadriel Kaplan; [email-masked]
> > What I have in mind is approach 3. Anyone outside the PBX's 
> domain could do a DNS look-up, and it would get to the SP, 
> which would then get it to the PBX.  Within the PBX, policy 
> would override the DNS look-up, such that the PBX would 
> regard itself as responsible for the domain.
> >    
> 
[JRE] The shaken draft includes an explicit indicator.

> PBX doesn't think it should. Looping again.
[JRE] Yes, this doesn't entirely get around the provisioning problem, but I think that is outside the scope of MARTINI.

> 
> 
> > Concerning approach 2, I did not fully grasp the "alternate 
> root" concept discussed in the call, and there is nothing in 
> the minutes (I was one of the note-takers, but I got left 
> behind at that point). Please explain.
> >    
> 
[JRE] I don't see how option 3 leads to this situation. Anyone looking in the DNS for pbx.com will be pointed at the SP. The SP will know it uses MARTINI procedures for pbx.com. The PBX will know it is responsible for pbx.com.

John

> > Concerning approach 4, reasons are given in the 
> problem-statement draft as to why this is not feasible, and 
> hence the need for MARTINI.
> >    
>

---

From: Adam Roach <[email-masked]>
Date: Fri, 22 Jan 2010 17:07:29 -0600

> [JRE] I don't see how option 3 leads to this situation. Anyone looking in the DNS for pbx.com will be pointed at the SP. The SP will know it uses MARTINI procedures for pbx.com. The PBX will know i…

You're still coming up with a parallel system for resolving names into 
IP addresses, even if you scope those procedures to the SSP. Even worse, 
you're defining it in such a way that it necessarily returns different 
results than DNS does.

If you want MARTINI's documents to be caught up in appeals after we're 
done with them, this is probably the best path to ensure that. On the 
other hand, if you have a goal of getting to RFC as quickly as possible 
(or at all), we might want to think about alternate approaches.

/a