Subject: [martini] Draft minutes of the IETF 78 MARTINI WG meeting

From: "Bernard Aboba" <[email-masked]>
Date: Mon, 23 Aug 2010 14:20:31 -0700

MARTINI WG IETF 78 Mintes

Chairs:

Bernard Aboba <bernard_aboba at hotmail.com>

Spencer Dawkins <spencer at wonderhamster.org>

Thursday, July 29, 2010

09:00 - 11:30

2.1 Colorado Room

09:00 - 9:10, Preliminaries

     Note Well

     Note Takers:  Paul Kyzivat and Cullen Jennings

     Jabber scribe

     Agenda bash

     Document Status

Solution Updates

MARTINI with Globally Identifiable Numbers, Adam Roach (40 minutes)

http://tools.ietf.org/html/draft-ietf-martini-gin

Went over changes and open issues:

Ticket 48 changes requirements but no impact on GIN.  There was 

discussion of process. This is about appendix A which is analysis of 

requirements. Adam proposes to align the appendix A by changing text 

that quotes the requirements doc to be consistent with the final 

version of the requirements doc.

Proposal by Cullen and Hadriel to just drop appendix A. John and Adam 

are happy to remove it. Keith would like it to remain. So decision is 

to keep it.

Agreed to change the text in Appendix A so that it matches the text 

in requirements specification. 

No objection to Issue 4 and Issue 5.

Ticket 49 - nits. Changed. Keith requested consistency on a number of 

other nits. He was asked to report them on the list. He agreed.

Ticket 50: propose to update inline with suggestions in the ticket.

Query made if any objections to the above tickets. There were none.

Ticket 51: ticket submitter proposed one resolution, Adam proposes to 

do contrary - reject BNC contact with user part. Discussion of 

pros/cons of the alternative. Keith and Cullen argued for being 

strict, and Hadriel agreed. That approach (consistent with the slide) 

was agreed: incorrect URI will cause rejection.

Ticket 54: Keith objected to use of "non-bnc URI" without definition. 

Adam agrees to fix that, make it clear what is intended.

Everywhere we have BNC before another term, it needs to be defined.

On this issue in #54 reword to be "URI without a BNC"

Ticket 55: regarding prohibition of "bnc" parameter in reg event bodies. 

Questions/objections of how this prohibition applies to reg event 

extensions. It was agreed to modify the proposed text - "after "bnc"

parameter" add "in an extension".

Ticket 56: about security review. Discussion of what the error code 

should be. Adam proposes using an existing 500 class response to 

indicate an overload condition.

Agreed on Proposal #1 and #2. Will return an existing 500 class response. 

Ticket 57: Are GRUUs mandatory? Three options offered - completely 

optional; mandatory to implement & optional to use; mandatory to use 

martini at all. 

Hadriel argued at length for optionality. Cullen argued strongly 

for mandatory to implement for public GRUU. There was clarification 

that these requirements are on the SSP. There was consensus that it be 

mandatory for an SSP implementing gin to supply a public gruu when 

requested by the registering PBX.

Then discussion moved to temp GRUU. Debate among Cullen and Hadriel. 

Cullen argues for support of confidentiality - need to support 

anonymous calls. He would accept some other mechanism than temp GRUU 

if someone can propose it for inclusion in this draft. Andrew Allen 

supports for fear that some other system likely to mangle public 

GRUUs. Hadriel asserted that he sells boxes that do this without use 

of temp GRUU.

Bernard Aboba noted that GRUU support (both public and temporary) is

covered by REQ16 in the requirements document: 

   REQ16 - The mechanism MUST allow the SIP-PBX to provide its UAs with

   public or temporary Globally Routable UA URIs (GRUUs) [RFC5627].

However, this requirement is phrased as "MUST allow" and only applies

to PBXes, not SSPs.  John Ewell was concerned that that mandating

support by SSPs might raise the bar too high and discourage SSPs from 

implementing GIN. Keith was concerned that we are having a requirements 

document in the context of the gin draft - that people who want new 

requirement should be making a bis version of the requirements document. T

here was suggestion to split the ticket, into the part about pub gruu 

and a separate one about private calls.

Request for Cullen to file that ticket. Proposal for interested 

parties to go off between now and next session at 3 and try to figure this
out.

Will pick it up then.

Individual Submissions (60 minutes)

Other Logical Identifier Values (OLIVE), Hadriel Kaplan

http://tools.ietf.org/html/draft-kaplan-martini-with-olive

Hadriel gave summary. There were a number of clarifying questions. 

John wanted to know if this is service that SSPs would want to 

provide. Adam observed that its perfectly reasonable to assume the SSP 

