Re: [martini] GRUU (was RE: Draft minutes of the IETF 78 MARTINI WG meeting)

[Paul Kyzivat <[e-mail]>]

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:[e-mail]]
> *Sent:* Wednesday, August 25, 2010 11:50 AM
> *To:* Bernard Aboba; [e-mail]
> *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/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
> 
> [e-mail]
> 
>  
> 
> *From:* [e-mail] [mailto:[e-mail]] *On 
> Behalf Of *Bernard Aboba
> *Sent:* Monday, August 23, 2010 5:21 PM
> *To:* [e-mail]
> *Subject:* [martini] Draft minutes of the IETF 78 MARTINI WG meeting
> 
>  
> 
> 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 
> "[e-mail]"
> 
> 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. "[e-mail]') 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.
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> martini mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/martini