From spencer@wonderhamster.org Mon Jun 7 11:00:58 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 9CCF23A67B6; Mon, 7 Jun 2010 11:00:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.136 X-Spam-Level: ** X-Spam-Status: No, score=2.136 tagged_above=-999 required=5 tests=[BAYES_50=0.001, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] 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 Z1uxwjmAhCIm; Mon, 7 Jun 2010 11:00:57 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id D273B3A67AE; Mon, 7 Jun 2010 11:00:57 -0700 (PDT) Received: from S73602b ([74.10.171.73]) by mrelay.perfora.net (node=mrus1) with ESMTP (Nemesis) id 0LZgcW-1P0V2I1a0a-00mIsm; Mon, 07 Jun 2010 14:00:58 -0400 Message-ID: From: "Spencer Dawkins" To: , "SIP-CLF Mailing List" , Date: Mon, 7 Jun 2010 13:00:48 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX18d2VhLBGBxP06H7DyRZsrrvJCIHHq6sYYzBKb Gih4TZPAvx7N1vFxOclVU0YlxQrJ0mrn8OH6r4Z90WStsWa/4B HnEVR9syh+LKE0LpkfKLxHKgav+zPn8sw4M9KuJ3aY= Subject: [martini] Fw: IETF Mail Delays - Resolved 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, 07 Jun 2010 18:00:58 -0000 Just to let people know - I saw that one e-mail to MEDIACTRL seems to have been delayed, so you might have also seen delays on other IETF-hosted mailing lists as well. Spencer ----- Original Message ----- From: "Glen Barney (AMS)" To: "Glen Barney (AMS)" Sent: Monday, June 07, 2010 9:57 AM Subject: IETF Mail Delays - Resolved > Good morning: > > This morning I received emergency alerts from Lars and Dan regarding mail > not > flowing through the server. > > As previously mentioned, an automatic database update from ClamAv - the > virus scanning software we use to scan incoming mail for viruses - was > causing ClamAv to crash. Incoming mail was still being accepted by the > server, and the mail processes were still up, but the internal virus > scanning system was crashing causing mail to be delayed inside the server. > > I was unable to get any portion of the ClamAv system to function correctly > after the database update that came in, and I was unable to construct an > older version of the database without expending a significant amount of > time; therefore, I chose to completely remove the OS-supplied version of > ClamAv and rebuild a new version from scratch. > > This process has been completed, and the new ClamAv appears to be > functioning > perfectly. Mail is now flowing through the system and being delivered > correctly. No mail appears to have been lost. We'll watch to make sure > there are no other problems surrounding this event. Let me know if you > have > any questions. > > Thanks, > Glen > > Glen Barney > IT Director > AMS (IETF Secretariat) From wwwrun@core3.amsl.com Tue Jun 8 06:50:49 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 6F24E28C1B2; Tue, 8 Jun 2010 06:50:49 -0700 (PDT) X-idtracker: yes To: IETF-Announce From: The IESG Message-Id: <20100608135049.6F24E28C1B2@core3.amsl.com> Date: Tue, 8 Jun 2010 06:50:49 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] Last Call: draft-ietf-martini-reqs (Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP)) to Informational RFC X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Jun 2010 13:50:49 -0000 The IESG has received a request from the Multiple AoR reachabiliTy InformatioN Indication WG (martini) to consider the following document: - 'Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-06-22. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-07.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=19614&rfc_flag=0 From bernarda@microsoft.com Fri Jun 11 21:23:06 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 34C8C28C0F7 for ; Fri, 11 Jun 2010 21:23:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.998 X-Spam-Level: X-Spam-Status: No, score=-7.998 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 LTeZA365GrGz for ; Fri, 11 Jun 2010 21:23:01 -0700 (PDT) Received: from smtp.microsoft.com (mail1.microsoft.com [131.107.115.212]) by core3.amsl.com (Postfix) with ESMTP id CFC9F28C110 for ; Fri, 11 Jun 2010 21:23:01 -0700 (PDT) Received: from TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) by TK5-EXGWY-E801.partners.extranet.microsoft.com (10.251.56.50) with Microsoft SMTP Server (TLS) id 8.2.176.0; Fri, 11 Jun 2010 21:23:04 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14MLTC104.redmond.corp.microsoft.com (157.54.79.159) with Microsoft SMTP Server (TLS) id 14.1.160.7; Fri, 11 Jun 2010 21:23:04 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.91]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Fri, 11 Jun 2010 21:23:05 -0700 From: Bernard Aboba To: "'martini@ietf.org'" Thread-Topic: Agenda MARTINI Virtual Interim on Wednesday, June 16, 2010 -- Take One Thread-Index: AcsJ5yWlTGn5+1NURNSVi/eorFQvsA== Date: Sat, 12 Jun 2010 04:24:28 +0000 Message-ID: <3E368C9530D1B640AA7BAE85FECC05BF12526502@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E368C9530D1B640AA7BAE85FECC05BF12526502TK5EX14MBXW651w_" MIME-Version: 1.0 Subject: [martini] Agenda MARTINI Virtual Interim on Wednesday, June 16, 2010 -- Take One 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: Sat, 12 Jun 2010 04:23:06 -0000 --_000_3E368C9530D1B640AA7BAE85FECC05BF12526502TK5EX14MBXW651w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that MARTINI will be having a Virtual Interim on Wednesday = June 16, 2010 from 11 AM - 1 PM Pacific. A strawman agenda is given below. If you'd like to be on the Agenda, ple= ase notify Spencer & myself ASAP (and get us slides no later than Tuesday a= fternoon). Agenda MARTINI Virtual Interim V Wednesday, June 16, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: TBD Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Solution Updates (30 minutes) 11:10 AM - 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam Ro= ach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (30 minutes) 11:40 AM - 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel Ka= plan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive 11:55 AM - 12:25 PM PT, MARTINI Event Package for Registration (VERMOUTH), = Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth Discussion and Wrap-up (35 minutes) 12:25 AM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1 PM PT Next Steps: WG Chairs & ADs (10 minutes) --_000_3E368C9530D1B640AA7BAE85FECC05BF12526502TK5EX14MBXW651w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that MARTINI will be having a Virtual Interim on Wednesday June 16, 2010 from 11 AM – 1 PM Pacific.

 

A strawman agenda is given below.   If you&#= 8217;d like to be on the Agenda,  please notify Spencer & myself ASAP (an= d get us slides no later than Tuesday afternoon).

 

Agenda

MARTINI Virtual Interim V

Wednesday, June 16, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/<= o:p>

Jabber room:  martini at jabber.ietf.org (Please join)

Dial in Audioconference and WebEx details:   TBD

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Solution Updates (30 minutes)

 

11:10 AM – 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam Ro= ach (30 minutes)

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

 

Individual Submissions (30 minutes)

 

11:40 AM – 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel Ka= plan (15 minutes)

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

 

11:55 AM – 12:25 PM PT, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (15 minutes)

http://to= ols.ietf.org/html/draft-kaplan-martini-vermouth

 

 

Discussion and Wrap-up (35 minutes)

 

12:25 AM – 12:40 PM  PT Discussion:  Participants (15 minutes)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)=

12:50 PM – 1 PM PT   Next Steps:  WG Chairs & ADs (10 minutes)

 

 

 

--_000_3E368C9530D1B640AA7BAE85FECC05BF12526502TK5EX14MBXW651w_-- From bernard_aboba@hotmail.com Fri Jun 11 21:23:40 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 42F0F3A6843 for ; Fri, 11 Jun 2010 21:23:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.224 X-Spam-Level: ** X-Spam-Status: No, score=2.224 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_95=3, SARE_OBFU_SPLIT_HR2=0.183] 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 H-dWli3c5XE4 for ; Fri, 11 Jun 2010 21:23:39 -0700 (PDT) Received: from blu0-omc2-s8.blu0.hotmail.com (blu0-omc2-s8.blu0.hotmail.com [65.55.111.83]) by core3.amsl.com (Postfix) with ESMTP id 631943A67FB for ; Fri, 11 Jun 2010 21:23:39 -0700 (PDT) Received: from BLU137-DS13 ([65.55.111.71]) by blu0-omc2-s8.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 11 Jun 2010 21:23:42 -0700 X-Originating-IP: [75.164.144.193] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Fri, 11 Jun 2010 21:25:06 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93wYi+plw Content-Language: en-us X-OriginalArrivalTime: 12 Jun 2010 04:23:42.0432 (UTC) FILETIME=[0A410600:01CB09E7] Subject: [martini] MARTINI Virtual Interim V 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: Sat, 12 Jun 2010 04:23:40 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100612T042506Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: Teleconference\, details TBD\n\nNote: T he GMT offset above does not reflect daylight saving time adjustments.\n\n *~*~*~*~*~*~*~*~*~*\n\nAgenda\nMARTINI Virtual Interim V\nWednesday\, June 16\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nSlide Pr esentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/\nJabbe r room: martini at jabber.ietf.org (Please join)\nDial in Audioconference and WebEx details: TBD\n\nAgenda\n\n11 AM - 11:10 AM PT: Preliminaries \n Conference issues/debugging\n Note Well\n Note Takers\n Agenda bash\n\nSolution Updates (30 minutes)\n\n11:10 AM – 11:40 AM PT\ , MARTINI with Globally Identifiable Numbers\, Adam Roach (30 minutes)\nht tp://tools.ietf.org/html/draft-ietf-martini-gin\n\nIndividual Submissions (30 minutes)\n\n11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (15 minutes)\nhttp://tools.ietf.org/html/draft-k aplan-martini-with-olive\n\n11:55 AM – 12:25 PM PT\, MARTINI Event Packa ge for Registration (VERMOUTH)\, Hadriel Kaplan (15 minutes)\nhttp://tools .ietf.org/html/draft-kaplan-martini-vermouth\n\n\nDiscussion and Wrap-up ( 35 minutes)\n\n12:25 AM – 12:40 PM PT Discussion: Participants (15 min utes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes)\n12:50 PM – 1 PM PT Next Steps: WG Chairs & ADs (10 minutes)\n\n\n\n\n DTEND:20100616T200000Z DTSTAMP:20100612T042506Z DTSTART:20100616T180000Z LAST-MODIFIED:20100612T042506Z LOCATION:Teleconference\, details TBD ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:1 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: Teleconference\, details TBD\n\n

Note: The GMT off set above does not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~* ~*~*

\n\n

Agenda

\n\n

MARTINI Virtual Interim V

\n\n

Wednesday\, June 16\, 2010

\n\n

11 AM – 1 PM Pacific Time

\n\n

Conferencing Details:

\n\n

S lide Presentations:  http://www.drizzle.com/~aboba/MARTINI/June-Inter im-V/

\n\n

Jabber room:  martin i at jabber.ietf.org (Please join)

\n\n

Dial in Audioconference and We bEx details:   TBD

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preli minaries

\n\n

     Conference issues/debugging

\n \n

     N ote Well

\n\n

     Note Takers

\n\n

     Agenda bash

\n\n

Solution Updates (30 minutes)

\n\n

11:10 AM – 11:40 AM PT\, MART INI with Globally Identifiable Numbers\, Adam Roach (30 minutes)

\n\n

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

\n\n

Individual Submissions (30 minutes)

\n\n

11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Ha driel Kaplan (15 minutes)

\n\n

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

\n\n

11:55 AM – 12:25 PM PT\, MARTINI Event Package for Registrati on (VERMOUTH)\, Hadriel Kaplan (15 minutes)

\n\n

< SPAN LANG="en-us">http: //tools.ietf.org/html/draft-kaplan-martini-vermouth

\n
\n\n

< FONT SIZE=2 FACE="Courier New">Discussion and Wrap-up (35 minutes)< /SPAN>

\n\n

12:25 AM – 12:40 PM  PT Discussion:  Participants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)< /P>\n\n

12:50 PM – 1 PM PT   Next Steps:  WG Chairs &\; ADs (10 minutes)

\n\n

\n\n

\n\n