could host your own domain name and then arbitrary user names within that
domain name.

Then got on to local numbers. Cullen suggests splitting this into 

separate drafts for alphanumeric user names and local numbers because.

About 10 people in the room thought it was worth solving the
"[email-masked]" 

problem - alphanumeric user names. This is simply guidance to hadriel 

about his authoring of private drafts.

There was a sughgestion to work on two separate documents:  one for

email-style addresses (e.g. "[email-masked]') and the other for numeric

addresses (but not E.164 numbers):  "1234". 

MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan

http://tools.ietf.org/html/draft-kaplan-martini-vermouth

Hadriel gave an overview. Normal subscription get routed to the PBX. 

Presented two alternatives - use reg-event with 

extensions or a new event package. John Elwell questioned if SIP is 

right for this. Andrew Allen also preferred new event package because 

semantics are different. Cullen Jennings gave another reason - authorization

rules are different.

There seemed to be general support for a new event package. 

Thursday, July 29, 2010

15:10 - 16:10

This session was just to clear up the temp-gruu issue.

People had worked in the intervening time and had proposed text 

which was displayed on a slide.

After brief discussion, the room was polled about this new text. 

Result was 12-0 in favor, which was considered to be consensus.

The group then adjourned.

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 25 Aug 2010 18:50:15 +0000

Hi,

   Regarding GRUU, I was unable to attend the IETF 78 WG Meeting, but I would like to object to the outcome regarding mandating support for GRUU on the SSP.

   There was discussion of the topic on the list in July, and I believe there was no consensus on mandating GRUU at that time, so  I think the topic is one that could be valid for the broader set of list participants to consider.

   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.

   Why?

*         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).

    The discussions on temporary GRUUs for privacy also seem to be exceeding the scope of the original focus of MARTINI and the requirements document. There was never an intent for MARTINI to define a privacy solution for SIP PBXs.

   Regards
        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: Monday, August 23, 2010 5:21 PM
To: [email-masked]
Subject: [martini] Draft minutes of the IETF 78 MARTINI WG meeting

Chairs:

Thursday, July 29, 2010
09:00 - 11:30
2.1 Colorado Room

     Note Well

Solution Updates

Request for Cullen to file that ticket. Proposal for interested
parties to go off between now and next session at 3 and try to figure this out.
Will pick it up then.

could host your own domain name and then arbitrary user names within that domain name.

About 10 people in the room thought it was worth solving the "[email-masked]"
problem - alphanumeric user names. This is simply guidance to hadriel
about his authoring of private drafts.

Thursday, July 29, 2010
15:10 - 16:10

---

From: "Bernard Aboba" <[email-masked]>
Date: Wed, 25 Aug 2010 14:03:20 -0700

Are you objecting to the public GRUU requirement, or temp GRUUs, or both?
Would it make a difference if it was a SHOULD vs. MUST or are you arguing
for MAY?

From: Brian Lindsay [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 11:50 AM
To: Bernard Aboba; [email-masked]
Subject: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG
meeting)

Hi,

   Regarding GRUU, I was unable to attend the IETF 78 WG Meeting, but I
would like to object to the outcome regarding mandating support for GRUU on
the SSP.

   There was discussion of the topic on the list in July, and I believe
there was no consensus on mandating GRUU at that time, so  I think the topic
is one that could be valid for the broader set of list participants to
consider.

   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.

   Why?

.         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/Ite
mid,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).

    The discussions on temporary GRUUs for privacy also seem to be exceeding
the scope of the original focus of MARTINI and the requirements document.
There was never an intent for MARTINI to define a privacy solution for SIP
PBXs.

   Regards

        Brian

Brian Lindsay

GENBAND

+1.613.763.3459

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Bernard Aboba
Sent: Monday, August 23, 2010 5:21 PM
To: [email-masked]
Subject: [martini] Draft minutes of the IETF 78 MARTINI WG meeting

Chairs:

Thursday, July 29, 2010

09:00 - 11:30

2.1 Colorado Room

     Note Well

     Jabber scribe

     Agenda bash

     Document Status

Solution Updates

to keep it.

martini at all. 

of temp GRUU.

 

Will pick it up then.

rules are different.

Thursday, July 29, 2010

15:10 - 16:10

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 25 Aug 2010 21:12:20 +0000

Hi Bernard,

   I'm arguing for a MAY for both.

   This text addition to the intro of section 7, that was discussed on the list previously, would be OK:

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

   Thanks
     Brian

From: Bernard Aboba [mailto:[email-masked]]
Sent: Wednesday, August 25, 2010 5:03 PM
To: Brian Lindsay; [email-masked]
Subject: RE: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG meeting)

