Subject: [martini] Consensus call: Resolution of Ticket #57

From: Bernard Aboba <[email-masked]>
Date: Fri, 27 Aug 2010 13:55:55 -0700

In the MARTINI WG second session at IETF 78, the participants in the room came to consensus (12-0) on the following text to resolve Issue 57:

In order to provide support for privacy, the SSP
SHOULD implement the temporary GRUU
mechanism described in this section. Reasons for
not doing so would include systems with an
alternative privacy mechanism which maintains
the integrity of public GRUUs (i.e., if public
GRUUs are anonymized then the anonymizer
function would need to be capable of providing as
the anonymized URI a globally routable URI
that routes back only to the target identified by
the original public GRUU).

We are now bringing this resolution to the mailing list to verify that consensus. 

If you did not express your opinion during the IETF 78 MARTINI WG meeting, and would like to do so now, please respond to this email and post your opinion as to whether you agree with the text above as a resolution to Issue 57. 

This consensus call will last until September 12, 2010.

---

From: Brian Lindsay <[email-masked]>
Date: Sat, 28 Aug 2010 15:12:23 +0000

Hi Bernard,

   My preference is to NOT introduce the text below.

   I don't believe Privacy requirements were in the original scope of MARTINI charter, nor in the MARTINI Requirements draft (since MARTINI wasn't looking at a complete set of market requirements for SIP PBXs).

  Temporary-GRUU's may form part of a privacy solution in some cases, but not necessarily a complete solution, and as the text below indicates there are other solutions. As well, privacy solutions may not be required in all deployments in all markets.

   I would like to see the text keep to the original intent (e.g. as in the -05 draft), which was to define how the GIN registration mechanism interacts with public/temporary GRUU's and how public/temporary GRUU's can be supported, but not couple an implementation of the GIN registration mechanism in any fashion to a public/temporary GRUU's implementation.

   The draft defines how public and temporary GRUU's can be implemented if needed which should be sufficient.

   There was text discussed on the list previously which could be added to the start of section 7:

http://www.ietf.org/mail-archive/web/martini/current/msg01831.html

   I commented previously on the topic of  GRUU's here:

http://www.ietf.org/mail-archive/web/martini/current/msg01846.html

   Thanks
       Brian

