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

["Bernard Aboba" <[e-mail]>]

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/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

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.