From brian.rosen@neustar.biz Wed Jun 5 12:25:24 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 145CF21F9644 for ; Wed, 5 Jun 2013 12:25:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.156 X-Spam-Level: X-Spam-Status: No, score=-6.156 tagged_above=-999 required=5 tests=[AWL=-0.111, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRtSKgrTKoPb for ; Wed, 5 Jun 2013 12:25:18 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id DAB1521F8263 for ; Wed, 5 Jun 2013 12:25:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1370460804; x=1685817504; q=dns/txt; h=From:Subject:Date:Message-ID:Content-Language: Content-Type; bh=h14oDegbi/bq9nfMI8XX94CrFZbJbsDDhWX/niy4R3I=; b=jxmvzRy1YsqAg72wMGE1QbyUooId1yGwd2UapoA/TzSuRlzzN8TNccCYi7H6N5 parDK3imfwYEpOqTlvameMKA== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.25833469; Wed, 05 Jun 2013 15:33:23 -0400 Received: from STNTEXCHCASHT05.cis.neustar.com (10.31.15.157) by STNTEXCHHT03.cis.neustar.com (10.31.13.242) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 5 Jun 2013 15:25:15 -0400 Received: from stntexmb12.cis.neustar.com ([169.254.2.76]) by STNTEXCHCASHT05.cis.neustar.com ([::1]) with mapi id 14.02.0247.003; Wed, 5 Jun 2013 15:25:14 -0400 From: "Rosen, Brian" To: DISPATCH list Thread-Topic: New effort on source identity in SIP to reduce robocalling, swatting and vishing Thread-Index: AQHOYiJn8hjy43ice0SF6YtNUfYN0Q== Date: Wed, 5 Jun 2013 19:25:14 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.33.193.6] x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: tieNYCSY9p0zz2mQnnFmkg== Content-Type: multipart/alternative; boundary="_000_F35FF4D8DABE4D6ABABC178A581EB33Dneustarbiz_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 05 Jun 2013 12:29:33 -0700 Subject: [dispatch] New effort on source identity in SIP to reduce robocalling, swatting and vishing X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jun 2013 19:25:24 -0000 --_000_F35FF4D8DABE4D6ABABC178A581EB33Dneustarbiz_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable We have started a new effort to reduce robocalling, swatting and vishing in= a SIP network following the ideas presented by Henning Schulzrinne in his = presentation at IETF 86 Orlando and the recent SIPNOC. Fundamentally, we p= lan to minimize the ability to spoof the caller's id. We have created a n= ew ietf list, stir@ietf.org, where stir stands for "S= ecure Telephone Identity Revisited". Our emphasis in this effort is deployable solutions that can significantly = reduce problems in a year or two, not solutions that take a revolution in h= ow service provider and enterprises deploy SIP networks. For that reason, = we are particularly interested in getting active participation by as many S= IP service providers as possible, as well as the vendors that serve them. Some discussion has been ongoing among a group of us, and a meeting was hel= d last week to see if we had enough common vision to initiate an IETF effor= t we thought would actually get deployed. So if you get on the list, you w= ill see discussion on specific points already underway. If you are interested in working on this effort, or want to stay informed, = you can subscribe by visiting: https://www.ietf.org/mailman/listinfo/stir We hope to arrange a session in Berlin, details will be forthcoming. Brian --_000_F35FF4D8DABE4D6ABABC178A581EB33Dneustarbiz_ Content-Type: text/html; charset="us-ascii" Content-ID: <8904DEE89E7037479BE97ECBFDB03FD0@neustar.biz> Content-Transfer-Encoding: quoted-printable We have started a new effort to reduce robocalling, swatting and vishing in= a SIP network following the ideas presented by Henning Schulzrinne in his = presentation at IETF 86 Orlando and the recent SIPNOC.  Fundamentally,= we plan to minimize the ability to spoof the caller's id.   We have created a new ietf list, stir@ietf.org, where stir stands for "Secure Telephone Identity Re= visited".    

Our emphasis in this effort is deployable solutions that can significa= ntly reduce problems in a year or two, not solutions that take a revolution= in how service provider and enterprises deploy SIP networks.  For tha= t reason, we are particularly interested in getting active participation by as many SIP service providers as possib= le, as well as the vendors that serve them.

Some discussion has been ongoing among a group of us, and a meeting wa= s held last week to see if we had enough common vision to initiate an IETF = effort we thought would actually get deployed.  So if you get on the l= ist, you will see discussion on specific points already underway. 

If you are interested in working on this effort, or want to stay infor= med, you can subscribe by visiting:

We hope to arrange a session in Berlin, details will be forthcoming.

Brian
--_000_F35FF4D8DABE4D6ABABC178A581EB33Dneustarbiz_-- From carl_klatsky@cable.comcast.com Thu Jun 6 09:56:31 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D152521F9A41 for ; Thu, 6 Jun 2013 09:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.064 X-Spam-Level: X-Spam-Status: No, score=-3.064 tagged_above=-999 required=5 tests=[AWL=-2.167, BAYES_00=-2.599, HOST_EQ_MODEMCABLE=1.368, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJ0wihyLa+26 for ; Thu, 6 Jun 2013 09:56:26 -0700 (PDT) Received: from cable.comcast.com (pacdcavout01.cable.comcast.com [69.241.43.119]) by ietfa.amsl.com (Postfix) with ESMTP id 8C02E21F9A2F for ; Thu, 6 Jun 2013 09:56:26 -0700 (PDT) Received: from ([24.40.56.115]) by pacdcavout01.cable.comcast.com with ESMTP id 97wm3m1.54572000; Thu, 06 Jun 2013 12:55:50 -0400 Received: from PACDCEXMB12.cable.comcast.com ([169.254.6.163]) by PACDCEXHUB02.cable.comcast.com ([fe80::492e:3fa1:c2ad:e04e%13]) with mapi id 14.02.0318.001; Thu, 6 Jun 2013 12:56:22 -0400 From: "Klatsky, Carl" To: "'dispatch@ietf.org'" Thread-Topic: Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: Ac5i1sUwgbY1hhy+RLyzNz7nciXYZg== Date: Thu, 6 Jun 2013 16:56:21 +0000 Message-ID: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.40.56.179] Content-Type: multipart/alternative; boundary="_000_6C15A6B88541034E912E94C2D8BC3E87B9A89D47PACDCEXMB12cabl_" MIME-Version: 1.0 Subject: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 16:56:31 -0000 --_000_6C15A6B88541034E912E94C2D8BC3E87B9A89D47PACDCEXMB12cabl_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, The draft noted below was just submitted. Soliciting feedback on the docum= ent and asking for direction on how proceed with this document. Thanks. Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 Revision: 00 Title: Interoperability Impacts of IPv6 Interworking w= ith Existing IPv4 SIP Implementations Creation date: 2013-06-04 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-klatsky-dispatch= -ipv6-impact-ipv4-00.txt Regards, Carl Klatsky --_000_6C15A6B88541034E912E94C2D8BC3E87B9A89D47PACDCEXMB12cabl_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

The draft noted below was just submitted.  Soli= citing feedback on the document and asking for direction on how proceed wit= h this document.  Thanks.

 

Filename:      &nbs= p;     draft-klatsky-dispatch-ipv6-impact-ipv4

Revision:      &nbs= p;       00

Title:       &= nbsp;           &nbs= p;  Interoperability Impacts of IPv6 Interworking with Existing IPv4 S= IP Implementations

Creation date:   2013-06-04<= /p>

Group:       &= nbsp;          Individual Subm= ission

Number of pages: 8

URL:       &nb= sp;     http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv4= -00.txt

 

 

 

Regards,

Carl Klatsky

--_000_6C15A6B88541034E912E94C2D8BC3E87B9A89D47PACDCEXMB12cabl_-- From pkyzivat@alum.mit.edu Thu Jun 6 10:35:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED3A521F9A9E for ; Thu, 6 Jun 2013 10:35:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.337 X-Spam-Level: X-Spam-Status: No, score=-0.337 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NaGXk4PPxHR5 for ; Thu, 6 Jun 2013 10:35:42 -0700 (PDT) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 2377E21F9AA1 for ; Thu, 6 Jun 2013 10:35:40 -0700 (PDT) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta14.westchester.pa.mail.comcast.net with comcast id l3io1l0050xGWP85E5bgHy; Thu, 06 Jun 2013 17:35:40 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id l5bg1l00W3ZTu2S3Y5bgGk; Thu, 06 Jun 2013 17:35:40 +0000 Message-ID: <51B0C86B.3080907@alum.mit.edu> Date: Thu, 06 Jun 2013 13:35:39 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370540140; bh=lD5lgVssVxWDcMwSNuQ4ezXSj31SxLwKWXhc7B5i6YM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=i09HIr1zzniV4SCLWpBEhuhPQH6/P511II/r8KHN1x/Si0V7EiwwWpNptiKXRnm6z hJE8bfGzThJBZh9GF6VS8dm+cDhtc+LHKt8R8CSw5q73+eB7e35PP9+s+JhIXnORGd j2WLCvCCZdE38mWuhYmmxRE03b+BdBEQA5VUsEqgn+a/FY0+q+zXPASZ2or0rtd//K LdOAXdrbQNl5FskhZx3O6RC+kbm0lWZu/3dl7dtaX8CzCT5XGHzSsWxF4L0r0Ej9Mk YnHScqgCaHNIDXB2YroLXnTgNGEPOmoq1HgcRHSq2sV9IhjOBFbR+DnmkXGv5Ew0lE cEQroW+GCsw3w== Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:35:47 -0000 Hi Carl, This seems like a useful draft. On a casual reading I only noticed one issue: In section 3.10 you say that a 488 should be returned. I suppose that is the worst case, but there may be less severe possibilities. For instance, if there are multiple m-lines with different addresses, it could simply reject those m-lines with addresses it can't use, and accept the m-lines it can use. The 488 then becomes a plausible response if all the m-lines need to be rejected. Thanks, Paul On 6/6/13 12:56 PM, Klatsky, Carl wrote: > Hi, > > The draft noted below was just submitted. Soliciting feedback on the > document and asking for direction on how proceed with this document. > Thanks. > > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > > Revision: 00 > > Title: Interoperability Impacts of IPv6 > Interworking with Existing IPv4 SIP Implementations > > Creation date: 2013-06-04 > > Group: Individual Submission > > Number of pages: 8 > > URL: > http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv4-00.txt > > Regards, > > Carl Klatsky > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From rifatyu@avaya.com Thu Jun 6 10:45:57 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E275921F99C3 for ; Thu, 6 Jun 2013 10:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id otj7epDMivwO for ; Thu, 6 Jun 2013 10:45:47 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 98A6D21F96FF for ; Thu, 6 Jun 2013 10:45:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgwFAEDKsFHGmAcF/2dsb2JhbABZDoJaITC/R3gWdIIjAQEBAQMBAQEPKDQXBAIBCA0BAwQBAQEKFAkHJwsUCQgBAQQBEggBGYdrAQufcZtpF48BOAaCdGEDngCKf4JRPoIn X-IronPort-AV: E=Sophos;i="4.87,816,1363147200"; d="scan'208";a="12174098" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 06 Jun 2013 13:45:45 -0400 Received: from unknown (HELO AZ-US1EXHC04.global.avaya.com) ([135.11.85.15]) by co300216-co-erhwest-out.avaya.com with ESMTP; 06 Jun 2013 13:44:30 -0400 Received: from AZ-US1EXMB01.global.avaya.com ([fe80::54fa:ed52:888e:7ca8]) by AZ-US1EXHC04.global.avaya.com ([135.11.85.15]) with mapi id 14.02.0328.009; Thu, 6 Jun 2013 13:45:44 -0400 From: "Shekh-Yusef, Rifaat (Rifaat)" To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: Ac5i1sUwgbY1hhy+RLyzNz7nciXYZgAJwR6AAAhLoOA= Date: Thu, 6 Jun 2013 17:45:43 +0000 Message-ID: References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <51B0C86B.3080907@alum.mit.edu> In-Reply-To: <51B0C86B.3080907@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.11.85.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2013 17:45:59 -0000 Yeah, that is correct. This section seems to have an older version of the t= ext. We will fix that in the next version of the document. Regards, Rifaat > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Paul Kyzivat > Sent: Thursday, June 06, 2013 1:36 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch- > ipv6-impact-ipv4 >=20 > Hi Carl, >=20 > This seems like a useful draft. > On a casual reading I only noticed one issue: >=20 > In section 3.10 you say that a 488 should be returned. > I suppose that is the worst case, but there may be less severe > possibilities. For instance, if there are multiple m-lines with > different addresses, it could simply reject those m-lines with addresses > it can't use, and accept the m-lines it can use. >=20 > The 488 then becomes a plausible response if all the m-lines need to be > rejected. >=20 > Thanks, > Paul >=20 >=20 > On 6/6/13 12:56 PM, Klatsky, Carl wrote: > > Hi, > > > > The draft noted below was just submitted. Soliciting feedback on the > > document and asking for direction on how proceed with this document. > > Thanks. > > > > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > > > > Revision: 00 > > > > Title: Interoperability Impacts of IPv6 > > Interworking with Existing IPv4 SIP Implementations > > > > Creation date: 2013-06-04 > > > > Group: Individual Submission > > > > Number of pages: 8 > > > > URL: > > http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6- > impact-ipv4-00.txt > > > > Regards, > > > > Carl Klatsky > > > > > > > > _______________________________________________ > > dispatch mailing list > > dispatch@ietf.org > > https://www.ietf.org/mailman/listinfo/dispatch > > >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Fri Jun 7 00:29:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4BCF21F8FA4 for ; Fri, 7 Jun 2013 00:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NMha1W+bEJcd for ; Fri, 7 Jun 2013 00:29:50 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 4549521F94F9 for ; Fri, 7 Jun 2013 00:29:46 -0700 (PDT) Received: from [IPv6:2001:16d8:cc57:1000::42:1001] (unknown [IPv6:2001:16d8:cc57:1000::42:1001]) by smtp7.webway.se (Postfix) with ESMTPA id 6A41493C2A1; Fri, 7 Jun 2013 07:29:44 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_DC3C314E-1A5E-49DC-87BE-CFE33B79476C" Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> Date: Fri, 7 Jun 2013 09:29:43 +0200 Message-Id: <4FFC250E-235C-43BC-9E7C-0A4E3D13CA4A@edvina.net> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> To: "Klatsky, Carl" X-Mailer: Apple Mail (2.1503) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 07:29:53 -0000 --Apple-Mail=_DC3C314E-1A5E-49DC-87BE-CFE33B79476C Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 6 jun 2013 kl. 18:56 skrev "Klatsky, Carl" = : > Hi, > =20 > The draft noted below was just submitted. Soliciting feedback on the = document and asking for direction on how proceed with this document. = Thanks. >=20 Additional background information: This document is one result of the = work done in the SIP Forum IPv6 working group. /O > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > Revision: 00 > Title: Interoperability Impacts of IPv6 = Interworking with Existing IPv4 SIP Implementations > Creation date: 2013-06-04 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv= 4-00.txt > =20 > =20 > =20 > Regards, > Carl Klatsky > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_DC3C314E-1A5E-49DC-87BE-CFE33B79476C Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
6 jun 2013 kl. = 18:56 skrev "Klatsky, Carl" <Carl_Klatsky@cable.comcast.= com>:

Hi,
The draft noted = below was just submitted.  Soliciting feedback on the document and = asking for direction on how proceed with this document.  = Thanks.
Creation = date:   2013-06-04
Number of pages: = 8
_____________________________________= __________
dispatch mailing list
dispatch@ietf.org
X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Jun 2013 21:02:38 -0000 The section 3.3 "IPv6 Address Handling in Contact Headers" will need = some work or further thought. For in-dialog requests: I assume (or = hope) that any true Proxy that switches a request from IPv4 to IPv6 is = session-stateful and inserts itself in a Record-Route in the = dialog-forming request, so that in-dialog requests from the UAS/UAC = always at least go through that Proxy. The hard part is what to do with = out-of-dialog requests trying to use the Contact... for example a REFER. = Sending the REFER to your outbound server, as the current text = recommends, won't help if that server is also only IPv4. Section 3.4. "IPv6 Address Handling in SDP Body" should just stipulate = it's in a received SDP offer, not that it is in an INVITE per se - since = the offer can come in a response to an offerless INVITE, or in an = in-dialog UPDATE, for example. In fact, I think theoretically it may be = possible to receive one in an SDP answer too, in one of the ICE = candidates form the far-end. (I don't recall if ICE advertised them all, = or limited itself to same address family) Section 3.6. "IPv6 Address Handling in 30x Redirect" says: The IPv4-only UAC should send its new request to its outbound SIP = server without generating an error upon receipt of a 30x message with IPv6 information. For "endpoint" UAC's such as phones I guess that's a reasonable = recommendation, but for gateways/app-servers and other UACs it's wrong - = I mean it's basically changing what 3xx is supposed to mean/do. If you = got a 3xx with a contact that you can't reach/access, then you can't = reach/access it - it's an error, for which you might have a local policy = for what to do next other than fail the request. Section 3.7. IPv6 Address Handling in REFER-based Transfer: ummm, this = text doesn't help. It basically just says "deal with it". :) -hadriel On Jun 6, 2013, at 12:56 PM, "Klatsky, Carl" = wrote: > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > Revision: 00 > Title: Interoperability Impacts of IPv6 = Interworking with Existing IPv4 SIP Implementations > Creation date: 2013-06-04 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv= 4-00.txt From worley@shell01.TheWorld.com Sat Jun 8 22:31:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B08B021F96DE for ; Sat, 8 Jun 2013 22:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLyJlFgvRr60 for ; Sat, 8 Jun 2013 22:31:11 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C924821F96D9 for ; Sat, 8 Jun 2013 22:31:10 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r595UAMA000916; Sun, 9 Jun 2013 01:30:12 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r595U9qu6391063; Sun, 9 Jun 2013 01:30:10 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r595U9xt6383905; Sun, 9 Jun 2013 01:30:09 -0400 (EDT) Date: Sun, 9 Jun 2013 01:30:09 -0400 (EDT) Message-Id: <201306090530.r595U9xt6383905@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Hadriel Kaplan In-reply-to: (hadriel.kaplan@oracle.com) References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> Cc: dispatch@ietf.org Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 05:31:16 -0000 > From: Hadriel Kaplan > > The section 3.3 "IPv6 Address Handling in Contact Headers" will need > some work or further thought. For in-dialog requests: I assume (or > hope) that any true Proxy that switches a request from IPv4 to IPv6 > is session-stateful and inserts itself in a Record-Route in the > dialog-forming request, so that in-dialog requests from the UAS/UAC > always at least go through that Proxy. Strictly speaking, a proxy can Record-Route itself without being session-stateful. The critical thing is that a proxy that switches address families used in addressing may have to Record-Route itself to ensure that in-dialog requests work. > The hard part is what to do > with out-of-dialog requests trying to use the Contact... for example > a REFER. Sending the REFER to your outbound server, as the current > text recommends, won't help if that server is also only IPv4. This seems to go back to the usual practical advice, "Use GRUUs as Contacts." But that only works if the registrar that issues the GRUUs is accessible via both IPv4 and IPv6. Dale From worley@shell01.TheWorld.com Sat Jun 8 22:31:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29EF21F96E1 for ; Sat, 8 Jun 2013 22:31:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.98 X-Spam-Level: X-Spam-Status: No, score=-2.98 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DTqtYUbdZfOc for ; Sat, 8 Jun 2013 22:31:11 -0700 (PDT) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C6AC921F96A9 for ; Sat, 8 Jun 2013 22:31:10 -0700 (PDT) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id r595UTYp001667; Sun, 9 Jun 2013 01:30:31 -0400 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id r595USrJ6383901; Sun, 9 Jun 2013 01:30:29 -0400 (EDT) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id r595USRe6349951; Sun, 9 Jun 2013 01:30:28 -0400 (EDT) Date: Sun, 9 Jun 2013 01:30:28 -0400 (EDT) Message-Id: <201306090530.r595USRe6349951@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Paul Kyzivat In-reply-to: <51B0C86B.3080907@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <51B0C86B.3080907@alum.mit.edu> Cc: dispatch@ietf.org Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2013 05:31:16 -0000 > From: Paul Kyzivat > > In section 3.10 you say that a 488 should be returned. > I suppose that is the worst case, but there may be less severe > possibilities. For instance, if there are multiple m-lines with > different addresses, it could simply reject those m-lines with addresses > it can't use, and accept the m-lines it can use. > > The 488 then becomes a plausible response if all the m-lines need to be > rejected. At the least, the text needs to be changed to "receives a ... SDP offer all of whose network addresses are not compatible ...", as there could both be m= lines with IPv4 addresses and m= lines with IPv6 addresses. But as Paul says, it's better to accept the lines you can and reject the ones you can't. BTW, what do real devices do when the receive an offer that contains no m= line that it can accept? Dale From oej@edvina.net Mon Jun 10 04:13:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 385D921F84AF for ; Mon, 10 Jun 2013 04:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Xvrndrz0rnl for ; Mon, 10 Jun 2013 04:13:39 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6C60121F84A1 for ; Mon, 10 Jun 2013 04:13:38 -0700 (PDT) Received: from [192.168.20.187] (static-213-115-251-100.sme.bredbandsbolaget.se [213.115.251.100]) by smtp7.webway.se (Postfix) with ESMTPA id 33A8093C1AF; Mon, 10 Jun 2013 11:13:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <201306090530.r595USRe6349951@shell01.TheWorld.com> Date: Mon, 10 Jun 2013 13:13:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <83BA3FBF-1771-4AB8-A106-2AFF6F6F8E0F@edvina.net> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <51B0C86B.3080907@alum.mit.edu> <201306090530.r595USRe6349951@shell01.TheWorld.com> To: Dale R. Worley X-Mailer: Apple Mail (2.1503) Cc: dispatch@ietf.org Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 11:13:42 -0000 9 jun 2013 kl. 07:30 skrev Dale R. Worley : >> From: Paul Kyzivat >>=20 >> In section 3.10 you say that a 488 should be returned. >> I suppose that is the worst case, but there may be less severe=20 >> possibilities. For instance, if there are multiple m-lines with=20 >> different addresses, it could simply reject those m-lines with = addresses=20 >> it can't use, and accept the m-lines it can use. >>=20 >> The 488 then becomes a plausible response if all the m-lines need to = be=20 >> rejected. >=20 > At the least, the text needs to be changed to "receives a ... SDP = offer > all of whose network addresses are not compatible ...", as there could > both be m=3D lines with IPv4 addresses and m=3D lines with IPv6 > addresses. But as Paul says, it's better to accept the lines you can > and reject the ones you can't. Right. >=20 > BTW, what do real devices do when the receive an offer that contains > no m=3D line that it can accept? =46rom SIPit, most of them send 488, but there are a few that sends = other codes. This was not from IPv6 tests, but tests with RTP/SAVPF. We reached = consensus that 488 was the recommended error code. =46rom the SIPit 30 summary: "We successfully set up calls between browsers with both video and audio = over both the proxy and the SBC. During the test, we invited a large set of = SIP UA's to test receiving INVITEs with these large SDPs to test how they = responded. A few ones responded incorrectly with "bad media type", one parsed via = headers and failed with a "400" message and most of the UA's correctly responded = with a "488" response code." /O >=20 > Dale > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From pkyzivat@alum.mit.edu Mon Jun 10 06:08:47 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B17321F8CB4 for ; Mon, 10 Jun 2013 06:08:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.405 X-Spam-Level: X-Spam-Status: No, score=-0.405 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RT11b4yyV7JN for ; Mon, 10 Jun 2013 06:08:42 -0700 (PDT) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id 454D321F8AC2 for ; Mon, 10 Jun 2013 06:08:40 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta13.westchester.pa.mail.comcast.net with comcast id mcqt1l0030ldTLk5Dd8ftX; Mon, 10 Jun 2013 13:08:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id md8e1l00g3ZTu2S01d8e3J; Mon, 10 Jun 2013 13:08:39 +0000 Message-ID: <51B5CFD6.7080308@alum.mit.edu> Date: Mon, 10 Jun 2013 09:08:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: "Olle E. Johansson" References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <51B0C86B.3080907@alum.mit.edu> <201306090530.r595USRe6349951@shell01.TheWorld.com> <83BA3FBF-1771-4AB8-A106-2AFF6F6F8E0F@edvina.net> In-Reply-To: <83BA3FBF-1771-4AB8-A106-2AFF6F6F8E0F@edvina.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1370869719; bh=OH6O93w+izjmRaYM/zMk9hh/DDZ0refAh+oAM9x6Frg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=JlSpXnioIfx7fPTpejYFT8UXM4FTdxj2jjjWCoSqkPf2CwFvlHkr3joXdCswbc3Sb +F+WIv/sdN/gfttopZLb8+/u+kgWLcZ2qh3WoNLxV8giI9u4z3O7kFY803KD2amAwe UDQsrIiocLygJfzwFqrYQ0+W/3lR5B2XQwyZdvt749OHh4ghFryhnFlphbnZqgL2v9 SBy+kWgyaPsYaRH/aquXViFzM31NUOV12QY1iG3uj6OK6r7eM2xLDB86FX1Akc2jOx 0UuZkx9J82XYDgPL+k86tR8wDvcChnycIDnhoKEz5+8DzWC2vL5G9jktJ8ao+6VUgM DTf2hsWD9IVzA== Cc: dispatch@ietf.org Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2013 13:08:48 -0000 An alternative to 488 when no m-lines can be accepted is to accept the offer while rejecting all the m-lines. Then, send another offer indicating what you *can* do. I've explored cases where that might be useful. But such behavior could also cause problems in forking scenarios. That can be minimized by only doing it with a reliable provisional followed by an UPDATE, so that it is still possible for the call leg to fail and forking to try someplace else. But its also a strategy that is only likely to be helpful in special cases - devices with unusual capabilities. Thanks, Paul On 6/10/13 7:13 AM, Olle E. Johansson wrote: > > 9 jun 2013 kl. 07:30 skrev Dale R. Worley : > >>> From: Paul Kyzivat >>> >>> In section 3.10 you say that a 488 should be returned. >>> I suppose that is the worst case, but there may be less severe >>> possibilities. For instance, if there are multiple m-lines with >>> different addresses, it could simply reject those m-lines with addresses >>> it can't use, and accept the m-lines it can use. >>> >>> The 488 then becomes a plausible response if all the m-lines need to be >>> rejected. >> >> At the least, the text needs to be changed to "receives a ... SDP offer >> all of whose network addresses are not compatible ...", as there could >> both be m= lines with IPv4 addresses and m= lines with IPv6 >> addresses. But as Paul says, it's better to accept the lines you can >> and reject the ones you can't. > Right. >> >> BTW, what do real devices do when the receive an offer that contains >> no m= line that it can accept? > From SIPit, most of them send 488, but there are a few that sends other codes. > > This was not from IPv6 tests, but tests with RTP/SAVPF. We reached consensus > that 488 was the recommended error code. From the SIPit 30 summary: > > "We successfully set up calls between browsers with both video and audio over > both the proxy and the SBC. During the test, we invited a large set of SIP UA's > to test receiving INVITEs with these large SDPs to test how they responded. A > few ones responded incorrectly with "bad media type", one parsed via headers > and failed with a "400" message and most of the UA's correctly responded with a > "488" response code." > > > /O >> >> Dale >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch > > From mary.ietf.barnes@gmail.com Tue Jun 11 15:26:27 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24CCE21F9A38 for ; Tue, 11 Jun 2013 15:26:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGkHBCE12zJh for ; Tue, 11 Jun 2013 15:26:25 -0700 (PDT) Received: from mail-qa0-x22b.google.com (mail-qa0-x22b.google.com [IPv6:2607:f8b0:400d:c00::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 4E39121F9A14 for ; Tue, 11 Jun 2013 15:26:18 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id d13so3314315qak.2 for ; Tue, 11 Jun 2013 15:26:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=9MjHSFsxJvnLxBg7Fq7gXyablceqh8vO0GOcIp4QvwQ=; b=jTa/3hvdPLHRUbLw06cVZLU/Me2sUWsClE6zKmo3sCzXATYCw8GTv65r7sS2tZCTWy DfRcBww37cpX+TafgQimeMroUa5QkWZ1glNNSuw5QN43bRle1sPdOFSR5yRmPYmG2Px1 MtIDd0cUylIUEtXcl8qsxIL4NJx4ClP3Xw+LWVBQEb+XoPhFB4Sfws5rVmQZV7TwCV8a mfJ3FxVVL5fRaMAmSyzXUyxAXL6xO0LzkRpCBDwMxwWLrXvi1YV3QDWVIGGk7uDfegFJ T35VLxr+VKxwjslhnob2yF+tbo8xyxHdVNMUXT5r4Wl7/wwL9R8jKkoUcYICvUyHpckr 3Bpg== MIME-Version: 1.0 X-Received: by 10.224.37.134 with SMTP id x6mr20478834qad.98.1370989569347; Tue, 11 Jun 2013 15:26:09 -0700 (PDT) Received: by 10.49.117.130 with HTTP; Tue, 11 Jun 2013 15:26:09 -0700 (PDT) Date: Tue, 11 Jun 2013 17:26:09 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Subject: [dispatch] Additional IPR disclosures on draft-allen-dispatch-imei-urn-as-instanceid and draft-montemurro-gsma-imei-urn X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jun 2013 22:26:27 -0000 Please note that additional IPR disclosures have been made with regards to http://datatracker.ietf.org/doc/draft-allen-dispatch-imei-urn-as-instanceid/ : http://datatracker.ietf.org/ipr/2094/ And http://tools.ietf.org/html/draft-montemurro-gsma-imei-urn-14 : https://datatracker.ietf.org/ipr/2090/ We are in the process of getting these documents published as AD sponsored (as has been previously discussed on the mailing list), so we just wanted to ensure that the community was aware of the additional IPR. Regards, Mary DISPATCH WG co-chair From Peter.Dawes@vodafone.com Thu Jun 13 04:18:25 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ADA321F99C1 for ; Thu, 13 Jun 2013 04:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lq4Wov3bIPjl for ; Thu, 13 Jun 2013 04:18:19 -0700 (PDT) Received: from mailout02.vodafone.com (mailout02.vodafone.com [195.232.224.71]) by ietfa.amsl.com (Postfix) with ESMTP id 719EB21F9A47 for ; Thu, 13 Jun 2013 04:18:19 -0700 (PDT) Received: from mailint02.vodafone.com (localhost [127.0.0.1]) by mailout02.vodafone.com (Postfix) with ESMTP id 9377838136D for ; Thu, 13 Jun 2013 13:18:16 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint02.vodafone.com (Postfix) with ESMTPS id 811A73802C5; Thu, 13 Jun 2013 13:18:16 +0200 (CEST) Received: from VOEXC15W.internal.vodafone.com (145.230.101.17) by VOEXC06W.internal.vodafone.com (145.230.101.26) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 13 Jun 2013 13:18:16 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.242]) by voexc15w.internal.vodafone.com ([145.230.101.17]) with mapi id 14.02.0328.011; Thu, 13 Jun 2013 13:17:37 +0200 From: "Dawes, Peter, Vodafone Group" To: "dispatch@ietf.org" Thread-Topic: Proposed charter for work on logging Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQEpuAXZA= Date: Thu, 13 Jun 2013 11:17:36 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> References: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> In-Reply-To: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed charter for work on logging X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 11:18:25 -0000 Hello All, Following on from the comments at IETF#86 (http://www.ietf.org/proceedings/= 86/minutes/minutes-86-dispatch), where there was mild support for working o= n logging, I have updated the log me requirements draft with 3 potential so= lutions (in clause 7) which can meet the requirements (http://www.ietf.org/= internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt). Opinions and comme= nts on these or any other potential solutions would be very welcome. It was commented at IETF#86 that a security analysis is needed so I would l= ike to understand if any scenarios exist with potential security threats in= order to add them to requirements. In many cases, a network simply logs th= e signalling that passes through it so no new security issues are created. = Collecting end-to-end logging for signalling that crosses multiple networks= must not compromise security or privacy, but I would expect networks to re= move any security sensitive fields before forwarding signalling regardless = of whether that signalling is of interest to logging. Also, as far as I can= see no final decision was made whether INSIPID could be a home for the log= ging topic. I think INSIPID would be a good working group to discuss a log = me indicator since troubleshooting is one possible use of session-id. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of DRAGE, Keith (Keith) Sent: 10 March 2013 17:26 To: dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging Peter has suggested a minor modification to the charter text (which he also= plans to make to the abstract of the requirements document). SIP networks use signalling monitoring tools to diagnose user reported problem and for regression testing if network or client software is upgraded. As networks grow and become interconnected, including connection via transit networks, it becomes impractical to predict the path that SIP signalling will take between clients, and therefore impractical to monitor SIP signalling end-to-end. This work will provide for adding an indicator to the SIP protocol which can be used to mark signalling as of interest to logging. Such marking will typically be applied as part of network testing controlled by the network operator and not used in regular client signalling. However, such marking can be carried end-to-end including the SIP terminals, even if a session originates and terminates in different networks. The change is in the 2nd paragraph, changing "subject to" to "of interest t= o". Regards Keith > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On=20 > Behalf Of DRAGE, Keith (Keith) > Sent: 15 February 2013 22:08 > To: dispatch@ietf.org > Subject: [dispatch] Proposed charter for work on logging >=20 > Peter Dawes has submitted >=20 > https://datatracker.ietf.org/doc/draft-dawes-dispatch-logme-reqs/ >=20 > as a set of requirements that will work with the session identifier=20 > produced by the INSIPID working group to enable identification of=20 > loggable sessions. >=20 > The INIPID WG did consider this work, but considered it was out of=20 > scope of the work they are currently chartered to do. >=20 > I propose the following scope for DISPATCH to consider based on the=20 > Abstract of the above document. >=20 > SIP networks use signalling monitoring tools to diagnose user > reported problem and for regression testing if network or client > software is upgraded. As networks grow and become interconnected, > including connection via transit networks, it becomes impractical to > predict the path that SIP signalling will take between clients, and > therefore impractical to monitor SIP signalling end-to-end. >=20 > This work will provide for adding an indicator to the SIP > protocol which can be used to mark signalling as subject to logging. > Such marking will typically be applied as part of network testing > controlled by the network operator and not used in regular client > signalling. However, such marking can be carried end-to-end > including the SIP terminals, even if a session originates and > terminates in different networks. >=20 >=20 > Milestones >=20 > Dec 2013 Requirements for marking SIP sessions for logging to IESG > (Informational) > Mar 2014 Protocol for marking SIP sessions for logging to IESG > (Proposed standard) >=20 > I would note that the work does not necessarily need a new working=20 > group, it could for example be an extension of the work of either the=20 > SIPCORE WG or the INSIPID WG, but that is for the discussion to decide. >=20 > Your comments and proposals for revision are welcome. >=20 > For information there have been a number of previous documents on the=20 > subject, but these might or might not form part of the proposed=20 > solution, particularly given that some of them predate the INSIPID work. >=20 > http://tools.ietf.org/html/draft-dawes-sipping-debug-id-01 > http://tools.ietf.org/html/draft-dawes-sipping-debug-event-01 > http://tools.ietf.org/html/draft-kaithal-dispatch-sip-log-information- > 00 > http://tools.ietf.org/html/draft-dawes-sipping-debug-05 > http://tools.ietf.org/html/draft-dawes-dispatch-debug-00 > http://tools.ietf.org/html/draft-kaithal-sipclf-sip-log-information-00 >=20 >=20 > Regards >=20 > Keith > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From vkg@bell-labs.com Thu Jun 13 14:19:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07B9C21F9ACD for ; Thu, 13 Jun 2013 14:19:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aiqupan-ol2y for ; Thu, 13 Jun 2013 14:19:16 -0700 (PDT) Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0FD21F9A39 for ; Thu, 13 Jun 2013 14:19:15 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r5DLJ4tl017188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 13 Jun 2013 16:19:04 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id r5DLJ3DX000793 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 13 Jun 2013 16:19:04 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r5DLJ38P010320 for ; Thu, 13 Jun 2013 16:19:03 -0500 (CDT) Message-ID: <51BA382E.4040605@bell-labs.com> Date: Thu, 13 Jun 2013 16:22:54 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130514 Thunderbird/17.0.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> 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.10 Subject: Re: [dispatch] Proposed charter for work on logging X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2013 21:19:21 -0000 On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, Following on from the comments at IETF#86 > (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), > where there was mild support for working on logging, I have updated > the log me requirements draft with 3 potential solutions (in clause > 7) which can meet the requirements > (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.txt). > Opinions and comments on these or any other potential solutions would > be very welcome. Peter: I am not being a contrarian, just being curious. What is the utility of a log-me marker if all traffic is logged through a mechanism such as SIP CLF? > It was commented at IETF#86 that a security analysis is needed so I > would like to understand if any scenarios exist with potential > security threats in order to add them to requirements. In many cases, > a network simply logs the signalling that passes through it so no new > security issues are created. Collecting end-to-end logging for > signalling that crosses multiple networks must not compromise > security or privacy, but I would expect networks to remove any > security sensitive fields before forwarding signalling regardless of > whether that signalling is of interest to logging. We went through discussions related to all of the above points during the SIP CLF work. See the Security Consideration section of [1]; it may provide you some answers. [1] http://tools.ietf.org/html/rfc6872 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From fas_vm@surguttel.ru Mon Jun 17 06:17:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4D821F9B4A for ; Mon, 17 Jun 2013 06:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.472 X-Spam-Level: * X-Spam-Status: No, score=1.472 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cwLnwlCbDIFz for ; Mon, 17 Jun 2013 06:17:08 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id B222D21F9AF5 for ; Mon, 17 Jun 2013 06:17:07 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id 7E025514DA9; Mon, 17 Jun 2013 19:16:27 +0600 (YEKT) Received: from Gateway (unknown [151.252.67.133]) by mail.s86.ru (Postfix) with ESMTPA id 4F3B6514C46 for ; Mon, 17 Jun 2013 19:16:24 +0600 (YEKT) Message-ID: <84E37CB1D3B646C9B5D4919D724BAFF3@Gateway> From: "Anton Tveretin" To: Date: Mon, 17 Jun 2013 19:05:21 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130617-1, 17.06.2013), Outbound message X-Antivirus-Status: Clean Subject: [dispatch] New I-D X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jun 2013 13:17:14 -0000 Dear All, The I-D is not new, it is exactly the same that I published in May, yet converted into XML. Questions are the same. http://www.ietf.org/id/draft-tveretin-dispatch-l2tp-sdp-00.txt - Anton Tveretin From prvs=588192ab57=gonzalo.camarillo@ericsson.com Tue Jun 18 03:41:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9693421F9BB6 for ; Tue, 18 Jun 2013 03:41:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.864 X-Spam-Level: X-Spam-Status: No, score=-105.864 tagged_above=-999 required=5 tests=[AWL=0.385, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kgZudVG8TgUK for ; Tue, 18 Jun 2013 03:41:01 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3AC21F9605 for ; Tue, 18 Jun 2013 03:41:00 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-67-51c0393c56da Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 9B.40.18006.C3930C15; Tue, 18 Jun 2013 12:41:00 +0200 (CEST) Received: from [131.160.36.46] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Tue, 18 Jun 2013 12:41:00 +0200 Message-ID: <51C0393B.40306@ericsson.com> Date: Tue, 18 Jun 2013 13:40:59 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: DISPATCH X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrBJMWRmVeSWpSXmKPExsUyM+Jvra6N5YFAgwdtvBZLJy1gdWD0WLLk J1MAYxS3TVJiSVlwZnqevl0Cd8aGadPZC6axVsztOMbcwLiUpYuRk0NCwESif89ndghbTOLC vfVsXYxcHEICpxglrnbvY4RwVjNKfDx5hwmkildAU+LDxhuMIDaLgKrE3f37wLrZBCwktty6 DzZVVCBKYs66B2wQ9YISJ2c+AYuLCChI7L10gLWLkYNDWMBU4uJWZojFkhJbXrSDjWEW0JOY crWFEcKWl9j+dg5YjZCAtsTyZy0sExj5ZyGZOgtJyywkLQsYmVcxsucmZuaklxttYgQG1MEt v1V3MN45J3KIUZqDRUmc9+OpXYFCAumJJanZqakFqUXxRaU5qcWHGJk4OEEEl1QD46JrqbNf qAZfPcNasKF+6boNKZuZXqg56j+/O3Fhse4Etj3cj1taly1XSHmr06Uy9XbwThYb5sX3/kyp /1tQ3RS0pu29fsbc9cK1vV0HQjyW5N/cIH/ysUvbkx+zF/8qLbPl2aGQo3ZdVOjI/uzPm6rq 3f9otCatF/pVWn6+cfbke0vfzY2WPq/EUpyRaKjFXFScCACmCWyq+wEAAA== Subject: [dispatch] Progressing draft-ivov-grouptextchat-purpose X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 10:41:06 -0000 Folks, I am going to be AD sponsoring the following draft: https://datatracker.ietf.org/doc/draft-ivov-grouptextchat-purpose/ In principle, the idea was to progress it as PS. However, when the IESG discussed the following draft, it was decided that this type of registration can be better performed with an Informational RFC (see Pete's original discuss): https://datatracker.ietf.org/doc/draft-saintandre-impp-call-info/history/ So, if nobody objects, I will ask Saul (the document shepherd) and Emil (the author) to change the draft's boilerplate and the PROTO writeup before IETF LCing the draft as Informational. Thanks, Gonzalo From fluffy@cisco.com Tue Jun 18 07:29:12 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAAD021E8050 for ; Tue, 18 Jun 2013 07:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AeO5K2kf3BjA for ; Tue, 18 Jun 2013 07:29:07 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id C4D5121F9F47 for ; Tue, 18 Jun 2013 07:29:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=735; q=dns/txt; s=iport; t=1371565747; x=1372775347; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SAqE5FlnOQeL/FqVXnCKxp5J6hH6mVSvBTbQI7paDGk=; b=iY/ytiMaXFKkV3u/hIxKG2/89LNNEkiPEzCTbtLFvAelUE80rhBjoOYO 8NxoPGTjVOIdA07eYnUtpV1QTk4/v9u7g+8X4UDiNo0xZI2mqnQ1N1JA2 U29Qknr+4iquR4m3GJgGLPQBnAeJIAFrpinGVhCAgJWdlHBrJmmQg/XBn 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmAFACRuwFGtJV2b/2dsb2JhbABZgwkxSYI6vFGBARZ0giMBAQEDAQEBAWsLBQsCAQgOFCQnCyUCBA4FCAGHfwYMum+PCAIxB4MAYQOpBIMPgig X-IronPort-AV: E=Sophos;i="4.87,889,1363132800"; d="scan'208";a="224245333" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-2.cisco.com with ESMTP; 18 Jun 2013 14:29:07 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5IET7rb004193 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 18 Jun 2013 14:29:07 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.215]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.02.0318.004; Tue, 18 Jun 2013 09:29:07 -0500 From: "Cullen Jennings (fluffy)" To: Anton Tveretin Thread-Topic: [dispatch] New I-D Thread-Index: AQHObDAwXphIcOQuqUWQx9SwwIWDvA== Date: Tue, 18 Jun 2013 14:29:06 +0000 Message-ID: References: <84E37CB1D3B646C9B5D4919D724BAFF3@Gateway> In-Reply-To: <84E37CB1D3B646C9B5D4919D724BAFF3@Gateway> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.20.249.164] Content-Type: text/plain; charset="Windows-1252" Content-ID: <5817A876272DBA4981706AEE6D2E94CE@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "" Subject: Re: [dispatch] New I-D X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 14:29:12 -0000 Just as one trivial thought =85 You might want to talk to the authors of draft-saito-mmusic-sdp-ike-01 (RFC= 6193). That draft was pretty controversial - the main issue was around if = that was an appropriate use of SIP or not and this draft might have similar= issues.=20 On Jun 17, 2013, at 7:05 AM, Anton Tveretin wrote: > Dear All, > The I-D is not new, it is exactly the same that I published in May, yet c= onverted into XML. Questions are the same. > http://www.ietf.org/id/draft-tveretin-dispatch-l2tp-sdp-00.txt > - Anton Tveretin=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Tue Jun 18 15:05:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBAF21E80D2 for ; Tue, 18 Jun 2013 15:05:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kDnUe3-TPBTf for ; Tue, 18 Jun 2013 15:05:03 -0700 (PDT) Received: from mail-ie0-x236.google.com (mail-ie0-x236.google.com [IPv6:2607:f8b0:4001:c03::236]) by ietfa.amsl.com (Postfix) with ESMTP id AFCDE21E80C8 for ; Tue, 18 Jun 2013 15:05:03 -0700 (PDT) Received: by mail-ie0-f182.google.com with SMTP id s9so11597206iec.41 for ; Tue, 18 Jun 2013 15:05:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=mS0eWYsGPhZgl57SLTVoWHk+H8Uur+mWMgJLCu+XPXA=; b=reBvrrsvwRKabWGUP7R5B/j33TCv97lX0BCxfCzIOg8CWwaonikH6dhZTIS7MDeVDL O3HsewHS700IYM8a6P7a+DaKNq/WGAEO87Q86p/DtxoM+L2Mshr0eH0NAhDfT7quvj7u i6+pcmzcv37jUfdH2lJ6J48eD9oMi/V3xElG9YR6L6dhKB25PmLdIxxXDj8BrlJ2U0d2 fCaGsdio/eyP+QGi2LrzBW4cOyJCHK74ROt2scvrFNizOmujoPUtbin7cAYeOR/R60ti kywOPmgFRlg6w3FbbjqU7dMRZUntKz8vI5UrAupCu2SKoO+a//qhl0sRiQ1yH0z/HIbp 1gTA== MIME-Version: 1.0 X-Received: by 10.42.28.71 with SMTP id m7mr1347884icc.56.1371593102821; Tue, 18 Jun 2013 15:05:02 -0700 (PDT) Received: by 10.42.81.13 with HTTP; Tue, 18 Jun 2013 15:05:02 -0700 (PDT) Date: Tue, 18 Jun 2013 17:05:02 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings Subject: [dispatch] DISPATCH @ IETF-87 Deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jun 2013 22:05:09 -0000 As a reminder, the deadline for letting the chairs know that you are planning to submit something for consideration for the IETF-87 deadline is June 24th, 2013 (next Monday - 6 days time). The subsequent deadlines are also in the wiki: http://tools.ietf.org/wg/dispatch/trac/wiki Noting, that the draft deadlines are the same as the IETF draft deadlines. Regards, Mary DISPATCH WG co-chair From prvs=5883e00d1b=christer.holmberg@ericsson.com Thu Jun 20 01:45:01 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1B0021E80F9 for ; Thu, 20 Jun 2013 01:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.864 X-Spam-Level: X-Spam-Status: No, score=-5.864 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cIrEMCgrFhmh for ; Thu, 20 Jun 2013 01:44:55 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 15F5221E80FA for ; Thu, 20 Jun 2013 01:44:54 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-e2-51c2c1055946 Received: from ESESSHC001.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 09.E0.18006.501C2C15; Thu, 20 Jun 2013 10:44:53 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC001.ericsson.se ([153.88.183.21]) with mapi id 14.02.0328.009; Thu, 20 Jun 2013 10:44:53 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: Draft submission: draft-holmberg-dispatch-udptl-dtls-00 Thread-Index: Ac5tkm5Tax3vYMZOTkK6vthspT2Y8w== Date: Thu, 20 Jun 2013 08:44:53 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1C3B1E5B@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C3B1E5BESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM+JvrS7rwUOBBgsf6VksnbSA1YHRY8mS n0wBjFHcNkmJJWXBmel5+nYJ3Blff+5iK+iVrNh+7gBzA+MMsS5GTg4JAROJjgmdbBC2mMSF e+uBbC4OIYHDjBKz335gBUkICSxilNh/WrGLkYODTcBCovufNkhYREBb4uiqLmaQsLCAg8SH Ry4gpoiAq8S/xTUQFXoSkxvOg01nEVCV+PNlAjuIzSvgK7Hm6hpmEJsRaOv3U2uYQGxmAXGJ W0/mM0FcIyCxZM95ZghbVOLl43+sIOMlBBQllvfLQZTnSzz49IkNYqSgxMmZT1gmMArNQjJp FpKyWUjKIOI6Egt2Q8SZgX5ZtvA1M4x95sBjJmTxBYzsqxjZcxMzc9LLjTYxAgP+4JbfqjsY 75wTOcQozcGiJM778dSuQCGB9MSS1OzU1ILUovii0pzU4kOMTBycIIJLqoFx011TXR8Bm1dL enxUL3Fkp+226Hg4e73SsapDDuyqh2tknb4UeAn5X26tylsZnPpu3oMwZ7achsW9Z+P+6Zla S9VOd/h5vf3SnT9V2dKmr17Kv3jacMVOt2yW0Gl3TkatDbuUNl77mSUs9G6d2uPbj47wLF+t pXDVlzkz1I0z2+vtyemlCf+UWIozEg21mIuKEwH/hG8WSwIAAA== Subject: [dispatch] Draft submission: draft-holmberg-dispatch-udptl-dtls-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 08:45:01 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C3B1E5BESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have submitted a new draft, draft-holmberg-dispatch-udptl-dtls-00, to DI= SPATCH. The draft defines the usage of UDPTL over DTLS, which allows integrity and = confidentiality protection to fax sent using UDPTL. The draft also defines a new SDP "m=3D" line proto value, in order to indic= ate UDPTL over DTLS in SDP. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C3B1E5BESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have submitted a new draft, draft-holmberg-dispat= ch-udptl-dtls-00, to DISPATCH.

 

The draft defines the usage of UDPTL over DTLS, whic= h allows integrity and confidentiality protection to fax sent using UDPTL.<= o:p>

 

The draft also defines a new SDP “m=3D” = line proto value, in order to indicate UDPTL over DTLS in SDP.

 

Regards,

 

Christer

 

--_000_7594FB04B1934943A5C02806D1A2204B1C3B1E5BESESSMB209erics_-- From Peter.Dawes@vodafone.com Thu Jun 20 07:05:13 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 897A021F9C90 for ; Thu, 20 Jun 2013 07:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7oNQ4CYM1HKW for ; Thu, 20 Jun 2013 07:05:09 -0700 (PDT) Received: from mailout01.vodafone.com (mailout01.vodafone.com [195.232.224.70]) by ietfa.amsl.com (Postfix) with ESMTP id E573221F9C59 for ; Thu, 20 Jun 2013 07:05:08 -0700 (PDT) Received: from mailint01.vodafone.com (localhost [127.0.0.1]) by mailout01.vodafone.com (Postfix) with ESMTP id 9F2A92E1A1A for ; Thu, 20 Jun 2013 16:05:05 +0200 (CEST) Received: from VOEXC01W.internal.vodafone.com (voexc01w.dc-ratingen.de [145.230.101.21]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint01.vodafone.com (Postfix) with ESMTPS id 91F172E16A5; Thu, 20 Jun 2013 16:05:05 +0200 (CEST) Received: from VOEXC18W.internal.vodafone.com (145.230.101.20) by VOEXC01W.internal.vodafone.com (145.230.101.21) with Microsoft SMTP Server (TLS) id 14.2.328.11; Thu, 20 Jun 2013 16:05:05 +0200 Received: from VOEXM31W.internal.vodafone.com ([169.254.7.242]) by voexc18w.internal.vodafone.com ([145.230.101.20]) with mapi id 14.02.0328.011; Thu, 20 Jun 2013 16:05:04 +0200 From: "Dawes, Peter, Vodafone Group" To: "Vijay K. Gurbani" , "dispatch@ietf.org" Thread-Topic: [dispatch] Proposed charter for work on logging Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQEpuAXZAAEl09AAFUv0EQ Date: Thu, 20 Jun 2013 14:05:03 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6EC89@VOEXM31W.internal.vodafone.com> References: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> <51BA382E.4040605@bell-labs.com> In-Reply-To: <51BA382E.4040605@bell-labs.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed charter for work on logging X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 14:05:13 -0000 Hi Vijay, The utility of a marker is that currently there is no SIP protocol mechanis= m to indicate that signalling is of interest to logging, so it is not a log= ging format issue but an issue of making regression testing and troubleshoo= ting scaleable by not having to log everything.=20 Thanks for the pointer to RFC 6872, I will take a look at it. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Vijay K. Gurbani Sent: 13 June 2013 22:23 To: dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, Following on from the comments at IETF#86=20 > (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), > where there was mild support for working on logging, I have updated=20 > the log me requirements draft with 3 potential solutions (in clause > 7) which can meet the requirements > (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.t= xt). > Opinions and comments on these or any other potential solutions would=20 > be very welcome. Peter: I am not being a contrarian, just being curious. What is the utility of a log-me marker if all traffic is logged through a m= echanism such as SIP CLF? > It was commented at IETF#86 that a security analysis is needed so I=20 > would like to understand if any scenarios exist with potential=20 > security threats in order to add them to requirements. In many cases,=20 > a network simply logs the signalling that passes through it so no new=20 > security issues are created. Collecting end-to-end logging for=20 > signalling that crosses multiple networks must not compromise security=20 > or privacy, but I would expect networks to remove any security=20 > sensitive fields before forwarding signalling regardless of whether=20 > that signalling is of interest to logging. We went through discussions related to all of the above points during the S= IP CLF work. See the Security Consideration section of [1]; it may provide= you some answers. [1] http://tools.ietf.org/html/rfc6872 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Thu Jun 20 10:44:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E39221F9F4E; Thu, 20 Jun 2013 10:44:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.433 X-Spam-Level: X-Spam-Status: No, score=-102.433 tagged_above=-999 required=5 tests=[AWL=0.167, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UgZkMQfH59G3; Thu, 20 Jun 2013 10:44:25 -0700 (PDT) Received: from mail-qa0-x22f.google.com (mail-qa0-x22f.google.com [IPv6:2607:f8b0:400d:c00::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 270AE21F9F5D; Thu, 20 Jun 2013 10:44:25 -0700 (PDT) Received: by mail-qa0-f47.google.com with SMTP id i13so465976qae.20 for ; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=P7IX4sX1uAhu2G+vBCZNEjrkyxVGl+ZDH1k2KGmIeJw=; b=GcK71ekH2PYbS/1A7+vBcaGimudvirG3kfna3rVnasiNbEaPvYMn+6ElxlgOtkSc13 4eTYArwFpihyCdSU5VanHRDxu4ZybBo7weFx7BusD1dVV/KZCYcaqjeD3N2H0dgzuFlu EwOXkDa0lE/kzZfG5+2B6jq33xzNgDM8nd2OkHTV9Bg9v/WngmwiKmZ/fxKConmlbCeW zqr1XLgwqieoLkCQQ6c4/5FVX8BLvxlZck+QcRncWCJ5NaRktaPudTzuuRgf8CeEE+15 eSdYM8vAm3zI74U90McVJrG24wx5bBms70v/XBzCIj0KxNuyJYVsLFNWKN8T0THyKjqN +cNA== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr10212822qaj.13.1371750264650; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 20 Jun 2013 10:44:24 -0700 (PDT) In-Reply-To: <20130619221422.22392.12062.idtracker@ietfa.amsl.com> References: <20130619221422.22392.12062.idtracker@ietfa.amsl.com> Date: Thu, 20 Jun 2013 12:44:24 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH , CLUE Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [dispatch] Fwd: NOMCOM 2013 - UPDATE of validated volunteers list so far X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jun 2013 17:44:26 -0000 Thanks to the RAI folks who have volunteered! This is a great way to serve the community. [Note: I really would volunteer but I can't due to my IAB role]. The time commitment is most intense towards year end, but the role of a voting member can be fairly well managed, in particular since you have a great Nomcom chair this year! Thanks, Mary. ---------- Forwarded message ---------- From: NomCom Chair 2013 Date: Wed, Jun 19, 2013 at 5:14 PM Subject: NOMCOM 2013 - UPDATE of validated volunteers list so far To: IETF Announcement List Cc: ietf@ietf.org Below is the current validated list of volunteers for Nomcom 2013. If your name has a *, I'm waiting for a message back from you. Big thanks to everyone who has volunteered! Now what are the rest of you waiting for? We still need quite a few to get up to 200 volunteers. Please reply and volunteer - include in the email: your First Name, Last Name, email addresses you've used in the last few years in registering for IETF meetings, preferred email address, primary affiliation, and a contact phone number for use if you're selected. Thanks, Allison Mankin Nomcom 2013 Chair 1 John Scudder 2 Stephen Hanna 3 Wassim Haddad 4 Russ White 5 Stephan Wenger 6 ZHAO Yi 7 Eric Gray 8 Steve Kent 9 Toerless Eckert 10 Alia Atlas 11 Victor Kuarsingh 12 Yizhou LI 13 Gonzalo Salgueiro 14 Gang CHEN 15 Ning KONG 16 Marcelo Bagnulo 17 SHEN Shuo =E6=B2=88=E7=83=81 (Sean) 18 Fernando Gont 19 Glen Zorn 20 Reinaldo Penno 21 Klaas Wierenga 22 Pascal Thubert 23 Mehmet Ersue 24 Ole Troan 25 Jouni Korhonen 26 Giles Heron 27 Gunter Van de Velde 28 Arturo Servin 29 Eric Vyncke 30 Cullen Jennings 31 Tina Tsou 32 Dhruv Dhody 33 Hongyu LI (Julio) 34 Scott Mansfield 35 John Drake 36 Andrew McLachlan 37 Derek Atkins 38 Suhas Nandakumar 39 Eric Rescorla 40 Karen Seo 41 Stig Venaas 42 Stan Ratliff 43 Ignas Bagdonas 44 Peter Yee 45 Donald Eastlake 46 ZHOU Qian (Cathy) 47 Sam Hartman 48 Lixia Zhang 49 Teemu Savolainen 50 Alvaro Retana 51 Terry Manderson 52 Bill VerSteeg 53 Melinda Shore 54 IJsbrand Wijnands 55 Karen O'Donoghue 56 Benson Schliesser 57 Ari Ker=C3=A4nen 58 Fangwei HU 59 Mach CHEN 60 Hui Deng 61 LIU Dapeng 62 Jaap Akkerhuis 63 Magnus Westerlund 64 Zehn CAO 65 Zaheduzzaman Sarker 66 Bhumip Khasnabish 67 Andrew Chi 68 Thomas Nadeau 69 Steven C (Craig) Whilte 70 Orit Levin 71 Sam Aldrin 72 Paul Ebersman 73 Christopher Liljenstolpe 74 Uma Chunduri 75 Suresh Krishnan 76 Varun Singh 77 Ron Bonica 78 Bill (William) Manning 79 Radia Perlman 80 Daniele Ceccarelli 81 Deborah Brungard 82 Kostas Pentikousis 83 Gregory Mirsky 84 Dave Sinicrope 85 Thomas Walsh 86 Zhaohui (Jeffrey) ZHANG 87 Xian ZHANG 88 Mark Townsley 89 Hannes Gredler 90 Brian Trammell 91 Carlos Martinez 92 Peter Koch 93 Daniel Migault 94 Yi (Aaron) Ding 95 Michael Richardson 96 Sohel Khan 97 John Bradley 98 Huaimo Chen 99 Matthew Campagna 100 Keith Drage 101 Chris Bowers 102 Jakob Heitz 103 Tomofumi Okubo 104 Emil Ivov 105 Timothy B. Terriberry 106 JIANG Yuanlong 107 Luigi Iannone 108 Damien Saucez 109 Lou Berger 110 Yana Stamcheva 111 Ond=C5=99ej Sur=C3=BD 112 Marcin Pilarski 113 Michael StJohns 114 Wes George 115 Christian O'Flaherty 116 Uwe Rauschenbach 117 Olafur Gudmundsson 118 Shwetha Subray Bhandari* 119 Tobias Gondrom 120 Christer Holmberg 121 Susan Hares 122 Kiran Kumar Chittimaneni 123 Donald Fedyk 124 Stephen Botzko* 125 Li Xue* 126 John Sauer* From Peter.Dawes@vodafone.com Fri Jun 21 03:30:16 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E965811E8112 for ; Fri, 21 Jun 2013 03:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.599 X-Spam-Level: X-Spam-Status: No, score=-4.599 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NL+u4502NMes for ; Fri, 21 Jun 2013 03:30:12 -0700 (PDT) Received: from mailout10.vodafone.com (mailout10.vodafone.com [195.232.224.79]) by ietfa.amsl.com (Postfix) with ESMTP id F204011E8173 for ; Fri, 21 Jun 2013 03:30:11 -0700 (PDT) Received: from mailint10.vodafone.com (localhost [127.0.0.1]) by mailout10.vodafone.com (Postfix) with ESMTP id 520E3301F49 for ; Fri, 21 Jun 2013 12:29:58 +0200 (CEST) Received: from VOEXC06W.internal.vodafone.com (voexc06w.dc-ratingen.de [145.230.101.26]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailint10.vodafone.com (Postfix) with ESMTPS id 4384F301F0E; Fri, 21 Jun 2013 12:29:58 +0200 (CEST) Received: from VOEXM31W.internal.vodafone.com ([169.254.7.242]) by VOEXC06W.internal.vodafone.com ([145.230.101.26]) with mapi id 14.02.0328.011; Fri, 21 Jun 2013 12:29:57 +0200 From: "Dawes, Peter, Vodafone Group" To: Mary Barnes , DISPATCH Thread-Topic: [dispatch] DISPATCH @ IETF-87 Deadlines Thread-Index: AQHObG/wdZe2ogivoUOUcuNtrjMiTJk/9QBw Date: Fri, 21 Jun 2013 10:29:57 +0000 Message-ID: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6F1ED@VOEXM31W.internal.vodafone.com> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: Cullen Jennings Subject: Re: [dispatch] DISPATCH @ IETF-87 Deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 10:30:17 -0000 SGVsbG8gTWFyeSwNCkkgd291bGQgbGlrZSB0aGUgZGlzcGF0Y2ggd29ya2luZyBncm91cCB0byBj b25zaWRlciB0d28gZHJhZnRzIGF0IElFVEYtODcgYXMgZm9sbG93czoNCg0KMSkgaHR0cDovL3d3 dy5pZXRmLm9yZy9pZC9kcmFmdC1kYXdlcy1kaXNwYXRjaC1sb2dtZS1yZXFzLTAyLnR4dCANClRo aXMgZHJhZnQgd2FzIGRpc2N1c3NlZCBhdCBJRVRGLTg2IGFuZCBoYXMgYmVlbiB1cGRhdGVkIHdp dGggcG90ZW50aWFsIHNvbHV0aW9ucyB0byByZXF1aXJlbWVudHMgKGNsYXVzZSA3KS4gSSB3b3Vs ZCBsaWtlIHRvIHByb3Bvc2UgdGhhdCBJTlNJUElEIGFkb3B0IHRoaXMgd29yay4NCihmcm9tIElF VEYtODYgaHR0cDovL3RyYWMudG9vbHMuaWV0Zi5vcmcvd2cvZGlzcGF0Y2gvdHJhYy93aWtpIykN CuKAokxvZ2dpbmc6IEdlbmVyYWwgc3VwcG9ydCBmb3IgYWRvcHRpbmcgdGhpcyB3b3JrLiBQcm9w b3NhbCB0byB1cGRhdGUgSU5TSVBJRCBXRyB3aXRoIGEgbmV3IGRlbGl2ZXJhYmxlLiANCgnil6ZD aGFydGVyOiBodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvZGlzcGF0Y2gvY3Vy cmVudC9tc2cwNDU2MC5odG1sIA0KCeKXplJlbGF0ZWQgZG9jdW1lbnRzOiANCgkJ4pagZHJhZnQt ZGF3ZXMtZGlzcGF0Y2gtbG9nbWUtcmVxcw0KDQoyKSBodHRwOi8vd3d3LmlldGYub3JnL2lkL2Ry YWZ0LWRhd2VzLWRpc3BhdGNoLW1lZGlhc2VjLXBhcmFtZXRlci0wNi50eHQgDQpBbiBpbmZvcm1h dGlvbmFsIFJGQyBkZXNjcmliaW5nIGEgaGVhZGVyIGZpZWxkIHBhcmFtZXRlciB0byBkaXN0aW5n dWlzaCBzZWN1cml0eSBtZWNoYW5pc21zIHRoYXQgcHJvdGVjdCBtZWRpYSAoYXMgb3Bwb3NlZCB0 byB0aG9zZSB0aGF0IHByb3RlY3Qgc2lnbmFsbGluZykgYmV0d2VlbiBhIFVBIGFuZCBpdHMgZmly c3QtaG9wIFNJUCBlbnRpdHksIGFuZCB0byBjcmVhdGUgYW4gSUFOQSByZWdpc3RyeSB0byBsaXN0 IG5hbWVzIG9mIHN1Y2ggbWVkaWEtc3BlY2lmaWMgc2VjdXJpdHkgbWVjaGFuaXNtcy4NCg0KUmVn YXJkcywNClBldGVyDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBkaXNwYXRj aC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86ZGlzcGF0Y2gtYm91bmNlc0BpZXRmLm9yZ10gT24g QmVoYWxmIE9mIE1hcnkgQmFybmVzDQpTZW50OiAxOCBKdW5lIDIwMTMgMjM6MDUNClRvOiBESVNQ QVRDSA0KQ2M6IEN1bGxlbiBKZW5uaW5ncw0KU3ViamVjdDogW2Rpc3BhdGNoXSBESVNQQVRDSCBA IElFVEYtODcgRGVhZGxpbmVzDQoNCkFzIGEgcmVtaW5kZXIsIHRoZSBkZWFkbGluZSBmb3IgbGV0 dGluZyB0aGUgY2hhaXJzIGtub3cgdGhhdCB5b3UgYXJlIHBsYW5uaW5nIHRvIHN1Ym1pdCBzb21l dGhpbmcgZm9yIGNvbnNpZGVyYXRpb24gZm9yIHRoZSBJRVRGLTg3DQpkZWFkbGluZSBpcyBKdW5l IDI0dGgsIDIwMTMgKG5leHQgTW9uZGF5IC0gNiBkYXlzIHRpbWUpLiAgIFRoZQ0Kc3Vic2VxdWVu dCBkZWFkbGluZXMgYXJlIGFsc28gaW4gdGhlIHdpa2k6DQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcv d2cvZGlzcGF0Y2gvdHJhYy93aWtpDQpOb3RpbmcsIHRoYXQgdGhlIGRyYWZ0IGRlYWRsaW5lcyBh cmUgdGhlIHNhbWUgYXMgdGhlIElFVEYgZHJhZnQgZGVhZGxpbmVzLg0KDQpSZWdhcmRzLA0KTWFy eQ0KRElTUEFUQ0ggV0cgY28tY2hhaXINCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpkaXNwYXRjaCBtYWlsaW5nIGxpc3QNCmRpc3BhdGNoQGlldGYub3Jn DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQo= From gonzalo.camarillo@ericsson.com Fri Jun 21 08:18:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF6521F9EC0 for ; Fri, 21 Jun 2013 08:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.075 X-Spam-Level: X-Spam-Status: No, score=-106.075 tagged_above=-999 required=5 tests=[AWL=0.174, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XRjBjlpBBtBL for ; Fri, 21 Jun 2013 08:18:37 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 5399221F9E04 for ; Fri, 21 Jun 2013 08:18:36 -0700 (PDT) X-AuditID: c1b4fb25-b7f4c6d000004656-b4-51c46eca908a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 42.41.18006.ACE64C15; Fri, 21 Jun 2013 17:18:34 +0200 (CEST) Received: from [131.160.126.58] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Fri, 21 Jun 2013 17:18:34 +0200 Message-ID: <51C46EC9.5070908@ericsson.com> Date: Fri, 21 Jun 2013 18:18:33 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: DISPATCH References: <51C157BA.70509@ericsson.com> In-Reply-To: <51C157BA.70509@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+Jvre6pvCOBBu/XKFosnbSA1YHRY8mS n0wBjFFcNimpOZllqUX6dglcGX3dB5kKVgtXfHo2lbGB8RF/FyMnh4SAicSSbX9YIGwxiQv3 1rN1MXJxCAmcYpS4+eEDlLOGUeJC51l2kCpeAW2Jh896mUBsFgFVieYtjxhBbDYBC4ktt+6D TRIViJKYs+4BG0S9oMTJmU/A4iICChJ7Lx1gBbGFBewlWpe/BJsjJKAp0fcWYiangJbE3G1f WSEukpTY8qIdbC+zgJ7ElKstjBC2vMT2t3OYIXq1JZY/a2GZwCg4C8m6WUhaZiFpWcDIvIqR PTcxMye93GgTIzAAD275rbqD8c45kUOM0hwsSuK8H0/tChQSSE8sSc1OTS1ILYovKs1JLT7E yMTBKdXAaH4zr4dBifWWQ0Zih/CNKoFbXcuUUoyUrrW6PyuQOrt6ytyytIwnDTHuhQJMv2o/ XX5375bQ1PPJR7f//e607PTnuGg1QeHEv7wdcXPny2ukHTL/6PiApS3zYOOBN71HXwV+yC2Y psnnYi10WfD1V79LYQZ+rrFVlx6d2iXwbd7CSRN7zxl3KrEUZyQaajEXFScCAPrzHU4OAgAA Subject: [dispatch] Fwd: [RAI] RAI processes for handling work effectively X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Jun 2013 15:18:42 -0000 Folks, if you have any opinions on the following thread, which started with the email below, please send them to the RAI list: http://www.ietf.org/mail-archive/web/rai/current/msg01372.html Cheers, Gonzalo -------- Original Message -------- Subject: [RAI] RAI processes for handling work effectively Date: Wed, 19 Jun 2013 10:03:22 +0300 From: Gonzalo Camarillo To: Folks, as you know, in the RAI area we have always considered having effective processes to help us produce relevant and timely specifications a very important issue. When our environment has changed, we have sometimes modified or fine tuned our processes in order to continue being effective. A few examples (among many others) of such changes were the introduction of mentors, the old SIPPING process, P headers, and the current DISPATCH process. It is time for us to look at the current state of affairs and discuss whether or not we need to do certain things in a different way. In particular, we currently have a few groups (e.g., RTCWeb and CLUE) that work on higher-level constructions, which use elements developed in other working groups. For example, CLUE could potentially specify a mechanism that used mechanisms developed in MMUSIC or AVTEXT such as the offer/answer model and a number of RTP extensions. Note that what we called "higher-level constructions" above are referred to by different names by different people: architectures, applications, frameworks, etc. It does not really matter how we call them because this discussion is not about terminology and it is fairly clear what this type of work is about. The way this type of work is currently done in RAI requires the high-level WGs and the WGs developing the individual pieces to communicate often. Those communications are not always easy, since different WGs sometimes have different views on priorities, requirements, use cases, etc. What we would like to get your feedback on is: do we need a better way to handle this type of work in RAI or our current process is as good as it gets? Note that we are interested in getting constructive feedback and ideas on how to improve things. Please, focus your feedback on those aspects. Thanks, Gonzalo (on behalf of both RAI ADs) _______________________________________________ RAI mailing list RAI@ietf.org https://www.ietf.org/mailman/listinfo/rai From fas_vm@surguttel.ru Sat Jun 22 15:44:40 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66E2321F9EFF for ; Sat, 22 Jun 2013 15:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.206 X-Spam-Level: ** X-Spam-Status: No, score=2.206 tagged_above=-999 required=5 tests=[AWL=-1.400, BAYES_50=0.001, HELO_EQ_RU=0.595, HOST_EQ_RU=0.875, STOX_REPLY_TYPE=0.001, TVD_FINGER_02=2.134] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GA-UOT5xag-B for ; Sat, 22 Jun 2013 15:44:35 -0700 (PDT) Received: from mail.s86.ru (mail.s86.ru [217.8.80.233]) by ietfa.amsl.com (Postfix) with ESMTP id 928F021F9EA8 for ; Sat, 22 Jun 2013 15:44:35 -0700 (PDT) Received: by mail.s86.ru (Postfix, from userid 1116) id EA2E35138A3; Sun, 23 Jun 2013 04:43:43 +0600 (YEKT) Received: from Gateway (unknown [151.252.66.235]) by mail.s86.ru (Postfix) with ESMTPA id B129251385F; Sun, 23 Jun 2013 04:43:40 +0600 (YEKT) Message-ID: From: "Anton Tveretin" To: "Cullen Jennings \(fluffy\)" References: <84E37CB1D3B646C9B5D4919D724BAFF3@Gateway> Date: Sun, 23 Jun 2013 04:36:30 +0600 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="Windows-1252"; reply-type=original Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 X-Antivirus: avast! (VPS 130622-1, 22.06.2013), Outbound message X-Antivirus-Status: Clean Cc: dispatch@ietf.org Subject: Re: [dispatch] New I-D X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 Jun 2013 22:44:40 -0000 No, applicability is different. And I want SIP to be as powerful as at least POTS (with a fax modem). Or, anyone thinks that progress is something else? ----- Original Message ----- From: "Cullen Jennings (fluffy)" To: "Anton Tveretin" Cc: Sent: Tuesday, June 18, 2013 8:29 PM Subject: Re: [dispatch] New I-D Just as one trivial thought … You might want to talk to the authors of draft-saito-mmusic-sdp-ike-01 (RFC 6193). That draft was pretty controversial - the main issue was around if that was an appropriate use of SIP or not and this draft might have similar issues. On Jun 17, 2013, at 7:05 AM, Anton Tveretin wrote: > Dear All, > The I-D is not new, it is exactly the same that I published in May, yet > converted into XML. Questions are the same. > http://www.ietf.org/id/draft-tveretin-dispatch-l2tp-sdp-00.txt > - Anton Tveretin > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Mon Jun 24 01:03:36 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F23F121F9B85 for ; Mon, 24 Jun 2013 01:03:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EePi7xpctrx5 for ; Mon, 24 Jun 2013 01:03:34 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 048AC21F9AF8 for ; Mon, 24 Jun 2013 01:03:33 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 9C2D893C1AF; Mon, 24 Jun 2013 08:03:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" Date: Mon, 24 Jun 2013 10:03:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3BBDAFAA-BF30-45AF-B4C9-1D613CCF59D0@edvina.net> References: <20130624075730.20790.23082.idtracker@ietfa.amsl.com> To: "dispatch@ietf.org list" X-Mailer: Apple Mail (2.1503) Subject: [dispatch] Fwd: New Version Notification for draft-johansson-sip-dual-stack-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 08:03:36 -0000 Hi! We have submitted a short draft that updates RFC 3263 so that dual stack = SIP user agents=20 have to look up both A and AAAA records. RFC 3263 suggests "A or AAAA" = records. Please give feedback and guide us through the dispatch process! Regards, /Olle E. Johansson >=20 >=20 >=20 >=20 > A new version of I-D, draft-johansson-sip-dual-stack-00.txt > has been successfully submitted by Olle E. Johansson and posted to the > IETF repository. >=20 > Filename: draft-johansson-sip-dual-stack > Revision: 00 > Title: Locating SIP servers in a dual stack IP network > Creation date: 2013-06-24 > Group: Individual Submission > Number of pages: 5 > URL: = http://www.ietf.org/internet-drafts/draft-johansson-sip-dual-stack-00.txt > Status: = http://datatracker.ietf.org/doc/draft-johansson-sip-dual-stack > Htmlized: = http://tools.ietf.org/html/draft-johansson-sip-dual-stack-00 >=20 >=20 > Abstract: > RFC 3263 defines how a SIP implementation given an URL should locate > the next hop SIP server using DNS. The RFC repeatedly states that > the implementation should look up IPv4 or IPv6 addresses, which is > not a good solution considering the issues that lead to the > development of Happy Eyeballs (RFC XXX). This document corrects = this > behaviour for dual stack SIP implementations so that an > implementation so that an implementation should look up both IPv4 = and > IPv6 addresses. This way, the implementation can find the best > network flow and have a greater chance in success in reaching the > service. >=20 > This document also clarifies DNS SRV usage for single stack clients. >=20 From brett@broadsoft.com Mon Jun 24 04:06:42 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3579A21F99C5 for ; Mon, 24 Jun 2013 04:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.289 X-Spam-Level: X-Spam-Status: No, score=-1.289 tagged_above=-999 required=5 tests=[AWL=-0.710, BAYES_00=-2.599, LOCALPART_IN_SUBJECT=2.02] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFhroJ7g19h3 for ; Mon, 24 Jun 2013 04:06:37 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.21]) by ietfa.amsl.com (Postfix) with ESMTP id 6391311E8128 for ; Mon, 24 Jun 2013 04:06:36 -0700 (PDT) Received: from CASUMHUB03.citservers.local (172.16.98.219) by smtpedge.partnerhosted.com (172.16.98.247) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 24 Jun 2013 04:10:11 -0700 Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB03.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 24 Jun 2013 04:10:11 -0700 From: Brett Tate To: "draft-johansson-sip-dual-stack@tools.ietf.org" , "dispatch@ietf.org" Thread-Topic: draft-johansson-sip-dual-stack: reason to alter RFC 3263? Thread-Index: Ac5wyuKsJgxj/seaTMWf0ZrLzhgw7w== Date: Mon, 24 Jun 2013 11:10:10 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196B82B0@MBX07.citservers.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:06:42 -0000 Hi, Concerning draft-johansson-sip-dual-stack, my comment is that the draft sho= uld provide better justification to alter RFC 3263. As indicated within section 4, SRV records can be used to better control if= both IPv6 and IPv4 should be tried prior to the next set of IPv6 and IPv4 = addresses. As far as I know, the main reason to alter RFC 3263 would be fo= r a better experience when SRV is not supported. What are the other reason= s? There are various SRV, A, and AAAA DNS combinations already deployed based = upon RFC 3263. Is the draft going to provide guidelines about the transiti= on from devices/networks based upon RFC 3263 to those based upon the draft? For instance if the network is currently configured to attempt A or AAAA to= device before advancing to next SRV location, this draft would cause the d= ual stack device to attempt both A and AAAA before advancing to next SRV lo= cation; this could introduce unintended extra delays during call setup. Ho= w would the dual stack device know if the DNS configuration was based upon = RFC 3263 or this draft? Thanks, Brett This email is intended solely for the person or entity to which it is addre= ssed and may contain confidential and/or privileged information. If you are= not the intended recipient and have received this email in error, please n= otify BroadSoft, Inc. immediately by replying to this message, and destroy = all copies of this message, along with any attachment, prior to reading, di= stributing or copying it. From oej@edvina.net Mon Jun 24 04:18:53 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70DE421F9C9E for ; Mon, 24 Jun 2013 04:18:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oE9+owgsJcR5 for ; Mon, 24 Jun 2013 04:18:52 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0E06621F9C68 for ; Mon, 24 Jun 2013 04:18:50 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 8079393C1AF; Mon, 24 Jun 2013 11:18:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196B82B0@MBX07.citservers.local> Date: Mon, 24 Jun 2013 13:18:48 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7D451570-072B-4820-84DF-43252D1CFBEF@edvina.net> References: <576A8B541C219D4E9CEB1DF8C19C7B88196B82B0@MBX07.citservers.local> To: Brett Tate X-Mailer: Apple Mail (2.1503) Cc: "draft-johansson-sip-dual-stack@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 11:18:53 -0000 24 jun 2013 kl. 13:10 skrev Brett Tate : > Hi, >=20 > Concerning draft-johansson-sip-dual-stack, my comment is that the = draft should provide better justification to alter RFC 3263. >=20 > As indicated within section 4, SRV records can be used to better = control if both IPv6 and IPv4 should be tried prior to the next set of = IPv6 and IPv4 addresses. As far as I know, the main reason to alter RFC = 3263 would be for a better experience when SRV is not supported. What = are the other reasons? To prepare for a happy-eyeballs solution. Right now if a device looks up = IPv6 and not IPv4 it may fail miserably. The "or" should not be there. We've proven at SIPit that UAs have no failover or a 32 second (64*T1) = timeout before retrying with another address family. To be able to fail = over to the other network flow, you need to resolve the addresses. >=20 > There are various SRV, A, and AAAA DNS combinations already deployed = based upon RFC 3263. Is the draft going to provide guidelines about the = transition from devices/networks based upon RFC 3263 to those based upon = the draft? It doesn't change the records, it change how the UA looks them up. >=20 > For instance if the network is currently configured to attempt A or = AAAA to device before advancing to next SRV location, this draft would = cause the dual stack device to attempt both A and AAAA before advancing = to next SRV location; Yes. > this could introduce unintended extra delays during call setup. How? > How would the dual stack device know if the DNS configuration was = based upon RFC 3263 or this draft? I don't follow you here. What's the difference in DNS configuration? Are you suggesting that if we're in the situation that forced Happy = Eyeballs - a working IPv4 and an IPv6 tunnel that is closed by the = firewall we should try IPv6, fail, then move to the next priority when = the DNS publishes both A and AAAA records for the name we're looking up? The "how to set up a connection" issues will be targeted by a separate = draft. We do need to look into a Happy Eyeballs solution for UDP and = have so far not succeeded. Any help is appreciated. /O >=20 > Thanks, > Brett >=20 > This email is intended solely for the person or entity to which it is = addressed and may contain confidential and/or privileged information. If = you are not the intended recipient and have received this email in = error, please notify BroadSoft, Inc. immediately by replying to this = message, and destroy all copies of this message, along with any = attachment, prior to reading, distributing or copying it. > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From brett@broadsoft.com Mon Jun 24 05:43:34 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 769AC21E80F0 for ; Mon, 24 Jun 2013 05:43:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.944 X-Spam-Level: X-Spam-Status: No, score=-1.944 tagged_above=-999 required=5 tests=[AWL=0.655, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kFq8bxDvBfLe for ; Mon, 24 Jun 2013 05:43:29 -0700 (PDT) Received: from smtpout01.partnerhosted.com (smtpout01.partnerhosted.com [173.225.22.204]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8A521E80DF for ; Mon, 24 Jun 2013 05:43:27 -0700 (PDT) Received: from CASUMHUB04.citservers.local (172.16.98.225) by Xedge02.citservers.local (172.16.98.248) with Microsoft SMTP Server (TLS) id 14.2.247.3; Mon, 24 Jun 2013 05:47:04 -0700 Received: from MBX07.citservers.local ([fe80::d9a5:240b:376a:aeb6]) by CASUMHUB04.citservers.local ([::1]) with mapi id 14.02.0247.003; Mon, 24 Jun 2013 05:47:03 -0700 From: Brett Tate To: "Olle E. Johansson" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263? Thread-Index: AQHOcM0d9NCKowuxwEGEgJzHhbmz0JlEue3Q Date: Mon, 24 Jun 2013 12:47:03 +0000 Message-ID: <576A8B541C219D4E9CEB1DF8C19C7B88196B82EE@MBX07.citservers.local> References: <576A8B541C219D4E9CEB1DF8C19C7B88196B82B0@MBX07.citservers.local> <7D451570-072B-4820-84DF-43252D1CFBEF@edvina.net> In-Reply-To: <7D451570-072B-4820-84DF-43252D1CFBEF@edvina.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.16.98.77] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:43:34 -0000 > > As indicated within section 4, SRV records can be used=20 > > to better control if both IPv6 and IPv4 should be tried=20 > > prior to the next set of IPv6 and IPv4 addresses. As=20 > > far as I know, the main reason to alter RFC 3263 would=20 > > be for a better experience when SRV is not supported. > > What are the other reasons? > > To prepare for a happy-eyeballs solution. Right now if a=20 > device looks up IPv6 and not IPv4 it may fail miserably. =20 > The "or" should not be there. > > We've proven at SIPit that UAs have no failover or a=20 > 32 second (64*T1) timeout before retrying with another=20 > address family. To be able to fail over to the other=20 > network flow, you need to resolve the addresses. If the device cannot failover, the device still cannot failover after this = becomes an RFC unless the reason was because it did not support SRV. The slow failover is not unique to IPv6 switch to IPv4. It can occur durin= g the failover between IPv4 addresses. Many vendors use a timer to failove= r more quickly; if needed, the timer can become standardized for use. > > There are various SRV, A, and AAAA DNS combinations=20 > > already deployed based upon RFC 3263. Is the draft=20 > > going to provide guidelines about the transition from=20 > > devices/networks based upon RFC 3263 to those based > > upon the draft? > > It doesn't change the records, it change how the UA=20 > looks them up. It changes how they get used. More specifically, it would alter the attemp= ted order of where requests get sent. For instance, DNS SRV, AAAA, and A results indicate to try 1) Bv4 or Bv6, 2= ) Cv4, and 3) Bv4. Assuming number 1 was because of the RFC 3263 "A or AAA= A record lookup" snippet that is being changed by this draft, the attempted= order changes because of the draft to be 1) Bv4 or Bv6, 2) Bv4 or Bv6, 3) = Cv4, and 4) Bv4. NOTE: the above reflects the DNS results without the optimization to bypass= a previously tried location. With the optimization, there would be no "4)= Bv4". > > How would the dual stack device know if the DNS=20 > > configuration was based upon RFC 3263 or this draft? > > I don't follow you here. What's the difference in=20 > DNS configuration? The difference is attempted order (and potentially number of locations) bas= ed upon the SRV, AAAA, and A results. > Are you suggesting that if we're in the situation that=20 > forced Happy Eyeballs - a working IPv4 and an IPv6 tunnel=20 > that is closed by the firewall we should try IPv6, fail,=20 > then move to the next priority when the DNS publishes both=20 > A and AAAA records for the name we're looking up? Per RFC 3261, yes it moves to the next SRV record of the same or lower prio= rity. This may or may not be the same attempted order and number of locati= ons that are being caused the draft. If the admin knows that the failure is typically caused by maintenance or o= verload, why would they want to try both AAAA and A to the same server befo= re advancing to the next server? The admin would need to adjust the DNS co= nfiguration per the draft to produce the same desired result they were gett= ing with RFC 3263. Thanks, Brett From oej@edvina.net Mon Jun 24 05:57:38 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37FD511E813A for ; Mon, 24 Jun 2013 05:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbwIjPgVP3FA for ; Mon, 24 Jun 2013 05:57:37 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75B11E812F for ; Mon, 24 Jun 2013 05:57:35 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7F93193C2A1; Mon, 24 Jun 2013 12:57:33 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\)) From: "Olle E. Johansson" In-Reply-To: <576A8B541C219D4E9CEB1DF8C19C7B88196B82EE@MBX07.citservers.local> Date: Mon, 24 Jun 2013 14:57:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <576A8B541C219D4E9CEB1DF8C19C7B88196B82B0@MBX07.citservers.local> <7D451570-072B-4820-84DF-43252D1CFBEF@edvina.net> <576A8B541C219D4E9CEB1DF8C19C7B88196B82EE@MBX07.citservers.local> To: Brett Tate X-Mailer: Apple Mail (2.1503) Cc: "dispatch@ietf.org" Subject: Re: [dispatch] draft-johansson-sip-dual-stack: reason to alter RFC 3263? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 12:57:38 -0000 24 jun 2013 kl. 14:47 skrev Brett Tate : >>> As indicated within section 4, SRV records can be used=20 >>> to better control if both IPv6 and IPv4 should be tried=20 >>> prior to the next set of IPv6 and IPv4 addresses. As=20 >>> far as I know, the main reason to alter RFC 3263 would=20 >>> be for a better experience when SRV is not supported. >>> What are the other reasons? >>=20 >> To prepare for a happy-eyeballs solution. Right now if a=20 >> device looks up IPv6 and not IPv4 it may fail miserably. =20 >> The "or" should not be there. >>=20 >> We've proven at SIPit that UAs have no failover or a=20 >> 32 second (64*T1) timeout before retrying with another=20 >> address family. To be able to fail over to the other=20 >> network flow, you need to resolve the addresses. >=20 > If the device cannot failover, the device still cannot failover after = this becomes an RFC unless the reason was because it did not support = SRV. >=20 > The slow failover is not unique to IPv6 switch to IPv4. It can occur = during the failover between IPv4 addresses. Many vendors use a timer to = failover more quickly; if needed, the timer can become standardized for = use. >=20 >=20 >>> There are various SRV, A, and AAAA DNS combinations=20 >>> already deployed based upon RFC 3263. Is the draft=20 >>> going to provide guidelines about the transition from=20 >>> devices/networks based upon RFC 3263 to those based >>> upon the draft? >>=20 >> It doesn't change the records, it change how the UA=20 >> looks them up. >=20 > It changes how they get used. More specifically, it would alter the = attempted order of where requests get sent. >=20 > For instance, DNS SRV, AAAA, and A results indicate to try 1) Bv4 or = Bv6, 2) Cv4, and 3) Bv4. Assuming number 1 was because of the RFC 3263 = "A or AAAA record lookup" snippet that is being changed by this draft, = the attempted order changes because of the draft to be 1) Bv4 or Bv6, 2) = Bv4 or Bv6, 3) Cv4, and 4) Bv4. I've left it quite open - deliberately - in this draft how the = connections should happen, since I believe that has to be solved in = another document. Maybe that's wrong. I do believe we need to use a Happy Eyeballs-like solution so that we = connect to 1) Bv4 and Bv6, 2 Cv4, 3 Bv4 The problem with http was that it took 19 seconds for a web browser to = try another address family.=20 In SIP, with default timers (which hopefully is not used), it will take = 32 seconds. This is definitely not a happy situation. >=20 > NOTE: the above reflects the DNS results without the optimization to = bypass a previously tried location. With the optimization, there would = be no "4) Bv4". >=20 >=20 >>> How would the dual stack device know if the DNS=20 >>> configuration was based upon RFC 3263 or this draft? >>=20 >> I don't follow you here. What's the difference in=20 >> DNS configuration? >=20 > The difference is attempted order (and potentially number of = locations) based upon the SRV, AAAA, and A results. Assuming that we don't try IPv4 and IPv6 at the same time. >=20 >=20 >> Are you suggesting that if we're in the situation that=20 >> forced Happy Eyeballs - a working IPv4 and an IPv6 tunnel=20 >> that is closed by the firewall we should try IPv6, fail,=20 >> then move to the next priority when the DNS publishes both=20 >> A and AAAA records for the name we're looking up? >=20 > Per RFC 3261, yes it moves to the next SRV record of the same or lower = priority. This may or may not be the same attempted order and number of = locations that are being caused the draft. >=20 > If the admin knows that the failure is typically caused by maintenance = or overload, why would they want to try both AAAA and A to the same = server before advancing to the next server? The admin would need to = adjust the DNS configuration per the draft to produce the same desired = result they were getting with RFC 3263. YOu are assuming that the AAAA and A records are the very same server. = That may not be the case at all. Thanks for your feedback. Much food for thought. /O >=20 > Thanks, > Brett >=20 From eckelcu@cisco.com Mon Jun 24 09:59:26 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F34DC11E816F for ; Mon, 24 Jun 2013 09:59:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A+x7X7Y8Tp9a for ; Mon, 24 Jun 2013 09:59:21 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 1149411E816B for ; Mon, 24 Jun 2013 09:59:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3704; q=dns/txt; s=iport; t=1372093161; x=1373302761; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=5QXjxpd5TWsbyeQ+T3ZUK7FAysg2EI3fKLWq5CxqmlU=; b=ejoToGfYMkvnJUSPaWThXC39Q5HEKTCkEvsWcRMcB/+tQxfTOr63ZR1g h5tRO/FQ1IP77UQiS66gylbaneYZf4GKT1rhBI3x32l/LcZMCDBOeRUJz NhlZT7jY6I+THG9dz2YH7K3GslFx4BOMqIC3GBXV/vy921FVSQ8FTDh8y U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAIJ5yFGtJV2b/2dsb2JhbABbgwkxSb84gQYWdIIjAQEBBAEBATc0FwQCAQgRAwEBAQsUCQcnCxQJCAIEARIIAYgFDLpdjg0QgQEGLQUGgnxhA5NxlRaDEIFxNw X-IronPort-AV: E=Sophos;i="4.87,929,1363132800"; d="scan'208";a="223767530" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-9.cisco.com with ESMTP; 24 Jun 2013 16:59:20 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r5OGxKa7012547 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 24 Jun 2013 16:59:20 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.187]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.02.0318.004; Mon, 24 Jun 2013 11:59:20 -0500 From: "Charles Eckel (eckelcu)" To: Gonzalo Camarillo , DISPATCH Thread-Topic: [dispatch] Fwd: [RAI] RAI processes for handling work effectively Thread-Index: AQHObLsiycD7tTlSOUWEtETYQNx59JlAn4qAgARYdmA= Date: Mon, 24 Jun 2013 16:59:19 +0000 Message-ID: <92B7E61ADAC1BB4F941F943788C08828048991E5@xmb-aln-x08.cisco.com> References: <51C157BA.70509@ericsson.com> <51C46EC9.5070908@ericsson.com> In-Reply-To: <51C46EC9.5070908@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.61.110.30] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Fwd: [RAI] RAI processes for handling work effectively X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2013 16:59:26 -0000 Hi Gonzalo, I think it would be helpful to have an RAI area meeting, in which there is = a brief summary by each working group chair of the main topics/drafts to be= discussed at the given IETF. This would serve as a way for those attending= the session to hear about things they may not have been tracking closely (= i.e. not yet aware of or subscribed to the working group alias or missed th= e announcement of a draft). This would help bring synergies, conflicts, or = duplication of efforts to light much earlier and provide a forum in which t= o discuss how best to address them.=20 Cheers, Charles > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On > Behalf Of Gonzalo Camarillo > Sent: Friday, June 21, 2013 5:19 PM > To: DISPATCH > Subject: [dispatch] Fwd: [RAI] RAI processes for handling work effectivel= y >=20 > Folks, >=20 > if you have any opinions on the following thread, which started with the > email below, please send them to the RAI list: >=20 > http://www.ietf.org/mail-archive/web/rai/current/msg01372.html >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > -------- Original Message -------- > Subject: [RAI] RAI processes for handling work effectively > Date: Wed, 19 Jun 2013 10:03:22 +0300 > From: Gonzalo Camarillo > To: >=20 > Folks, >=20 > as you know, in the RAI area we have always considered having effective > processes to help us produce relevant and timely specifications a very > important issue. When our environment has changed, we have sometimes > modified or fine tuned our processes in order to continue being > effective. A few examples (among many others) of such changes were the > introduction of mentors, the old SIPPING process, P headers, and the > current DISPATCH process. >=20 > It is time for us to look at the current state of affairs and discuss > whether or not we need to do certain things in a different way. >=20 > In particular, we currently have a few groups (e.g., RTCWeb and CLUE) > that work on higher-level constructions, which use elements developed in > other working groups. For example, CLUE could potentially specify a > mechanism that used mechanisms developed in MMUSIC or AVTEXT such as > the > offer/answer model and a number of RTP extensions. >=20 > Note that what we called "higher-level constructions" above are referred > to by different names by different people: architectures, applications, > frameworks, etc. It does not really matter how we call them because this > discussion is not about terminology and it is fairly clear what this > type of work is about. >=20 > The way this type of work is currently done in RAI requires the > high-level WGs and the WGs developing the individual pieces to > communicate often. Those communications are not always easy, since > different WGs sometimes have different views on priorities, > requirements, use cases, etc. >=20 > What we would like to get your feedback on is: do we need a better way > to handle this type of work in RAI or our current process is as good as > it gets? >=20 > Note that we are interested in getting constructive feedback and ideas > on how to improve things. Please, focus your feedback on those aspects. >=20 > Thanks, >=20 > Gonzalo > (on behalf of both RAI ADs) >=20 > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai >=20 >=20 >=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From mary.ietf.barnes@gmail.com Tue Jun 25 11:50:07 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAFB11E813A for ; Tue, 25 Jun 2013 11:50:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wsp-fgq7Li9L for ; Tue, 25 Jun 2013 11:50:05 -0700 (PDT) Received: from mail-qe0-x22a.google.com (mail-qe0-x22a.google.com [IPv6:2607:f8b0:400d:c02::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 8231D11E8136 for ; Tue, 25 Jun 2013 11:50:05 -0700 (PDT) Received: by mail-qe0-f42.google.com with SMTP id s14so690401qeb.29 for ; Tue, 25 Jun 2013 11:50:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=Pqhwe+DbowGZkr/3pWowlnk4dl5wSMz2EUYTcnOuors=; b=F03tBWZRNQZqRGPnPunTFyqCjouONml0SX7lQNSfrnSuZhIaAg/SlfSChSIBkeiohD QbcIDNWxRsLTt3GlTeiNtPevEBEg8kxC+960R0B3BK5E8950ylmg0CQXGfSgnAZjr3IK NpldrF74c4W5amMhguOyLK86QcWO0ZP4czmDTsrnE6j+SAS04qzHAL0CwzXW2p9mKzj+ aoYR+ngGah9lwrRXda4xMpcOd7MPFRoTixb1yD1XpXk8BZzc9XP73JxSOaqcZgAATzBD janqEElr0mTYe+0TzPQyCB4PTGnk5rlUAmriMlvBUkay8A8UiJ1ihsOs/stkoDiPpAMI 3dwQ== MIME-Version: 1.0 X-Received: by 10.224.147.145 with SMTP id l17mr1469059qav.3.1372186204907; Tue, 25 Jun 2013 11:50:04 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Tue, 25 Jun 2013 11:50:04 -0700 (PDT) Date: Tue, 25 Jun 2013 13:50:04 -0500 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: text/plain; charset=ISO-8859-1 Cc: Cullen Jennings , Richard Barnes Subject: [dispatch] Progressing draft-worley-service-example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 18:50:07 -0000 Hi all, This document got orphaned when the BLISS WG closed and discussions in the past with ADs indicated that it could be AD sponsored. We would like to request folks to review this document and provide any comments and raise any concerns about it being progressed as AD sponsored no later than July 10th, 2013 (2 weeks time). http://datatracker.ietf.org/doc/draft-worley-service-example/ Thanks, Mary. From nneelakantan@sonusnet.com Tue Jun 25 12:42:06 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6324E11E8137 for ; Tue, 25 Jun 2013 12:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgoHLS6IC-gX for ; Tue, 25 Jun 2013 12:42:01 -0700 (PDT) Received: from p01c12o143.mxlogic.net (p01c12o143.mxlogic.net [208.65.145.66]) by ietfa.amsl.com (Postfix) with ESMTP id 8917A21E809B for ; Tue, 25 Jun 2013 12:41:59 -0700 (PDT) Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o143.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id 782f9c15.2acfb361e940.139615.00-584.359037.p01c12o143.mxlogic.net (envelope-from ); Tue, 25 Jun 2013 13:41:59 -0600 (MDT) X-MXL-Hash: 51c9f2875ce66194-df13373b16121dbf7372a4e0d5b413451c921fa3 Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o143.mxlogic.net(mxl_mta-7.1.0-3) over TLS secured channel with ESMTP id 482f9c15.0.139602.00-284.358994.p01c12o143.mxlogic.net (envelope-from ); Tue, 25 Jun 2013 13:41:58 -0600 (MDT) X-MXL-Hash: 51c9f2863a87f779-60ac7cfdff87c1124e8fc3d90a2c466d8c05e36d Received: from USMA-EX-MB2.sonusnet.com ([fe80::c51d:eb9c:bce7:e4b0]) by usma-ex-hub1.sonusnet.com ([2002:42cb:5a10::42cb:5a10]) with mapi id 14.02.0342.003; Tue, 25 Jun 2013 15:41:55 -0400 From: "Neelakantan, Neel" To: "Klatsky, Carl" , "'dispatch@ietf.org'" Thread-Topic: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: Ac5i1sUwgbY1hhy+RLyzNz7nciXYZgPBTYBw Date: Tue, 25 Jun 2013 19:41:54 +0000 Message-ID: <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> In-Reply-To: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.37] Content-Type: multipart/alternative; boundary="_000_56EB3FF5A53614438D93B3325407DBE576F314USMAEXMB2sonusnet_" MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=C+ZeP3z+ c=1 sm=1 a=ed0SwufR/ZNkx8DvM7kK7A==:17 a] X-AnalysisOut: [=kxZvkmloRasA:10 a=YCjQDKGAcrgA:10 a=URNJFqk9g_oA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=xqWC_Br6kY4A:10 a=kUVcWBOSAAAA:8 a=nzeCThAn] X-AnalysisOut: [UHUA:10 a=48vgC7mUAAAA:8 a=fkbd4o5FPS_X0Ceona0A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=lZB815dzVvQA:10 a=r7eeTOYKyZWuMDpA:21 a=m0V7rK] X-AnalysisOut: [UF63W-Y3LI:21 a=yMhMjlubAAAA:8 a=SSmOFEACAAAA:8 a=5YpaQDzY] X-AnalysisOut: [AhJQUcMgWMwA:9 a=gKO2Hq4RSVkA:10 a=UiCQ7L4-1S4A:10 a=hTZeC] X-AnalysisOut: [7Yk6K0A:10 a=frz4AuCg-hUA:10 a=ZMIGURhGNlwO9Toa:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.147.176.212] Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jun 2013 19:42:06 -0000 --_000_56EB3FF5A53614438D93B3325407DBE576F314USMAEXMB2sonusnet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Section 3 should have a brief description about IPv6 address handling, wher= e there could be IPv6 addresses on various SIP headers in the SIP message a= nd provide a general approach to handle these. All the subsections are spe= cial case of this general guideline. In other words, it will be good to talk about URI portion which might have = ipv6 headers and how this should be handled. Additionally, from/to headers could have IPv6 address. Thanks, Neel. From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Klatsky, Carl Sent: Thursday, June 06, 2013 11:56 AM To: 'dispatch@ietf.org' Subject: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impac= t-ipv4 Hi, The draft noted below was just submitted. Soliciting feedback on the docum= ent and asking for direction on how proceed with this document. Thanks. Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 Revision: 00 Title: Interoperability Impacts of IPv6 Interworking w= ith Existing IPv4 SIP Implementations Creation date: 2013-06-04 Group: Individual Submission Number of pages: 8 URL: http://www.ietf.org/internet-drafts/draft-klatsky-dispatch= -ipv6-impact-ipv4-00.txt Regards, Carl Klatsky --_000_56EB3FF5A53614438D93B3325407DBE576F314USMAEXMB2sonusnet_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Section 3 should have = a brief description about IPv6 address handling, where there could be IPv6 = addresses on various SIP headers in the SIP message and provide a general a= pproach to handle these.  All the subsections are special case of this general guideline.

 

In other words, it wil= l be good to talk about URI portion which might have ipv6 headers and how t= his should be handled.

 

Additionally, from/to = headers could have IPv6 address.

 

 

Thanks,

Neel.

 

 

From: dispatch= -bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Klatsky, Carl
Sent: Thursday, June 06, 2013 11:56 AM
To: 'dispatch@ietf.org'
Subject: [dispatch] Initial submission of draft-klatsky-dispatch-ipv= 6-impact-ipv4

 

Hi,

 

The draft noted below was just submitted.  Soli= citing feedback on the document and asking for direction on how proceed wit= h this document.  Thanks.

 

Filename:      &nbs= p;     draft-klatsky-dispatch-ipv6-impact-ipv4

Revision:      &nbs= p;       00

Title:       &= nbsp;           &nbs= p;  Interoperability Impacts of IPv6 Interworking with Existing IPv4 S= IP Implementations

Creation date:   2013-06-04<= /p>

Group:       &= nbsp;          Individual Subm= ission

Number of pages: 8

URL:       &nb= sp;     http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv4= -00.txt

 

 

 

Regards,

Carl Klatsky

--_000_56EB3FF5A53614438D93B3325407DBE576F314USMAEXMB2sonusnet_-- From oej@edvina.net Wed Jun 26 01:04:46 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4EC1711E81A2 for ; Wed, 26 Jun 2013 01:04:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RKlC+0VMjWMj for ; Wed, 26 Jun 2013 01:04:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 8913011E819E for ; Wed, 26 Jun 2013 01:04:45 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id A9F2F93C1AF; Wed, 26 Jun 2013 08:04:44 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Wed, 26 Jun 2013 10:04:44 +0200 Content-Transfer-Encoding: 7bit Message-Id: <3AAADE4D-4C89-4B3C-9AEB-8D5C5C1454C2@edvina.net> References: To: Mary Barnes X-Mailer: Apple Mail (2.1508) Cc: Cullen Jennings , Richard Barnes , DISPATCH Subject: Re: [dispatch] Progressing draft-worley-service-example X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:04:46 -0000 25 jun 2013 kl. 20:50 skrev Mary Barnes : > Hi all, > > This document got orphaned when the BLISS WG closed and discussions in > the past with ADs indicated that it could be AD sponsored. We would > like to request folks to review this document and provide any comments > and raise any concerns about it being progressed as AD sponsored no > later than July 10th, 2013 (2 weeks time). > http://datatracker.ietf.org/doc/draft-worley-service-example/ > I think it's a good and informative document and have no concerns with it making progress. /O From oej@edvina.net Wed Jun 26 01:13:51 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB6E921E80D7 for ; Wed, 26 Jun 2013 01:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ioIiYZe9v5wc for ; Wed, 26 Jun 2013 01:13:45 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id F378E21E8089 for ; Wed, 26 Jun 2013 01:13:42 -0700 (PDT) Received: from [192.168.40.16] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 3E98793C2A1; Wed, 26 Jun 2013 08:13:42 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_93C186DF-CE1D-4A63-95CD-6F106FAC25E4" Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> Date: Wed, 26 Jun 2013 10:13:41 +0200 Message-Id: <807CCE02-B653-49B5-BBAA-AD84B842EB7B@edvina.net> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> To: "Neelakantan, Neel" X-Mailer: Apple Mail (2.1508) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 08:13:51 -0000 --Apple-Mail=_93C186DF-CE1D-4A63-95CD-6F106FAC25E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 25 jun 2013 kl. 21:41 skrev "Neelakantan, Neel" = : > Section 3 should have a brief description about IPv6 address handling, = where there could be IPv6 addresses on various SIP headers in the SIP = message and provide a general approach to handle these. All the = subsections are special case of this general guideline. > =20 > In other words, it will be good to talk about URI portion which might = have ipv6 headers and how this should be handled. > =20 > Additionally, from/to headers could have IPv6 address. We tried to avoid listing ALL possibly headers that could have IPv6 = headers, because that will be a moving target. We want to alert the = developer with a few cases that we've seen in real life. In the next release we're adding an appendix with more information about = using IPv6 in the URI. Thank you for your feedback. /O > =20 > =20 > Thanks, > Neel. > =20 > =20 > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On = Behalf Of Klatsky, Carl > Sent: Thursday, June 06, 2013 11:56 AM > To: 'dispatch@ietf.org' > Subject: [dispatch] Initial submission of = draft-klatsky-dispatch-ipv6-impact-ipv4 > =20 > Hi, > =20 > The draft noted below was just submitted. Soliciting feedback on the = document and asking for direction on how proceed with this document. = Thanks. > =20 > Filename: draft-klatsky-dispatch-ipv6-impact-ipv4 > Revision: 00 > Title: Interoperability Impacts of IPv6 = Interworking with Existing IPv4 SIP Implementations > Creation date: 2013-06-04 > Group: Individual Submission > Number of pages: 8 > URL: = http://www.ietf.org/internet-drafts/draft-klatsky-dispatch-ipv6-impact-ipv= 4-00.txt > =20 > =20 > =20 > Regards, > Carl Klatsky > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_93C186DF-CE1D-4A63-95CD-6F106FAC25E4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
25 jun 2013 kl. = 21:41 skrev "Neelakantan, Neel" <nneelakantan@sonusnet.com>= ;:

Section = 3 should have a brief description about IPv6 address handling, where = there could be IPv6 addresses on various SIP headers in the SIP message = and provide a general approach to handle these.  All the = subsections are special case of this general = guideline.
 
In = other words, it will be good to talk about URI portion which might have = ipv6 headers and how this should be handled.
Additionally, from/to headers could have IPv6 = address.
We tried to avoid listing = ALL possibly headers that could have IPv6 headers, because that will be = a moving target. We want to alert the developer with a few cases that = we've seen in real life.

In the next release = we're adding an appendix with more information about using IPv6 in the = URI.

Thank you for your = feedback.

/O
 
 
Neel.
 
_______________________________= ________________
dispatch mailing list
dispatch@ietf.org
, "mmusic@ietf.org" , "dispatch@ietf.org" Date: Wed, 26 Jun 2013 17:04:52 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099Q Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> In-Reply-To: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.6.26.131226 Subject: [dispatch] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:05:00 -0000 Dear all, I submitted this short I-D to explain how PCP can be used in IPv6 SIP deplo= yments (with a focus on the managed networks case). Cheers, Med -----Message d'origine----- De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org]= De la part de internet-drafts@ietf.org Envoy=E9=A0: mercredi 26 juin 2013 15:40 =C0=A0: i-d-announce@ietf.org Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : PCP for IPv6-enabled SIP Deployments Author(s) : Mohamed Boucadair Filename : draft-boucadair-pcp-sip-ipv6-00.txt Pages : 7 Date : 2013-06-26 Abstract: This document discusses how PCP can be used in IPv6-enabled SIP deployments. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 There's also a htmlized version available at: http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From pkyzivat@alum.mit.edu Wed Jun 26 08:41:45 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00C21F9D76 for ; Wed, 26 Jun 2013 08:41:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.168 X-Spam-Level: X-Spam-Status: No, score=-0.168 tagged_above=-999 required=5 tests=[AWL=0.269, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VDPPaY8dptwN for ; Wed, 26 Jun 2013 08:41:40 -0700 (PDT) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:17]) by ietfa.amsl.com (Postfix) with ESMTP id 3F82A21F9971 for ; Wed, 26 Jun 2013 08:41:40 -0700 (PDT) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by qmta10.westchester.pa.mail.comcast.net with comcast id szeP1l0041ei1Bg5A3hfER; Wed, 26 Jun 2013 15:41:39 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id t3hf1l00W3ZTu2S3k3hfRS; Wed, 26 Jun 2013 15:41:39 +0000 Message-ID: <51CB0BB2.8050804@alum.mit.edu> Date: Wed, 26 Jun 2013 11:41:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: dispatch@ietf.org References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6F1ED@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6F1ED@VOEXM31W.internal.vodafone.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1372261299; bh=Og/x/ecKMZfPtZ0Y8n+H71XV2d0Oi6+epOLM31LajbM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WfzUMOsFSz73VUsKCYAI+t3XfqVVJbKqa+EAvZtIWmNYqsb5XJovHq+k6irZEtMiG lePpEP9swmtuzRKCMhzQLJeLnyHPyncTQYJmlEN2xvrN1oZ4ZV+oePNM/6QGSQlL1P SyGkOBJmdy9z1u8FqDNNH3iq05p+LdsGuGLsbKMruWRdFuQ0qbag1EADHcmwqz5iOc VQdDwR7BiOV7FsqijrvXD8hblml1JFIhyBxut5Db1Gze0pS8pnfChsM7H1GZqCE5qC z6UHArP7/f6ib18A1eFYpWeGplG+HCVW5UOgSBRZLg96LuwsaULqujCMfxGB3fZtSr c33C8R0wC7Meg== Subject: Re: [dispatch] DISPATCH @ IETF-87 Deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:41:45 -0000 Peter, I'm fine with discussing this in dispatch. My main concern with this is around REQ9 - locator of log collector server: - how is the log collector designated? The examples show just a dns name. I would think it would need to be a URL. But what protocol would be used to transfer the log? Is it required that those supporting log-me also support specific protocol(s) for log collection? If there is more than one protocol, how will the entity inserting the log-me indicator decide which one? (There isn't any opportunity here to negotiate which one will be used.) - This has security implications. How would the server sending the log decide if it can trust the specified server? Would it have a list of servers it trusts? This seems like a hard problem. And it may need to be solved for each protocol that might be used to transfer logs. It is glossed over in the security considerations. Thanks, Paul On 6/21/13 6:29 AM, Dawes, Peter, Vodafone Group wrote: > Hello Mary, > I would like the dispatch working group to consider two drafts at IETF-87 as follows: > > 1) http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-02.txt > This draft was discussed at IETF-86 and has been updated with potential solutions to requirements (clause 7). I would like to propose that INSIPID adopt this work. > (from IETF-86 http://trac.tools.ietf.org/wg/dispatch/trac/wiki#) > •Logging: General support for adopting this work. Proposal to update INSIPID WG with a new deliverable. > ◦Charter: http://www.ietf.org/mail-archive/web/dispatch/current/msg04560.html > ◦Related documents: > ■draft-dawes-dispatch-logme-reqs > > 2) http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-06.txt > An informational RFC describing a header field parameter to distinguish security mechanisms that protect media (as opposed to those that protect signalling) between a UA and its first-hop SIP entity, and to create an IANA registry to list names of such media-specific security mechanisms. > > Regards, > Peter > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 18 June 2013 23:05 > To: DISPATCH > Cc: Cullen Jennings > Subject: [dispatch] DISPATCH @ IETF-87 Deadlines > > As a reminder, the deadline for letting the chairs know that you are planning to submit something for consideration for the IETF-87 > deadline is June 24th, 2013 (next Monday - 6 days time). The > subsequent deadlines are also in the wiki: > http://tools.ietf.org/wg/dispatch/trac/wiki > Noting, that the draft deadlines are the same as the IETF draft deadlines. > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From mperumal@cisco.com Wed Jun 26 08:58:22 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 321ED21E8063; Wed, 26 Jun 2013 08:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VcBd435qQLM5; Wed, 26 Jun 2013 08:58:13 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id BA52D11E80DF; Wed, 26 Jun 2013 08:58:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2238; q=dns/txt; s=iport; t=1372262293; x=1373471893; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=1Qf+oMAVxOgwxCHGz0xiv9DJRB9TgKehyS5DmLadoRs=; b=H/uTF/Eoxvw2GwMlhI6DjswmTDBl3D8TSxCdplaF+ulTBKt+yQ4LJF1X fqyfzJNCg10fMQ2dYJSLSuXJjPz2u40l372iAo/l/LAW/6kWuH1EEMOfW QwT5yBFfNPtUynePj3F/h8s/7PC8yk+xgDOz0mlkd1+Zap+M5INcITqV4 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgQFADAPy1GtJV2Y/2dsb2JhbABagwkxSb59gQEWdIIjAQEBBAEBAWsXBAIBCBEEAQELHQcnCxQJCAEBBAESCAGIBQy6NI8aMwUGgnxhA4hqkASKeoUigxGCKA X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227720897" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-5.cisco.com with ESMTP; 26 Jun 2013 15:58:12 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id r5QFwCsn007918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 15:58:12 GMT Received: from xmb-rcd-x02.cisco.com ([169.254.4.192]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 10:58:11 -0500 From: "Muthu Arul Mozhi Perumal (mperumal)" To: "mohamed.boucadair@orange.com" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKA= Date: Wed, 26 Jun 2013 15:58:10 +0000 Message-ID: References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.74.236] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 15:58:22 -0000 Hi Med, This looks interesting. Comparing with ICE, what is missing are the connect= ivity checks that are particularly important when the IPv6/IPv4 path is bro= ken. So, using PCP for retrieving the external media transport addresses an= d using ICE for concluding on them might work, I think. Muthu =20 |-----Original Message----- |From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf O= f |mohamed.boucadair@orange.com |Sent: Wednesday, June 26, 2013 8:35 PM |To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org |Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | |Dear all, | |I submitted this short I-D to explain how PCP can be used in IPv6 SIP depl= oyments (with a focus on the |managed networks case). | |Cheers, |Med | |-----Message d'origine----- |De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org= ] De la part de internet- |drafts@ietf.org |Envoy=E9=A0: mercredi 26 juin 2013 15:40 |=C0=A0: i-d-announce@ietf.org |Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt | | |A New Internet-Draft is available from the on-line Internet-Drafts directo= ries. | | | Title : PCP for IPv6-enabled SIP Deployments | Author(s) : Mohamed Boucadair | Filename : draft-boucadair-pcp-sip-ipv6-00.txt | Pages : 7 | Date : 2013-06-26 | |Abstract: | This document discusses how PCP can be used in IPv6-enabled SIP | deployments. | | |The IETF datatracker status page for this draft is: |https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 | |There's also a htmlized version available at: |http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 | | |Internet-Drafts are also available by anonymous FTP at: |ftp://ftp.ietf.org/internet-drafts/ | |_______________________________________________ |I-D-Announce mailing list |I-D-Announce@ietf.org |https://www.ietf.org/mailman/listinfo/i-d-announce |Internet-Draft directories: http://www.ietf.org/shadow.html |or ftp://ftp.ietf.org/ietf/1shadow-sites.txt |_______________________________________________ |mmusic mailing list |mmusic@ietf.org |https://www.ietf.org/mailman/listinfo/mmusic From mjavier@cisco.com Wed Jun 26 10:56:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7117321F9362 for ; Wed, 26 Jun 2013 10:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6yvCv6IL4PS for ; Wed, 26 Jun 2013 10:56:13 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 19FBC21F9634 for ; Wed, 26 Jun 2013 10:56:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3777; q=dns/txt; s=iport; t=1372269373; x=1373478973; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=2Xh7qD14zqLUWOYpIie3zwECWxLTvH0Sgl452DJbmFg=; b=dazO++lIBZDvcolrf31CWk0Frb86cfjkOWx7Z+9SVyDnR0tvq7LKakgj sXRl7uuwSufqNhqA+ke2rUUeGJcy7+mg/EIxMSpxcsLhfXOlnffU2ZUa3 1bVYG54Zt/PpnxJiUy9GrHc3TiOZ6GuQ2Hp4w6mvcbZJRdd6TH/YafLt+ I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag4FAMwqy1GtJXHA/2dsb2JhbABbgwkxQwa+fYEDFnSCIwEBAQMBAQEBNzQQBwQCAQgRBAEBAQoUCQcnCxQJCAEBBAESCAESh20GBwW6AI4JgRE4BoJ8YQOTc4R7inoBhSGDEXIBAX03 X-IronPort-AV: E=Sophos;i="4.87,945,1363132800"; d="scan'208";a="227593788" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-1.cisco.com with ESMTP; 26 Jun 2013 17:55:50 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id r5QHtoqI013026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Jun 2013 17:55:50 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.56]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Wed, 26 Jun 2013 12:55:49 -0500 From: "Javier Martinez (mjavier)" To: "Dawes, Peter, Vodafone Group" , "Vijay K. Gurbani" , "dispatch@ietf.org" Thread-Topic: [dispatch] Proposed charter for work on logging Thread-Index: Ac4LyOtf/7ujcRPHQoOZ6+wpJgfGIAR6wVFQEpuAXZAAIQhVAAFQv4qAASqq0kA= Date: Wed, 26 Jun 2013 17:55:49 +0000 Message-ID: <040624DCD17A4644A389FC9078A50B7541011B@xmb-rcd-x10.cisco.com> References: <949EF20990823C4C85C18D59AA11AD8BF1BA@FR712WXCHMBA11.zeu.alcatel-lucent.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6D673@VOEXM31W.internal.vodafone.com> <51BA382E.4040605@bell-labs.com> <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6EC89@VOEXM31W.internal.vodafone.com> In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6EC89@VOEXM31W.internal.vodafone.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.115.62] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dispatch] Proposed charter for work on logging X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 17:56:17 -0000 Hi Peter, I agree with the utility of the marker proposal. In large SIP network deplo= yments it is a challenge collecting logs and debug traces during trouble shooting sessions, even with a single vendor deployments. In most situati= ons you end up with large amounts of data to sort through to extract the se= ssions, or files of interest from multiple boxes, in others you end up missing pieces of in= formation. There is a need for an automated way to extract the specific logs of intere= st in multi-vendor deployments. This proposal is also a great complement to the "End-to-End Session Id" pr= oposal. I would be glad to help in any way to get an implementation proposal going, Regards Javier -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Dawes, Peter, Vodafone Group Sent: Thursday, June 20, 2013 8:05 AM To: Vijay K. Gurbani; dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging Hi Vijay, The utility of a marker is that currently there is no SIP protocol mechanis= m to indicate that signalling is of interest to logging, so it is not a log= ging format issue but an issue of making regression testing and troubleshoo= ting scaleable by not having to log everything.=20 Thanks for the pointer to RFC 6872, I will take a look at it. Regards, Peter -----Original Message----- From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Behal= f Of Vijay K. Gurbani Sent: 13 June 2013 22:23 To: dispatch@ietf.org Subject: Re: [dispatch] Proposed charter for work on logging On 06/13/2013 06:17 AM, Dawes, Peter, Vodafone Group wrote: > Hello All, Following on from the comments at IETF#86=20 > (http://www.ietf.org/proceedings/86/minutes/minutes-86-dispatch), > where there was mild support for working on logging, I have updated=20 > the log me requirements draft with 3 potential solutions (in clause > 7) which can meet the requirements > (http://www.ietf.org/internet-drafts/draft-dawes-dispatch-logme-reqs-02.t= xt). > Opinions and comments on these or any other potential solutions would=20 > be very welcome. Peter: I am not being a contrarian, just being curious. What is the utility of a log-me marker if all traffic is logged through a m= echanism such as SIP CLF? > It was commented at IETF#86 that a security analysis is needed so I=20 > would like to understand if any scenarios exist with potential=20 > security threats in order to add them to requirements. In many cases,=20 > a network simply logs the signalling that passes through it so no new=20 > security issues are created. Collecting end-to-end logging for=20 > signalling that crosses multiple networks must not compromise security=20 > or privacy, but I would expect networks to remove any security=20 > sensitive fields before forwarding signalling regardless of whether=20 > that signalling is of interest to logging. We went through discussions related to all of the above points during the S= IP CLF work. See the Security Consideration section of [1]; it may provide= you some answers. [1] http://tools.ietf.org/html/rfc6872 Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq ___= ____________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From mohamed.boucadair@orange.com Wed Jun 26 22:49:17 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B088B21F9BCE; Wed, 26 Jun 2013 22:49:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1J7VxIjkobh; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 4C0D421F9BCB; Wed, 26 Jun 2013 22:49:13 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm10.si.francetelecom.fr (ESMTP service) with ESMTP id 11851264C83; Thu, 27 Jun 2013 07:49:12 +0200 (CEST) Received: from PUEXCH41.nanterre.francetelecom.fr (unknown [10.101.44.30]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 1D75235C04E; Thu, 27 Jun 2013 07:49:00 +0200 (CEST) Received: from PUEXCB1B.nanterre.francetelecom.fr ([10.101.44.13]) by PUEXCH41.nanterre.francetelecom.fr ([10.101.44.30]) with mapi; Thu, 27 Jun 2013 07:49:00 +0200 From: To: "Muthu Arul Mozhi Perumal (mperumal)" , "pcp@ietf.org" , "mmusic@ietf.org" , "dispatch@ietf.org" Date: Thu, 27 Jun 2013 07:48:58 +0200 Thread-Topic: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt Thread-Index: Ac5ycsff5RgIurehTuSyu27p5vugrwAC099QAAGlhKAAHPPhkA== Message-ID: <94C682931C08B048B7A8645303FDC9F36EDB5C836F@PUEXCB1B.nanterre.francetelecom.fr> References: <20130626134028.17581.26454.idtracker@ietfa.amsl.com> <94C682931C08B048B7A8645303FDC9F36EDB5C82CE@PUEXCB1B.nanterre.francetelecom.fr> In-Reply-To: Accept-Language: fr-FR Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.5.21.113319 Subject: Re: [dispatch] I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 05:49:17 -0000 Dear Muthu, Thank you for the feedback.=20 For managed networks, there is no need to do connectivity checks. For the g= eneral case, yes PCP can co-exist with ICE as discussed in draft-penno-rtcw= eb-pcp. Various reasons are identified in that document. You may notice this text in the draft which captures this discussion: " Even in deployments where ICE [RFC5245] is required, PCP can be of great help as discussed in [I-D.penno-rtcweb-pcp]. The document is targeting SIP deployments in managed networks." Cheers, Med >-----Message d'origine----- >De=A0: Muthu Arul Mozhi Perumal (mperumal) [mailto:mperumal@cisco.com] >Envoy=E9=A0: mercredi 26 juin 2013 17:58 >=C0=A0: BOUCADAIR Mohamed OLNC/OLN; pcp@ietf.org; mmusic@ietf.org; >dispatch@ietf.org >Objet=A0: RE: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt > >Hi Med, > >This looks interesting. Comparing with ICE, what is missing are the >connectivity checks that are particularly important when the IPv6/IPv4 pat= h >is broken. So, using PCP for retrieving the external media transport >addresses and using ICE for concluding on them might work, I think. > >Muthu > >|-----Original Message----- >|From: mmusic-bounces@ietf.org [mailto:mmusic-bounces@ietf.org] On Behalf >Of >|mohamed.boucadair@orange.com >|Sent: Wednesday, June 26, 2013 8:35 PM >|To: pcp@ietf.org; mmusic@ietf.org; dispatch@ietf.org >|Subject: [MMUSIC] TR: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >|Dear all, >| >|I submitted this short I-D to explain how PCP can be used in IPv6 SIP >deployments (with a focus on the >|managed networks case). >| >|Cheers, >|Med >| >|-----Message d'origine----- >|De=A0: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.or= g] >De la part de internet- >|drafts@ietf.org >|Envoy=E9=A0: mercredi 26 juin 2013 15:40 >|=C0=A0: i-d-announce@ietf.org >|Objet=A0: I-D Action: draft-boucadair-pcp-sip-ipv6-00.txt >| >| >|A New Internet-Draft is available from the on-line Internet-Drafts >directories. >| >| >| Title : PCP for IPv6-enabled SIP Deployments >| Author(s) : Mohamed Boucadair >| Filename : draft-boucadair-pcp-sip-ipv6-00.txt >| Pages : 7 >| Date : 2013-06-26 >| >|Abstract: >| This document discusses how PCP can be used in IPv6-enabled SIP >| deployments. >| >| >|The IETF datatracker status page for this draft is: >|https://datatracker.ietf.org/doc/draft-boucadair-pcp-sip-ipv6 >| >|There's also a htmlized version available at: >|http://tools.ietf.org/html/draft-boucadair-pcp-sip-ipv6-00 >| >| >|Internet-Drafts are also available by anonymous FTP at: >|ftp://ftp.ietf.org/internet-drafts/ >| >|_______________________________________________ >|I-D-Announce mailing list >|I-D-Announce@ietf.org >|https://www.ietf.org/mailman/listinfo/i-d-announce >|Internet-Draft directories: http://www.ietf.org/shadow.html >|or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >|_______________________________________________ >|mmusic mailing list >|mmusic@ietf.org >|https://www.ietf.org/mailman/listinfo/mmusic From hadriel.kaplan@oracle.com Thu Jun 27 10:01:20 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DCB21F9D7B for ; Thu, 27 Jun 2013 10:01:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.948 X-Spam-Level: X-Spam-Status: No, score=-5.948 tagged_above=-999 required=5 tests=[AWL=0.650, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AR1YL7MzXseM for ; Thu, 27 Jun 2013 10:01:13 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id B104921F9E4D for ; Thu, 27 Jun 2013 10:01:10 -0700 (PDT) Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r5RH0jfM001651 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 27 Jun 2013 17:00:47 GMT Received: from userz7022.oracle.com (userz7022.oracle.com [156.151.31.86]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5RH0h3s007946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 27 Jun 2013 17:00:44 GMT Received: from abhmt117.oracle.com (abhmt117.oracle.com [141.146.116.69]) by userz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r5RH0hA5021690; Thu, 27 Jun 2013 17:00:43 GMT Received: from dhcp-amer-vpn-adc-anyconnect-10-154-182-231.vpn.oracle.com (/10.154.182.231) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 27 Jun 2013 10:00:43 -0700 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: Hadriel Kaplan In-Reply-To: <807CCE02-B653-49B5-BBAA-AD84B842EB7B@edvina.net> Date: Thu, 27 Jun 2013 13:00:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <21A0BB60-FDBE-457C-8311-01C078703A29@oracle.com> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> <807CCE02-B653-49B5-BBAA-AD84B842EB7B@edvina.net> To: "Olle E. Johansson" X-Mailer: Apple Mail (2.1508) X-Source-IP: ucsinet21.oracle.com [156.151.31.93] Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:01:20 -0000 On Jun 26, 2013, at 4:13 AM, Olle E. Johansson wrote: >=20 > 25 jun 2013 kl. 21:41 skrev "Neelakantan, Neel" = : >=20 >> Additionally, from/to headers could have IPv6 address. > We tried to avoid listing ALL possibly headers that could have IPv6 = headers, because that will be a moving target. We want to alert the = developer with a few cases that we've seen in real life. >=20 I agree we can't list them all (nor should we try), but the To/=46rom in = particular are mandatory headers and so commonly used for processing = purposes that I think we should mention them explicitly. (I know I = suggested that the To/=46rom be listed before the draft got published = into IETF, but there's no rule against repeating ourselves :) -hadriel From nneelakantan@sonusnet.com Thu Jun 27 10:04:21 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D55221F9E5F for ; Thu, 27 Jun 2013 10:04:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYOhQUHC4-om for ; Thu, 27 Jun 2013 10:04:15 -0700 (PDT) Received: from p01c12o149.mxlogic.net (p01c12o149.mxlogic.net [208.65.145.72]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE9C21F9E58 for ; Thu, 27 Jun 2013 10:04:15 -0700 (PDT) Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o149.mxlogic.net(mxl_mta-7.1.0-3) with ESMTP id f807cc15.2b78a5998940.214712.00-533.515194.p01c12o149.mxlogic.net (envelope-from ); Thu, 27 Jun 2013 11:04:15 -0600 (MDT) X-MXL-Hash: 51cc708f1ab5bf2b-6f420a781a50c9cbdc595e65f83c2cb63911912e Received: from unknown [69.147.176.212] (EHLO usma-ex-hub1.sonusnet.com) by p01c12o149.mxlogic.net(mxl_mta-7.1.0-3) over TLS secured channel with ESMTP id 0707cc15.0.214436.00-281.514533.p01c12o149.mxlogic.net (envelope-from ); Thu, 27 Jun 2013 11:03:55 -0600 (MDT) X-MXL-Hash: 51cc707b28aca491-e8bf16498b7876d940576452abc6a50758230acc Received: from USMA-EX-MB2.sonusnet.com ([fe80::c51d:eb9c:bce7:e4b0]) by usma-ex-hub1.sonusnet.com ([2002:42cb:5a10::42cb:5a10]) with mapi id 14.02.0342.003; Thu, 27 Jun 2013 13:03:43 -0400 From: "Neelakantan, Neel" To: Hadriel Kaplan , "Olle E. Johansson" Thread-Topic: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: Ac5i1sUwgbY1hhy+RLyzNz7nciXYZgPBTYBwACKnT4AARLKmgAAIV+DQ Date: Thu, 27 Jun 2013 17:03:42 +0000 Message-ID: <56EB3FF5A53614438D93B3325407DBE5770840@USMA-EX-MB2.sonusnet.com> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> <807CCE02-B653-49B5-BBAA-AD84B842EB7B@edvina.net> <21A0BB60-FDBE-457C-8311-01C078703A29@oracle.com> In-Reply-To: <21A0BB60-FDBE-457C-8311-01C078703A29@oracle.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [192.168.2.37] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-AnalysisOut: [v=2.0 cv=bdbcppzB c=1 sm=1 a=ed0SwufR/ZNkx8DvM7kK7A==:17 a] X-AnalysisOut: [=kxZvkmloRasA:10 a=YCjQDKGAcrgA:10 a=URNJFqk9g_oA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=xqWC_Br6kY4A:10 a=kUVcWBO] X-AnalysisOut: [SAAAA:8 a=nzeCThAnUHUA:10 a=yPCof4ZbAAAA:8 a=48vgC7mUAAAA:] X-AnalysisOut: [8 a=5-KlvN02AAAA:8 a=L0SscB4JJKiv2RnoOYsA:9 a=CjuIK1q_8ugA] X-AnalysisOut: [:10 a=7DSvI1NPTFQA:10 a=lZB815dzVvQA:10 a=aFo64ATDO6kA:10 ] X-AnalysisOut: [a=AOwmXBQAedEA:10 a=YdxJoIH_kfxIYOJQ:21 a=bNYOhGlX3U4kriYK] X-AnalysisOut: [:21] X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [69.147.176.212] Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:04:21 -0000 See inline. > -----Original Message----- > From: Hadriel Kaplan [mailto:hadriel.kaplan@oracle.com] > Sent: Thursday, June 27, 2013 12:01 PM > To: Olle E. Johansson > Cc: Neelakantan, Neel; 'dispatch@ietf.org' > Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6= - > impact-ipv4 >=20 >=20 > On Jun 26, 2013, at 4:13 AM, Olle E. Johansson wrote: >=20 > > > > 25 jun 2013 kl. 21:41 skrev "Neelakantan, Neel" > : > > > >> Additionally, from/to headers could have IPv6 address. > > We tried to avoid listing ALL possibly headers that could have IPv6 hea= ders, > because that will be a moving target. We want to alert the developer with= a > few cases that we've seen in real life. > > >=20 > I agree we can't list them all (nor should we try), but the To/From in pa= rticular > are mandatory headers and so commonly used for processing purposes that I > think we should mention them explicitly. (I know I suggested that the > To/From be listed before the draft got published into IETF, but there's n= o > rule against repeating ourselves :) >=20 [Neel]=20 I agree that there is no need to catalog for every header. However, there = can be a generic section which covers about URI host portion where it can b= e a IPv6 address. This way it is future proof and need not be repeated at = all places. Thanks, Neel > -hadriel >=20 >=20 From mary.ietf.barnes@gmail.com Thu Jun 27 10:04:55 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A289821F9E5F for ; Thu, 27 Jun 2013 10:04:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yYxSlcn9hFay for ; Thu, 27 Jun 2013 10:04:55 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 00E0A21F9E58 for ; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id c10so684327qcz.0 for ; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ZhTvg9d8vYTTUTRmX3C3gY0Q9egUr9fTUQWzbUwSBrc=; b=diGc6Y9NQ7dpxhsdRBJq3PyTKTgTL3hB+WJx7fbadZUtAF8dS1LCn81Yrm/GNGGGzx qPceQR8PrWCZ5mS4zR9FSl7kfRqJmBW4UA8vTVM3b+vgS0Y9cGSLzRJ8fSnDzoLgPq/z jSKmyhPYekSSsBpWsiDXoNIOBI1FIlPDGD/z1em6OKYI8rF8SD4B6TkuUBiQgoup7/Wp HuW01PgtlAKr3q5X3ygXB+xN+PHYuNZ5s5dAUCOsLbvqVwj7CXsa0QrA3cWAwGKzNRrt VSsgzam2bmDIO8C2/m+SxoZuEq08Bl3kEu1TsOPcTpxDtCaYO0Doqjml1EsE89twherf JUeA== MIME-Version: 1.0 X-Received: by 10.224.72.203 with SMTP id n11mr12787595qaj.13.1372352694468; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) Received: by 10.49.76.167 with HTTP; Thu, 27 Jun 2013 10:04:54 -0700 (PDT) In-Reply-To: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6F1ED@VOEXM31W.internal.vodafone.com> References: <4A4F136CBD0E0D44AE1EDE36C4CD9D996EE6F1ED@VOEXM31W.internal.vodafone.com> Date: Thu, 27 Jun 2013 12:04:54 -0500 Message-ID: From: Mary Barnes To: "Dawes, Peter, Vodafone Group" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: Cullen Jennings , DISPATCH Subject: Re: [dispatch] DISPATCH @ IETF-87 Deadlines X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 17:04:55 -0000 On Fri, Jun 21, 2013 at 5:29 AM, Dawes, Peter, Vodafone Group wrote: > Hello Mary, > I would like the dispatch working group to consider two drafts at IETF-87= as follows: > > 1) http://www.ietf.org/id/draft-dawes-dispatch-logme-reqs-02.txt > This draft was discussed at IETF-86 and has been updated with potential s= olutions to requirements (clause 7). I would like to propose that INSIPID a= dopt this work. > (from IETF-86 http://trac.tools.ietf.org/wg/dispatch/trac/wiki#) > =E2=80=A2Logging: General support for adopting this work. Proposal to upd= ate INSIPID WG with a new deliverable. > =E2=97=A6Charter: http://www.ietf.org/mail-archive/web/dispatch/c= urrent/msg04560.html > =E2=97=A6Related documents: > =E2=96=A0draft-dawes-dispatch-logme-reqs [MB] Per the above, we dispatched that document at IETF-86 with the recommendation that it be handled in the INSIPID WG. We saw no concerns over that expressed on this mailing list post-IETF-86. My recommendation is that the discussion of this document (and whether a new deliverable should be added to the INSIPID WG charter) should move to the INISIPID WG mailing list. [/MB] > > 2) http://www.ietf.org/id/draft-dawes-dispatch-mediasec-parameter-06.txt > An informational RFC describing a header field parameter to distinguish s= ecurity mechanisms that protect media (as opposed to those that protect sig= nalling) between a UA and its first-hop SIP entity, and to create an IANA r= egistry to list names of such media-specific security mechanisms. [MB] At this point, it's not clear as to exactly why this is required and why this needs to be in a SIP header field parameter as opposed to SDP, for example. Again, we need clear problem statements as opposed to specific solutions for discussion. Since this appears to be based on 3GPP requirements, Gonzalo will follow-up with you all to get more details in that regards to further inform the DISPATCH chairs & ADs decision. [/MB] > > Regards, > Peter > > -----Original Message----- > From: dispatch-bounces@ietf.org [mailto:dispatch-bounces@ietf.org] On Beh= alf Of Mary Barnes > Sent: 18 June 2013 23:05 > To: DISPATCH > Cc: Cullen Jennings > Subject: [dispatch] DISPATCH @ IETF-87 Deadlines > > As a reminder, the deadline for letting the chairs know that you are plan= ning to submit something for consideration for the IETF-87 > deadline is June 24th, 2013 (next Monday - 6 days time). The > subsequent deadlines are also in the wiki: > http://tools.ietf.org/wg/dispatch/trac/wiki > Noting, that the draft deadlines are the same as the IETF draft deadlines= . > > Regards, > Mary > DISPATCH WG co-chair > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From oej@edvina.net Thu Jun 27 12:45:44 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41B5F21F9F28 for ; Thu, 27 Jun 2013 12:45:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t+pxtFQCQBJy for ; Thu, 27 Jun 2013 12:45:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 5589721F9F2B for ; Thu, 27 Jun 2013 12:45:41 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 26E0893C1AF; Thu, 27 Jun 2013 19:45:41 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: <21A0BB60-FDBE-457C-8311-01C078703A29@oracle.com> Date: Thu, 27 Jun 2013 21:45:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6B405F81-A88F-4C58-80AE-6629F6AED0F2@edvina.net> References: <6C15A6B88541034E912E94C2D8BC3E87B9A89D47@PACDCEXMB12.cable.comcast.com> <56EB3FF5A53614438D93B3325407DBE576F314@USMA-EX-MB2.sonusnet.com> <807CCE02-B653-49B5-BBAA-AD84B842EB7B@edvina.net> <21A0BB60-FDBE-457C-8311-01C078703A29@oracle.com> To: Hadriel Kaplan X-Mailer: Apple Mail (2.1508) Cc: "'dispatch@ietf.org'" Subject: Re: [dispatch] Initial submission of draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Jun 2013 19:45:44 -0000 27 jun 2013 kl. 19:00 skrev Hadriel Kaplan : >=20 > On Jun 26, 2013, at 4:13 AM, Olle E. Johansson wrote: >=20 >>=20 >> 25 jun 2013 kl. 21:41 skrev "Neelakantan, Neel" = : >>=20 >>> Additionally, from/to headers could have IPv6 address. >> We tried to avoid listing ALL possibly headers that could have IPv6 = headers, because that will be a moving target. We want to alert the = developer with a few cases that we've seen in real life. >>=20 >=20 > I agree we can't list them all (nor should we try), but the To/=46rom = in particular are mandatory headers and so commonly used for processing = purposes that I think we should mention them explicitly. (I know I = suggested that the To/=46rom be listed before the draft got published = into IETF, but there's no rule against repeating ourselves :) Well, there are rules against repeating some headers... ;-) Thanks for the feedback - again - Hadriel. We'll consider this for the = next version. /O= From fluffy@cisco.com Fri Jun 28 15:29:08 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1904A21F9D8B for ; Fri, 28 Jun 2013 15:29:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9K+I4qpZ0fI0 for ; Fri, 28 Jun 2013 15:29:02 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 04A5E21F9CEE for ; Fri, 28 Jun 2013 15:28:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1584; q=dns/txt; s=iport; t=1372458538; x=1373668138; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=ssR06oQveCrQfy9DR7gzciuqWbwUNryFg8KRVkAJdHc=; b=OnnptxKDEeV4pjwSoBYXMQozpl444Vye3pd1gaqYTwMHlg3KIf+5d1e7 BMpJcAh1Bi8s/noWXeeSy66e4Lu5lxKUxS+b5SGHGrAotp3E1mhyIbW7q 29tyWse/nhXJZeIjme4DH7f6IEdI4HKrBHKACkO0YlUgoiBd05pRIchik k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhAFAKsMzlGtJXHB/2dsb2JhbABbgwl7vwqBChZ0giUBBDo/EgEqFEInBAENDYgGAbpRjyUxgwtjA6kKgxGCKA X-IronPort-AV: E=Sophos;i="4.87,962,1363132800"; d="scan'208";a="225842548" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-9.cisco.com with ESMTP; 28 Jun 2013 22:28:57 +0000 Received: from xhc-rcd-x01.cisco.com (xhc-rcd-x01.cisco.com [173.37.183.75]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r5SMSvxT029152 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 28 Jun 2013 22:28:57 GMT Received: from xmb-aln-x02.cisco.com ([169.254.5.116]) by xhc-rcd-x01.cisco.com ([173.37.183.75]) with mapi id 14.02.0318.004; Fri, 28 Jun 2013 17:28:57 -0500 From: "Cullen Jennings (fluffy)" To: Rifaat Shekh-Yusef , Olle E Johansson , "Gonzalo Salgueiro (gsalguei)" , "carl_klatsky@cable.comcast.com" , "Andrew Hutton" Thread-Topic: Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 Thread-Index: AQHOdE7gkEpHsjUQLkK6+KYIhBdntA== Date: Fri, 28 Jun 2013 22:28:56 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [171.68.20.14] Content-Type: text/plain; charset="us-ascii" Content-ID: <30E656F0504984428DFB97A0AA006D10@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dispatch@ietf.org list" Subject: [dispatch] Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 22:29:08 -0000 The chairs are trying to figure out how to frame the purpose of this draft = as that helps us figure out what to do with it. Three questions to the auth= ors (but happy to hear from anyone): 1) Guidance or Standard ? My current understanding of the draft is that it does not require any updat= es or changes to any existing RFC. It does not specify new normative behavi= or. (and I see it is informational) It seems to be more a collection of sce= narios that a implementer might want to consider but does not change any no= rmative behavior.=20 Is my understanding roughly correct? 2) Operators or Implementers ? Another ways of looking at this draft, seem to be advice to operators to us= e DNS names instead of IP addresses that might not be supported. That will = allow v4/v6 interop mechanism at layer 3 to come into play.=20 Does the draft want to be advice to operators about how to use IP addresses= and DNS names in SIP to avoid the problems raised in the draft?=20 3) Scope=20 Nearly every section of the draft raises as many questions in my mind as it= answers. Is the intend that this draft is "close to done" with some review= or is it more that this draft is just the starting point of a much larger = effort? ( I can give examples but I want to focus on the big picture not th= e questions raised in my mind ) Cullen=20 PS - As a chair - this type of draft is the hardest. It's hard to know what= is the best thing to do with this draft until I get a clear picture of wha= t work this is proposing for IETF.=20 From oej@edvina.net Sat Jun 29 00:06:52 2013 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440CA21F9E35 for ; Sat, 29 Jun 2013 00:06:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ENWzcR0dbqc for ; Sat, 29 Jun 2013 00:06:51 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 3886E21F9E0D for ; Sat, 29 Jun 2013 00:06:47 -0700 (PDT) Received: from [192.168.40.15] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id E30D993C1AF; Sat, 29 Jun 2013 07:06:44 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\)) From: "Olle E. Johansson" In-Reply-To: Date: Sat, 29 Jun 2013 09:06:47 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Cullen Jennings (fluffy)" X-Mailer: Apple Mail (2.1508) Cc: "dispatch@ietf.org list" Subject: Re: [dispatch] Chair question around draft-klatsky-dispatch-ipv6-impact-ipv4 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Jun 2013 07:06:52 -0000 29 jun 2013 kl. 00:28 skrev "Cullen Jennings (fluffy)" = : >=20 > The chairs are trying to figure out how to frame the purpose of this = draft as that helps us figure out what to do with it. Three questions to = the authors (but happy to hear from anyone): >=20 > 1) Guidance or Standard ? >=20 > My current understanding of the draft is that it does not require any = updates or changes to any existing RFC. It does not specify new = normative behavior. (and I see it is informational) It seems to be more = a collection of scenarios that a implementer might want to consider but = does not change any normative behavior.=20 >=20 > Is my understanding roughly correct? Yes. >=20 >=20 > 2) Operators or Implementers ? >=20 > Another ways of looking at this draft, seem to be advice to operators = to use DNS names instead of IP addresses that might not be supported. = That will allow v4/v6 interop mechanism at layer 3 to come into play.=20 >=20 > Does the draft want to be advice to operators about how to use IP = addresses and DNS names in SIP to avoid the problems raised in the = draft?=20 Good question. I think that is the general religion of SIP - and we've = been working with it at SIPit - "test using DNS, not IP addresses".=20 I personally don't think we should add it to this specific document at = this point as it may generate a lot of discussions and lead to = happy-eyeballs whcih is in scope for the other documents. I need guidance from those of you that are more experienced in the IETF = process here. WHile I would love to add another argument for not using = numeric IP addresses. >=20 >=20 > 3) Scope=20 >=20 > Nearly every section of the draft raises as many questions in my mind = as it answers. Is the intend that this draft is "close to done" with = some review or is it more that this draft is just the starting point of = a much larger effort? ( I can give examples but I want to focus on the = big picture not the questions raised in my mind ) I think this draft should stay "problem statement" more than solution. = At this point we just want to alert and wake up everyone saying "oh, I = only do IPv4 so I don't have to bother". And that fact needs to be out = there soon. If there are issues in this draft that lacks a solution in the current = set of RFCs we need to handle that, but in my head that would be a = separate document.=20 We might make it a bit more clear that this is a problem statement. = Again, I'm the newbie in this process so this is just my 5 =F6re = contribution :-) >=20 >=20 > Cullen=20 >=20 > PS - As a chair - this type of draft is the hardest. It's hard to know = what is the best thing to do with this draft until I get a clear picture = of what work this is proposing for IETF.=20 /O=