-----------------------------------------
Brian Lindsay
Sr. Architect, System Architecture
GENBAND
+1.613.763.3459
[email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Friday, August 27, 2010 4:56 PM
To: [email-masked]
Subject: [martini] Consensus call: Resolution of Ticket #57

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 28 Aug 2010 12:44:08 -0700

At the IETF 78 MARTINI WG meeting, during the discussion of Ticket 57 (relating to temporary GRUUs), a suggestion was made that public GRUUs be mandatory to implement for SSPs.  

We will now attempt to determine whether consensus exists within the MARTINI WG to make this change to the document. 

Please respond to this email and post your opinion as
to whether you agree that SSPs supporting MARTINI MUST implement support for public GRUUs.

---

From: "Andrew Allen" <[email-masked]>
Date: Sun, 29 Aug 2010 09:28:24 -0500

I certainly agree with the compromise we worked out in Masstricht. As I stated during the meeting GRUU is basically a bug fix for SIP and without it originally intended basic SIP capabilities either break, have negative side effects or have significant limitations on other capabilities in order to make them work. 

Public GRUU is not complex to implement and with temporary GRUU the compromise gives enough wiggle room to allow other alternatives that provide anonymity to be used provided they don't break the use of Public GRUUs. 

The privacy text is not so much about implementing privacy as to ensure that deployments don't break GRUU capabilities in order to achieve privacy.

Especially in enterprise deployments (which is the major MARTINI use case) endpoints will likely not have public IP addresses (or will have SBCs that modify them). So the need for GRUU support here is even more essential than "generic internet SIP".

So I agree that SSPs supporting MARTINI MUST implement support for providing public GRUUs.

Andrew

From: Bernard Aboba [mailto:[email-masked]] 
Sent: Saturday, August 28, 2010 03:44 PM
To: [email-masked] <[email-masked]> 
Subject: [martini] Call for Consensus: Support for Public GRUUs 

Please respond to this email and post your opinion as to whether you agree that SSPs supporting MARTINI MUST implement support for public GRUUs. 

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: Brian Lindsay <[email-masked]>
Date: Sun, 29 Aug 2010 15:15:16 +0000

HI Bernard,

      I would like to see public GRUU's continue to be optional in the GIN draft, rather than mandating them.

      My view is that is that it is appropriate for the GIN draft to define how GRUU interacts with the GIN registration mechanism, but there does not need to be a coupling/dependency such that an implementer of the GIN registration mechanism is also required to implement GRUU.  In short - I think what is in the -05 draft is fine.

*         Most existing SIP Trunking deployments do not use/require GRUU's. The main driver for the martini work has always been about aligning on the semantics of the registration request and request uri population. This can be done without introducing a dependency on GRUU implementation.

*         The GRUU RFC is still an optional mechanism as far as SIP is concerned

*         A baseline set of services can be provided without requiring GRUU. For example, the current draft of SIP Connect 1.1 (  http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,84/Itemid,75/   ) has a baseline call transfer capability defined that uses re-invites and doesn't use REFER.  REFER-based transfer is optional, as is the usage of out-of-dialog REFER. (The language actually discourages use of REFER due to billing risks/considerations).

  Thanks
      Brian

-----------------------------------------
Brian Lindsay
Sr. Architect, System Architecture
GENBAND
+1.613.763.3459
[email-masked]

From: [email-masked] [mailto:[email-masked]] On Behalf Of Bernard Aboba
Sent: Saturday, August 28, 2010 3:44 PM
To: [email-masked]
Subject: [martini] Call for Consensus: Support for Public GRUUs

---

From: Adam Roach <[email-masked]>
Date: Sun, 29 Aug 2010 16:08:04 -0500

I agree with Andrew on this point

The key issue in my mind is deployability. With a single registrar, 
deployment of GRUUs is a fairly tractable problem: once the registrar 
supports GRUUs, then clients can start making use of them. When we start 
having more entities involved in the mix -- like the dual-registrar 
situation that MARTINI was chartered to address -- then the chances of 
deployment decrease multiplicatively.

In other words, unless GRUU is mandated in GIN (or any solution to the 
MARTINI problem, for that matter), the chances of GRUU deployment are 
vanishingly small, in a way that doesn't exist in a single-registrar 
system. Because the MARTINI architecture *caused* this problem, I 
believe that it is incumbent on us to *fix* this problem.

As public GRUU is really quite easy to implement, I don't imagine that 
this requirement should be particularly controversial.

/a

On 8/29/10 09:28, Aug 29, Andrew Allen wrote:
>
> I certainly agree with the compromise we worked out in Masstricht. As 
> I stated during the meeting GRUU is basically a bug fix for SIP and 
> without it originally intended basic SIP capabilities either break, 
> have negative side effects or have significant limitations on other 
> capabilities in order to make them work.
>
> Public GRUU is not complex to implement and with temporary GRUU the 
> compromise gives enough wiggle room to allow other alternatives that 
> provide anonymity to be used provided they don't break the use of 
> Public GRUUs.
>
> The privacy text is not so much about implementing privacy as to 
> ensure that deployments don't break GRUU capabilities in order to 
> achieve privacy.
>
> Especially in enterprise deployments (which is the major MARTINI use 
> case) endpoints will likely not have public IP addresses (or will have 
> SBCs that modify them). So the need for GRUU support here is even more 
> essential than "generic internet SIP".
>
> *From*: Bernard Aboba [mailto:[email-masked]]
> *Sent*: Saturday, August 28, 2010 03:44 PM
> *To*: [email-masked] <[email-masked]>
> *Subject*: [martini] Call for Consensus: Support for Public GRUUs
>
> At the IETF 78 MARTINI WG meeting, during the discussion of Ticket 57 
> (relating to temporary GRUUs), a suggestion was made that public GRUUs 
> be mandatory to implement for SSPs.
>
> We will now attempt to determine whether consensus exists within the 
> MARTINI WG to make this change to the document.
>
> Please respond to this email and post your opinion as to whether you 
> agree that SSPs supporting MARTINI MUST implement support for public 
> GRUUs.
>
> This transmission (including any attachments) may contain confidential 
> information, privileged material (including material protected by the 
> solicitor-client or other applicable privileges), or constitute 
> non-public information. Any use of this information by anyone other 
> than the intended recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender and 
> delete this information from your system. Use, dissemination, 
> distribution, or reproduction of this transmission by unintended 
> recipients is not authorized and may be unlawful.
>
>
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Mary Barnes <[email-masked]>
Date: Sun, 29 Aug 2010 17:27:57 -0500

+1

On Sun, Aug 29, 2010 at 4:08 PM, Adam Roach <[email-masked]> wrote:
> vanishingly small, in a way that doesn't exist in a single-registrar system.
> Because the MARTINI architecture *caused* this problem, I believe that it is
> incumbent on us to *fix* this problem.
>
> As public GRUU is really quite easy to implement, I don't imagine that this
> requirement should be particularly controversial.
>
> /a
>
> I certainly agree with the compromise we worked out in Masstricht. As I
> stated during the meeting GRUU is basically a bug fix for SIP and without it
> originally intended basic SIP capabilities either break, have negative side
> effects or have significant limitations on other capabilities in order to
> make them work.
>
> compromise gives enough wiggle room to allow other alternatives that provide
> anonymity to be used provided they don't break the use of Public GRUUs.
>
> The privacy text is not so much about implementing privacy as to ensure that
> deployments don't break GRUU capabilities in order to achieve privacy.
>
> Especially in enterprise deployments (which is the major MARTINI use case)
> endpoints will likely not have public IP addresses (or will have SBCs that
> modify them). So the need for GRUU support here is even more essential than
> "generic internet SIP".
>
> (relating to temporary GRUUs), a suggestion was made that public GRUUs be
> mandatory to implement for SSPs.
>
> Please respond to this email and post your opinion as to whether you agree
> that SSPs supporting MARTINI MUST implement support for public GRUUs.
>
> solicitor-client or other applicable privileges), or constitute non-public
> information. Any use of this information by anyone other than the intended
> recipient is prohibited. If you have received this transmission in error,
> please immediately reply to the sender and delete this information from your
> system. Use, dissemination, distribution, or reproduction of this
> transmission by unintended recipients is not authorized and may be unlawful.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 09:37:41 -0400