\n \n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTSEQTIME:20100511T224305Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Mon Jun 14 09:52:43 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 211403A687C for ; Mon, 14 Jun 2010 09:52:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.793 X-Spam-Level: X-Spam-Status: No, score=0.793 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 B4hsBAJ6Sgp3 for ; Mon, 14 Jun 2010 09:51:24 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by core3.amsl.com (Postfix) with ESMTP id 5E8EC3A6817 for ; Mon, 14 Jun 2010 09:51:24 -0700 (PDT) Received: from BLU137-DS14 ([65.55.111.71]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 09:51:28 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 14 Jun 2010 09:52:53 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0048_01CB0BA7.5BDB8C30" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsL4gfRXICQ/PcTQ/y9Xtwc538s+Q== Content-Language: en-us X-OriginalArrivalTime: 14 Jun 2010 16:51:28.0142 (UTC) FILETIME=[D52092E0:01CB0BE1] Subject: [martini] WebEx parameters for June 16 Virtual Interim 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, 14 Jun 2010 16:52:43 -0000 ------=_NextPart_000_0048_01CB0BA7.5BDB8C30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI Virtual Interim V June 16, 2010 Time: 11 AM - 1 PM pacific Time ------------------------------------------------------- To join the online meeting (Now from iPhones too!) ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/j.php?ED=134516692 &UID=1127822057&RT=MiM0 2. If requested, enter your name and email address. 3. If a password is required, enter the meeting password: (This meeting does not require a password.) 4. Click "Join". 5. Follow the instructions that appear on your screen. To view in other time zones or languages, please click the link: https://workgreen.webex.com/workgreen/j.php?ED=134516692 &UID=1127822057&ORT=MiM0 ------------------------------------------------------- To join the audio conference only ------------------------------------------------------- To receive a call back, provide your phone number when you join the meeting, or call the number below and enter the access code. Call-in toll-free number (US/Canada): 1-866-699-3239 Call-in toll number (US/Canada): 1-408-792-6300 Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?serviceType=MC &ED=134516692&tollFree=1 Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Access code:960 408 698 ------------------------------------------------------- For assistance ------------------------------------------------------- 1. Go to https://workgreen.webex.com/workgreen/mc 2. On the left navigation bar, click "Support". You can contact me at: amorris@amsl.com 1-510-492-4081 To update this meeting to your calendar program (for example Microsoft Outlook), click this link: https://workgreen.webex.com/workgreen/j.php?ED=134516692 &UID=1127822057&ICS=UMI&LD=1&RD=2&ST=1&SHA2=vgU7HYosinVqu5gfAI1Emg/tFVjTJyc4 V-8mA9TbcxE=&RT=MiM0 WebEx will automatically setup Meeting Manager for Windows the first time you join a meeting. To save time, you can setup prior to the meeting by clicking this link: https://workgreen.webex.com/workgreen/meetingcenter/mcsetup.php The playback of UCF (Universal Communications Format) rich media files requires appropriate players. To view this type of rich media files in the meeting, please check whether you have the players installed on your computer by going to https://workgreen.webex.com/workgreen/systemdiagnosis.php http://www.webex.com ------=_NextPart_000_0048_01CB0BA7.5BDB8C30 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI Virtual Interim V

June 16, 2010

Time: 11 AM – 1 PM pacific Time


-------------------------------------------------------
To join the online meeting (Now from iPhones too!)
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/j.php?ED=3D134516= 692&UID=3D1127822057&RT=3DMiM0
2. If requested, enter your name and email address.
3. If a password is required, enter the meeting password: (This meeting = does not require a password.)
4. Click "Join".
5. Follow the instructions that appear on your screen.

To view in other time zones or languages, please click the link:
https://workgreen.webex.com/workgreen/j.php?ED=3D134516= 692&UID=3D1127822057&ORT=3DMiM0

-------------------------------------------------------
To join the audio conference only
-------------------------------------------------------
To receive a call back, provide your phone number when you join the = meeting, or call the number below and enter the access code.
Call-in toll-free number (US/Canada): 1-866-699-3239
Call-in toll number (US/Canada): 1-408-792-6300
Global call-in numbers: https://workgreen.webex.com/workgreen/globalcallin.php?= serviceType=3DMC&ED=3D134516692&tollFree=3D1
Toll-free dialing restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf

Access code:960 408 698

-------------------------------------------------------
For assistance
-------------------------------------------------------
1. Go to https://workgreen.webex.com/workgreen/mc
2. On the left navigation bar, click "Support".

You can contact me at:
amorris@amsl.com
1-510-492-4081

To update this meeting to your calendar program (for example Microsoft Outlook), click this link:
https://workgreen.webex.com/workgreen/j.php?ED=3D134516= 692&UID=3D1127822057&ICS=3DUMI&LD=3D1&RD=3D2&ST=3D1&a= mp;SHA2=3DvgU7HYosinVqu5gfAI1Emg/tFVjTJyc4V-8mA9TbcxE=3D&RT=3DMiM0


WebEx will automatically setup Meeting Manager for Windows the first = time you join a meeting. To save time, you can setup prior to the meeting by = clicking this link:
https://workgreen.webex.com/workgreen/meetingcenter/mcs= etup.php


The playback of UCF (Universal Communications Format) rich media files = requires appropriate players. To view this type of rich media files in the = meeting, please check whether you have the players installed on your computer by = going to https://workgreen.webex.com/workgreen/systemdiagnosis.p= hp

http://www.webex.com



------=_NextPart_000_0048_01CB0BA7.5BDB8C30-- From bernard_aboba@hotmail.com Mon Jun 14 10:22:15 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 5EF1F3A69A3 for ; Mon, 14 Jun 2010 10:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.771 X-Spam-Level: X-Spam-Status: No, score=0.771 tagged_above=-999 required=5 tests=[AWL=0.587, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] 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 UpNMrrJW+B2I for ; Mon, 14 Jun 2010 10:22:14 -0700 (PDT) Received: from blu0-omc2-s32.blu0.hotmail.com (blu0-omc2-s32.blu0.hotmail.com [65.55.111.107]) by core3.amsl.com (Postfix) with ESMTP id 4E3843A69EB for ; Mon, 14 Jun 2010 10:22:14 -0700 (PDT) Received: from BLU137-DS2 ([65.55.111.72]) by blu0-omc2-s32.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:22:18 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 14 Jun 2010 10:23:42 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93waiwQng Content-Language: en-us X-OriginalArrivalTime: 14 Jun 2010 17:22:18.0437 (UTC) FILETIME=[23FD2F50:01CB0BE6] Subject: [martini] MARTINI Virtual Interim V 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, 14 Jun 2010 17:22:15 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100614T172342Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: See http://www.ietf.org/mail-archive/we b/martini/current/msg01670.html for details\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nAgenda\nMARTINI Virtual Interim V\nWednesday\, June 16\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nSlide Presentations: http ://www.drizzle.com/~aboba/MARTINI/June-Interim-V/\nJabber room: martini a t jabber.ietf.org (Please join)\nDial in Audioconference and WebEx details : http://www.ietf.org/mail-archive/web/martini/current/msg01670.html\n \n Agenda\n\n11 AM - 11:10 AM PT: Preliminaries\n Conference issues/debu gging\n Note Well\n Note Takers\n Agenda bash\n\nSolution Upda tes (40 minutes)\n\n11:10 AM – 11:50 AM PT\, MARTINI with Globally Ident ifiable Numbers\, Adam Roach (40 minutes)\nhttp://tools.ietf.org/html/draf t-ietf-martini-gin\n\nIndividual Submissions (40 minutes)\n\n11:50 AM – 12:10 PM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (20 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-martini-with-olive\n\n1 2:10 PM – 12:30 PM PT\, MARTINI Event Package for Registration (VERMOUTH )\, Hadriel Kaplan (20 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-m artini-vermouth\n\n\nDiscussion and Wrap-up (35 minutes)\n\n12:30 PM – 1 2:40 PM PT Discussion: Participants (10 minutes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes)\n12:50 PM – 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes)\n\n\n\n\n DTEND:20100616T200000Z DTSTAMP:20100614T172342Z DTSTART:20100616T180000Z LAST-MODIFIED:20100614T172342Z LOCATION:See http://www.ietf.org/mail-archive/web/martini/current/msg01670. html for details ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:2 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: See http://www.ietf.org/mail-archive/web/ martini/current/msg01670.html for details

\n\n

Note: The GMT offset above doe s not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Agenda< /P>\n\n

MARTI NI Virtual Interim V

\n\n

Wednesday\, June 16\, 2010

\n\n

11 AM – 1 PM Pacific Time

\n\n

< FONT SIZE=2 FACE="Courier New">Conferencing Details:

\n\n

Slide Presen tations:  http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/

\n\n

Jabber room:  martini at jabber .ietf.org (Please join)

\n\n

Dial in Audioconference and WebEx details :   http://www.ietf.org/mail-archive/web/martini/current /msg01670.html

\n\n

 \;

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

      Conference issues/debugging

\n\n

     Note Well\n\n

      Note Takers

\n\n

     Agenda bash

\n\n

Solution Updates (40 minutes)

\n\n

11:10 AM – 11:50 AM PT\, MARTINI with Globally Identi fiable Numbers\, Adam Roach (40 minutes)

\n\n

< SPAN LANG="en-us">http://tools.ie tf.org/html/draft-ietf-martini-gin

\n\n

Individual Submissions (40 minutes)

\n\n

11:50 AM – 12:10 PM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (20 minutes )

\n\n

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

\n\n< P DIR=LTR>12:10 PM – 12:30 PM PT\, MARTINI Event Package for Registration (VERMOUTH)\, Hadriel Kaplan (20 minutes)

\n\n

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

\n
\n\n

Discussion and Wrap-up (35 minutes)

\n\n

12:30 PM – 12:40 PM  PT \; Discussion:  Participants (10 minutes)

\n\n< P DIR=LTR>12:40 PM - 12 :50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12:50 PM – \; 1: 00 PM PT  Next Steps:  WG Chairs &\; ADs (10 minutes)< /P>\n\n

\n\n

\n\n

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:1 X-MS-OLK-APPTSEQTIME:20100612T042506Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Mon Jun 14 10:23:13 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 3BDA73A69A3 for ; Mon, 14 Jun 2010 10:23:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.607 X-Spam-Level: X-Spam-Status: No, score=0.607 tagged_above=-999 required=5 tests=[AWL=0.605, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 NdvbSbZo3iYy for ; Mon, 14 Jun 2010 10:23:11 -0700 (PDT) Received: from blu0-omc2-s20.blu0.hotmail.com (blu0-omc2-s20.blu0.hotmail.com [65.55.111.95]) by core3.amsl.com (Postfix) with ESMTP id E43CC3A68DC for ; Mon, 14 Jun 2010 10:23:10 -0700 (PDT) Received: from BLU137-DS7 ([65.55.111.71]) by blu0-omc2-s20.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 14 Jun 2010 10:23:14 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 14 Jun 2010 10:24:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0053_01CB0BAB.CC2A52B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsL5nhBicM7m7GdTGOvnaaqm8HJAg== Content-Language: en-us X-OriginalArrivalTime: 14 Jun 2010 17:23:14.0853 (UTC) FILETIME=[459D9550:01CB0BE6] Subject: [martini] MARTINI Virtual Interim V Agenda - Take Two 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, 14 Jun 2010 17:23:13 -0000 ------=_NextPart_000_0053_01CB0BAB.CC2A52B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda MARTINI Virtual Interim V Wednesday, June 16, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg01670.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Solution Updates (40 minutes) 11:10 AM - 11:50 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (40 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (40 minutes) 11:50 AM - 12:10 PM PT, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (20 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive 12:10 PM - 12:30 PM PT, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (20 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth Discussion and Wrap-up (35 minutes) 12:30 PM - 12:40 PM PT Discussion: Participants (10 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_0053_01CB0BAB.CC2A52B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda

MARTINI Virtual Interim V

Wednesday, June 16, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  http://www= .drizzle.com/~aboba/MARTINI/June-Interim-V/

Jabber room:  martini at jabber.ietf.org (Please = join)

Dial in Audioconference and WebEx details:  http://www.ietf.org/mail-archive/web/martini/current/msg01670.html=

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Solution Updates (40 minutes)

 

11:10 AM – 11:50 AM PT, MARTINI with Globally Identifiable Numbers, Adam = Roach (40 minutes)

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

 

Individual Submissions (40 minutes)

 

11:50 AM – 12:10 PM PT, Other Logical Identifier Values (OLIVE), Hadriel = Kaplan (20 minutes)

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

 

12:10 PM – 12:30 PM PT, MARTINI Event Package for Registration = (VERMOUTH), Hadriel Kaplan (20 minutes)

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

 

 

Discussion and Wrap-up (35 minutes)

 

12:30 PM – 12:40 PM PT  Discussion:  Participants (10 = minutes)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 = minutes)

12:50 PM –  1:00 PM PT  Next Steps:  WG Chairs & = ADs (10 minutes)

 

------=_NextPart_000_0053_01CB0BAB.CC2A52B0-- From trac@tools.ietf.org Mon Jun 14 14:53:07 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 75C2B3A69BC for ; Mon, 14 Jun 2010 14:53:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.309 X-Spam-Level: X-Spam-Status: No, score=-102.309 tagged_above=-999 required=5 tests=[AWL=0.291, BAYES_00=-2.599, NO_RELAYS=-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 vrZvoRkaiIrM for ; Mon, 14 Jun 2010 14:53:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 9E4453A69A6 for ; Mon, 14 Jun 2010 14:53:06 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OOHag-000672-KH; Mon, 14 Jun 2010 14:53:10 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Mon, 14 Jun 2010 21:53:10 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/41#comment:1 Message-ID: <073.7f44ed4b925dcfd53a416c6297c769d0@tools.ietf.org> References: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> X-Trac-Ticket-ID: 41 In-Reply-To: <064.c7f9b407eec269da298fd711cd7baeaa@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #41: What happens to a "presence" Subscription for an E.164 AoR? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 14 Jun 2010 21:53:07 -0000 #41: What happens to a "presence" Subscription for an E.164 AoR? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: wontfix Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => wontfix Comment: Answered on-list, no document action appears necessary. -- Ticket URL: martini From Adam.Roach@tekelec.com Mon Jun 14 12:15:12 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 DE40F28C0E7 for ; Mon, 14 Jun 2010 12:15:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 6Mbu2BSpt8Lt for ; Mon, 14 Jun 2010 12:15:09 -0700 (PDT) Received: from dcexchedge02.tekelec.com (dcexchedge02.tekelec.com [198.89.35.103]) by core3.amsl.com (Postfix) with ESMTP id A01FE3A6936 for ; Mon, 14 Jun 2010 12:15:07 -0700 (PDT) Received: from DCHUB2.tekelec.com (199.165.206.133) by dcexchedge02.tekelec.com (198.89.35.103) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 14 Jun 2010 15:10:30 -0400 Received: from MAIL1.tekelec.com ([fe80::58a6:c1ee:29ec:4a81]) by DCHUB2.tekelec.com ([::1]) with mapi; Mon, 14 Jun 2010 15:15:10 -0400 From: "Roach, Adam" To: Adam Roach , "'martini@ietf.org'" Date: Mon, 14 Jun 2010 15:15:09 -0400 Thread-Topic: MARTINI Virtual Interim V Thread-Index: AcsL9efAJYP2d2UiRWuSQf/aOpDcxQ== Message-ID: <07E82B9FD6C6814C8606E7BE591D771A061D6851DE@MAIL1.tekelec.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_002_07E82B9FD6C6814C8606E7BE591D771A061D6851DEMAIL1tekelecc_" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 15 Jun 2010 02:45:17 -0700 Subject: [martini] MARTINI Virtual Interim V 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, 14 Jun 2010 19:15:12 -0000 --_002_07E82B9FD6C6814C8606E7BE591D771A061D6851DEMAIL1tekelecc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 V2hlbjogV2VkbmVzZGF5LCBKdW5lIDE2LCAyMDEwIDY6MDAgUE0tODowMCBQTS4gR3JlZW53aWNo IFN0YW5kYXJkIFRpbWUNCldoZXJlOiBTZWUgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL21hcnRpbmkvY3VycmVudC9tc2cwMTY3MC5odG1sIGZvciBkZXRhaWxzDQoNCip+Kn4q fip+Kn4qfip+Kn4qfioNCg0KV2hlbjogV2VkbmVzZGF5LCBKdW5lIDE2LCAyMDEwIDExOjAwIEFN LTE6MDAgUE0gKFVUQy0wODowMCkgUGFjaWZpYyBUaW1lIChVUyAmIENhbmFkYSkuDQpXaGVyZTog U2VlIGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9tYXJ0aW5pL2N1cnJlbnQv bXNnMDE2NzAuaHRtbCBmb3IgZGV0YWlscw0KDQpOb3RlOiBUaGUgR01UIG9mZnNldCBhYm92ZSBk b2VzIG5vdCByZWZsZWN0IGRheWxpZ2h0IHNhdmluZyB0aW1lIGFkanVzdG1lbnRzLg0KDQoqfip+ Kn4qfip+Kn4qfip+Kn4qDQoNCkFnZW5kYQ0KTUFSVElOSSBWaXJ0dWFsIEludGVyaW0gVg0KV2Vk bmVzZGF5LCBKdW5lIDE2LCAyMDEwDQoxMSBBTSDigJMgMSBQTSBQYWNpZmljIFRpbWUNCg0KQ29u ZmVyZW5jaW5nIERldGFpbHM6DQpTbGlkZSBQcmVzZW50YXRpb25zOiAgaHR0cDovL3d3dy5kcml6 emxlLmNvbS9+YWJvYmEvTUFSVElOSS9KdW5lLUludGVyaW0tVi8NCkphYmJlciByb29tOiAgbWFy dGluaSBhdCBqYWJiZXIuaWV0Zi5vcmcgKFBsZWFzZSBqb2luKQ0KRGlhbCBpbiBBdWRpb2NvbmZl cmVuY2UgYW5kIFdlYkV4IGRldGFpbHM6ICBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2 ZS93ZWIvbWFydGluaS9jdXJyZW50L21zZzAxNjcwLmh0bWwNCg0KQWdlbmRhDQoNCjExIEFNIC0g MTE6MTAgQU0gUFQ6ICBQcmVsaW1pbmFyaWVzDQogICAgIENvbmZlcmVuY2UgaXNzdWVzL2RlYnVn Z2luZw0KICAgICBOb3RlIFdlbGwNCiAgICAgTm90ZSBUYWtlcnMNCiAgICAgQWdlbmRhIGJhc2gN Cg0KU29sdXRpb24gVXBkYXRlcyAoNDAgbWludXRlcykNCg0KMTE6MTAgQU0g4oCTIDExOjUwIEFN IFBULCBNQVJUSU5JIHdpdGggR2xvYmFsbHkgSWRlbnRpZmlhYmxlIE51bWJlcnMsIEFkYW0gUm9h Y2ggKDQwIG1pbnV0ZXMpDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW1h cnRpbmktZ2luDQoNCkluZGl2aWR1YWwgU3VibWlzc2lvbnMgKDQwIG1pbnV0ZXMpDQoNCjExOjUw IEFNIOKAkyAxMjoxMCBQTSBQVCwgT3RoZXIgTG9naWNhbCBJZGVudGlmaWVyIFZhbHVlcyAoT0xJ VkUpLCBIYWRyaWVsIEthcGxhbiAoMjAgbWludXRlcykNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWthcGxhbi1tYXJ0aW5pLXdpdGgtb2xpdmUNCg0KMTI6MTAgUE0g4oCTIDEyOjMw IFBNIFBULCBNQVJUSU5JIEV2ZW50IFBhY2thZ2UgZm9yIFJlZ2lzdHJhdGlvbiAoVkVSTU9VVEgp LCBIYWRyaWVsIEthcGxhbiAoMjAgbWludXRlcykNCmh0dHA6Ly90b29scy5pZXRmLm9yZy9odG1s L2RyYWZ0LWthcGxhbi1tYXJ0aW5pLXZlcm1vdXRoDQoNCg0KRGlzY3Vzc2lvbiBhbmQgV3JhcC11 cCAoMzUgbWludXRlcykNCg0KMTI6MzAgUE0g4oCTIDEyOjQwIFBNIFBUICBEaXNjdXNzaW9uOiAg UGFydGljaXBhbnRzICgxMCBtaW51dGVzKQ0KMTI6NDAgUE0gLSAxMjo1MCBQTSBQVCAgSHVtczog IFdHIENoYWlycyAoMTAgbWludXRlcykNCjEyOjUwIFBNIOKAkyAgMTowMCBQTSBQVCAgTmV4dCBT dGVwczogIFdHIENoYWlycyAmIEFEcyAoMTAgbWludXRlcykNCg0KDQoNCg0K --_002_07E82B9FD6C6814C8606E7BE591D771A061D6851DEMAIL1tekelecc_ Content-Type: text/calendar; charset="utf-8"; method=REQUEST Content-Transfer-Encoding: base64 QkVHSU46VkNBTEVOREFSDQpNRVRIT0Q6UkVRVUVTVA0KUFJPRElEOk1pY3Jvc29mdCBFeGNoYW5n ZSBTZXJ2ZXIgMjAwNw0KVkVSU0lPTjoyLjANCkJFR0lOOlZUSU1FWk9ORQ0KVFpJRDpHcmVlbndp Y2ggU3RhbmRhcmQgVGltZQ0KQkVHSU46U1RBTkRBUkQNCkRUU1RBUlQ6MTYwMTAxMDFUMDAwMDAw DQpUWk9GRlNFVEZST006KzAwMDANClRaT0ZGU0VUVE86KzAwMDANCkVORDpTVEFOREFSRA0KQkVH SU46REFZTElHSFQNCkRUU1RBUlQ6MTYwMTAxMDFUMDAwMDAwDQpUWk9GRlNFVEZST006KzAwMDAN ClRaT0ZGU0VUVE86KzAwMDANCkVORDpEQVlMSUdIVA0KRU5EOlZUSU1FWk9ORQ0KQkVHSU46VkVW RU5UDQpPUkdBTklaRVI7Q049IlJvYWNoLCBBZGFtIjpNQUlMVE86QWRhbS5Sb2FjaEB0ZWtlbGVj LmNvbQ0KQVRURU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9O O1JTVlA9VFJVRTtDTj1BZGFtIFJvYWNoDQogOk1BSUxUTzphZGFtQGVzdGFjYWRvLm5ldA0KQVRU RU5ERUU7Uk9MRT1SRVEtUEFSVElDSVBBTlQ7UEFSVFNUQVQ9TkVFRFMtQUNUSU9OO1JTVlA9VFJV RTtDTj0nbWFydGluaUBpDQogZXRmLm9yZyc6TUFJTFRPOm1hcnRpbmlAaWV0Zi5vcmcNCkRFU0NS SVBUSU9OO0xBTkdVQUdFPWVuLVVTOldoZW46IFdlZG5lc2RheVwsIEp1bmUgMTZcLCAyMDEwIDY6 MDAgUE0tODowMCBQTQ0KIC4gR3JlZW53aWNoIFN0YW5kYXJkIFRpbWVcbldoZXJlOiBTZWUgaHR0 cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViDQogL21hcnRpbmkvY3VycmVudC9tc2cw MTY3MC5odG1sIGZvciBkZXRhaWxzXG5cbip+Kn4qfip+Kn4qfip+Kn4qfipcblxuV2hlbjoNCiAg V2VkbmVzZGF5XCwgSnVuZSAxNlwsIDIwMTAgMTE6MDAgQU0tMTowMCBQTSAoVVRDLTA4OjAwKSBQ YWNpZmljIFRpbWUgKFVTIA0KICYgQ2FuYWRhKS5cbldoZXJlOiBTZWUgaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL21hcnRpbmkvY3VycmVuDQogdC9tc2cwMTY3MC5odG1sIGZv ciBkZXRhaWxzXG5cbk5vdGU6IFRoZSBHTVQgb2Zmc2V0IGFib3ZlIGRvZXMgbm90IHJlZmxlY3QN CiAgZGF5bGlnaHQgc2F2aW5nIHRpbWUgYWRqdXN0bWVudHMuXG5cbip+Kn4qfip+Kn4qfip+Kn4q fipcblxuQWdlbmRhXG5NQVJUSQ0KIE5JIFZpcnR1YWwgSW50ZXJpbSBWXG5XZWRuZXNkYXlcLCBK dW5lIDE2XCwgMjAxMFxuMTEgQU0g4oCTIDEgUE0gUGFjaWZpYyBUDQogaW1lXG5cbkNvbmZlcmVu Y2luZyBEZXRhaWxzOlxuU2xpZGUgUHJlc2VudGF0aW9uczogIGh0dHA6Ly93d3cuZHJpenpsZS5j b20NCiAvfmFib2JhL01BUlRJTkkvSnVuZS1JbnRlcmltLVYvXG5KYWJiZXIgcm9vbTogIG1hcnRp bmkgYXQgamFiYmVyLmlldGYub3JnIA0KIChQbGVhc2Ugam9pbilcbkRpYWwgaW4gQXVkaW9jb25m ZXJlbmNlIGFuZCBXZWJFeCBkZXRhaWxzOiAgaHR0cDovL3d3dy5pZXRmDQogLm9yZy9tYWlsLWFy Y2hpdmUvd2ViL21hcnRpbmkvY3VycmVudC9tc2cwMTY3MC5odG1sXG5cbkFnZW5kYVxuXG4xMSBB TSAtIDENCiAxOjEwIEFNIFBUOiAgUHJlbGltaW5hcmllc1xuICAgICBDb25mZXJlbmNlIGlzc3Vl cy9kZWJ1Z2dpbmdcbiAgICAgTm90ZSBXZQ0KIGxsXG4gICAgIE5vdGUgVGFrZXJzXG4gICAgIEFn ZW5kYSBiYXNoXG5cblNvbHV0aW9uIFVwZGF0ZXMgKDQwIG1pbnV0ZXMpXG5cDQogbjExOjEwIEFN IOKAkyAxMTo1MCBBTSBQVFwsIE1BUlRJTkkgd2l0aCBHbG9iYWxseSBJZGVudGlmaWFibGUgTnVt YmVyc1wsIEENCiBkYW0gUm9hY2ggKDQwIG1pbnV0ZXMpXG5odHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC1pZXRmLW1hcnRpbmktZ2luXA0KIG5cbkluZGl2aWR1YWwgU3VibWlzc2lvbnMg KDQwIG1pbnV0ZXMpXG5cbjExOjUwIEFNIOKAkyAxMjoxMCBQTSBQVFwsIE90aGVyDQogIExvZ2lj YWwgSWRlbnRpZmllciBWYWx1ZXMgKE9MSVZFKVwsIEhhZHJpZWwgS2FwbGFuICgyMCBtaW51dGVz KVxuaHR0cDovL3QNCiBvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2FwbGFuLW1hcnRpbmktd2l0 aC1vbGl2ZVxuXG4xMjoxMCBQTSDigJMgMTI6MzAgUA0KIE0gUFRcLCBNQVJUSU5JIEV2ZW50IFBh Y2thZ2UgZm9yIFJlZ2lzdHJhdGlvbiAoVkVSTU9VVEgpXCwgSGFkcmllbCBLYXBsYW4gDQogKDIw IG1pbnV0ZXMpXG5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rYXBsYW4tbWFydGlu aS12ZXJtb3V0aFxuXG4NCiBcbkRpc2N1c3Npb24gYW5kIFdyYXAtdXAgKDM1IG1pbnV0ZXMpXG5c bjEyOjMwIFBNIOKAkyAxMjo0MCBQTSBQVCAgRGlzY3Vzcw0KIGlvbjogIFBhcnRpY2lwYW50cyAo MTAgbWludXRlcylcbjEyOjQwIFBNIC0gMTI6NTAgUE0gUFQgIEh1bXM6ICBXRyBDaGFpcnMgDQog KDEwIG1pbnV0ZXMpXG4xMjo1MCBQTSDigJMgIDE6MDAgUE0gUFQgIE5leHQgU3RlcHM6ICBXRyBD aGFpcnMgJiBBRHMgKDEwIG0NCiBpbnV0ZXMpXG5cblxuXG5cbg0KU1VNTUFSWTtMQU5HVUFHRT1l bi1VUzpNQVJUSU5JIFZpcnR1YWwgSW50ZXJpbSBWDQpEVFNUQVJUO1RaSUQ9R3JlZW53aWNoIFN0 YW5kYXJkIFRpbWU6MjAxMDA2MTZUMTgwMDAwDQpEVEVORDtUWklEPUdyZWVud2ljaCBTdGFuZGFy ZCBUaW1lOjIwMTAwNjE2VDIwMDAwMA0KVUlEOjBENUY5REQwLTQ2RTMtNDA0MS1CRTdGLTgwNzVG ODFBRDZBMw0KQ0xBU1M6UFVCTElDDQpQUklPUklUWTo1DQpEVFNUQU1QOjIwMTAwNjE0VDE5MTUw OVoNClRSQU5TUDpPUEFRVUUNClNUQVRVUzpDT05GSVJNRUQNClNFUVVFTkNFOjANCkxPQ0FUSU9O O0xBTkdVQUdFPWVuLVVTOlNlZSBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIv bWFydGluaS9jdQ0KIHJyZW50L21zZzAxNjcwLmh0bWwgZm9yIGRldGFpbHMNClgtTUlDUk9TT0ZU LUNETy1BUFBULVNFUVVFTkNFOjANClgtTUlDUk9TT0ZULUNETy1PV05FUkFQUFRJRDoyMTA4MDYw NjE3DQpYLU1JQ1JPU09GVC1DRE8tQlVTWVNUQVRVUzpURU5UQVRJVkUNClgtTUlDUk9TT0ZULUNE Ty1JTlRFTkRFRFNUQVRVUzpCVVNZDQpYLU1JQ1JPU09GVC1DRE8tQUxMREFZRVZFTlQ6RkFMU0UN ClgtTUlDUk9TT0ZULUNETy1JTVBPUlRBTkNFOjENClgtTUlDUk9TT0ZULUNETy1JTlNUVFlQRTow DQpCRUdJTjpWQUxBUk0NCkFDVElPTjpESVNQTEFZDQpERVNDUklQVElPTjpSRU1JTkRFUg0KVFJJ R0dFUjtSRUxBVEVEPVNUQVJUOi1QVDE1TQ0KRU5EOlZBTEFSTQ0KRU5EOlZFVkVOVA0KRU5EOlZD QUxFTkRBUg0K --_002_07E82B9FD6C6814C8606E7BE591D771A061D6851DEMAIL1tekelecc_-- From adam@estacado.net Mon Jun 14 12:17:31 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 99CF93A69BD for ; Mon, 14 Jun 2010 12:17:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_43=0.6] 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 LqT9qaxAJHM7 for ; Mon, 14 Jun 2010 12:17:30 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id F16A23A698E for ; Mon, 14 Jun 2010 12:17:27 -0700 (PDT) Received: from dn3-228.estacado.net (dn3-228.estacado.net [172.16.3.228]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o5EJHRsr076272 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 14 Jun 2010 14:17:28 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4C168047.9020100@estacado.net> Date: Mon, 14 Jun 2010 14:17:27 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Roach, Adam" References: <07E82B9FD6C6814C8606E7BE591D771A061D6851DE@MAIL1.tekelec.com> In-Reply-To: <07E82B9FD6C6814C8606E7BE591D771A061D6851DE@MAIL1.tekelec.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 15 Jun 2010 02:45:17 -0700 Cc: "'martini@ietf.org'" Subject: Re: [martini] MARTINI Virtual Interim V 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, 14 Jun 2010 19:17:31 -0000 Sorry -- more tools blowback. It's unfortunate -- the interface to iCal.app is inscrutable and, for the most part, unusable. It simply doesn't match the rest of the stuff that Apple includes with the operating system. /a On 6/14/10 2:15 PM, Roach, Adam wrote: > When: Wednesday, June 16, 2010 6:00 PM-8:00 PM. Greenwich Standard Time > Where: See http://www.ietf.org/mail-archive/web/martini/current/msg01670.html for details > > *~*~*~*~*~*~*~*~*~* > > When: Wednesday, June 16, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US& Canada). > Where: See http://www.ietf.org/mail-archive/web/martini/current/msg01670.html for details > > Note: The GMT offset above does not reflect daylight saving time adjustments. > > *~*~*~*~*~*~*~*~*~* > > Agenda > MARTINI Virtual Interim V > Wednesday, June 16, 2010 > 11 AM – 1 PM Pacific Time > > Conferencing Details: > Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ > Jabber room: martini at jabber.ietf.org (Please join) > Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg01670.html > > Agenda > > 11 AM - 11:10 AM PT: Preliminaries > Conference issues/debugging > Note Well > Note Takers > Agenda bash > > Solution Updates (40 minutes) > > 11:10 AM – 11:50 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (40 minutes) > http://tools.ietf.org/html/draft-ietf-martini-gin > > Individual Submissions (40 minutes) > > 11:50 AM – 12:10 PM PT, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (20 minutes) > http://tools.ietf.org/html/draft-kaplan-martini-with-olive > > 12:10 PM – 12:30 PM PT, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (20 minutes) > http://tools.ietf.org/html/draft-kaplan-martini-vermouth > > > Discussion and Wrap-up (35 minutes) > > 12:30 PM – 12:40 PM PT Discussion: Participants (10 minutes) > 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) > 12:50 PM – 1:00 PM PT Next Steps: WG Chairs& ADs (10 minutes) > > > > > From bernard_aboba@hotmail.com Tue Jun 15 11:23:04 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 1AECF3A69A2 for ; Tue, 15 Jun 2010 11:23:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.414 X-Spam-Level: * X-Spam-Status: No, score=1.414 tagged_above=-999 required=5 tests=[AWL=-0.769, BAYES_80=2, SARE_OBFU_SPLIT_HR2=0.183] 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 KJTv1te9cCBX for ; Tue, 15 Jun 2010 11:23:03 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by core3.amsl.com (Postfix) with ESMTP id 533F73A6837 for ; Tue, 15 Jun 2010 11:23:03 -0700 (PDT) Received: from BLU137-DS7 ([65.55.111.72]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 11:23:07 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 15 Jun 2010 11:24:33 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93wbXK68g Content-Language: en-us X-OriginalArrivalTime: 15 Jun 2010 18:23:07.0720 (UTC) FILETIME=[CD8B5480:01CB0CB7] Subject: [martini] MARTINI Virtual Interim V 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: Tue, 15 Jun 2010 18:23:04 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100615T182433Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: See http://www.ietf.org/mail-archive/we b/martini/current/msg01670.html for details\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nAgenda\nMARTINI Virtual Interim V\nWednesday\, June 16\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nSlide Presentations: http ://www.drizzle.com/~aboba/MARTINI/June-Interim-V/\nJabber room: martini a t jabber.ietf.org (Please join)\nDial in Audioconference and WebEx details : http://www.ietf.org/mail-archive/web/martini/current/msg01670.html\n \n Agenda\n\n11 AM - 11:10 AM PT: Preliminaries\n Conference issues/debu gging\n Note Well\n Note Takers\n Agenda bash\n\nSolution Upda tes (30 minutes)\n\n11:10 AM – 11:40 AM PT\, MARTINI with Globally Ident ifiable Numbers\, Adam Roach (30 minutes)\nhttp://tools.ietf.org/html/draf t-ietf-martini-gin\n\nIndividual Submissions (45 minutes)\n\n11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (15 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-martini-with-olive\n\n1 1:55 AM – 12:10 PM PT\, MARTINI Event Package for Registration (VERMOUTH )\, Hadriel Kaplan (15 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-m artini-vermouth\n\n12:10 PM – 12:25 PM PT\, Registration for MARTINI wit h Federated Intra-Enterprise Domain Name Setup\, Hans Erik van Elburg\,(15 minutes)\nhttp://tools.ietf.org/html/draft-vanelburg-martini-friends\n\n\ nDiscussion and Wrap-up (35 minutes)\n\n12:25 PM – 12:40 PM PT Discussi on: Participants (15 minutes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs ( 10 minutes)\n12:50 PM – 1:00 PM PT Next Steps: WG Chairs & ADs (10 mi nutes)\n\n\n\n\n DTEND:20100616T200000Z DTSTAMP:20100615T182433Z DTSTART:20100616T180000Z LAST-MODIFIED:20100615T182433Z LOCATION:See http://www.ietf.org/mail-archive/web/martini/current/msg01670. html for details ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:3 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: See http://www.ietf.org/mail-archive/web/ martini/current/msg01670.html for details

\n\n

Note: The GMT offset above doe s not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Agenda< /P>\n\n

MARTI NI Virtual Interim V

\n\n

Wednesday\, June 16\, 2010

\n\n

11 AM – 1 PM Pacific Time

\n\n

< FONT SIZE=2 FACE="Courier New">Conferencing Details:

\n\n

Slide Presen tations:  http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/

\n\n

Jabber room:  martini at jabber .ietf.org (Please join)

\n\n

Dial in Audioconference and WebEx details :   http://www.ietf.org/mail-archive/web/martini/current /msg01670.html

\n\n

 \;

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

      Conference issues/debugging

\n\n

     Note Well\n\n

      Note Takers

\n\n

     Agenda bash

\n\n

Solution Updates (30 minutes)

\n\n

11:10 AM – 11:40 AM PT\, MARTINI with Globally Identi fiable Numbers\, Adam Roach (30 minutes)

\n\n

< SPAN LANG="en-us">http://tools.ie tf.org/html/draft-ietf-martini-gin

\n\n

Individual Submissions (45 minutes)

\n\n

11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (15 minutes )

\n\n

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

\n\n< P DIR=LTR>11:55 AM – 12:10 PM PT\, MARTINI Event Package for Registration (VERMOUTH)\, Hadriel Kaplan (15 minutes)

\n\n

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

\n\n

12:10 PM – 12:25 PM PT\, Registration for MARTINI with Federated Intra- Enterprise Domain Name Setup\, Hans Erik van Elburg\,(15 minutes)

\n\n

http://tools.ietf.org/html/draft-vanelburg-martini-frie nds

\n
\n\n

Discussion and Wr ap-up (35 minutes)

\n\n

12:25 PM – 12:40 PM PT \; Discussion:  Participants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Ch airs (10 minutes)

\n\n

12:50 PM – \; 1:00 PM PT  Next Steps:  WG Chairs &\; ADs (10 minutes)

\n\n

\n\n

\n\n

\n\n

< /SPAN>

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:2 X-MS-OLK-APPTSEQTIME:20100614T172342Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Tue Jun 15 11:24:21 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 C81AD3A690C for ; Tue, 15 Jun 2010 11:24:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.388 X-Spam-Level: X-Spam-Status: No, score=0.388 tagged_above=-999 required=5 tests=[AWL=0.386, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 vO5HHJQE1hcz for ; Tue, 15 Jun 2010 11:24:17 -0700 (PDT) Received: from blu0-omc2-s34.blu0.hotmail.com (blu0-omc2-s34.blu0.hotmail.com [65.55.111.109]) by core3.amsl.com (Postfix) with ESMTP id 94F0C3A68B7 for ; Tue, 15 Jun 2010 11:24:17 -0700 (PDT) Received: from BLU137-DS4 ([65.55.111.71]) by blu0-omc2-s34.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 11:24:21 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 15 Jun 2010 11:25:47 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00EA_01CB0C7D.80C17B00" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsMuCzg2gvzLz+uShS9UehKMgub7Q== Content-Language: en-us X-OriginalArrivalTime: 15 Jun 2010 18:24:21.0659 (UTC) FILETIME=[F99D86B0:01CB0CB7] Subject: [martini] MARTINI Virtual Interim V Agenda - Take Three 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: Tue, 15 Jun 2010 18:24:21 -0000 ------=_NextPart_000_00EA_01CB0C7D.80C17B00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda MARTINI Virtual Interim V Wednesday, June 16, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg01670.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Solution Updates (30 minutes) 11:10 AM - 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (45 minutes) 11:40 AM - 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive 11:55 AM - 12:10 PM PT, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth 12:10 PM - 12:25 PM PT, Registration for MARTINI with Federated Intra-Enterprise Domain Name Setup, Hans Erik van Elburg,(15 minutes) http://tools.ietf.org/html/draft-vanelburg-martini-friends Discussion and Wrap-up (35 minutes) 12:25 PM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_00EA_01CB0C7D.80C17B00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda

MARTINI Virtual Interim V

Wednesday, June 16, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  http://www= .drizzle.com/~aboba/MARTINI/June-Interim-V/

Jabber room:  martini at jabber.ietf.org (Please = join)

Dial in Audioconference and WebEx details:  http://www.ietf.org/mail-archive/web/martini/current/msg01670.html=

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Solution Updates (30 minutes)

 

11:10 AM – 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam = Roach (30 minutes)

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

 

Individual Submissions (45 minutes)

 

11:40 AM – 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel = Kaplan (15 minutes)

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

 

11:55 AM – 12:10 PM PT, MARTINI Event Package for Registration = (VERMOUTH), Hadriel Kaplan (15 minutes)

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

 

12:10 PM – 12:25 PM PT, Registration for MARTINI with Federated Intra-Enterprise Domain Name Setup, Hans Erik van Elburg,(15 = minutes)

http:= //tools.ietf.org/html/draft-vanelburg-martini-friends

 

 

Discussion and Wrap-up (35 minutes)

 

12:25 PM – 12:40 PM PT  Discussion:  Participants (15 = minutes)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 = minutes)

12:50 PM –  1:00 PM PT  Next Steps:  WG Chairs & = ADs (10 minutes)

 

 

 

 

 

------=_NextPart_000_00EA_01CB0C7D.80C17B00-- From bernard_aboba@hotmail.com Tue Jun 15 12:38:13 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 995AA3A6927 for ; Tue, 15 Jun 2010 12:38:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.499 X-Spam-Level: X-Spam-Status: No, score=0.499 tagged_above=-999 required=5 tests=[AWL=0.315, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] 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 wgICrthGFHXY for ; Tue, 15 Jun 2010 12:38:12 -0700 (PDT) Received: from blu0-omc2-s25.blu0.hotmail.com (blu0-omc2-s25.blu0.hotmail.com [65.55.111.100]) by core3.amsl.com (Postfix) with ESMTP id B438E3A68DA for ; Tue, 15 Jun 2010 12:38:12 -0700 (PDT) Received: from BLU137-DS16 ([65.55.111.71]) by blu0-omc2-s25.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 12:38:17 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 15 Jun 2010 12:39:42 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93wbZy5NQ Content-Language: en-us X-OriginalArrivalTime: 15 Jun 2010 19:38:17.0315 (UTC) FILETIME=[4D78EB30:01CB0CC2] Subject: [martini] MARTINI Virtual Interim V 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: Tue, 15 Jun 2010 19:38:13 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100615T193942Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: See http://www.ietf.org/mail-archive/we b/martini/current/msg01670.html for details\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nAgenda\nMARTINI Virtual Interim V\nWednesday\, June 16\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nSlide Presentations: http ://www.drizzle.com/~aboba/MARTINI/June-Interim-V/\nJabber room: martini a t jabber.ietf.org (Please join)\nDial in Audioconference and WebEx details : http://www.ietf.org/mail-archive/web/martini/current/msg01670.html\n \n Agenda\n\n11 AM - 11:10 AM PT: Preliminaries\n Conference issues/debu gging\n Note Well\n Note Takers\n Agenda bash\n\nSolution Upda tes (30 minutes)\n\n11:10 AM – 11:40 AM PT\, MARTINI with Globally Ident ifiable Numbers\, Adam Roach (30 minutes)\nhttp://tools.ietf.org/html/draf t-ietf-martini-gin\n\nIndividual Submissions (45 minutes)\n\n11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (15 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-martini-with-olive\n\n1 1:55 AM – 12:10 PM PT\, MARTINI Event Package for Registration (VERMOUTH )\, Hadriel Kaplan (15 minutes)\nhttp://tools.ietf.org/html/draft-kaplan-m artini-vermouth\n\n12:10 PM – 12:25 PM PT\, Registration for MARTINI wit h Federated Intra-Enterprise Domain Name Setup\, Martin Dolly\,(15 minutes )\nhttp://tools.ietf.org/html/draft-vanelburg-martini-friends\n\n\nDiscuss ion and Wrap-up (35 minutes)\n\n12:25 PM – 12:40 PM PT Discussion: Par ticipants (15 minutes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minut es)\n12:50 PM – 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes)\n \n\n\n\n DTEND:20100616T200000Z DTSTAMP:20100615T193942Z DTSTART:20100616T180000Z LAST-MODIFIED:20100615T193942Z LOCATION:See http://www.ietf.org/mail-archive/web/martini/current/msg01670. html for details ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:4 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: See http://www.ietf.org/mail-archive/web/ martini/current/msg01670.html for details

\n\n

Note: The GMT offset above doe s not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Agenda< /P>\n\n

MARTI NI Virtual Interim V

\n\n

Wednesday\, June 16\, 2010

\n\n

11 AM – 1 PM Pacific Time

\n\n

< FONT SIZE=2 FACE="Courier New">Conferencing Details:

\n\n

Slide Presen tations:  http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/

\n\n

Jabber room:  martini at jabber .ietf.org (Please join)

\n\n

Dial in Audioconference and WebEx details :   http://www.ietf.org/mail-archive/web/martini/current /msg01670.html

\n\n

 \;

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

      Conference issues/debugging

\n\n

     Note Well\n\n

      Note Takers

\n\n

     Agenda bash

\n\n

Solution Updates (30 minutes)

\n\n

11:10 AM – 11:40 AM PT\, MARTINI with Globally Identi fiable Numbers\, Adam Roach (30 minutes)

\n\n

< SPAN LANG="en-us">http://tools.ie tf.org/html/draft-ietf-martini-gin

\n\n

Individual Submissions (45 minutes)

\n\n

11:40 AM – 11:55 AM PT\, Other Logical Identifier Values (OLIVE)\, Hadriel Kaplan (15 minutes )

\n\n

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

\n\n< P DIR=LTR>11:55 AM – 12:10 PM PT\, MARTINI Event Package for Registration (VERMOUTH)\, Hadriel Kaplan (15 minutes)

\n\n

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

\n\n

12:10 PM – 12:25 PM PT\, Registration for MARTINI with Federated Intra- Enterprise Domain Name Setup\, Martin Dolly\,(15 minutes)

\n\n

http://tools.ietf.org/html/draft-vanelburg-martini-friends

\n
\n\n

Discussion and Wrap-up (3 5 minutes)

\n\n

12:25 PM – 12:40 PM PT \; Discussion:  Partici pants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12:50 PM – \; 1:00 PM PT  Next Steps:  WG Chai rs &\; ADs (10 minutes)

\n\n

\n\n

\n\n

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:3 X-MS-OLK-APPTSEQTIME:20100615T182433Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From bernard_aboba@hotmail.com Tue Jun 15 12:39:09 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 3FAB83A69B8 for ; Tue, 15 Jun 2010 12:39:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.387 X-Spam-Level: X-Spam-Status: No, score=0.387 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 pN+ocGvqCq1z for ; Tue, 15 Jun 2010 12:39:04 -0700 (PDT) Received: from blu0-omc2-s27.blu0.hotmail.com (blu0-omc2-s27.blu0.hotmail.com [65.55.111.102]) by core3.amsl.com (Postfix) with ESMTP id E49523A68DA for ; Tue, 15 Jun 2010 12:39:03 -0700 (PDT) Received: from BLU137-DS15 ([65.55.111.72]) by blu0-omc2-s27.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 15 Jun 2010 12:39:08 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 15 Jun 2010 12:40:33 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0129_01CB0C87.F2AF63D0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsMwp7GnJQXJmFUTKy71k7H5NuPVQ== Content-Language: en-us X-OriginalArrivalTime: 15 Jun 2010 19:39:08.0056 (UTC) FILETIME=[6BB76180:01CB0CC2] Subject: [martini] MARTINI Interim V - Final Agenda 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: Tue, 15 Jun 2010 19:39:09 -0000 ------=_NextPart_000_0129_01CB0C87.F2AF63D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Agenda MARTINI Virtual Interim V Wednesday, June 16, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archive/web/martini/current/msg01670.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Solution Updates (30 minutes) 11:10 AM - 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam Roach (30 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (45 minutes) 11:40 AM - 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive 11:55 AM - 12:10 PM PT, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (15 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth 12:10 PM - 12:25 PM PT, Registration for MARTINI with Federated Intra-Enterprise Domain Name Setup, Martin Dolly,(15 minutes) http://tools.ietf.org/html/draft-vanelburg-martini-friends Discussion and Wrap-up (35 minutes) 12:25 PM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_0129_01CB0C87.F2AF63D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda

MARTINI Virtual Interim V

Wednesday, June 16, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  http://www= .drizzle.com/~aboba/MARTINI/June-Interim-V/

Jabber room:  martini at jabber.ietf.org (Please = join)

Dial in Audioconference and WebEx details:  http://www.ietf.org/mail-archive/web/martini/current/msg01670.html=

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Solution Updates (30 minutes)

 

11:10 AM – 11:40 AM PT, MARTINI with Globally Identifiable Numbers, Adam = Roach (30 minutes)

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

 

Individual Submissions (45 minutes)

 

11:40 AM – 11:55 AM PT, Other Logical Identifier Values (OLIVE), Hadriel = Kaplan (15 minutes)

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

 

11:55 AM – 12:10 PM PT, MARTINI Event Package for Registration = (VERMOUTH), Hadriel Kaplan (15 minutes)

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

 

12:10 PM – 12:25 PM PT, Registration for MARTINI with Federated Intra-Enterprise Domain Name Setup, Martin Dolly,(15 = minutes)

http:= //tools.ietf.org/html/draft-vanelburg-martini-friends

 

 

Discussion and Wrap-up (35 minutes)

 

12:25 PM – 12:40 PM PT  Discussion:  Participants (15 = minutes)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 = minutes)

12:50 PM –  1:00 PM PT  Next Steps:  WG Chairs & = ADs (10 minutes)

 

 

 

 

 

------=_NextPart_000_0129_01CB0C87.F2AF63D0-- From bernarda@microsoft.com Wed Jun 16 09:03:49 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 267B33A693F for ; Wed, 16 Jun 2010 09:03:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.298 X-Spam-Level: X-Spam-Status: No, score=-9.298 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] 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 xD89eYGDUC6T for ; Wed, 16 Jun 2010 09:03:44 -0700 (PDT) Received: from smtp.microsoft.com (mail2.microsoft.com [131.107.115.215]) by core3.amsl.com (Postfix) with ESMTP id D9F493A67A7 for ; Wed, 16 Jun 2010 09:03:44 -0700 (PDT) Received: from TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) by TK5-EXGWY-E802.partners.extranet.microsoft.com (10.251.56.168) with Microsoft SMTP Server (TLS) id 8.2.176.0; Wed, 16 Jun 2010 09:03:49 -0700 Received: from TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com (157.54.71.39) by TK5EX14HUBC103.redmond.corp.microsoft.com (157.54.86.9) with Microsoft SMTP Server (TLS) id 14.1.160.7; Wed, 16 Jun 2010 09:03:51 -0700 Received: from TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com ([169.254.1.91]) by TK5EX14MLTW651.wingroup.windeploy.ntdev.microsoft.com ([157.54.71.39]) with mapi; Wed, 16 Jun 2010 09:03:50 -0700 From: Bernard Aboba To: "martini@ietf.org" Thread-Topic: MARTINI Interim V - Agenda Update Thread-Index: AcsMwp7GnJQXJmFUTKy71k7H5NuPVQAqtqOg Date: Wed, 16 Jun 2010 16:05:13 +0000 Message-ID: <3E368C9530D1B640AA7BAE85FECC05BF12529438@TK5EX14MBXW651.wingroup.windeploy.ntdev.microsoft.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_3E368C9530D1B640AA7BAE85FECC05BF12529438TK5EX14MBXW651w_" MIME-Version: 1.0 Subject: [martini] MARTINI Interim V - Agenda Update 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, 16 Jun 2010 16:03:49 -0000 --_000_3E368C9530D1B640AA7BAE85FECC05BF12529438TK5EX14MBXW651w_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agenda MARTINI Virtual Interim V Wednesday, June 16, 2010 11 AM - 1 PM Pacific Time Conferencing Details: Slide Presentations: http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/ Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: http://www.ietf.org/mail-archiv= e/web/martini/current/msg01670.html Agenda 11 AM - 11:10 AM PT: Preliminaries Conference issues/debugging Note Well Note Takers Agenda bash Solution Updates (50 minutes) 11:10 AM - 12:00 PM PT, MARTINI with Globally Identifiable Numbers, Adam Ro= ach (50 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (25 minutes) 12:00 PM - 12:25 PM PT, Registration for MARTINI with Federated Intra-Enter= prise Domain Name Setup, Martin Dolly,(25 minutes) http://tools.ietf.org/html/draft-vanelburg-martini-friends Discussion and Wrap-up (35 minutes) 12:25 PM - 12:40 PM PT Discussion: Participants (15 minutes) 12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes) 12:50 PM - 1:00 PM PT Next Steps: WG Chairs & ADs (10 minutes) --_000_3E368C9530D1B640AA7BAE85FECC05BF12529438TK5EX14MBXW651w_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Agenda

MARTINI Virtual Interim V

Wednesday, June 16, 2010

11 AM – 1 PM Pacific Time

 

Conferencing Details:

Slide Presentations:  http://www.d= rizzle.com/~aboba/MARTINI/June-Interim-V/

Jabber room:  martini at jabber.ietf.org (Please join)

Dial in Audioconference and WebEx details:  http://www.ietf.org/mail-archive/web/martini/current/msg01670.html

 

Agenda

 

11 AM - 11:10 AM PT:  Preliminaries

     Conference issues/debugging

     Note Well

     Note Takers

     Agenda bash

 

Solution Updates (50 minutes)

 

11:10 AM – 12:00 PM PT, MARTINI with Globally Identifiab= le Numbers, Adam Roach (50 minutes)

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

 

Individual Submissions (25 minutes)

 

12:00 PM – 12:25 PM PT, Registration for MARTINI with Fe= derated Intra-Enterprise Domain Name Setup, Martin Dolly,(25 minutes)

http://= tools.ietf.org/html/draft-vanelburg-martini-friends

 

 

Discussion and Wrap-up (35 minutes)

 

12:25 PM – 12:40 PM PT  Discussion:  Participants (15 minute= s)

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)=

12:50 PM –  1:00 PM PT  Next Steps:  WG Chairs & AD= s (10 minutes)

 

 

 

 

 

--_000_3E368C9530D1B640AA7BAE85FECC05BF12529438TK5EX14MBXW651w_-- From bernard_aboba@hotmail.com Wed Jun 16 09:08:00 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 6FD3F3A68CE for ; Wed, 16 Jun 2010 09:08:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.454 X-Spam-Level: X-Spam-Status: No, score=0.454 tagged_above=-999 required=5 tests=[AWL=0.270, BAYES_50=0.001, SARE_OBFU_SPLIT_HR2=0.183] 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 TGHlT4XuvxmP for ; Wed, 16 Jun 2010 09:07:58 -0700 (PDT) Received: from blu0-omc2-s9.blu0.hotmail.com (blu0-omc2-s9.blu0.hotmail.com [65.55.111.84]) by core3.amsl.com (Postfix) with ESMTP id B57543A67B8 for ; Wed, 16 Jun 2010 09:07:58 -0700 (PDT) Received: from BLU137-DS11 ([65.55.111.71]) by blu0-omc2-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 16 Jun 2010 09:08:03 -0700 X-Originating-IP: [75.164.156.18] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 16 Jun 2010 09:09:28 -0700 MIME-Version: 1.0 Content-Type: text/calendar; method=REQUEST; charset="utf-8" Content-Transfer-Encoding: 8bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcrxW1IDDLBhmE10RcGXYhVD9UG93wcEvo9g Content-Language: en-us X-OriginalArrivalTime: 16 Jun 2010 16:08:03.0759 (UTC) FILETIME=[199EC3F0:01CB0D6E] Subject: [martini] MARTINI Virtual Interim V 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, 16 Jun 2010 16:08:00 -0000 BEGIN:VCALENDAR PRODID:-//Microsoft Corporation//Outlook 12.0 MIMEDIR//EN VERSION:2.0 METHOD:REQUEST X-MS-OLK-FORCEINSPECTOROPEN:TRUE BEGIN:VEVENT ATTENDEE;CN='martini@ietf.org';RSVP=TRUE:mailto:martini@ietf.org CLASS:PUBLIC CREATED:20100616T160928Z DESCRIPTION:When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) P acific Time (US & Canada).\nWhere: See http://www.ietf.org/mail-archive/we b/martini/current/msg01670.html for details\n\nNote: The GMT offset above does not reflect daylight saving time adjustments.\n\n*~*~*~*~*~*~*~*~*~*\ n\nAgenda\nMARTINI Virtual Interim V\nWednesday\, June 16\, 2010\n11 AM – 1 PM Pacific Time\n\nConferencing Details:\nSlide Presentations: http ://www.drizzle.com/~aboba/MARTINI/June-Interim-V/\nJabber room: martini a t jabber.ietf.org (Please join)\nDial in Audioconference and WebEx details : http://www.ietf.org/mail-archive/web/martini/current/msg01670.html\n \n Agenda\n\n11 AM - 11:10 AM PT: Preliminaries\n Conference issues/debu gging\n Note Well\n Note Takers\n Agenda bash\n\nSolution Upda tes (50 minutes)\n\n11:10 AM – 12:00 PM PT\, MARTINI with Globally Ident ifiable Numbers\, Adam Roach (50 minutes)\nhttp://tools.ietf.org/html/draf t-ietf-martini-gin\n\nIndividual Submissions (25 minutes)\n\n12:00 PM – 12:25 PM PT\, Registration for MARTINI with Federated Intra-Enterprise Dom ain Name Setup\, Martin Dolly\,(25 minutes)\nhttp://tools.ietf.org/html/dr aft-vanelburg-martini-friends\n\n\nDiscussion and Wrap-up (35 minutes)\n\n 12:25 PM – 12:40 PM PT Discussion: Participants (15 minutes)\n12:40 PM - 12:50 PM PT Hums: WG Chairs (10 minutes)\n12:50 PM – 1:00 PM PT N ext Steps: WG Chairs & ADs (10 minutes)\n\n\n\n\n DTEND:20100616T200000Z DTSTAMP:20100616T160928Z DTSTART:20100616T180000Z LAST-MODIFIED:20100616T160928Z LOCATION:See http://www.ietf.org/mail-archive/web/martini/current/msg01670. html for details ORGANIZER;CN="Bernard Aboba":mailto:bernard_aboba@hotmail.com PRIORITY:5 SEQUENCE:5 SUMMARY;LANGUAGE=en-us:MARTINI Virtual Interim V TRANSP:OPAQUE UID:040000008200E00074C5B7101A82E00800000000C00DA4A520F1CA01000000000000000 0100000008ECA0F9EA2FCB34AA7A950A9AB259A9D X-ALT-DESC;FMTTYPE=text/html:\n\n\n\n\n\n\n\n\n

When: Wednesday\, June 16\, 2010 11:00 AM-1:00 PM (UTC-08:00) Pacific Time (US &\; Canada).

\n\n

Where: See http://www.ietf.org/mail-archive/web/ martini/current/msg01670.html for details

\n\n

Note: The GMT offset above doe s not reflect daylight saving time adjustments.

\n\n

*~*~*~*~*~*~*~*~*~*

\n\n

Agenda< /P>\n\n

MARTI NI Virtual Interim V

\n\n

Wednesday\, June 16\, 2010

\n\n

11 AM – 1 PM Pacific Time

\n\n

< FONT SIZE=2 FACE="Courier New">Conferencing Details:

\n\n

Slide Presen tations:  http://www.drizzle.com/~aboba/MARTINI/June-Interim-V/

\n\n

Jabber room:  martini at jabber .ietf.org (Please join)

\n\n

Dial in Audioconference and WebEx details :   http://www.ietf.org/mail-archive/web/martini/current /msg01670.html

\n\n

 \;

\n\n

Agenda

\n\n

11 AM - 11:10 AM PT:  Preliminaries

\n\n

      Conference issues/debugging

\n\n

     Note Well\n\n

      Note Takers

\n\n

     Agenda bash

\n\n

Solution Updates (50 minutes)

\n\n

11:10 AM – 12:00 PM PT\, MARTINI with Globally Identi fiable Numbers\, Adam Roach (50 minutes)

\n\n

< SPAN LANG="en-us">http://tools.ie tf.org/html/draft-ietf-martini-gin

\n\n

Individual Submissions (25 minutes)

\n\n

12:00 PM – 12:25 PM PT\, Registration for MARTINI with Federated Intra-Enterprise Domain Name Setup\, Martin Dolly\,(25 minutes)

\n\n

http://tool s.ietf.org/html/draft-vanelburg-martini-friends< SPAN LANG="en-us">

\n
\n\n

Discussion and Wrap-up (35 minutes)

\n\n

12 :25 PM – 12:40 PM PT \; Discussion:  Participants (15 minutes)

\n\n

12:40 PM - 12:50 PM PT  Hums:  WG Chairs (10 minutes)

\n\n

12: 50 PM – \; 1:00 PM PT  Next Steps:  WG Chairs &\; ADs (10 minu tes)

\n\n

\n\n

\n\n

\n\n

\n\n\n X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-DISALLOW-COUNTER:FALSE X-MS-OLK-ALLOWEXTERNCHECK:TRUE X-MS-OLK-APPTLASTSEQUENCE:4 X-MS-OLK-APPTSEQTIME:20100615T193942Z X-MS-OLK-AUTOSTARTCHECK:FALSE X-MS-OLK-CONFTYPE:0 BEGIN:VALARM TRIGGER:-PT15M ACTION:DISPLAY DESCRIPTION:Reminder END:VALARM END:VEVENT END:VCALENDAR From fluffy@cisco.com Wed Jun 16 10:00:13 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 286B83A69FC for ; Wed, 16 Jun 2010 10:00:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.939 X-Spam-Level: X-Spam-Status: No, score=-109.939 tagged_above=-999 required=5 tests=[AWL=0.660, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Q8qjkfLwIDf8 for ; Wed, 16 Jun 2010 10:00:12 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 6CFF93A6958 for ; Wed, 16 Jun 2010 10:00:12 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGACqgGEyrR7Hu/2dsb2JhbACeaWsGplSZfYUaBINS X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="213317499" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2010 17:00:17 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GH0GsD010423 for ; Wed, 16 Jun 2010 17:00:17 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 16 Jun 2010 11:00:16 -0600 Message-Id: <5CD60AE9-482E-47D8-8FF8-5F64101DCAA6@cisco.com> To: "martini@ietf.org" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] Question about draft-vanelburg-martini-fiends 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, 16 Jun 2010 17:00:13 -0000 Can someone explain to me what is the solution that 3GPP has specified = for this? And is the specification done or still be worked on? Thanks, Cullen From fluffy@cisco.com Wed Jun 16 10:00:25 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 ABE953A69FC for ; Wed, 16 Jun 2010 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=0.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 emh394VAqoQJ for ; Wed, 16 Jun 2010 10:00:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id DCC093A6915 for ; Wed, 16 Jun 2010 10:00:24 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMJACqgGEyrR7Hu/2dsb2JhbAAenktxplSZfYUaBINS X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="145515846" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2010 17:00:23 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GH0GsE010423; Wed, 16 Jun 2010 17:00:21 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 16 Jun 2010 11:00:20 -0600 Message-Id: <64F1878D-01E7-41AB-8625-EE9C103F5D74@cisco.com> To: "martini@ietf.org" , Hadriel Kaplan Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] Vermoth 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, 16 Jun 2010 17:00:25 -0000 I'm not yet convinced that the SSP can't just return all the implicit = resignations - even with an "open" plan. Can you walk me down the garden = path of a use case or two where you would really need this.=20 From fluffy@cisco.com Wed Jun 16 10:00:25 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 E25E03A6915 for ; Wed, 16 Jun 2010 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[AWL=0.550, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 bGjPJSPfGKBk for ; Wed, 16 Jun 2010 10:00:25 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 32DD63A6958 for ; Wed, 16 Jun 2010 10:00:25 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGACqgGEyrR7Hu/2dsb2JhbACeaWsGplSZfYUaBINS X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="145515968" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2010 17:00:28 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GH0GsF010423 for ; Wed, 16 Jun 2010 17:00:28 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 16 Jun 2010 11:00:28 -0600 Message-Id: To: "martini@ietf.org" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] Olives 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, 16 Jun 2010 17:00:26 -0000 At the high level, I like this draft. Hadriel has convinced me Olives = can go with GIN.=20 From fluffy@cisco.com Wed Jun 16 10:01: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 9E83428C101 for ; Wed, 16 Jun 2010 10:01:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.092 X-Spam-Level: X-Spam-Status: No, score=-110.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 S7G2Y4dC5BO5 for ; Wed, 16 Jun 2010 10:01:10 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id D894A3A6820 for ; Wed, 16 Jun 2010 10:01:10 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AskFACqgGEyrR7Hu/2dsb2JhbACSTIwdcaZUmX2FGgSDUg X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="213318308" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2010 17:01:15 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GH0GsG010423 for ; Wed, 16 Jun 2010 17:01:15 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 16 Jun 2010 11:01:15 -0600 Message-Id: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> To: martini@ietf.org Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] GIN temp GRUU 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, 16 Jun 2010 17:01:11 -0000 I'm not OK with requiring out of band provisioning for K_e2. This would = be a nightmare in practice. Could it be passed in the register response? Having this as optional does not really work for me because most the US = based customers doing PSTN replacement believe they are required to = provide anonymous call.=20 Overall, looks workable yet complicated - I wish there was a simpler way = but I could live with this.=20 From fluffy@cisco.com Wed Jun 16 10:01:19 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 8B2B63A6B49 for ; Wed, 16 Jun 2010 10:01:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -107.628 X-Spam-Level: X-Spam-Status: No, score=-107.628 tagged_above=-999 required=5 tests=[AWL=-2.029, BAYES_50=0.001, J_CHICKENPOX_41=0.6, J_CHICKENPOX_45=0.6, J_CHICKENPOX_46=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_HI=-8, 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 ty10JQQZsLzj for ; Wed, 16 Jun 2010 10:01:18 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 9773A3A6820 for ; Wed, 16 Jun 2010 10:01:18 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQGACqgGEyrR7Hu/2dsb2JhbACeaWsGplSZfYUaBINS X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="145516713" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 16 Jun 2010 17:01:23 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GH0GsH010423 for ; Wed, 16 Jun 2010 17:01:22 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Impp: xmpp:cullenfluffyjennings@jabber.org Date: Wed, 16 Jun 2010 11:01:22 -0600 Message-Id: <197682FE-DE02-4E75-82BD-9548ACEACCAC@cisco.com> To: "martini@ietf.org" Mime-Version: 1.0 (Apple Message framework v1078) X-Mailer: Apple Mail (2.1078) Subject: [martini] GIN and user=insane 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, 16 Jun 2010 17:01:19 -0000 I'm objecting to the autouser stuff in GIN. The rest of this message is = just a longer rant saying the same thing so you can stop reading here if = you don't care.=20 We discussed user=3DX forever at IETF and never came to any satisfactory = resolution because the truth of the matter is that it was classic IETF = over engineering and in practice it was easy to ignore with no bad = consequences. This resulted in many problem - the worst way to fix = theses problems would be to make the situation even more complicated. = The best way would be to simplify the situation. In practice, people = don't have users names that are all numeric, and they don't have dial = strings that start with +. Think of how much simpler life would be if we = just assumed things that started with a + were an E.164 number, things = that were all numeric where a dial string and some times a dial string = happened to be exactly the same as the related phone number and things = that looked like were alpha number where email style user names. I am = not aware of single deployment that does not fit the above model. =46rom = a purely pragmatic point of view, many systems already implicitly assume = the above. I've yet to see a deployment where both calls to 123@domain = and 123@domain;user=3Dphone both work yet go to different places. Yes, I = understand it is possible in theory but it would be nuts to deploy that.=20= For years people have tried to clarify this whole things by adding more = definition, yet implementations mostly just ignored it - and for good = reason - it did not really matter. So now we have the issue where some = PBX want user=3Dphone and some do not. To implement GIN on theses PBX, = code is going to have to change, so instead of making the situation = worse with autouser=3Dtrue, why don't we just fix the bugs and cause the = PBX to be be generous in what they are willing to receive.=20 From adam@nostrum.com Wed Jun 16 10:34: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 EB5703A68FB for ; Wed, 16 Jun 2010 10:34:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 Ast4iAHB04fQ for ; Wed, 16 Jun 2010 10:34:11 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CF1053A6A72 for ; Wed, 16 Jun 2010 10:34:10 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5GHXV07023764 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2010 12:33:32 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C190AEB.2070501@nostrum.com> Date: Wed, 16 Jun 2010 12:33:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> In-Reply-To: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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, 16 Jun 2010 17:34:12 -0000 On 6/16/10 12:01 PM, Cullen Jennings wrote: > I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response? > I don't think so. Even for a 1024-bit key (which is pretty much the smallest RSA key one would consider using), you're looking at 171 bytes once you've base-64 encoded them. 2048-bit keys, which are not unrealistically large, would be 342 bytes long. I think these would pose very real problems in a REGISTER response. I did briefly think about using draft-ietf-sip-certs to get keys, but that introduced even *more* complexity. Plus, it can be added on as an extension at a later date if people really want it. But I think we'd be really getting out way in front of demand if we did that now. /a From fluffy@cisco.com Wed Jun 16 10:38:04 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 16EAB3A6A72 for ; Wed, 16 Jun 2010 10:38:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.993 X-Spam-Level: X-Spam-Status: No, score=-109.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 1WHi77x0bm-K for ; Wed, 16 Jun 2010 10:37:57 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 2FD1C3A6B62 for ; Wed, 16 Jun 2010 10:37:56 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAF+oGEyrR7Hu/2dsb2JhbACeaXGmS5l6hRoEg1I X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="545867123" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2010 17:37:45 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o5GHbi2G017292; Wed, 16 Jun 2010 17:37:44 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C190AEB.2070501@nostrum.com> Date: Wed, 16 Jun 2010 11:37:43 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C190AEB.2070501@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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, 16 Jun 2010 17:38:05 -0000 On Jun 16, 2010, at 11:33 AM, Adam Roach wrote: > > =20 >=20 > I don't think so. Even for a 1024-bit key (which is pretty much the > smallest RSA key one would consider using), you're looking at 171 = bytes > once you've base-64 encoded them. 2048-bit keys, which are not > unrealistically large, would be 342 bytes long. >=20 > I think these would pose very real problems in a REGISTER response. I don't see why that size is a problem. I get SDP in responses that is = larger than this all the time.=20 From adam@nostrum.com Wed Jun 16 10:43:39 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 012723A6B6B for ; Wed, 16 Jun 2010 10:43:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 I0BY4e5DhYW3 for ; Wed, 16 Jun 2010 10:43:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8E48D3A6B6A for ; Wed, 16 Jun 2010 10:43:37 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5GHhdeU024590 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 16 Jun 2010 12:43:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C190D4B.6080107@nostrum.com> Date: Wed, 16 Jun 2010 12:43:39 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Cullen Jennings References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C190AEB.2070501@nostrum.com> <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> In-Reply-To: <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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, 16 Jun 2010 17:43:39 -0000 On 6/16/10 12:37 PM, Cullen Jennings wrote: > On Jun 16, 2010, at 11:33 AM, Adam Roach wrote: > > >>> >>> >> I don't think so. Even for a 1024-bit key (which is pretty much the >> smallest RSA key one would consider using), you're looking at 171 bytes >> once you've base-64 encoded them. 2048-bit keys, which are not >> unrealistically large, would be 342 bytes long. >> >> I think these would pose very real problems in a REGISTER response. >> > I don't see why that size is a problem. I get SDP in responses that is larger than this all the time. > > To put it another way -- you could fit an awful lot of phone numbers into 342 bytes (if packed using some sane approach), but people were freaking clean out of their skins at the prospect that we might even try. It would be easy to specify, of course. I just want to make sure that we're not going to have another knock-down-drag-out fight over response sizes. /a From ietf.hanserik@gmail.com Wed Jun 16 10:53:23 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 BDDB73A6B78 for ; Wed, 16 Jun 2010 10:53:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6] 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 j6JXcCD7O4e1 for ; Wed, 16 Jun 2010 10:53:23 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id CED713A6B77 for ; Wed, 16 Jun 2010 10:53:19 -0700 (PDT) Received: by wya21 with SMTP id 21so2260006wya.31 for ; Wed, 16 Jun 2010 10:53:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=i5+8inRMqaWVOx7+oQCGc59jm/tLqZLyYPKxICNscPQ=; b=J08xnVPb8CTJVIY4M9ohwSBFe4rooNVv+nT7/3VHHu1IZbAY8g+BcF5j/wjpUTy4bX r+95fkuqsbun1TFNn4xilkVRRxd4ZyabecBdLwx7X1EGbfMciOQjYSgMJ3e4a+oTjM0j 3q9dzaoYHKFS9UUSYZFagcfNeB9L75RrZEuSI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=diOkm5UxpyzVAEJtgjTitcd+Rx6IEOM5SIs+qhT4nWOyUSDu0Q9PfUu3fGAgZta/9i M0DYnOerIZRjpHUYi06z5sneFfiYMoQFxQRJcOExuHTKaqYjH2CsUyNGo7UydUeD40g7 UQaZcyPJXEBxIBJp1EQ0QcntBjnW5dYJhGzKA= MIME-Version: 1.0 Received: by 10.216.90.8 with SMTP id d8mr5384762wef.52.1276710800211; Wed, 16 Jun 2010 10:53:20 -0700 (PDT) Received: by 10.216.179.70 with HTTP; Wed, 16 Jun 2010 10:53:20 -0700 (PDT) In-Reply-To: <197682FE-DE02-4E75-82BD-9548ACEACCAC@cisco.com> References: <197682FE-DE02-4E75-82BD-9548ACEACCAC@cisco.com> Date: Wed, 16 Jun 2010 19:53:20 +0200 Message-ID: From: Hans Erik van Elburg To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6d778beba40c704892965d6 Cc: "martini@ietf.org" Subject: Re: [martini] GIN and user=insane 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, 16 Jun 2010 17:53:23 -0000 --0016e6d778beba40c704892965d6 Content-Type: text/plain; charset=ISO-8859-1 +1 /Hans Erik van Elburg On Wed, Jun 16, 2010 at 7:01 PM, Cullen Jennings wrote: > > I'm objecting to the autouser stuff in GIN. The rest of this message is > just a longer rant saying the same thing so you can stop reading here if you > don't care. > > > --0016e6d778beba40c704892965d6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable +1

/Hans Erik van Elburg

On Wed, Jun 16, 2010 at 7:01 PM, Cullen Jenn= ings <fluffy@cisco= .com> wrote:

I'm objecting to the autouser stuff in GIN. The rest of this message is= just a longer rant saying the same thing so you can stop reading here if y= ou don't care.


--0016e6d778beba40c704892965d6-- From ietf.hanserik@gmail.com Wed Jun 16 10:59:18 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 3EE543A6B78 for ; Wed, 16 Jun 2010 10:59:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 l1SkWR1lX1z0 for ; Wed, 16 Jun 2010 10:59:17 -0700 (PDT) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 1C3353A6B79 for ; Wed, 16 Jun 2010 10:59:16 -0700 (PDT) Received: by wwc33 with SMTP id 33so778985wwc.31 for ; Wed, 16 Jun 2010 10:59:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=k0y4rmxqAAa71BcQeS8ivv8KeHk+AJuL+qqe/YFN+k8=; b=LJvZJVRgKYolybWPIc2k6gsONjNZbfMJ+qKLuNjaT6RXnhfQQ6xErBc0bOm/TJ6q2A US4i63mPq3pXn1QewxlZajrIeaIk+sFhLq4WSgH+s/LnCYigWx/KgdWxKaRyxzS+C4gi BwEVuOdsklaZ+tph2WLBaIdaGvJ5yAL3rBPZk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=r/dZz+JEZJY/h5JdA9hWYaEM75vzHxytzoRVDZAUhdlBCoruL3IxUZMig1as5OK2Qx SeirGp2vm2IxvRDTUNTg+bHZCDFzJ94wYuIBmF9t5Acassc0TktJ5TLHXIREGIpmzaWc eZbVqFUNVSnCJzY+b+9hNNoy1bSqBLSjYqfr4= MIME-Version: 1.0 Received: by 10.216.91.6 with SMTP id g6mr1020354wef.95.1276711156810; Wed, 16 Jun 2010 10:59:16 -0700 (PDT) Received: by 10.216.179.70 with HTTP; Wed, 16 Jun 2010 10:59:16 -0700 (PDT) In-Reply-To: <5CD60AE9-482E-47D8-8FF8-5F64101DCAA6@cisco.com> References: <5CD60AE9-482E-47D8-8FF8-5F64101DCAA6@cisco.com> Date: Wed, 16 Jun 2010 19:59:16 +0200 Message-ID: From: Hans Erik van Elburg To: Cullen Jennings Content-Type: multipart/alternative; boundary=0016e6d62699fb84340489297a6a Cc: "martini@ietf.org" Subject: Re: [martini] Question about draft-vanelburg-martini-fiends 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, 16 Jun 2010 17:59:18 -0000 --0016e6d62699fb84340489297a6a Content-Type: text/plain; charset=ISO-8859-1 There is a reference section in the friends draft. But I think also Johns requirement draft has the refenrences. ETSI TISPAN NGN Release 2 containing the business trunking solution is published for around 2 years. The needed core IMS mechanisms have been specified in 3GPP 24229 for example. Others might have better overview of the details. Best Regards, /Hans Erik van Elburg On Wed, Jun 16, 2010 at 7:00 PM, Cullen Jennings wrote: > > Can someone explain to me what is the solution that 3GPP has specified for > this? And is the specification done or still be worked on? > > Thanks, Cullen > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > --0016e6d62699fb84340489297a6a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable There is a reference section in the friends draft. But I think also Johns r= equirement draft has the refenrences.

ETSI TISPAN NGN Release 2 cont= aining the business trunking solution is published for around 2 years. The = needed core IMS mechanisms have been=A0 specified in 3GPP 24229 for example= .

Others might have better overview of the details.

Best Regards,<= br clear=3D"all">/Hans Erik van Elburg

On Wed, Jun 16, 2010 at 7:00 PM, Cullen Jenn= ings <fluffy@cisco= .com> wrote:

Can someone explain to me what is the solution that 3GPP has specified for = this? And is the specification done or still be worked on?

Thanks, Cullen


_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini

--0016e6d62699fb84340489297a6a-- From fluffy@cisco.com Wed Jun 16 11:09:40 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 0E5353A6B7A for ; Wed, 16 Jun 2010 11:09:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.823 X-Spam-Level: X-Spam-Status: No, score=-108.823 tagged_above=-999 required=5 tests=[AWL=-0.638, BAYES_40=-0.185, RCVD_IN_DNSWL_HI=-8, 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 Y9bjhrz6HHMC for ; Wed, 16 Jun 2010 11:09:39 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 361883A6932 for ; Wed, 16 Jun 2010 11:09:39 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJWwGEyrR7H+/2dsb2JhbACea3GmWpl5hRoEg1I X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="545889330" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2010 18:09:44 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5GI9hlr007345; Wed, 16 Jun 2010 18:09:43 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <4C190D4B.6080107@nostrum.com> Date: Wed, 16 Jun 2010 12:09:42 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C190AEB.2070501@nostrum.com> <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> <4C190D4B.6080107@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1078) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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, 16 Jun 2010 18:09:40 -0000 On Jun 16, 2010, at 11:43 AM, Adam Roach wrote: > On 6/16/10 12:37 PM, Cullen Jennings wrote: >> On Jun 16, 2010, at 11:33 AM, Adam Roach wrote: >>=20 >> =20 >>>>=20 >>>> =20 >>> I don't think so. Even for a 1024-bit key (which is pretty much the >>> smallest RSA key one would consider using), you're looking at 171 = bytes >>> once you've base-64 encoded them. 2048-bit keys, which are not >>> unrealistically large, would be 342 bytes long. >>>=20 >>> I think these would pose very real problems in a REGISTER response. >>> =20 >> I don't see why that size is a problem. I get SDP in responses that = is larger than this all the time. >>=20 >> =20 >=20 > To put it another way -- you could fit an awful lot of phone numbers = into 342 bytes (if packed using some sane approach), but people were = freaking clean out of their skins at the prospect that we might even = try. Sure, we only got to GIN due to fairly unlikely requirements combined = with strange beliefs about compression - can't say I like it but I could = live with it. GIN does seem like a lot of work just to avoid turning on = DynDNS on my NAT but whatever. I see no problem with stuffing a 1500 = bit key in the responses and if people think that is going to fail, it = seems that some pretty typically INVITES are also going to fail. =20 >=20 > It would be easy to specify, of course. I just want to make sure that = we're not going to have another knock-down-drag-out fight over response = sizes. I've got 3 gallons of shed paint left but can only transport it over = UDP. From keith.drage@alcatel-lucent.com Wed Jun 16 12:50:32 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 104E828C182 for ; Wed, 16 Jun 2010 12:50:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.174 X-Spam-Level: X-Spam-Status: No, score=-3.174 tagged_above=-999 required=5 tests=[AWL=-0.925, BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 dMjVDVnCll+5 for ; Wed, 16 Jun 2010 12:50:25 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 03CF43A6BB2 for ; Wed, 16 Jun 2010 12:50:23 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o5GJoOba004598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 16 Jun 2010 21:50:25 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 16 Jun 2010 21:50:24 +0200 From: "DRAGE, Keith (Keith)" To: "martini@ietf.org" Date: Wed, 16 Jun 2010 21:46:47 +0200 Thread-Topic: References to 3GPP solution Thread-Index: AcsNjKfARALrbLeDREOTzlt/MQrJfw== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Subject: [martini] References to 3GPP solution 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, 16 Jun 2010 19:50:32 -0000 There are a number of references needed to build the solution, but the prim= e reference that leads to the rest at the protocol level is: ETSI TS 182 025 subclause 5.2, subclause 6.1. Note that where details of the protocol are not in that document, they are = essentially reusing standard IMS (as in 3GPP TS 24.229), which is mostly st= andard SIP. Keith= From spencer@wonderhamster.org Wed Jun 16 13:19:32 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 F235E3A6BCD for ; Wed, 16 Jun 2010 13:19:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.151 X-Spam-Level: X-Spam-Status: No, score=0.151 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_50=0.001, STOX_REPLY_TYPE=0.001] 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 hRcCGxDJIox0 for ; Wed, 16 Jun 2010 13:19:30 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.195]) by core3.amsl.com (Postfix) with ESMTP id 058433A67A2 for ; Wed, 16 Jun 2010 13:19:30 -0700 (PDT) Received: from S73602b ([220.231.21.146]) by mrelay.perfora.net (node=mrus2) with ESMTP (Nemesis) id 0M0hPy-1PFS2u2Mxy-00uaLq; Wed, 16 Jun 2010 16:19:34 -0400 Message-ID: <3824B3E8AFE041CABBBB5551BEE15C4C@china.huawei.com> From: "Spencer Dawkins" To: "DRAGE, Keith \(Keith\)" , References: Date: Thu, 17 Jun 2010 04:19:17 +0800 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.5931 X-Provags-ID: V01U2FsdGVkX1+W3E05o+IbzfoQsMwZy+Jd1j+Ota2bpIvdPfz qzEwm9mPMm5DkTjThHD72Akcjvt1D2aUBfyDAH+r873rY2RDlk Ki1un13Rw9eYr8XL9eIhgFsrX0SNYWRDjDK2+zrRyI= Subject: Re: [martini] References to 3GPP solution 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, 16 Jun 2010 20:19:32 -0000 > There are a number of references needed to build the solution, but the > prime reference that leads to the rest at the protocol level is: > > ETSI TS 182 025 subclause 5.2, subclause 6.1. > > Note that where details of the protocol are not in that document, they are > essentially reusing standard IMS (as in 3GPP TS 24.229), which is mostly > standard SIP. Just in case people don't have the link already, Brian Lindsay suggested "The TISPAN architecture document for this work is ETSI TS 182 025, which can be downloaded here: http://pda.etsi.org/pda/queryform.asp" a while ago, on the SIP Forum TechWG mailing list ...Thanks,Spencer From fluffy@cisco.com Wed Jun 16 13:48:16 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 4962D3A67A2 for ; Wed, 16 Jun 2010 13:48:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.993 X-Spam-Level: X-Spam-Status: No, score=-109.993 tagged_above=-999 required=5 tests=[AWL=0.606, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 PHtUurvpNHZO for ; Wed, 16 Jun 2010 13:48:15 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 0D43A3A68A3 for ; Wed, 16 Jun 2010 13:48:15 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPHUGEyrR7Ht/2dsb2JhbACebnGldJoGhRoEg1I X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="213455451" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 16 Jun 2010 20:48:20 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5GKmJO2026666; Wed, 16 Jun 2010 20:48:19 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: Date: Wed, 16 Jun 2010 14:48:18 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97F69202-58A7-429C-AE3F-F32F660D2E95@cisco.com> References: To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1078) Cc: "martini@ietf.org" Subject: Re: [martini] References to 3GPP solution 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, 16 Jun 2010 20:48:16 -0000 So I was just looking at=20 = http://www.etsi.org/deliver/etsi_ts/182000_182099/182025/02.01.01_60/ts_18= 2025v020101p.pdf and read section 5.2 and 6.1. I had a hard time making heads or tails of = it but it looked to me like they had a regular expression approach that = violates more than one SIP spec. Could you make sure the liaison coming = over from 3GPP address if 3GPP thinks the already specified solution = violates the IETF specs, I'm sure that will be an important part of the = discussion with the IAB. On Jun 16, 2010, at 1:46 PM, DRAGE, Keith (Keith) wrote: > There are a number of references needed to build the solution, but the = prime reference that leads to the rest at the protocol level is: >=20 > ETSI TS 182 025 subclause 5.2, subclause 6.1. >=20 > Note that where details of the protocol are not in that document, they = are essentially reusing standard IMS (as in 3GPP TS 24.229), which is = mostly standard SIP. >=20 > Keith > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini From richard@shockey.us Wed Jun 16 17:14:05 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 CCDE43A67FA for ; Wed, 16 Jun 2010 17:14:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.058 X-Spam-Level: X-Spam-Status: No, score=0.058 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_50=0.001, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] 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 FTDKOok4Hptf for ; Wed, 16 Jun 2010 17:14:02 -0700 (PDT) Received: from oproxy3-pub.bluehost.com (oproxy3-pub.bluehost.com [69.89.21.8]) by core3.amsl.com (Postfix) with SMTP id 070583A688E for ; Wed, 16 Jun 2010 17:14:00 -0700 (PDT) Received: (qmail 30096 invoked by uid 0); 16 Jun 2010 23:14:06 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy3.bluehost.com with SMTP; 16 Jun 2010 23:14:06 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:Subject:Date:Message-ID:MIME-Version:Content-Type:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=AcVFfIM3SFD12X+Tmv3hmPmjHfd//wQ2PhWw3yEvvv6s4kSQRzYK/PuuLfxVKyjzgUGX9b0VaFSDD+3ezN2i/3oNMK6QM9ZmH43ZgBfmHyTjR/C1pc8IJGhsCrXJ3skC; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OP1o6-0004WQ-AF for martini@ietf.org; Wed, 16 Jun 2010 17:14:06 -0600 From: "Richard Shockey" To: Date: Wed, 16 Jun 2010 19:13:57 -0400 Message-ID: <002f01cb0da9$9998c070$ccca4150$@us> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0030_01CB0D88.12872070" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsNqZj7SFj5T/XsTcu3cfHoDRMltA== Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: [martini] On the essential issue... 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: Thu, 17 Jun 2010 00:14:06 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0030_01CB0D88.12872070 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit I wish to reiterate my support, as we discussed on the call, for a "2 state" solution here. Two options tags. One for the gin solution and one for the 3GPP solution. In addition I do not believe these IANA requests should be made in a single RFC they should IMHO be separate documents. Richard Shockey Shockey Consulting Chairman of the Board of Directors SIP Forum PSTN Mobile: +1 703.593.2683 < mailto:richard(at)shockey.us> skype: rshockey101 LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org ------=_NextPart_000_0030_01CB0D88.12872070 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I wish to reiterate my support, as we discussed on = the call, for a  “2 state” solution here.

 

Two options tags.

 

One for the gin solution and one for the 3GPP = solution.

 

In addition I do not believe these IANA =  requests should be made in a single RFC they should IMHO be separate documents. =

 

Richard = Shockey
Shockey Consulting
Chairman of the Board of Directors SIP Forum
PSTN Mobile: +1 703.593.2683
<mailto:richard(at)shockey.us>
skype: rshockey101
LinkedIn : http://www.linkedin.com/in/rshockey101 http//www.sipforum.org

 

------=_NextPart_000_0030_01CB0D88.12872070-- From pkyzivat@cisco.com Wed Jun 16 17:21:18 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 AA4D43A688E for ; Wed, 16 Jun 2010 17:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.971 X-Spam-Level: X-Spam-Status: No, score=-8.971 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_50=0.001, RCVD_IN_DNSWL_HI=-8] 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 XcBk5-sBzoL4 for ; Wed, 16 Jun 2010 17:21:09 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id BE2863A6846 for ; Wed, 16 Jun 2010 17:21:08 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUGAEf8GExAZnwM/2dsb2JhbACeb2sGpVKZfoUaBA X-IronPort-AV: E=Sophos;i="4.53,427,1272844800"; d="scan'208";a="122507077" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 16 Jun 2010 23:35:23 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o5GNZN5V015061 for ; Wed, 16 Jun 2010 23:35:23 GMT Message-ID: <4C195FBB.3070400@cisco.com> Date: Wed, 16 Jun 2010 19:35:23 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [martini] draft-vanelburg-martini-friends-00 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: Thu, 17 Jun 2010 00:21:19 -0000 Somehow I missed this draft before, but following the interim meeting today I read it. IIUC this proposal is similar to the original "shaken" proposal (I think that was the one) to use the Contact-URI from REGISTER as a Route header rather than using it to rewrite the R-URI (which was adapted for martini by the gin draft). There were pros and cons to both of those proposals. IMO we eventually decided to pursue -gin because its balance of pros to cons was thought, at the time, to be better than the alternative. Now -friends essentially proposes to adopt both approaches. ISTM that is the worst of all possible worlds. Its double the work for those who want to support both, and it presents interop problems for those who don't support both. And its just two solutions to the same problem - there is almost no benefit to having both over having one. IMO there needs to be a *choice* among alternative approaches. (They pay us the big bucks to make hard choices.) Potentially we could make such a choice, if we had two proposals of comparable completeness to choose among. For that I think we would need another draft, that fleshes out the "domain federation" approach. (Maybe -shaken or another of Hadriel's early drafts on the subject could be a starting point.) Just pointing to an ETSI document isn't enough. Some tricky things that have come up along the way with -gin would also need to be dealt with in this alternative. Among them is GRUU, especially temporary GRUUs. Something similar to what Adam has proposed for -gin is probably needed to address the same issues. Also, some issues unique to this approach need to be addressed. Specifically, how does the registered contact that becomes a Route header interact with - existing Route headers in the incoming request? - Path headers that were registered? There may also be issues with routing spirals when using GRUUs. This was a knotty problem in IMS. (I wrote some text regarding that which may or may not have made it into 24.229.) (To be fair, this issue may also exist with -gin, so it will need to be investigated/solved either way.) I liked Jonathan's original proposal to switch registration routing to use Route headers. I could be happy with a Martini approach that went in that direction if it deals with all the loose ends. So to the authors of -friends (and their friends) I suggest that if you want to see a martini solution that uses the "domain federation" approach, please submit a draft that spells out all the details needed to define that. Thanks, Paul From dean.willis@softarmor.com Wed Jun 16 18:35:07 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 7456C3A6784 for ; Wed, 16 Jun 2010 18:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001] 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 8vK8xK7hKUyS for ; Wed, 16 Jun 2010 18:35:05 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C52BD3A6782 for ; Wed, 16 Jun 2010 18:35:01 -0700 (PDT) Received: from [192.168.2.113] (cpe-66-25-30-183.tx.res.rr.com [66.25.30.183]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o5H1Z37S019787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 16 Jun 2010 20:35:04 -0500 Message-Id: <0CFA6FF7-B955-45F8-BA4C-9941C926A578@softarmor.com> From: Dean Willis To: Cullen Jennings In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Wed, 16 Jun 2010 20:34:53 -0500 References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C190AEB.2070501@nostrum.com> <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> <4C190D4B.6080107@nostrum.com> X-Mailer: Apple Mail (2.936) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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: Thu, 17 Jun 2010 01:35:07 -0000 On Jun 16, 2010, at 1:09 PM, Cullen Jennings wrote: > > Sure, we only got to GIN due to fairly unlikely requirements > combined with strange beliefs about compression - can't say I like > it but I could live with it. GIN does seem like a lot of work just > to avoid turning on DynDNS on my NAT but whatever. I see no problem > with stuffing a 1500 bit key in the responses and if people think > that is going to fail, it seems that some pretty typically INVITES > are also going to fail. Just to reiterate, DynDNS is inadequate, as my NAT doesn't know which of my phones/pbexes to redirect port 5060 for, and it works much better if I use a real publicly-reachable proxy to register with, ala outbound. MARTINI fits into this space, specifically for PBXes with more than one DID number. -- Dean From peter.leis@nsn.com Thu Jun 17 00:36:31 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 16DDD3A6A18 for ; Thu, 17 Jun 2010 00:36:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_46=0.6] 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 gMQQSk57Wyq6 for ; Thu, 17 Jun 2010 00:36:30 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 099403A67E5 for ; Thu, 17 Jun 2010 00:36:26 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id o5H7aQuW031562 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 17 Jun 2010 09:36:26 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id o5H7aQIl018062; Thu, 17 Jun 2010 09:36:26 +0200 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 17 Jun 2010 09:36:25 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0DEF.CA6788BA" Date: Thu, 17 Jun 2010 09:36:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] GIN and user=insane Thread-Index: AcsNfNYAmBwKAdwhQZWsu8SCTWKWkgAcuDmw References: <197682FE-DE02-4E75-82BD-9548ACEACCAC@cisco.com> From: "Leis, Peter (NSN - DE/Munich)" To: "martini@ietf.org" X-OriginalArrivalTime: 17 Jun 2010 07:36:25.0949 (UTC) FILETIME=[CAB670D0:01CB0DEF] Subject: Re: [martini] GIN and user=insane 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: Thu, 17 Jun 2010 07:36:31 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0DEF.CA6788BA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable +1 ________________________________ From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of ext Hans Erik van Elburg Sent: Wednesday, June 16, 2010 7:53 PM To: Cullen Jennings Cc: martini@ietf.org Subject: Re: [martini] GIN and user=3Dinsane =09 =09 +1 =09 /Hans Erik van Elburg =09 =09 On Wed, Jun 16, 2010 at 7:01 PM, Cullen Jennings wrote: =09 I'm objecting to the autouser stuff in GIN. The rest of this message is just a longer rant saying the same thing so you can stop reading here if you don't care. =09 =09 =09 ------_=_NextPart_001_01CB0DEF.CA6788BA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
+1

