From bernard_aboba@hotmail.com Sun Aug 22 12:18:17 2010 Return-Path: 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 124C23A688B for ; Sun, 22 Aug 2010 12:18:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.407 X-Spam-Level: X-Spam-Status: No, score=-100.407 tagged_above=-999 required=5 tests=[AWL=-0.409, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 s6ZsMMqMsblL for ; Sun, 22 Aug 2010 12:18:16 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id 24BA63A67F9 for ; Sun, 22 Aug 2010 12:18:16 -0700 (PDT) Received: from BLU137-W9 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 22 Aug 2010 12:18:49 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_b0aa2fed-5b6f-4533-9afe-29477002b393_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Sun, 22 Aug 2010 12:18:49 -0700 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 22 Aug 2010 19:18:49.0585 (UTC) FILETIME=[D98A7610:01CB422E] Subject: [martini] Minutes from IETF 79 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Aug 2010 19:18:17 -0000 --_b0aa2fed-5b6f-4533-9afe-29477002b393_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at IETF 79 and haven't already sent them to the MARTINI= WG mailing list=2C please do so ASAP. =20 Thanks! = --_b0aa2fed-5b6f-4533-9afe-29477002b393_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If you took minutes at IETF 79 and haven't already sent them to the MARTINI= WG mailing list=2C please do so ASAP. =3B

Thanks!
= = --_b0aa2fed-5b6f-4533-9afe-29477002b393_-- From bernard_aboba@hotmail.com Mon Aug 23 14:20:10 2010 Return-Path: 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 889713A68B1 for ; Mon, 23 Aug 2010 14:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.381 X-Spam-Level: X-Spam-Status: No, score=-100.381 tagged_above=-999 required=5 tests=[AWL=-0.383, BAYES_50=0.001, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 IhS+dklpFcXj for ; Mon, 23 Aug 2010 14:20:00 -0700 (PDT) Received: from blu0-omc2-s35.blu0.hotmail.com (blu0-omc2-s35.blu0.hotmail.com [65.55.111.110]) by core3.amsl.com (Postfix) with ESMTP id D8A073A686D for ; Mon, 23 Aug 2010 14:19:59 -0700 (PDT) Received: from BLU137-DS17 ([65.55.111.73]) by blu0-omc2-s35.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 23 Aug 2010 14:20:32 -0700 X-Originating-IP: [131.107.0.72] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 23 Aug 2010 14:20:31 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_055B_01CB42CE.57CE1190" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: ActDCPrYKc9tR1hISSS68JTSczq8CA== X-OriginalArrivalTime: 23 Aug 2010 21:20:32.0652 (UTC) FILETIME=[04EBCCC0:01CB4309] Subject: [martini] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Aug 2010 21:20:11 -0000 ------=_NextPart_000_055B_01CB42CE.57CE1190 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI WG IETF 78 Mintes Chairs: Bernard Aboba Spencer Dawkins 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. ------=_NextPart_000_055B_01CB42CE.57CE1190 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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<= /o:p>

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-ol= ive

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-vermout= h

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.

------=_NextPart_000_055B_01CB42CE.57CE1190-- From brian.lindsay@genband.com Wed Aug 25 11:50:42 2010 Return-Path: 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 ; 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 ; 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 ; 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 To: Bernard Aboba , "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: References: In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 18:50:43 -0000 --_000_F1A0ED6425368141998E077AC43334E414EA7CBCgbplmail01genba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Regarding GRUU, I was unable to attend the IETF 78 WG Meeting, but I wou= ld like to object to the outcome regarding mandating support for GRUU on th= e SSP. There was discussion of the topic on the list in July, and I believe the= re was no consensus on mandating GRUU at that time, so I think the topic i= s one that could be valid for the broader set of list participants to consi= der. My view is that is that it is appropriate for the GIN draft to define ho= w GRUU interacts with the GIN registration mechanism, but there does not ne= ed to be a coupling/dependency such that an implementer of the GIN registra= tion 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 conc= erned * 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 b= aseline call transfer capability defined that uses re-invites and doesn't u= se REFER. REFER-based transfer is optional, as is the usage of out-of-dial= og REFER. (The language actually discourages use of REFER due to billing ri= sks/considerations). The discussions on temporary GRUUs for privacy also seem to be exceedin= g 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 Spencer Dawkins 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 d= omain 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.c= om" 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 - authorizatio= n 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. --_000_F1A0ED6425368141998E077AC43334E414EA7CBCgbplmail01genba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Regarding G= RUU, 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.<= /p>

There was discussion of the topic on the list in July, and I believe there was no con= sensus on mandating GRUU at that time, so I think the topic is one that coul= d 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/depend= ency 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 t= he 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 i= s 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 d= raft of SIP Connect 1.1 ( http://www.sipforum.org/component/option,com_doc= man/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 REF= ER due to billing risks/considerations).

The discussions on temporary GRUUs for privacy also seem to be exceeding the sc= ope of the original focus of MARTINI and the requirements document. There was n= ever 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.co= m

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 Kyziv= at 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.&n= bsp; 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 mat= ches the text

in requirements specification.

No objection to Issue 4 and Issue 5.

Ticket 49 – nits. Changed. Keith requested consi= stency on a number of

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

Ticket 50: propose to update inline with suggestions i= n the ticket.

Query made if any objections to the above tickets. The= re were none.

Ticket 51: ticket submitter proposed one resolution, A= dam 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&= quot; without definition.

Adam agrees to fix that, make it clear what is intende= d.

Everywhere we have BNC before another term, it needs t= o 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 t= o reg event

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

parameter" add "in an extension".<= /o:p>

Ticket 56: about security review. Discussion of what t= he 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 argue= d strongly

for mandatory to implement for public GRUU. There was clarification

that these requirements are on the SSP. There was cons= ensus that it be

mandatory for an SSP implementing gin to supply a publ= ic gruu when

requested by the registering PBX.

Then discussion moved to temp GRUU. Debate among Culle= n and Hadriel.

Cullen argues for support of confidentiality – n= eed 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 man= gle public

GRUUs. Hadriel asserted that he sells boxes that do th= is 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 tha= t that mandating

support by SSPs might raise the bar too high and disco= urage SSPs from

implementing GIN. Keith was concerned that we are havi= ng 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 an= d try to figure this out.

Will pick it up then.

Individual Submissions (60 minutes)

Other Logical Identifier Values (OLIVE), Hadriel Kapla= n

http://tools.ietf.org/html/draft-kaplan-martini-with-o= live

Hadriel gave summary. There were a number of clarifyin= g questions.

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

provide. Adam observed that its perfectly reasonable t= o assume the SSP

could host your own domain name and then arbitrary use= r names within that domain name.

Then got on to local numbers. Cullen suggests splittin= g this into

separate drafts for alphanumeric user names and local numbers because.

About 10 people in the room thought it was worth solvi= ng the "Bob@example.com"

problem – alphanumeric user names. This is simpl= y 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') an= d the other for numeric

addresses (but not E.164 numbers): "1234&qu= ot;.

MARTINI Event Package for Registration (VERMOUTH), Had= riel Kaplan

http://tools.ietf.org/html/draft-kaplan-martini-vermou= th

Hadriel gave an overview. Normal subscription get rout= ed to the PBX.

Presented two alternatives – use reg-event with =

extensions or a new event package. John Elwell questio= ned 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 pac= kage.

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 prop= osed 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.

--_000_F1A0ED6425368141998E077AC43334E414EA7CBCgbplmail01genba_-- From bernard_aboba@hotmail.com Wed Aug 25 14:02:11 2010 Return-Path: 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 C25423A6903 for ; Wed, 25 Aug 2010 14:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.663 X-Spam-Level: X-Spam-Status: No, score=-101.663 tagged_above=-999 required=5 tests=[AWL=0.935, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] 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 rrIBH0nXr98E for ; Wed, 25 Aug 2010 14:02:00 -0700 (PDT) Received: from blu0-omc4-s26.blu0.hotmail.com (blu0-omc4-s26.blu0.hotmail.com [65.55.111.165]) by core3.amsl.com (Postfix) with ESMTP id C5C1D3A68E3 for ; Wed, 25 Aug 2010 14:01:59 -0700 (PDT) Received: from BLU137-DS17 ([65.55.111.137]) by blu0-omc4-s26.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 25 Aug 2010 14:02:31 -0700 X-Originating-IP: [131.107.0.117] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: "'Brian Lindsay'" , References: In-Reply-To: Date: Wed, 25 Aug 2010 14:03:20 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000A_01CB445E.46ADF010" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: ActDCPrYKc9tR1hISSS68JTSczq8CABdHRUQAAbQ8ZA= Content-Language: en-us X-OriginalArrivalTime: 25 Aug 2010 21:02:31.0919 (UTC) FILETIME=[D59487F0:01CB4498] Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:02:11 -0000 ------=_NextPart_000_000A_01CB445E.46ADF010 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:brian.lindsay@genband.com] Sent: Wednesday, August 25, 2010 11:50 AM To: Bernard Aboba; martini@ietf.org 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 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 Spencer Dawkins 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. ------=_NextPart_000_000A_01CB445E.46ADF010 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:brian.lindsay@genband.com]
Sent: Wednesday, August 25, 2010 11:50 AM
To: Bernard Aboba; martini@ietf.org
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

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<= /o:p>

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-ol= ive

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-vermout= h

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.

------=_NextPart_000_000A_01CB445E.46ADF010-- From brian.lindsay@genband.com Wed Aug 25 14:15:11 2010 Return-Path: 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 129593A6942 for ; Wed, 25 Aug 2010 14:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.382 X-Spam-Level: X-Spam-Status: No, score=-6.382 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, 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 ahj6QK56+afz for ; Wed, 25 Aug 2010 14:15:00 -0700 (PDT) Received: from exprod7og111.obsmtp.com (exprod7og111.obsmtp.com [64.18.2.175]) by core3.amsl.com (Postfix) with ESMTP id F2A953A6926 for ; Wed, 25 Aug 2010 14:14:42 -0700 (PDT) Received: from source ([63.149.188.88]) (using TLSv1) by exprod7ob111.postini.com ([64.18.6.12]) with SMTP ID DSNKTHWH4Tyv9HmT4PjPrcyIRv8+vVC6Qssp@postini.com; Wed, 25 Aug 2010 14:15:18 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 16:12:23 -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 16:12:22 -0500 From: Brian Lindsay To: Bernard Aboba , "martini@ietf.org" Thread-Topic: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG meeting) Thread-Index: ActDCPrYKc9tR1hISSS68JTSczq8CABdHRUQAAbQ8ZAAABXmIA== Date: Wed, 25 Aug 2010 21:12:20 +0000 Message-ID: References:

In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_F1A0ED6425368141998E077AC43334E414EA80E7gbplmail01genba_" MIME-Version: 1.0 X-OriginalArrivalTime: 25 Aug 2010 21:12:23.0040 (UTC) FILETIME=[35EA7000:01CB449A] X-TM-AS-Product-Ver: SMEX-8.0.0.4160-6.500.1024-17596.002 X-TM-AS-Result: No--32.455600-5.000000-31 X-TM-AS-User-Approved-Sender: No X-TM-AS-User-Blocked-Sender: No Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Aug 2010 21:15:11 -0000 --_000_F1A0ED6425368141998E077AC43334E414EA80E7gbplmail01genba_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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:bernard_aboba@hotmail.com] Sent: Wednesday, August 25, 2010 5:03 PM To: Brian Lindsay; martini@ietf.org Subject: RE: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI W= G 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 f= or MAY? From: Brian Lindsay [mailto:brian.lindsay@genband.com] Sent: Wednesday, August 25, 2010 11:50 AM To: Bernard Aboba; martini@ietf.org Subject: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTINI WG me= eting) Hi, Regarding GRUU, I was unable to attend the IETF 78 WG Meeting, but I wou= ld like to object to the outcome regarding mandating support for GRUU on th= e SSP. There was discussion of the topic on the list in July, and I believe the= re was no consensus on mandating GRUU at that time, so I think the topic i= s one that could be valid for the broader set of list participants to consi= der. My view is that is that it is appropriate for the GIN draft to define ho= w GRUU interacts with the GIN registration mechanism, but there does not ne= ed to be a coupling/dependency such that an implementer of the GIN registra= tion 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 conc= erned * 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 b= aseline call transfer capability defined that uses re-invites and doesn't u= se REFER. REFER-based transfer is optional, as is the usage of out-of-dial= og REFER. (The language actually discourages use of REFER due to billing ri= sks/considerations). The discussions on temporary GRUUs for privacy also seem to be exceedin= g 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 Spencer Dawkins 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 d= omain 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.c= om" 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 - authorizatio= n 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. --_000_F1A0ED6425368141998E077AC43334E414EA80E7gbplmail01genba_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Bernard,

I’m a= rguing for a MAY for both.

This text a= ddition 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:bernard_aboba@hotmail.com]
Sent: Wednesday, August 25, 2010 5:03 PM
To: Brian Lindsay; martini@ietf.org
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:brian.lindsay@genband.com]
Sent: Wednesday, August 25, 2010 11:50 AM
To: Bernard Aboba; martini@ietf.org
Subject: GRUU (was RE: [martini] Draft minutes of the IETF 78 MARTIN= I WG meeting)

Hi,

Regarding G= RUU, 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.<= /p>

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.

Why?

· The GRUU RFC i= s 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 d= raft of SIP Connect 1.1 ( http://www.sipforum.org/component/option,com_docman/task,cat_view/gid,84/It= emid,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 REF= ER due to billing risks/considerations).