Are you objecting to the public GRUU requirement, or temp GRUUs, or both?  Would it make a difference if it was a SHOULD vs. MUST or are you arguing for MAY?

From: Brian Lindsay [mailto:[email-masked]]
Sent: Wednesday, August 25, 2010 11:50 AM
To: Bernard Aboba; [email-masked]
Subject: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG meeting)

Hi,

   Why?

   Regards
        Brian

Chairs:

Thursday, July 29, 2010
09:00 - 11:30
2.1 Colorado Room

     Note Well

Solution Updates

Thursday, July 29, 2010
15:10 - 16:10

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 25 Aug 2010 19:40:49 -0400

Brian,

The logic behind the requirement for the *temp* gruu is that we have no 
other way to offer the PBX to make anonymous calls.

The alternative, if that requirement is made optional, is
- the pbx cannot make anonymous calls if the SP doesn't
   provide this option

- or that the SP provides some other mechanism for making
   anonymous calls, which the PBX will need to know about
   and invoke

Is it reasonable to release this spec with that sort of restriction?

	Thanks,
	Paul

Bernard Aboba wrote:
> Are you objecting to the public GRUU requirement, or temp GRUUs, or 
> both?  Would it make a difference if it was a SHOULD vs. MUST or are you 
> arguing for MAY?
> 
>  
> 
> *From:* Brian Lindsay [mailto:[email-masked]]
> *Sent:* Wednesday, August 25, 2010 11:50 AM
> *To:* Bernard Aboba; [email-masked]
> *Subject:* GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI 
> WG meeting)
> 
>  
> 
> Hi,
> 
>  
> 
> would like to object to the outcome regarding mandating support for GRUU 
> on the SSP.
> 
>  
> 
> there was no consensus on mandating GRUU at that time, so  I think the 
> topic is one that could be valid for the broader set of list 
> participants to consider.
> 
>  
> 
>    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.
> 
>  
> 
>    Why?
> 
>  
> 
> ·         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 
>     The discussions on temporary GRUUs for privacy also seem to be 
> exceeding the scope of the original focus of MARTINI and the 
> requirements document. There was never an intent for MARTINI to define a 
> privacy solution for SIP PBXs.
> 
>  
> 
>    Regards
> 
>         Brian
> 
>  
> 
> *From:* [email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Bernard Aboba
> *Sent:* Monday, August 23, 2010 5:21 PM
> *To:* [email-masked]
> *Subject:* [martini] Draft minutes of the IETF 78 MARTINI WG meeting
> 
>  
> 
> Ticket 49 – nits. Changed. Keith requested consistency on a number of
> 
> do contrary – reject BNC contact with user part. Discussion of
> 
> Ticket 57: Are GRUUs mandatory? Three options offered – completely
> 
> Cullen argues for support of confidentiality – need to support
> 
> document in the context of the gin draft – that people who want new
> 
> problem – alphanumeric user names. This is simply guidance to hadriel
> 
> Presented two alternatives – use reg-event with
> 
> semantics are different. Cullen Jennings gave another reason – 
> authorization
> 
> rules are different.
> 
>  
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: Brian Lindsay <[email-masked]>
Date: Thu, 26 Aug 2010 03:39:23 +0000

Hi Paul,

  For a complete solution for privacy, isn't there more required than just Temp-GRUU's? I believe RFC 5627 acknowledges additional need/requirements for a network-provided privacy service, for example, to cover other aspects of the privacy problem. Temp-GRUU's can be part of an overall solution (if GRUU's in general are used), and there are also solutions that wouldn't need Temp-GRUU's at all to ensure privacy (that seems to have been acknowledged in the proposed text that came out of IETF 78). 

  I'm on the page that GIN could describe some building blocks (e.g. temp-GRUU's) and their importance with respect to privacy, but GIN needn't necessarily mandate particular architecture(s)/solution(s) (which may not necessarily even be required in all deployments).

  I did listen to the audio archive from the morning session of the WG meeting, and I agreed with many of the comments that Hadriel was making regarding temp-GRUUs.

   Thanks,
     Brian

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Wednesday, August 25, 2010 7:41 PM
To: Bernard Aboba
Cc: Brian Lindsay; [email-masked]
Subject: Re: [martini] GRUU (was RE: Draft minutes of the IETF 78 MARTINI WG meeting)

Brian,

	Thanks,
	Paul

Bernard Aboba wrote:
> registration mechanism is also required to implement GRUU.  In short - I 
> *         Most existing SIP Trunking deployments do not use/require 
> GRUU's. The main driver for the martini work has always been about 
> *         A baseline set of services can be provided without requiring 
> and doesn't use REFER.  REFER-based transfer is optional, as is the