From: martini-bounces@ietf.org=20 [mailto:martini-bounces@ietf.org] On Behalf Of ext Hans Erik = van=20 Elburg
Sent: Wednesday, June 16, 2010 7:53 PM
To: = Cullen=20 Jennings
Cc: martini@ietf.org
Subject: Re: = [martini] GIN=20 and user=3Dinsane

+1

/Hans Erik van Elburg

On Wed, Jun 16, 2010 at 7:01 PM, Cullen = Jennings <fluffy@cisco.com>=20 wrote:

I'm objecting to the autouser stuff in GIN. = The rest=20 of this message is just a longer rant saying the same thing so you = can stop=20 reading here if you don't=20 care.


------_=_NextPart_001_01CB0DEF.CA6788BA-- From john.elwell@siemens-enterprise.com Thu Jun 17 02:47:49 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 90A023A6A35 for ; Thu, 17 Jun 2010 02:47:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.601 X-Spam-Level: X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[AWL=-0.416, BAYES_40=-0.185] 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 4fGSfHLFsypI for ; Thu, 17 Jun 2010 02:47:46 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7FF9C3A6A48 for ; Thu, 17 Jun 2010 02:47:22 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-539395; Thu, 17 Jun 2010 11:47:24 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D716E23F0278; Thu, 17 Jun 2010 11:47:24 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 17 Jun 2010 11:47:25 +0200 From: "Elwell, John" To: Richard Shockey , "martini@ietf.org" Date: Thu, 17 Jun 2010 11:47:23 +0200 Thread-Topic: [martini] On the essential issue... Thread-Index: AcsNqZj7SFj5T/XsTcu3cfHoDRMltAASJPgQ Message-ID: References: <002f01cb0da9$9998c070$ccca4150$@us> In-Reply-To: <002f01cb0da9$9998c070$ccca4150$@us> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] On the essential issue... 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: Thu, 17 Jun 2010 09:47:49 -0000 This is not the essential issue. The essential issue is whether the 3GPP so= lution is acceptable to the IETF, subjecting it to the same scrutiny as ear= lier proposals from the SIP Forum that were rejected by the IETF. In fact t= he 3GPP solution is not 100 miles away from earlier SIP Forum proposals. If= we could have a single solution, that would obviously be preferable. So if= the 3GPP solution is acceptable to the IETF, would it also be acceptable t= o the SIP Forum? If the 3GPP does not pass scrutiny with the IETF, it could still be publish= ed as an RFC for use in the 3GPP closed environment (as has been the case w= ith several other things specific to 3GPP). In that case, clearly it would = need to be in a separate RFC. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Richard Shockey > Sent: 17 June 2010 00:14 > To: martini@ietf.org > Subject: [martini] On the essential issue... >=20 > I wish to reiterate my support, as we discussed on the call,=20 > for a "2 state" solution here.=20 >=20 > =20 >=20 > Two options tags.=20 >=20 > =20 >=20 > One for the gin solution and one for the 3GPP solution. >=20 > =20 >=20 > In addition I do not believe these IANA requests should be=20 > made in a single RFC they should IMHO be separate documents.=20 >=20 > =20 >=20 > Richard Shockey > Shockey Consulting > Chairman of the Board of Directors SIP Forum > PSTN Mobile: +1 703.593.2683 > > > skype: rshockey101 > LinkedIn : http://www.linkedin.com/in/rshockey101=20 > =20 > http//www.sipforum.org >=20 > =20 >=20 > = From fluffy@cisco.com Thu Jun 17 08:28:38 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 BB7223A6AF6 for ; Thu, 17 Jun 2010 08:28:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.027 X-Spam-Level: X-Spam-Status: No, score=-110.027 tagged_above=-999 required=5 tests=[AWL=0.572, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 7AbPdB0fWk4A for ; Thu, 17 Jun 2010 08:28:38 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 0B07A3A6AF5 for ; Thu, 17 Jun 2010 08:28:38 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGfbGUyrR7H+/2dsb2JhbACed3GmJZpEhRoEg1I X-IronPort-AV: E=Sophos;i="4.53,432,1272844800"; d="scan'208";a="146060218" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 17 Jun 2010 15:28:43 +0000 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5HFSgtc013086; Thu, 17 Jun 2010 15:28:42 GMT Mime-Version: 1.0 (Apple Message framework v1078) Content-Type: text/plain; charset=us-ascii Impp: xmpp:cullenfluffyjennings@jabber.org From: Cullen Jennings In-Reply-To: <0CFA6FF7-B955-45F8-BA4C-9941C926A578@softarmor.com> Date: Thu, 17 Jun 2010 09:28:41 -0600 Content-Transfer-Encoding: 7bit Message-Id: <8A06D7D7-55E1-4145-B20E-1455E8D34E06@cisco.com> References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C190AEB.2070501@nostrum.com> <79AEBFF1-1987-4CA3-AAD3-0FA7C5D33996@cisco.com> <4C190D4B.6080107@nostrum.com> <0CFA6FF7-B955-45F8-BA4C-9941C926A578@softarmor.com> To: Dean Willis X-Mailer: Apple Mail (2.1078) Cc: martini@ietf.org Subject: Re: [martini] GIN temp GRUU 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: Thu, 17 Jun 2010 15:28:38 -0000 On Jun 16, 2010, at 7:34 PM, Dean Willis wrote: > > On Jun 16, 2010, at 1:09 PM, Cullen Jennings wrote: > > > > > Sure, we only got to GIN due to fairly unlikely requirements > > combined with strange beliefs about compression - can't say I like > > it but I could live with it. GIN does seem like a lot of work just > > to avoid turning on DynDNS on my NAT but whatever. I see no problem > > with stuffing a 1500 bit key in the responses and if people think > > that is going to fail, it seems that some pretty typically INVITES > > are also going to fail. > > Just to reiterate, DynDNS is inadequate, as my NAT doesn't know which > of my phones/pbexes to redirect port 5060 for, and it works much > better if I use a real publicly-reachable proxy to register with, ala > outbound. MARTINI fits into this space, specifically for PBXes with > more than one DID number. Yah - I've lost that argument. I should not have brought it up. From trac@tools.ietf.org Thu Jun 17 15:10:00 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 AD29D3A6A37 for ; Thu, 17 Jun 2010 15:10:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.356 X-Spam-Level: X-Spam-Status: No, score=-102.356 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599, NO_RELAYS=-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 F3nwZOTxEP6r for ; Thu, 17 Jun 2010 15:10:00 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 0E91D3A6B24 for ; Thu, 17 Jun 2010 15:10:00 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OPNHe-0003vq-82; Thu, 17 Jun 2010 15:10:02 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Thu, 17 Jun 2010 22:10:02 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/35#comment:6 Message-ID: <085.e6c62570cb926d58858ef74aa8d96375@tools.ietf.org> References: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-Trac-Ticket-ID: 35 In-Reply-To: <076.e6cc00fa95c4de7c0466bc499cb65491@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #35: Use of the word "extensions" X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 22:10:00 -0000 #35: Use of the word "extensions" ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------------------+--------------------------- Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Updated in -04 -- Ticket URL: martini From trac@tools.ietf.org Thu Jun 17 15:10:34 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 2A5C73A6B24 for ; Thu, 17 Jun 2010 15:10:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.359 X-Spam-Level: X-Spam-Status: No, score=-102.359 tagged_above=-999 required=5 tests=[AWL=0.241, BAYES_00=-2.599, NO_RELAYS=-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 GoOBmk-8K1Lj for ; Thu, 17 Jun 2010 15:10:33 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6153A3A6876 for ; Thu, 17 Jun 2010 15:10:33 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OPNIF-0004ca-2a; Thu, 17 Jun 2010 15:10:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Thu, 17 Jun 2010 22:10:39 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/40#comment:1 Message-ID: <067.02a5576a05605ae2133b118800265bdd@tools.ietf.org> References: <058.d58a10c6dc955f4daed65c19fdcf878b@tools.ietf.org> X-Trac-Ticket-ID: 40 In-Reply-To: <058.d58a10c6dc955f4daed65c19fdcf878b@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #40: Public GRUU Example is Incorrect X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 22:10:34 -0000 #40: Public GRUU Example is Incorrect --------------------------------+------------------------------------------- Reporter: adam@… | Owner: Type: defect | Status: closed Priority: trivial | Milestone: milestone1 Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | --------------------------------+------------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Fixed in -04 -- Ticket URL: martini From trac@tools.ietf.org Thu Jun 17 15:28:14 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 D251828C0EE for ; Thu, 17 Jun 2010 15:28:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.061 X-Spam-Level: X-Spam-Status: No, score=-102.061 tagged_above=-999 required=5 tests=[AWL=-0.061, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, NO_RELAYS=-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 BQo-5BBYH49T for ; Thu, 17 Jun 2010 15:28:14 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 3344A28C0DF for ; Thu, 17 Jun 2010 15:28:14 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OPNZL-0007os-EM; Thu, 17 Jun 2010 15:28:19 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Thu, 17 Jun 2010 22:28:19 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/28#comment:2 Message-ID: <073.6301692308a9ed6ed6f6220210e21716@tools.ietf.org> References: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> X-Trac-Ticket-ID: 28 In-Reply-To: <064.241210f222f003dfaa003794ffd3ae94@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #28: GIN: user=phone in the Contact X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 22:28:14 -0000 #28: GIN: user=phone in the Contact ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: adam@… Type: defect | Status: closed Priority: minor | Milestone: Component: gin | Version: Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: assigned => closed * resolution: => fixed Comment: Re-resolving in -04, per discussion at Interim V. -- Ticket URL: martini From trac@tools.ietf.org Thu Jun 17 15:39:54 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 5A59628C0CF for ; Thu, 17 Jun 2010 15:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.36 X-Spam-Level: X-Spam-Status: No, score=-102.36 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, NO_RELAYS=-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 4hTZFjC0NWyI for ; Thu, 17 Jun 2010 15:39:53 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 02F2428C0E9 for ; Thu, 17 Jun 2010 15:39:53 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OPNkc-0003aI-Lt; Thu, 17 Jun 2010 15:39:58 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Thu, 17 Jun 2010 22:39:58 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/43#comment:1 Message-ID: <073.6cdf23d67feb1fb17567c7f4ef476e5a@tools.ietf.org> References: <064.dc530b9ba5e66b0cf7f07120a5680d5d@tools.ietf.org> X-Trac-Ticket-ID: 43 In-Reply-To: <064.dc530b9ba5e66b0cf7f07120a5680d5d@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #43: Do option-tags in REGISTER apply for all expanded Contacts? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 22:39:54 -0000 #43: Do option-tags in REGISTER apply for all expanded Contacts? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Resolving with: If the SSP servers perform processing based on User Agent Capabilities (as defined in RFC 3840 ), they will treat any feature tags present on a "bnc" Contact header field as applicable to all of the resulting AOR-to-Contact mappings. Similarly, any option tags present on the REGISTER request that indicate special handling for any subsequent requests are also applicable to all of the AOR-to-Conact mappings. -- Ticket URL: martini From trac@tools.ietf.org Thu Jun 17 15:40:18 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 A49F628C0DF for ; Thu, 17 Jun 2010 15:40:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.362 X-Spam-Level: X-Spam-Status: No, score=-102.362 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, NO_RELAYS=-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 XDaVmuhxUAmG for ; Thu, 17 Jun 2010 15:40:17 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id E9F6328C0CF for ; Thu, 17 Jun 2010 15:40:17 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.71) (envelope-from ) id 1OPNl1-0003i7-EK; Thu, 17 Jun 2010 15:40:23 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com X-Trac-Project: martini Date: Thu, 17 Jun 2010 22:40:23 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/42#comment:1 Message-ID: <073.2ecd38fc20dca1e5d9b802e9d9ad1687@tools.ietf.org> References: <064.cc4bd224fb47783459292c826cf7630f@tools.ietf.org> X-Trac-Ticket-ID: 42 In-Reply-To: <064.cc4bd224fb47783459292c826cf7630f@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #42: Do Contact feature-tags apply to all expanded contacts? X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 List-Id: Discussion of en-mass SIP PBX registration mechanisms List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Jun 2010 22:40:18 -0000 #42: Do Contact feature-tags apply to all expanded contacts? ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: closed Priority: minor | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Resolution: fixed Keywords: | ------------------------------------+--------------------------------------- Changes (by adam@…): * status: new => closed * resolution: => fixed Comment: Resolving with: If the SSP servers perform processing based on User Agent Capabilities (as defined in RFC 3840 ), they will treat any feature tags present on a "bnc" Contact header field as applicable to all of the resulting AOR-to-Contact mappings. Similarly, any option tags present on the REGISTER request that indicate special handling for any subsequent requests are also applicable to all of the AOR-to-Conact mappings. -- Ticket URL: martini From root@core3.amsl.com Thu Jun 17 16:00:01 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 7BCAB3A6B2F; Thu, 17 Jun 2010 16:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100617230001.7BCAB3A6B2F@core3.amsl.com> Date: Thu, 17 Jun 2010 16:00:01 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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: Thu, 17 Jun 2010 23:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Registration for Multiple Phone Numbers in the Session Initiation Protocol (SIP) Author(s) : A. Roach Filename : draft-ietf-martini-gin-04.txt Pages : 27 Date : 2010-06-17 This document defines a mechanism by which a SIP server acting as a traditional Private Branch Exchange (SIP-PBX) can register with a SIP Service Provider (SSP) to receive phone calls for UAs designated by phone numbers. In order to function properly, this mechanism relies on the fact that the phone numbers are fully qualified and globally unique. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-gin-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-17155459.I-D@ietf.org> --NextPart-- From adam@nostrum.com Thu Jun 17 16:02:04 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 B50F53A6B2F for ; Thu, 17 Jun 2010 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 hizdpF4vvBjF for ; Thu, 17 Jun 2010 16:02:04 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 36F433A6B2E for ; Thu, 17 Jun 2010 16:02:00 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5HN24tk039852 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 17 Jun 2010 18:02:04 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C1AA96C.6070708@nostrum.com> Date: Thu, 17 Jun 2010 18:02:04 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [martini] New gin-04 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: Thu, 17 Jun 2010 23:02:04 -0000 Rather than wait for me to finish the things that'll take a bit longer, I've closed all the tickets that I could close quickly, and put out a new version. The key difference to look for here is the rewritten section 5.3, which captures the discussion we had on the Interim V phone call. It is also in line with Cullen's most recent post on the topic to this mailing list, along with the two "+1" supporting comments to that email. That it the sole technical change in this version of the document. All other changes are editorial or clarifying. New version: http://www.ietf.org/id/draft-ietf-martini-gin-04.txt Diffs: http://tools.ietf.org/rfcdiff?url2=draft-ietf-martini-gin-04.txt /a From john.elwell@siemens-enterprise.com Fri Jun 18 03:28:19 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 C35A83A680F for ; Fri, 18 Jun 2010 03:28:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.923 X-Spam-Level: X-Spam-Status: No, score=-1.923 tagged_above=-999 required=5 tests=[AWL=0.676, BAYES_00=-2.599] 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 zOJsNKu5FWzJ for ; Fri, 18 Jun 2010 03:28:18 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 8CBC93A679F for ; Fri, 18 Jun 2010 03:28:18 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-554674 for martini@ietf.org; Fri, 18 Jun 2010 12:28:23 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 25DC51EB82AB for ; Fri, 18 Jun 2010 12:28:23 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 18 Jun 2010 12:28:23 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Fri, 18 Jun 2010 12:28:21 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-gin-04.txt Thread-Index: AcsOcPGzDuBcRex0T7qThXSMIumhbQAXrbIg Message-ID: References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> In-Reply-To: <20100617230001.7BCAB3A6B2F@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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: Fri, 18 Jun 2010 10:28:19 -0000 Changes look good in general. I noticed the following in 5.3: "An SSP registrar that receives such a URI MAY discard the "user" parameter and process the request as if the parameter were not present. Alternately, it MAY return a 400 (Bad Request) error in response. Note that this requirement is talking about the user parameter of a URI:" 1. Instead of two "MAY"s, would it be better to have a "MUST do either ... = or ..."? The present formulation allows other behaviours - I don't know whe= ther we intend that or not. 2. In the note, what exactly does "this requirement" apply to? Presumably t= he "MUST" that came earlier, although if we do as I suggest in 1, we would = end up with a second MUST, so we might need to say "these requirements". De= pending on the resolution of 1, I think the note could do with some clarifi= cation. John > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of=20 > Internet-Drafts@ietf.org > Sent: 18 June 2010 00:00 > To: i-d-announce@ietf.org > Cc: martini@ietf.org > Subject: [martini] I-D Action:draft-ietf-martini-gin-04.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Multiple AoR reachabiliTy=20 > InformatioN Indication Working Group of the IETF. >=20 >=20 > Title : Registration for Multiple Phone=20 > Numbers in the Session Initiation Protocol (SIP) > Author(s) : A. Roach > Filename : draft-ietf-martini-gin-04.txt > Pages : 27 > Date : 2010-06-17 >=20 > This document defines a mechanism by which a SIP server acting as a > traditional Private Branch Exchange (SIP-PBX) can register with a SIP > Service Provider (SSP) to receive phone calls for UAs designated by > phone numbers. In order to function properly, this mechanism relies > on the fact that the phone numbers are fully qualified and globally > unique. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-martini-gin-04.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > = From laura.liess.dt@googlemail.com Fri Jun 18 05:12:41 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 796C73A6A51 for ; Fri, 18 Jun 2010 05:12:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.152 X-Spam-Level: X-Spam-Status: No, score=-0.152 tagged_above=-999 required=5 tests=[AWL=-0.775, BAYES_50=0.001, FM_FORGED_GMAIL=0.622] 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 53xq841oN6K9 for ; Fri, 18 Jun 2010 05:12:40 -0700 (PDT) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id C69293A6A45 for ; Fri, 18 Jun 2010 05:12:39 -0700 (PDT) Received: by wya21 with SMTP id 21so772411wya.31 for ; Fri, 18 Jun 2010 05:12:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:received:date:message-id :subject:from:to:cc:content-type; bh=DpJOpdNqohcBu8Kyi0vOxS9edHWG1U/xC75llLPI92U=; b=C0M1vSJoiS/iL0Zg3S/4z6Ehn7m6mMvjaa6m0pzcTCwIwMK7H5ak3++tQfDF0dL6mC CBqIXdim9M7sDf87pbH3oNsQK2EFm5kU95aD1UW6rDQZU+gk4FBJc7i1Ccev2rTKg08U pZIrG9qSbontf+aracHed3seheBWZZhyeNtIg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=xOkmnpqYcruedoFRzZgYdfrncrvFCy1zRZyR6vZIyGcmYg09JGtiawyyg6IeKhEK6c ywh8eHX+CloFV0lncTC486KIuQzGuJdJ+1Jcsxo6byaBN+SDCPZ70hxccsbnpiPKhmuc wAquKp6K7n5Kw8vr9EJUwDDVybJGTjCScBy8M= MIME-Version: 1.0 Received: by 10.216.90.211 with SMTP id e61mr100319wef.91.1276863162051; Fri, 18 Jun 2010 05:12:42 -0700 (PDT) Received: by 10.216.169.9 with HTTP; Fri, 18 Jun 2010 05:12:42 -0700 (PDT) Date: Fri, 18 Jun 2010 14:12:42 +0200 Message-ID: From: Laura Liess To: martini@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [martini] draft-vanelburg-martini-friends-00 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: Fri, 18 Jun 2010 12:12:41 -0000 +1 I agree with Paul. Having two completly different "standards" is not a good choice. In the end everybody will need to implement both, whatever the intention now. Laura From: Paul Kyzivat To: "martini at ietf.org" Date: Wed, 16 Jun 2010 19:35:23 -0400 List-id: Discussion of en-mass SIP PBX registration mechanisms -------------------------------------------------------------------------------- Somehow I missed this draft before, but following the interim meeting today I read it. IIUC this proposal is similar to the original "shaken" proposal (I think that was the one) to use the Contact-URI from REGISTER as a Route header rather than using it to rewrite the R-URI (which was adapted for martini by the gin draft). There were pros and cons to both of those proposals. IMO we eventually decided to pursue -gin because its balance of pros to cons was thought, at the time, to be better than the alternative. Now -friends essentially proposes to adopt both approaches. ISTM that is the worst of all possible worlds. Its double the work for those who want to support both, and it presents interop problems for those who don't support both. And its just two solutions to the same problem - there is almost no benefit to having both over having one. IMO there needs to be a *choice* among alternative approaches. (They pay us the big bucks to make hard choices.) Potentially we could make such a choice, if we had two proposals of comparable completeness to choose among. For that I think we would need another draft, that fleshes out the "domain federation" approach. (Maybe -shaken or another of Hadriel's early drafts on the subject could be a starting point.) Just pointing to an ETSI document isn't enough. Some tricky things that have come up along the way with -gin would also need to be dealt with in this alternative. Among them is GRUU, especially temporary GRUUs. Something similar to what Adam has proposed for -gin is probably needed to address the same issues. Also, some issues unique to this approach need to be addressed. Specifically, how does the registered contact that becomes a Route header interact with - existing Route headers in the incoming request? - Path headers that were registered? There may also be issues with routing spirals when using GRUUs. This was a knotty problem in IMS. (I wrote some text regarding that which may or may not have made it into 24.229.) (To be fair, this issue may also exist with -gin, so it will need to be investigated/solved either way.) I liked Jonathan's original proposal to switch registration routing to use Route headers. I could be happy with a Martini approach that went in that direction if it deals with all the loose ends. So to the authors of -friends (and their friends) I suggest that if you want to see a martini solution that uses the "domain federation" approach, please submit a draft that spells out all the details needed to define that. Thanks, Paul From christer.holmberg@ericsson.com Fri Jun 18 05:50:25 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 3D1C93A6A3F for ; Fri, 18 Jun 2010 05:50:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.698 X-Spam-Level: X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[AWL=-0.958, BAYES_20=-0.74] 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 kiPGjp0coUNe for ; Fri, 18 Jun 2010 05:50:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id B6BFD3A67F6 for ; Fri, 18 Jun 2010 05:50:23 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-4c-4c1b6b93654b Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id B8.2E.06817.39B6B1C4; Fri, 18 Jun 2010 14:50:27 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.84]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Fri, 18 Jun 2010 14:50:27 +0200 From: Christer Holmberg To: Laura Liess , "martini@ietf.org" Date: Fri, 18 Jun 2010 14:50:25 +0200 Thread-Topic: [martini] draft-vanelburg-martini-friends-00 Thread-Index: AcsO35PnfT1Y2qErTPaWG3+qcMDDmAABKySg Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] draft-vanelburg-martini-friends-00 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: Fri, 18 Jun 2010 12:50:25 -0000 Hi, I agree with Laura and others. Also, let's keep in mind that the possibility of having two solutions has b= een on the table for a long time. Many people did not agree to the restrict= ions (e.g related to numbering) that were suggested for GIN, and it was sug= gested that we first do GIN, since there was a time issue, and then work on= a solution that do not have the same restrictions. Ie the idea was not to close MARTINI after GIN is done. Regards, Christer =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Laura Liess > Sent: 18. kes=E4kuuta 2010 15:13 > To: martini@ietf.org > Subject: Re: [martini] draft-vanelburg-martini-friends-00 >=20 > +1 >=20 > I agree with Paul. Having two completly different "standards"=20 > is not a good choice. In the end everybody will need to=20 > implement both, whatever the intention now. >=20 > Laura >=20 >=20 >=20 >=20 > From: Paul Kyzivat > To: "martini at ietf.org" > Date: Wed, 16 Jun 2010 19:35:23 -0400 > List-id: Discussion of en-mass SIP PBX registration=20 > mechanisms >=20 > -------------------------------------------------------------- > ------------------ > Somehow I missed this draft before, but following the interim=20 > meeting today I read it. >=20 >=20 > IIUC this proposal is similar to the original "shaken"=20 > proposal (I think that was the one) to use the Contact-URI=20 > from REGISTER as a Route header rather than using it to=20 > rewrite the R-URI (which was adapted for martini by the gin draft). >=20 >=20 > There were pros and cons to both of those proposals. IMO we=20 > eventually decided to pursue -gin because its balance of pros=20 > to cons was thought, at the time, to be better than the alternative. >=20 >=20 > Now -friends essentially proposes to adopt both approaches.=20 > ISTM that is the worst of all possible worlds. Its double the=20 > work for those who want to support both, and it presents=20 > interop problems for those who don't support both. And its=20 > just two solutions to the same problem - there is almost no=20 > benefit to having both over having one. >=20 >=20 > IMO there needs to be a *choice* among alternative=20 > approaches. (They pay us the big bucks to make hard choices.)=20 > Potentially we could make such a choice, if we had two=20 > proposals of comparable completeness to choose among. For=20 > that I think we would need another draft, that fleshes out=20 > the "domain federation" approach. (Maybe -shaken or another=20 > of Hadriel's early drafts on the subject could be a starting > point.) Just pointing to an ETSI document isn't enough. >=20 >=20 > Some tricky things that have come up along the way with -gin=20 > would also need to be dealt with in this alternative. Among=20 > them is GRUU, especially temporary GRUUs. Something similar=20 > to what Adam has proposed for -gin is probably needed to=20 > address the same issues. >=20 >=20 > Also, some issues unique to this approach need to be addressed. > Specifically, how does the registered contact that becomes a=20 > Route header interact with > - existing Route headers in the incoming request? > - Path headers that were registered? >=20 >=20 > There may also be issues with routing spirals when using=20 > GRUUs. This was a knotty problem in IMS. (I wrote some text=20 > regarding that which may or may not have made it into=20 > 24.229.) (To be fair, this issue may also exist with -gin, so=20 > it will need to be investigated/solved either > way.) >=20 >=20 > I liked Jonathan's original proposal to switch registration=20 > routing to use Route headers. I could be happy with a Martini=20 > approach that went in that direction if it deals with all the=20 > loose ends. >=20 >=20 > So to the authors of -friends (and their friends) I suggest=20 > that if you want to see a martini solution that uses the=20 > "domain federation" > approach, please submit a draft that spells out all the=20 > details needed to define that. >=20 > Thanks, > Paul > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From bruno.chatras@orange-ftgroup.com Fri Jun 18 07:55:22 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 3C2523A699A for ; Fri, 18 Jun 2010 07:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-1] 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 6eClDlRoUaWb for ; Fri, 18 Jun 2010 07:55:21 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id F2F193A683E for ; Fri, 18 Jun 2010 07:55:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7EA278B800E; Fri, 18 Jun 2010 16:55:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 7766D8B800D; Fri, 18 Jun 2010 16:55:45 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jun 2010 16:54:51 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 18 Jun 2010 16:54:52 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421410195959A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-vanelburg-martini-friends-00 Thread-Index: AcsO36XVYKA0kTubRs67jYt0ikBCVgAA4Zyg References: From: To: , X-OriginalArrivalTime: 18 Jun 2010 14:54:51.0997 (UTC) FILETIME=[34C090D0:01CB0EF6] Subject: Re: [martini] draft-vanelburg-martini-friends-00 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: Fri, 18 Jun 2010 14:55:22 -0000 These are not two COMPLETELY different "standards", just two modes of = operation: basic (current gin) and federated (friends)bulk contact = routing. The difference between the two modes is only on the contents of = the Request-URI (i.e. whether it is rewritten or not by the SSP). A PBX = is not required to support both. The value(s) of the bulk contact = parameter will tell to the SSP which mode(s) it supports. BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Laura Liess > Envoy=E9 : vendredi 18 juin 2010 14:13 > =C0 : martini@ietf.org > Objet : Re: [martini] draft-vanelburg-martini-friends-00 >=20 > +1 >=20 > I agree with Paul. Having two completly different "standards"=20 > is not a good choice. In the end everybody will need to=20 > implement both, whatever the intention now. >=20 > Laura >=20 >=20 >=20 >=20 > From: Paul Kyzivat > To: "martini at ietf.org" > Date: Wed, 16 Jun 2010 19:35:23 -0400 > List-id: Discussion of en-mass SIP PBX registration=20 > mechanisms >=20 > -------------------------------------------------------------- > ------------------ > Somehow I missed this draft before, but following the interim=20 > meeting today I read it. >=20 >=20 > IIUC this proposal is similar to the original "shaken"=20 > proposal (I think that was the one) to use the Contact-URI=20 > from REGISTER as a Route header rather than using it to=20 > rewrite the R-URI (which was adapted for martini by the gin draft). >=20 >=20 > There were pros and cons to both of those proposals. IMO we=20 > eventually decided to pursue -gin because its balance of pros=20 > to cons was thought, at the time, to be better than the alternative. >=20 >=20 > Now -friends essentially proposes to adopt both approaches.=20 > ISTM that is the worst of all possible worlds. Its double the=20 > work for those who want to support both, and it presents=20 > interop problems for those who don't support both. And its=20 > just two solutions to the same problem - there is almost no=20 > benefit to having both over having one. >=20 >=20 > IMO there needs to be a *choice* among alternative=20 > approaches. (They pay us the big bucks to make hard choices.)=20 > Potentially we could make such a choice, if we had two=20 > proposals of comparable completeness to choose among. For=20 > that I think we would need another draft, that fleshes out=20 > the "domain federation" approach. (Maybe -shaken or another=20 > of Hadriel's early drafts on the subject could be a starting > point.) Just pointing to an ETSI document isn't enough. >=20 >=20 > Some tricky things that have come up along the way with -gin=20 > would also need to be dealt with in this alternative. Among=20 > them is GRUU, especially temporary GRUUs. Something similar=20 > to what Adam has proposed for -gin is probably needed to=20 > address the same issues. >=20 >=20 > Also, some issues unique to this approach need to be addressed. > Specifically, how does the registered contact that becomes a=20 > Route header interact with > - existing Route headers in the incoming request? > - Path headers that were registered? >=20 >=20 > There may also be issues with routing spirals when using=20 > GRUUs. This was a knotty problem in IMS. (I wrote some text=20 > regarding that which may or may not have made it into=20 > 24.229.) (To be fair, this issue may also exist with -gin, so=20 > it will need to be investigated/solved either > way.) >=20 >=20 > I liked Jonathan's original proposal to switch registration=20 > routing to use Route headers. I could be happy with a Martini=20 > approach that went in that direction if it deals with all the=20 > loose ends. >=20 >=20 > So to the authors of -friends (and their friends) I suggest=20 > that if you want to see a martini solution that uses the=20 > "domain federation" > approach, please submit a draft that spells out all the=20 > details needed to define that. >=20 > Thanks, > Paul > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From bruno.chatras@orange-ftgroup.com Fri Jun 18 07:55:22 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 730393A6967 for ; Fri, 18 Jun 2010 07:55:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.782 X-Spam-Level: X-Spam-Status: No, score=-0.782 tagged_above=-999 required=5 tests=[AWL=-2.467, BAYES_40=-0.185, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1, TVD_SPACE_RATIO=2.219] 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 aLhDaG15UifJ for ; Fri, 18 Jun 2010 07:55:21 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 005E93A68F9 for ; Fri, 18 Jun 2010 07:55:20 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B4E7C8B8015; Fri, 18 Jun 2010 16:55:45 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id AC2D68B8018; Fri, 18 Jun 2010 16:55:45 +0200 (CEST) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 18 Jun 2010 16:55:16 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:recallmessage MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CB0EF6.44383C6E" Date: Fri, 18 Jun 2010 16:55:17 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421410195959B@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [martini] draft-vanelburg-martini-friends-00 Thread-Index: AcsO9kQ4pI29DPO4Sbue3mZKSNq8Tw== Priority: Urgent Expiry-Date: Sun, 20 Jun 2010 16:55:15 +0200 From: To: , X-OriginalArrivalTime: 18 Jun 2010 14:55:16.0717 (UTC) FILETIME=[437C89D0:01CB0EF6] Subject: [martini] =?iso-8859-1?q?Rappel=A0=3A__draft-vanelburg-martini-fr?= =?iso-8859-1?q?iends-00?= 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: Fri, 18 Jun 2010 14:55:22 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CB0EF6.44383C6E Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable CHATRAS Bruno RD-CORE-ISS souhaite rappeler le message =AB[martini] = draft-vanelburg-martini-friends-00=BB. ------_=_NextPart_001_01CB0EF6.44383C6E Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Rappel=A0: [martini] draft-vanelburg-martini-friends-00

