From christer.holmberg@ericsson.com Fri Jun 10 00:48:59 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3C211E80A9 for ; Fri, 10 Jun 2011 00:48:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OyM0Xftm31By for ; Fri, 10 Jun 2011 00:48:58 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by ietfa.amsl.com (Postfix) with ESMTP id D757611E809E for ; Fri, 10 Jun 2011 00:48:57 -0700 (PDT) X-AuditID: c1b4fb3d-b7c17ae00000262e-8f-4df1cc67a519 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 69.EF.09774.76CC1FD4; Fri, 10 Jun 2011 09:48:56 +0200 (CEST) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.136]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 10 Jun 2011 09:48:55 +0200 From: Christer Holmberg To: "cuss@ietf.org" Date: Fri, 10 Jun 2011 09:48:53 +0200 Thread-Topic: WGLC for draft-ietf-cuss-sip-uui-reqs-02 - Christer's comments Thread-Index: AcwnQtg5tRvsCviYSKiSZ3JLkGzs8g== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194E360350@ESESSCMS0356.eemea.ericsson.se> 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_7F2072F1E0DE894DA4B517B93C6A0585194E360350ESESSCMS0356e_" MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 - Christer's comments X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 07:48:59 -0000 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E360350ESESSCMS0356e_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I have some editorial comments (see below), but in general I think the docu= ment is in good shape and ready for publication. Regards, Christer Abstract: ------------- Q_A_1: The first sentence is a little confusing, when it talks about introd= ucing and developing. I would suggest re-writing it to: "This document defines requirements for a new mechanism, for suppor= t of transporting call control related User to User Information (UUI) using= the Session Initiation Protocol (SIP)." Q_A_2: The second, third and fourth sentences are a little confusing, when = it talks about non-SIP application and examples in another protocol. I woul= d suggest re-writing it to: "A SIP session can be associated with an application, that needs to= be able to transport application specific information between SIP entities= during the session establishment. This is similar to the ISDN User to User Information Service." Q_A_3: The text says that the document discusses requirements and approache= s. However, I think the published version will define use-cases are require= ments. I would suggest re-writing to: "This document defines use-cases and requirements in order to achie= ve this." Section 1: -------------- Q_1_1: I think it is enough to say "...in both the originator and terminato= r of the session." Q_1_2: Change "SIP should not interpret, understand..." to "SIP MUST NOT be= required to interpret, understand...". Q_1_3: Regarding sending of information not considered to be UUI, I think i= t would be good to add text saying: "Transport of such information is outsi= de the scope of this document.". Q_1_4: Replace the reference to RFC 2976 with RFC 6086. Section 3 (including sub sections): -------------------------------------------------- Q_3_1: The examples talk about "originator UA" and "terminating UA". Please= use "originating UA". Q_3_2: Please use "INVITE request" instead of only "INVITE". Section 4: -------------- Q_4_1: Please re-write to: "This section defines the requirements...". Q_4_2: Please change "The mechanism will support..." to "The mechanism MUST= support". Q_4_3: REQ-1 talks about "SIP call setup requests and responses." However, = I don't think REFER counts as a call setup request, so I would suggest to r= e-write it to: "...and receive UUI data in initial SIP requests and responses for = a dialog." Q_4_4: Regarding REQ-7, about interworking, the text is a little unclear. I= s the intention that the solution is going to specify the interworking? If = so, should the requirement say that the mechanism must define the interwork= ing? Q_4_5: Regarding REQ-8, I would suggest to re-write to: "The mechanism MUST= define a way for SIP UAs to inform each other about the support of the mec= hanism." ...or something like that :) Section 6: -------------- Q_6_1: Change "this specification" to "this document", in order to be cons= istant with the rest of the document. --_000_7F2072F1E0DE894DA4B517B93C6A0585194E360350ESESSCMS0356e_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 
Hi,
 
I have some editorial comments (see below), but in ge= neral I think the document is in good shape and ready for publication.
 
Regards,
 
Christer
 
 
 
Abstract:
-------------
 
Q_A_1: The first sentence is a little confusing, when= it talks about introducing and developing. I would suggest re-writing it t= o:
 
        "This= document defines requirements for a new mechanism, for support of transpor= ting call control related User to User Information (UUI) using the Session = Initiation Protocol (SIP)."
 
 
Q_A_2: The second, third and fourth sentences are a l= ittle confusing, when it talks about non-SIP application and examples in an= other protocol. I would suggest re-writing it to:
 
        "A SI= P session can be associated with an application, that needs to be able to t= ransport application specific information between SIP entities during the s= ession establishment.
        This is si= milar to the ISDN User to User Information Service."
 
 
Q_A_3: The text says that the document discusses requ= irements and approaches. However, I think the published version will define= use-cases are requirements. I would suggest re-writing to:
 
        "This= document defines use-cases and requirements in order to achieve this."= ;
 
 
 
Section 1:
--------------
 
Q_1_1: I think it is enough to say "...in both t= he originator and terminator of the session."
 
 
Q_1_2: Change "SIP should not interpret, underst= and..." to "SIP MUST NOT be required to interpret, understand...&= quot;.
 
 
Q_1_3: Regarding sending of information not considere= d to be UUI, I think it would be good to add text saying: "Transport o= f such information is outside the scope of this document.".
 
 
Q_1_4: Replace the reference to RFC 2976 with RFC 608= 6.
 
 
Section 3 (including sub sections):
--------------------------------------------------
 
Q_3_1: The examples talk about "originator UA&qu= ot; and "terminating UA". Please use "originating UA".<= /font>
 
 
Q_3_2: Please use "INVITE request" instead = of only "INVITE".
 
 
Section 4:
--------------
 
Q_4_1: Please re-write to: "This section defines= the requirements...".
 
 
Q_4_2: Please change "The mechanism will support= ..." to "The mechanism MUST support".
 
 
Q_4_3: REQ-1 talks about "SIP call setup request= s and responses." However, I don't think REFER counts as a call setup = request, so I would suggest to re-write it to:
 
        "...a= nd receive UUI data in initial SIP requests and responses for a dialog.&quo= t;
 
 
Q_4_4: Regarding REQ-7, about interworking, the text = is a little unclear. Is the intention that the solution is going to specify= the interworking? If so, should the requirement say that the mechanism mus= t define the interworking?
 
 
Q_4_5: Regarding REQ-8, I would suggest to re-write t= o: "The mechanism MUST define a way for SIP UAs to inform each other a= bout the support of the mechanism."
 
...or something like that :)
 
 
Section 6:
--------------
 
