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

Brian Lindsay <brian.lindsay@genband.com> Wed, 25 August 2010 18:50 UTC

Return-Path: <brian.lindsay@genband.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF8A93A68F3 for <martini@core3.amsl.com>; Wed, 25 Aug 2010 11:50:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.298
X-Spam-Level:
X-Spam-Status: No, score=-5.298 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1DvG+n+WO6y for <martini@core3.amsl.com>; Wed, 25 Aug 2010 11:50:28 -0700 (PDT)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 05F4B3A687F for <martini@ietf.org>; Wed, 25 Aug 2010 11:50:27 -0700 (PDT)
Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKTHVmFB+uwNRZxwPVe+xkx9tRK/kQ8i8D@postini.com; Wed, 25 Aug 2010 11:51:01 PDT
Received: from owa.genband.com ([172.16.21.97]) by mail.genband.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 13:50:19 -0500
Received: from GBPLMAIL01.genband.com ([fe80::70bf:29d1:2cfe:42b5]) by GBEX01.genband.com ([fe80::8d5f:3299:f2:285c%14]) with mapi; Wed, 25 Aug 2010 13:50:18 -0500
From: Brian Lindsay <brian.lindsay@genband.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>, "martini@ietf.org" <martini@ietf.org>
Thread-Topic: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG meeting)
Thread-Index: ActDCPrYKc9tR1hISSS68JTSczq8CABdHRUQ
Date: Wed, 25 Aug 2010 18:50:15 +0000
Message-ID: <F1A0ED6425368141998E077AC43334E414EA7CBC@gbplmail01.genband.com>
References: <BLU137-DS1702DB8E15AB61E03417A493820@phx.gbl>
In-Reply-To: <BLU137-DS1702DB8E15AB61E03417A493820@phx.gbl>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_F1A0ED6425368141998E077AC43334E414EA7CBCgbplmail01genba_"
MIME-Version: 1.0
X-OriginalArrivalTime: 25 Aug 2010 18:50:19.0235 (UTC) FILETIME=[5D550330:01CB4486]
X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-17596.001
X-TM-AS-Result: No--26.880400-5.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Subject: [martini] GRUU (was RE: Draft minutes of the IETF 78 MARTINI WG meeting)
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 25 Aug 2010 18:50:43 -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
brian.lindsay@genband.com

From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Bernard Aboba
Sent: Monday, August 23, 2010 5:21 PM
To: martini@ietf.org
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 "Bob@example.com"
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. "bob@example.com') 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.