CHATRAS Bruno RD-CORE-ISS souhaite rappeler le message = =AB[martini] draft-vanelburg-martini-friends-00=BB.

------_=_NextPart_001_01CB0EF6.44383C6E-- From richard@shockey.us Fri Jun 18 09:09:16 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 803F03A68D8 for ; Fri, 18 Jun 2010 09:09:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.15 X-Spam-Level: X-Spam-Status: No, score=-1.15 tagged_above=-999 required=5 tests=[AWL=1.115, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 Cv-YjqJUVQsq for ; Fri, 18 Jun 2010 09:09:15 -0700 (PDT) Received: from oproxy2-pub.bluehost.com (oproxy2-pub.bluehost.com [67.222.39.60]) by core3.amsl.com (Postfix) with SMTP id 389503A68B6 for ; Fri, 18 Jun 2010 09:09:15 -0700 (PDT) Received: (qmail 29706 invoked by uid 0); 18 Jun 2010 16:09:20 -0000 Received: from unknown (HELO box462.bluehost.com) (74.220.219.62) by oproxy2.bluehost.com with SMTP; 18 Jun 2010 16:09:20 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=shockey.us; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=km/nADzmuS2P6lUAdhjDMcBYJaddU5tTqe6ERsGllz54bg4DzQ7RLQy+fgctF86ljrT9lWbp7tEEZ7jK2e4i6tOdUzOM8ORDj5DLARU5hG7YEsaMiC15GRtTOTEFZeNn; Received: from pool-96-231-199-72.washdc.fios.verizon.net ([96.231.199.72] helo=RSHOCKEYPC) by box462.bluehost.com with esmtpa (Exim 4.69) (envelope-from ) id 1OPe88-0001II-EA; Fri, 18 Jun 2010 10:09:20 -0600 From: "Richard Shockey" To: , , References: <9ECCF01B52E7AB408A7EB853526421410195959A@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB853526421410195959A@ftrdmel0.rd.francetelecom.fr> Date: Fri, 18 Jun 2010 12:09:11 -0400 Message-ID: <011201cb0f00$97a9dee0$c6fd9ca0$@us> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsO36XVYKA0kTubRs67jYt0ikBCVgAA4ZygAAdEQiA= Content-Language: en-us X-Identified-User: {3286:box462.bluehost.com:shockeyu:shockey.us} {sentby:smtp auth 96.231.199.72 authed with richard@shockey.us} Subject: Re: [martini] draft-vanelburg-martini-friends-00 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: Fri, 18 Jun 2010 16:09:16 -0000 And the customers will ultimately decide which one to use. For the X = time There are serious operational issues in the SMB markets that drove the decisions on how gin was designed. There is not one size fits all IMHO. = -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On = Behalf Of bruno.chatras@orange-ftgroup.com Sent: Friday, June 18, 2010 10:55 AM To: laura.liess.dt@googlemail.com; martini@ietf.org Subject: Re: [martini] draft-vanelburg-martini-friends-00 These are not two COMPLETELY different "standards", just two modes of operation: basic (current gin) and federated (friends)bulk contact = routing. The difference between the two modes is only on the contents of the Request-URI (i.e. whether it is rewritten or not by the SSP). A PBX is = not required to support both. The value(s) of the bulk contact parameter = will tell to the SSP which mode(s) it supports. BC > -----Message d'origine----- > De : martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] De la part de Laura Liess > Envoy=E9 : vendredi 18 juin 2010 14:13 > =C0 : martini@ietf.org > Objet : Re: [martini] draft-vanelburg-martini-friends-00 >=20 > +1 >=20 > I agree with Paul. Having two completly different "standards"=20 > is not a good choice. In the end everybody will need to=20 > implement both, whatever the intention now. >=20 > Laura >=20 >=20 >=20 >=20 > From: Paul Kyzivat > To: "martini at ietf.org" > Date: Wed, 16 Jun 2010 19:35:23 -0400 > List-id: Discussion of en-mass SIP PBX registration=20 > mechanisms >=20 > -------------------------------------------------------------- > ------------------ > Somehow I missed this draft before, but following the interim=20 > meeting today I read it. >=20 >=20 > IIUC this proposal is similar to the original "shaken"=20 > proposal (I think that was the one) to use the Contact-URI=20 > from REGISTER as a Route header rather than using it to=20 > rewrite the R-URI (which was adapted for martini by the gin draft). >=20 >=20 > There were pros and cons to both of those proposals. IMO we=20 > eventually decided to pursue -gin because its balance of pros=20 > to cons was thought, at the time, to be better than the alternative. >=20 >=20 > Now -friends essentially proposes to adopt both approaches.=20 > ISTM that is the worst of all possible worlds. Its double the=20 > work for those who want to support both, and it presents=20 > interop problems for those who don't support both. And its=20 > just two solutions to the same problem - there is almost no=20 > benefit to having both over having one. >=20 >=20 > IMO there needs to be a *choice* among alternative=20 > approaches. (They pay us the big bucks to make hard choices.)=20 > Potentially we could make such a choice, if we had two=20 > proposals of comparable completeness to choose among. For=20 > that I think we would need another draft, that fleshes out=20 > the "domain federation" approach. (Maybe -shaken or another=20 > of Hadriel's early drafts on the subject could be a starting > point.) Just pointing to an ETSI document isn't enough. >=20 >=20 > Some tricky things that have come up along the way with -gin=20 > would also need to be dealt with in this alternative. Among=20 > them is GRUU, especially temporary GRUUs. Something similar=20 > to what Adam has proposed for -gin is probably needed to=20 > address the same issues. >=20 >=20 > Also, some issues unique to this approach need to be addressed. > Specifically, how does the registered contact that becomes a=20 > Route header interact with > - existing Route headers in the incoming request? > - Path headers that were registered? >=20 >=20 > There may also be issues with routing spirals when using=20 > GRUUs. This was a knotty problem in IMS. (I wrote some text=20 > regarding that which may or may not have made it into=20 > 24.229.) (To be fair, this issue may also exist with -gin, so=20 > it will need to be investigated/solved either > way.) >=20 >=20 > I liked Jonathan's original proposal to switch registration=20 > routing to use Route headers. I could be happy with a Martini=20 > approach that went in that direction if it deals with all the=20 > loose ends. >=20 >=20 > So to the authors of -friends (and their friends) I suggest=20 > that if you want to see a martini solution that uses the=20 > "domain federation" > approach, please submit a draft that spells out all the=20 > details needed to define that. >=20 > Thanks, > Paul > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From adam@nostrum.com Fri Jun 18 15:49:14 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 5FF683A6972 for ; Fri, 18 Jun 2010 15:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001] 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 ofefSXh7Opwq for ; Fri, 18 Jun 2010 15:49:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 398903A69E6 for ; Fri, 18 Jun 2010 15:49:12 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5IMnGue071841 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 18 Jun 2010 17:49:17 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C1BF7EC.7000000@nostrum.com> Date: Fri, 18 Jun 2010 17:49:16 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "Elwell, John" References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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: Fri, 18 Jun 2010 22:49:14 -0000 On 6/18/10 5:28 AM, Elwell, John wrote: > Changes look good in general. I noticed the following in 5.3: > > "An SSP registrar that > receives such a URI MAY discard the "user" parameter and process the > request as if the parameter were not present. Alternately, it MAY > return a 400 (Bad Request) error in response. > > Note that this requirement is talking about the user parameter of > a URI:" > > 1. Instead of two "MAY"s, would it be better to have a "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not. > I kind of did, but really only for one set of circumstances -- I didn't want to disallow other valid error codes (e.g., 5xx codes) in this circumstance. But I can make that explicit: An SSP registrar that receives a "bnc" URI with a "user" parameter MUST either discard the "user" parameter and process the request as if the parameter were not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). > 2. In the note, what exactly does "this requirement" apply to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we might need to say "these requirements". Depending on the resolution of 1, I think the note could do with some clarification. > Yes, the note was written prior to some expansion of that paragraph. I've revised it to read: Note that the preceding paragraph is talking about the "user" parameter of a URI: sip:+12145550100@example.com;user=phone ^^^^^^^^^^ There was some similar text in 5.2 (regarding user portions) that I'm updating in a congruent fashion. /a From adam@estacado.net Fri Jun 18 16:02:48 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 650D028B56A for ; Fri, 18 Jun 2010 16:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] 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 bNlmRkrGitw1 for ; Fri, 18 Jun 2010 16:02:47 -0700 (PDT) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id 1C6EA3A6A74 for ; Fri, 18 Jun 2010 16:02:46 -0700 (PDT) Received: from dn3-228.estacado.net (dn3-228.estacado.net [172.16.3.228]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id o5IN2ocX058825 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 18 Jun 2010 18:02:51 -0500 (CDT) (envelope-from adam@estacado.net) Message-ID: <4C1BFB1A.6080305@estacado.net> Date: Fri, 18 Jun 2010 18:02:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "martini@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [martini] GIN: 'reg' event package proposal 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: Fri, 18 Jun 2010 23:02:48 -0000 After giving things some thought and reading through the 'reg' event package RFC, I think things will only really work if the SIP-PBX puts the public (i.e. SSP) AOR into the registration document. I propose the following text (which will appear in the next version of GIN unless there is a constructive counter-proposal): When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then the resulting registration information documents SHOULD contain an 'aor' attribute in its element that corresponds to the AOR at the SSP. For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com" The SIP-PBX used a contact of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request-URI of "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP-PBX, with a Request-URI of "sip:+12145550102@198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a element with an "aor" attribute of "sip:+12145550102@ssp.example.com". This behavior ensures that subscribers external to the system (and unaware of GIN procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly-visible AOR, not the address used for sending information from the SSP to the SIP-PBX). Also, based on Paul's comments during Interim V regarding the potential ability for SSPs to form back-end subscriptions to SIP-PBXes for registration state, I propose loosening up the normative requirement about passing through reg event SUBSCRIBEs; everything after the word "unless" is new: If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). Again, this text will appear in the next version of GIN unless there is a constructive counter-proposal. /a From trac@tools.ietf.org Sun Jun 20 11:28: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 23B8F3A695E for ; Sun, 20 Jun 2010 11:28:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.066 X-Spam-Level: X-Spam-Status: No, score=-101.066 tagged_above=-999 required=5 tests=[AWL=-1.066, BAYES_50=0.001, NO_RELAYS=-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 lnL9O49+RDzh for ; Sun, 20 Jun 2010 11:28:41 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 269573A691F for ; Sun, 20 Jun 2010 11:28:41 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OQPGB-00034W-Gu; Sun, 20 Jun 2010 11:28:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com X-Trac-Project: martini Date: Sun, 20 Jun 2010 18:28:47 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/45 Message-ID: <076.029d6075b6c603127c4415b1da3d855a@tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #45: Section 5.3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jun 2010 18:28:42 -0000 #45: Section 5.3 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Changes look good in general. I noticed the following in 5.3: "An SSP registrar that receives such a URI MAY discard the "user" parameter and process the request as if the parameter were not present. Alternately, it MAY return a 400 (Bad Request) error in response. Note that this requirement is talking about the user parameter of a URI:" 1. Instead of two "MAY"s, would it be better to have a "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not. 2. In the note, what exactly does "this requirement" apply to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we might need to say "these requirements". Depending on the resolution of 1, I think the note could do with some clarification. [Adam Roach] Changes look good in general. I noticed the following in 5.3: "An SSP registrar that receives such a URI MAY discard the "user" parameter and process the request as if the parameter were not present. Alternately, it MAY return a 400 (Bad Request) error in response. Note that this requirement is talking about the user parameter of a URI:" 1. Instead of two "MAY"s, would it be better to have a "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not. 2. In the note, what exactly does "this requirement" apply to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we might need to say "these requirements". Depending on the resolution of 1, I think the note could do with some clarification. -- Ticket URL: martini From trac@tools.ietf.org Sun Jun 20 11:29:52 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 102693A698C for ; Sun, 20 Jun 2010 11:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.357 X-Spam-Level: X-Spam-Status: No, score=-102.357 tagged_above=-999 required=5 tests=[AWL=0.243, BAYES_00=-2.599, NO_RELAYS=-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 7o2g3rIUZgWd for ; Sun, 20 Jun 2010 11:29:51 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 5BED93A691F for ; Sun, 20 Jun 2010 11:29:51 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OQPHJ-000352-2p; Sun, 20 Jun 2010 11:29:57 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: adam@nostrum.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sun, 20 Jun 2010 18:29:57 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://wiki.tools.ietf.org/wg/martini/trac/ticket/45#comment:1 Message-ID: <085.153bb3ec92a290d344efee7dbbf5d89a@tools.ietf.org> References: <076.029d6075b6c603127c4415b1da3d855a@tools.ietf.org> X-Trac-Ticket-ID: 45 In-Reply-To: <076.029d6075b6c603127c4415b1da3d855a@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: adam@nostrum.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #45: Section 5.3 X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 20 Jun 2010 18:29:52 -0000 #45: Section 5.3 ------------------------------------------------+--------------------------- Reporter: john.elwell@… | Owner: adam@… Type: defect | Status: new Priority: major | Milestone: milestone1 Component: gin | Version: 1.0 Severity: Active WG Document | Keywords: ------------------------------------------------+--------------------------- Changes (by bernard_aboba@…): * owner: => adam@… -- Ticket URL: martini From john.elwell@siemens-enterprise.com Sun Jun 20 23:24:29 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 E87C33A6A2A for ; Sun, 20 Jun 2010 23:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.348 X-Spam-Level: X-Spam-Status: No, score=-1.348 tagged_above=-999 required=5 tests=[AWL=-0.238, BAYES_05=-1.11] 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 s1dcyV5sjloV for ; Sun, 20 Jun 2010 23:24:29 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CE5D13A6807 for ; Sun, 20 Jun 2010 23:24:28 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-569858; Mon, 21 Jun 2010 08:24:34 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D625323F0278; Mon, 21 Jun 2010 08:24:34 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 21 Jun 2010 08:24:34 +0200 From: "Elwell, John" To: Adam Roach Date: Mon, 21 Jun 2010 08:24:36 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-gin-04.txt Thread-Index: AcsPOH39K8lx80iwS8WxgQ326EPyeQB0eQkA Message-ID: References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> In-Reply-To: <4C1BF7EC.7000000@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 06:24:30 -0000 Thanks, that's fine. John=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com]=20 > Sent: 18 June 2010 23:49 > To: Elwell, John > Cc: martini@ietf.org > Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >=20 > On 6/18/10 5:28 AM, Elwell, John wrote: > > Changes look good in general. I noticed the following in 5.3: > > > > "An SSP registrar that > > receives such a URI MAY discard the "user" parameter=20 > and process the > > request as if the parameter were not present. =20 > Alternately, it MAY > > return a 400 (Bad Request) error in response. > > > > Note that this requirement is talking about the user=20 > parameter of > > a URI:" > > > > 1. Instead of two "MAY"s, would it be better to have a=20 > "MUST do either ... or ..."? The present formulation allows=20 > other behaviours - I don't know whether we intend that or not. > > =20 >=20 > I kind of did, but really only for one set of circumstances=20 > -- I didn't=20 > want to disallow other valid error codes (e.g., 5xx > codes) in this circumstance. But I can make that explicit: >=20 > An SSP registrar that > receives a "bnc" URI with a "user" parameter MUST either=20 > discard the > "user" parameter and process the request as if the=20 > parameter were not > present or return a 400 (Bad Request) error in response=20 > (unless some > other error code is more appropriate). >=20 > > 2. In the note, what exactly does "this requirement" apply=20 > to? Presumably the "MUST" that came earlier, although if we=20 > do as I suggest in 1, we would end up with a second MUST, so=20 > we might need to say "these requirements". Depending on the=20 > resolution of 1, I think the note could do with some clarification. > > =20 >=20 > Yes, the note was written prior to some expansion of that paragraph.=20 > I've revised it to read: >=20 > Note that the preceding paragraph is talking about the "user" > parameter of a URI: >=20 > sip:+12145550100@example.com;user=3Dphone > ^^^^^^^^^^ >=20 > There was some similar text in 5.2 (regarding user portions) that I'm=20 > updating in a congruent fashion. >=20 > /a > = From christer.holmberg@ericsson.com Mon Jun 21 05:08:08 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 4D0D73A6A76 for ; Mon, 21 Jun 2010 05:08:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.167 X-Spam-Level: X-Spam-Status: No, score=-2.167 tagged_above=-999 required=5 tests=[AWL=-0.168, BAYES_00=-2.599, J_CHICKENPOX_45=0.6] 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 BQRksaTEyqLs for ; Mon, 21 Jun 2010 05:08:07 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 25BC03A6A4C for ; Mon, 21 Jun 2010 05:08:06 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-2a-4c1f562c5ad1 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 6B.CD.06817.C265F1C4; Mon, 21 Jun 2010 14:08:12 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.18]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 21 Jun 2010 14:08:12 +0200 From: Christer Holmberg To: "Elwell, John" , Adam Roach Date: Mon, 21 Jun 2010 14:08:11 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-gin-04.txt Thread-Index: AcsPOH39K8lx80iwS8WxgQ326EPyeQB0eQkAAAt/guA= Message-ID: References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 12:08:08 -0000 Hi, Q1. As far as I remember, RFC 3261 defines an "ip" default value for the us= er parameter, so I guess some parsers could include it by default. Q2. I pretty much know what you mean by "bnc" URI, but if you are going to = use that in the text I think you need some definition of it. Q3. 400 Bad Request is sent because of "malformed syntax". Is that really t= he case here? I think we are talking about a service error, or a unknown de= stination error, or something similar. Q4. I am a little concerned with the rejecting the message in the first pla= ce. If the SSP does this, I believe it would reject at least more or less e= very call coming from PSTN, because every MGC I am aware of does insert use= r=3Dphone in the Request-URI. Q5. One could claim (and I think Cullen did) that +123 is the same with or = without user=3Dphone. But, if the userpart contains some tel-uri parameter = the meaning is not the same. For example: +1234;param=3Dblah with user=3Dphone is *not* the same as +1234;param=3Dbla= h without user=3Dphone. I know that GIN is restricted to E.164 numbers, but is there a restriction = regarding the usage of tel-uri parameters? Regards, Christer =20 > -----Original Message----- > From: martini-bounces@ietf.org=20 > [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John > Sent: 21. kes=E4kuuta 2010 9:25 > To: Adam Roach > Cc: martini@ietf.org > Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >=20 > Thanks, that's fine. >=20 > John=20 >=20 > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: 18 June 2010 23:49 > > To: Elwell, John > > Cc: martini@ietf.org > > Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt > >=20 > > On 6/18/10 5:28 AM, Elwell, John wrote: > > > Changes look good in general. I noticed the following in 5.3: > > > > > > "An SSP registrar that > > > receives such a URI MAY discard the "user" parameter > > and process the > > > request as if the parameter were not present. =20 > > Alternately, it MAY > > > return a 400 (Bad Request) error in response. > > > > > > Note that this requirement is talking about the user > > parameter of > > > a URI:" > > > > > > 1. Instead of two "MAY"s, would it be better to have a > > "MUST do either ... or ..."? The present formulation allows other=20 > > behaviours - I don't know whether we intend that or not. > > > =20 > >=20 > > I kind of did, but really only for one set of circumstances > > -- I didn't > > want to disallow other valid error codes (e.g., 5xx > > codes) in this circumstance. But I can make that explicit: > >=20 > > An SSP registrar that > > receives a "bnc" URI with a "user" parameter MUST=20 > either discard=20 > > the > > "user" parameter and process the request as if the=20 > parameter were=20 > > not > > present or return a 400 (Bad Request) error in response (unless=20 > > some > > other error code is more appropriate). > >=20 > > > 2. In the note, what exactly does "this requirement" apply > > to? Presumably the "MUST" that came earlier, although if we do as I=20 > > suggest in 1, we would end up with a second MUST, so we=20 > might need to=20 > > say "these requirements". Depending on the resolution of 1, I think=20 > > the note could do with some clarification. > > > =20 > >=20 > > Yes, the note was written prior to some expansion of that=20 > paragraph.=20 > > I've revised it to read: > >=20 > > Note that the preceding paragraph is talking about the "user" > > parameter of a URI: > >=20 > > sip:+12145550100@example.com;user=3Dphone > > ^^^^^^^^^^ > >=20 > > There was some similar text in 5.2 (regarding user=20 > portions) that I'm=20 > > updating in a congruent fashion. > >=20 > > /a > >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > = From pkyzivat@cisco.com Mon Jun 21 06:37:50 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 D688D3A6856 for ; Mon, 21 Jun 2010 06:37:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.922 X-Spam-Level: X-Spam-Status: No, score=-9.922 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, RCVD_IN_DNSWL_HI=-8] 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 iiTG7pr9TazS for ; Mon, 21 Jun 2010 06:37:49 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 168E73A683C for ; Mon, 21 Jun 2010 06:37:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8HH0xAZnwN/2dsb2JhbACfEXGoJZoPhRsE X-IronPort-AV: E=Sophos;i="4.53,453,1272844800"; d="scan'208";a="123884779" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Jun 2010 13:37:55 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o5LDbtUC029968; Mon, 21 Jun 2010 13:37:55 GMT Message-ID: <4C1F6B33.7040506@cisco.com> Date: Mon, 21 Jun 2010 09:37:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Christer Holmberg References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 13:37:51 -0000 Christer Holmberg wrote: > Q5. One could claim (and I think Cullen did) that +123 is the same with or without user=phone. But, if the userpart contains some tel-uri parameter the meaning is not the same. For example: > > +1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone. Why? From adam@nostrum.com Mon Jun 21 08:14:34 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 19DF53A68B3 for ; Mon, 21 Jun 2010 08:14:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] 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 HycoCqS9ckQm for ; Mon, 21 Jun 2010 08:14:31 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B27533A6880 for ; Mon, 21 Jun 2010 08:14:27 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5LFEQNu012262 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 10:14:27 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C1F81D2.5080501@nostrum.com> Date: Mon, 21 Jun 2010 10:14:26 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 15:14:34 -0000 On 6/21/10 7:08 AM, Christer Holmberg wrote: > Q1. As far as I remember, RFC 3261 defines an "ip" default value for the user parameter, so I guess some parsers could include it by default. > And, if they're going to be used in a SIP-PBX that uses GIN for registration, they need to be changed. (To reiterate the arguments that started this thread in the first place: it would be questionable to include a "user" parameter on a URI that has no user portion. And these won't. So I doubt your theoretical case exists.) > Q2. I pretty much know what you mean by "bnc" URI, but if you are going to use that in the text I think you need some definition of it. > I'll add a definition. > Q3. 400 Bad Request is sent because of "malformed syntax". Is that really the case here? I think we are talking about a service error, or a unknown destination error, or something similar. > Pretty much, yes. Again, the objection that started this whole bike-shed-painting exercise was an assertion that inclusion of a "user" parameter on a SIP URI with no user portion was syntactically invalid. So I think "400" is the right way to go. > Q4. I am a little concerned with the rejecting the message in the first place. If the SSP does this, I believe it would reject at least more or less every call coming from PSTN, because every MGC I am aware of does insert user=phone in the Request-URI. > What? No. No, no, no, no, no, no, no, no, no. It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX registrations. This doesn't even slightly apply to the case you're describing. > Q5. One could claim (and I think Cullen did) that +123 is the same with or without user=phone. But, if the userpart contains some tel-uri parameter the meaning is not the same. For example: > > +1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone. > It could be. That's a site-local decision to make. "user=phone" is just as ambiguous in both cases. > > > >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John >> Sent: 21. kesäkuuta 2010 9:25 >> To: Adam Roach >> Cc: martini@ietf.org >> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >> >> Thanks, that's fine. >> >> John >> >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: 18 June 2010 23:49 >>> To: Elwell, John >>> Cc: martini@ietf.org >>> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >>> >>> On 6/18/10 5:28 AM, Elwell, John wrote: >>> >>>> Changes look good in general. I noticed the following in 5.3: >>>> >>>> "An SSP registrar that >>>> receives such a URI MAY discard the "user" parameter >>>> >>> and process the >>> >>>> request as if the parameter were not present. >>>> >>> Alternately, it MAY >>> >>>> return a 400 (Bad Request) error in response. >>>> >>>> Note that this requirement is talking about the user >>>> >>> parameter of >>> >>>> a URI:" >>>> >>>> 1. Instead of two "MAY"s, would it be better to have a >>>> >>> "MUST do either ... or ..."? The present formulation allows other >>> behaviours - I don't know whether we intend that or not. >>> >>>> >>>> >>> I kind of did, but really only for one set of circumstances >>> -- I didn't >>> want to disallow other valid error codes (e.g., 5xx >>> codes) in this circumstance. But I can make that explicit: >>> >>> An SSP registrar that >>> receives a "bnc" URI with a "user" parameter MUST >>> >> either discard >> >>> the >>> "user" parameter and process the request as if the >>> >> parameter were >> >>> not >>> present or return a 400 (Bad Request) error in response (unless >>> some >>> other error code is more appropriate). >>> >>> >>>> 2. In the note, what exactly does "this requirement" apply >>>> >>> to? Presumably the "MUST" that came earlier, although if we do as I >>> suggest in 1, we would end up with a second MUST, so we >>> >> might need to >> >>> say "these requirements". Depending on the resolution of 1, I think >>> the note could do with some clarification. >>> >>>> >>>> >>> Yes, the note was written prior to some expansion of that >>> >> paragraph. >> >>> I've revised it to read: >>> >>> Note that the preceding paragraph is talking about the "user" >>> parameter of a URI: >>> >>> sip:+12145550100@example.com;user=phone >>> ^^^^^^^^^^ >>> >>> There was some similar text in 5.2 (regarding user >>> >> portions) that I'm >> >>> updating in a congruent fashion. >>> >>> /a >>> >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >> From christer.holmberg@ericsson.com Mon Jun 21 14:28:12 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 88D643A68FB for ; Mon, 21 Jun 2010 14:28:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.843 X-Spam-Level: X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-0.444, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6] 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 l34f6kPZ-IjW for ; Mon, 21 Jun 2010 14:28:10 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0E2D23A684E for ; Mon, 21 Jun 2010 14:28:09 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-5b-4c1fd96f95c6 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id E4.EA.06817.F69DF1C4; Mon, 21 Jun 2010 23:28:15 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.18]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 21 Jun 2010 23:28:15 +0200 From: Christer Holmberg To: Adam Roach Date: Mon, 21 Jun 2010 23:28:14 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-gin-04.txt Thread-Index: AcsRVHWf/bF/8NzvT46XQ+V4mWwkNQAMbIoP Message-ID: References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> , <4C1F81D2.5080501@nostrum.com> In-Reply-To: <4C1F81D2.5080501@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 21:28:12 -0000 Hi, >>Q1. As far as I remember, RFC 3261 defines an "ip" default value for th= e user parameter, so I guess some parsers could include it by default. > > >And, if they're going to be used in a SIP-PBX that uses GIN for >registration, they need to be changed. (To reiterate the arguments that >started this thread in the first place: it would be questionable to >include a "user" parameter on a URI that has no user portion. And these >won't. So I doubt your theoretical case exists.) I am talking about the SSP procedure. Is there a spelling error in section = 5.3? >>Q3. 400 Bad Request is sent because of "malformed syntax". Is that real= ly the case here? I think we are talking about a service error, or a unknow= n destination error, or something similar. > > >Pretty much, yes. Again, the objection that started this whole >bike-shed-painting exercise was an assertion that inclusion of a "user" >parameter on a SIP URI with no user portion was syntactically invalid. >So I think "400" is the right way to go. I agree that a SIP URI with no user portion, and user=3Dphone, is invalid.= =20 But, I don't think user=3Dip is invalid. Can you show some text/ABNF which = shows that? >>Q4. I am a little concerned with the rejecting the message in the first= place. If the SSP does this, I believe it would reject at least more or le= ss every call coming from PSTN, because every MGC I am aware of does insert= user=3Dphone in the Request-URI. > > >What? > >No. > >No, no, no, no, no, no, no, no, no. > >It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX >registrations. This doesn't even slightly apply to the case you're >describing. Again, I am not talking about the SIP-PBX, but the SSP, which can get the r= equest from wherever. >>Q5. One could claim (and I think Cullen did) that +123 is the same with= or without user=3Dphone. But, if the userpart contains some tel-uri parame= ter the meaning is not the same. For example: > > +1234;param=3Dblah with user=3Dphone is *not* the same as +1234;param=3Db= lah without user=3Dphone. > >It could be. That's a site-local decision to make. "user=3Dphone" is just = as ambiguous in both cases. user=3Dphone means that the userpart shall be parsed as a tel URL. Of cours= e a site COULD decide to do that also in other cases. Regards, Christer >> -----Original Message----- >> From: martini-bounces@ietf.org >> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John >> Sent: 21. kes=E4kuuta 2010 9:25 >> To: Adam Roach >> Cc: martini@ietf.org >> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >> >> Thanks, that's fine. >> >> John >> >> >>> -----Original Message----- >>> From: Adam Roach [mailto:adam@nostrum.com] >>> Sent: 18 June 2010 23:49 >>> To: Elwell, John >>> Cc: martini@ietf.org >>> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >>> >>> On 6/18/10 5:28 AM, Elwell, John wrote: >>> >>>> Changes look good in general. I noticed the following in 5.3: >>>> >>>> "An SSP registrar that >>>> receives such a URI MAY discard the "user" parameter >>>> >>> and process the >>> >>>> request as if the parameter were not present. >>>> >>> Alternately, it MAY >>> >>>> return a 400 (Bad Request) error in response. >>>> >>>> Note that this requirement is talking about the user >>>> >>> parameter of >>> >>>> a URI:" >>>> >>>> 1. Instead of two "MAY"s, would it be better to have a >>>> >>> "MUST do either ... or ..."? The present formulation allows other >>> behaviours - I don't know whether we intend that or not. >>> >>>> >>>> >>> I kind of did, but really only for one set of circumstances >>> -- I didn't >>> want to disallow other valid error codes (e.g., 5xx >>> codes) in this circumstance. But I can make that explicit: >>> >>> An SSP registrar that >>> receives a "bnc" URI with a "user" parameter MUST >>> >> either discard >> >>> the >>> "user" parameter and process the request as if the >>> >> parameter were >> >>> not >>> present or return a 400 (Bad Request) error in response (unless >>> some >>> other error code is more appropriate). >>> >>> >>>> 2. In the note, what exactly does "this requirement" apply >>>> >>> to? Presumably the "MUST" that came earlier, although if we do as I >>> suggest in 1, we would end up with a second MUST, so we >>> >> might need to >> >>> say "these requirements". Depending on the resolution of 1, I think >>> the note could do with some clarification. >>> >>>> >>>> >>> Yes, the note was written prior to some expansion of that >>> >> paragraph. >> >>> I've revised it to read: >>> >>> Note that the preceding paragraph is talking about the "user" >>> parameter of a URI: >>> >>> sip:+12145550100@example.com;user=3Dphone >>> ^^^^^^^^^^ >>> >>> There was some similar text in 5.2 (regarding user >>> >> portions) that I'm >> >>> updating in a congruent fashion. >>> >>> /a >>> >>> >> _______________________________________________ >> martini mailing list >> martini@ietf.org >> https://www.ietf.org/mailman/listinfo/martini >>= From adam@nostrum.com Mon Jun 21 14:47:31 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 E86AA28C139 for ; Mon, 21 Jun 2010 14:47:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.94 X-Spam-Level: X-Spam-Status: No, score=-1.94 tagged_above=-999 required=5 tests=[AWL=-0.540, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6, SPF_PASS=-0.001] 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 ztD2Pui5KDdF for ; Mon, 21 Jun 2010 14:47:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B727A3A68E3 for ; Mon, 21 Jun 2010 14:47:28 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o5LLlV38047916 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jun 2010 16:47:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C1FDDF3.8000902@nostrum.com> Date: Mon, 21 Jun 2010 16:47:31 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Christer Holmberg References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> , <4C1F81D2.5080501@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030802080505020502050403" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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, 21 Jun 2010 21:47:31 -0000 This is a multi-part message in MIME format. --------------030802080505020502050403 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Christer: I think you've gotten really far off into the weeds here. Let's look at section 5.3 closely. The first paragraph talks gives you the proper scope: [T]o avoid any ambiguity in handling at the SIP-PBX, the following normative behavior is imposed on its interactions with the SSP. So, what we're talking about here is the registration process between the SIP-PBX and the SSP. Registration. Only registration. Nothing but registration. Just registration. Which is only coming from the PBX. Now, let's look at the the next sentence: When a SIP-PBX registers with an SSP using a "bnc" contact, that contact MUST NOT include a "user" parameter. That's a restriction on the PBX. During registration, the PBX is not allowed to send a "user" parameter on a Contact URI that also has a "bnc" parameter. Pretty straightforward stuff, really. An SSP registrar that receives such a URI... (that is, a URI with both "bnc" and "user" parameters) ... MUST either discard the "user" parameter and process the request as if the parameter were not present or return a 400 (Bad Request) error in response. Now, we're still in a sentence talking about getting both a "bnc" parameter (WHICH CAN ONLY HAPPEN IN A REGISTER MESSAGE FROM THE SIP-PBX) and a "user" parameter. So this restriction can only ever apply to a REGISTER message that an SSP gets from a PBX. Does that clear things up for you? /a On 6/21/10 4:28 PM, Christer Holmberg wrote: > Hi, > >>> Q1. As far as I remember, RFC 3261 defines an "ip" default value for >>> the user parameter, so I guess some parsers could include it by default. >> >> >> And, if they're going to be used in a SIP-PBX that uses GIN for >> registration, they need to be changed. (To reiterate the arguments that >> started this thread in the first place: it would be questionable to >> include a "user" parameter on a URI that has no user portion. And these >> won't. So I doubt your theoretical case exists.) > > I am talking about the SSP procedure. Is there a spelling error in > section 5.3? > > >>> Q3. 400 Bad Request is sent because of "malformed syntax". Is that >>> really the case here? I think we are talking about a service error, >>> or a unknown destination error, or something similar. >> >> >> Pretty much, yes. Again, the objection that started this whole >> bike-shed-painting exercise was an assertion that inclusion of a "user" >> parameter on a SIP URI with no user portion was syntactically invalid. >> So I think "400" is the right way to go. > > I agree that a SIP URI with no user portion, and user=phone, is invalid. > > But, I don't think user=ip is invalid. Can you show some text/ABNF > which shows that? > > >>> Q4. I am a little concerned with the rejecting the message in the >>> first place. If the SSP does this, I believe it would reject at >>> least more or less every call coming from PSTN, because every MGC I >>> am aware of does insert user=phone in the Request-URI. >> >> >> What? >> >> No. >> >> No, no, no, no, no, no, no, no, no. >> >> It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX >> registrations. This doesn't even slightly apply to the case you're >> describing. > > Again, I am not talking about the SIP-PBX, but the SSP, which can get > the request from wherever. > > >>> Q5. One could claim (and I think Cullen did) that +123 is the same >>> with or without user=phone. But, if the userpart contains some >>> tel-uri parameter the meaning is not the same. For example: >> >> +1234;param=blah with user=phone is *not* the same as >> +1234;param=blah without user=phone. >> >> It could be. That's a site-local decision to make. "user=phone" is >> just as ambiguous in both cases. > > user=phone means that the userpart shall be parsed as a tel URL. Of > course a site COULD decide to do that also in other cases. > > Regards, > > Christer > > > >>> -----Original Message----- >>> From: martini-bounces@ietf.org >>> [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John >>> Sent: 21. kesäkuuta 2010 9:25 >>> To: Adam Roach >>> Cc: martini@ietf.org >>> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >>> >>> Thanks, that's fine. >>> >>> John >>> >>> >>>> -----Original Message----- >>>> From: Adam Roach [mailto:adam@nostrum.com] >>>> Sent: 18 June 2010 23:49 >>>> To: Elwell, John >>>> Cc: martini@ietf.org >>>> Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt >>>> >>>> On 6/18/10 5:28 AM, Elwell, John wrote: >>>> >>>>> Changes look good in general. I noticed the following in 5.3: >>>>> >>>>> "An SSP registrar that >>>>> receives such a URI MAY discard the "user" parameter >>>>> >>>> and process the >>>> >>>>> request as if the parameter were not present. >>>>> >>>> Alternately, it MAY >>>> >>>>> return a 400 (Bad Request) error in response. >>>>> >>>>> Note that this requirement is talking about the user >>>>> >>>> parameter of >>>> >>>>> a URI:" >>>>> >>>>> 1. Instead of two "MAY"s, would it be better to have a >>>>> >>>> "MUST do either ... or ..."? The present formulation allows other >>>> behaviours - I don't know whether we intend that or not. >>>> >>>>> >>>>> >>>> I kind of did, but really only for one set of circumstances >>>> -- I didn't >>>> want to disallow other valid error codes (e.g., 5xx >>>> codes) in this circumstance. But I can make that explicit: >>>> >>>> An SSP registrar that >>>> receives a "bnc" URI with a "user" parameter MUST >>>> >>> either discard >>> >>>> the >>>> "user" parameter and process the request as if the >>>> >>> parameter were >>> >>>> not >>>> present or return a 400 (Bad Request) error in response (unless >>>> some >>>> other error code is more appropriate). >>>> >>>> >>>>> 2. In the note, what exactly does "this requirement" apply >>>>> >>>> to? Presumably the "MUST" that came earlier, although if we do as I >>>> suggest in 1, we would end up with a second MUST, so we >>>> >>> might need to >>> >>>> say "these requirements". Depending on the resolution of 1, I think >>>> the note could do with some clarification. >>>> >>>>> >>>>> >>>> Yes, the note was written prior to some expansion of that >>>> >>> paragraph. >>> >>>> I've revised it to read: >>>> >>>> Note that the preceding paragraph is talking about the "user" >>>> parameter of a URI: >>>> >>>> sip:+12145550100@example.com;user=phone >>>> ^^^^^^^^^^ >>>> >>>> There was some similar text in 5.2 (regarding user >>>> >>> portions) that I'm >>> >>>> updating in a congruent fashion. >>>> >>>> /a >>>> >>>> >>> _______________________________________________ >>> martini mailing list >>> martini@ietf.org >>> https://www.ietf.org/mailman/listinfo/martini >> > --------------030802080505020502050403 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Christer:

I think you've gotten really far off into the weeds here. Let's look at section 5.3 closely. The first paragraph talks gives you the proper scope:

   [T]o avoid any ambiguity in handling at the SIP-PBX, the following
   normative behavior is imposed on its interactions with the SSP.

So, what we're talking about here is the registration process between the SIP-PBX and the SSP.

Registration.

Only registration.

Nothing but registration.

Just registration.

Which is only coming from the PBX.

Now, let's look at the the next sentence:

    When a SIP-PBX registers with an SSP using a "bnc" contact, that contact MUST NOT include a "user" parameter.

That's a restriction on the PBX. During registration, the PBX is not allowed to send a "user" parameter on a Contact URI that also has a "bnc" parameter. Pretty straightforward stuff, really.

   An SSP registrar that receives such a URI...

(that is, a URI with both "bnc" and "user" parameters)

   ... MUST either discard the "user" parameter and process the request as if the
   parameter were not present or return a 400 (Bad Request) error in response.

Now, we're still in a sentence talking about getting both a "bnc" parameter (WHICH CAN ONLY HAPPEN IN A REGISTER MESSAGE FROM THE SIP-PBX) and a "user" parameter. So this restriction can only ever apply to a REGISTER message that an SSP gets from a PBX.

Does that clear things up for you?

/a


On 6/21/10 4:28 PM, Christer Holmberg wrote:
Hi,

Q1. As far as I remember, RFC 3261 defines an "ip" default value for the user parameter, so I guess some parsers could include it by default.


And, if they're going to be used in a SIP-PBX that uses GIN for
registration, they need to be changed. (To reiterate the arguments that
started this thread in the first place: it would be questionable to
include a "user" parameter on a URI that has no user portion. And these
won't. So I doubt your theoretical case exists.)

I am talking about the SSP procedure. Is there a spelling error in section 5.3?


Q3. 400 Bad Request is sent because of "malformed syntax". Is that really the case here? I think we are talking about a service error, or a unknown destination error, or something similar.


Pretty much, yes. Again, the objection that started this whole
bike-shed-painting exercise was an assertion that inclusion of a "user"
parameter on a SIP URI with no user portion was syntactically invalid.
So I think "400" is the right way to go.

I agree that a SIP URI with no user portion, and user=phone, is invalid.

But, I don't think user=ip is invalid. Can you show some text/ABNF which shows that?


Q4. I am a little concerned with the rejecting the message in the first place. If the SSP does this, I believe it would reject at least more or less every call coming from PSTN, because every MGC I am aware of does insert user=phone in the Request-URI.


What?

No.

No, no, no, no, no, no, no, no, no.

It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX
registrations. This doesn't even slightly apply to the case you're
describing.

Again, I am not talking about the SIP-PBX, but the SSP, which can get the request from wherever.


Q5. One could claim (and I think Cullen did) that +123 is the same with or without user=phone. But, if the userpart contains some tel-uri parameter the meaning is not the same. For example:

+1234;param=blah with user=phone is *not* the same as +1234;param=blah without user=phone.

It could be. That's a site-local decision to make. "user=phone" is just as ambiguous in both cases.

user=phone means that the userpart shall be parsed as a tel URL. Of course a site COULD decide to do that also in other cases.

Regards,

Christer



-----Original Message-----
From: martini-bounces@ietf.org
[mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John
Sent: 21. kesäkuuta 2010 9:25
To: Adam Roach
Cc: martini@ietf.org
Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt

Thanks, that's fine.

John


-----Original Message-----
From: Adam Roach [mailto:adam@nostrum.com]
Sent: 18 June 2010 23:49
To: Elwell, John
Cc: martini@ietf.org
Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt

On 6/18/10 5:28 AM, Elwell, John wrote:

Changes look good in general. I noticed the following in 5.3:

"An SSP registrar that
receives such a URI MAY discard the "user" parameter

and process the

request as if the parameter were not present.

Alternately, it MAY

return a 400 (Bad Request) error in response.

Note that this requirement is talking about the user

parameter of

a URI:"

1. Instead of two "MAY"s, would it be better to have a

"MUST do either ... or ..."? The present formulation allows other
behaviours - I don't know whether we intend that or not.



I kind of did, but really only for one set of circumstances
-- I didn't
want to disallow other valid error codes (e.g., 5xx
codes) in this circumstance. But I can make that explicit:

An SSP registrar that
receives a "bnc" URI with a "user" parameter MUST

either discard

the
"user" parameter and process the request as if the

parameter were

not
present or return a 400 (Bad Request) error in response (unless
some
other error code is more appropriate).


2. In the note, what exactly does "this requirement" apply

to? Presumably the "MUST" that came earlier, although if we do as I
suggest in 1, we would end up with a second MUST, so we

might need to

say "these requirements". Depending on the resolution of 1, I think
the note could do with some clarification.



Yes, the note was written prior to some expansion of that

paragraph.

I've revised it to read:

Note that the preceding paragraph is talking about the "user"
parameter of a URI:

sip:+12145550100@example.com;user=phone
^^^^^^^^^^

There was some similar text in 5.2 (regarding user

portions) that I'm

updating in a congruent fashion.

/a


_______________________________________________
martini mailing list
martini@ietf.org
https://www.ietf.org/mailman/listinfo/martini
>

--------------030802080505020502050403-- From bernard_aboba@hotmail.com Mon Jun 21 19:16:49 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 272593A692C for ; Mon, 21 Jun 2010 19:16:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.213 X-Spam-Level: X-Spam-Status: No, score=0.213 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_20=-0.74, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 bX1+eRRT7Bt8 for ; Mon, 21 Jun 2010 19:16:48 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 0D8783A691A for ; Mon, 21 Jun 2010 19:16:47 -0700 (PDT) Received: from BLU137-W3 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 21 Jun 2010 19:16:55 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_c4f6a576-29fa-44d2-b44f-f536350b8421_" X-Originating-IP: [72.11.69.66] From: Bernard Aboba To: Date: Mon, 21 Jun 2010 19:16:55 -0700 Importance: Normal In-Reply-To: <201006220148.o5M1mdgA006857@fermat.rhmr.com> References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> MIME-Version: 1.0 X-OriginalArrivalTime: 22 Jun 2010 02:16:55.0207 (UTC) FILETIME=[FC201B70:01CB11B0] Subject: [martini] FW: review of draft-ietf-martini-reqs-07.txt 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: Tue, 22 Jun 2010 02:16:49 -0000 --_c4f6a576-29fa-44d2-b44f-f536350b8421_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Date: Mon=2C 21 Jun 2010 19:48:39 -0600 > From: ho@alum.mit.edu > To: secdir@ietf.org > CC: Bernard_Aboba@hotmail.com=3B spencer@wonderhamster.org=3B gonzalo.cam= arillo@ericsson.com=3B rjsparks@nostrum.com=3B john.elwell@siemens-enterpri= se.com=3B hkaplan@acmepacket.com > Subject: review of draft-ietf-martini-reqs-07.txt >=20 > Security review of draft-ietf-martini-reqs-07.txt=2C > Multiple AOR reachability in SIP=20 >=20 > Do not be alarmed. I have reviewed this document as part of the > security directorate's ongoing effort to review all IETF documents > being processed by the IESG. These comments were written primarily > for the benefit of the security area directors. Document editors and > WG chairs should treat these comments just like any other last call > comments. >=20 > The abstract: > This document states requirements for a standardized SIP registration > mechanism for multiple addresses of record=2C the mechanism being > suitable for deployment by SIP service providers on a large scale in > support of small to medium sized Private Branch Exchanges (PBXs). > The requirements are for a solution that can=2C as a minimum=2C support > AORs based on E.164 numbers. >=20 > There are 21 requirements=2C and two of them address security. >=20 > I think requirement 14 leaves out a couple of things: > REQ14 - The mechanism MUST be able to operate over a transport that > provides integrity protection and confidentiality. > It should probably require "end-to-end" integrity protection and > confidentiality between the two entities (SIP-PBX and the SSP). >=20 > And I think requirement 15 should say something about how the two > entites are expected to agree on an authentication method=2C and that > the authentication should apply to every registration message > exchanged by the entities. That is=2C once they have authenticated=2C > then that information should be tied to requirement 14 and ensure that > the integrity and/or confidentiality is defined between the two > entities (by use of=2C for example=2C an authenticated key exchange > protocol) on all subsequent messages between the two. =20 > REQ15 - The mechanism MUST support authentication of the SIP-PBX by > the SSP and vice versa. > I'd also add that it MUST support termination of authenticaton and > re-authentication. >=20 > Minor non-security things: >=20 > Requirement 4 has a triple negative ("not" "prevent" "without")=2C and > I'm not sure what the heck it means. >=20 > Requirement 5 has a typo=2C probably "internally" for "internal". >=20 > Hilarie = --_c4f6a576-29fa-44d2-b44f-f536350b8421_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

>=3B Date: Mon=2C 21 Jun 2010 19:48:39 -0600
>=3B From: ho@a= lum.mit.edu
>=3B To: secdir@ietf.org
>=3B CC: Bernard_Aboba@hotma= il.com=3B spencer@wonderhamster.org=3B gonzalo.camarillo@ericsson.com=3B rj= sparks@nostrum.com=3B john.elwell@siemens-enterprise.com=3B hkaplan@acmepac= ket.com
>=3B Subject: review of draft-ietf-martini-reqs-07.txt
>= =3B
>=3B Security review of draft-ietf-martini-reqs-07.txt=2C
>= =3B Multiple AOR reachability in SIP
>=3B
>=3B Do not be alarme= d. I have reviewed this document as part of the
>=3B security directo= rate's ongoing effort to review all IETF documents
>=3B being processe= d by the IESG. These comments were written primarily
>=3B for the ben= efit of the security area directors. Document editors and
>=3B WG cha= irs should treat these comments just like any other last call
>=3B com= ments.
>=3B
>=3B The abstract:
>=3B This document states r= equirements for a standardized SIP registration
>=3B mechanism for mu= ltiple addresses of record=2C the mechanism being
>=3B suitable for d= eployment by SIP service providers on a large scale in
>=3B support o= f small to medium sized Private Branch Exchanges (PBXs).
>=3B The req= uirements are for a solution that can=2C as a minimum=2C support
>=3B = AORs based on E.164 numbers.
>=3B
>=3B There are 21 requirement= s=2C and two of them address security.
>=3B
>=3B I think require= ment 14 leaves out a couple of things:
>=3B REQ14 - The mechanism MU= ST be able to operate over a transport that
>=3B provides integrity = protection and confidentiality.
>=3B It should probably require "end-t= o-end" integrity protection and
>=3B confidentiality between the two e= ntities (SIP-PBX and the SSP).
>=3B
>=3B And I think requirement= 15 should say something about how the two
>=3B entites are expected t= o agree on an authentication method=2C and that
>=3B the authenticatio= n should apply to every registration message
>=3B exchanged by the ent= ities. That is=2C once they have authenticated=2C
>=3B then that info= rmation should be tied to requirement 14 and ensure that
>=3B the inte= grity and/or confidentiality is defined between the two
>=3B entities = (by use of=2C for example=2C an authenticated key exchange
>=3B protoc= ol) on all subsequent messages between the two.
>=3B REQ15 - The = mechanism MUST support authentication of the SIP-PBX by
>=3B the SS= P and vice versa.
>=3B I'd also add that it MUST support termination o= f authenticaton and
>=3B re-authentication.
>=3B
>=3B Minor= non-security things:
>=3B
>=3B Requirement 4 has a triple negat= ive ("not" "prevent" "without")=2C and
>=3B I'm not sure what the heck= it means.
>=3B
>=3B Requirement 5 has a typo=2C probably "inter= nally" for "internal".
>=3B
>=3B Hilarie
= --_c4f6a576-29fa-44d2-b44f-f536350b8421_-- From christer.holmberg@ericsson.com Mon Jun 21 22:30:41 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 C717D3A6876 for ; Mon, 21 Jun 2010 22:30:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=-0.389, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_45=0.6] 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 mL2OgQQeXYEl for ; Mon, 21 Jun 2010 22:30:36 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 32A003A63CB for ; Mon, 21 Jun 2010 22:30:35 -0700 (PDT) X-AuditID: c1b4fb39-b7b80ae000001aa1-b7-4c204a818b2a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 39.FA.06817.18A402C4; Tue, 22 Jun 2010 07:30:42 +0200 (CEST) Received: from ESESSCMS0354.eemea.ericsson.se ([169.254.2.18]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Tue, 22 Jun 2010 07:30:41 +0200 From: Christer Holmberg To: Adam Roach Date: Tue, 22 Jun 2010 07:30:41 +0200 Thread-Topic: [martini] I-D Action:draft-ietf-martini-gin-04.txt Thread-Index: AcsRi1v22nVvigEETi2CED7PoPuEYwAP3Eig Message-ID: References: <20100617230001.7BCAB3A6B2F@core3.amsl.com> <4C1BF7EC.7000000@nostrum.com> , <4C1F81D2.5080501@nostrum.com> <4C1FDDF3.8000902@nostrum.com> In-Reply-To: <4C1FDDF3.8000902@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt 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: Tue, 22 Jun 2010 05:30:42 -0000 Hi Adam, Ok, if this only applies to the registration it clear things up. To make it a little more clear, maybe you could talk say "that receives suc= h contact", instead of "SIP URI". "An SSP registrar that receives a REGISTER request with such a contact MAY = discard the "user" parameter and process the request as if the parameter we= re not present." Regards, Christer =20 ________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: 22. kes=E4kuuta 2010 0:48 To: Christer Holmberg Cc: Elwell, John; martini@ietf.org Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt =09 =09 Christer: =09 I think you've gotten really far off into the weeds here. Let's look at se= ction 5.3 closely. The first paragraph talks gives you the proper scope: =09 [T]o avoid any ambiguity in handling at the SIP-PBX, the following normative behavior is imposed on its interactions with the SSP. =09 So, what we're talking about here is the registration process between the = SIP-PBX and the SSP.=20 =09 Registration. =09 Only registration. =09 Nothing but registration. =09 Just registration. =09 Which is only coming from the PBX. =09 Now, let's look at the the next sentence: =09 When a SIP-PBX registers with an SSP using a "bnc" contact, that conta= ct MUST NOT include a "user" parameter. =09 That's a restriction on the PBX. During registration, the PBX is not allow= ed to send a "user" parameter on a Contact URI that also has a "bnc" parame= ter. Pretty straightforward stuff, really. =09 An SSP registrar that receives such a URI... =09 (that is, a URI with both "bnc" and "user" parameters) =09 ... MUST either discard the "user" parameter and process the request as= if the parameter were not present or return a 400 (Bad Request) error in respo= nse. =09 Now, we're still in a sentence talking about getting both a "bnc" paramete= r (WHICH CAN ONLY HAPPEN IN A REGISTER MESSAGE FROM THE SIP-PBX) and a "use= r" parameter. So this restriction can only ever apply to a REGISTER message= that an SSP gets from a PBX. =09 Does that clear things up for you? =09 /a =09 =09 On 6/21/10 4:28 PM, Christer Holmberg wrote:=20 Hi, =09 =09 Q1. As far as I remember, RFC 3261 defines an "ip" default value for th= e user parameter, so I guess some parsers could include it by default. =09 And, if they're going to be used in a SIP-PBX that uses GIN for registration, they need to be changed. (To reiterate the arguments that started this thread in the first place: it would be questionable to include a "user" parameter on a URI that has no user portion. And these won't. So I doubt your theoretical case exists.) =09 I am talking about the SSP procedure. Is there a spelling error in sectio= n 5.3? =09 =09 =09 Q3. 400 Bad Request is sent because of "malformed syntax". Is that real= ly the case here? I think we are talking about a service error, or a unknow= n destination error, or something similar. =09 Pretty much, yes. Again, the objection that started this whole bike-shed-painting exercise was an assertion that inclusion of a "user" parameter on a SIP URI with no user portion was syntactically invalid. So I think "400" is the right way to go. =09 I agree that a SIP URI with no user portion, and user=3Dphone, is invalid= .=20 =09 But, I don't think user=3Dip is invalid. Can you show some text/ABNF whic= h shows that? =09 =09 =09 Q4. I am a little concerned with the rejecting the message in the first= place. If the SSP does this, I believe it would reject at least more or le= ss every call coming from PSTN, because every MGC I am aware of does insert= user=3Dphone in the Request-URI. =09 What? =09 No. =09 No, no, no, no, no, no, no, no, no. =09 It's *not* getting requests with "bnc" on them from anywhere but SIP-PBX registrations. This doesn't even slightly apply to the case you're describing. =09 Again, I am not talking about the SIP-PBX, but the SSP, which can get the= request from wherever. =09 =09 =09 Q5. One could claim (and I think Cullen did) that +123 is the same with= or without user=3Dphone. But, if the userpart contains some tel-uri parame= ter the meaning is not the same. For example: =09 +1234;param=3Dblah with user=3Dphone is *not* the same as +1234;param=3D= blah without user=3Dphone. =09 It could be. That's a site-local decision to make. "user=3Dphone" is jus= t as ambiguous in both cases. =09 user=3Dphone means that the userpart shall be parsed as a tel URL. Of cou= rse a site COULD decide to do that also in other cases. =09 Regards, =09 Christer =09 =09 =09 =09 -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Elwell, John Sent: 21. kes=E4kuuta 2010 9:25 To: Adam Roach Cc: martini@ietf.org Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt =09 Thanks, that's fine. =09 John =09 =09 =09 -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: 18 June 2010 23:49 To: Elwell, John Cc: martini@ietf.org Subject: Re: [martini] I-D Action:draft-ietf-martini-gin-04.txt =09 On 6/18/10 5:28 AM, Elwell, John wrote: =09 =09 Changes look good in general. I noticed the following in 5.3: =09 "An SSP registrar that receives such a URI MAY discard the "user" parameter =09 =09 and process the =09 =09 request as if the parameter were not present. =09 =09 Alternately, it MAY =09 =09 return a 400 (Bad Request) error in response. =09 Note that this requirement is talking about the user =09 =09 parameter of =09 =09 a URI:" =09 1. Instead of two "MAY"s, would it be better to have a =09 =09 "MUST do either ... or ..."? The present formulation allows other behaviours - I don't know whether we intend that or not. =09 =09 I kind of did, but really only for one set of circumstances -- I didn't want to disallow other valid error codes (e.g., 5xx codes) in this circumstance. But I can make that explicit: =09 An SSP registrar that receives a "bnc" URI with a "user" parameter MUST =09 =09 either discard =09 =09 the "user" parameter and process the request as if the =09 =09 parameter were =09 =09 not present or return a 400 (Bad Request) error in response (unless some other error code is more appropriate). =09 =09 =09 2. In the note, what exactly does "this requirement" apply =09 =09 to? Presumably the "MUST" that came earlier, although if we do as I suggest in 1, we would end up with a second MUST, so we =09 =09 might need to =09 =09 say "these requirements". Depending on the resolution of 1, I think the note could do with some clarification. =09 =09 Yes, the note was written prior to some expansion of that =09 =09 paragraph. =09 =09 I've revised it to read: =09 Note that the preceding paragraph is talking about the "user" parameter of a URI: =09 sip:+12145550100@example.com;user=3Dphone ^^^^^^^^^^ =09 There was some similar text in 5.2 (regarding user =09 =09 portions) that I'm =09 =09 updating in a congruent fashion. =09 /a =09 =09 =09 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini =09 > From john.elwell@siemens-enterprise.com Tue Jun 22 00:36:51 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 052893A6452 for ; Tue, 22 Jun 2010 00:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.631 X-Spam-Level: X-Spam-Status: No, score=-0.631 tagged_above=-999 required=5 tests=[AWL=-0.859, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227] 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 avJ4BYClbVDM for ; Tue, 22 Jun 2010 00:36:50 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D329C3A6959 for ; Tue, 22 Jun 2010 00:36:49 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-586512 for martini@ietf.org; Tue, 22 Jun 2010 09:36:53 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 5D6DC23F0278 for ; Tue, 22 Jun 2010 09:36:53 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 22 Jun 2010 09:36:53 +0200 From: "Elwell, John" To: "martini@ietf.org" Date: Tue, 22 Jun 2010 09:36:51 +0200 Thread-Topic: review of draft-ietf-martini-reqs-07.txt Thread-Index: AcsRrNf3iQcBLAwuSGGCporU9M2CQwAJhl5wAAKp2RA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [martini] FW: review of draft-ietf-martini-reqs-07.txt 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: Tue, 22 Jun 2010 07:36:51 -0000 > -----Original Message----- > From: Elwell, John=20 > Sent: 22 June 2010 07:44 > To: 'Hilarie Orman'; secdir@ietf.org > Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com;=20 > hkaplan@acmepacket.com > Subject: RE: review of draft-ietf-martini-reqs-07.txt >=20 > Hilarie, >=20 > Thanks for your review. See responses below:=20 >=20 > > -----Original Message----- > > From: hilarie@purplestreak.com=20 > > [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman > > Sent: 22 June 2010 02:49 > > To: secdir@ietf.org > > Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org;=20 > > gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell,=20 > > John; hkaplan@acmepacket.com > > Subject: review of draft-ietf-martini-reqs-07.txt > >=20 > > Security review of draft-ietf-martini-reqs-07.txt, > > Multiple AOR reachability in SIP=20 > >=20 > > Do not be alarmed. I have reviewed this document as part of the > > security directorate's ongoing effort to review all IETF documents > > being processed by the IESG. These comments were written primarily > > for the benefit of the security area directors. Document=20 > editors and > > WG chairs should treat these comments just like any other last call > > comments. > >=20 > > The abstract: > > This document states requirements for a standardized SIP=20 > registration > > mechanism for multiple addresses of record, the mechanism being > > suitable for deployment by SIP service providers on a=20 > large scale in > > support of small to medium sized Private Branch Exchanges (PBXs). > > The requirements are for a solution that can, as a minimum, support > > AORs based on E.164 numbers. > >=20 > > There are 21 requirements, and two of them address security. > >=20 > > I think requirement 14 leaves out a couple of things: > > REQ14 - The mechanism MUST be able to operate over a=20 > transport that > > provides integrity protection and confidentiality. > > It should probably require "end-to-end" integrity protection and > > confidentiality between the two entities (SIP-PBX and the SSP). > [JRE] In the next version I will change it to: > "The mechanism MUST be able to operate over a transport that=20 > provides end-to-end integrity protection and confidentiality=20 > between the SIP-PBX and the SSP." >=20 > >=20 > > And I think requirement 15 should say something about how the two > > entites are expected to agree on an authentication method, and that > > the authentication should apply to every registration message > > exchanged by the entities. That is, once they have authenticated, > > then that information should be tied to requirement 14 and=20 > ensure that > > the integrity and/or confidentiality is defined between the two > > entities (by use of, for example, an authenticated key exchange > > protocol) on all subsequent messages between the two. =20 > [JRE] I am reluctant to make any changes here. We don't=20 > anticipate any new security mechanism, and indeed the=20 > solution that is moving forward in the WG allows use of TLS,=20 > which is already allowed for in SIP. For authentication it=20 > allows both TLS mutual authentication or SIP digest=20 > authentication + TLS server authentication, again, in line=20 > with what is already allowed in SIP. SIP has a wealth of=20 > material in this area, including aspects of RFC 3263 and RFC=20 > 3329. I don't think it worthwhile adding a bunch of=20 > requirements that in the end will not lead to any new=20 > mechanisms or influence use of existing mechanisms. REQ14 and=20 > REQ15 I think are sufficient pointers to needs in this area. >=20 > > REQ15 - The mechanism MUST support authentication of the=20 > SIP-PBX by > > the SSP and vice versa. > > I'd also add that it MUST support termination of authenticaton and > > re-authentication. > [JRE] I am not sure exactly what you are looking for here. Is=20 > this referring to what happens when a certificate expires,=20 > say? Again, I would doubt we really need to add anything=20 > here, since we don't anticipate new security mechanisms. >=20 > >=20 > > Minor non-security things: > >=20 > > Requirement 4 has a triple negative ("not" "prevent" "without"), and > > I'm not sure what the heck it means. > [JRE] Yes, in the next version I will change it to: > "The mechanism MUST allow UAs attached to a SIP-PBX to=20 > register with the SIP-PBX for AORs based on assigned=20 > telephone numbers, in order to receive requests targeted at=20 > those telephone numbers, without needing to involve the SSP=20 > in the registration process." >=20 > >=20 > > Requirement 5 has a typo, probably "internally" for "internal". > [JRE] It intentionally says "internally" at present - an=20 > adverb modifying the verb "handle". I am not sure how to=20 > reword it to prevent misinterpretation. >=20 > John >=20 >=20 > >=20 > > Hilarie > > = From bernard_aboba@hotmail.com Tue Jun 22 13:59: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 EB1D93A69E2 for ; Tue, 22 Jun 2010 13:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.365 X-Spam-Level: X-Spam-Status: No, score=0.365 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 zBrQbp52q747 for ; Tue, 22 Jun 2010 13:59:11 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id 1A6353A68C5 for ; Tue, 22 Jun 2010 13:59:11 -0700 (PDT) Received: from BLU137-DS6 ([65.55.111.71]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 22 Jun 2010 13:59:18 -0700 X-Originating-IP: [72.11.66.126] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Tue, 22 Jun 2010 13:59:16 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00DB_01CB1213.1AC7EE60" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsSTcbP9L/4oqrxQFSv3nyt4L0ypw== Content-Language: en-us X-OriginalArrivalTime: 22 Jun 2010 20:59:18.0675 (UTC) FILETIME=[C7F5D630:01CB124D] Subject: [martini] MARTINI Virtual Interim V minutes 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: Tue, 22 Jun 2010 20:59:12 -0000 ------=_NextPart_000_00DB_01CB1213.1AC7EE60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you took minutes for MARTINI Virtual Interim V, can you resend them to me? Thanks! ------=_NextPart_000_00DB_01CB1213.1AC7EE60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you took minutes for MARTINI Virtual Interim V, = can you resend them to me? 

 

Thanks!

------=_NextPart_000_00DB_01CB1213.1AC7EE60-- From bernard_aboba@hotmail.com Wed Jun 23 09:55:08 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 9171728C0E4 for ; Wed, 23 Jun 2010 09:55:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.675 X-Spam-Level: X-Spam-Status: No, score=0.675 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_45=0.6] 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 VIMp3S-y3uuV for ; Wed, 23 Jun 2010 09:55:06 -0700 (PDT) Received: from blu0-omc2-s6.blu0.hotmail.com (blu0-omc2-s6.blu0.hotmail.com [65.55.111.81]) by core3.amsl.com (Postfix) with ESMTP id EA8CD3A69DB for ; Wed, 23 Jun 2010 09:55:05 -0700 (PDT) Received: from BLU137-DS14 ([65.55.111.73]) by blu0-omc2-s6.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Jun 2010 09:55:13 -0700 X-Originating-IP: [72.11.69.66] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Wed, 23 Jun 2010 09:55:12 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0012_01CB12BA.2C9F1030" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcsS9NieB/OdiKBUQjuMHz6U4follg== Content-Language: en-us X-OriginalArrivalTime: 23 Jun 2010 16:55:13.0750 (UTC) FILETIME=[D9515F60:01CB12F4] Subject: [martini] Draft notes from MARTINI Interim V 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, 23 Jun 2010 16:55:08 -0000 ------=_NextPart_000_0012_01CB12BA.2C9F1030 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit If you want me to tidy them up, ask and I will do it tomorrow. I've already had a 14 hour working day. John ################################ Adam Roach Bernard Aboba Brian Lindsay Cullen Jennings begin_of_the_skype_highlighting end_of_the_skype_highlighting Ernst Horvath John Elwell Laura Liess Martien Huysmans Mary Barnes Paul Kyzivat Richard Shockey begin_of_the_skype_highlighting end_of_the_skype_highlighting Spencer Dawkins Alan Johnston Dan Romascanu Krisztian Kiss Keith Drage Peter Leis Tim Dwight David Hancock James Swan Hadriel Kaplan Martin Dolly Draft-ietf-martin-gin-03 - Adam Roach No objection to moving requirements analysis to appendix. Ticket#28 - user=phone. Can we live with autouser mechanism in 03? Cullen: PBX does nothing different if it receives user=phone - effectively should be ignored, so adding specification for this will make things better rather than worse. John: Shares Adam's opinion that just need a solution, but solution should be as simple as possible. Cullen: Similar statement. E.g., if get all numeric string or string beginning +, just ignore whether user=phone present. Keith: So rewrite RFC 3261? Cullen: Expect the unexpected - be generous in what you receive. Keith: So send whatever you like? Cullen: Yes. Adam: ???? Cullen: Send what 3261 says you should send, and accept whatever you receive (with/without user=phone). Adam: So what template is sent to SSP? Cullen: Doesn't matter. Spencer: So sending should be OK. Cullen: It doesn't matter. Adam: Cullen seems to be suggesting don't send user= in templates, and SSP sends whatever 3261 says, and PBX acceptes what it receives (with/without user=phone). Any objection? Bernard: Would we expect any objection from IESG. Adam: Should be a problem as long as we are not contradicting SIP. Keith: So 3261 says must include user=phone if expect recipient to process as telephone-subscriber string. Adam: That is really an issue with 3261 itself. Adam: No objection to proposal above, so will reflect in next draft. Keith: What about delivery through to phones behind the PBX. Adam: That is a matter for the PBX. Keith: Which entities are we writing behaviour for? Adam: Terminals not impacted and will have no knowledge that they are behind a MARTINI interface. Keith: ???? Adam: We are only specifying the PBX interface to the SSP and vice versa. Keith: PBX could be a proxy or B2BUA. What requirement are we placing the "ignore" on? Paul: This is processing request-URIs. John: And even proxies can manipulate Request-URIs Adam: ???? Keith: Be careful of terminology. Paul: ???? Adam: I think I can provide text to capture Keith's concerns and make it clear exactly to which interface procedures apply to. No further objection to the approach. Ticket #36 - reg-event handling Issue of whether to handle subscription at SSP or at PBX. Proposed way forward is for gin to mandate neither behaviour - just describe the pros and cons and leave it to other bodies such as 3GPP to define it to suit their architectures. Cullen: Sounds like an interoperability nightmare, because a subscriber won't know what it will get. Spencer: Will have different Request-URIs Adam: No, they will be the same. This is a similar situation to architectural issues already discussed with presence, i.e., whether a presence subscription is handled by a presence server or a terminal. Paul: I am more in Cullen's camp. People will want both. Cullen: Different people will want different things. Keith: If you want the local one, how do you ensure you have got the local one. Paul: Could do a second subscription if it gets the wrong one, but puts burden on client, which shouldn't know about MARTINI. Keith: Yes. Adam: That is why my initial proposal was for PBX to process subscriptions, which would normally be what the subscriber expects. Hadriel and Bernard convinced him to do differently. Bernard: Was not disagreeing with Paul. Hadriel: Doesn't understand what domain name a UA behind the PBX would register to - isn't ssp.com, so if they want events for the PBX registrar, would not be subscribing to ...@ssp.com. Paul: But other people wanting information about me would use the URI they would use to reach me. Keith: If get URI of business card and subscribe to it, would they get the information they want? Adam: Right, and if SSP replies would not get expected information like whether I can do video. Cullen: Agree with Keith that it has to be the PBX that responds. Paul: If there are other cases requiring different logic ... Martin: ???? Adam: Part of callee caps, part of registrar and in reg-event package. Martin: Doesn't see usefulness of this. Hadriel: That is not a commmon use case for reg-event package. Adam: Keith: Can understand why you might want to do it for diagnostic purposes. Cullen: Boatload of reasons for callee caps. Paul: Question was simply why callee caps is included in reg-event. For completeness. Hadriel: This is a sidetrack - what are people using reg-event for. Paul: Mostly people in same domain, UAs from same user, buddies, etc. But dangerous to make assumptions about what things are used for. Hadriel: Most people use reg-event just for ???? ???? Couldn't keep up with discussion here - largely repetitive. Keith: Not sure whether we have a need for reg-event from the MARTINI side of the PBX requiring state from the PBX. Chair: Need to take this to list. Adam: We tried this already, and we had this proposal and no comments on list. Bernard: Can we cover the points stated during this discussion in context of Adam's proposal: ????: But doesn't address Cullen's concern. Hadriel: Happy to say it must go to the PBX, as long as you have some separate means for subscribing to the SSP. Adam: That is already covered in the document - can subscribe to the PBX state as whole as seen by the SSP. Spencer: would be thrilled to stick with what is in the document. Cullen: Any objections to this? Hadriel: Question about URS that end up in reg-event document. Adam: Will need to dig into reg-event a little to clarify this. Paul: A way of federating: Adam: SSP can create back-end subscriptions and aggregate them, but a lot of work and unlikely to be implemented. Paul: We have a bunch of stuff on GRUU, but we have not talked about GRUU reg-event. Adam: What are use cases? Paul: Some 3GPP cases. Keith: Have to make sure that what we do works even when PBX registrar is not aware of MARTINI. Adam: PBX has the information, because it is the one handing out the GRUUs to the terminals. Paul: Public GRUU will be in domain of SSP anyway. Adam: Yes, and that can be send for reg-event. Paul: Will result in hairpinning of request to these GRUUs Adam: Can have local interception. Martin: What problem are we solving. PBXs know where to route traffic. Adam: Don't think there is one. Martin: We can route things today, so why is routing of GRUUs any different? Paul: But this is something different they have to route, so might break things. Paul: I go back to what Adam says - PBX allocates the GRUUs and can route accordingly. Martin: We don't want people hairpinning through us. All seem to be in agreement really! Adam: To summarise, text in -03 is what we will move forward with, but need to work out how it interacts with URIs in body or reg-event document. Keith: Going in right direction, but not sufficient. Richard: Isn't the PBX logically the correct entity? Keith: Does 03 allow subscription to SSP registrar. Adam: Yes, but only for the PBX itself, not for a single phone number behind the PBX. Keith: So need some text that clarifies the two cases. Adam: These are in separate sections, so difference should be clear enough. Keith: Would like something earlier on in an informative part of the document, e.g., section 4. Adam: 7.2 talks about this, send text if something is missing. Temp-GRUU handling. Described how asymmetric encryption scheme replaces the symmetric encryption scheme of GRUU RFC. Paul: Seem to recall some desire at time of working on GRUU to distribute the functionality more between registrar and UA, and gave up on it. Cullen: Three key people at the time had very different ideas on how to proceed. Alan: Is it the case that what might be acceptable for PBXs would have been unacceptable to terminals? Paul: But Cullen doesn't find it acceptable to PBXs either. Cullen: Issue is with transporting the key. Can easily avoid it, and doesn't object to mechanism in general. Paul: Don't have a good idea on computational load - could be a problem. Adam: Operations are exactly the same, except for SSP signing an integer, but only happens once when PBX comes on-line. Plus one is RSA rather than symmetric, but still talking the same order of magnitude. Bernard: Need to take to list. Draft-vanelburg-martini-friends-00 (Martin Dolly) Adam: So what changes are proposed to gin: ????: Just a new option tag Martin: Want to define another option tag within gin that is not the gin option tag. ???? What are semantics of new option tag? Spencer: Would it be sufficient just to point to the 3GPP/ETSI standard. Adam: Could be done as a different draft. Cullen: Can somebody give me a description of this, can somebody send a link? Keith: Was in slides for one of the early MARTINI meetings. Richard: References are in the 3GPP draft. Cullen: Want specific reference, and in fact a description of how it works in 3GPP. Martini: Can do that on the list. Speaking as AT&T, my motivation for including it in the gin draft, as opposed to a separate draft, makes me feel more comfortable. Richard: I am sold with the idea of two option tags, and only question is which draft. Martin: ???? Spencer: Both chairs are sold on two option tags, and need to work out how to make that happen. Can somebody provide some text for the IANA section? Bernard: Would it be possible for ETSI/3GPP to actually ask for the tag? Spencer: Perhaps Gonzalo could help. John: Concern that 3GPP/ETSI would be allocated an option tag without undergoing the same scrutiny that the SIP Forum proposal 6 months ago had to go through, going through several drafts and end up with gin. Cullen: I have some sympathy with AT&T, Verizon, etc., and want to know what has to be done to make it work. Martin: We enter into business agreement with enterprise, and know exactly what we will receive from them, what sort of traffic. Don't need reg-event package. Richard: As chairman of SIP Forum board, different sizes of PBX, and reg-event package deals with the <24 or <12 size. Bernard: Way forward is to get 3GPP/ETSI to make a proposal. John: Concerned about 2 solutions, when in fact the 3GPP/ETSI proposal is not 100 miles away from the original SIP Forum proposal, which was rejected by the IETF. Spencer: Need to see what our AD, Gonzalo, thinks about this, also in his capacity as 3GPP liaison officer. I hear what John says and is sympathetic, but does not want to hold up gin. Adam: But including option tag in gin draft would hold it up anyway. Keith: Should already have been done. Nothing in IETF/3GPP agreement that 3GPP has to submit an I-D. IETF should take publicly available specs. Martin: Will provide information for Cullen. Richard: Simply a tactical issue whether two RFCs or not. Spencer: Actions are 3GPP guys (Martin, Keith) to make sure we get a request to our 3GPP liaison, and see what Gonzalo as AD thinks is the right way to go. Richard: And that we get the documents to the list so we can see them. ------=_NextPart_000_0012_01CB12BA.2C9F1030 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

If you want me to tidy them up, ask and I will do = it tomorrow. I've already had a 14 hour working day.

John

################################

Adam Roach
Bernard Aboba
Brian Lindsay
Cullen Jennings = begin_of_the_skype_highlighting     end_of_the_skype_highlighting
Ernst Horvath
John Elwell
Laura Liess
Martien Huysmans
Mary Barnes
Paul Kyzivat
Richard Shockey = begin_of_the_skype_highlighting     end_of_the_skype_highlighting
Spencer Dawkins
Alan Johnston
Dan Romascanu
Krisztian Kiss
Keith Drage
Peter Leis
Tim Dwight
David Hancock
James Swan
Hadriel Kaplan
Martin Dolly

Draft-ietf-martin-gin-03 - Adam Roach
No objection to moving requirements analysis to appendix.

Ticket#28 - user=3Dphone. Can we live with autouser mechanism in 03?
Cullen: PBX does nothing different if it receives user=3Dphone - = effectively should be ignored, so adding specification for this will make things = better rather than worse.
John: Shares Adam's opinion that just need a solution, but solution = should be as simple as possible.
Cullen: Similar statement. E.g., if get all numeric string or string = beginning +, just ignore whether user=3Dphone present.
Keith: So rewrite RFC 3261?
Cullen: Expect the unexpected - be generous in what you receive.
Keith: So send whatever you like?
Cullen: Yes.
Adam: ????
Cullen: Send what 3261 says you should send, and accept whatever you = receive (with/without user=3Dphone).
Adam: So what template is sent to SSP?
Cullen: Doesn't matter.
Spencer: So sending should be OK.
Cullen: It doesn't matter.
Adam: Cullen seems to be suggesting don't send user=3D in templates, and = SSP sends whatever 3261 says, and PBX acceptes what it receives = (with/without user=3Dphone). Any objection?
Bernard: Would we expect any objection from IESG.
Adam: Should be a problem as long as we are not contradicting SIP.
Keith: So 3261 says must include user=3Dphone if expect recipient to = process as telephone-subscriber string.
Adam: That is really an issue with 3261 itself.
Adam: No objection to proposal above, so will reflect in next draft.
Keith: What about delivery through to phones behind the PBX.
Adam: That is a matter for the PBX.
Keith: Which entities are we writing behaviour for?
Adam: Terminals not impacted and will have no knowledge that they are = behind a MARTINI interface.
Keith: ????
Adam: We are only specifying the PBX interface to the SSP and vice = versa.
Keith: PBX could be a proxy or B2BUA. What requirement are we placing = the "ignore" on?
Paul: This is processing request-URIs.
John: And even proxies can manipulate Request-URIs
Adam: ????
Keith: Be careful of terminology.
Paul: ????
Adam: I think I can provide text to capture Keith's concerns and make it = clear exactly to which interface procedures apply to.
No further objection to the approach.

Ticket #36 - reg-event handling
Issue of whether to handle subscription at SSP or at PBX. Proposed way = forward is for gin to mandate neither behaviour - just describe the pros and = cons and leave it to other bodies such as 3GPP to define it to suit their = architectures.
Cullen: Sounds like an interoperability nightmare, because a subscriber = won't know what it will get.
Spencer: Will have different Request-URIs
Adam: No, they will be the same. This is a similar situation to = architectural issues already discussed with presence, i.e., whether a presence = subscription is handled by a presence server or a terminal.
Paul: I am more in Cullen's camp. People will want both.
Cullen: Different people will want different things.
Keith: If you want the local one, how do you ensure you have got the = local one.
Paul: Could do a second subscription if it gets the wrong one, but puts = burden on client, which shouldn't know about MARTINI.
Keith: Yes.
Adam: That is why my initial proposal was for PBX to process = subscriptions, which would normally be what the subscriber expects. Hadriel and Bernard convinced him to do differently.
Bernard: Was not disagreeing with Paul.
Hadriel: Doesn't understand what domain name a UA behind the PBX would = register to - isn't ssp.com, so if they want events for the PBX registrar, would = not be subscribing to ...@ssp.com.
Paul: But other people wanting information about me would use the URI = they would use to reach me.
Keith: If get URI of business card and subscribe to it, would they get = the information they want?
Adam: Right, and if SSP replies would not get expected information like = whether I can do video.
Cullen: Agree with Keith that it has to be the PBX that responds.
Paul: If there are other cases requiring different logic ...
Martin: ????
Adam: Part of callee caps, part of registrar and in reg-event = package.
Martin: Doesn't see usefulness of this.
Hadriel: That is not a commmon use case for reg-event package.
Adam:
Keith: Can understand why you might want to do it for diagnostic = purposes.
Cullen: Boatload of reasons for callee caps.
Paul: Question was simply why callee caps is included in reg-event. For completeness.
Hadriel: This is a sidetrack - what are people using reg-event for.
Paul: Mostly people in same domain, UAs from same user, buddies, etc. = But dangerous to make assumptions about what things are used for.
Hadriel: Most people use reg-event just for ????
???? Couldn't keep up with discussion here - largely repetitive.
Keith: Not sure whether we have a need for reg-event from the MARTINI = side of the PBX requiring state from the PBX.
Chair: Need to take this to list.
Adam: We tried this already, and we had this proposal and no comments on = list.
Bernard: Can we cover the points stated during this discussion in = context of Adam's proposal:
????: But doesn't address Cullen's concern.
Hadriel: Happy to say it must go to the PBX, as long as you have some = separate means for subscribing to the SSP.
Adam: That is already covered in the document - can subscribe to the PBX = state as whole as seen by the SSP.
Spencer: would be thrilled to stick with what is in the document.
Cullen: Any objections to this?
Hadriel: Question about URS that end up in reg-event document.
Adam: Will need to dig into reg-event a little to clarify this.
Paul: A way of federating:
Adam: SSP can create back-end subscriptions and aggregate them, but a = lot of work and unlikely to be implemented.
Paul: We have a bunch of stuff on GRUU, but we have not talked about = GRUU reg-event.
Adam: What are use cases?
Paul: Some 3GPP cases.
Keith: Have to make sure that what we do works even when PBX registrar = is not aware of MARTINI.
Adam: PBX has the information, because it is the one handing out the = GRUUs to the terminals.
Paul: Public GRUU will be in domain of SSP anyway.
Adam: Yes, and that can be send for reg-event.
Paul: Will result in hairpinning of request to these GRUUs
Adam: Can have local interception.
Martin: What problem are we solving. PBXs know where to route = traffic.
Adam: Don't think there is one.
Martin: We can route things today, so why is routing of GRUUs any = different?
Paul: But this is something different they have to route, so might break things.
Paul: I go back to what Adam says - PBX allocates the GRUUs and can = route accordingly.
Martin: We don't want people hairpinning through us.
All seem to be in agreement really!
Adam: To summarise, text in -03 is what we will move forward with, but = need to work out how it interacts with URIs in body or reg-event document.
Keith: Going in right direction, but not sufficient.
Richard: Isn't the PBX logically the correct entity?
Keith: Does 03 allow subscription to SSP registrar.
Adam: Yes, but only for the PBX itself, not for a single phone number = behind the PBX.
Keith: So need some text that clarifies the two cases.
Adam: These are in separate sections, so difference should be clear = enough.
Keith: Would like something earlier on in an informative part of the = document, e.g., section 4.
Adam: 7.2 talks about this, send text if something is missing.

Temp-GRUU handling. Described how asymmetric encryption scheme replaces = the symmetric encryption scheme of GRUU RFC.
Paul: Seem to recall some desire at time of working on GRUU to = distribute the functionality more between registrar and UA, and gave up on it.
Cullen: Three key people at the time had very different ideas on how to proceed.
Alan: Is it the case that what might be acceptable for PBXs would have = been unacceptable to terminals?
Paul: But Cullen doesn't find it acceptable to PBXs either.
Cullen: Issue is with transporting the key. Can easily avoid it, and = doesn't object to mechanism in general.
Paul: Don't have a good idea on computational load - could be a = problem.
Adam: Operations are exactly the same, except for SSP signing an = integer, but only happens once when PBX comes on-line. Plus one is RSA rather than symmetric, but still talking the same order of magnitude.
Bernard: Need to take to list.


Draft-vanelburg-martini-friends-00 (Martin Dolly)

Adam: So what changes are proposed to gin:
????: Just a new option tag
Martin: Want to define another option tag within gin that is not the gin = option tag.
???? What are semantics of new option tag?
Spencer: Would it be sufficient just to point to the 3GPP/ETSI = standard.
Adam: Could be done as a different draft.
Cullen: Can somebody give me a description of this, can somebody send a = link?
Keith: Was in slides for one of the early MARTINI meetings.
Richard: References are in the 3GPP draft.
Cullen: Want specific reference, and in fact a description of how it = works in 3GPP.
Martini: Can do that on the list. Speaking as AT&T, my motivation = for including it in the gin draft, as opposed to a separate draft, makes me = feel more comfortable.
Richard: I am sold with the idea of two option tags, and only question = is which draft.
Martin: ????
Spencer: Both chairs are sold on two option tags, and need to work out = how to make that happen. Can somebody provide some text for the IANA = section?
Bernard: Would it be possible for ETSI/3GPP to actually ask for the = tag?
Spencer: Perhaps Gonzalo could help.
John: Concern that 3GPP/ETSI would be allocated an option tag without undergoing the same scrutiny that the SIP Forum proposal 6 months ago = had to go through, going through several drafts and end up with gin.
Cullen: I have some sympathy with AT&T, Verizon, etc., and want to = know what has to be done to make it work.
Martin: We enter into business agreement with enterprise, and know = exactly what we will receive from them, what sort of traffic. Don't need reg-event = package.
Richard: As chairman of SIP Forum board, different sizes of PBX, and = reg-event package deals with the <24 or <12 size.
Bernard: Way forward is to get 3GPP/ETSI to make a proposal.
John: Concerned about 2 solutions, when in fact the 3GPP/ETSI proposal = is not 100 miles away from the original SIP Forum proposal, which was rejected = by the IETF.
Spencer: Need to see what our AD, Gonzalo, thinks about this, also in = his capacity as 3GPP liaison officer. I hear what John says and is = sympathetic, but does not want to hold up gin.
Adam: But including option tag in gin draft would hold it up anyway.
Keith: Should already have been done. Nothing in IETF/3GPP agreement = that 3GPP has to submit an I-D. IETF should take publicly available specs.
Martin: Will provide information for Cullen.
Richard: Simply a tactical issue whether two RFCs or not.
Spencer: Actions are 3GPP guys (Martin, Keith) to make sure we get a = request to our 3GPP liaison, and see what Gonzalo as AD thinks is the right way to = go.
Richard: And that we get the documents to the list so we can see = them.



------=_NextPart_000_0012_01CB12BA.2C9F1030-- From bernard_aboba@hotmail.com Thu Jun 24 15:20:37 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 181523A69D2 for ; Thu, 24 Jun 2010 15:20:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.362 X-Spam-Level: X-Spam-Status: No, score=0.362 tagged_above=-999 required=5 tests=[AWL=0.360, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 B5j990dS9nC5 for ; Thu, 24 Jun 2010 15:20:32 -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 B8E793A68C3 for ; Thu, 24 Jun 2010 15:20:31 -0700 (PDT) Received: from BLU137-DS9 ([65.55.111.71]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 24 Jun 2010 15:20:39 -0700 X-Originating-IP: [131.107.0.75] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Thu, 24 Jun 2010 15:20:39 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_063B_01CB13B0.CE144D80" X-Mailer: Microsoft Outlook 14.0 Thread-index: AcsT61tsPWpMMzr7TfqeCOoWClArxw== Content-Language: en-us X-OriginalArrivalTime: 24 Jun 2010 22:20:39.0599 (UTC) FILETIME=[7A0B3BF0:01CB13EB] Subject: [martini] IETF 78 MARTINI WG Agenda - Take One 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: Thu, 24 Jun 2010 22:20:37 -0000 ------=_NextPart_000_063B_01CB13B0.CE144D80 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit IETF 78 Agenda MARTINI WG Thursday, July 29, 2010 9:00 AM - 11:30 AM Jabber room: martini at jabber.ietf.org (Please join) Dial in Audioconference and WebEx details: TBD (do we need this?) Agenda 9 AM - 9:10 AM PT: Preliminaries Note Well Note Takers Jabber scribe Agenda bash Document Status Solution Updates (45 minutes) 9:10 AM - 9:55 AM, MARTINI with Globally Identifiable Numbers, Adam Roach (45 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (60 minutes) 9:55 AM - 10:25 AM, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive 10:25 AM - 10:55 AM, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth Discussion and Wrap-up (35 minutes) 10:55 AM - 11:10 AM Discussion: Participants (15 minutes) 11:10 AM - 11:20 AM Hums: WG Chairs (10 minutes) 11:20 PM - 11:30 AM Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_063B_01CB13B0.CE144D80 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

IETF 78 = Agenda

 

MARTINI WG

Thursday, July 29, 2010

 

9:00 AM - = 11:30 AM

 

Jabber room:  martini at jabber.ietf.org (Please = join)

Dial in Audioconference and = WebEx details:  TBD (do we need this?)

 

Agenda

 

9 AM - 9:10 = AM PT:  Preliminaries

 

     Note Well

     Note Takers

     Jabber = scribe

     = Agenda bash

  =    Document Status

 

=

Solution Updates (45 = minutes)

 

9:10 AM – 9:55 AM, MARTINI with Globally = Identifiable Numbers, Adam Roach (45 minutes)

http://tools.ietf.org/html/draft-ietf-martini-gin<= /o:p>

 

Individual Submissions (60 minutes)

 

9:55 AM = – 10:25 AM, Other Logical Identifier Values (OLIVE), Hadriel = Kaplan (30 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-with-ol= ive

 

10:25 AM – 10:55 AM, MARTINI Event Package for = Registration (VERMOUTH), Hadriel Kaplan (30 minutes)

http://tools.ietf.org/html/draft-kaplan-martini-vermout= h

 

Discussion and Wrap-up (35 minutes)

10:55 AM – = 11:10 AM   Discussion:  Participants (15 = minutes)

 

11:10 AM - 11:20 AM   Hums:  WG Chairs = (10 minutes)

 

11:20 PM – 11:30 AM   Next = Steps:  WG Chairs & ADs (10 = minutes)

------=_NextPart_000_063B_01CB13B0.CE144D80-- From trac@tools.ietf.org Sun Jun 27 11:40: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 9A32C3A691B for ; Sun, 27 Jun 2010 11:40:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.036 X-Spam-Level: X-Spam-Status: No, score=-101.036 tagged_above=-999 required=5 tests=[AWL=-1.263, BAYES_50=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, 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 yEbvVhl-wfis for ; Sun, 27 Jun 2010 11:40:16 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id B1A523A696E for ; Sun, 27 Jun 2010 11:40:16 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OSwmD-00073M-N3; Sun, 27 Jun 2010 11:40:21 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com, ho@alum.mit.edu X-Trac-Project: martini Date: Sun, 27 Jun 2010 18:40:21 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: https://trac.tools.ietf.org/wg/martini/trac/ticket/46 Message-ID: <057.f6f86a244cf71c330f658826f6f7debc@tools.ietf.org> X-Trac-Ticket-ID: 46 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, ho@alum.mit.edu, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: [martini] #46: Security Directorate review of draft-ietf-martini-reqs-07.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 18:40:17 -0000 #46: Security Directorate review of draft-ietf-martini-reqs-07.txt -----------------------------------+---------------------------------------- Reporter: ho@… | Owner: john.elwell@… Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: Submitted WG Document | Keywords: -----------------------------------+---------------------------------------- Do not be alarmed. I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. The abstract: This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. There are 21 requirements, and two of them address security. I think requirement 14 leaves out a couple of things: REQ14 - The mechanism MUST be able to operate over a transport that provides integrity protection and confidentiality. It should probably require "end-to-end" integrity protection and confidentiality between the two entities (SIP-PBX and the SSP). And I think requirement 15 should say something about how the two entites are expected to agree on an authentication method, and that the authentication should apply to every registration message exchanged by the entities. That is, once they have authenticated, then that information should be tied to requirement 14 and ensure that the integrity and/or confidentiality is defined between the two entities (by use of, for example, an authenticated key exchange protocol) on all subsequent messages between the two. REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa. I'd also add that it MUST support termination of authenticaton and re-authentication. Minor non-security things: Requirement 4 has a triple negative ("not" "prevent" "without"), and I'm not sure what the heck it means. Requirement 5 has a typo, probably "internally" for "internal". Hilarie -- Ticket URL: martini From trac@tools.ietf.org Sun Jun 27 11:43:21 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 F141B3A6971 for ; Sun, 27 Jun 2010 11:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.032 X-Spam-Level: X-Spam-Status: No, score=-101.032 tagged_above=-999 required=5 tests=[AWL=-1.259, BAYES_50=0.001, NO_RELAYS=-0.001, SARE_SUB_OBFU_Q1=0.227, 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 eLpBc+fD-T0X for ; Sun, 27 Jun 2010 11:43:21 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 185363A696E for ; Sun, 27 Jun 2010 11:43:21 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1OSwpG-00078s-QT; Sun, 27 Jun 2010 11:43:30 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "martini issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com X-Trac-Project: martini Date: Sun, 27 Jun 2010 18:43:30 -0000 X-URL: http://tools.ietf.org/martini/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/martini/trac/ticket/46#comment:1 Message-ID: <066.59dbf53932a2640ef2457faff8b1e98f@tools.ietf.org> References: <057.f6f86a244cf71c330f658826f6f7debc@tools.ietf.org> X-Trac-Ticket-ID: 46 In-Reply-To: <057.f6f86a244cf71c330f658826f6f7debc@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: john.elwell@siemens-enterprise.com, bernard_aboba@hotmail.com, martini@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: martini@ietf.org Subject: Re: [martini] #46: Security Directorate review of draft-ietf-martini-reqs-07.txt X-BeenThere: martini@ietf.org X-Mailman-Version: 2.1.9 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, 27 Jun 2010 18:43:22 -0000 #46: Security Directorate review of draft-ietf-martini-reqs-07.txt -----------------------------------+---------------------------------------- Reporter: ho@… | Owner: john.elwell@… Type: defect | Status: closed Priority: minor | Milestone: milestone1 Component: reqs | Version: 1.0 Severity: Submitted WG Document | Resolution: fixed Keywords: | -----------------------------------+---------------------------------------- Changes (by bernard_aboba@…): * status: new => closed * resolution: => fixed Comment: I think requirement 15 should say something about how the two entites are expected to agree on an authentication method.... [JRE] I am reluctant to make any changes here. We don't anticipate any new security mechanism, and indeed the solution that is moving forward in the WG allows use of TLS, which is already allowed for in SIP. For authentication it allows both TLS mutual authentication or SIP digest authentication + TLS server authentication, again, in line with what is already allowed in SIP. SIP has a wealth of material in this area, including aspects of RFC 3263 and RFC 3329. I don't think it worthwhile adding a bunch of requirements that in the end will not lead to any new mechanisms or influence use of existing mechanisms. REQ14 and REQ15 I think are sufficient pointers to needs in this area. REQ15 - The mechanism MUST support authentication of the SIP-PBX by the SSP and vice versa. I'd also add that it MUST support termination of authenticaton and re-authentication. [JRE] I am not sure exactly what you are looking for here. Is this referring to what happens when a certificate expires, say? Again, I would doubt we really need to add anything here, since we don't anticipate new security mechanisms. Minor non-security things: Requirement 4 has a triple negative ("not" "prevent" "without"), and I'm not sure what the heck it means. [JRE] Yes, in the next version I will change it to: "The mechanism MUST allow UAs attached to a SIP-PBX to register with the SIP-PBX for AORs based on assigned telephone numbers, in order to receive requests targeted at those telephone numbers, without needing to involve the SSP in the registration process." Requirement 5 has a typo, probably "internally" for "internal". [JRE] It intentionally says "internally" at present - an adverb modifying the verb "handle". I am not sure how to reword it to prevent misinterpretation. -- Ticket URL: martini From bernard_aboba@hotmail.com Sun Jun 27 11:44:55 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 0DD253A6952 for ; Sun, 27 Jun 2010 11:44:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.532 X-Spam-Level: X-Spam-Status: No, score=0.532 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_50=0.001, HTML_MESSAGE=0.001, SARE_SUB_OBFU_Q1=0.227] 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 xi4b4snf3qXX for ; Sun, 27 Jun 2010 11:44:53 -0700 (PDT) Received: from blu0-omc1-s33.blu0.hotmail.com (blu0-omc1-s33.blu0.hotmail.com [65.55.116.44]) by core3.amsl.com (Postfix) with ESMTP id 880E73A696A for ; Sun, 27 Jun 2010 11:44:53 -0700 (PDT) Received: from BLU137-W5 ([65.55.116.7]) by blu0-omc1-s33.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sun, 27 Jun 2010 11:45:03 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_9b3801f6-1f52-45fe-93d0-71f3feef1459_" X-Originating-IP: [24.19.160.219] From: Bernard Aboba To: , Date: Sun, 27 Jun 2010 11:45:03 -0700 Importance: Normal In-Reply-To: <4C262A09.5070008@ericsson.com> References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> , <4C262A09.5070008@ericsson.com> MIME-Version: 1.0 X-OriginalArrivalTime: 27 Jun 2010 18:45:03.0054 (UTC) FILETIME=[DA805EE0:01CB1628] Cc: martini@ietf.org, ho@alum.mit.edu, rjsparks@nostrum.com Subject: Re: [martini] review of draft-ietf-martini-reqs-07.txt 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, 27 Jun 2010 18:44:55 -0000 --_9b3801f6-1f52-45fe-93d0-71f3feef1459_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have opened Ticket #46 for this. So far=2C I believe this is the only IE= TF last call comment.=20 > Date: Sat=2C 26 Jun 2010 19:25:45 +0300 > From: Gonzalo.Camarillo@ericsson.com > To: john.elwell@siemens-enterprise.com > CC: ho@alum.mit.edu=3B secdir@ietf.org=3B Bernard_Aboba@hotmail.com=3B sp= encer@wonderhamster.org=3B rjsparks@nostrum.com=3B hkaplan@acmepacket.com > Subject: Re: review of draft-ietf-martini-reqs-07.txt >=20 > Hi John=2C >=20 > please=2C agree with Hilarie on how to address these comments and submit = a > new revision of the draft. Please=2C also include any other IETF LC > comments you have received. >=20 > I have updated the draft's state in the tracker to Revised ID Needed. >=20 > Thanks=2C >=20 > Gonzalo >=20 >=20 > On 22/06/2010 9:43 AM=2C Elwell=2C John wrote: > > Hilarie=2C > >=20 > > Thanks for your review. See responses below:=20 > >=20 > >> -----Original Message----- > >> From: hilarie@purplestreak.com=20 > >> [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman > >> Sent: 22 June 2010 02:49 > >> To: secdir@ietf.org > >> Cc: Bernard_Aboba@hotmail.com=3B spencer@wonderhamster.org=3B=20 > >> gonzalo.camarillo@ericsson.com=3B rjsparks@nostrum.com=3B Elwell=2C=20 > >> John=3B hkaplan@acmepacket.com > >> Subject: review of draft-ietf-martini-reqs-07.txt > >> > >> Security review of draft-ietf-martini-reqs-07.txt=2C > >> Multiple AOR reachability in SIP=20 > >> > >> Do not be alarmed. I have reviewed this document as part of the > >> security directorate's ongoing effort to review all IETF documents > >> being processed by the IESG. These comments were written primarily > >> for the benefit of the security area directors. Document editors and > >> WG chairs should treat these comments just like any other last call > >> comments. > >> > >> The abstract: > >> This document states requirements for a standardized SIP registration > >> mechanism for multiple addresses of record=2C the mechanism being > >> suitable for deployment by SIP service providers on a large scale in > >> support of small to medium sized Private Branch Exchanges (PBXs). > >> The requirements are for a solution that can=2C as a minimum=2C suppo= rt > >> AORs based on E.164 numbers. > >> > >> There are 21 requirements=2C and two of them address security. > >> > >> I think requirement 14 leaves out a couple of things: > >> REQ14 - The mechanism MUST be able to operate over a transport that > >> provides integrity protection and confidentiality. > >> It should probably require "end-to-end" integrity protection and > >> confidentiality between the two entities (SIP-PBX and the SSP). > > [JRE] In the next version I will change it to: > > "The mechanism MUST be able to operate over a transport that provides e= nd-to-end integrity protection and confidentiality between the SIP-PBX and = the SSP." > >=20 > >> > >> And I think requirement 15 should say something about how the two > >> entites are expected to agree on an authentication method=2C and that > >> the authentication should apply to every registration message > >> exchanged by the entities. That is=2C once they have authenticated=2C > >> then that information should be tied to requirement 14 and ensure that > >> the integrity and/or confidentiality is defined between the two > >> entities (by use of=2C for example=2C an authenticated key exchange > >> protocol) on all subsequent messages between the two. =20 > > [JRE] I am reluctant to make any changes here. We don't anticipate any = new security mechanism=2C and indeed the solution that is moving forward in= the WG allows use of TLS=2C which is already allowed for in SIP. For authe= ntication it allows both TLS mutual authentication or SIP digest authentica= tion + TLS server authentication=2C again=2C in line with what is already a= llowed in SIP. SIP has a wealth of material in this area=2C including aspec= ts of RFC 3263 and RFC 3329. I don't think it worthwhile adding a bunch of = requirements that in the end will not lead to any new mechanisms or influen= ce use of existing mechanisms. REQ14 and REQ15 I think are sufficient point= ers to needs in this area. > >=20 > >> REQ15 - The mechanism MUST support authentication of the SIP-PBX by > >> the SSP and vice versa. > >> I'd also add that it MUST support termination of authenticaton and > >> re-authentication. > > [JRE] I am not sure exactly what you are looking for here. Is this refe= rring to what happens when a certificate expires=2C say? Again=2C I would d= oubt we really need to add anything here=2C since we don't anticipate new s= ecurity mechanisms. > >=20 > >> > >> Minor non-security things: > >> > >> Requirement 4 has a triple negative ("not" "prevent" "without")=2C and > >> I'm not sure what the heck it means. > > [JRE] Yes=2C in the next version I will change it to: > > "The mechanism MUST allow UAs attached to a SIP-PBX to register with th= e SIP-PBX for AORs based on assigned telephone numbers=2C in order to recei= ve requests targeted at those telephone numbers=2C without needing to invol= ve the SSP in the registration process." > >=20 > >> > >> Requirement 5 has a typo=2C probably "internally" for "internal". > > [JRE] It intentionally says "internally" at present - an adverb modifyi= ng the verb "handle". I am not sure how to reword it to prevent misinterpre= tation. > >=20 > > John > >=20 > >=20 > >> > >> Hilarie >=20 = --_9b3801f6-1f52-45fe-93d0-71f3feef1459_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I have opened Ticket #46 for this. =3B So far=2C I believe this is the = only IETF last call comment.

>=3B Date: Sat=2C 26 Jun 2010 19:25:= 45 +0300
>=3B From: Gonzalo.Camarillo@ericsson.com
>=3B To: john.= elwell@siemens-enterprise.com
>=3B CC: ho@alum.mit.edu=3B secdir@ietf.= org=3B Bernard_Aboba@hotmail.com=3B spencer@wonderhamster.org=3B rjsparks@n= ostrum.com=3B hkaplan@acmepacket.com
>=3B Subject: Re: review of draft= -ietf-martini-reqs-07.txt
>=3B
>=3B Hi John=2C
>=3B
>= =3B please=2C agree with Hilarie on how to address these comments and submi= t a
>=3B new revision of the draft. Please=2C also include any other I= ETF LC
>=3B comments you have received.
>=3B
>=3B I have up= dated the draft's state in the tracker to Revised ID Needed.
>=3B
= >=3B Thanks=2C
>=3B
>=3B Gonzalo
>=3B
>=3B
>= =3B On 22/06/2010 9:43 AM=2C Elwell=2C John wrote:
>=3B >=3B Hilarie= =2C
>=3B >=3B
>=3B >=3B Thanks for your review. See response= s below:
>=3B >=3B
>=3B >=3B>=3B -----Original Message---= --
>=3B >=3B>=3B From: hilarie@purplestreak.com
>=3B >=3B&= gt=3B [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman
>= =3B >=3B>=3B Sent: 22 June 2010 02:49
>=3B >=3B>=3B To: secdir= @ietf.org
>=3B >=3B>=3B Cc: Bernard_Aboba@hotmail.com=3B spencer@w= onderhamster.org=3B
>=3B >=3B>=3B gonzalo.camarillo@ericsson.com= =3B rjsparks@nostrum.com=3B Elwell=2C
>=3B >=3B>=3B John=3B hkapl= an@acmepacket.com
>=3B >=3B>=3B Subject: review of draft-ietf-mart= ini-reqs-07.txt
>=3B >=3B>=3B
>=3B >=3B>=3B Security revi= ew of draft-ietf-martini-reqs-07.txt=2C
>=3B >=3B>=3B Multiple AOR= reachability in SIP
>=3B >=3B>=3B
>=3B >=3B>=3B Do not = be alarmed. I have reviewed this document as part of the
>=3B >=3B&= gt=3B security directorate's ongoing effort to review all IETF documents>=3B >=3B>=3B being processed by the IESG. These comments were writ= ten primarily
>=3B >=3B>=3B for the benefit of the security area d= irectors. Document editors and
>=3B >=3B>=3B WG chairs should tre= at these comments just like any other last call
>=3B >=3B>=3B comm= ents.
>=3B >=3B>=3B
>=3B >=3B>=3B The abstract:
>=3B= >=3B>=3B This document states requirements for a standardized SIP reg= istration
>=3B >=3B>=3B mechanism for multiple addresses of recor= d=2C the mechanism being
>=3B >=3B>=3B suitable for deployment by= SIP service providers on a large scale in
>=3B >=3B>=3B support = of small to medium sized Private Branch Exchanges (PBXs).
>=3B >=3B&= gt=3B The requirements are for a solution that can=2C as a minimum=2C supp= ort
>=3B >=3B>=3B AORs based on E.164 numbers.
>=3B >=3B&g= t=3B
>=3B >=3B>=3B There are 21 requirements=2C and two of them ad= dress security.
>=3B >=3B>=3B
>=3B >=3B>=3B I think requi= rement 14 leaves out a couple of things:
>=3B >=3B>=3B REQ14 - T= he mechanism MUST be able to operate over a transport that
>=3B >=3B= >=3B provides integrity protection and confidentiality.
>=3B >= =3B>=3B It should probably require "end-to-end" integrity protection and<= br>>=3B >=3B>=3B confidentiality between the two entities (SIP-PBX an= d the SSP).
>=3B >=3B [JRE] In the next version I will change it to:=
>=3B >=3B "The mechanism MUST be able to operate over a transport t= hat provides end-to-end integrity protection and confidentiality between th= e SIP-PBX and the SSP."
>=3B >=3B
>=3B >=3B>=3B
>=3B = >=3B>=3B And I think requirement 15 should say something about how the = two
>=3B >=3B>=3B entites are expected to agree on an authenticati= on method=2C and that
>=3B >=3B>=3B the authentication should appl= y to every registration message
>=3B >=3B>=3B exchanged by the ent= ities. That is=2C once they have authenticated=2C
>=3B >=3B>=3B t= hen that information should be tied to requirement 14 and ensure that
&g= t=3B >=3B>=3B the integrity and/or confidentiality is defined between t= he two
>=3B >=3B>=3B entities (by use of=2C for example=2C an auth= enticated key exchange
>=3B >=3B>=3B protocol) on all subsequent m= essages between the two.
>=3B >=3B [JRE] I am reluctant to make an= y changes here. We don't anticipate any new security mechanism=2C and indee= d the solution that is moving forward in the WG allows use of TLS=2C which = is already allowed for in SIP. For authentication it allows both TLS mutual= authentication or SIP digest authentication + TLS server authentication=2C= again=2C in line with what is already allowed in SIP. SIP has a wealth of = material in this area=2C including aspects of RFC 3263 and RFC 3329. I don'= t think it worthwhile adding a bunch of requirements that in the end will n= ot lead to any new mechanisms or influence use of existing mechanisms. REQ1= 4 and REQ15 I think are sufficient pointers to needs in this area.
>= =3B >=3B
>=3B >=3B>=3B REQ15 - The mechanism MUST support au= thentication of the SIP-PBX by
>=3B >=3B>=3B the SSP and vice v= ersa.
>=3B >=3B>=3B I'd also add that it MUST support termination = of authenticaton and
>=3B >=3B>=3B re-authentication.
>=3B &g= t=3B [JRE] I am not sure exactly what you are looking for here. Is this ref= erring to what happens when a certificate expires=2C say? Again=2C I would = doubt we really need to add anything here=2C since we don't anticipate new = security mechanisms.
>=3B >=3B
>=3B >=3B>=3B
>=3B >= =3B>=3B Minor non-security things:
>=3B >=3B>=3B
>=3B >= =3B>=3B Requirement 4 has a triple negative ("not" "prevent" "without")= =2C and
>=3B >=3B>=3B I'm not sure what the heck it means.
>= =3B >=3B [JRE] Yes=2C in the next version I will change it to:
>=3B = >=3B "The mechanism MUST allow UAs attached to a SIP-PBX to register with= the SIP-PBX for AORs based on assigned telephone numbers=2C in order to re= ceive requests targeted at those telephone numbers=2C without needing to in= volve the SSP in the registration process."
>=3B >=3B
>=3B >= =3B>=3B
>=3B >=3B>=3B Requirement 5 has a typo=2C probably "inte= rnally" for "internal".
>=3B >=3B [JRE] It intentionally says "inter= nally" at present - an adverb modifying the verb "handle". I am not sure ho= w to reword it to prevent misinterpretation.
>=3B >=3B
>=3B &g= t=3B John
>=3B >=3B
>=3B >=3B
>=3B >=3B>=3B
>= =3B >=3B>=3B Hilarie
>=3B
= --_9b3801f6-1f52-45fe-93d0-71f3feef1459_-- From root@core3.amsl.com Mon Jun 28 00:45:07 2010 Return-Path: X-Original-To: martini@ietf.org Delivered-To: martini@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C6EC43A67E3; Mon, 28 Jun 2010 00:45:07 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20100628074507.C6EC43A67E3@core3.amsl.com> Date: Mon, 28 Jun 2010 00:45:07 -0700 (PDT) Cc: martini@ietf.org Subject: [martini] I-D Action:draft-ietf-martini-reqs-08.txt 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, 28 Jun 2010 07:45:07 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multiple AoR reachabiliTy InformatioN Indication Working Group of the IETF. Title : Requirements for multiple address of record (AOR) reachability information in the Session Initiation Protocol (SIP) Author(s) : J. Elwell, H. Kaplan Filename : draft-ietf-martini-reqs-08.txt Pages : 12 Date : 2010-06-28 This document states requirements for a standardized SIP registration mechanism for multiple addresses of record, the mechanism being suitable for deployment by SIP service providers on a large scale in support of small to medium sized Private Branch Exchanges (PBXs). The requirements are for a solution that can, as a minimum, support AORs based on E.164 numbers. This work is being discussed on the martini@ietf.org mailing list. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-martini-reqs-08.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-martini-reqs-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-06-28003807.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Mon Jun 28 03:24: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 6204E3A68D5 for ; Mon, 28 Jun 2010 03:24:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.814 X-Spam-Level: X-Spam-Status: No, score=-101.814 tagged_above=-999 required=5 tests=[AWL=-2.042, BAYES_50=0.001, SARE_SUB_OBFU_Q1=0.227, 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 WfuvFBysoHe4 for ; Mon, 28 Jun 2010 03:24:05 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 9B8583A689E for ; Mon, 28 Jun 2010 03:24:04 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-64-4c28784dd6ef Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DA.2D.19600.D48782C4; Mon, 28 Jun 2010 12:24:13 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jun 2010 12:24:13 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 28 Jun 2010 12:24:12 +0200 Message-ID: <4C28784C.8030307@ericsson.com> Date: Mon, 28 Jun 2010 13:24:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Bernard Aboba References: <201006220148.o5M1mdgA006857@fermat.rhmr.com> , <4C262A09.5070008@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jun 2010 10:24:12.0974 (UTC) FILETIME=[0DABCCE0:01CB16AC] X-Brightmail-Tracker: AAAAAA== Cc: "rjsparks@nostrum.com" , "martini@ietf.org" , "ho@alum.mit.edu" Subject: Re: [martini] review of draft-ietf-martini-reqs-07.txt 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, 28 Jun 2010 10:24:10 -0000 Hi, thanks for addressing the IETF LC comments with the new revision of the draft. I have put it on the agenda of the IESG telechat on July 15th. Authors, please be responsive when you start receiving comments from the ADs reviewing the document. Cheers, Gonzalo On 27/06/2010 9:45 PM, Bernard Aboba wrote: > I have opened Ticket #46 for this. So far, I believe this is the only > IETF last call comment. > >> Date: Sat, 26 Jun 2010 19:25:45 +0300 >> From: Gonzalo.Camarillo@ericsson.com >> To: john.elwell@siemens-enterprise.com >> CC: ho@alum.mit.edu; secdir@ietf.org; Bernard_Aboba@hotmail.com; > spencer@wonderhamster.org; rjsparks@nostrum.com; hkaplan@acmepacket.com >> Subject: Re: review of draft-ietf-martini-reqs-07.txt >> >> Hi John, >> >> please, agree with Hilarie on how to address these comments and submit a >> new revision of the draft. Please, also include any other IETF LC >> comments you have received. >> >> I have updated the draft's state in the tracker to Revised ID Needed. >> >> Thanks, >> >> Gonzalo >> >> >> On 22/06/2010 9:43 AM, Elwell, John wrote: >> > Hilarie, >> > >> > Thanks for your review. See responses below: >> > >> >> -----Original Message----- >> >> From: hilarie@purplestreak.com >> >> [mailto:hilarie@purplestreak.com] On Behalf Of Hilarie Orman >> >> Sent: 22 June 2010 02:49 >> >> To: secdir@ietf.org >> >> Cc: Bernard_Aboba@hotmail.com; spencer@wonderhamster.org; >> >> gonzalo.camarillo@ericsson.com; rjsparks@nostrum.com; Elwell, >> >> John; hkaplan@acmepacket.com >> >> Subject: review of draft-ietf-martini-reqs-07.txt >> >> >> >> Security review of draft-ietf-martini-reqs-07.txt, >> >> Multiple AOR reachability in SIP >> >> >> >> Do not be alarmed. I have reviewed this document as part of the >> >> security directorate's ongoing effort to review all IETF documents >> >> being processed by the IESG. These comments were written primarily >> >> for the benefit of the security area directors. Document editors and >> >> WG chairs should treat these comments just like any other last call >> >> comments. >> >> >> >> The abstract: >> >> This document states requirements for a standardized SIP registration >> >> mechanism for multiple addresses of record, the mechanism being >> >> suitable for deployment by SIP service providers on a large scale in >> >> support of small to medium sized Private Branch Exchanges (PBXs). >> >> The requirements are for a solution that can, as a minimum, support >> >> AORs based on E.164 numbers. >> >> >> >> There are 21 requirements, and two of them address security. >> >> >> >> I think requirement 14 leaves out a couple of things: >> >> REQ14 - The mechanism MUST be able to operate over a transport that >> >> provides integrity protection and confidentiality. >> >> It should probably require "end-to-end" integrity protection and >> >> confidentiality between the two entities (SIP-PBX and the SSP). >> > [JRE] In the next version I will change it to: >> > "The mechanism MUST be able to operate over a transport that > provides end-to-end integrity protection and confidentiality between the > SIP-PBX and the SSP." >> > >> >> >> >> And I think requirement 15 should say something about how the two >> >> entites are expected to agree on an authentication method, and that >> >> the authentication should apply to every registration message >> >> exchanged by the entities. That is, once they have authenticated, >> >> then that information should be tied to requirement 14 and ensure that >> >> the integrity and/or confidentiality is defined between the two >> >> entities (by use of, for example, an authenticated key exchange >> >> protocol) on all subsequent messages between the two. >> > [JRE] I am reluctant to make any changes here. We don't anticipate > any new security mechanism, and indeed the solution that is moving > forward in the WG allows use of TLS, which is already allowed for in > SIP. For authentication it allows both TLS mutual authentication or SIP > digest authentication + TLS server authentication, again, in line with > what is already allowed in SIP. SIP has a wealth of material in this > area, including aspects of RFC 3263 and RFC 3329. I don't think it > worthwhile adding a bunch of requirements that in the end will not lead > to any new mechanisms or influence use of existing mechanisms. REQ14 and > REQ15 I think are sufficient pointers to needs in this area. >> > >> >> REQ15 - The mechanism MUST support authentication of the SIP-PBX by >> >> the SSP and vice versa. >> >> I'd also add that it MUST support termination of authenticaton and >> >> re-authentication. >> > [JRE] I am not sure exactly what you are looking for here. Is this > referring to what happens when a certificate expires, say? Again, I > would doubt we really need to add anything here, since we don't > anticipate new security mechanisms. >> > >> >> >> >> Minor non-security things: >> >> >> >> Requirement 4 has a triple negative ("not" "prevent" "without"), and >> >> I'm not sure what the heck it means. >> > [JRE] Yes, in the next version I will change it to: >> > "The mechanism MUST allow UAs attached to a SIP-PBX to register with > the SIP-PBX for AORs based on assigned telephone numbers, in order to > receive requests targeted at those telephone numbers, without needing to > involve the SSP in the registration process." >> > >> >> >> >> Requirement 5 has a typo, probably "internally" for "internal". >> > [JRE] It intentionally says "internally" at present - an adverb > modifying the verb "handle". I am not sure how to reword it to prevent > misinterpretation. >> > >> > John >> > >> > >> >> >> >> Hilarie >> From martien.huysmans@ericsson.com Mon Jun 28 06:03:55 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 926D83A6A36 for ; Mon, 28 Jun 2010 06:03:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_50=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 THV2qgWzuaPf for ; Mon, 28 Jun 2010 06:03:54 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D068628C138 for ; Mon, 28 Jun 2010 06:03:28 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-ea-4c289da968c3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A9.40.10125.9AD982C4; Mon, 28 Jun 2010 15:03:37 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 28 Jun 2010 15:03:37 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Mon, 28 Jun 2010 15:03:35 +0200 Thread-Topic: [martini] GIN: 'reg' event package proposal Thread-Index: AcsPOmT7shBY3JQhT/yjxSbEz+djZwHhAgaAAADy/FA= Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] FW: GIN: 'reg' event package proposal 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, 28 Jun 2010 13:03:55 -0000 Forgot to include martini@ietf.org in the To. -----Original Message----- From: Martien Huysmans=20 Sent: Monday, June 28, 2010 2:46 PM To: 'Adam Roach' Subject: RE: [martini] GIN: 'reg' event package proposal Adam Assume that the pbx has a user, say sip:user1@pbx.com with corresponding SS= P identity: sip:+12145550102@ssp.example.com. Then I guess that it's is upto the SIP-PBX to include both, if both are pub= licly-visible? Would the procedure below imply that a SIP-PBX could provide a different re= plies to a SUBSCRIBE for regvent depending on the RURI: - SUBSCRIBE sip:+12145550102@ssp.example.com as described below - SUBSCRIBE sip:user1@pbx.com with all AOR's included ? Do you see a similar rule for the Contact's included in the registration do= cument? Regards Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Saturday, June 19, 2010 1:03 AM To: martini@ietf.org Subject: [martini] GIN: 'reg' event package proposal After giving things some thought and reading through the 'reg' event packag= e RFC, I think things will only really work if the SIP-PBX puts the public = (i.e. SSP) AOR into the registration document. I propose the following text= (which will appear in the next version of GIN unless there is a constructi= ve counter-proposal): When a SIP-PBX receives a registration event subscription addressed to an AOR that has been registered using the bulk registration mechanism described in this document, then the resulting registration information documents SHOULD contain an 'aor' attribute in its element that corresponds to the AOR at the SSP. For example, consider a SIP-PBX that has registered with an SSP that has a domain of "ssp.example.com" The SIP-PBX used a contact of "sip:198.51.100.3:5060;bnc". After such registration is complete, a registration event subscription arriving at the SSP with a Request-URI of "sip:+12145550102@ssp.example.com" will be re-targeted to the SIP-PBX, with a Request-URI of "sip:+12145550102@198.51.100.3:5060". The resulting registration document created by the SIP-PBX would contain a element with an "aor" attribute of "sip:+12145550102@ssp.example.com". This behavior ensures that subscribers external to the system (and unaware of GIN procedures) will be able to find the relevant information in the registration document (since they will be looking for the publicly-visible AOR, not the address used for sending information from the SSP to the SIP-PBX). Also, based on Paul's comments during Interim V regarding the potential abi= lity for SSPs to form back-end subscriptions to SIP-PBXes for registration = state, I propose loosening up the normative requirement about passing throu= gh reg event SUBSCRIBEs; everything after the word "unless" is new: If the SSP receives a SUBSCRIBE request for the registration event package with a Request-URI that indicates a contact registered via the "Bulk Number Contact" mechanism defined in this document, then the SSP MUST proxy that SUBSCRIBE to the SIP-PBX in the same way that is would proxy an INVITE bound for that AOR, unless the SSP has and can maintain a copy of complete, accurate, and up-to-date information from the SIP-PBX (e.g., through an active back-end subscription). Again, this text will appear in the next version of GIN unless there is a c= onstructive counter-proposal. /a _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From bernard_aboba@hotmail.com Mon Jun 28 15:44:36 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 0F5FC3A6A72 for ; Mon, 28 Jun 2010 15:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.398 X-Spam-Level: X-Spam-Status: No, score=0.398 tagged_above=-999 required=5 tests=[AWL=0.396, BAYES_50=0.001, HTML_MESSAGE=0.001] 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 giqEn9caGbGv for ; Mon, 28 Jun 2010 15:44:28 -0700 (PDT) Received: from blu0-omc2-s7.blu0.hotmail.com (blu0-omc2-s7.blu0.hotmail.com [65.55.111.82]) by core3.amsl.com (Postfix) with ESMTP id A2E7B3A69C5 for ; Mon, 28 Jun 2010 15:44:25 -0700 (PDT) Received: from BLU137-DS5 ([65.55.111.72]) by blu0-omc2-s7.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Jun 2010 15:44:35 -0700 X-Originating-IP: [131.107.0.75] X-Originating-Email: [bernard_aboba@hotmail.com] Message-ID: From: "Bernard Aboba" To: Date: Mon, 28 Jun 2010 15:44:34 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001A_01CB16D8.CF166710" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AcsXE2pbKhSCtvCvTh6O0lm2SNwP4A== Content-Language: en-us X-OriginalArrivalTime: 28 Jun 2010 22:44:35.0142 (UTC) FILETIME=[7B58B660:01CB1713] Subject: [martini] IETF 78 MARTINI WG Agenda - Take Two 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, 28 Jun 2010 22:44:36 -0000 ------=_NextPart_000_001A_01CB16D8.CF166710 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit MARTINI WG IETF 78 Agenda Chairs: Bernard Aboba Spencer Dawkins Jabber room: martini at jabber.ietf.org (Please join) Thursday, July 29, 2010 09:00 - 11:30 Berin/Copenhagen Room 09:00 - 9:10, Preliminaries Note Well Note Takers Jabber scribe Agenda bash Document Status Solution Updates (60 minutes) 9:10 - 10:10, MARTINI with Globally Identifiable Numbers, Adam Roach (60 minutes) http://tools.ietf.org/html/draft-ietf-martini-gin Individual Submissions (30 minutes) 10:10 - 10:40, Other Logical Identifier Values (OLIVE), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-with-olive Discussion and Wrap-up (50 minutes) 10:40 - 11:10, Discussion: Participants (30 minutes) 11:10 - 11:20, Hums: WG Chairs (10 minutes) 11:20 - 11:30, Next Steps: WG Chairs & ADs (10 minutes) Thursday, July 29, 2010 15:10 - 16:20 Berlin/Copenhagen Room 15:10 - 15:20, Preliminaries Note Well Note Takers Jabber scribe Agenda bash Individual Submissions (30 minutes) 15:20 - 15:50, MARTINI Event Package for Registration (VERMOUTH), Hadriel Kaplan (30 minutes) http://tools.ietf.org/html/draft-kaplan-martini-vermouth Discussion and Wrap-up (30 minutes) 15:50 - 16:10, Discussion: Participants (20 minutes) 16:10 - 16:20, Next Steps: WG Chairs & ADs (10 minutes) ------=_NextPart_000_001A_01CB16D8.CF166710 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

MARTINI WG = IETF 78 Agenda

 

Chairs:

Bernard = Aboba <bernard_aboba at hotmail.com>

Spencer Dawkins <spencer at = wonderhamster.org>

 

Jabber = room:  martini at jabber.ietf.org (Please join)

 

Thursday, = July 29, 2010

09:00 - = 11:30

Berin/Copenhagen = Room

 

09:00 - 9:10, Preliminaries

 

     Note Well

     Note Takers

     Jabber = scribe

     = Agenda bash

     = Document Status

 

Solution = Updates (60 minutes)

 

9:10 – = 10:10, MARTINI with Globally Identifiable Numbers, Adam Roach (60 = minutes)

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

 

Individual = Submissions (30 minutes)

 

10:10 = – 10:40, Other Logical Identifier Values (OLIVE), Hadriel Kaplan = (30 minutes)

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

<= p class=3DMsoNormal> 

Discussion = and Wrap-up (50 minutes)

 

10:40 = – 11:10, Discussion:  Participants (30 = minutes)

11:10 - 11:20, Hums:  = WG Chairs (10 minutes)

11:20 – = 11:30, Next Steps:  WG Chairs & ADs (10 = minutes)

 

Thursday, July 29, 2010

15:10 - 16:20

Berlin/Copenhagen Room

 

15:10 - = 15:20, Preliminaries

 

     Note Well

     Note Takers

     Jabber = scribe

     = Agenda bash

 

Individual Submissions (30 minutes)

 

15:20 = – 15:50, MARTINI Event Package for Registration (VERMOUTH), = Hadriel Kaplan (30 minutes)

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

 

Discussion = and Wrap-up (30 minutes)

 

15:50 = – 16:10, Discussion:  Participants (20 = minutes)

16:10 – 16:20, Next = Steps:  WG Chairs & ADs (10 minutes)

 

 

------=_NextPart_000_001A_01CB16D8.CF166710-- From martien.huysmans@ericsson.com Wed Jun 30 04:09:25 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 698C63A695A for ; Wed, 30 Jun 2010 04:09:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.37 X-Spam-Level: X-Spam-Status: No, score=-2.37 tagged_above=-999 required=5 tests=[AWL=-1.630, BAYES_20=-0.74] 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 JRR4j9M798mu for ; Wed, 30 Jun 2010 04:09:24 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 21D863A67D9 for ; Wed, 30 Jun 2010 04:09:23 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-f3-4c2b25eea7bb Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id F8.D6.19600.EE52B2C4; Wed, 30 Jun 2010 13:09:34 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 30 Jun 2010 13:09:33 +0200 From: Martien Huysmans To: Cullen Jennings , "martini@ietf.org" Date: Wed, 30 Jun 2010 13:09:32 +0200 Thread-Topic: [martini] GIN temp GRUU Thread-Index: AcsNdYq1sh7EV9d9RS28pvNy0H6ZYAKzgy2Q Message-ID: References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> In-Reply-To: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: Re: [martini] GIN temp GRUU 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, 30 Jun 2010 11:09:25 -0000 Hi In the mailing list also the option of a privacy service provided by the SS= P was suggested, which when acting as B2BUA, would ensure that a party remain= s anonymous. No comments were posted on this suggestion. Can this be a viable alternative? Regards Martien -----Original Message----- From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf = Of Cullen Jennings Sent: Wednesday, June 16, 2010 7:01 PM To: martini@ietf.org Subject: [martini] GIN temp GRUU I'm not OK with requiring out of band provisioning for K_e2. This would be = a nightmare in practice. Could it be passed in the register response? Having this as optional does not really work for me because most the US bas= ed customers doing PSTN replacement believe they are required to provide an= onymous call.=20 Overall, looks workable yet complicated - I wish there was a simpler way bu= t I could live with this.=20 _______________________________________________ martini mailing list martini@ietf.org https://www.ietf.org/mailman/listinfo/martini From pkyzivat@cisco.com Wed Jun 30 17:24:09 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 C13773A683D for ; Wed, 30 Jun 2010 17:24:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.261 X-Spam-Level: X-Spam-Status: No, score=-10.261 tagged_above=-999 required=5 tests=[AWL=0.338, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] 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 W9OXOe9GHw3q for ; Wed, 30 Jun 2010 17:24:09 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 15AA93A6803 for ; Wed, 30 Jun 2010 17:24:09 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.53,516,1272844800"; d="scan'208";a="152258627" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 01 Jul 2010 00:24:19 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o610OHCI011591; Thu, 1 Jul 2010 00:24:18 GMT Message-ID: <4C2BE02D.4080703@cisco.com> Date: Wed, 30 Jun 2010 20:24:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Martien Huysmans References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "martini@ietf.org" Subject: Re: [martini] GIN temp GRUU 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: Thu, 01 Jul 2010 00:24:10 -0000 Martien Huysmans wrote: > Hi > > In the mailing list also the option of a privacy service provided by the SSP > was suggested, which when acting as B2BUA, would ensure that a party remains anonymous. > No comments were posted on this suggestion. > Can this be a viable alternative? I didn't see that mail - can you provide a reference? What privacy service spec/features does this imply? To provide full functionality, for every dialog it would have to insert a B2BUA, create a temp gruu to replace the supplied contact, and then route out-of-dialog requests for that temp-gruu to the calling UA. And it would have to inactivate that temp-gruu at some suitable time. The real gruu mechanism seems less trouble. Thanks, Paul > Regards Martien > > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On Behalf Of Cullen Jennings > Sent: Wednesday, June 16, 2010 7:01 PM > To: martini@ietf.org > Subject: [martini] GIN temp GRUU > > > I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response? > > Having this as optional does not really work for me because most the US based customers doing PSTN replacement believe they are required to provide anonymous call. > > Overall, looks workable yet complicated - I wish there was a simpler way but I could live with this. > > > > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > From martien.huysmans@ericsson.com Wed Jun 30 23:26:00 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 7AC7C3A67AB for ; Wed, 30 Jun 2010 23:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.484 X-Spam-Level: X-Spam-Status: No, score=-4.484 tagged_above=-999 required=5 tests=[AWL=2.115, BAYES_00=-2.599, 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 uUiusxYBtY+9 for ; Wed, 30 Jun 2010 23:25:59 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 48F553A67A1 for ; Wed, 30 Jun 2010 23:25:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-fc-4c2c3501d9e2 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id EA.04.10125.1053C2C4; Thu, 1 Jul 2010 08:26:09 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Thu, 1 Jul 2010 08:26:09 +0200 From: Martien Huysmans To: Paul Kyzivat Date: Thu, 1 Jul 2010 08:26:07 +0200 Thread-Topic: [martini] GIN temp GRUU Thread-Index: AcsYs8F4mpOtjWGjTI+TBzMTUvATmQAMYgGQ Message-ID: References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <4C2BE02D.4080703@cisco.com> In-Reply-To: <4C2BE02D.4080703@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "martini@ietf.org" Subject: Re: [martini] GIN temp GRUU 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: Thu, 01 Jul 2010 06:26:00 -0000 The mail was called: GIN and anonymous GRUUS I was not considering "out of dialog requests".=20 Is that a requirement for anonymous calls? With a B2BUA in place, perhaps gruu would not be needed at all. /Regards Martien=20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Thursday, July 01, 2010 2:24 AM To: Martien Huysmans Cc: Cullen Jennings; martini@ietf.org Subject: Re: [martini] GIN temp GRUU Martien Huysmans wrote: > Hi >=20 > In the mailing list also the option of a privacy service provided by=20 > the SSP was suggested, which when acting as B2BUA, would ensure that a pa= rty remains anonymous. > No comments were posted on this suggestion. > Can this be a viable alternative? I didn't see that mail - can you provide a reference? What privacy service spec/features does this imply? To provide full functionality, for every dialog it would have to insert a B= 2BUA, create a temp gruu to replace the supplied contact, and then route ou= t-of-dialog requests for that temp-gruu to the calling UA. And it would hav= e to inactivate that temp-gruu at some suitable time. The real gruu mechanism seems less trouble. Thanks, Paul > Regards Martien >=20 > -----Original Message----- > From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On=20 > Behalf Of Cullen Jennings > Sent: Wednesday, June 16, 2010 7:01 PM > To: martini@ietf.org > Subject: [martini] GIN temp GRUU >=20 >=20 > I'm not OK with requiring out of band provisioning for K_e2. This would b= e a nightmare in practice. Could it be passed in the register response? >=20 > Having this as optional does not really work for me because most the US b= ased customers doing PSTN replacement believe they are required to provide = anonymous call.=20 >=20 > Overall, looks workable yet complicated - I wish there was a simpler way = but I could live with this.=20 >=20 >=20 >=20 > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini > _______________________________________________ > martini mailing list > martini@ietf.org > https://www.ietf.org/mailman/listinfo/martini >=20 From martien.huysmans@ericsson.com Wed Jun 30 23:59:21 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 DFE813A67C3 for ; Wed, 30 Jun 2010 23:59:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.189 X-Spam-Level: X-Spam-Status: No, score=-5.189 tagged_above=-999 required=5 tests=[AWL=1.409, 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 jXp2Im+FcvAm for ; Wed, 30 Jun 2010 23:59:21 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D83233A67A1 for ; Wed, 30 Jun 2010 23:59:20 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-2f-4c2c3cd38dee Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id A7.48.10125.3DC3C2C4; Thu, 1 Jul 2010 08:59:31 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.240]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 1 Jul 2010 08:59:31 +0200 From: Martien Huysmans To: "martini@ietf.org" Date: Thu, 1 Jul 2010 08:59:29 +0200 Thread-Topic: Impact of friends on martini-gin Thread-Index: AcsY6vOMm/z+btRzR6WuRPxdo2vtoA== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_B5CE2B521539624E8364D395B6F76B5C23D4260844ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [martini] Impact of friends on martini-gin 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: Thu, 01 Jul 2010 06:59:22 -0000 --_000_B5CE2B521539624E8364D395B6F76B5C23D4260844ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable In MARTINI Interim V martini-friends was discussed. I think there is impact of friends on martini-gin. Friends makes a distinction between two modes of operation, which are calle= d basic and federated. The basic mode is described in the current MARTINI-GIN. The PBX would announce the used mode by setting the bulk contact parameter = to either "basic" or "federated". This bulk contact parameter could be the bnc parameter. Regards Martien --_000_B5CE2B521539624E8364D395B6F76B5C23D4260844ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
In MARTINI Interim V martini-friends was discussed.
I think there is impact of friends on martini-gin.
 
Friends makes a distinction between two modes of operation, which are = called basic and federated.
The basic mode is described in the current MARTINI-GIN.
The PBX would announce the used mode by setting the bulk contact param= eter to either "basic" or "federated".
This bulk contact parameter could be the bnc parameter.
 
Regards Martien
 
 --_000_B5CE2B521539624E8364D395B6F76B5C23D4260844ESESSCMS0356e_--