+1

Adam Roach wrote:
> ------------------------------------------------------------------------
>

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 30 Aug 2010 09:53:28 -0400

-1 

This statement disturbs me 

"unless GRUU is mandated in GIN (or any solution to the MARTINI problem, for
that matter), the chances of GRUU deployment are vanishingly small"

I don't understand this argument .. so GRUU's have not deployed for well
known reasons so we want to shove them down the throats of implementers and
use MARTINI as the mechanism? 

What in the MARTINI architecture has created this dilema...only the privacy
issue? 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Paul Kyzivat
Sent: Monday, August 30, 2010 9:38 AM
To: Adam Roach
Cc: [email-masked]; [email-masked]
Subject: Re: [martini] Call for Consensus: Support for Public GRUUs

+1

---

From: Adam Roach <[email-masked]>
Date: Mon, 30 Aug 2010 09:07:32 -0500

On 8/30/10 8:53 AM, Richard Shockey wrote:
> I don't understand this argument

Yeah, out of context, it is pretty difficult to understand. The 
paragraph right before it put it into context -- and even reading the 
rest of the sentence gives a good clue that this isn't the 
run-of-the-mill deployment issue.

> What in the MARTINI architecture has created this dilema...only the privacy

No, it's not the privacy issue. We're discussing public GRUUs, which 
provide no more privacy than AORs. Pretty much every part of my message 
that you didn't quote above goes over exactly what causes this problem. 
I don't know if you didn't read it, or if my writing is just that bad, 
but I'll have another run at explaining it.

The problem is that we have two registrars, and they *both* need to 
support GRUU before it can be used.

So, for example, when GRUU implementation has reached 10% in registrars 
overall, then only 1% (10% * 10%) of GIN systems will be able to make 
use of GRUU. Even when we reach 50% node deployment, we're still stuck 
at 25% of GIN systems that can support GRUU.

That's how MARTINI has made the problem demonstrably worse than the 
general case.

With this proposed solution (mandating *public* GRUU usage in SSPs), all 
we're doing is returning to the status quo. (Note that we're *not* 
requiring PBXes to use GRUUs, only for SSPs to allow them to do so).

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 10:20:56 -0400

> What in the MARTINI architecture has created this dilema...only the privacy

IMO this is called "learn from you mistakes".
We have a whole hierarchy of mistakes here:

- why hasn't the requirement in 3261 that Contact URIs must be globally
   routable been supported? (This was the reason that public GRUU was
   introduced.)

- why hasn't GRUU been widely implemented?

- if alternatives to GRUU have been deployed, why has none of them
   been proposed as a standard?

If somebody has a different solution for anonymity of calls from the 
sorts of devices that will be using GIN, that can be included/referenced 
in GIN, then I think we should consider that. But I have seen nothing 
other than "that problem will be solved elsewhere".

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Mon, 30 Aug 2010 11:24:13 -0400

RS> this is helpful. 

/a

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 30 Aug 2010 14:13:18 -0600

GIN breaks significant parts of SIP without GRUUs (or some equivalent functionality) so I think we need GRUUs to be required to be implement on the SSP side of GIN. 

> This consensus call will last until September 12, 2010.  

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Brian Lindsay <[email-masked]>
Date: Mon, 30 Aug 2010 21:29:47 +0000

Hi,

  If GIN truly "breaks" SIP, then wouldn't that mean that SIP PBXs, and their UA's, would also need to be mandated to support GRUU (which doesn't seem to be the suggestion).

  Now perhaps something like an out-of-dialog REFER for Call Transfer to the SIP PBX won't be possible without GRUU. But is that truly a mandatory capability that is required to be supported as part of a basic SIP PBX offering by a service provider? Or would be ubiquitously supported/allowed by SIP PBXs?

 Thanks
     Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Cullen Jennings
Sent: Monday, August 30, 2010 4:13 PM
To: [email-masked]
Subject: Re: [martini] Call for Consensus: Support for Public GRUUs

Cullen Jennings