Q_6_1:  Change "this specification" to= "this document", in order to be consistant with the rest of the = document.
 
 
 
 
 
 --_000_7F2072F1E0DE894DA4B517B93C6A0585194E360350ESESSCMS0356e_-- From R.Jesske@telekom.de Fri Jun 10 01:37:25 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B664F11E80DB for ; Fri, 10 Jun 2011 01:37:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.022 X-Spam-Level: X-Spam-Status: No, score=-3.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eBZdG3Lf2a1p for ; Fri, 10 Jun 2011 01:37:25 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by ietfa.amsl.com (Postfix) with ESMTP id C174A11E80D9 for ; Fri, 10 Jun 2011 01:37:24 -0700 (PDT) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail51.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2011 10:37:21 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 10 Jun 2011 10:37:21 +0200 From: To: , , Date: Fri, 10 Jun 2011 10:37:18 +0200 Thread-Topic: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt Thread-Index: Acwcwcj0rxRLuwHrR42IzU+eGv4AXgKh3W8A Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BAE8@HE111648.emea1.cds.t-internal.com> References: <20110527225849.18902.1217.idtracker@ietfa.amsl.com> In-Reply-To: <20110527225849.18902.1217.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 08:37:25 -0000 Dear Alan, Dear Laura, Thank you for your excellent work on this draft. I have read it and I'm happy with it and fully support it. Best Regards Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von internet-drafts@ietf.org > Gesendet: Samstag, 28. Mai 2011 00:59 > An: i-d-announce@ietf.org > Cc: cuss@ietf.org > Betreff: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt > > A New Internet-Draft is available from the on-line > Internet-Drafts directories. This draft is a work item of the > Call Control UUI Service for SIP Working Group of the IETF. > > Title : Problem Statement and Requirements > for Transporting User to User Call Control Information in SIP > Author(s) : Alan Johnston > Laura Liess > Filename : draft-ietf-cuss-sip-uui-reqs-02.txt > Pages : 11 > Date : 2011-05-27 > > This document introduces the transport of call control related User > to User Information (UUI) using the Session Initiation Protocol > (SIP), and develops several requirements for a new SIP mechanism. > Some SIP sessions are established by or related to a non-SIP > application. This application may have information that > needs to be > transported between the SIP User Agents during session > establishment. > A common example in another protocol is the ISDN User to User > Information Service. As networks move to SIP it is important that > applications requiring this data can continue to function in SIP > networks as well as the ability to interwork with this ISDN service > for end-to-end transparency. This document discusses requirements > and approaches to achieve this. In addition, the > extension will also > be used for native SIP endpoints implementing similar services and > interworking with ISDN services. Example use cases include an > exchange between two user agents, retargeting by a proxy, and > redirection. An example application is an Automatic Call > Distributor > (ACD) in a contact center. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-re > qs-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-02.txt > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From R.Jesske@telekom.de Fri Jun 10 03:44:44 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E445621F8472 for ; Fri, 10 Jun 2011 03:44:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.136 X-Spam-Level: X-Spam-Status: No, score=-3.136 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MyVYD4fqwEZG for ; Fri, 10 Jun 2011 03:44:43 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by ietfa.amsl.com (Postfix) with ESMTP id 5395121F846D for ; Fri, 10 Jun 2011 03:44:42 -0700 (PDT) Received: from he111631.emea1.cds.t-internal.com ([10.134.93.23]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 10 Jun 2011 12:44:37 +0200 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.233]) by HE111631.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 10 Jun 2011 12:44:37 +0200 From: To: , , , Date: Fri, 10 Jun 2011 12:44:36 +0200 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: Acwcwcj0rxRLuwHrR42IzU+eGv4AXgKh3W8AAAR1AVA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BCDE@HE111648.emea1.cds.t-internal.com> References: <20110527225849.18902.1217.idtracker@ietfa.amsl.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BAE8@HE111648.emea1.cds.t-internal.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BAE8@HE111648.emea1.cds.t-internal.com> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 10:44:45 -0000 Sorry I took the wrong mail. That was meant for the WGLC. I'm satisfied and we can go forward for publication. Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von Jesske, Roland > Gesendet: Freitag, 10. Juni 2011 10:37 > An: alan.b.johnston@gmail.com; Liess, Laura; cuss@ietf.org > Betreff: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt > > Dear Alan, > Dear Laura, > Thank you for your excellent work on this draft. > I have read it and I'm happy with it and fully support it. > > Best Regards > > Roland > > > > > -----Urspr=FCngliche Nachricht----- > > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > > Auftrag von internet-drafts@ietf.org > > Gesendet: Samstag, 28. Mai 2011 00:59 > > An: i-d-announce@ietf.org > > Cc: cuss@ietf.org > > Betreff: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. This draft is a work item of the > > Call Control UUI Service for SIP Working Group of the IETF. > > > > Title : Problem Statement and Requirements > > for Transporting User to User Call Control Information in SIP > > Author(s) : Alan Johnston > > Laura Liess > > Filename : draft-ietf-cuss-sip-uui-reqs-02.txt > > Pages : 11 > > Date : 2011-05-27 > > > > This document introduces the transport of call control > related User > > to User Information (UUI) using the Session Initiation Protocol > > (SIP), and develops several requirements for a new SIP mechanism. > > Some SIP sessions are established by or related to a non-SIP > > application. This application may have information that > > needs to be > > transported between the SIP User Agents during session > > establishment. > > A common example in another protocol is the ISDN User to User > > Information Service. As networks move to SIP it is > important that > > applications requiring this data can continue to function in SIP > > networks as well as the ability to interwork with this > ISDN service > > for end-to-end transparency. This document discusses > requirements > > and approaches to achieve this. In addition, the > > extension will also > > be used for native SIP endpoints implementing similar > services and > > interworking with ISDN services. Example use cases include an > > exchange between two user agents, retargeting by a proxy, and > > redirection. An example application is an Automatic Call > > Distributor > > (ACD) in a contact center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-re > > qs-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-02.txt > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From md3135@att.com Fri Jun 10 03:58:25 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C651621F852A for ; Fri, 10 Jun 2011 03:58:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.419 X-Spam-Level: X-Spam-Status: No, score=-106.419 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9Fhns+8W5qS4 for ; Fri, 10 Jun 2011 03:58:24 -0700 (PDT) Received: from mail119.messagelabs.com (mail119.messagelabs.com [216.82.241.195]) by ietfa.amsl.com (Postfix) with ESMTP id 96DA221F8528 for ; Fri, 10 Jun 2011 03:58:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-6.tower-119.messagelabs.com!1307703502!21384417!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 7864 invoked from network); 10 Jun 2011 10:58:22 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-6.tower-119.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jun 2011 10:58:22 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5AAvGiM007815; Fri, 10 Jun 2011 06:57:16 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5AAv7fs007698; Fri, 10 Jun 2011 06:57:09 -0400 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, 10 Jun 2011 06:58:14 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FD8@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BCDE@HE111648.emea1.cds.t-internal.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: Acwcwcj0rxRLuwHrR42IzU+eGv4AXgKh3W8AAAR1AVAAAGarYA== References: <20110527225849.18902.1217.idtracker@ietfa.amsl.com><580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BAE8@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BCDE@HE111648.emea1.cds.t-internal.com> From: "DOLLY, MARTIN C (ATTSI)" To: , , , Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 10:58:25 -0000 +1 -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of = R.Jesske@telekom.de Sent: Friday, June 10, 2011 6:45 AM To: R.Jesske@telekom.de; alan.b.johnston@gmail.com; L.Liess@telekom.de; = cuss@ietf.org Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Sorry I took the wrong mail. That was meant for the WGLC. I'm satisfied and we can go forward for publication. Roland > -----Urspr=FCngliche Nachricht----- > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > Auftrag von Jesske, Roland > Gesendet: Freitag, 10. Juni 2011 10:37 > An: alan.b.johnston@gmail.com; Liess, Laura; cuss@ietf.org > Betreff: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt > > Dear Alan, > Dear Laura, > Thank you for your excellent work on this draft. > I have read it and I'm happy with it and fully support it. > > Best Regards > > Roland > > > > > -----Urspr=FCngliche Nachricht----- > > Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im > > Auftrag von internet-drafts@ietf.org > > Gesendet: Samstag, 28. Mai 2011 00:59 > > An: i-d-announce@ietf.org > > Cc: cuss@ietf.org > > Betreff: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt > > > > A New Internet-Draft is available from the on-line > > Internet-Drafts directories. This draft is a work item of the > > Call Control UUI Service for SIP Working Group of the IETF. > > > > Title : Problem Statement and Requirements > > for Transporting User to User Call Control Information in SIP > > Author(s) : Alan Johnston > > Laura Liess > > Filename : draft-ietf-cuss-sip-uui-reqs-02.txt > > Pages : 11 > > Date : 2011-05-27 > > > > This document introduces the transport of call control > related User > > to User Information (UUI) using the Session Initiation Protocol > > (SIP), and develops several requirements for a new SIP mechanism. > > Some SIP sessions are established by or related to a non-SIP > > application. This application may have information that > > needs to be > > transported between the SIP User Agents during session > > establishment. > > A common example in another protocol is the ISDN User to User > > Information Service. As networks move to SIP it is > important that > > applications requiring this data can continue to function in SIP > > networks as well as the ability to interwork with this > ISDN service > > for end-to-end transparency. This document discusses > requirements > > and approaches to achieve this. In addition, the > > extension will also > > be used for native SIP endpoints implementing similar > services and > > interworking with ISDN services. Example use cases include an > > exchange between two user agents, retargeting by a proxy, and > > redirection. An example application is an Automatic Call > > Distributor > > (ACD) in a contact center. > > > > > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-re > > qs-02.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > This Internet-Draft can be retrieved at: > > > ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-02.txt > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From shida@agnada.com Fri Jun 10 04:53:52 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED81911E8071 for ; Fri, 10 Jun 2011 04:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.038 X-Spam-Level: X-Spam-Status: No, score=-2.038 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSgyhck+WA2m for ; Fri, 10 Jun 2011 04:53:52 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.66.24]) by ietfa.amsl.com (Postfix) with SMTP id 4038A11E8093 for ; Fri, 10 Jun 2011 04:53:52 -0700 (PDT) Received: (qmail 2312 invoked from network); 10 Jun 2011 11:50:36 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 10 Jun 2011 11:50:36 -0000 Received: from [125.192.75.244] (port=60225 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1QV0Hc-0001Yd-VA; Fri, 10 Jun 2011 06:53:49 -0500 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FD8@gaalpa1msgusr7e.ugd.att.com> Date: Fri, 10 Jun 2011 20:53:49 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1FC176AA-8A34-41D0-B04D-A1B08CFC539D@agnada.com> References: <20110527225849.18902.1217.idtracker@ietfa.amsl.com><580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BAE8@HE111648.emea1.cds.t-internal.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D088DE3BCDE@HE111648.emea1.cds.t-internal.com> <14C85D6CCBE92743AF33663BF5D24EBA0A4A2FD8@gaalpa1msgusr7e.ugd.att.com> To: "DOLLY, MARTIN C (ATTSI)" X-Mailer: Apple Mail (2.1084) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-BWhitelist: no X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:60225 X-Source-Auth: shida@agnada.com X-Email-Count: 1 X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t Cc: L.Liess@telekom.de, cuss@ietf.org Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 11:53:53 -0000 +1 On Jun 10, 2011, at 7:58 PM, DOLLY, MARTIN C (ATTSI) wrote: > +1 >=20 > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf = Of R.Jesske@telekom.de > Sent: Friday, June 10, 2011 6:45 AM > To: R.Jesske@telekom.de; alan.b.johnston@gmail.com; = L.Liess@telekom.de; cuss@ietf.org > Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >=20 > Sorry I took the wrong mail. > That was meant for the WGLC. > I'm satisfied and we can go forward for publication. >=20 > Roland >=20 >=20 >> -----Urspr=FCngliche Nachricht----- >> Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im >> Auftrag von Jesske, Roland >> Gesendet: Freitag, 10. Juni 2011 10:37 >> An: alan.b.johnston@gmail.com; Liess, Laura; cuss@ietf.org >> Betreff: Re: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt >>=20 >> Dear Alan, >> Dear Laura, >> Thank you for your excellent work on this draft. >> I have read it and I'm happy with it and fully support it. >>=20 >> Best Regards >>=20 >> Roland >>=20 >>=20 >>=20 >>> -----Urspr=FCngliche Nachricht----- >>> Von: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] Im >>> Auftrag von internet-drafts@ietf.org >>> Gesendet: Samstag, 28. Mai 2011 00:59 >>> An: i-d-announce@ietf.org >>> Cc: cuss@ietf.org >>> Betreff: [cuss] I-D Action: draft-ietf-cuss-sip-uui-reqs-02.txt >>>=20 >>> A New Internet-Draft is available from the on-line >>> Internet-Drafts directories. This draft is a work item of the >>> Call Control UUI Service for SIP Working Group of the IETF. >>>=20 >>> Title : Problem Statement and Requirements >>> for Transporting User to User Call Control Information in SIP >>> Author(s) : Alan Johnston >>> Laura Liess >>> Filename : draft-ietf-cuss-sip-uui-reqs-02.txt >>> Pages : 11 >>> Date : 2011-05-27 >>>=20 >>> This document introduces the transport of call control >> related User >>> to User Information (UUI) using the Session Initiation Protocol >>> (SIP), and develops several requirements for a new SIP mechanism. >>> Some SIP sessions are established by or related to a non-SIP >>> application. This application may have information that >>> needs to be >>> transported between the SIP User Agents during session >>> establishment. >>> A common example in another protocol is the ISDN User to User >>> Information Service. As networks move to SIP it is >> important that >>> applications requiring this data can continue to function in SIP >>> networks as well as the ability to interwork with this >> ISDN service >>> for end-to-end transparency. This document discusses >> requirements >>> and approaches to achieve this. In addition, the >>> extension will also >>> be used for native SIP endpoints implementing similar >> services and >>> interworking with ISDN services. Example use cases include an >>> exchange between two user agents, retargeting by a proxy, and >>> redirection. An example application is an Automatic Call >>> Distributor >>> (ACD) in a contact center. >>>=20 >>>=20 >>> A URL for this Internet-Draft is: >>> http://www.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-re >>> qs-02.txt >>>=20 >>> Internet-Drafts are also available by anonymous FTP at: >>> ftp://ftp.ietf.org/internet-drafts/ >>>=20 >>> This Internet-Draft can be retrieved at: >>>=20 >> = ftp://ftp.ietf.org/internet-drafts/draft-ietf-cuss-sip-uui-reqs-02.txt >>> _______________________________________________ >>> cuss mailing list >>> cuss@ietf.org >>> https://www.ietf.org/mailman/listinfo/cuss >>>=20 >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >>=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss From James.Rafferty@dialogic.com Fri Jun 10 14:24:49 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AC111E8105 for ; Fri, 10 Jun 2011 14:24:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.372 X-Spam-Level: X-Spam-Status: No, score=-2.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TjIBkW75p27L for ; Fri, 10 Jun 2011 14:24:45 -0700 (PDT) Received: from outbound.dialogic.com (outbound.dialogic.com [173.210.122.27]) by ietfa.amsl.com (Postfix) with ESMTP id 55C5411E8077 for ; Fri, 10 Jun 2011 14:24:44 -0700 (PDT) Received: from MBX.dialogic.com ([fe80::d09:39e:8fa1:c2a3]) by pysxht01.dialogic.com ([::1]) with mapi; Fri, 10 Jun 2011 17:24:44 -0400 From: James Rafferty To: "Vijay K. Gurbani" , "cuss@ietf.org" Date: Fri, 10 Jun 2011 17:24:43 -0400 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: AcwfnR23ooqsIrgYRKmyVeGk+InsLwIFmCNg Message-ID: <54633A5E61DC84429CB9FE3D9143C72104C9D0C0@MBX.dialogic.com> References: <4DE4F7D9.3010904@bell-labs.com> In-Reply-To: <4DE4F7D9.3010904@bell-labs.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: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2011 21:24:49 -0000 Hi,=20 I've reviewed the document and think it's in good shape for publication. =20 I have one small editorial comment on the last sentence of section 3.3 The sentence currently reads: =20 " The ability to maintain UUI in these scenarios is critical." I'd suggest -- "The ability to pass along UUI in these call redirection sc= enarios is critical." -- since the meaning of "maintain" in this context is= n't totally clear. =20 James -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of Vij= ay K. Gurbani Sent: Tuesday, May 31, 2011 10:15 AM To: cuss@ietf.org Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Folks: Enrico and I will like to issue a WGLC for the CUSS Problem Statemen= t and Requirements draft as follows: Draft: draft-ietf-cuss-sip-uui-reqs-02.txt WGLC period: May 31, 2011 - June 17, 2011 The authors believe that they have addressed all open issues. Please go through the latest version of the draft [1] and make sure that th= ere aren't any other outstanding issues. [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From vkg@bell-labs.com Mon Jun 13 06:34:41 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93BDC9E8007 for ; Mon, 13 Jun 2011 06:34:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.486 X-Spam-Level: X-Spam-Status: No, score=-106.486 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q84PZ+-ELIqp for ; Mon, 13 Jun 2011 06:34:40 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id 8CF0C9E8016 for ; Mon, 13 Jun 2011 06:34:40 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p5DDYdh6001830 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 13 Jun 2011 08:34:39 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5DDYdI3025876 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 13 Jun 2011 08:34:39 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5DDYcIh026192 for ; Mon, 13 Jun 2011 08:34:39 -0500 (CDT) Message-ID: <4DF6120C.3000109@bell-labs.com> Date: Mon, 13 Jun 2011 08:35:08 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Subject: [cuss] Reminder: WGLC in progress for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 13:34:41 -0000 Folks: This is a reminder that we are in the middle of WGLC [1] for draft-ietf-cuss-sip-uui-reqs-02. The WGLC ends on June 17, 2011; so please get in your comments and feedback before that. I note that a fair number of people have already provided feedback. If you have not already done so, please do take a couple of minutes of your time to look over the draft [2]. Thanks, [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html [2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From pkyzivat@cisco.com Mon Jun 13 08:10:12 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF6C22800A for ; Mon, 13 Jun 2011 08:10:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.255 X-Spam-Level: X-Spam-Status: No, score=-110.255 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lp1uH4Z41Cgt for ; Mon, 13 Jun 2011 08:10:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 83360228004 for ; Mon, 13 Jun 2011 08:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3445; q=dns/txt; s=iport; t=1307977808; x=1309187408; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=L950CUAAn0yWJMbtijUWJF9DLJCjn5Nk8i1hO9hel24=; b=dhB/+pxZBIGjVSKqGzb0Fq7oTrpiNoFrbCJt+WKFObvzJbxSlcOIPc1J zyhDLq9eNiv+Ld26IFz7QtQiCeb03eVLu1U/5Cd10eo91oIdVNJ9aOPc/ GbiL2vbxYHgg8z+/ALFZzZrk8e/zhGrNNMI7myp0IQKrMs0yO3F5f42wZ o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAO4n9k2rRDoG/2dsb2JhbABSpjl3iHKhap1GhiQEkTSET4sq X-IronPort-AV: E=Sophos;i="4.65,359,1304294400"; d="scan'208";a="375591049" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by sj-iport-2.cisco.com with ESMTP; 13 Jun 2011 15:10:07 +0000 Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by mtv-core-1.cisco.com (8.14.3/8.14.3) with ESMTP id p5DFA6om018681 for ; Mon, 13 Jun 2011 15:10:07 GMT Message-ID: <4DF6284E.3010208@cisco.com> Date: Mon, 13 Jun 2011 11:10:06 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: cuss@ietf.org References: <4DF6120C.3000109@bell-labs.com> In-Reply-To: <4DF6120C.3000109@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [cuss] Reminder: WGLC in progress for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2011 15:10:12 -0000 On 6/13/2011 9:35 AM, Vijay K. Gurbani wrote: > Folks: This is a reminder that we are in the middle of WGLC [1] > for draft-ietf-cuss-sip-uui-reqs-02. > > The WGLC ends on June 17, 2011; so please get in your comments > and feedback before that. I note that a fair number of people > have already provided feedback. > > If you have not already done so, please do take a couple of > minutes of your time to look over the draft [2]. OK, I just did a fresh review of the document. Its been awhile since I read it, and so the fresh view may have allowed me to see some things I hadn't seen before: 3.3. Redirection In this scenario, UUI is inserted by an application which utilizes a SIP redirect server. The UUI is then included in the INVITE sent by the Originator to the Terminator. In this case, the Originator does not necessarily need to support the UUI mechanism but does need to support the SIP redirection mechanism used to include the UUI information. Two examples of UUI with redirection (transfer and diversion) are defined in [ANSII] and [ETSI]. The statement "In this case, the Originator does not necessarily need to support the UUI mechanism" is dubious at best. It either must understand the mechanism in order to make an informed choice of whether to pass the UUI information from the 3xx to the new INVITE, or else it must blindly pass all URI header parameters that it receives. (If that is what the mechanism uses. If not, its even more of a problem.) Doing *that* is very unwise and not advocated by 3261. But it is the only way the Originator doesn't need to understand the mechanism. Or is this intended to mean that the *Originating application" need not know about the mechanism as long as the originating UA understands it and believes it to be sufficiently benign to allow passing from 3xx to resulting INVITE? REQ-9: The mechanism will allow proxies to remove a particular type of UUI information from a request or response. REQ-10: The mechanism will provide the ability for a UA to discover which types or application usages of UUI another UA understands or supports. The creation of a registry of application usages for the SIP UUI mechanism is implied by this requirement. For the ISDN Service, there could be value in utilizing the protocol discriminator, which is the first octet of the ISDN UUI information, for this purpose. I find no definition of any notion of "types" of UUI. Without such a definition this requirement is meaningless. Is it assumed that "type" and "application usage" are synonyms? Is it assumed that there is a relationship between types and/or application usages and protocol discriminators? IMO this needs to be nailed down to finalize the requirements. I *think* the intent is that "types" and "application usages" refer to the same thing, and we should use one term rather than two. (I'd prefer application usage.) And IMO ("based" on a very limited understanding of the use in ISDN) is that we ought to consider the various ISDN protocol discriminators to map onto *some* of the possible "application usages". Thanks, Paul > Thanks, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html > [2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt > > - vijay From christian.1.schmidt@nsn.com Wed Jun 15 01:58:35 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF45421F8560 for ; Wed, 15 Jun 2011 01:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dLcN+TvsJbc4 for ; Wed, 15 Jun 2011 01:58:31 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 7E14621F855B for ; Wed, 15 Jun 2011 01:58:31 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id p5F8wRpV010998 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 15 Jun 2011 10:58:28 +0200 Received: from demuexc023.nsn-intra.net (demuexc023.nsn-intra.net [10.150.128.36]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id p5F8wNpc021269; Wed, 15 Jun 2011 10:58:24 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc023.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Wed, 15 Jun 2011 10:58:23 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 15 Jun 2011 10:58:19 +0200 Message-ID: In-reply-to: <4DF6120C.3000109@bell-labs.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] Reminder: WGLC in progress fordraft-ietf-cuss-sip-uui-reqs-02 Thread-index: AcwpzqnmybedN4dAS1O9j0gRv58cwwAuhWtA References: <4DF6120C.3000109@bell-labs.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Vijay K. Gurbani" , X-OriginalArrivalTime: 15 Jun 2011 08:58:23.0991 (UTC) FILETIME=[620B5870:01CC2B3A] Subject: Re: [cuss] Reminder: WGLC in progress fordraft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jun 2011 08:58:35 -0000 Hi, after minor clarifications and adjustments, the draft should be ready for publication. Best Regards Christian General comment to the figures: UUI information is mentioned only sporadic, it should be mentioned in every message where UUI may be included. Examples: 200 OK in all figures or INVITE (F1) in figure 3. Figure 4: The flow sequence seems to be wrong. I would propose: F1, F2, F5, F3, F4, F6, F8, F9, F7. E.g. Notify trying F3 should not be sent before INVITE F5. Redirection: "If the Redirect Server is not in the same administrative domain as the Terminator, the Redirect Server must not remove or replace any UUI in the initial INVITE. In Figure 3, this means that if F1 included UUI, the Redirect Server could not modify or replace the UUI in F2. However, if the Redirect Server and the Terminator are part of the same administrative domain, they may have a policy allowing the Redirect Server to modify or rewrite UUI information. In fact, many UUI uses within an Enterprise rely on this feature to work today in ISDN." This section is somehow confusing.=20 What should the Redirect Server do with the UUI? Remove? Replace? Rewrite? Modify? What is the influence to REQ-12? Should there be 2 entries, one entry for the entity that inserted the UUI and one entry for the entity that modify/rewrite/replace the UUI? If this section is relevant for the requirements, please extend them accordingly, e.g. REQ-12. If this section is not relevant for the requirements, I would propose to delete the section. It seems not to be relevant for the understanding of the use case. REQ-1: "SIP messages covered by this include INVITE requests and end-to- end responses to the INVITE, which includes 18x and 200 responses." What about the 302 Moved Reply in the Redirection use case? Should we mention this Response here as well? -----Original Message----- From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of ext Vijay K. Gurbani Sent: Monday, June 13, 2011 3:35 PM To: cuss@ietf.org Subject: [cuss] Reminder: WGLC in progress fordraft-ietf-cuss-sip-uui-reqs-02 Folks: This is a reminder that we are in the middle of WGLC [1] for draft-ietf-cuss-sip-uui-reqs-02. The WGLC ends on June 17, 2011; so please get in your comments and feedback before that. I note that a fair number of people have already provided feedback. If you have not already done so, please do take a couple of minutes of your time to look over the draft [2]. Thanks, [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html [2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt - vijay --=20 Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ cuss mailing list cuss@ietf.org https://www.ietf.org/mailman/listinfo/cuss From john.elwell@siemens-enterprise.com Fri Jun 17 07:03:17 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9D811E8183 for ; Fri, 17 Jun 2011 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.436 X-Spam-Level: X-Spam-Status: No, score=-106.436 tagged_above=-999 required=5 tests=[AWL=-0.063, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tc6v8kYqbGTS for ; Fri, 17 Jun 2011 07:03:16 -0700 (PDT) Received: from mail174.messagelabs.com (mail174.messagelabs.com [85.158.138.51]) by ietfa.amsl.com (Postfix) with SMTP id ED5DA11E8184 for ; Fri, 17 Jun 2011 07:03:15 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-13.tower-174.messagelabs.com!1308319393!21881835!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 16915 invoked from network); 17 Jun 2011 14:03:13 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-13.tower-174.messagelabs.com with SMTP; 17 Jun 2011 14:03:13 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 2FC041EB83EE; Fri, 17 Jun 2011 16:03:13 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 17 Jun 2011 16:03:13 +0200 From: "Elwell, John" To: "Vijay K. Gurbani" , "cuss@ietf.org" Date: Fri, 17 Jun 2011 16:03:11 +0200 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: AcwfnRzeW0Zat0VpQs6GuRk67185kANPw27Q Message-ID: References: <4DE4F7D9.3010904@bell-labs.com> In-Reply-To: <4DE4F7D9.3010904@bell-labs.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: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:03:17 -0000 I don't think this is quite ready to go yet, mainly because I don't think t= he security story stands scrutiny. See comments 13 and 14 below. In particu= lar, knowing that we are choosing a mechanism based on a header field, end-= to-end privacy and integrity protection does not seem to be feasible. Given= that we probably need to accept hop-by-hop security, this will probably be= OK within a trusted domain (where intermediaries are trusted), but falls a= part when leaving that domain. For example, in the redirect case, if the 3x= x sends UUI all the way back to the originating UA in another domain, it co= uld disclose sensitive information, or the UUI could be subject to modifica= tion by that other domain before including in the new INVITE request. In pr= actice, of course, this would all be taken care of by an SBC, which would p= erform the redirection without the UUI leaving the domain. Similarly for RE= FER. I think we need proper discussion of these aspects and a reformulation= of the relevant requirements. Specific comments: 1. The Abstract is too long. Some of the stuff about examples could be left= for the main document. 2. Also in Abstract: "A common example in another protocol is the ISDN User to User Information Service." Since the previous sentences are talking about applications, it seems to im= ply ISDN U-U is an application, which isn't correct, so shouldn't portray t= his as an example application, but as a corresponding mechanism in another = protocol. 3. Section 1: "It is assumed that the application is running in both the originator of the session and the terminator of the session. That is, the application interacts with the User Agent Client (UAC) and User Agent Server (UAS)." This seems to imply a fixed relationship between session originator and UAC= and between session terminator and UAS, which is not correct - UAC and UAS= relate to transactions, not sessions. Note that we are not concerned only = with the initial INVITE transaction. 4. Section 2: I don't think the document uses RFC 2119 terms. 5. Section 3.2: Figure 2 looks identical to figure 1 - could just reference figure 1 instea= d or enhance figure 2 to show what is different. 6. Section 3.3: "Instead, these slight differences between the SIP UUI service and the ISDN service need to be carefully noted and discussed in an interworking specification." This implies somebody will write an interworking specification. I think it = would suffice to say: "Instead, these slight differences between the SIP UUI service and the ISDN service need to be carefully noted and taken into account when considering interworking.= " 7. Section 3.3: "If the Redirect Server is not in the same administrative domain as the Terminator, the Redirect Server must not remove or replace any UUI in the initial INVITE. In Figure 3, this means that if F1 included UUI, the Redirect Server could not modify or replace the UUI in F2. However, if the Redirect Server and the Terminator are part of the same administrative domain, they may have a policy allowing the Redirect Server to modify or rewrite UUI information. In fact, many UUI uses within an Enterprise rely on this feature to work today in ISDN." This sounds more like something for the mechanism document - is it really n= eeded in this document? 8. Section 3.4: "such as out-of-dialog REFER call control" What is "REFER call control"? 9. Section 4: "This section discusses the requirements for the transport of call control related user to user information (UUI)." I think it "states" the requirements. Similar at the end of section 1. 10. Section 4: " REQ-8: The mechanism will allow a UAC to learn or request that a UAS understands the call control UUI mechanism and permit routing of requests based on this." Should these be two separate requirements? Or are we happy for the mechanis= m just to satisfy either one of these (as implied by "learn or request"? 11. Section 4: " REQ-10: The mechanism will provide the ability for a UA to discover which types or application usages of UUI another UA understands or supports." This sounds like it is asking for a sort of OPTIONS request to see whether = application foo is supported, prior to sending UUI for foo in the INVITE re= quest. If that is not the intention, I think it needs some rewording. The I= SDN protocol discriminator indicates that a particular piece of UUI being t= ransmitted is for application foo - I don't recall that it does more than t= hat. 12. Section 4: "REQ-13: The mechanism will allow integrity protection of the UUI. This allows the UAS to be able to know that the UUI has not been modified or tampered with by intermediaries." This seems to suggest S/MIME? But I am not even sure that S/MIME would cove= r the redirect or refer cases. Note that TLS and SIPS do not satisfy this r= equirement as stated. 13. Section 4: "REQ-14: The mechanism will allow end-to-end privacy of the UUI." Again it seems to imply S/MIME. Yes, it could be achieved by some sort of e= ncryption mechanism used by the application, but that is always possible. W= e don't need a requirement on the mechanism to achieve that, unless the mec= hanism is to specify such an encryption mechanism for applications. As for = an RFC 3323-like privacy mechanism, this would not provide end-to-end priva= cy, because intermediaries have access to the information. 14. QSIG is mentioned, so there should be a reference to ECMA-143 (the basi= c QSIG standard). However, note that QSIG does not have a UUI standard, so = any QSIG interworking will be with a proprietary extension. Nits: - "a new SIP extensions" - Could do with a terminology consistency check, e.g., I think "terminator"= and "terminating UA" refer to the same thing. - Use "INVITE request" rather than "INVITE", in cases where INVITE request = (as opposed to INVITE transaction, INVITE method or INVITE response) is int= ended. - "The UUI could be used to lookup information rendered to the agent at the time of call answering." Change "rendered to" to "for rendering to". Also I would del= ete "at the time of call answer", since it could be rendered prior to answe= r. - "SIP messages covered by this include 3xx responses to INVITE and REFER requests." This is ambiguous - it could be interpreted as cover= ing 3xx responses to REFER requests. I think it should say: "SIP messages covered by this include REFER requests and 3xx responses to I= NVITE requests." John > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > Behalf Of Vijay K. Gurbani > Sent: 31 May 2011 15:15 > To: cuss@ietf.org > Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >=20 > Folks: Enrico and I will like to issue a WGLC for the CUSS > Problem Statement and Requirements draft as follows: >=20 >=20 > Draft: draft-ietf-cuss-sip-uui-reqs-02.txt > WGLC period: May 31, 2011 - June 17, 2011 >=20 > The authors believe that they have addressed all open issues. > Please go through the latest version of the draft [1] and > make sure that there aren't any other outstanding issues. >=20 > [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt >=20 > Thanks, >=20 > - vijay > --=20 > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From md3135@att.com Fri Jun 17 07:31:11 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7350B1F0C4C for ; Fri, 17 Jun 2011 07:31:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.35 X-Spam-Level: X-Spam-Status: No, score=-106.35 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sM7JVy6EIPPr for ; Fri, 17 Jun 2011 07:31:10 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id C48481F0C3F for ; Fri, 17 Jun 2011 07:31:09 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-15.tower-120.messagelabs.com!1308321068!23281060!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 29486 invoked from network); 17 Jun 2011 14:31:08 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-15.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 17 Jun 2011 14:31:08 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5HEU04N017589 for ; Fri, 17 Jun 2011 10:30:00 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id p5HETuXJ017515 for ; Fri, 17 Jun 2011 10:29:56 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Fri, 17 Jun 2011 10:31:02 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA093DBF30@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: AcwfnRzeW0Zat0VpQs6GuRk67185kANPw27QAAfBLcI= From: "DOLLY, MARTIN C (ATTSI)" To: , , Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 14:31:11 -0000 Sm9obg0KDQpUaGVyZSBhcmUgZXhpc3RpbmcgYnVzaW5lc3MgcmVsYXRpb25zaGlwcyB3aGVyZSBV VUkgaXMgYmV0d2VlbiB0aGUgU1AgYW5kIGFuIGVudGVycHJpc2UuIElzIHRoaXMgYSBmb3JtIG9m IEUtdG8tRSBvciBpbnRlcm1lZGlhcnksIGFzIGluIHlvdXIgcG9pbnQgMTM/DQoNClRoYW5rcw0K DQpNYXJ0aW4gQy4gRG9sbHkNClNlbnQgdG8geW91IGJ5IEFUJlQuLi4gQW1lcmljYSdzIEZhc3Rl c3QgTW9iaWxlIEJyb2FkYmFuZCBOZXR3b3JrLiBSZXRoaW5rIFBvc3NpYmxlLg0KKzEuNjA5Ljkw My4zMzYwDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0NCkZyb206IGN1c3MtYm91bmNl c0BpZXRmLm9yZyA8Y3Vzcy1ib3VuY2VzQGlldGYub3JnPg0KVG86IFZpamF5IEsuIEd1cmJhbmkg PHZrZ0BiZWxsLWxhYnMuY29tPjsgY3Vzc0BpZXRmLm9yZyA8Y3Vzc0BpZXRmLm9yZz4NClNlbnQ6 IEZyaSBKdW4gMTcgMTA6MDM6MTEgMjAxMQ0KU3ViamVjdDogUmU6IFtjdXNzXSBXR0xDIGZvciBk cmFmdC1pZXRmLWN1c3Mtc2lwLXV1aS1yZXFzLTAyDQoNCkkgZG9uJ3QgdGhpbmsgdGhpcyBpcyBx dWl0ZSByZWFkeSB0byBnbyB5ZXQsIG1haW5seSBiZWNhdXNlIEkgZG9uJ3QgdGhpbmsgdGhlIHNl Y3VyaXR5IHN0b3J5IHN0YW5kcyBzY3J1dGlueS4gU2VlIGNvbW1lbnRzIDEzIGFuZCAxNCBiZWxv dy4gSW4gcGFydGljdWxhciwga25vd2luZyB0aGF0IHdlIGFyZSBjaG9vc2luZyBhIG1lY2hhbmlz bSBiYXNlZCBvbiBhIGhlYWRlciBmaWVsZCwgZW5kLXRvLWVuZCBwcml2YWN5IGFuZCBpbnRlZ3Jp dHkgcHJvdGVjdGlvbiBkb2VzIG5vdCBzZWVtIHRvIGJlIGZlYXNpYmxlLiBHaXZlbiB0aGF0IHdl IHByb2JhYmx5IG5lZWQgdG8gYWNjZXB0IGhvcC1ieS1ob3Agc2VjdXJpdHksIHRoaXMgd2lsbCBw cm9iYWJseSBiZSBPSyB3aXRoaW4gYSB0cnVzdGVkIGRvbWFpbiAod2hlcmUgaW50ZXJtZWRpYXJp ZXMgYXJlIHRydXN0ZWQpLCBidXQgZmFsbHMgYXBhcnQgd2hlbiBsZWF2aW5nIHRoYXQgZG9tYWlu LiBGb3IgZXhhbXBsZSwgaW4gdGhlIHJlZGlyZWN0IGNhc2UsIGlmIHRoZSAzeHggc2VuZHMgVVVJ IGFsbCB0aGUgd2F5IGJhY2sgdG8gdGhlIG9yaWdpbmF0aW5nIFVBIGluIGFub3RoZXIgZG9tYWlu LCBpdCBjb3VsZCBkaXNjbG9zZSBzZW5zaXRpdmUgaW5mb3JtYXRpb24sIG9yIHRoZSBVVUkgY291 bGQgYmUgc3ViamVjdCB0byBtb2RpZmljYXRpb24gYnkgdGhhdCBvdGhlciBkb21haW4gYmVmb3Jl IGluY2x1ZGluZyBpbiB0aGUgbmV3IElOVklURSByZXF1ZXN0LiBJbiBwcmFjdGljZSwgb2YgY291 cnNlLCB0aGlzIHdvdWxkIGFsbCBiZSB0YWtlbiBjYXJlIG9mIGJ5IGFuIFNCQywgd2hpY2ggd291 bGQgcGVyZm9ybSB0aGUgcmVkaXJlY3Rpb24gd2l0aG91dCB0aGUgVVVJIGxlYXZpbmcgdGhlIGRv bWFpbi4gU2ltaWxhcmx5IGZvciBSRUZFUi4gSSB0aGluayB3ZSBuZWVkIHByb3BlciBkaXNjdXNz aW9uIG9mIHRoZXNlIGFzcGVjdHMgYW5kIGEgcmVmb3JtdWxhdGlvbiBvZiB0aGUgcmVsZXZhbg0K IHQgcmVxdWlyZW1lbnRzLg0KDQpTcGVjaWZpYyBjb21tZW50czoNCg0KMS4gVGhlIEFic3RyYWN0 IGlzIHRvbyBsb25nLiBTb21lIG9mIHRoZSBzdHVmZiBhYm91dCBleGFtcGxlcyBjb3VsZCBiZSBs ZWZ0IGZvciB0aGUgbWFpbiBkb2N1bWVudC4NCg0KMi4gQWxzbyBpbiBBYnN0cmFjdDoNCiJBIGNv bW1vbiBleGFtcGxlIGluIGFub3RoZXIgcHJvdG9jb2wgaXMgdGhlIElTRE4gVXNlciB0byBVc2Vy DQogICBJbmZvcm1hdGlvbiBTZXJ2aWNlLiINClNpbmNlIHRoZSBwcmV2aW91cyBzZW50ZW5jZXMg YXJlIHRhbGtpbmcgYWJvdXQgYXBwbGljYXRpb25zLCBpdCBzZWVtcyB0byBpbXBseSBJU0ROIFUt VSBpcyBhbiBhcHBsaWNhdGlvbiwgd2hpY2ggaXNuJ3QgY29ycmVjdCwgc28gc2hvdWxkbid0IHBv cnRyYXkgdGhpcyBhcyBhbiBleGFtcGxlIGFwcGxpY2F0aW9uLCBidXQgYXMgYSBjb3JyZXNwb25k aW5nIG1lY2hhbmlzbSBpbiBhbm90aGVyIHByb3RvY29sLg0KDQozLiBTZWN0aW9uIDE6DQoiSXQg aXMNCiAgIGFzc3VtZWQgdGhhdCB0aGUgYXBwbGljYXRpb24gaXMgcnVubmluZyBpbiBib3RoIHRo ZSBvcmlnaW5hdG9yIG9mIHRoZQ0KICAgc2Vzc2lvbiBhbmQgdGhlIHRlcm1pbmF0b3Igb2YgdGhl IHNlc3Npb24uICBUaGF0IGlzLCB0aGUgYXBwbGljYXRpb24NCiAgIGludGVyYWN0cyB3aXRoIHRo ZSBVc2VyIEFnZW50IENsaWVudCAoVUFDKSBhbmQgVXNlciBBZ2VudCBTZXJ2ZXINCiAgIChVQVMp LiINClRoaXMgc2VlbXMgdG8gaW1wbHkgYSBmaXhlZCByZWxhdGlvbnNoaXAgYmV0d2VlbiBzZXNz aW9uIG9yaWdpbmF0b3IgYW5kIFVBQyBhbmQgYmV0d2VlbiBzZXNzaW9uIHRlcm1pbmF0b3IgYW5k IFVBUywgd2hpY2ggaXMgbm90IGNvcnJlY3QgLSBVQUMgYW5kIFVBUyByZWxhdGUgdG8gdHJhbnNh Y3Rpb25zLCBub3Qgc2Vzc2lvbnMuIE5vdGUgdGhhdCB3ZSBhcmUgbm90IGNvbmNlcm5lZCBvbmx5 IHdpdGggdGhlIGluaXRpYWwgSU5WSVRFIHRyYW5zYWN0aW9uLg0KDQo0LiBTZWN0aW9uIDI6DQpJ IGRvbid0IHRoaW5rIHRoZSBkb2N1bWVudCB1c2VzIFJGQyAyMTE5IHRlcm1zLg0KDQo1LiBTZWN0 aW9uIDMuMjoNCkZpZ3VyZSAyIGxvb2tzIGlkZW50aWNhbCB0byBmaWd1cmUgMSAtIGNvdWxkIGp1 c3QgcmVmZXJlbmNlIGZpZ3VyZSAxIGluc3RlYWQgb3IgZW5oYW5jZSBmaWd1cmUgMiB0byBzaG93 IHdoYXQgaXMgZGlmZmVyZW50Lg0KDQo2LiBTZWN0aW9uIDMuMzoNCiJJbnN0ZWFkLCB0aGVzZSBz bGlnaHQNCiAgIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIFNJUCBVVUkgc2VydmljZSBhbmQgdGhl IElTRE4gc2VydmljZSBuZWVkIHRvDQogICBiZSBjYXJlZnVsbHkgbm90ZWQgYW5kIGRpc2N1c3Nl ZCBpbiBhbiBpbnRlcndvcmtpbmcgc3BlY2lmaWNhdGlvbi4iDQpUaGlzIGltcGxpZXMgc29tZWJv ZHkgd2lsbCB3cml0ZSBhbiBpbnRlcndvcmtpbmcgc3BlY2lmaWNhdGlvbi4gSSB0aGluayBpdCB3 b3VsZCBzdWZmaWNlIHRvIHNheToNCiJJbnN0ZWFkLCB0aGVzZSBzbGlnaHQNCiAgIGRpZmZlcmVu Y2VzIGJldHdlZW4gdGhlIFNJUCBVVUkgc2VydmljZSBhbmQgdGhlIElTRE4gc2VydmljZSBuZWVk IHRvDQogICBiZSBjYXJlZnVsbHkgbm90ZWQgYW5kIHRha2VuIGludG8gYWNjb3VudCB3aGVuIGNv bnNpZGVyaW5nIGludGVyd29ya2luZy4iDQoNCjcuIFNlY3Rpb24gMy4zOg0KIklmIHRoZSBSZWRp cmVjdCBTZXJ2ZXIgaXMgbm90IGluIHRoZSBzYW1lIGFkbWluaXN0cmF0aXZlIGRvbWFpbiBhcw0K ICAgdGhlIFRlcm1pbmF0b3IsIHRoZSBSZWRpcmVjdCBTZXJ2ZXIgbXVzdCBub3QgcmVtb3ZlIG9y IHJlcGxhY2UgYW55DQogICBVVUkgaW4gdGhlIGluaXRpYWwgSU5WSVRFLiAgSW4gRmlndXJlIDMs IHRoaXMgbWVhbnMgdGhhdCBpZiBGMQ0KICAgaW5jbHVkZWQgVVVJLCB0aGUgUmVkaXJlY3QgU2Vy dmVyIGNvdWxkIG5vdCBtb2RpZnkgb3IgcmVwbGFjZSB0aGUgVVVJDQogICBpbiBGMi4gIEhvd2V2 ZXIsIGlmIHRoZSBSZWRpcmVjdCBTZXJ2ZXIgYW5kIHRoZSBUZXJtaW5hdG9yIGFyZSBwYXJ0DQog ICBvZiB0aGUgc2FtZSBhZG1pbmlzdHJhdGl2ZSBkb21haW4sIHRoZXkgbWF5IGhhdmUgYSBwb2xp Y3kgYWxsb3dpbmcNCiAgIHRoZSBSZWRpcmVjdCBTZXJ2ZXIgdG8gbW9kaWZ5IG9yIHJld3JpdGUg VVVJIGluZm9ybWF0aW9uLiAgSW4gZmFjdCwNCiAgIG1hbnkgVVVJIHVzZXMgd2l0aGluIGFuIEVu dGVycHJpc2UgcmVseSBvbiB0aGlzIGZlYXR1cmUgdG8gd29yayB0b2RheQ0KICAgaW4gSVNETi4i DQpUaGlzIHNvdW5kcyBtb3JlIGxpa2Ugc29tZXRoaW5nIGZvciB0aGUgbWVjaGFuaXNtIGRvY3Vt ZW50IC0gaXMgaXQgcmVhbGx5IG5lZWRlZCBpbiB0aGlzIGRvY3VtZW50Pw0KDQo4LiBTZWN0aW9u IDMuNDoNCiJzdWNoIGFzIG91dC1vZi1kaWFsb2cgUkVGRVINCiAgIGNhbGwgY29udHJvbCINCldo YXQgaXMgIlJFRkVSIGNhbGwgY29udHJvbCI/DQoNCjkuIFNlY3Rpb24gNDoNCiJUaGlzIHNlY3Rp b24gZGlzY3Vzc2VzIHRoZSByZXF1aXJlbWVudHMgZm9yIHRoZSB0cmFuc3BvcnQgb2YgY2FsbA0K ICAgY29udHJvbCByZWxhdGVkIHVzZXIgdG8gdXNlciBpbmZvcm1hdGlvbiAoVVVJKS4iDQpJIHRo aW5rIGl0ICJzdGF0ZXMiIHRoZSByZXF1aXJlbWVudHMuIFNpbWlsYXIgYXQgdGhlIGVuZCBvZiBz ZWN0aW9uIDEuDQoNCjEwLiBTZWN0aW9uIDQ6DQoiIFJFUS04OiBUaGUgbWVjaGFuaXNtIHdpbGwg YWxsb3cgYSBVQUMgdG8gbGVhcm4gb3IgcmVxdWVzdCB0aGF0IGEgVUFTDQogICB1bmRlcnN0YW5k cyB0aGUgY2FsbCBjb250cm9sIFVVSSBtZWNoYW5pc20gYW5kIHBlcm1pdCByb3V0aW5nIG9mDQog ICByZXF1ZXN0cyBiYXNlZCBvbiB0aGlzLiINClNob3VsZCB0aGVzZSBiZSB0d28gc2VwYXJhdGUg cmVxdWlyZW1lbnRzPyBPciBhcmUgd2UgaGFwcHkgZm9yIHRoZSBtZWNoYW5pc20ganVzdCB0byBz YXRpc2Z5IGVpdGhlciBvbmUgb2YgdGhlc2UgKGFzIGltcGxpZWQgYnkgImxlYXJuIG9yIHJlcXVl c3QiPw0KDQoxMS4gU2VjdGlvbiA0Og0KIiBSRVEtMTA6IFRoZSBtZWNoYW5pc20gd2lsbCBwcm92 aWRlIHRoZSBhYmlsaXR5IGZvciBhIFVBIHRvIGRpc2NvdmVyDQogICB3aGljaCB0eXBlcyBvciBh cHBsaWNhdGlvbiB1c2FnZXMgb2YgVVVJIGFub3RoZXIgVUEgdW5kZXJzdGFuZHMgb3INCiAgIHN1 cHBvcnRzLiINClRoaXMgc291bmRzIGxpa2UgaXQgaXMgYXNraW5nIGZvciBhIHNvcnQgb2YgT1BU SU9OUyByZXF1ZXN0IHRvIHNlZSB3aGV0aGVyIGFwcGxpY2F0aW9uIGZvbyBpcyBzdXBwb3J0ZWQs IHByaW9yIHRvIHNlbmRpbmcgVVVJIGZvciBmb28gaW4gdGhlIElOVklURSByZXF1ZXN0LiBJZiB0 aGF0IGlzIG5vdCB0aGUgaW50ZW50aW9uLCBJIHRoaW5rIGl0IG5lZWRzIHNvbWUgcmV3b3JkaW5n LiBUaGUgSVNETiBwcm90b2NvbCBkaXNjcmltaW5hdG9yIGluZGljYXRlcyB0aGF0IGEgcGFydGlj dWxhciBwaWVjZSBvZiBVVUkgYmVpbmcgdHJhbnNtaXR0ZWQgaXMgZm9yIGFwcGxpY2F0aW9uIGZv byAtIEkgZG9uJ3QgcmVjYWxsIHRoYXQgaXQgZG9lcyBtb3JlIHRoYW4gdGhhdC4NCg0KMTIuIFNl Y3Rpb24gNDoNCiJSRVEtMTM6IFRoZSBtZWNoYW5pc20gd2lsbCBhbGxvdyBpbnRlZ3JpdHkgcHJv dGVjdGlvbiBvZiB0aGUgVVVJLg0KVGhpcyBhbGxvd3MgdGhlIFVBUyB0byBiZSBhYmxlIHRvIGtu b3cgdGhhdCB0aGUgVVVJIGhhcyBub3QgYmVlbg0KICAgICAgbW9kaWZpZWQgb3IgdGFtcGVyZWQg d2l0aCBieSBpbnRlcm1lZGlhcmllcy4iDQpUaGlzIHNlZW1zIHRvIHN1Z2dlc3QgUy9NSU1FPyBC dXQgSSBhbSBub3QgZXZlbiBzdXJlIHRoYXQgUy9NSU1FIHdvdWxkIGNvdmVyIHRoZSByZWRpcmVj dCBvciByZWZlciBjYXNlcy4gTm90ZSB0aGF0IFRMUyBhbmQgU0lQUyBkbyBub3Qgc2F0aXNmeSB0 aGlzIHJlcXVpcmVtZW50IGFzIHN0YXRlZC4NCg0KMTMuIFNlY3Rpb24gNDoNCiJSRVEtMTQ6IFRo ZSBtZWNoYW5pc20gd2lsbCBhbGxvdyBlbmQtdG8tZW5kIHByaXZhY3kgb2YgdGhlIFVVSS4iDQpB Z2FpbiBpdCBzZWVtcyB0byBpbXBseSBTL01JTUUuIFllcywgaXQgY291bGQgYmUgYWNoaWV2ZWQg Ynkgc29tZSBzb3J0IG9mIGVuY3J5cHRpb24gbWVjaGFuaXNtIHVzZWQgYnkgdGhlIGFwcGxpY2F0 aW9uLCBidXQgdGhhdCBpcyBhbHdheXMgcG9zc2libGUuIFdlIGRvbid0IG5lZWQgYSByZXF1aXJl bWVudCBvbiB0aGUgbWVjaGFuaXNtIHRvIGFjaGlldmUgdGhhdCwgdW5sZXNzIHRoZSBtZWNoYW5p c20gaXMgdG8gc3BlY2lmeSBzdWNoIGFuIGVuY3J5cHRpb24gbWVjaGFuaXNtIGZvciBhcHBsaWNh dGlvbnMuIEFzIGZvciBhbiBSRkMgMzMyMy1saWtlIHByaXZhY3kgbWVjaGFuaXNtLCB0aGlzIHdv dWxkIG5vdCBwcm92aWRlIGVuZC10by1lbmQgcHJpdmFjeSwgYmVjYXVzZSBpbnRlcm1lZGlhcmll cyBoYXZlIGFjY2VzcyB0byB0aGUgaW5mb3JtYXRpb24uDQoNCjE0LiBRU0lHIGlzIG1lbnRpb25l ZCwgc28gdGhlcmUgc2hvdWxkIGJlIGEgcmVmZXJlbmNlIHRvIEVDTUEtMTQzICh0aGUgYmFzaWMg UVNJRyBzdGFuZGFyZCkuIEhvd2V2ZXIsIG5vdGUgdGhhdCBRU0lHIGRvZXMgbm90IGhhdmUgYSBV VUkgc3RhbmRhcmQsIHNvIGFueSBRU0lHIGludGVyd29ya2luZyB3aWxsIGJlIHdpdGggYSBwcm9w cmlldGFyeSBleHRlbnNpb24uDQoNCg0KTml0czoNCi0gImEgbmV3IFNJUCBleHRlbnNpb25zIg0K LSBDb3VsZCBkbyB3aXRoIGEgdGVybWlub2xvZ3kgY29uc2lzdGVuY3kgY2hlY2ssIGUuZy4sIEkg dGhpbmsgInRlcm1pbmF0b3IiIGFuZCAidGVybWluYXRpbmcgVUEiIHJlZmVyIHRvIHRoZSBzYW1l IHRoaW5nLg0KLSBVc2UgIklOVklURSByZXF1ZXN0IiByYXRoZXIgdGhhbiAiSU5WSVRFIiwgaW4g Y2FzZXMgd2hlcmUgSU5WSVRFIHJlcXVlc3QgKGFzIG9wcG9zZWQgdG8gSU5WSVRFIHRyYW5zYWN0 aW9uLCBJTlZJVEUgbWV0aG9kIG9yIElOVklURSByZXNwb25zZSkgaXMgaW50ZW5kZWQuDQotICJU aGUgVVVJIGNvdWxkIGJlIHVzZWQgdG8NCiAgIGxvb2t1cCBpbmZvcm1hdGlvbiByZW5kZXJlZCB0 byB0aGUgYWdlbnQgYXQgdGhlIHRpbWUgb2YgY2FsbA0KICAgYW5zd2VyaW5nLiIgQ2hhbmdlICJy ZW5kZXJlZCB0byIgdG8gImZvciByZW5kZXJpbmcgdG8iLiBBbHNvIEkgd291bGQgZGVsZXRlICJh dCB0aGUgdGltZSBvZiBjYWxsIGFuc3dlciIsIHNpbmNlIGl0IGNvdWxkIGJlIHJlbmRlcmVkIHBy aW9yIHRvIGFuc3dlci4NCi0gIlNJUCBtZXNzYWdlcyBjb3ZlcmVkIGJ5IHRoaXMgaW5jbHVkZSAz eHggcmVzcG9uc2VzIHRvIElOVklURSBhbmQNCiAgICAgIFJFRkVSIHJlcXVlc3RzLiIgVGhpcyBp cyBhbWJpZ3VvdXMgLSBpdCBjb3VsZCBiZSBpbnRlcnByZXRlZCBhcyBjb3ZlcmluZyAzeHggcmVz cG9uc2VzIHRvIFJFRkVSIHJlcXVlc3RzLiBJIHRoaW5rIGl0IHNob3VsZCBzYXk6DQoiU0lQIG1l c3NhZ2VzIGNvdmVyZWQgYnkgdGhpcyBpbmNsdWRlIFJFRkVSIHJlcXVlc3RzIGFuZCAzeHggcmVz cG9uc2VzIHRvIElOVklURSByZXF1ZXN0cy4iDQoNCkpvaG4NCg0KPiAtLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KPiBGcm9tOiBjdXNzLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpjdXNzLWJv dW5jZXNAaWV0Zi5vcmddIE9uIA0KPiBCZWhhbGYgT2YgVmlqYXkgSy4gR3VyYmFuaQ0KPiBTZW50 OiAzMSBNYXkgMjAxMSAxNToxNQ0KPiBUbzogY3Vzc0BpZXRmLm9yZw0KPiBTdWJqZWN0OiBbY3Vz c10gV0dMQyBmb3IgZHJhZnQtaWV0Zi1jdXNzLXNpcC11dWktcmVxcy0wMg0KPiANCj4gRm9sa3M6 IEVucmljbyBhbmQgSSB3aWxsIGxpa2UgdG8gaXNzdWUgYSBXR0xDIGZvciB0aGUgQ1VTUw0KPiBQ cm9ibGVtIFN0YXRlbWVudCBhbmQgUmVxdWlyZW1lbnRzIGRyYWZ0IGFzIGZvbGxvd3M6DQo+IA0K PiANCj4gICAgRHJhZnQ6IGRyYWZ0LWlldGYtY3Vzcy1zaXAtdXVpLXJlcXMtMDIudHh0DQo+ICAg IFdHTEMgcGVyaW9kOiBNYXkgMzEsIDIwMTEgLSBKdW5lIDE3LCAyMDExDQo+IA0KPiBUaGUgYXV0 aG9ycyBiZWxpZXZlIHRoYXQgdGhleSBoYXZlIGFkZHJlc3NlZCBhbGwgb3BlbiBpc3N1ZXMuDQo+ IFBsZWFzZSBnbyB0aHJvdWdoIHRoZSBsYXRlc3QgdmVyc2lvbiBvZiB0aGUgZHJhZnQgWzFdIGFu ZA0KPiBtYWtlIHN1cmUgdGhhdCB0aGVyZSBhcmVuJ3QgYW55IG90aGVyIG91dHN0YW5kaW5nIGlz c3Vlcy4NCj4gDQo+IFsxXSBodHRwOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtY3Vzcy1z aXAtdXVpLXJlcXMtMDIudHh0DQo+IA0KPiBUaGFua3MsDQo+IA0KPiAtIHZpamF5DQo+IC0tIA0K PiBWaWpheSBLLiBHdXJiYW5pLCBCZWxsIExhYm9yYXRvcmllcywgQWxjYXRlbC1MdWNlbnQNCj4g MTk2MCBMdWNlbnQgTGFuZSwgUm0uIDlDLTUzMywgTmFwZXJ2aWxsZSwgSWxsaW5vaXMgNjA1NjYg KFVTQSkNCj4gRW1haWw6IHZrZ0B7YmVsbC1sYWJzLmNvbSxhY20ub3JnfSAvIHZpamF5Lmd1cmJh bmlAYWxjYXRlbC1sdWNlbnQuY29tDQo+IFdlYjogICBodHRwOi8vZWN0LmJlbGwtbGFicy5jb20v d2hvL3ZrZy8NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gY3VzcyBtYWlsaW5nIGxpc3QNCj4gY3Vzc0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2N1c3MNCj4gDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KY3VzcyBtYWlsaW5nIGxpc3QNCmN1c3NAaWV0Zi5v cmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vY3Vzcw0K From john.elwell@siemens-enterprise.com Fri Jun 17 08:58:50 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A0D811E81EB for ; Fri, 17 Jun 2011 08:58:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.431 X-Spam-Level: X-Spam-Status: No, score=-106.431 tagged_above=-999 required=5 tests=[AWL=-0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o3XP9HOqzz80 for ; Fri, 17 Jun 2011 08:58:49 -0700 (PDT) Received: from mail27.messagelabs.com (mail27.messagelabs.com [193.109.254.147]) by ietfa.amsl.com (Postfix) with SMTP id A462111E81E7 for ; Fri, 17 Jun 2011 08:58:48 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1308326317!40926901!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.9] Received: (qmail 3244 invoked from network); 17 Jun 2011 15:58:37 -0000 Received: from unknown (HELO senmx11-mx) (62.134.46.9) by server-6.tower-27.messagelabs.com with SMTP; 17 Jun 2011 15:58:37 -0000 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 0A0ED1EB83EE; Fri, 17 Jun 2011 17:58:47 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 17 Jun 2011 17:58:47 +0200 From: "Elwell, John" To: "DOLLY, MARTIN C (ATTSI)" , "vkg@bell-labs.com" , "cuss@ietf.org" Date: Fri, 17 Jun 2011 17:58:45 +0200 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: AcwfnRzeW0Zat0VpQs6GuRk67185kANPw27QAAfBLcIAAvcSAA== Message-ID: References: <14C85D6CCBE92743AF33663BF5D24EBA093DBF30@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA093DBF30@gaalpa1msgusr7e.ugd.att.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: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Jun 2011 15:58:50 -0000 Martin, I don't know the answer to your question. It depends on the particular usag= e. For example, there could be UUI from an SP to an enterprise, and there m= ight be one or more intermediaries (e.g., SBCs) between the source and sink= of the UUI. The question is whether privacy / encryption is end-to-end bet= ween source and sink or whether it is hop-by-hop (so that intermediaries ca= n see the data). What are the requirements here? John > -----Original Message----- > From: DOLLY, MARTIN C (ATTSI) [mailto:md3135@att.com]=20 > Sent: 17 June 2011 15:31 > To: Elwell, John; vkg@bell-labs.com; cuss@ietf.org > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >=20 > John >=20 > There are existing business relationships where UUI is=20 > between the SP and an enterprise. Is this a form of E-to-E or=20 > intermediary, as in your point 13? >=20 > Thanks >=20 > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband=20 > Network. Rethink Possible. > +1.609.903.3360 >=20 > ----- Original Message ----- > From: cuss-bounces@ietf.org > To: Vijay K. Gurbani ; cuss@ietf.org=20 > > Sent: Fri Jun 17 10:03:11 2011 > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >=20 > I don't think this is quite ready to go yet, mainly because I=20 > don't think the security story stands scrutiny. See comments=20 > 13 and 14 below. In particular, knowing that we are choosing=20 > a mechanism based on a header field, end-to-end privacy and=20 > integrity protection does not seem to be feasible. Given that=20 > we probably need to accept hop-by-hop security, this will=20 > probably be OK within a trusted domain (where intermediaries=20 > are trusted), but falls apart when leaving that domain. For=20 > example, in the redirect case, if the 3xx sends UUI all the=20 > way back to the originating UA in another domain, it could=20 > disclose sensitive information, or the UUI could be subject=20 > to modification by that other domain before including in the=20 > new INVITE request. In practice, of course, this would all be=20 > taken care of by an SBC, which would perform the redirection=20 > without the UUI leaving the domain. Similarly for REFER. I=20 > think we need proper discussion of these aspects and a=20 > reformulation of the relevan > t requirements. >=20 > Specific comments: >=20 > 1. The Abstract is too long. Some of the stuff about examples=20 > could be left for the main document. >=20 > 2. Also in Abstract: > "A common example in another protocol is the ISDN User to User > Information Service." > Since the previous sentences are talking about applications,=20 > it seems to imply ISDN U-U is an application, which isn't=20 > correct, so shouldn't portray this as an example application,=20 > but as a corresponding mechanism in another protocol. >=20 > 3. Section 1: > "It is > assumed that the application is running in both the=20 > originator of the > session and the terminator of the session. That is, the=20 > application > interacts with the User Agent Client (UAC) and User Agent Server > (UAS)." > This seems to imply a fixed relationship between session=20 > originator and UAC and between session terminator and UAS,=20 > which is not correct - UAC and UAS relate to transactions,=20 > not sessions. Note that we are not concerned only with the=20 > initial INVITE transaction. >=20 > 4. Section 2: > I don't think the document uses RFC 2119 terms. >=20 > 5. Section 3.2: > Figure 2 looks identical to figure 1 - could just reference=20 > figure 1 instead or enhance figure 2 to show what is different. >=20 > 6. Section 3.3: > "Instead, these slight > differences between the SIP UUI service and the ISDN=20 > service need to > be carefully noted and discussed in an interworking specification." > This implies somebody will write an interworking=20 > specification. I think it would suffice to say: > "Instead, these slight > differences between the SIP UUI service and the ISDN=20 > service need to > be carefully noted and taken into account when considering=20 > interworking." >=20 > 7. Section 3.3: > "If the Redirect Server is not in the same administrative domain as > the Terminator, the Redirect Server must not remove or replace any > UUI in the initial INVITE. In Figure 3, this means that if F1 > included UUI, the Redirect Server could not modify or=20 > replace the UUI > in F2. However, if the Redirect Server and the Terminator are part > of the same administrative domain, they may have a policy allowing > the Redirect Server to modify or rewrite UUI information. In fact, > many UUI uses within an Enterprise rely on this feature to=20 > work today > in ISDN." > This sounds more like something for the mechanism document -=20 > is it really needed in this document? >=20 > 8. Section 3.4: > "such as out-of-dialog REFER > call control" > What is "REFER call control"? >=20 > 9. Section 4: > "This section discusses the requirements for the transport of call > control related user to user information (UUI)." > I think it "states" the requirements. Similar at the end of section 1. >=20 > 10. Section 4: > " REQ-8: The mechanism will allow a UAC to learn or request that a UAS > understands the call control UUI mechanism and permit routing of > requests based on this." > Should these be two separate requirements? Or are we happy=20 > for the mechanism just to satisfy either one of these (as=20 > implied by "learn or request"? >=20 > 11. Section 4: > " REQ-10: The mechanism will provide the ability for a UA to discover > which types or application usages of UUI another UA understands or > supports." > This sounds like it is asking for a sort of OPTIONS request=20 > to see whether application foo is supported, prior to sending=20 > UUI for foo in the INVITE request. If that is not the=20 > intention, I think it needs some rewording. The ISDN protocol=20 > discriminator indicates that a particular piece of UUI being=20 > transmitted is for application foo - I don't recall that it=20 > does more than that. >=20 > 12. Section 4: > "REQ-13: The mechanism will allow integrity protection of the UUI. > This allows the UAS to be able to know that the UUI has not been > modified or tampered with by intermediaries." > This seems to suggest S/MIME? But I am not even sure that=20 > S/MIME would cover the redirect or refer cases. Note that TLS=20 > and SIPS do not satisfy this requirement as stated. >=20 > 13. Section 4: > "REQ-14: The mechanism will allow end-to-end privacy of the UUI." > Again it seems to imply S/MIME. Yes, it could be achieved by=20 > some sort of encryption mechanism used by the application,=20 > but that is always possible. We don't need a requirement on=20 > the mechanism to achieve that, unless the mechanism is to=20 > specify such an encryption mechanism for applications. As for=20 > an RFC 3323-like privacy mechanism, this would not provide=20 > end-to-end privacy, because intermediaries have access to the=20 > information. >=20 > 14. QSIG is mentioned, so there should be a reference to=20 > ECMA-143 (the basic QSIG standard). However, note that QSIG=20 > does not have a UUI standard, so any QSIG interworking will=20 > be with a proprietary extension. >=20 >=20 > Nits: > - "a new SIP extensions" > - Could do with a terminology consistency check, e.g., I=20 > think "terminator" and "terminating UA" refer to the same thing. > - Use "INVITE request" rather than "INVITE", in cases where=20 > INVITE request (as opposed to INVITE transaction, INVITE=20 > method or INVITE response) is intended. > - "The UUI could be used to > lookup information rendered to the agent at the time of call > answering." Change "rendered to" to "for rendering to".=20 > Also I would delete "at the time of call answer", since it=20 > could be rendered prior to answer. > - "SIP messages covered by this include 3xx responses to INVITE and > REFER requests." This is ambiguous - it could be=20 > interpreted as covering 3xx responses to REFER requests. I=20 > think it should say: > "SIP messages covered by this include REFER requests and 3xx=20 > responses to INVITE requests." >=20 > John >=20 > > -----Original Message----- > > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On=20 > > Behalf Of Vijay K. Gurbani > > Sent: 31 May 2011 15:15 > > To: cuss@ietf.org > > Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 > >=20 > > Folks: Enrico and I will like to issue a WGLC for the CUSS > > Problem Statement and Requirements draft as follows: > >=20 > >=20 > > Draft: draft-ietf-cuss-sip-uui-reqs-02.txt > > WGLC period: May 31, 2011 - June 17, 2011 > >=20 > > The authors believe that they have addressed all open issues. > > Please go through the latest version of the draft [1] and > > make sure that there aren't any other outstanding issues. > >=20 > > [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt > >=20 > > Thanks, > >=20 > > - vijay > > --=20 > > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > > Email: vkg@{bell-labs.com,acm.org} /=20 > vijay.gurbani@alcatel-lucent.com > > Web: http://ect.bell-labs.com/who/vkg/ > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > >=20 > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > = From alan.b.johnston@gmail.com Tue Jun 21 08:26:00 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8AA11E8102 for ; Tue, 21 Jun 2011 08:26:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.486 X-Spam-Level: X-Spam-Status: No, score=-103.486 tagged_above=-999 required=5 tests=[AWL=-0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 77RSV8p5rH8E for ; Tue, 21 Jun 2011 08:25:59 -0700 (PDT) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by ietfa.amsl.com (Postfix) with ESMTP id A101711E80C7 for ; Tue, 21 Jun 2011 08:25:59 -0700 (PDT) Received: by yie30 with SMTP id 30so3836453yie.31 for ; Tue, 21 Jun 2011 08:25:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6nrzmbTj+nYWwvrJF14OvRy0II9TQb0mJMZOU6mpvjg=; b=GDwJ1qpt/I+KX9xMryJzThlr/h7mKF+1v36lHrhrxv6N6HFrUYFjngh1NoJq1Sco9H ufrMwx7YibWRhq1uPUIT9X3XepSbSPWKztlQjRA+/y73WXRUQ3n8Ntc6r6tqJm10nJNv 6O8MbevEKJDWzbPf0MBzr9Rnqr85WBA9BccgA= 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:content-transfer-encoding; b=XLujYLWCeIIfk6e4dT4QunhntnoKO7QYP8rYdhegsZ6cHjk6pujyfn9prrClI9JURZ 8cqG7VvY3mmIiVSzdeXwsczARn944wKB2K7nzjWrnTkemvRwxuFG5LU6oYzS57ESyJKx Cne7iDjEBhqpFkJxC547UxPiHoTjc59E3ZRgw= MIME-Version: 1.0 Received: by 10.151.118.2 with SMTP id v2mr7239067ybm.99.1308669947222; Tue, 21 Jun 2011 08:25:47 -0700 (PDT) Received: by 10.151.46.3 with HTTP; Tue, 21 Jun 2011 08:25:47 -0700 (PDT) In-Reply-To: <4DF6284E.3010208@cisco.com> References: <4DF6120C.3000109@bell-labs.com> <4DF6284E.3010208@cisco.com> Date: Tue, 21 Jun 2011 10:25:47 -0500 Message-ID: From: Alan Johnston To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] Reminder: WGLC in progress for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:26:00 -0000 Paul, Thanks for your review. See my comments below. - Alan - On Mon, Jun 13, 2011 at 10:10 AM, Paul Kyzivat wrote: > > On 6/13/2011 9:35 AM, Vijay K. Gurbani wrote: >> >> Folks: This is a reminder that we are in the middle of WGLC [1] >> for draft-ietf-cuss-sip-uui-reqs-02. >> >> The WGLC ends on June 17, 2011; so please get in your comments >> and feedback before that. I note that a fair number of people >> have already provided feedback. >> >> If you have not already done so, please do take a couple of >> minutes of your time to look over the draft [2]. > > OK, I just did a fresh review of the document. Its been awhile since I re= ad > it, and so the fresh view may have allowed me to see some things I hadn't > seen before: > > 3.3. =A0Redirection > > =A0 In this scenario, UUI is inserted by an application which utilizes a > =A0 SIP redirect server. =A0The UUI is then included in the INVITE sent b= y > =A0 the Originator to the Terminator. =A0In this case, the Originator doe= s > =A0 not necessarily need to support the UUI mechanism but does need to > =A0 support the SIP redirection mechanism used to include the UUI > =A0 information. =A0Two examples of UUI with redirection (transfer and > =A0 diversion) are defined in [ANSII] and [ETSI]. > > The statement "In this case, the Originator does not necessarily need to > support the UUI mechanism" is dubious at best. It either must understand = the > mechanism in order to make an informed choice of whether to pass the UUI > information from the 3xx to the new INVITE, or else it must blindly pass = all > URI header parameters that it receives. (If that is what the mechanism us= es. > If not, its even more of a problem.) Doing *that* is very unwise and not > advocated by 3261. But it is the only way the Originator doesn't need to > understand the mechanism. Agreed, and this exact point is made in Section 3 of draft-ietf-cuss-sip-uui, which I think is the right place for that text. > > Or is this intended to mean that the *Originating application" need not k= now > about the mechanism as long as the originating UA understands it and > believes it to be sufficiently benign to allow passing from 3xx to result= ing > INVITE? No, this was not the intended meaning. > > =A0 REQ-9: The mechanism will allow proxies to remove a particular type > =A0 of UUI information from a request or response. > > =A0 REQ-10: The mechanism will provide the ability for a UA to discover > =A0 which types or application usages of UUI another UA understands or > =A0 supports. > > =A0 =A0 =A0The creation of a registry of application usages for the SIP U= UI > =A0 =A0 =A0mechanism is implied by this requirement. =A0For the ISDN Serv= ice, > =A0 =A0 =A0there could be value in utilizing the protocol discriminator, > =A0 =A0 =A0which is the first octet of the ISDN UUI information, for this > =A0 =A0 =A0purpose. > > I find no definition of any notion of "types" of UUI. Without such a > definition this requirement is meaningless. > > Is it assumed that "type" and "application usage" are synonyms? Is it > assumed that there is a relationship between types and/or application usa= ges > and protocol discriminators? > > IMO this needs to be nailed down to finalize the requirements. > > I *think* the intent is that "types" and "application usages" refer to th= e > same thing, and we should use one term rather than two. (I'd prefer > application usage.) Yes, they are the same thing, so we should use one term. I propose 'application usage'. > > And IMO ("based" on a very limited understanding of the use in ISDN) is t= hat > we ought to consider the various ISDN protocol discriminators to map onto > *some* of the possible "application usages". This will be a matter for our ISDN interworking draft. I do not think that ISDN protocol discriminators have any meaning outside of ISDN and provide no value in being mapped to SIP. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Thanks, >> >> [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html >> [2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt >> >> - vijay > > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Tue Jun 21 08:51:17 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E851311E80AE for ; Tue, 21 Jun 2011 08:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.457 X-Spam-Level: X-Spam-Status: No, score=-103.457 tagged_above=-999 required=5 tests=[AWL=-0.085, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vYg1VZQWCpOP for ; Tue, 21 Jun 2011 08:51:16 -0700 (PDT) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7C71311E807E for ; Tue, 21 Jun 2011 08:51:16 -0700 (PDT) Received: by yxt33 with SMTP id 33so4394619yxt.31 for ; Tue, 21 Jun 2011 08:51:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jCd6hwsAo6qfc/3yrASKGYeDeK6eiw61OvU13hzUadk=; b=rTS6yF2DWXKYuYybDXaYbqhxVkcsoWE6K2BJCx1dvWHmLOdPhakIk8l8XXIxxXsZxt 56lMy2/WQDmUMRokV07/PfiaiiueFNv48NbmAOZfhbtwilG8hp4TTDWxbIRIcipTtXdb DB92qfLMad+xksV5TylpmmAsnI09w7oJQNWGI= 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:content-transfer-encoding; b=T+zUWP1i4WrOEtM4RYRtZVMkmm8TQor89+5JZErxENXW87EsGFMn7nQiGZ2t0L9awa VrBaW2+fdsiCLEBMmIBC4SGIK+jGiiTA6PsKOjTy+DKcJkfy3X5/AageB84ne+C8fmGR jzHY1IfSKlyE07kpz0nH9cGQr0WdkyAXd7fWs= MIME-Version: 1.0 Received: by 10.150.132.4 with SMTP id f4mr2392112ybd.156.1308671475989; Tue, 21 Jun 2011 08:51:15 -0700 (PDT) Received: by 10.151.46.3 with HTTP; Tue, 21 Jun 2011 08:51:15 -0700 (PDT) In-Reply-To: References: <4DE4F7D9.3010904@bell-labs.com> Date: Tue, 21 Jun 2011 10:51:15 -0500 Message-ID: From: Alan Johnston To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 15:51:18 -0000 John, Thanks for your comments. We should have some more discussion about security now as it may save us time when working on the mechanism. See my comments below marked AJ> - Alan - On Fri, Jun 17, 2011 at 9:03 AM, Elwell, John wrote: > I don't think this is quite ready to go yet, mainly because I don't think= the security story stands scrutiny. See comments 13 and 14 below. In parti= cular, knowing that we are choosing a mechanism based on a header field, en= d-to-end privacy and integrity protection does not seem to be feasible. AJ> Well, it depends if you think S/MIME is feasible. As described in RFC 3261, it is possible, using S/MIME to get end-to-end privacy and integrity protection even for a header field. Of course, in the process, the header is transported as a body. This is far from ideal, and the lack of S/MIME deployment with SIP in any case makes this more theoretical than not. However, it is an option that could be used in certain deployments where this made sense. Given that we probably need to accept hop-by-hop security, this will probably be OK within a trusted domain (where intermediaries are trusted), but falls apart when leaving that domain. AJ> I agree that the real usage of this mechanism will use (and need) hop-by-hop security within a trust domain. For example, in the redirect case, if the 3xx sends UUI all the way back to the originating UA in another domain, it could disclose sensitive information, or the UUI could be subject to modification by that other domain before including in the new INVITE request. In practice, of course, this would all be taken care of by an SBC, which would perform the redirection without the UUI leaving the domain. Similarly for REFER. I think we need proper discussion of these aspects and a reformulation of the relevan > =A0t requirements. AJ> So you would like a discussion of this most likely deployed security model in this draft? I think that might be a good idea. > > Specific comments: > > 1. The Abstract is too long. Some of the stuff about examples could be le= ft for the main document. AJ> OK. > > 2. Also in Abstract: > "A common example in another protocol is the ISDN User to User > =A0 Information Service." > Since the previous sentences are talking about applications, it seems to = imply ISDN U-U is an application, which isn't correct, so shouldn't portray= this as an example application, but as a corresponding mechanism in anothe= r protocol. AJ> Agreed. > > 3. Section 1: > "It is > =A0 assumed that the application is running in both the originator of the > =A0 session and the terminator of the session. =A0That is, the applicatio= n > =A0 interacts with the User Agent Client (UAC) and User Agent Server > =A0 (UAS)." > This seems to imply a fixed relationship between session originator and U= AC and between session terminator and UAS, which is not correct - UAC and U= AS relate to transactions, not sessions. Note that we are not concerned onl= y with the initial INVITE transaction. AJ> Right - I'll fix this. > > 4. Section 2: > I don't think the document uses RFC 2119 terms. AJ> You are correct. I can remove this section. > > 5. Section 3.2: > Figure 2 looks identical to figure 1 - could just reference figure 1 inst= ead or enhance figure 2 to show what is different. > AJ> Yes, we can do that. > 6. Section 3.3: > "Instead, these slight > =A0 differences between the SIP UUI service and the ISDN service need to > =A0 be carefully noted and discussed in an interworking specification." > This implies somebody will write an interworking specification. I think i= t would suffice to say: > "Instead, these slight > =A0 differences between the SIP UUI service and the ISDN service need to > =A0 be carefully noted and taken into account when considering interworki= ng." > AJ> Well, an interworking specification is a milestone on our charter and we have an individual draft written, so I think it is pretty safe that we will have this specification. > 7. Section 3.3: > "If the Redirect Server is not in the same administrative domain as > =A0 the Terminator, the Redirect Server must not remove or replace any > =A0 UUI in the initial INVITE. =A0In Figure 3, this means that if F1 > =A0 included UUI, the Redirect Server could not modify or replace the UUI > =A0 in F2. =A0However, if the Redirect Server and the Terminator are part > =A0 of the same administrative domain, they may have a policy allowing > =A0 the Redirect Server to modify or rewrite UUI information. =A0In fact, > =A0 many UUI uses within an Enterprise rely on this feature to work today > =A0 in ISDN." > This sounds more like something for the mechanism document - is it really= needed in this document? > AJ> It is not needed here, so I can move it to the mechanism draft. > 8. Section 3.4: > "such as out-of-dialog REFER > =A0 call control" > What is "REFER call control"? AJ> Call control using REFER - I'll clarify the sentence. > > 9. Section 4: > "This section discusses the requirements for the transport of call > =A0 control related user to user information (UUI)." > I think it "states" the requirements. Similar at the end of section 1. AJ> OK > > 10. Section 4: > " REQ-8: The mechanism will allow a UAC to learn or request that a UAS > =A0 understands the call control UUI mechanism and permit routing of > =A0 requests based on this." > Should these be two separate requirements? Or are we happy for the mechan= ism just to satisfy either one of these (as implied by "learn or request"? AJ> I think they are separate requirements. > > 11. Section 4: > " REQ-10: The mechanism will provide the ability for a UA to discover > =A0 which types or application usages of UUI another UA understands or > =A0 supports." > This sounds like it is asking for a sort of OPTIONS request to see whethe= r application foo is supported, prior to sending UUI for foo in the INVITE = request. If that is not the intention, I think it needs some rewording. AJ> Yes, this is the intention. The ISDN protocol discriminator indicates that a particular piece of UUI being transmitted is for application foo - I don't recall that it does more than that. > AJ> Right - in some cases, we may do better than the ISDN. > 12. Section 4: > "REQ-13: The mechanism will allow integrity protection of the UUI. > This allows the UAS to be able to know that the UUI has not been > =A0 =A0 =A0modified or tampered with by intermediaries." > This seems to suggest S/MIME? But I am not even sure that S/MIME would co= ver the redirect or refer cases. Note that TLS and SIPS do not satisfy this= requirement as stated. AJ> In the case of redirect or refer, the UUI would be signed by the redirector or referer. Again, real world usages would not use S/MIME. > > 13. Section 4: > "REQ-14: The mechanism will allow end-to-end privacy of the UUI." > Again it seems to imply S/MIME. Yes, it could be achieved by some sort of= encryption mechanism used by the application, but that is always possible.= We don't need a requirement on the mechanism to achieve that, unless the m= echanism is to specify such an encryption mechanism for applications. As fo= r an RFC 3323-like privacy mechanism, this would not provide end-to-end pri= vacy, because intermediaries have access to the information. AJ> Yes, S/MIME would be required. I do expect applications that transport sensitive information in UUI to do their own encryption. > > 14. QSIG is mentioned, so there should be a reference to ECMA-143 (the ba= sic QSIG standard). However, note that QSIG does not have a UUI standard, s= o any QSIG interworking will be with a proprietary extension. > AJ> I'll add it. > > Nits: > - "a new SIP extensions" > - Could do with a terminology consistency check, e.g., I think "terminato= r" and "terminating UA" refer to the same thing. > - Use "INVITE request" rather than "INVITE", in cases where INVITE reques= t (as opposed to INVITE transaction, INVITE method or INVITE response) is i= ntended. > - "The UUI could be used to > =A0 lookup information rendered to the agent at the time of call > =A0 answering." Change "rendered to" to "for rendering to". Also I would = delete "at the time of call answer", since it could be rendered prior to an= swer. > - "SIP messages covered by this include 3xx responses to INVITE and > =A0 =A0 =A0REFER requests." This is ambiguous - it could be interpreted a= s covering 3xx responses to REFER requests. I think it should say: > "SIP messages covered by this include REFER requests and 3xx responses to= INVITE requests." > > John > >> -----Original Message----- >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On >> Behalf Of Vijay K. Gurbani >> Sent: 31 May 2011 15:15 >> To: cuss@ietf.org >> Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >> >> Folks: Enrico and I will like to issue a WGLC for the CUSS >> Problem Statement and Requirements draft as follows: >> >> >> =A0 =A0Draft: draft-ietf-cuss-sip-uui-reqs-02.txt >> =A0 =A0WGLC period: May 31, 2011 - June 17, 2011 >> >> The authors believe that they have addressed all open issues. >> Please go through the latest version of the draft [1] and >> make sure that there aren't any other outstanding issues. >> >> [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt >> >> Thanks, >> >> - vijay >> -- >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) >> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com >> Web: =A0 http://ect.bell-labs.com/who/vkg/ >> _______________________________________________ >> cuss mailing list >> cuss@ietf.org >> https://www.ietf.org/mailman/listinfo/cuss >> > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Tue Jun 21 09:58:40 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1728011E82AA for ; Tue, 21 Jun 2011 09:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.372 X-Spam-Level: X-Spam-Status: No, score=-103.372 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zJ+WyqBrNxyt for ; Tue, 21 Jun 2011 09:58:39 -0700 (PDT) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3245D11E82A5 for ; Tue, 21 Jun 2011 09:58:39 -0700 (PDT) Received: by gwb20 with SMTP id 20so1521007gwb.31 for ; Tue, 21 Jun 2011 09:58:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=qQiweYikvI2Q2PfJpgpONKYVKBtotzMlSlZB6t+U+Ho=; b=tFBzaUuJm1/AWCl2CYxwY2qFtL7N2VqrXtbmeqA+PzuiZAl6l76fo5NzMwZd6YJkKg PG6l54NahPEeNErAThpzqtapHoK2Yghqfm3g/rwo3UHv0jW5k41cu6mZNCejCdvnFnue lvUX5GkEadpDqeMs5HzyJKHqwPwJMezpaImsw= 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:content-transfer-encoding; b=cs+BJHH3S0mHdA+MFfWsJ2dmdGKT5MUrL0xmrT83dftEp8jzgZ1KiB5cAfru/AIDNA CYtmWxAG+dwEh6kq4fEDf7QzLk+AGbWxrplLO+iBo/b/zWqHBrvEwNWWsaraMF9ERGYm BnBR6PcQMHOEy6Y8KnqP73hl/CjMTaXuY+1Dc= MIME-Version: 1.0 Received: by 10.151.92.1 with SMTP id u1mr7036755ybl.384.1308675516708; Tue, 21 Jun 2011 09:58:36 -0700 (PDT) Received: by 10.151.46.3 with HTTP; Tue, 21 Jun 2011 09:58:36 -0700 (PDT) In-Reply-To: References: <4DF6120C.3000109@bell-labs.com> Date: Tue, 21 Jun 2011 11:58:36 -0500 Message-ID: From: Alan Johnston To: "Schmidt, Christian 1. (NSN - DE/Munich)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: cuss@ietf.org Subject: Re: [cuss] Reminder: WGLC in progress fordraft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:58:40 -0000 Christian, Thanks for your comments on the draft. See my comments below. - Alan - On Wed, Jun 15, 2011 at 3:58 AM, Schmidt, Christian 1. (NSN - DE/Munich) wrote: > Hi, > > after minor clarifications and adjustments, the draft should be ready > for publication. > > Best Regards > Christian > > > General comment to the figures: > UUI information is mentioned only sporadic, it should be mentioned in > every message where UUI may be included. > Examples: 200 OK in all figures or INVITE (F1) in figure 3. You are suggesting that that the figures show UUI in every place where it could be present? I'm not sure that will make things clearer. > > > Figure 4: The flow sequence seems to be wrong. I would propose: F1, F2, > F5, F3, F4, F6, F8, F9, F7. E.g. Notify trying F3 should not be sent > before INVITE F5. It doesn't really matter - F3 and F5 can be sent at the same time. I'm using the sequence that is usually used - see the figures in RFC 3515 for example. > > > Redirection: > =A0 "If the Redirect Server is not in the same administrative domain as > =A0 the Terminator, the Redirect Server must not remove or replace any > =A0 UUI in the initial INVITE. =A0In Figure 3, this means that if F1 > =A0 included UUI, the Redirect Server could not modify or replace the UUI > =A0 in F2. =A0However, if the Redirect Server and the Terminator are part > =A0 of the same administrative domain, they may have a policy allowing > =A0 the Redirect Server to modify or rewrite UUI information. =A0In fact, > =A0 many UUI uses within an Enterprise rely on this feature to work today > =A0 in ISDN." > > This section is somehow confusing. > What should the Redirect Server do with the UUI? Remove? Replace? > Rewrite? Modify? > What is the influence to REQ-12? Should there be 2 entries, one entry > for the entity that inserted the UUI and one entry for the entity that > modify/rewrite/replace the UUI? > If this section is relevant for the requirements, please extend them > accordingly, e.g. REQ-12. > If this section is not relevant for the requirements, I would propose to > delete the section. It seems not to be relevant for the understanding of > the use case. > I will move this text to the mechanism draft and clarify it. > > REQ-1: > =A0 =A0 =A0"SIP messages covered by this include INVITE requests and end-= to- > =A0 =A0 =A0end responses to the INVITE, which includes 18x and 200 > responses." > > What about the 302 Moved Reply in the Redirection use case? Should we > mention this > Response here as well? > > Good catch! I will add in 3xx here. > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of > ext Vijay K. Gurbani > Sent: Monday, June 13, 2011 3:35 PM > To: cuss@ietf.org > Subject: [cuss] Reminder: WGLC in progress > fordraft-ietf-cuss-sip-uui-reqs-02 > > Folks: This is a reminder that we are in the middle of WGLC [1] > for draft-ietf-cuss-sip-uui-reqs-02. > > The WGLC ends on June 17, 2011; so please get in your comments > and feedback before that. =A0I note that a fair number of people > have already provided feedback. > > If you have not already done so, please do take a couple of > minutes of your time to look over the draft [2]. > > Thanks, > > [1] http://www.ietf.org/mail-archive/web/cuss/current/msg00190.html > [2] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: =A0 http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From alan.b.johnston@gmail.com Tue Jun 21 09:59:29 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976791F0C38 for ; Tue, 21 Jun 2011 09:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.44 X-Spam-Level: X-Spam-Status: No, score=-103.44 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U4qZ7VfP9YDa for ; Tue, 21 Jun 2011 09:59:28 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by ietfa.amsl.com (Postfix) with ESMTP id 90D251F0C37 for ; Tue, 21 Jun 2011 09:59:28 -0700 (PDT) Received: by gxk19 with SMTP id 19so3879372gxk.31 for ; Tue, 21 Jun 2011 09:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=5xGfv0BrUGk/14rX+BuJjx9lImXvVkCIPlW4NAG0jds=; b=oFfMF3VUSLlabB4QiPjfH4OyG3LV7VaJ/rNFWlt0pJHhq4ytmicKJelGTwhHtuLsYy kYebxF2MNEJ053j0aHTCyX7KCg2LzLDppw1FR7wv2GYr4jTZlRhn8YjUxyFVNiPr0FOZ Oqnk3APuOp2LUp+fwhJ5mRbEDbSg2xqPn5rSQ= 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:content-transfer-encoding; b=eoEezOPumIFLdly0akm6USS2Ah9Av4JlMDdC2+0ZXnhRDfOH6XYQ2XEswNQIjJegcE IAl1v20pDU8XxpUI45SBuP3V/4NxHTircXny/JSNTZHACZ6wC3nfEUNGcdrrE8zun3L7 6PcVwKEiTCwGCTejvlY6UvJnheqejIC/YFP24= MIME-Version: 1.0 Received: by 10.150.197.19 with SMTP id u19mr7774807ybf.327.1308675566839; Tue, 21 Jun 2011 09:59:26 -0700 (PDT) Received: by 10.151.46.3 with HTTP; Tue, 21 Jun 2011 09:59:26 -0700 (PDT) In-Reply-To: <54633A5E61DC84429CB9FE3D9143C72104C9D0C0@MBX.dialogic.com> References: <4DE4F7D9.3010904@bell-labs.com> <54633A5E61DC84429CB9FE3D9143C72104C9D0C0@MBX.dialogic.com> Date: Tue, 21 Jun 2011 11:59:26 -0500 Message-ID: From: Alan Johnston To: James Rafferty Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "cuss@ietf.org" Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 16:59:29 -0000 James, Thanks for the review. We'll fix it. - Alan - On Fri, Jun 10, 2011 at 4:24 PM, James Rafferty wrote: > Hi, > > I've reviewed the document and think it's in good shape for publication. > > I have one small editorial comment on the last sentence of section 3.3 > > The sentence currently reads: > > " The ability to maintain UUI in these scenarios is critical." > > I'd suggest -- =A0"The ability to pass along UUI in these call redirectio= n scenarios is critical." -- since the meaning of "maintain" in this contex= t isn't totally clear. > > James > > > > > > -----Original Message----- > From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On Behalf Of V= ijay K. Gurbani > Sent: Tuesday, May 31, 2011 10:15 AM > To: cuss@ietf.org > Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 > > Folks: Enrico and I will like to issue a WGLC for the CUSS Problem Statem= ent and Requirements draft as follows: > > > =A0 Draft: draft-ietf-cuss-sip-uui-reqs-02.txt > =A0 WGLC period: May 31, 2011 - June 17, 2011 > > The authors believe that they have addressed all open issues. > Please go through the latest version of the draft [1] and make sure that = there aren't any other outstanding issues. > > [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt > > Thanks, > > - vijay > -- > Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com > Web: =A0 http://ect.bell-labs.com/who/vkg/ > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > _______________________________________________ > cuss mailing list > cuss@ietf.org > https://www.ietf.org/mailman/listinfo/cuss > From john.elwell@siemens-enterprise.com Tue Jun 21 11:44:58 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB18811E817C for ; Tue, 21 Jun 2011 11:44:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.432 X-Spam-Level: X-Spam-Status: No, score=-106.432 tagged_above=-999 required=5 tests=[AWL=-0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggv0KvJtiQDw for ; Tue, 21 Jun 2011 11:44:57 -0700 (PDT) Received: from mail216.messagelabs.com (mail216.messagelabs.com [85.158.143.99]) by ietfa.amsl.com (Postfix) with SMTP id E124611E808A for ; Tue, 21 Jun 2011 11:44:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: john.elwell@siemens-enterprise.com X-Msg-Ref: server-11.tower-216.messagelabs.com!1308681895!1441324!1 X-StarScan-Version: 6.2.17; banners=-,-,- X-Originating-IP: [62.134.46.10] Received: (qmail 7512 invoked from network); 21 Jun 2011 18:44:55 -0000 Received: from unknown (HELO senmx12-mx) (62.134.46.10) by server-11.tower-216.messagelabs.com with SMTP; 21 Jun 2011 18:44:55 -0000 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 4368B23F03E2; Tue, 21 Jun 2011 20:44:55 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 21 Jun 2011 20:44:55 +0200 From: "Elwell, John" To: Alan Johnston Date: Tue, 21 Jun 2011 20:44:54 +0200 Thread-Topic: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 Thread-Index: AcwwKw6ASIf49aGnRZqW904yfSNLXgAGCfwA Message-ID: References: <4DE4F7D9.3010904@bell-labs.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 Cc: "cuss@ietf.org" Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jun 2011 18:44:59 -0000 Alan, I pretty much agree with your responses and will wait to see how the next v= ersion looks, particularly the security discussion. John =20 > -----Original Message----- > From: Alan Johnston [mailto:alan.b.johnston@gmail.com]=20 > Sent: 21 June 2011 16:51 > To: Elwell, John > Cc: Vijay K. Gurbani; cuss@ietf.org > Subject: Re: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 >=20 > John, >=20 > Thanks for your comments. We should have some more discussion about > security now as it may save us time when working on the mechanism. > See my comments below marked AJ> >=20 > - Alan - >=20 > On Fri, Jun 17, 2011 at 9:03 AM, Elwell, John > wrote: > > I don't think this is quite ready to go yet, mainly because=20 > I don't think the security story stands scrutiny. See=20 > comments 13 and 14 below. In particular, knowing that we are=20 > choosing a mechanism based on a header field, end-to-end=20 > privacy and integrity protection does not seem to be feasible. >=20 > AJ> Well, it depends if you think S/MIME is feasible. As described in > RFC 3261, it is possible, using S/MIME to get end-to-end privacy and > integrity protection even for a header field. Of course, in the > process, the header is transported as a body. This is far from ideal, > and the lack of S/MIME deployment with SIP in any case makes this more > theoretical than not. However, it is an option that could be used in > certain deployments where this made sense. >=20 > Given that we probably need to accept hop-by-hop security, this will > probably be OK within a trusted domain (where intermediaries are > trusted), but falls apart when leaving that domain. >=20 > AJ> I agree that the real usage of this mechanism will use (and need) > hop-by-hop security within a trust domain. >=20 > For example, in the redirect case, if the 3xx sends UUI all the way > back to the originating UA in another domain, it could disclose > sensitive information, or the UUI could be subject to modification by > that other domain before including in the new INVITE request. In > practice, of course, this would all be taken care of by an SBC, which > would perform the redirection without the UUI leaving the domain. > Similarly for REFER. I think we need proper discussion of these > aspects and a reformulation of the relevan > > =A0t requirements. >=20 > AJ> So you would like a discussion of this most likely deployed > security model in this draft? I think that might be a good idea. >=20 > > > > Specific comments: > > > > 1. The Abstract is too long. Some of the stuff about=20 > examples could be left for the main document. >=20 > AJ> OK. >=20 > > > > 2. Also in Abstract: > > "A common example in another protocol is the ISDN User to User > > =A0 Information Service." > > Since the previous sentences are talking about=20 > applications, it seems to imply ISDN U-U is an application,=20 > which isn't correct, so shouldn't portray this as an example=20 > application, but as a corresponding mechanism in another protocol. >=20 > AJ> Agreed. >=20 > > > > 3. Section 1: > > "It is > > =A0 assumed that the application is running in both the=20 > originator of the > > =A0 session and the terminator of the session. =A0That is, the=20 > application > > =A0 interacts with the User Agent Client (UAC) and User Agent Server > > =A0 (UAS)." > > This seems to imply a fixed relationship between session=20 > originator and UAC and between session terminator and UAS,=20 > which is not correct - UAC and UAS relate to transactions,=20 > not sessions. Note that we are not concerned only with the=20 > initial INVITE transaction. >=20 > AJ> Right - I'll fix this. >=20 > > > > 4. Section 2: > > I don't think the document uses RFC 2119 terms. >=20 > AJ> You are correct. I can remove this section. >=20 > > > > 5. Section 3.2: > > Figure 2 looks identical to figure 1 - could just reference=20 > figure 1 instead or enhance figure 2 to show what is different. > > >=20 > AJ> Yes, we can do that. >=20 > > 6. Section 3.3: > > "Instead, these slight > > =A0 differences between the SIP UUI service and the ISDN=20 > service need to > > =A0 be carefully noted and discussed in an interworking=20 > specification." > > This implies somebody will write an interworking=20 > specification. I think it would suffice to say: > > "Instead, these slight > > =A0 differences between the SIP UUI service and the ISDN=20 > service need to > > =A0 be carefully noted and taken into account when=20 > considering interworking." > > >=20 > AJ> Well, an interworking specification is a milestone on our charter > and we have an individual draft written, so I think it is pretty safe > that we will have this specification. >=20 > > 7. Section 3.3: > > "If the Redirect Server is not in the same administrative domain as > > =A0 the Terminator, the Redirect Server must not remove or replace any > > =A0 UUI in the initial INVITE. =A0In Figure 3, this means that if F1 > > =A0 included UUI, the Redirect Server could not modify or=20 > replace the UUI > > =A0 in F2. =A0However, if the Redirect Server and the=20 > Terminator are part > > =A0 of the same administrative domain, they may have a policy allowing > > =A0 the Redirect Server to modify or rewrite UUI information.=20 > =A0In fact, > > =A0 many UUI uses within an Enterprise rely on this feature=20 > to work today > > =A0 in ISDN." > > This sounds more like something for the mechanism document=20 > - is it really needed in this document? > > >=20 > AJ> It is not needed here, so I can move it to the mechanism draft. >=20 > > 8. Section 3.4: > > "such as out-of-dialog REFER > > =A0 call control" > > What is "REFER call control"? >=20 > AJ> Call control using REFER - I'll clarify the sentence. >=20 > > > > 9. Section 4: > > "This section discusses the requirements for the transport of call > > =A0 control related user to user information (UUI)." > > I think it "states" the requirements. Similar at the end of=20 > section 1. >=20 > AJ> OK >=20 > > > > 10. Section 4: > > " REQ-8: The mechanism will allow a UAC to learn or request=20 > that a UAS > > =A0 understands the call control UUI mechanism and permit routing of > > =A0 requests based on this." > > Should these be two separate requirements? Or are we happy=20 > for the mechanism just to satisfy either one of these (as=20 > implied by "learn or request"? >=20 > AJ> I think they are separate requirements. >=20 > > > > 11. Section 4: > > " REQ-10: The mechanism will provide the ability for a UA=20 > to discover > > =A0 which types or application usages of UUI another UA understands or > > =A0 supports." > > This sounds like it is asking for a sort of OPTIONS request=20 > to see whether application foo is supported, prior to sending=20 > UUI for foo in the INVITE request. If that is not the=20 > intention, I think it needs some rewording. >=20 > AJ> Yes, this is the intention. >=20 > The ISDN protocol discriminator indicates that a particular piece of > UUI being transmitted is for application foo - I don't recall that it > does more than that. > > >=20 > AJ> Right - in some cases, we may do better than the ISDN. >=20 > > 12. Section 4: > > "REQ-13: The mechanism will allow integrity protection of the UUI. > > This allows the UAS to be able to know that the UUI has not been > > =A0 =A0 =A0modified or tampered with by intermediaries." > > This seems to suggest S/MIME? But I am not even sure that=20 > S/MIME would cover the redirect or refer cases. Note that TLS=20 > and SIPS do not satisfy this requirement as stated. >=20 > AJ> In the case of redirect or refer, the UUI would be signed by the > redirector or referer. Again, real world usages would not use S/MIME. >=20 > > > > 13. Section 4: > > "REQ-14: The mechanism will allow end-to-end privacy of the UUI." > > Again it seems to imply S/MIME. Yes, it could be achieved=20 > by some sort of encryption mechanism used by the application,=20 > but that is always possible. We don't need a requirement on=20 > the mechanism to achieve that, unless the mechanism is to=20 > specify such an encryption mechanism for applications. As for=20 > an RFC 3323-like privacy mechanism, this would not provide=20 > end-to-end privacy, because intermediaries have access to the=20 > information. >=20 > AJ> Yes, S/MIME would be required. I do expect applications that > transport sensitive information in UUI to do their own encryption. >=20 > > > > 14. QSIG is mentioned, so there should be a reference to=20 > ECMA-143 (the basic QSIG standard). However, note that QSIG=20 > does not have a UUI standard, so any QSIG interworking will=20 > be with a proprietary extension. > > >=20 > AJ> I'll add it. >=20 >=20 > > > > Nits: > > - "a new SIP extensions" > > - Could do with a terminology consistency check, e.g., I=20 > think "terminator" and "terminating UA" refer to the same thing. > > - Use "INVITE request" rather than "INVITE", in cases where=20 > INVITE request (as opposed to INVITE transaction, INVITE=20 > method or INVITE response) is intended. > > - "The UUI could be used to > > =A0 lookup information rendered to the agent at the time of call > > =A0 answering." Change "rendered to" to "for rendering to".=20 > Also I would delete "at the time of call answer", since it=20 > could be rendered prior to answer. > > - "SIP messages covered by this include 3xx responses to INVITE and > > =A0 =A0 =A0REFER requests." This is ambiguous - it could be=20 > interpreted as covering 3xx responses to REFER requests. I=20 > think it should say: > > "SIP messages covered by this include REFER requests and=20 > 3xx responses to INVITE requests." > > > > John > > > >> -----Original Message----- > >> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On > >> Behalf Of Vijay K. Gurbani > >> Sent: 31 May 2011 15:15 > >> To: cuss@ietf.org > >> Subject: [cuss] WGLC for draft-ietf-cuss-sip-uui-reqs-02 > >> > >> Folks: Enrico and I will like to issue a WGLC for the CUSS > >> Problem Statement and Requirements draft as follows: > >> > >> > >> =A0 =A0Draft: draft-ietf-cuss-sip-uui-reqs-02.txt > >> =A0 =A0WGLC period: May 31, 2011 - June 17, 2011 > >> > >> The authors believe that they have addressed all open issues. > >> Please go through the latest version of the draft [1] and > >> make sure that there aren't any other outstanding issues. > >> > >> [1] http://www.ietf.org/id/draft-ietf-cuss-sip-uui-reqs-02.txt > >> > >> Thanks, > >> > >> - vijay > >> -- > >> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent > >> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) > >> Email: vkg@{bell-labs.com,acm.org} /=20 > vijay.gurbani@alcatel-lucent.com > >> Web: =A0 http://ect.bell-labs.com/who/vkg/ > >> _______________________________________________ > >> cuss mailing list > >> cuss@ietf.org > >> https://www.ietf.org/mailman/listinfo/cuss > >> > > _______________________________________________ > > cuss mailing list > > cuss@ietf.org > > https://www.ietf.org/mailman/listinfo/cuss > > > = From vkg@bell-labs.com Wed Jun 22 08:43:41 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0355711E8131 for ; Wed, 22 Jun 2011 08:43:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.477 X-Spam-Level: X-Spam-Status: No, score=-106.477 tagged_above=-999 required=5 tests=[AWL=-0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CCyHwM8E2lft for ; Wed, 22 Jun 2011 08:43:36 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0E311E8105 for ; Wed, 22 Jun 2011 08:43:36 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p5MFh5ms014582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 22 Jun 2011 10:43:05 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5MFh5Gm019775 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 22 Jun 2011 10:43:05 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5MFh4tV013218; Wed, 22 Jun 2011 10:43:05 -0500 (CDT) Message-ID: <4E020DBD.6080407@bell-labs.com> Date: Wed, 22 Jun 2011 10:43:57 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] WGLC ended for draft-ietf-cuss-sip-uui-reqs-02 X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jun 2011 15:43:41 -0000 Folks: The WGLC for draft-ietf-cuss-sip-uui-reqs-02 ended last week (Jun-17). A note of thanks to all of you who provided comments on the draft. Alan is in the process of revising the draft to address the comments raised during WGLC. As soon as the updated draft is submitted and the changes okay'd by all the list members that had substantive, non-editorial comments, we'll move the draft ahead to IESG. This now leaves us with adopting a draft for the last deliverable on the charter. We will start that discussion in a separate thread. Thank you, Vijay K. Gurbani and Enrico Marocco From vkg@bell-labs.com Sun Jun 26 17:57:20 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21DD421F8586 for ; Sun, 26 Jun 2011 17:57:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F5IHF+CcXI0v for ; Sun, 26 Jun 2011 17:57:19 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 088B621F8557 for ; Sun, 26 Jun 2011 17:56:53 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p5R0DJdO026689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Sun, 26 Jun 2011 19:13:19 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5R0DJwZ000399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Sun, 26 Jun 2011 19:13:19 -0500 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.34.184]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5R0DIUO020358 for ; Sun, 26 Jun 2011 19:13:18 -0500 (CDT) Message-ID: <4E07CB59.1060805@bell-labs.com> Date: Sun, 26 Jun 2011 19:14:17 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Subject: [cuss] Fwd: Please help the Nomcom X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Jun 2011 00:57:20 -0000 Folks: Please consider volunteering for NomCom. It is an excellent way to serve the larger IETF community. Thanks, -------- Original Message -------- Subject: Please help the Nomcom Date: Fri, 24 Jun 2011 11:35:13 -0700 (PDT) From: NomCom Chair To: Working Group Chairs Hi WG chairs, We have had a good response to the first call for volunteers but the rate at which new volunteers are coming in is slowing down. The Nomcom process is best served by a large pool of volunteers drawn from a wide spectrum of IETF attendees. Where else would we find this wide spectrum if not in the WG mailing lists. I would really appreciate it if you can forward the message onto your working group mailing lists. The latest volunteer status and the second call for volunteers can be found at https://datatracker.ietf.org/ann/nomcom/2964/ Thanks in advance for your help. Suresh Krishnan Nomcom Chair 2011-2012 Email: nomcom-chair@ietf.org, suresh.krishnan@ericsson.com - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ From vkg@bell-labs.com Wed Jun 29 05:54:26 2011 Return-Path: X-Original-To: cuss@ietfa.amsl.com Delivered-To: cuss@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48F8511E8070 for ; Wed, 29 Jun 2011 05:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EMUAaiAXfwCB for ; Wed, 29 Jun 2011 05:54:24 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3ED1A22801A for ; Wed, 29 Jun 2011 05:54:23 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p5TCsMGq027724 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 29 Jun 2011 07:54:22 -0500 (CDT) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p5TCsL2E017763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 29 Jun 2011 07:54:21 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p5TCsKVn012359 for ; Wed, 29 Jun 2011 07:54:21 -0500 (CDT) Message-ID: <4E0B20BC.2060904@bell-labs.com> Date: Wed, 29 Jun 2011 07:55:24 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.17) Gecko/20110428 Fedora/3.1.10-1.fc14 Lightning/1.0b2 Thunderbird/3.1.10 MIME-Version: 1.0 To: cuss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [cuss] Agenda requests for Quebec City X-BeenThere: cuss@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: "Call Control UUI for SIP \(cuss\) working group discussion list" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Jun 2011 12:54:26 -0000 Folks: We are having a face-to-face in Quebec City. Those of you who want agenda time, please send an email to me and Enrico to that effect by Monday, July 11, indicating the length of the session and the topic. We have been tentatively assigned the following session for CUSS in Quebec City: Wednesday, Afternoon Session I 1300-1500 Room Name: 202 As usual, nothing is final until we're actually holding the meeting. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/