From nobody Wed Apr 2 01:51:26 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 840BE1A0176 for ; Wed, 2 Apr 2014 01:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.24 X-Spam-Level: X-Spam-Status: No, score=-101.24 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Tl9rKTxw0AG for ; Wed, 2 Apr 2014 01:51:22 -0700 (PDT) Received: from sesbmg21.mgmt.ericsson.se (sesbmg21.ericsson.net [193.180.251.49]) by ietfa.amsl.com (Postfix) with ESMTP id 72A371A0173 for ; Wed, 2 Apr 2014 01:51:21 -0700 (PDT) X-AuditID: c1b4fb31-b7f688e000003e64-ae-533bcf849ef2 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg21.mgmt.ericsson.se (Symantec Mail Security) with SMTP id 7C.EC.15972.48FCB335; Wed, 2 Apr 2014 10:51:17 +0200 (CEST) Received: from [147.214.153.51] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.41) with Microsoft SMTP Server id 14.3.174.1; Wed, 2 Apr 2014 10:51:16 +0200 Message-ID: <533BCF84.4090807@ericsson.com> Date: Wed, 2 Apr 2014 11:51:16 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: References: <20140401220040.F06667FC394@rfc-editor.org> In-Reply-To: <20140401220040.F06667FC394@rfc-editor.org> X-Enigmail-Version: 1.6 X-Forwarded-Message-Id: <20140401220040.F06667FC394@rfc-editor.org> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKLMWRmVeSWpSXmKPExsUyM+JvjW7reetgg7l3mCyWTlrA6sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujMlb5jIWdApWrHh7jbmB8TdPFyMnh4SAicTZf4tYIGwxiQv3 1rOB2EICJxkl7lxJ62LkArJXM0pc23mGvYuRg4NXQFui52AhiMkioCLx4o4aSDmbgIXEllv3 wcaICkRJdE96xA5i8woISpyc+QQsLiIgLtHQ/Y4ZxBYWyJW4s62PGWKVucSaK7uZQGxOoDlr tz1mARkvAVTf0xgEcZmzxL5PfWCXMQvoSUy52sIIYctLbH87B2qMtsTyZy0sExiFZiHZPAtJ yywkLQsYmVcxShanFiflphsZ6uWm55bopRZlJhcX5+fpFaduYgQG7cEtvw13ME68Zn+IUZqD RUmcl2F6Z5CQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGxnnHbryc/0nenen0ii1XfG66rZH7 XnqU/06u/Bez28tsQ3zthN4dvPxiqyXTEifTHp/fjlsUVD8GzNCy2/7jkvqPpG6ee1FWU39z 31rvJPbcfVmVHJdyLFdzwoYoTw2NpmsNpvfXHlZybC/OET9qd+TAfPerdxuXM5stWbvTaeW7 nbdm3DoeXazEUpyRaKjFXFScCADqXDrTKAIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/YrCMW7GAZUCY4ZZ7sKp1qOq7RaI Subject: [dispatch] Fwd: RFC 7168 on The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 08:51:25 -0000 Hey, I am so glad this RFC was just published! Now I can start enjoying all my nice tea! :-) Cheers, Gonzalo -------- Original Message -------- Subject: RFC 7168 on The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) Date: Tue, 1 Apr 2014 15:00:38 -0700 From: Reply-To: To: , CC: , A new Request for Comments is now available in online RFC libraries. RFC 7168 Title: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA) Author: I. Nazar Status: Informational Stream: Independent Date: 1 April 2014 Mailbox: inazar@deviantart.com Pages: 7 Characters: 14490 Updates: RFC 2324 I-D Tag: draft-nazar-htcpcp-tea-00.txt URL: http://www.rfc-editor.org/rfc/rfc7168.txt The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Apr 5 12:50:22 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D816B1A02B5 for ; Sat, 5 Apr 2014 12:50:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.348 X-Spam-Level: X-Spam-Status: No, score=0.348 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlIi_zWrU6rG for ; Sat, 5 Apr 2014 12:50:17 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 6947A1A029D for ; Sat, 5 Apr 2014 12:50:14 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 8474E93C1AF; Sat, 5 Apr 2014 19:49:46 +0000 (UTC) From: "Olle E. Johansson" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Sat, 5 Apr 2014 21:49:42 +0200 Message-Id: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> To: DISPATCH Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/wHmBRJKXvz4qqXDxB-QoSUOBVrg Subject: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Apr 2014 19:50:22 -0000 http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security Is this something we can use in SIP? How would it work in a proxied network? Of course a b2bua or SBC can change anything... /O From nobody Sat Apr 5 21:34:02 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9EB01A0248 for ; Sat, 5 Apr 2014 21:33:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dx-zZ8spYTON for ; Sat, 5 Apr 2014 21:33:56 -0700 (PDT) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id B17C31A022D for ; Sat, 5 Apr 2014 21:33:55 -0700 (PDT) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta03.westchester.pa.mail.comcast.net with comcast id mUYw1n0031ap0As53UZq0k; Sun, 06 Apr 2014 04:33:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta22.westchester.pa.mail.comcast.net with comcast id mUZp1n00U3ZTu2S3iUZpAT; Sun, 06 Apr 2014 04:33:50 +0000 Message-ID: <5340D92D.7040001@alum.mit.edu> Date: Sun, 06 Apr 2014 00:33:49 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> In-Reply-To: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@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=q20140121; t=1396758830; bh=KbmkeHaR7RLYzgq0fdLnaCmo/rDR1/f/U2/sChXag0I=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=IHiPjt0ObUSAZtnhr5QG0tfuFXTqeejDnwAEQq10qpXCKI/7yEjEpMHlpadlL2LTu a8WGWiS+za8LDBFFefM/1GQQLIn+EOUxz1sIFKk8feeU4w/IY+3LRSgulo93bMS4un d6moerc0TpD3+XxvfUc0UqfCJZ1YQRK8eTnyjMQhYv43dX+XDmeL7ZrG3l5n3w7f8m Q2JKMHXmdVRb3UbmkbyzcGZJ9vQ9d/VgcmNgWJhjwOEN+GAajSOEQaagGYAfhBcfky CoIcuIhnrelbmbK6YQg64xDDei7Cm2gJEX+zC58qRyETfoelnHk0dKfgNS9/2X2pY6 ieVpzR6XDQJig== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/qhgj1nN05KFrR18r1yAkgvXgAag Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 04:34:00 -0000 On 4/5/14 3:49 PM, Olle E. Johansson wrote: > http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security > > Is this something we can use in SIP? Perhaps in SIP over websockets. With SIP over UDP or TCP there would be no way for the server to communicate it to the client. The mechanism we have is DNSSRV, indicating that only TLS is supported. Thanks, Paul > How would it work in a proxied network? > > Of course a b2bua or SBC can change anything... > > /O > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Sun Apr 6 00:13:33 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FC5D1A02F2 for ; Sun, 6 Apr 2014 00:13:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JikhBULEb7IQ for ; Sun, 6 Apr 2014 00:13:27 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 047C81A0238 for ; Sun, 6 Apr 2014 00:13:26 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 7CA0693C1AF; Sun, 6 Apr 2014 07:12:55 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <5340D92D.7040001@alum.mit.edu> Date: Sun, 6 Apr 2014 09:13:07 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/TmK6F48C1GJ6uw4fBambb5UUBHE Cc: dispatch@ietf.org Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 07:13:31 -0000 On 06 Apr 2014, at 06:33, Paul Kyzivat wrote: > On 4/5/14 3:49 PM, Olle E. Johansson wrote: >> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>=20 >> Is this something we can use in SIP? >=20 > Perhaps in SIP over websockets. >=20 > With SIP over UDP or TCP there would be no way for the server to = communicate it to the client. Of course we can communicate it in the response, like HTTP, over any = transport. "You should be using TLS for this connection from now on" Now the question is what it would mean... If the sip outbound connection = is over TCP to the edge proxy and someone beyond that proxy requests TLS, there's not = much a UA=20 can do. I guess it can be one hop only.=20 >=20 > The mechanism we have is DNSSRV, indicating that only TLS is = supported. I guess you mean NAPTR. The idea with HSTS is for a user agent to "remember" that TLS was = required for a=20 specific target in case a middlebox suddenly changes the DNS record and = forces another target. /O >=20 > Thanks, > Paul >=20 >> How would it work in a proxied network? >>=20 >> Of course a b2bua or SBC can change anything... >>=20 >> /O >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >>=20 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Apr 6 11:30:32 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52901A0227 for ; Sun, 6 Apr 2014 11:30:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OgLXjzcBYBQ2 for ; Sun, 6 Apr 2014 11:30:25 -0700 (PDT) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id A9ACC1A023E for ; Sun, 6 Apr 2014 11:30:25 -0700 (PDT) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta15.westchester.pa.mail.comcast.net with comcast id mhU31n0051swQuc5FiWKU3; Sun, 06 Apr 2014 18:30:19 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id miWK1n0033ZTu2S3biWKTS; Sun, 06 Apr 2014 18:30:19 +0000 Message-ID: <53419D3A.1010103@alum.mit.edu> Date: Sun, 06 Apr 2014 14:30:18 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> In-Reply-To: <4A7D17AC-6A4F-484A-B61E-E73423B28B83@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=q20140121; t=1396809019; bh=qcS1XioHHYStNXOX8zZMtLH0p5Xp3qT7sXXDek1BatA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=vQxVRbDCUiTjq+MT6GXfc/3u5wpJCVDJr7/v5R7y7AzGWA7Yk/vRUc5cs+p4CWXbE +N81KUIEuDjEFC7HIJgu/nhLQmm9XXlmdDTmnDLNmidbo/s08qKB0BtlHT4GIG5o4A bnpNCFvXm5px5VvsVS1PmQS2lf97lOOBrbONXPICN3YlUVkekZUEl6zSlx01EkTi+7 YdBDq/NW6gfWJKf0Uvu5HdV1tbhs4/qg5j6sxLhwVjEQW0BdUCyMxZ2V8zgj3uRmCD GTMtQaJfYnmiauSklxaR11tUj50hKe8VR+PQtppQGp6NnmD0J6IfkTLxi1lR/4yIpt 9GeX/J8Azpxxw== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/SGDy4gCSQXK3AYfbCcRD4kUMN8U Cc: dispatch@ietf.org Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 18:30:29 -0000 On 4/6/14 3:13 AM, Olle E. Johansson wrote: > > On 06 Apr 2014, at 06:33, Paul Kyzivat wrote: > >> On 4/5/14 3:49 PM, Olle E. Johansson wrote: >>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>> >>> Is this something we can use in SIP? >> >> Perhaps in SIP over websockets. >> >> With SIP over UDP or TCP there would be no way for the server to communicate it to the client. > Of course we can communicate it in the response, like HTTP, over any transport. > "You should be using TLS for this connection from now on" Oh, I misunderstood in my *very* brief look at the reference. So you mean that for sip there would be a new header field in some sip response that would provide this hint? > Now the question is what it would mean... If the sip outbound connection is over TCP to > the edge proxy and someone beyond that proxy requests TLS, there's not much a UA > can do. I guess it can be one hop only. >> >> The mechanism we have is DNSSRV, indicating that only TLS is supported. > I guess you mean NAPTR. Yeah, sorry. > The idea with HSTS is for a user agent to "remember" that TLS was required for a > specific target in case a middlebox suddenly changes the DNS record and forces > another target. ISTM that the usage model it is based on doesn't fit well with sip. It seems to be predicated on the client being a browser, that has a cache of visited web addresses. Sip doesn't have that. Also, ISTM that proxies totally mess this up. Thanks, Paul > /O >> >> Thanks, >> Paul >> >>> How would it work in a proxied network? >>> >>> Of course a b2bua or SBC can change anything... >>> >>> /O >>> >>> _______________________________________________ >>> 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 nobody Sun Apr 6 11:37:25 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C3B1A04CD for ; Sun, 6 Apr 2014 11:37:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x0mrQGo1cAqd for ; Sun, 6 Apr 2014 11:37:18 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id C5A2A1A04B1 for ; Sun, 6 Apr 2014 11:37:16 -0700 (PDT) Received: from [192.168.40.10] (h87-96-134-129.dynamic.se.alltele.net [87.96.134.129]) by smtp7.webway.se (Postfix) with ESMTPA id 499D793C1AF; Sun, 6 Apr 2014 18:36:47 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: <53419D3A.1010103@alum.mit.edu> Date: Sun, 6 Apr 2014 20:36:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> <53419D3A.1010103@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/I5VZ7P3eXb0YKw_PkbPcMgxXif4 Cc: dispatch@ietf.org Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Apr 2014 18:37:23 -0000 On 06 Apr 2014, at 20:30, Paul Kyzivat wrote: > On 4/6/14 3:13 AM, Olle E. Johansson wrote: >>=20 >> On 06 Apr 2014, at 06:33, Paul Kyzivat wrote: >>=20 >>> On 4/5/14 3:49 PM, Olle E. Johansson wrote: >>>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>>>=20 >>>> Is this something we can use in SIP? >>>=20 >>> Perhaps in SIP over websockets. >>>=20 >>> With SIP over UDP or TCP there would be no way for the server to = communicate it to the client. >> Of course we can communicate it in the response, like HTTP, over any = transport. >> "You should be using TLS for this connection from now on" >=20 > Oh, I misunderstood in my *very* brief look at the reference. >=20 > So you mean that for sip there would be a new header field in some sip = response that would provide this hint? >=20 >> Now the question is what it would mean... If the sip outbound = connection is over TCP to >> the edge proxy and someone beyond that proxy requests TLS, there's = not much a UA >> can do. I guess it can be one hop only. >>>=20 >>> The mechanism we have is DNSSRV, indicating that only TLS is = supported. >> I guess you mean NAPTR. >=20 > Yeah, sorry. >=20 >> The idea with HSTS is for a user agent to "remember" that TLS was = required for a >> specific target in case a middlebox suddenly changes the DNS record = and forces >> another target. >=20 > ISTM that the usage model it is based on doesn't fit well with sip. > It seems to be predicated on the client being a browser, that has a = cache of visited web addresses. >=20 > Sip doesn't have that. Also, ISTM that proxies totally mess this up. >=20 HTTP did not have a cache on SSL fingerprints or HSTS either, so that's = no good argument ;-) For TOFU - Trust On First use - kind of solutions we will need a cache - = if we go down that path. Save known fingerprints and make sure we get = the same next time.=20 We need to figure out how to apply one or a few of these solutions to = SIP clients. /O From nobody Mon Apr 7 07:59:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6111B1A0447 for ; Mon, 7 Apr 2014 07:59:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyviyXI3_u-9 for ; Mon, 7 Apr 2014 07:59:29 -0700 (PDT) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8B1301A045E for ; Mon, 7 Apr 2014 07:59:29 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id s37ExMhs018054 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 7 Apr 2014 09:59:23 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s37ExMUD017329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 7 Apr 2014 09:59:22 -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 s37ExMYY000332; Mon, 7 Apr 2014 09:59:22 -0500 (CDT) Message-ID: <5342BDAF.4060506@bell-labs.com> Date: Mon, 07 Apr 2014 10:01:03 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/j5V0TS8xCNi7BSKQ0x3cc465fmE Cc: draft-salgueiro-dispatch-websocket-sipclf@tools.ietf.org Subject: [dispatch] Shepherd review of draft-salgueiro-dispatch-websocket-sipclf X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Apr 2014 14:59:34 -0000 I am shepherding draft-salgueiro-dispatch-websocket-sipclf. The document is ready to be sent further, but does need one more revision to address minor issues identified below. Once a revision is submitted, I will go ahead and post the PROTO writeup and we can move ahead from there. Here are the minor issues in document-order form: - S1: s/two-way message/bi-directional message/ - S1: s/reuse existing HTTP infrastructure/reuse existing transport connections/ (Reason: The term "HTTP infrastructure" is fairly large and contains caches, proxies, load balancers, etc. I believe what you are most interested in reusing is the connection itself.) - S3: s/document details/document contains/ - S5: In the examples, you may want to provide some hints on how to base64 decode the encoded blob of text. I suspect you used uuencode(1) to encode, so simply pointing out to the reader to use uudecode(1) suffices. Alternatively (or in addition), you can use the Perl script contained in Section 5 of rfc6873 with one simple modification: rfc6873 uses "begin-base64 644 clf_record" as the begin marker, your examples imply that the begin marker should be "begin-base64 644 clf_ws_record" That's it. 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 nobody Mon Apr 7 20:53:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695AD1A00BC for ; Mon, 7 Apr 2014 20:53:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9wd6DO1Ebdr for ; Mon, 7 Apr 2014 20:53:31 -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 6F21D1A00B0 for ; Mon, 7 Apr 2014 20:53:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2096; q=dns/txt; s=iport; t=1396929206; x=1398138806; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=kmiZnYNlc1cZeTOayNi0reIuXsCPNifSrD9guBmYu/c=; b=I3hlLZSIWm5K0OUjGYOnttLcJgUXp4huCV5itRn+boqyQZK+XWufHDGq dK+/BEicLFBlNA6Xk0iquyoM4akz4jSq4ivX1R2FKefz2rCV2IVHFFphe AQbTWt1LT0/up+l8xPBzbsFNFsbMXnGBF4Gywvw26GnECnih4K9klZ9zP o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AmoFAEhxQ1OtJV2d/2dsb2JhbABZgwY7UQa8cYZmUYEhFnSCJQEBAQMBAQEBJhErCQsFCwIBAgY2ECcLJQIEDgWHcQgIBcsZF44IEQFQB4MkgRQElHCDbIx0AYVLgzByAQF+OQ X-IronPort-AV: E=Sophos;i="4.97,815,1389744000"; d="scan'208";a="315777621" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-1.cisco.com with ESMTP; 08 Apr 2014 03:53:25 +0000 Received: from xhc-aln-x12.cisco.com (xhc-aln-x12.cisco.com [173.36.12.86]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s383rPdA013788 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 8 Apr 2014 03:53:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.55]) by xhc-aln-x12.cisco.com ([173.36.12.86]) with mapi id 14.03.0123.003; Mon, 7 Apr 2014 22:53:25 -0500 From: "Gonzalo Salgueiro (gsalguei)" To: "Vijay K. Gurbani" Thread-Topic: [dispatch] Shepherd review of draft-salgueiro-dispatch-websocket-sipclf Thread-Index: AQHPUnILarQ6dsF+sk2DvaLID3UGi5sHaxqA Importance: high X-Priority: 1 Date: Tue, 8 Apr 2014 03:53:24 +0000 Message-ID: <61163C32-BA29-4AB8-B5CD-5896A93BCBC4@cisco.com> References: <5342BDAF.4060506@bell-labs.com> In-Reply-To: <5342BDAF.4060506@bell-labs.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.132.59] Content-Type: text/plain; charset="us-ascii" Content-ID: <713012C75FB28A438A33684B552BFC1D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/8tDwsMf6EfbYrlPreGH0X44tLfo Cc: "draft-salgueiro-dispatch-websocket-sipclf@tools.ietf.org" , "dispatch@ietf.org" Subject: Re: [dispatch] Shepherd review of draft-salgueiro-dispatch-websocket-sipclf X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 03:53:35 -0000 Thanks for your review, Vijay. I have submitted an -01 that hopefully addresses all your comments.=20 Reviews from others are certainly welcomed and much appreciated. Cheers, Gonzalo On Apr 7, 2014, at 11:01 AM, Vijay K. Gurbani wrote: > I am shepherding draft-salgueiro-dispatch-websocket-sipclf. >=20 > The document is ready to be sent further, but does need one more > revision to address minor issues identified below. Once a revision > is submitted, I will go ahead and post the PROTO writeup and we can > move ahead from there. >=20 > Here are the minor issues in document-order form: >=20 > - S1: s/two-way message/bi-directional message/ > - S1: s/reuse existing HTTP infrastructure/reuse existing transport > connections/ > (Reason: The term "HTTP infrastructure" is fairly large and > contains caches, proxies, load balancers, etc. I believe > what you are most interested in reusing is the connection > itself.) > - S3: s/document details/document contains/ > - S5: In the examples, you may want to provide some hints on how to > base64 decode the encoded blob of text. I suspect you used > uuencode(1) to encode, so simply pointing out to the reader to > use uudecode(1) suffices. >=20 > Alternatively (or in addition), you can use the Perl script > contained in Section 5 of rfc6873 with one simple modification: > rfc6873 uses "begin-base64 644 clf_record" as the begin marker, > your examples imply that the begin marker should be > "begin-base64 644 clf_ws_record" >=20 > That's it. Thanks, >=20 > - vijay > --=20 > 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 >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 8 00:14:40 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 785EF1A0170 for ; Tue, 8 Apr 2014 00:14:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.579 X-Spam-Level: X-Spam-Status: No, score=-3.579 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhhzO1n8DkcS for ; Tue, 8 Apr 2014 00:14:33 -0700 (PDT) Received: from na3sys009aog115.obsmtp.com (na3sys009aog115.obsmtp.com [74.125.149.238]) by ietfa.amsl.com (Postfix) with SMTP id 7903A1A0141 for ; Tue, 8 Apr 2014 00:14:33 -0700 (PDT) Received: from mail-we0-f181.google.com ([74.125.82.181]) (using TLSv1) by na3sys009aob115.postini.com ([74.125.148.12]) with SMTP ID DSNKU0Oh0yWFalKRmpHVQ7XYOk8whUe8xXzn@postini.com; Tue, 08 Apr 2014 00:14:28 PDT Received: by mail-we0-f181.google.com with SMTP id q58so481965wes.40 for ; Tue, 08 Apr 2014 00:14:26 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=9bOEZCATEIlSz14OszWu1HDIIer8O6MzsiBqpLtSg0o=; b=BtiAYSZqGcoh+lRSiRMjJOmhNIkcw0dwXGtpQs5/agsnfRYIulv5jSgQEkcGOQQB86 T4KUo++Fvm0YZ8ZuVX2DKd54Bnr1TgDSKD7oDrnHoP81vubX+/WKtq9w0mrV7BrZ7wq/ iVYwJ565n3gkmLDlBoTsioC5zDomhS7lQgH9+PxexWJtZFpMxZ3/u2Lu3WiaIRk/cfta yqHPmlXINpxzalF12oJylZ2JGQrA95OvWWMnLVAm9yOlrlTQ1iArXmm4sMYU8JNMQg2P RxLMsc/MfddFw5X3OUDygsLHAXePomsY1bop1EejozL+XmdQEA2/zpa0uMA7j4sjJ/zd 7Shw== X-Gm-Message-State: ALoCoQmtqT7iq2yEaC8mLiTQtOIVEwB1Fk8eCwiUaGK6uHPvMZhc/yWFvsgUW7V1V/agyispJktAOkIMCbJJ3eQEVaLhQ5qusp8TfzQoV0nds2G2pSRnftcBb6XDC9DZ6HNqJToli0gq X-Received: by 10.194.92.228 with SMTP id cp4mr50237wjb.81.1396941266373; Tue, 08 Apr 2014 00:14:26 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.194.92.228 with SMTP id cp4mr50224wjb.81.1396941266175; Tue, 08 Apr 2014 00:14:26 -0700 (PDT) Received: by 10.194.77.205 with HTTP; Tue, 8 Apr 2014 00:14:26 -0700 (PDT) In-Reply-To: References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> <53419D3A.1010103@alum.mit.edu> Date: Tue, 8 Apr 2014 08:14:26 +0100 Message-ID: From: Michael Procter To: "Olle E. Johansson" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/aqHlN86TJDu8gheR7w3tj1eD17k Cc: IETF Dispatch Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 07:14:38 -0000 You could respond to an initial request with a "301 Moved Permanently", specifying a sips: address instead ;-) That should "update any local directories, address books, and user location caches". More seriously, one of the reasons an approach like this wouldn't work is the limited level of support for TLS, combined with a reluctance to use it sensibly. I can't be the only person who has seen a UA configured to use TLS, only use it for the initial INVITE and then drop back to UDP for in-dialog traffic! I'm not sure we need new headers/protocol work to get a HSTS-like feature for SIP, but there may be some useful guidance that could be issued to help use the pieces we already have. Michael On 6 April 2014 19:36, Olle E. Johansson wrote: > > On 06 Apr 2014, at 20:30, Paul Kyzivat wrote: > >> On 4/6/14 3:13 AM, Olle E. Johansson wrote: >>> >>> On 06 Apr 2014, at 06:33, Paul Kyzivat wrote: >>> >>>> On 4/5/14 3:49 PM, Olle E. Johansson wrote: >>>>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>>>> >>>>> Is this something we can use in SIP? >>>> >>>> Perhaps in SIP over websockets. >>>> >>>> With SIP over UDP or TCP there would be no way for the server to communicate it to the client. >>> Of course we can communicate it in the response, like HTTP, over any transport. >>> "You should be using TLS for this connection from now on" >> >> Oh, I misunderstood in my *very* brief look at the reference. >> >> So you mean that for sip there would be a new header field in some sip response that would provide this hint? >> >>> Now the question is what it would mean... If the sip outbound connection is over TCP to >>> the edge proxy and someone beyond that proxy requests TLS, there's not much a UA >>> can do. I guess it can be one hop only. >>>> >>>> The mechanism we have is DNSSRV, indicating that only TLS is supported. >>> I guess you mean NAPTR. >> >> Yeah, sorry. >> >>> The idea with HSTS is for a user agent to "remember" that TLS was required for a >>> specific target in case a middlebox suddenly changes the DNS record and forces >>> another target. >> >> ISTM that the usage model it is based on doesn't fit well with sip. >> It seems to be predicated on the client being a browser, that has a cache of visited web addresses. >> >> Sip doesn't have that. Also, ISTM that proxies totally mess this up. >> > HTTP did not have a cache on SSL fingerprints or HSTS either, so that's no good argument ;-) > > For TOFU - Trust On First use - kind of solutions we will need a cache - if we go down that path. Save known fingerprints and make sure we get the same next time. > > We need to figure out how to apply one or a few of these solutions to SIP clients. > > /O > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 8 05:52:49 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1281A0166 for ; Tue, 8 Apr 2014 05:52:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.149 X-Spam-Level: * X-Spam-Status: No, score=1.149 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0oV_lFRSfG7m for ; Tue, 8 Apr 2014 05:52:43 -0700 (PDT) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 590031A0130 for ; Tue, 8 Apr 2014 05:52:42 -0700 (PDT) Received: from [192.168.16.131] (host-62-245-202-230.customer.m-online.net [62.245.202.230]) by smtp7.webway.se (Postfix) with ESMTPA id 54E2C93C2A1; Tue, 8 Apr 2014 12:52:13 +0000 (UTC) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 8 Apr 2014 14:52:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> <53419D3A.1010103@alum.mit.edu> To: Michael Procter X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/40_MJMYqv2iqAUE5AcSGqM6W4fE Cc: IETF Dispatch Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 12:52:47 -0000 On 08 Apr 2014, at 09:14, Michael Procter wrote: > You could respond to an initial request with a "301 Moved > Permanently", specifying a sips: address instead ;-) That should > "update any local directories, address books, and user location > caches". >=20 > More seriously, one of the reasons an approach like this wouldn't work > is the limited level of support for TLS, combined with a reluctance to > use it sensibly. I can't be the only person who has seen a UA > configured to use TLS, only use it for the initial INVITE and then > drop back to UDP for in-dialog traffic! >=20 > I'm not sure we need new headers/protocol work to get a HSTS-like > feature for SIP, but there may be some useful guidance that could be > issued to help use the pieces we already have. We can do a lot to help people who don't read RFCs, but we can't stop standards development because of them. For those that use TLS, and = there is luckily a growing number (based on customer requests) I think a=20 HSTS-like feature would be good to avoid MITM boxes downgrading connections with a 30x. No, I haven't seen those boxes yet - but I guess that is a matter of = time only. Well, it was just a thought. /O >=20 > Michael >=20 > On 6 April 2014 19:36, Olle E. Johansson wrote: >>=20 >> On 06 Apr 2014, at 20:30, Paul Kyzivat wrote: >>=20 >>> On 4/6/14 3:13 AM, Olle E. Johansson wrote: >>>>=20 >>>> On 06 Apr 2014, at 06:33, Paul Kyzivat = wrote: >>>>=20 >>>>> On 4/5/14 3:49 PM, Olle E. Johansson wrote: >>>>>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>>>>>=20 >>>>>> Is this something we can use in SIP? >>>>>=20 >>>>> Perhaps in SIP over websockets. >>>>>=20 >>>>> With SIP over UDP or TCP there would be no way for the server to = communicate it to the client. >>>> Of course we can communicate it in the response, like HTTP, over = any transport. >>>> "You should be using TLS for this connection from now on" >>>=20 >>> Oh, I misunderstood in my *very* brief look at the reference. >>>=20 >>> So you mean that for sip there would be a new header field in some = sip response that would provide this hint? >>>=20 >>>> Now the question is what it would mean... If the sip outbound = connection is over TCP to >>>> the edge proxy and someone beyond that proxy requests TLS, there's = not much a UA >>>> can do. I guess it can be one hop only. >>>>>=20 >>>>> The mechanism we have is DNSSRV, indicating that only TLS is = supported. >>>> I guess you mean NAPTR. >>>=20 >>> Yeah, sorry. >>>=20 >>>> The idea with HSTS is for a user agent to "remember" that TLS was = required for a >>>> specific target in case a middlebox suddenly changes the DNS record = and forces >>>> another target. >>>=20 >>> ISTM that the usage model it is based on doesn't fit well with sip. >>> It seems to be predicated on the client being a browser, that has a = cache of visited web addresses. >>>=20 >>> Sip doesn't have that. Also, ISTM that proxies totally mess this up. >>>=20 >> HTTP did not have a cache on SSL fingerprints or HSTS either, so = that's no good argument ;-) >>=20 >> For TOFU - Trust On First use - kind of solutions we will need a = cache - if we go down that path. Save known fingerprints and make sure = we get the same next time. >>=20 >> We need to figure out how to apply one or a few of these solutions to = SIP clients. >>=20 >> /O >>=20 >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch From nobody Tue Apr 8 09:20:27 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2D5C1A0464 for ; Tue, 8 Apr 2014 09:20:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TBSWTz_atTgH for ; Tue, 8 Apr 2014 09:20:21 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id EAEB01A0436 for ; Tue, 8 Apr 2014 09:20:20 -0700 (PDT) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by QMTA11.westchester.pa.mail.comcast.net with comcast id nTuN1n00417dt5G5BULLzC; Tue, 08 Apr 2014 16:20:20 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id nULL1n00U3ZTu2S3ZULLWl; Tue, 08 Apr 2014 16:20:20 +0000 Message-ID: <534421C4.7060801@alum.mit.edu> Date: Tue, 08 Apr 2014 12:20:20 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "Olle E. Johansson" References: <20DC24BF-AAAC-4867-B4ED-E66E081CA495@edvina.net> <5340D92D.7040001@alum.mit.edu> <4A7D17AC-6A4F-484A-B61E-E73423B28B83@edvina.net> <53419D3A.1010103@alum.mit.edu> In-Reply-To: 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=q20140121; t=1396974020; bh=gtF4+NT+1SH+p+RFqOx7Uy5PS5KofEyFD9oGVVb/kSY=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Vdg4MGMsVgMn9SJNlibkwd/eQHfC+LV6qUqIPKzYc6bKrRdPoMagfS2xUtl1XcZsp kGYoY0KIH7wJlLLRyx9DR6W0CPQX2qw5ptHop62CtXUE43DJwAFxowkXMYd7yCj0hh Kc/JJrCSdqlQPd3073ZfXA+XCM4J32AtxS5k7nB5Haqt1Mpc4hrTpEGpfB316mOTHt ffbzG9xiE2H8LuOCE2mLFZyiNvJie1Ls0OkJzbSKdApjpLucYLxVaH9/6xNCd2DnPA /vnftVK7xskLWaaunRRE5MmjXaVolT01qR2z7xjgpk+g7dPGg0J4EdPc+0/3USF5qc Ev5Eg4G9UPE1g== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/iCfZ_G4rhxEjB1u4i1ApLWq63vM Cc: dispatch@ietf.org Subject: Re: [dispatch] HSTS for SIP? X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Apr 2014 16:20:24 -0000 Olle, I'm generally not understanding the point of this for SIP. What would it bring that we need and don't already have without it? Thanks, Paul On 4/6/14 2:36 PM, Olle E. Johansson wrote: > > On 06 Apr 2014, at 20:30, Paul Kyzivat wrote: > >> On 4/6/14 3:13 AM, Olle E. Johansson wrote: >>> >>> On 06 Apr 2014, at 06:33, Paul Kyzivat wrote: >>> >>>> On 4/5/14 3:49 PM, Olle E. Johansson wrote: >>>>> http://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security >>>>> >>>>> Is this something we can use in SIP? >>>> >>>> Perhaps in SIP over websockets. >>>> >>>> With SIP over UDP or TCP there would be no way for the server to communicate it to the client. >>> Of course we can communicate it in the response, like HTTP, over any transport. >>> "You should be using TLS for this connection from now on" >> >> Oh, I misunderstood in my *very* brief look at the reference. >> >> So you mean that for sip there would be a new header field in some sip response that would provide this hint? >> >>> Now the question is what it would mean... If the sip outbound connection is over TCP to >>> the edge proxy and someone beyond that proxy requests TLS, there's not much a UA >>> can do. I guess it can be one hop only. >>>> >>>> The mechanism we have is DNSSRV, indicating that only TLS is supported. >>> I guess you mean NAPTR. >> >> Yeah, sorry. >> >>> The idea with HSTS is for a user agent to "remember" that TLS was required for a >>> specific target in case a middlebox suddenly changes the DNS record and forces >>> another target. >> >> ISTM that the usage model it is based on doesn't fit well with sip. >> It seems to be predicated on the client being a browser, that has a cache of visited web addresses. >> >> Sip doesn't have that. Also, ISTM that proxies totally mess this up. >> > HTTP did not have a cache on SSL fingerprints or HSTS either, so that's no good argument ;-) > > For TOFU - Trust On First use - kind of solutions we will need a cache - if we go down that path. Save known fingerprints and make sure we get the same next time. > > We need to figure out how to apply one or a few of these solutions to SIP clients. > > /O > > From nobody Mon Apr 14 06:41:19 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C01A0460 for ; Mon, 14 Apr 2014 06:41:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MQqLzEVDV7xi for ; Mon, 14 Apr 2014 06:41:11 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 90CE01A0109 for ; Mon, 14 Apr 2014 06:41:11 -0700 (PDT) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s3EDf4qk007505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 14 Apr 2014 08:41:05 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s3EDf48O007268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 14 Apr 2014 08:41: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 s3EDf4Qu011528 for ; Mon, 14 Apr 2014 08:41:04 -0500 (CDT) Message-ID: <534BE5D8.4010609@bell-labs.com> Date: Mon, 14 Apr 2014 08:42:48 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dispatch@ietf.org" Content-Type: multipart/mixed; boundary="------------030102020801020908030908" X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/57-hAebCEMEuvzkI1QYxH25tFQs Subject: [dispatch] PROTO writeup for http://tools.ietf.org/html/draft-salgueiro-dispatch-websocket-sipclf X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Apr 2014 13:41:16 -0000 This is a multi-part message in MIME format. --------------030102020801020908030908 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Folks: Attached is the PROTO writeup for draft-salgueiro-dispatch-websocket-sipclf. The draft is being published through the AD-sponsored stream. I will send a request to the sponsoring AD (Richard Barnes) to start his magic on the draft. Cheers, - 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 --------------030102020801020908030908 Content-Type: text/plain; charset=UTF-8; name="PROTO.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="PROTO.txt" PROTO questionnaire for: draft-salgueiro-dispatch-websocket-sipclf-00 To be Published as: Proposed Standard Prepared by: Vijay Gurbani (vkg@bell-labs.com) on 14 April 2014 (with help from Gonzalo Salgueiro) (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this type of RFC indicated in the title page header? This document is requested to be published as a Proposed Standard. This is the proper type of RFC as it requires IANA registrations for a registry that requires a standards track RFC. This RFC type is indicated on the title page. (2) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up. Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary: RFC 7118 specifies a WebSocket sub-protocol as a reliable real-time transport mechanism between Session Initiation Protocol (SIP) entities to enable usage of SIP in web-oriented deployments. This document updates the SIP Common Log Format (CLF), defined in RFC 6873, with a new "Transport Flag" for such SIP WebSocket transport. Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? With the SIPCLF WG recently closed, this document was not contextually relevant within any active WG charters. The narrow scope of the document didn't warrant creation of a new WG, so RAI ADs and DISPATCH WG chairs agreed that an AD sponsored individual draft was the proper course of action. Document Quality: Are there existing implementations of the protocol? Have a significant number of vendors indicated their plan to implement the specification? Are there any reviewers that merit special mention as having done a thorough review, e.g., one that resulted in important changes or a conclusion that the document had no substantive issues? If there was a MIB Doctor, Media Type or other expert review, what was its course (briefly)? In the case of a Media Type review, on what date was the request posted? SIP CLF Transport Flag values must be registered via the IETF Review method described in RFC5226. This document updates RFC 6873 by defining a new SIP CLF "Transport Flag" value for WebSocket ('W'). Personnel: Who is the Document Shepherd? Who is the Responsible Area Director? Vijay Gurbani is the Document Shepherd. Richard Barnes is the Responsible AD. (3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG. The draft uses well established conventions of representing long lines for RFC consumption. It adds a new Transport Flag type ('W') to the existing registry for SIP CLF transport flags established by rfc6873. The document shepherd reviewed the -00 version of the draft (please see http://www.ietf.org/mail-archive/web/dispatch/current/msg05456.html). A -01 version was released to attend to the review. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? There are no concerns about the depth or breadth of the reviews. (5) Do portions of the document need review from a particular or from broader perspective, e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization? If so, describe the review that took place. No. (6) Describe any specific concerns or issues that the Document Shepherd has with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. There are no specific concerns or issues. (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR disclosures filed by any of the authors of the draft. (9) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? Consensus represents the strong concurrence of a few individuals, with others being silent. No one has expressed concerns about its progression. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is publicly available.) No. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. The document passes idnits 2.13.01. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. SIP CLF Transport Flag values must be registered via the IETF Review method described in RFC5226. This document serves as the Standards Track RFC to make this SIP CLF "Transport Flag" registration. (13) Have all references within this document been identified as either normative or informative? Yes. (14) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the plan for their completion? No. The references are split between normative and informative; all the normative references are to RFCs. None are downward references. (15) Are there downward normative references references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure. No. (16) Will publication of this document change the status of any existing RFCs? Are those RFCs listed on the title page header, listed in the abstract, and discussed in the introduction? If the RFCs are not listed in the Abstract and Introduction, explain why, and point to the part of the document where the relationship of this document to the other RFCs is discussed. If this information is not in the document, explain why the WG considers it unnecessary. This document updates RFC 6873 and it is explicitly indicated in the title page header and the Abstract. (17) Describe the Document Shepherd's review of the IANA considerations section, especially with regard to its consistency with the body of the document. Confirm that all protocol extensions that the document makes are associated with the appropriate reservations in IANA registries. Confirm that any referenced IANA registries have been clearly identified. Confirm that newly created IANA registries include a detailed specification of the initial contents for the registry, that allocations procedures for future registrations are defined, and a reasonable name for the new registry has been suggested (see RFC 5226). (18) List any new IANA registries that require Expert Review for future allocations. Provide any public guidance that the IESG would find useful in selecting the IANA Experts for these new registries. The document shepherd has reviewed the IANA Considerations section and confirms the veracity the registration. This document defines no new IANA registries. It does, however, populate existing SIP CLF registry with a new entry. Such a population requires IETF Review registration policy, which is fulfilled by the document under consideration. (19) Describe reviews and automated checks performed by the Document Shepherd to validate sections of the document written in a formal language, such as XML code, BNF rules, MIB definitions, etc. The document shepherd has reviewed the examples in Section 5.1, including unencoding the base64 text to ensure that they match the cleartext (they do). Beyond this, the document itself does not define new XML, BNF rules or MIB definitions. --------------030102020801020908030908-- From nobody Tue Apr 22 19:05:29 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF07E1A02EB; Tue, 22 Apr 2014 19:05:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.172 X-Spam-Level: X-Spam-Status: No, score=-2.172 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.272] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w762J7e0r6my; Tue, 22 Apr 2014 19:05:20 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5B11A00FC; Tue, 22 Apr 2014 19:05:16 -0700 (PDT) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3N258MM044627 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 22 Apr 2014 21:05:10 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [173.172.146.58] claimed to be [10.0.1.29] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ben Campbell Date: Tue, 22 Apr 2014 21:05:08 -0500 X-Mao-Original-Outgoing-Id: 419911508.354364-d1644464687562143e870b731dc196ed Content-Transfer-Encoding: quoted-printable Message-Id: <8884698C-5A65-4F1A-860F-6B54E66503D1@nostrum.com> References: <5BA2B746-FB80-4564-B6D0-97F7D8F843FF@nostrum.com> To: rai@ietf.org, DISPATCH X-Mailer: Apple Mail (2.1874) Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/kUCso0oP6faqSEsDBhOnpOE72B4 Subject: [dispatch] Fwd: [Dart] We're Official! X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Apr 2014 02:05:26 -0000 Hi, In case anyone missed it, the DART working group charter has been = approved. The mailing list is dart@ietf.org . Thanks! Ben. Begin forwarded message: > From: Ben Campbell > Subject: [Dart] We're Official! > Date: April 22, 2014 at 4:27:14 PM CDT > To: dart@ietf.org > Cc: Richard Barnes , Cullen Jennings , = "Black, David" , Dan York >=20 > The DART working group is official. The approved charter is available = at http://datatracker.ietf.org/wg/dart/charter/=20 >=20 > We've got a milestone to deliver an informational draft to the IESG by = August. That time will pass quickly, so I ask participants to hit the = ground running. I understand that Dan, David, and Cullen are working on = an initial draft. I will send an update to the list as soon as we have = an estimated date for the 00 version. >=20 > Thanks! >=20 > Ben. > _______________________________________________ > Dart mailing list > Dart@ietf.org > https://www.ietf.org/mailman/listinfo/dart From nobody Mon Apr 28 04:44:32 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE7291A081B for ; Mon, 28 Apr 2014 04:44:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id enQtkYnvddHa for ; Mon, 28 Apr 2014 04:44:29 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) by ietfa.amsl.com (Postfix) with ESMTP id A7E881A078B for ; Mon, 28 Apr 2014 04:44:28 -0700 (PDT) X-AuditID: c1b4fb3a-f79156d000001144-55-535e3f1b23aa Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 60.3B.04420.B1F3E535; Mon, 28 Apr 2014 13:44:27 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 13:44:27 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+Ijg== Date: Mon, 28 Apr 2014 11:44:26 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@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.19] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1D2E20D2ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvja60fVywwddjshZLJy1gdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxv0zfUwFR+Qr9q6bxdzAeFi6i5GTQ0LARKL1y0l2CFtM4sK9 9WxdjFwcQgJHGSXeLdjJAuEsYZS4OOE2axcjBwebgIVE9z9tkAYRAW2Jo6u6mEFsYaBBO+d8 YISIW0pcudzFBmHrSezsusgCYrMIqEpsvXqcBWQMr4CvxMZPuSBhRqC930+tYQKxmQXEJW49 mc8EcY+AxJI955khbFGJl4//sULYihLtTxsYIerzJRYtnwIW5xUQlDg58wnLBEahWUhGzUJS NgtJGURcR2LB7k9sELa2xLKFr5lh7DMHHjMhiy9gZF/FKFqcWlycm25kpJdalJlcXJyfp5eX WrKJERgRB7f8ttrBePC54yFGAQ5GJR7e4i+RwUKsiWXFlbmHGKU5WJTEeSctcg8WEkhPLEnN Tk0tSC2KLyrNSS0+xMjEwSnVwOjFsu5hwsO1/bEHtGuPPFjpZMXmJndm2+xZ0f8nB0dMKi79 xbHow4X8A5vzV1U3v7Iru5AgsdVQjfv1a1bF93ueJv8PXDK7fo4M46sa9ddKbDvT6x3inr86 Uqt40vTUHKspFqFS8af2XD5162mx8TG7dfO1WhaLHn3B80jE6H/cmfkrDASVRI8rsRRnJBpq MRcVJwIA9NAPmWkCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/88YWCxQR4rCa0CK73BstOMD1vdA Subject: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 11:44:31 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1D2E20D2ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new draft, draft-holmberg-dispatch-iotl-00. The draft defines a new SIP URI parameter, which can be used to associate a= SIP URI with the end of a so called traffic leg, which is a specific part = of a signaling path (see more in the draft for details). This information i= s very important in scenarios where the signaling traverse different operat= or networks, where a user can be located in its home network or in a visite= d network (in case of roaming), etc. The draft is needed for 3GPP, but we've tried to write it in a way so that = it can also be applied to other environments. http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.txt Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1D2E20D2ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ve submitted a new draft, draft-holmberg-di= spatch-iotl-00.

 

The draft defines a new SIP URI parameter, which can= be used to associate a SIP URI with the end of a so called traffic leg, wh= ich is a specific part of a signaling path (see more in the draft for detai= ls). This information is very important in scenarios where the signaling traverse different operator networks, whe= re a user can be located in its home network or in a visited network (in ca= se of roaming), etc.

 

The draft is needed for 3GPP, but we’ve tried = to write it in a way so that it can also be applied to other environments.<= o:p>

 

http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.t= xt

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B1D2E20D2ESESSMB209erics_-- From nobody Mon Apr 28 08:25:36 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D8D11A04B9 for ; Mon, 28 Apr 2014 08:25:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lo9R6lNjqLSO for ; Mon, 28 Apr 2014 08:25:32 -0700 (PDT) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA6A1A048C for ; Mon, 28 Apr 2014 08:25:29 -0700 (PDT) Received: from omta18.westchester.pa.mail.comcast.net ([76.96.62.90]) by qmta08.westchester.pa.mail.comcast.net with comcast id vSjo1n0041wpRvQ58TRV9f; Mon, 28 Apr 2014 15:25:29 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta18.westchester.pa.mail.comcast.net with comcast id vTRU1n00b1KKtkw3eTRUXQ; Mon, 28 Apr 2014 15:25:29 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3SFPSfo006922; Mon, 28 Apr 2014 11:25:28 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3SFPSvs006921; Mon, 28 Apr 2014 11:25:28 -0400 Date: Mon, 28 Apr 2014 11:25:28 -0400 Message-Id: <201404281525.s3SFPSvs006921@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Christer Holmberg In-reply-to: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> (christer.holmberg@ericsson.com) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398698729; bh=HlWkNW4FqcubDTL07+73EppzmqdBX7juXtfblgfjZyc=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=QPVyYDRfoEkF49E5/g3tC0QTqPqmzPk5pwPRiwYjF6EkkoG7kmw7XgY+Egq0HwVyJ qKFywwVn0aOc0+7vyk0LCUY8Feiqhc77pU31itOqi9FF0gr/P15flLT4hXl8K+eg+1 NVd/qrYNJAZ4l/NhdxU5bsYwQdiDEpy1Kyy4mFGKbsyGN5nfRgNCcBo37Nk+Vd0zH5 aSUkfzqkQQCEwTcXe+1F4yzGU4WSaxyhymdCpXT81rgEHiWeu0jOC59xPkJ8mkMExy 1hZjrYNHhA2aqAo3WrJSKELlZRJwRydkw8n/4Z+zqFY6dm/PvmMIxppa8g3uNW1Ks2 SCq+ia6eiCbeg== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/cusYoNtpc3GAaQczQBLzCtB_NWo Cc: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:25:33 -0000 > From: Christer Holmberg > We've submitted a new draft, draft-holmberg-dispatch-iotl-00. Interesting... Why is "iotl" listed as having no predefined values in section 7: 7. IANA Considerations [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This specification adds one new value to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [RFC3969]. Parameter Name Predefined Values Reference ____________________________________________ iotl NO [This RFC] while section 5.2 gives five predefined values, which seem to be the only values that are expected to be used. (Though the BNF provides for extension values.) iotl-value = "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" / "homeA-visitedA" /" visitedA-homeB" / gen-value Dale From nobody Mon Apr 28 08:36:49 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EF5C1A6F04 for ; Mon, 28 Apr 2014 08:36:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vuvqw8_-jlKQ for ; Mon, 28 Apr 2014 08:36:46 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 446C21A0A0F for ; Mon, 28 Apr 2014 08:36:46 -0700 (PDT) X-AuditID: c1b4fb30-f790e6d000001067-8c-535e758cb31a Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 49.27.04199.C857E535; Mon, 28 Apr 2014 17:36:44 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0174.001; Mon, 28 Apr 2014 17:36:44 +0200 From: Christer Holmberg To: "Dale R. Worley" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAH9sLsAABkXY4= Date: Mon, 28 Apr 2014 15:36:44 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se>, <201404281525.s3SFPSvs006921@hobgoblin.ariadne.com> In-Reply-To: <201404281525.s3SFPSvs006921@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrALMWRmVeSWpSXmKPExsUyM+JvjW5PaVywwZ6zRhZLJy1gtXh5osyB yWPy/q/MHkuW/GQKYIrisklJzcksSy3St0vgyvh5bhVbQTdnxdEDzUwNjI/Yuhg5OSQETCT6 F31ngbDFJC7cWw8U5+IQEjjKKNF56QAzhLOEUeLN6dWMXYwcHGwCFhLd/7RBTBEBTYmOBTkg vcwC2hL/r69jBLGFBZwl7kx8zw5iiwi4SOz63A1lW0msWP8RbC+LgKrEnQsrwfbyCrhJTJ30 AWpvI6PEq84nYA2cAg4SvQ0zmEFsRqDjvp9awwSxTFzi1pP5TBBHC0gs2XOeGcIWlXj5+B8r RI2exI2pU9hgjlu28DUzxDJBiZMzn7BMYBSdhWTULCQts5C0zELSsoCRZRWjaHFqcVJuupGR XmpRZnJxcX6eXl5qySZGYJQc3PLbYAfjy+eOhxgFOBiVeHiLv0QGC7EmlhVX5h5ilOZgURLn /XbWPVhIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QDo4hkbz7PzBbe1NzNy9ctE+Tpejhv6tIq /k986+Tb9nz6IOxd9m7+rU1bXlydc1D/3/TzJqvSpU//X6bsKvmQody75q/PRH6zsAa++pKp Sw/8OfU+0sTd9+3KmpW8J7Lsb8UaVTFMlo/vyfzmZNqVZuS8O9XRNDVZbIGiQtfzT4+DazYv u3x5hxJLcUaioRZzUXEiAPUCREFzAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/zlvQhjLLGfqfxYRYvE2XTqKpDqE Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 15:36:48 -0000 Hi Dale, It may be a mistake. I'll look into it at the office tomorrow. Thanks! Regards, Christer Sent from my Sony Ericsson Xperia arc S "Dale R. Worley" wrote: > From: Christer Holmberg > We've submitted a new draft, draft-holmberg-dispatch-iotl-00. Interesting... Why is "iotl" listed as having no predefined values in section 7: 7. IANA Considerations [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.] This specification adds one new value to the IANA registration in the "SIP/SIPS URI Parameters" registry as defined in [RFC3969]. Parameter Name Predefined Values Reference ____________________________________________ iotl NO [This RFC] while section 5.2 gives five predefined values, which seem to be the only values that are expected to be used. (Though the BNF provides for extension values.) iotl-value =3D "homeA-homeB" / "homeB-visitedB" / "visitedA-homeA" / "homeA-visitedA" /" visitedA-homeB" / gen-value Dale From nobody Mon Apr 28 12:23:19 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 761061A6FF8; Mon, 28 Apr 2014 12:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.551 X-Spam-Level: X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLLV4dkavvdg; Mon, 28 Apr 2014 12:23:14 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) by ietfa.amsl.com (Postfix) with ESMTP id 502A41A6FBA; Mon, 28 Apr 2014 12:23:14 -0700 (PDT) Received: from unnumerable.local (pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66]) (authenticated bits=0) by nostrum.com (8.14.8/8.14.7) with ESMTP id s3SJNCXZ001945 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=OK); Mon, 28 Apr 2014 14:23:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host pool-173-57-107-66.dllstx.fios.verizon.net [173.57.107.66] claimed to be unnumerable.local Message-ID: <535EAAA0.6000509@nostrum.com> Date: Mon, 28 Apr 2014 14:23:12 -0500 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: rai@ietf.org References: <532B2896.6090502@nostrum.com> In-Reply-To: <532B2896.6090502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/oXxZkUsWPu5ga8TecHX55ziQSy4 Cc: dispatch@ietf.org Subject: Re: [dispatch] [RAI] SIPit 31 registration is open X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 19:23:17 -0000 On 3/20/14, 12:42 PM, Robert Sparks wrote: > SIPit 31 will be held in Nice, France Sep 28 - Oct 3, 2014. > The event will be hosted by ETSI. > > More information, and the registration page, is available at > > Please take advantage of the opportunity to register early. Please note the new information about the hotel block at the link above (you may have to expand the section titled "Nice, France" to see it). In particular, the hotel block rate guarantee requires reservation before 31 July, 2014. > > In addition to the normal team-to-team testing at the event, > we will be concentrating on several specific interoperability areas: > * Nat and Firewall Traversal using Outbound, TURN, and STUN > * RTCWeb > * Advanced Video scenarios > * Use of TLS and DTLS > > If you're planning to attend and have other areas you would like > have a multi-team focus session around, please let me know. > > RjS > > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From nobody Mon Apr 28 14:20:09 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47D041A797C for ; Mon, 28 Apr 2014 14:20:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07egzyIokNTL for ; Mon, 28 Apr 2014 14:20:02 -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 007D21A7D82 for ; Mon, 28 Apr 2014 14:20:01 -0700 (PDT) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta14.westchester.pa.mail.comcast.net with comcast id vWPk1n00B0ldTLk5EZL0cR; Mon, 28 Apr 2014 21:20:00 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id vZL01n01C3ZTu2S01ZL0LA; Mon, 28 Apr 2014 21:20:00 +0000 Message-ID: <535EC600.3010709@alum.mit.edu> Date: Mon, 28 Apr 2014 17:20:00 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dispatch@ietf.org References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398720000; bh=XPpu0weGwNbCbgQZM5P9XYdjiryzTFc10HAQW5kiQ5w=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Nfy4bJyThBWFjfpPgJb5Mw290gwi8Gu5f5NPOsRux33b9n2Imn8a47vno8vT/rjTb DboMT2VRvS6G1BB7QjKNh6i8wHi3r8GlsPrBb/tTWiL8sW4h6CrspN5YoB3aQOxDSl VM43B7BgH1jvCCSGVKXXetQtoL9nA7WlldN6Z56H6f42ngQUekMnKCfIexAJZ0aLpB 0VsPDvo3Su14CM2W+qu/hcV3Q7ldfm18pKs9UxB91lAv2zieYa5NR+iwAaBToLcxyV k0HHmitY+Q/Tc7/BGBA07+vIbPqmPobU3eHTPuDSiA2BknfuaNsqdM6sjsDZPU79qE GQupcuFSHEOmQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/QxlhRCc8y8g1NYDMyBfK1QG4bC8 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Apr 2014 21:20:03 -0000 Well, I read this draft, but I don't think I understand it. I may *partially* understand it in the context of IMS. But I don't understand it in the abstract. In particular I don't understand what you mean by "traffic leg". What I do understand is that the signaling path of a request can be described by a route. When the request is sent the route is described, in part, by the Route header and the r-uri. When the request has reached the recipient, the route is described by the Via header. But the Route header may be incomplete, and the Via header may be obfuscate. But certainly the request ends up traversing some set of sip nodes starting with the UAC and ending with the UAS, and we can view it as the actual route even if it was never encoded anywhere. I *guess* you are proposing that this route can be *partitioned* into segments called "traffic legs", that these legs have differing behaviors, and that these behaviors can be enumerated and named. Is that right? Further, I guess you are asserting that it is useful to know which URIs of hops along the route are part of which traffic legs. Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg. Suppose I have a route from Alice to Bob consisting of: Alice -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> Bob When I partition this into traffic legs, do the boundaries between the partitions fall on the nodes or on the hops between the nodes? In other words, does a node that ends one leg also originate another leg? What if a request was sent in the opposite direction over the same path. How would the use of iotl parameters differ on the two? Apparently you also are assuming that the *sender* of a request knows when a URI it is adding to the request denotes the end of a traffic leg. (Could it not be possible that the sender doesn't know, but the recipient does?) Another thing: Dale already asked about the IANA considerations - whether there are defined values. ISTM that in the context you have in mind (IMS) there are a fixed set of values that make sense, and further, that only certain combinations of those values make sense. In some other application, other values and combinations of values might make sense. Most of what I mention above seems like stuff that ought to be addressed in the draft, one way or another. It also seems to me that there is some conceptual overlap between this draft and what INSIPID is doing. It too is concerned with requests and dialogs that traverse multiple legs, and has had difficulty clearly defining what it talking about. It is concerned largely with situations where the legs are defined by B2BUAs. I don't know if the legs you are talking about are the same or not. If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e? Thanks, Paul On 4/28/14 7:44 AM, Christer Holmberg wrote: > Hi, > > We’ve submitted a new draft, draft-holmberg-dispatch-iotl-00. > > The draft defines a new SIP URI parameter, which can be used to > associate a SIP URI with the end of a so called traffic leg, which is a > specific part of a signaling path (see more in the draft for details). > This information is very important in scenarios where the signaling > traverse different operator networks, where a user can be located in its > home network or in a visited network (in case of roaming), etc. > > The draft is needed for 3GPP, but we’ve tried to write it in a way so > that it can also be applied to other environments. > > http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.txt > > Regards, > > Christer > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Tue Apr 29 05:42:04 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE241A08C0 for ; Tue, 29 Apr 2014 05:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LJbDvUFZHM4x for ; Tue, 29 Apr 2014 05:42:00 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 0E3CF1A08BB for ; Tue, 29 Apr 2014 05:41:59 -0700 (PDT) X-AuditID: c1b4fb2d-f79036d00000126a-bf-535f9e16f72e Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 88.12.04714.61E9F535; Tue, 29 Apr 2014 14:41:58 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.191]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Tue, 29 Apr 2014 14:41:57 +0200 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAQJ0cAAB73ewA= Date: Tue, 29 Apr 2014 12:41:56 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> In-Reply-To: <535EC600.3010709@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.147] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM+Jvja7YvPhgg4//hC2WTlrAarFiwwFW ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStjQ+c55oJnGhV/Lv5haWBcqtDFyMkhIWAi 8ebsfzYIW0ziwr31QDYXh5DAUUaJw/NnM4MkhASWMEq0Ls7pYuTgYBOwkOj+pw0SFhEIljh4 eCcLiC0s4Czx7/AGdoi4i8Suz91QtpXE5ckfWEFsFgFVieNtaxlBbF4BX4k/r7+zg4wUEsiX 2NJZARLmFNCR2PhtFlgJI9A530+tYQKxmQXEJW49mc8EcaaAxJI955khbFGJl4//sYKMkRBQ kpi2NQ2iXEdiwe5PbBC2tsSyha+ZIbYKSpyc+YRlAqPoLCRTZyFpmYWkZRaSlgWMLKsYRYtT i4tz042M9VKLMpOLi/Pz9PJSSzYxAiPk4JbfujsYV792PMQowMGoxMNb/CUyWIg1say4MvcQ ozQHi5I4b9td72AhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjAzZLMtunGnZLjqFLfmCgYV3 qnsj66eFN56YHYiOj8qvlfs/47pIg///yvenHwmo//j951/pprIFq+boThHyXsQQMOPp9XvL 66VL9XfUnnmlHXuNhyVNae1MTZetDKLrdC5//z1ziqF7AatQmvTNhwIR5k35lac2hGwXncp4 vNcq/KTqxhmvFimxFGckGmoxFxUnAgAthjhjcQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/-xSFEzjpxeA6EqUExmSRA9yL76c Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Apr 2014 12:42:03 -0000 Hi Paul, See reply inline. > Well, I read this draft, but I don't think I understand it. > > I may *partially* understand it in the context of IMS. But I don't unders= tand it in the abstract. > > In particular I don't understand what you mean by "traffic leg". What I d= o understand is that the signaling path=20 > of a request can be described by a route. When the request is sent the ro= ute is described, in part, by the Route=20 > header and the r-uri. When the request has reached the recipient, the rou= te is described by the Via header. But=20 > the Route header may be incomplete, and the Via header may be obfuscate. = But certainly the request ends up=20 > traversing some set of sip nodes starting with the UAC and ending with th= e UAS, and we can view it as the actual=20 > route even if it was never encoded anywhere. > > I *guess* you are proposing that this route can be *partitioned* into seg= ments called "traffic legs", that these legs=20 > have differing behaviors, and that these behaviors can be enumerated and = named. Is that right? Correct. > Further, I guess you are asserting that it is useful to know which URIs o= f hops along the route are part of which traffic legs. Correct. > Then, the description of the parameter says the uri with the parameter is= the *end* of a traffic leg with that name. It says nothing about which nod= e or URI *starts* each leg. The each value description, the text says between which 3GPP nodes the traf= fic leg spans. There is no need to indicate the *start* in the signaling. If someone wants to use the mechanism in a non-3GPP environment, he/she of = course needs to provide similar text for that specific environment. > Suppose I have a route from Alice to Bob consisting of: > > Alice -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> Bob > > When I partition this into traffic legs, do the boundaries between the pa= rtitions fall on the nodes or on the hops=20 > between the nodes? In other words, does a node that ends one leg also ori= ginate another leg? What if a request=20 > was sent in the opposite direction over the same path. How would the use = of iotl parameters differ on the two?=20 > Apparently you also are assuming that the *sender* of a request knows whe= n a URI it is adding to the request=20 > denotes the end of a traffic leg. (Could it not be possible that the send= er doesn't know, but the recipient does?) In IMS the sender always knows. > Another thing: Dale already asked about the IANA considerations - whether= there are defined values. ISTM that in the context you have=20 > in mind (IMS) there are a fixed set of values that make sense, and furthe= r, that only certain combinations of those values make sense.=20 > In some other application, other values and combinations of values might = make sense. Sure, and the ABNF does allow for additional values/combinations to be defi= ned - either in the draft itself, or in future (we obviously need to define= the procedure for defining new values). > Most of what I mention above seems like stuff that ought to be addressed = in the draft, one way or another. Sure - this is only the first version :) > It also seems to me that there is some conceptual overlap between this dr= aft and what INSIPID is doing. It too is concerned=20 > with requests and dialogs that traverse multiple legs, and has had diffic= ulty clearly defining what it talking about. It is concerned=20 > largely with situations where the legs are defined by B2BUAs. I don't kno= w if the legs you are talking about are the same or not. There is no relation with the session id. In addition, with session id the aim is to keep the same value end-to-end, = which is not the case with iotl (as there may be multiple traffic legs on t= he path). > If B2BUAs (especially SBCs) are involved, is it important whether the iot= l parameters are preserved e2e? The iotl parameter only needs to be preserved until it is "consumed" at the= end of the traffic leg. Regards, Christer On 4/28/14 7:44 AM, Christer Holmberg wrote: > Hi, > > We've submitted a new draft, draft-holmberg-dispatch-iotl-00. > > The draft defines a new SIP URI parameter, which can be used to=20 > associate a SIP URI with the end of a so called traffic leg, which is=20 > a specific part of a signaling path (see more in the draft for details). > This information is very important in scenarios where the signaling=20 > traverse different operator networks, where a user can be located in=20 > its home network or in a visited network (in case of roaming), etc. > > The draft is needed for 3GPP, but we've tried to write it in a way so=20 > that it can also be applied to other environments. > > http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.txt > > Regards, > > Christer > > > > _______________________________________________ > 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 nobody Wed Apr 30 07:59:12 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FF6B1A08F1; Wed, 30 Apr 2014 07:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_FREEMAIL_DOC_PDF=0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nfkRIy0YtVpW; Wed, 30 Apr 2014 07:59:02 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id D238E1A6F03; Wed, 30 Apr 2014 07:59:01 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id f8so3069665wiw.3 for ; Wed, 30 Apr 2014 07:58:59 -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; bh=fqEnbk3NtDjBfvTicvyD2IDrmrbNul8l3p+5pEOGATw=; b=x+Vvhx1JGgjXCD0v5KLbLf7h6Uu16JIUdPDYh5mjKxBp8E97mDN2077Gkz7TZa8MGG nKEY7sDpYUI75ADBe9IGB+PwoTbtqQ+XChX4Yn4PKC3ugRLgUSUB9fM2+f4b7hM7xVtZ rRjP4TxFVh/MBLCHYJ6kdOuQhlg/jlD6d8pR5/4zMBx6rF4jH3zySp2nyVxzJzNX4Z9m 43P9HGg9S+GbcHRiiXxsOL2fSehNqxbT2Ke7SrpdawMJ/ni0vdt2don7KaTrLUaJOa6p ntrAtmCt9CHi14t8DQg3qFh360fw1lwvlPcTZY8gvjQuIB0tOhOUYFg7TFbfNbPvSd5k Jx3Q== MIME-Version: 1.0 X-Received: by 10.180.74.39 with SMTP id q7mr4056990wiv.36.1398869939771; Wed, 30 Apr 2014 07:58:59 -0700 (PDT) Received: by 10.216.93.68 with HTTP; Wed, 30 Apr 2014 07:58:59 -0700 (PDT) In-Reply-To: <53602729.474be00a.2f3d.66aaSMTPIN_ADDED_BROKEN@mx.google.com> References: <53602729.474be00a.2f3d.66aaSMTPIN_ADDED_BROKEN@mx.google.com> Date: Wed, 30 Apr 2014 09:58:59 -0500 Message-ID: From: Mary Barnes To: "rai@ietf.org" , DISPATCH , SIPCORE , "ecrit@ietf.org Org" Content-Type: multipart/mixed; boundary=f46d04374abfd8f46904f843c9f2 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/6Qs9oNV4M08fKg_76xhGcDlw90M Subject: [dispatch] Fwd: [SIPForum-techwg] Call for Comments on SIPconnect 2.0 Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 14:59:09 -0000 --f46d04374abfd8f46904f843c9f2 Content-Type: multipart/alternative; boundary=f46d04374abfd8f46504f843c9f0 --f46d04374abfd8f46504f843c9f0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I'm forwarding this as I think this new activity might be of interest to the community. In particular, since the focus is adding recommendations for the following to the SIP Connect specification (available at SIPconnect Technical Recommendation Documents and Presentations ): =E2=80=A2 Update the security model based on existing standards to authenti= cate and authorize utilization of the service provider=E2=80=99s resources by an IP = PBX. The security model should also define methods for ensuring the confidentiality and authenticity of messages exchanged between the service provider and IP PBX. =E2=80=A2 Specify the consensus method for supporting IPV6 and IPV4/6 Dual = Stack components within the reference architecture. =E2=80=A2 Specify the consensus method for supporting secure media (SRTP). =E2=80=A2 Specify the consensus method for supporting Video enabled devices= . =E2=80=A2 Specify the consensus method for supporting emergency calling (NG911/NG112) and the transport of location information. Please do not reply to this email but rather provide comments on the SIP Forum Tech WG mailing list. The SIP Forum is a totally open organization (i.e., you don't have to be a Full Member to participate in discussions - just to vote), so joining the mailing list to provide feedback is straightforward: http://www.sipforum.org/content/view/28/139/ Regards, Mary ---------- Forwarded message ---------- From: Marc Robins Date: Tue, Apr 29, 2014 at 5:24 PM Subject: [SIPForum-techwg] Call for Comments on SIPconnect 2.0 Charter To: techwg@sipforum.org Dear SIP Forum TechWG Members, The SIP Forum has officially begun the process of restarting the work of the TechWG, focusing on the next version of SIPconnect -- SIPconnect 2.0. A draft SIPconnect 2.0 Task Group Charter is attached to this message, and a formal call for comments is now being made. Please review this charter, and respond with any comments by the deadline of May 15, 2014. In addition, please contact me directly if you wish to contribute to the work as an active participant. All best, Marc ************************* Marc Robins President and Managing Director SIPNOC 2014 Program Chair SIP Forum http://www.sipforum.org Mobile: 203-829-6307 SkypeMe! marcrobins ************************* SIPNOC 2014 Registration is Open! SIPit 31 Registration is Open! _______________________________________________ techwg mailing list Send mail to: techwg@sipforum.org Unsubscribe or edit options at: http://sipforum.org/mailman/listinfo/techw= g --f46d04374abfd8f46504f843c9f0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I'm forwarding this as I think this new activity might= be of interest to the community. =C2=A0In particular, since the focus is a= dding recommendations for the following to the SIP Connect specification (a= vailable at=C2=A0SIPconnect Technica= l Recommendation Documents and Presentations):

=E2=80=A2 Update the security model based on existing standards to authenticate an= d authorize utilization of the service provider=E2=80=99s resources by an I= P PBX. The security model should also define methods for ensuring the confi= dentiality and authenticity of messages exchanged between the service provi= der and IP PBX.
=E2=80=A2 Specify the cons= ensus method for supporting IPV6 and IPV4/6 Dual Stack components within th= e reference architecture.
=E2=80=A2 Specify the consensus method for supporting secure media (SR= TP).
=E2=80=A2 Specify the cons= ensus method for supporting Video enabled devices.
=E2=80=A2 Specify the consensus method for su= pporting emergency calling (NG911/NG112) and the transport of location info= rmation.

Please do not reply to this email but rather provide co= mments on the SIP Forum Tech WG mailing list.=C2=A0The SIP Forum is a total= ly open organization (i.e., you don't have to be a Full Member to parti= cipate in discussions - just to vote), so joining the mailing list to provi= de feedback is straightforward:
=

Regards,
Mary



---------- Forwarded message ----------<= br>From: Marc Robins &l= t;marc.robins= @sipforum.org>
Date: Tue, Apr 29, 2014 at 5:24 PM
Subject: [SIPForum-techwg] Call for C= omments on SIPconnect 2.0 Charter
To: techwg@sipforum.org


Dear SIP Forum TechWG Members,

=C2=A0

The = SIP Forum has officially begun the process of restarting the work of the Te= chWG, focusing on the next version of SIPconnect -- SIPconnect 2.0.<= u>

=C2=A0

A dra= ft SIPconnect 2.0 Task Group Charter is attached to this message, and a for= mal call for comments is now being made.

=C2=A0

Please review this charter, and respond with any com= ments by the deadline of May 15, 2014.

=C2=A0

In addition, please cont= act me directly if you wish to contribute to the work as an active particip= ant.

=C2=A0

All b= est,

=C2=A0

Marc

=C2=A0=

*************************

Marc Robi= ns

President and Managing Director<= u>

SIPNOC 2014 Program Chair=

SIP Forum

http://www.sipforum.org

Mobile: 203-829-6307

SkypeMe! marcrobins

=C2=A0

********************= *****

=C2=A0

SIPNOC 2014 Registration is Open!

=C2=A0

SIPit 31 Registration is Open!

=C2=A0


____________= ___________________________________
techwg mailing list
Send mail to: tech= wg@sipforum.org
Unsubscribe or edit options at: =C2=A0http://sipforum.org/mailman/listinfo/t= echwg


--f46d04374abfd8f46504f843c9f0-- --f46d04374abfd8f46904f843c9f2 Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document; name="SIPconnect_2_0_Charter_Draft.docx" Content-Disposition: attachment; filename="SIPconnect_2_0_Charter_Draft.docx" Content-Transfer-Encoding: base64 X-Attachment-Id: 46429a0d304b128d_0.1 UEsDBBQABgAIAAAAIQAwySgMcgEAAKUFAAATAAgCW0NvbnRlbnRfVHlwZXNdLnhtbCCiBAIooAAC AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC0 VMluwjAQvVfqP0S+Vomhh6qqCBy6HFuk0g8w9gSsepPHbH/fSaBR1UKQClwiJeO3+OXZg9HammwJ EbV3JesXPZaBk15pNyvZx+Qlv2cZJuGUMN5ByTaAbDS8vhpMNgEwI7TDks1TCg+co5yDFVj4AI4m lY9WJHqNMx6E/BQz4Le93h2X3iVwKU81BxsOnqASC5Oy5zV93jqJYJBlj9uFtVbJRAhGS5HIKV86 9Usl3ykUhGzW4FwHvCEbjO9VqCeHBXa4N4omagXZWMT0KizZ4CsfFVdeLiztoeim2ePTV5WW0OJr thC9BETK3JqinVih3bf/gz7cwk4hEvL8RlrqoyYwbQzg+R1sebvkKaxx9AE5leNkfajrp0Dl9D8C xKSh7c/B/BFSovQvsfkdc9f2myomOnTAm2f/5AwamqOSFZ3LiZgaOFnvT/1b6qMmVjB9v1j6P8i7 jLT9kz7+I4zvO6tG72kdby7Z4RcAAAD//wMAUEsDBBQABgAIAAAAIQAekRq38wAAAE4CAAALAAgC X3JlbHMvLnJlbHMgogQCKKAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAjJLbSgNBDIbvBd9hyH032woi0tneSKF3IusDhJnsAXcOzKTavr2j ILpQ217m9OfLT9abg5vUO6c8Bq9hWdWg2JtgR99reG23iwdQWchbmoJnDUfOsGlub9YvPJGUoTyM Maui4rOGQSQ+ImYzsKNchci+VLqQHEkJU4+RzBv1jKu6vsf0VwOamabaWQ1pZ+9AtcdYNl/WDl03 Gn4KZu/Yy4kVyAdhb9kuYipsScZyjWop9SwabDDPJZ2RYqwKNuBpotX1RP9fi46FLAmhCYnP83x1 nANaXg902aJ5x687HyFZLBZ9e/tDg7MvaD4BAAD//wMAUEsDBBQABgAIAAAAIQDaqRepYAEAAJ0E AAAcAAgBd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVscyCiBAEooAABAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAKxUTU/CQBC9m/gfmj1jlyIWYyhc1ISDF8WzWbrTj9D9yO5g4d87NkJLxHrp pdl5Td97OzOv8+VeVcEnOF8anbAoHLMAdGpkqfOEva+fb+5Z4FFoKSqjIWEH8Gy5uL6av0IlkD7y RWl9QCzaJ6xAtA+c+7QAJXxoLGh6kxmnBFLpcm5FuhU58Ml4HHPX5WCLM85gJRPmVvKWBeuDJeX/ uU2WlSk8mnSnQOMFCe4BkW7miVO4HDBhRyQkn4xftjAb0gJSa6DVb0rePKM+D5MhPXg8VDTHtglN 3ScfDSmvd2oDjubQOjhBfSbiIU1kRuNabKrOLE5Qn4m7IU0UtNmuKvW27cTPmtd1HfrSUnR2qglO apSlBNJeG/uduxEBH9KkSmiOwm9HdKa61pURkuelHE1nMV8hKDpO4ogfJV6MpDQ97RGcFn/u/HTI a9awefuVvA547Dc/+6ksvgAAAP//AwBQSwMEFAAGAAgAAAAhAFXBZKd9DwAAqmQAABEAAAB3b3Jk L2RvY3VtZW50LnhtbOxc3W4bNxa+X2DfgdDeOIAsS6pjp9paRRMnXQP7Yzhuu3cFNUNpZj0znJIc yepVX2OBXaDP0kfpk+x3SM5oRpZkJ1WyUiMDiaT54c/h4eF3vnPIL768TxM2FUrHMrto9TrdFhNZ IMM4m1y0vrl9c/yixbThWcgTmYmL1lzo1pfDP/7hi9kglEGRiswwFJHpwRR3I2PywcmJDiKRct2R uchwcyxVyg1+qslJytVdkR8HMs25iUdxEpv5Sb/bPWv5YuRFq1DZwBdxnMaBklqODb0ykONxHAj/ Ub6hnlKve/PSN9nWeKJEgjbITEdxrsvS0vctDV2MykKmmzoxTZPyuVn+lNpCxWcYjzRxzZ5JFeZK BkJrXL10N6sSe91NdXsBUhHVG09pQrPOsiUpj7OqGNKOpfGvBq+DwTtxdZ9QUYuOQBZD6NJIhnP6 zNlsAF0Mby5a3W7/8+dn569a5aVLMeZFYmp37BvXij6U+0h4NsHzU55ctER2/PXL1snwixN/G585 PUafDyrrXZ6fnvZWVebvfJzKXnS7vUtMBieGa+rsw/p1zgMMPR7iYyOg/5i1s0ES0xD0T6sfN0WC C7wwkqQwG8jC0DN/nSaliHruhheeeiMzo3FPcG2+0jG/aN3GqdDs72LGbmTKMdizQaAfXrbFj9z/ r7T9DGQiVVVP7+z8xQtXmf6xvNo/La+8olrtoLlryyMGaeABqxjX1N2uF1Nt5Hev8bOBNY0DGi2M Q66EFmoqWsO3V9eBzDIRGNbvdBnpo3FaavtT9rQ29uWlver88JbrO/a1kkXOXkVcQVMbXV05DZv6 f9PocCmFmiFoPn6YLk83cI9JtmkPP65kG7ajb/9KSwEdqNmJ2UD/uAXbsZX6aBLfRoLVZvetCKIs DnjCbgRWQICl0AIOFmvGMxanuVTAVobFWVhoo+b4EpsYz0wFMxE3bFTESaiZzJi4j7Uho3/1+vaN h2QKt4xkoRjDrDPOUmEiGTLgLRSE6eatDCAOGwkzEyJjV9fs+uU/qfqQfSvxi2wSMBUDopjGoVAs w5NS3em2fUbnIojHMRYBzpQYCwV0iKpUEMUGBqxQoo3rPxSxEiGVYSSE6YofC073fUHobCIILjoJ KKxNGnURiuHoOLVZC57iqqZG5kIo6u2T2607jxuXpk4/alyaj+/xFFhpaZu9e1QY56dn593nBABo Gd5jYcwG0TwXCkjojqlBHF601FVoOxZhhkk1hxtkMWkFOd5hIf7oluRb57qxXqe3rP9VN98XVbwL UlsLdn75eRsAZ2tyjbiGTYEhtE5pksyZgkGCgQvZaA6ba+03eyNVkbIjPCvH7G9k7VivzfrdXu/Z wczAtVqN0rdhZppW6almptevnJ6NHtB2HJ2tKCMJy7uuJa5tQLLtuTZbaS6hm6uM8TAEQAGeaM4U mlWhmIoEjE8IpFDDQIFQNL8Ct+wT7LDQBA8q7ugfgg0TxdMnzKzXl+eXr/vlIvTomnVQpq37yVtT pu+iONGmpimN5avm8Nfc/T2ZKMRkPvT61y6DOz7tV/cGeIO8mBH5NZaKgu+AxbRC+TADs9hEsbMU lX/TNBubhnzTVN8927haSArSmWTxj/B0rDeH3itynuw/mExIZxbFABckFu9peUPpfSrNxoWi1xj5 ZOTs3QmRMzAq5PdxI6yU4UfNSi+MXCznfxn4aqHuNPVuG2v0+5EuhzV6A3e6NbN66xmI38/UGjqq dF2H9tJ6Nufk0mK3X5ZvSBR2jenFomDNHPwrwQJH+2IxWNBUuKvFGosF5S05JKaLnOix9mJNqTFH jpwqGabS9tlqxkUyjpPE2lRvRWs2USK8yUeJqFDoOr0i2PFZ97x3/nI13Ny9NWhYAeqSNAMMP3bd DcGpHW/q6p4pHXGYm7qzZyPXZuzty1e//vTvjZ3arzFaDYksqVzXy5Uk9IdALQdncHedwV9+/uXn xnTeBkz9kIz1doikdyFYPx5f9C6tAokVBwheTwfwdRDHApv+/X0Xf9/HvW4frLo2c0pCmMWhiQbd P0cinkRm0Ouc5qbF5CBS2uAd/z2TOuIhHve/7RdazC08vmj9qd8H+YNAmbwTeGtMQUGSi20CvqzL 7Wg6LDeH+PEj6RbbmH3vZ26fRuMeElk+ahYOcb+v7xEINgDy/yhMXpgmTvn/6cuBVPgIpMJqJHeL cCkzlOIzsSk+M3K64L2FBRIEGov5fvu3fF1f9pN5APb24c11/do/wn0po25Tx34XPhTxyotsonXd 3U/9tES5y2ha1zFS0P0ax2FzvawZxP0cJM5IAREG1sJQikQV9qlRdC4Nrcz6QpoKYh2Uq6aRKkZ0 oA0Dj5EaS6lwLi3NBTNs+LjirZbz0zqMKO7mDDjSz/Aqlh8XQ5n7qIrbt0BJcimy6xCrKjlFEbZp paJ8N3wiwQ2E5KSIQ065bT5khSgNIjQzG7EBZVnLuEsER3peilT0GCltTOZ2D0HbFu5S3BC0yQK6 yml7A5vw3MZ6qhS+kuMsU+NCxGzi8RyB8xHXgnK0S8FWDKedFjqSRYJEFRCrTvwQ40J4+LEsrIWQ O+xtgUAT9dJWgK6RwDJprASSAqKgbi6NJMa2DPkji5HWjmbXKJ6fqzhFUsC0jHKF0haL5MNxAs/M DSqV7Ru9VIXLBERF9MiDcX1CUsC2vbs9xpQrgfhBPrSQrN/5cZDPZvk8P++dPn9dRUFq7EnzzieQ rLVyfjWZjkNSEoRk6dFy0u0N2kmw7ekGORNI0giv+US8BAS4s5uZ1mzkQZooywuVS421z65gTZe4 iWQ8xsEjDt4iUY6y6rF8TpHI0XaI4rjAGm5XyoJ2DlhowfRcG5FigcSOAB8WpTcDIBGVzI/L4pbB Ay3XCwxEGzixZQxJOUxiqVXsyCEXnjxDG3zi/lK2SG3o9i8euo62ANBZYi0MvwMKDQJZYC9GiUQk sJ0PyhEwg8wsQgFUEwpjBsiIkCrikAzp8IRhEXwmmLi8nYLurpfqjsP/4VcGfY/A2bOE0jvbto8L 5A7IubLThcHGXkp7so7CKM6cXwDRWp2MJ4SMoY0ktVSEMWdG8UxTvJ8VtKuV3dxeb3L/ep+fvegu tobuuhhP3m7oz443fvU0cm5YQxNgOa318qaQ5gftNWIBXBS4LDTysJc8m3v7UxodPJDblAyoh4C9 GiUxdmSTdrCppK1JsK60PZ0daXJhYDQ3acaeRf6/E6Ob21frOrTjqjFss790Put/1mYhnPrAIAHU bzmjLHDMcTlhv/70n1HCgzuWRzhA4Nef/ttmwgSdZ4wSgAWOHshC2q5W8gTOUAQRDbxmU9oadhR3 YEHJzpA2pXzuHWBrhEOy15UvTtaXmAayK6RvKDyXUFL9zFmupvUR98hPyiY+VRXq9sB4l7wBrFMg rI6Sxw2Ln03Q9nLFgIWH/27mbc87+CZSeTnH9hJ41f4JNlYyhYWjNvp1Bn3qMGTWI1dWw/0lBgM5 T2VvCU9I6u80FjM0FBKl/YQQtMUOviHULYsbAFqwgiH1yhbQhCY+5ckyLo1cU5rKBEokBF7nA9os kjNYfeWaY2epPa/BVuDNtm3cQpCVHpQpSCuXBxoe9BtHOmSI5SYJOlYfLGAcN89x0WqNG1Bfo1BI OAYZwUOeY7vWzuz722PaoAbzdt3ivJUpKDdHFpVazOToX5g1loHyt2oID0TeoGFft+LENfDHGs83 K1K3wydOFkcudN1OZty7Qoq828xsj2FAs6oXFgc8jAQlUmJLYteGxt3Pr3Ckg3+ENiuiGH8OxNnT 4udIx8c7iRibi9bpC9+i7aS0bCWRee88RzP8JrfZ+DB3DV2rzSxyoDZRBbuXULoa+WGRWrUNHCsO eacCmw+gsd5Z8oyv31LOhKPHH+77XtqCjiUPpp9We78NfJ1Md9xarRHg0evOBICGQiCBJd69m/ls XTf3T3WGT+DtN02GcqdXjWxsPn4wuXQcz8OTdvr274OelvEbT9rZygpBKUlv7dEUbtM2qK84WNBY 2LqNJa5yMMW9ERm5kIgTWjNV4npPpgF/YvO34ECd3kSVEGO1rTsod/NgqQOe2OpcXFZucc8RRr15 g5Nu4Nk58raKJdcIXq1lgMNjSn8WWAQkZTkJ/BZEq/koZRFK3p05cMDUD85b+6QNvMPUvx9QtAYO ruvgjoPb4afg62gRFIpyeFKJvBmbngPGsXYa18L8EjNYQCagAhG3cxEhuiAVIiHMRUSqMAiee8A2 0vYvYgBloYj7BCKpcnsc277UGG/CeaKrI8DcAWDWAwP3qdF00OhUFyXjOBLSpSQRPKpaS/0jFpWO 4pqg5gWd9yiL59y0p+ChhnF/PEjeePwA9g9gvwb2ocyatBt5fYsD7zyMIYW/uv72zIYA8OX05Ixd FpS7ZigIAUIiRxjCHnO6OJ7i/VF+Q03fS6tdCUT++OOAKhLwwBrS8Y4lR7pLh8V+EBf2Ma221h95 pzZcfkQB5SedRfbbNdQdjHzQUHhN5eGjnybJUtPQ/wEAAP//1FTBjtowEP0VK6f20CVJAwtoQdqC inooQlD1bpxJsOTYke2Q0q/vjJOwS9netxyC53nseeOZeeBPJmeFscw1dW2sl7pkP2UOhoHmRwU5 y+EsBbiHp1E790v62vCtl0/tvGZoOpnvF1EcJ7PJNF5FA7SzBE4RX0+u4BoK3ih/774L0Poxy5Io 3LzDMO1cN1W3kOqs8OYzV+gYjfq9b/mAJYQhuesBV3NB2bTzI2CCsIiSOCYenfnceNO74A7hvPCA lCfBSUmNJ9LsauwbhQDHU11wqSm0ggJzyaY9I9txtV+N9g63gTv/7CRfRD9kBY5toWV7U3FN8YS7 h0NewigsSJ9rGn5dTPf7imYDsqI44VXSgFF9iAX+1z0bdAg1uikIPeA7oou9xX5Vak4lwXeuLTiw Z4iWhxqELC7Mn4AJox1o1zhWvdm4UIEtQYsLE1xhBUt207SY8PAU1Gyr1SQeT6kS/+/rfNhuZkky 2m6SJP34z2zfeeGXHGeJ6ust145UiJmCKSO4l0YzqXF8q7B+uKkntXiQiqGEryRkgLrUk05XBvC1 CN0pTj8UigftCJMF+tPmS68vN8M1MHAg/O6muf6K+BaNAx4ixulsPHlcdaJXHmjEW1SktNeeE67H U9ShIA11+Z1THG9qxLNOnqwsT3jTYB6N96Z6sTuNGnZPwHOSucc4tH5hTFC93iwbH8w+HCoRyUs/ lOQTWORGbKwM+ocyuZNeIMvPKJydBHevESToaPJLWOCRpgLtl38AAAD//wMAUEsDBBQABgAIAAAA IQCWta3ilgYAAFAbAAAVAAAAd29yZC90aGVtZS90aGVtZTEueG1s7FlPb9s2FL8P2HcgdG9jJ3Ya B3WK2LGbLU0bxG6HHmmJlthQokDSSX0b2uOAAcO6YYcV2G2HYVuBFtil+zTZOmwd0K+wR1KSxVhe kjbYiq0+JBL54/v/Hh+pq9fuxwwdEiEpT9pe/XLNQyTxeUCTsO3dHvYvrXlIKpwEmPGEtL0pkd61 jfffu4rXVURigmB9Itdx24uUSteXlqQPw1he5ilJYG7MRYwVvIpwKRD4COjGbGm5VltdijFNPJTg GMjeGo+pT9BQk/Q2cuI9Bq+JknrAZ2KgSRNnhcEGB3WNkFPZZQIdYtb2gE/Aj4bkvvIQw1LBRNur mZ+3tHF1Ca9ni5hasLa0rm9+2bpsQXCwbHiKcFQwrfcbrStbBX0DYGoe1+v1ur16Qc8AsO+DplaW Ms1Gf63eyWmWQPZxnna31qw1XHyJ/sqczK1Op9NsZbJYogZkHxtz+LXaamNz2cEbkMU35/CNzma3 u+rgDcjiV+fw/Sut1YaLN6CI0eRgDq0d2u9n1AvImLPtSvgawNdqGXyGgmgookuzGPNELYq1GN/j og8ADWRY0QSpaUrG2Ico7uJ4JCjWDPA6waUZO+TLuSHNC0lf0FS1vQ9TDBkxo/fq+fevnj9Fxw+e HT/46fjhw+MHP1pCzqptnITlVS+//ezPxx+jP55+8/LRF9V4Wcb/+sMnv/z8eTUQ0mcmzosvn/z2 7MmLrz79/btHFfBNgUdl+JDGRKKb5Ajt8xgUM1ZxJScjcb4VwwjT8orNJJQ4wZpLBf2eihz0zSlm mXccOTrEteAdAeWjCnh9cs8ReBCJiaIVnHei2AHucs46XFRaYUfzKpl5OEnCauZiUsbtY3xYxbuL E8e/vUkKdTMPS0fxbkQcMfcYThQOSUIU0nP8gJAK7e5S6th1l/qCSz5W6C5FHUwrTTKkIyeaZou2 aQx+mVbpDP52bLN7B3U4q9J6ixy6SMgKzCqEHxLmmPE6nigcV5Ec4piVDX4Dq6hKyMFU+GVcTyrw dEgYR72ASFm15pYAfUtO38FQsSrdvsumsYsUih5U0byBOS8jt/hBN8JxWoUd0CQqYz+QBxCiGO1x VQXf5W6G6HfwA04WuvsOJY67T68Gt2noiDQLED0zEdqXUKqdChzT5O/KMaNQj20MXFw5hgL44uvH FZH1thbiTdiTqjJh+0T5XYQ7WXS7XAT07a+5W3iS7BEI8/mN513JfVdyvf98yV2Uz2cttLPaCmVX 9w22KTYtcrywQx5TxgZqysgNaZpkCftE0IdBvc6cDklxYkojeMzquoMLBTZrkODqI6qiQYRTaLDr niYSyox0KFHKJRzszHAlbY2HJl3ZY2FTHxhsPZBY7fLADq/o4fxcUJAxu01oDp85oxVN4KzMVq5k REHt12FW10KdmVvdiGZKncOtUBl8OK8aDBbWhAYEQdsCVl6F87lmDQcTzEig7W733twtxgsX6SIZ 4YBkPtJ6z/uobpyUx4q5CYDYqfCRPuSdYrUSt5Ym+wbczuKkMrvGAna5997ES3kEz7yk8/ZEOrKk nJwsQUdtr9VcbnrIx2nbG8OZFh7jFLwudc+HWQgXQ74SNuxPTWaT5TNvtnLF3CSowzWFtfucwk4d SIVUW1hGNjTMVBYCLNGcrPzLTTDrRSlgI/01pFhZg2D416QAO7quJeMx8VXZ2aURbTv7mpVSPlFE DKLgCI3YROxjcL8OVdAnoBKuJkxF0C9wj6atbabc4pwlXfn2yuDsOGZphLNyq1M0z2QLN3lcyGDe SuKBbpWyG+XOr4pJ+QtSpRzG/zNV9H4CNwUrgfaAD9e4AiOdr22PCxVxqEJpRP2+gMbB1A6IFriL hWkIKrhMNv8FOdT/bc5ZGiat4cCn9mmIBIX9SEWCkD0oSyb6TiFWz/YuS5JlhExElcSVqRV7RA4J G+oauKr3dg9FEOqmmmRlwOBOxp/7nmXQKNRNTjnfnBpS7L02B/7pzscmMyjl1mHT0OT2L0Ss2FXt erM833vLiuiJWZvVyLMCmJW2glaW9q8pwjm3Wlux5jRebubCgRfnNYbBoiFK4b4H6T+w/1HhM/tl Qm+oQ74PtRXBhwZNDMIGovqSbTyQLpB2cASNkx20waRJWdNmrZO2Wr5ZX3CnW/A9YWwt2Vn8fU5j F82Zy87JxYs0dmZhx9Z2bKGpwbMnUxSGxvlBxjjGfNIqf3Xio3vg6C24358wJU0wwTclgaH1HJg8 gOS3HM3Sjb8AAAD//wMAUEsDBBQABgAIAAAAIQAQESW/NQMAAH0HAAARAAAAd29yZC9zZXR0aW5n cy54bWycVWGPozYQ/V7p/gPi82UDLIQEHXvShs1dq932VO5+gIGBWGtjy3bCpr++Y8CX3ZaeTv0U +715j/F4PPnw8YUz7wxKU9HnfngT+B70tWho3+X+t6+H1db3tCF9Q5joIfcvoP2Pd+9++TBkGozB MO2hRa8zkfsn1We6PgInesVprYQWrVnVgmeibWkN848/K1TuH42R2Xo9i26EhB7dWqE4MfpGqG49 KQtRnzj0Zh0FwWatgBGDCesjldq58f/rhp86OpPzjw5x5szFDWHwo8j5uINQzXfFz6RnBVKJGrTG ynI2HZcT2jsbzX7GZ6rnI60UUZdXJnd4bX8Jwb0hOxN0qkCbAzU+7iWoGguc+1G489c2sBG/C1NQ LRm5fCEd3IsTtoGioEca8xRtaYgBVGsJjI09UzMgmO2QdYpwTvCOJ2SyhJacmPlKqtII6bJIo2D6 Yn0kitQGVClJjW570RslmIsbE9oLLhXWZ1bgjpjRG1u40TZvu/hTCONkQRAWaRyHk8Kyr5jdZhvs F5n/1ES7ZJMuam6DNEzvl9ySNIyThyUmjTdpkCwxW5v4ZonZbcM0XNTsivQh3i5p9vtNkCwyD0Va PERLmkNxW+wWz3M4JPsotZr1VHCsPM/sS/qi3OqAt+fxqdH2hFeKEu/JvjVU8axSz/e0d3wF+Obh NVOeKkeuVhOhOWHsgB3iCHxmE9NglxbQjsbsiaju6jy2Fs/UItpA+9t3N9v+oD4pcZKT66CI/LVv EHYfDON49qO9eaTc4fpUlU7V45N7ReGb+eOsrOH6WqAhMzglwVbokfSd60foV99KGzpkNVOlnaTw RKTEp4AhVRfmPqPd0YT2fRnc4XN8HjdVF81cNHK4s9y4IbU9GUbPCxswLTFqXlyxW4fdXrHYYfEV SxyWXLGNwzYWO15wpuBQeMaJ5ZYWbwVjYoDmswNz/1/QVAR9JBLwXu3MwAYT2QjgpY2Ad87gBQcW NHaCaUkbTl5yPwmjsZnnaBxe4mTexFonGyzfoF5DDMG/wPGq3ojHJv9HLjgeoabYkOWFV9cRdTMl zqg2JUicZkYoPPI4bN+Pztf/zbu/AQAA//8DAFBLAwQUAAYACAAAACEABeE5FTkBAACkAgAAFAAA AHdvcmQvd2ViU2V0dGluZ3MueG1slFLLbsMgELxX6j9Y3BvcRHJbK3akKMqppzb9AALrGAlYBMRu 8vXd2H2kj0NzYtmdGWZ3mS9erck6CFGjq9jtJGcZOIlKu13FXjbrm3uWxSScEgYdVOwAkS3q66t5 X/awfYaUCBkzUnGxDBVrU/Il51G2YEWcoAdHtQaDFYmuYcexabSEFcq9BZf4NM8LHsCIRA5iq31k 72r9f9R6DMoHlBAjGbFm1LNCO1aTR6W7+H5mfalVxWbTu2L2MCuKob5FdVjpjmqdMNQ/4ye0FeER mvSRzT+zT3rX/pHeoP+NXWJKaH/kyc9ShdMb6YvjaLKMgPFYMZo/BV5ImvUQSzRIcxX7hKMNc+bs Mub2m6PLuOG880uofFjC0PQY1vPxHPaCPmmrj7DGsAzYRwi0AKqf/a36DQAA//8DAFBLAwQUAAYA CAAAACEAIRjiroAIAACIQQAADwAAAHdvcmQvc3R5bGVzLnhtbNxc31PbOBB+v5n7Hzx+unugkIQm B9O0Q+lxMEMpJTB9VmyFeHCsnOXwo3/9rVa249hxvIvNdOb6QLAs7ber3f1WgLYfPj0vQudRxjpQ 0djtvTtwHRl5yg+i+7F7d3u295fr6EREvghVJMfui9Tup4+///bh6VgnL6HUDgiI9HE8dudJsjze 39feXC6EfqeWMoJ3MxUvRAKP8f2+ms0CT35R3moho2S/f3Aw3I9lKBIA1/Ngqd1U2hNF2pOK/WWs PKk1aLsIrbyFCCL3I6jnK++LnIlVmGjzGF/H6WP6hB9nKkq083QstBcEt6A4mLgIIhWfn0Q6cOGN FDo50YHY+nJuZm194+mkIO1z4AfuvkHUP0HmowjHbr+fjZwaDTbGQhHdZ2My2rubFDUZu/nQFOSO XRHvTU6MsH00M/ssmLvcMB6eUJWl8GDjAEfMEgkOBH8YnDAwju6PhtnDzSqEAbFKVAqCAgCsKBYe SzsOfgUvT2yUwFs5u1Teg/QnCbwYu4gFg3cX13Gg4iB5GbtHRwYTBidyEZwHvi9NUKZjd9E88OWP uYzutPTX49/PMMRSiZ5aRQmoPxxhFITa//vZk0sTYiA6EsbDV2ZBaMTqAg4qtArW2tiBEioO/ptB 9qwPt6LMpTBp5KD+O4HQ6lVroL6xqGgAymXpOmgv4rC9iPftRWDwttuLUXstgDzbesTGRiEq6U5N lGeDr7gPg6MdIWtWVKKocUUlaBpXVGKkcUUlJBpXVCKgcUXF4Y0rKv5tXFFx584VnkDiKkfRAHeD lNi3QRJKs34nAfVaUl1aapxrEYv7WCznjimsZbV3keVkNU1oqiKdvp4sJ0msovvGHYHqbFL31Zz8 92I5FzqAE03D1vdbbv2tmIbS+ScO/Eao9zb4KjbhwWRrCbsOhSfnKvRl7NzKZ+tRxvor5UzsKaNR uZZuvQzu54kzmWPJbQQb1mx6/U5Y+ZeBxj3YmUzDGlOahJN8OKyJy3rhX6UfrBbZ1hBOI0PL5ww3 lyBQxd1bdGhcVM2uRiuMAygm2HLBNwHlE/S3xYUv3/iYor8tRa+UT9DfFq5Xysf42O1fNtN8EfGD Q0qvETt3T1Wo4tkqzHKgkR5G7AzOIWgmsJM4l08iiRE7gzfo0znxPPjJjRKnbF+seZSBwnaHRcFk o9vCdkqJ9noMi9gOKmH1GVjtuJYBxCbdG/kYmF88cYsBsnR+1mxM50HNDkAJIp2hv69U0nyG7tdw HhXlIoJfl2jp0NAGNZlHRUvjydY7ho/bFT4GULsKyABqVwoZQDXxUX/myWsiHaR9cWRgsWk5r2IY dmRmHrGZOQfilYCO6ibh/FWTvfWxUK2bBBS2g6p1k4DC9k6pluV1k4DVWd0kYNVUjXofFTmVYxS7 bhaB8pMAwaJuyJsA1A15E4C6IW8CUHvybgbpjrwJWGxuyDm1SN4EIJzC+VE/ByqSNwGIzQ2W7dLf GWV1D6Xs/uG2A/ImoLAdVCVvAgrbO3XkTcDCKZxIKGHlVEfA6oa8CUDdkDcBqBvyJgB1Q94EoG7I mwDUnrybQbojbwIWmxtyTi2SNwGITQ85UJG8CUA4hcMNW8kbs/7NyZuAwnZQlbwJKGzvlAg1P6QS sNgOKmHl5E3AwimcYEixMLg5RnVD3gSLuiFvAlA35E0A6oa8CUDtybsZpDvyJmCxuSHn1CJ5E4DY 9JADFcmbAMTmhq3kjcn45uRNQGE7qEreBBS2d0qEmvMcAYvtoBJWTt4ELIyX1uRNAMIprwXiWNQN eRMs6oa8CUDdkDcBqD15N4N0R94ELDY35JxaJG8CEJsecqAieROA2NywlbwxR96cvAkobAdVyZuA wvZOiVBz8iZgsR1UwsqpjoDVDXkTgDAwW5M3AQinvAIIs4jjpm7Im2BRN+RNAGpP3s0g3ZE3AYvN DTmnFsmbAMSmhxyoSN4EIDY3mHu2cF+UfD21VxME1HsG2a0GMmC/xklUwNTAGzmTMXQyyebbIS0B MwsZiDXhQTXxs1IPDu1i96AmQMhQwTQMFF7pfsFbOoVGhMFoRyfB7bdT59w2wFTWYUht3ryB7qFi uxC2J5nGIdAzeVlCy84yu1lupEGDkOnrSluAsA/tAhqC0rYes9j0+cBEbKpKh/Hvtikqfg89b342 5+Cgf/R+ODpNG5xQZIMSOWxqZh/7jYrAWQNQ2ug1FdC29M10IVXUgparh2w8E3c6F7Hd4HX7RjYn 7eGot6b3ZXR4mN63r7R7TSU05cGe9my/l308gfYube9qp/uadoWls/CpOiltFjvEv4mZh81msadj tUrM8OVjmCmPatnuMbPF0JiHHxuteGP3NlhAc+GVfHJu1ELgFbGsFW/rS2zF2/rG09VhDICp/Xqq 8XPdmTcY2n3XP9edeXYMtEZ14bMmRDzwmvCgnW5HnKbdEvkFNuyVKEdtTUsFqloNiNTV6wO4nbdx wReG6vVOTBvBDp2xzWBngjk4pTZi05Bt0jC/kocGJNPQRgd8cxGZbIXOUAw1ywr+s7CA8P5UhuFX gbGUqGX91FDOEvu2d4BHqZKoqUoStahfH2OnAWqyTQBscVEZ+2iMqN/7aLWYyhhaBXfs/5UyR5AK xUCDBY7XhAX0U+Kbpl2v120jnr2Vhq2ZGGIuc+8Ga5VjOX3p9J01qZXYcGtOoO7buLE2yuyLTWYv cuH/i2w2imJej2yW/pDTLdFi+l6dP+Ddn3anSl4olsoqyVCjCUhyo7QWHfArixFEeQr/68JgXWX6 h2luFqqMHQM9OVVmR1aK5TKUe56KoMM/kf6eKfCyEhbbZ2HyleKjPkvrPE5kljx4z+G0F5uUr2i5 fsPT7G3iOI0gz7SWQK3AE90B/Ds7S7kpGzT/NwFUVtC56tZsc/TH/wAAAP//AwBQSwMEFAAGAAgA AAAhAGd0rgpfAQAAhgIAABEACAFkb2NQcm9wcy9jb3JlLnhtbCCiBAEooAABAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAISSX0/DIBTF3038Dg3vHS2bi5KWxT9ZfHCJ0RqNbwh3W2OBBtjqvr20 3eoWTXyk59wf51yazb5UFW3ButLoHKWjBEWghZGlXuXopZjHlyhynmvJK6MhRztwaMbOzzJRU2Es PFpTg/UluCiQtKOiztHa+5pi7MQaFHej4NBBXBqruA9Hu8I1F598BZgkyRQr8Fxyz3ELjOuBiPZI KQZkvbFVB5ACQwUKtHc4HaX4x+vBKvfnQKccOVXpd3XotI97zJaiFwf3lysHY9M0o2bcxQj5U/y2 eHjuqsalbnclALFMCioscG8su9bSQhPdb7w3OsNHSrvFiju/CAtfliBvdixacCuiJ/MRWBn+rbcj FrZl+2DsonMMx3Bp17G/GWQUUtO+40F5Hd/eFXPESJJO4oTEJCnSKZ0QmiTvbbST+bZF/0HtA/5L nMTkqiCEkvEp8QBgXeLTP4d9AwAA//8DAFBLAwQUAAYACAAAACEA78WDmjoDAADGGwAAEgAAAHdv cmQvbnVtYmVyaW5nLnhtbOxZ3W7aMBS+n7R3QL5v8wMFippWrGmlTlM1aZ12HYIp1mI7sh0ou+zL 7BH2WH2FHds4DWiKaMlFJuWG4PNrfzmJ/Z1cXD3RrLfCQhLOIhSc+qiHWcrnhD1G6PvD7ckY9aRK 2DzJOMMR2mCJri4/frhYT1hBZ1iAYQ9iMDlZgXqpVD7xPJkuMU3kKc8xA+WCC5ooGIpHjybiZ5Gf pJzmiSIzkhG18ULfH6JtGB6hQrDJNsQJJangki+UdpnwxYKkeHtxHuKQvNYz5mlBMVMmoydwBnPg TC5JLl00+t5osMSlC7KqW8SKZs5unR+SbS6SNeBMMzvtNRfzXPAUSwnS2CrLiIFfl3sLoA5Rehwy hd2cbiY0IawMo8tj7/6XN+8Ubp5nc3s61OtCAItLKKZkJpVIUnVf0N7O6G4eId+YMEnmoFslWYTC 6+mgfx1MkaedaZEp8gWvcPawybGzMdJMS62VonnmdHEc3/ifzodWk620gsDF5YKSF8oZB9YK6v2W lsJZkWVYlf4P+KlUvTz/KeWfUxclw4utef5V6FkrWPP26mwgBYL/OZcRGoW+juK9GhKm16/jWC0M lgl7NI9qf+ist9GFTSJuOVMSLBOZEhKhbxs641B+4DoFQHcEhEHgOV4kAKddgPwFhhZwF97EhUkB WHryVegCHVbB0wUPlX4ZBOa2HQUlbwDIYDBwk3eQV5E0ao3HW6G85oUgWPTu8bqC5770WFDD5kF9 ef7dAKxhUJbcv2A16vfA+gPqWW8/8EIui3RXdiyk/dZCOh7XVWqo1e2EdNBWSOG9WAepUbcT0rO2 Qjro1+5MRt1OSOGM2fQG1cy79Myv3aKMup2QjloL6ah2ezrT6nZCCoyrnVU6HNRuT0bdFkjhhFqh FPqkWhnCJCsjzTDsUbXKMIbTOB5OR317Uno7wwjiOByf34zLkxYk7RhGxzB0X+VQsrbPJSxj25ce exzuGAbQ4I5h6K5CxzAi9NY+TccwdlpfTbQWOobROKQdw2ge0o5hVHveTTz4/zfDgO49HPLh95VR 7NAMUJpeumtIgaUmJjtu4f7XkDvd8zdu5jME8BrjZq/2+9vlXwAAAP//AwBQSwMEFAAGAAgAAAAh ABDbLFv4AQAAJwcAABIAAAB3b3JkL2ZvbnRUYWJsZS54bWzUlN9vmzAQx98n7X9Afl8xDvnRqKTq j+VxD1urPjtggiVsI58Tmv9+ZyBN23hakTZNS0RI7o7j+OT7vavrZ1VHe2FBGp2R5IKSSOjcFFJv M/L4sP6yIBE4rgteGy0ychBArlefP121y9JoBxFer2FpM1I51yzjGPJKKA4XphEac6Wxijv8abex KUuZi3uT75TQLmaUzmIrau7w3lDJBsjQrf1It9bYorEmFwA4rKr7fopLTVbDdFG71Fzh1D8OamPq Lt5wbUAkmNrzOiN0iu+EMjzmdIbnKZ2T2DfIK25BuJdC1odLrmR9OEatUVz3iUa6vDrG99xKvqlF nwK5xcQONhRvOLxIH0kQ+tsIO6uZvI3kXZ/Fq6swgn1eOuP4cf/3nIF4kEpA9E200fducl/wnghD CjM6QRIpHgy/pWEi9M8QQR1QdrOYn4i8fjakdiKCYuw4Bol0z5+s177m40TuzM5KYT2ToD4Y6mJC L5GD1wZDJmNoKFMIGxJIKZ9Fca6Of8viCY3knQ9BEtOjwE7nsC6CTuE7Z/ry/8Iod7yWGyuDIBhd d1LwkkhRHPgZBhE0CLQSYBSJGw+cfe2EjXZAq6c+QOe3gx1OBsH1/RuD0MuxBuEKQfBfkPArol8V fmWMIzF+eYZJUJr+HRLDFoXVTwAAAP//AwBQSwMEFAAGAAgAAAAhAFZEYyzpAQAA5QMAABAACAFk b2NQcm9wcy9hcHAueG1sIKIEASigAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAnFNNb9sw DL0P2H8wfG+UrzVFoKgYUgw9bGuAOO1Zk+lEmCwJEhs0+/Wj7MZVtp7qE/lIPz4/0vz2pTXFEULU zq7KyWhcFmCVq7Xdr8pd9e3qpiwiSltL4yysyhPE8lZ8/sQ3wXkIqCEWRGHjqjwg+iVjUR2glXFE ZUuVxoVWIqVhz1zTaAV3Tj23YJFNx+NrBi8Itob6yg+EZc+4POJHSWunkr74WJ08CRa8gtYbiSB+ JjlmVDtsORtQXjmUptItiPmE8CHjG7mHKKac9QF/cqGO4vrLnLM+5OuDDFIhWShmixm9nQH8q/dG K4nkrvihVXDRNVg8dD4UiYCzvIWTN1tQz0HjSYw5y1P+XVuSkib0EWkLch+kP0RxkwQOGd8qaWBN DohGmgicvQH8HmTa7kZqUsyPuDyCQheKqP/Qfqdl8UtGSL6tyqMMWlok/1Jbn3Sx8RGDqDQa4qZa n3dh3pbHei5IOfVScNmYwF4DFS7VdRPiQ0Pfhu+IneRiOw291ExOFg4z/mFdu9ZLexI7q5sTre81 TX7/jjtfubt0OK9GXoLZ8p80HrZeKlrRfLZY5GeQlfiWrgVq2uuZ8A3g92R6MGkqnZDdQ33u+b+Q Duux/2vFZDoa09Nd0hmjcxh+J/EXAAD//wMAUEsBAi0AFAAGAAgAAAAhADDJKAxyAQAApQUAABMA AAAAAAAAAAAAAAAAAAAAAFtDb250ZW50X1R5cGVzXS54bWxQSwECLQAUAAYACAAAACEAHpEat/MA AABOAgAACwAAAAAAAAAAAAAAAACrAwAAX3JlbHMvLnJlbHNQSwECLQAUAAYACAAAACEA2qkXqWAB AACdBAAAHAAAAAAAAAAAAAAAAADPBgAAd29yZC9fcmVscy9kb2N1bWVudC54bWwucmVsc1BLAQIt ABQABgAIAAAAIQBVwWSnfQ8AAKpkAAARAAAAAAAAAAAAAAAAAHEJAAB3b3JkL2RvY3VtZW50Lnht bFBLAQItABQABgAIAAAAIQCWta3ilgYAAFAbAAAVAAAAAAAAAAAAAAAAAB0ZAAB3b3JkL3RoZW1l L3RoZW1lMS54bWxQSwECLQAUAAYACAAAACEAEBElvzUDAAB9BwAAEQAAAAAAAAAAAAAAAADmHwAA d29yZC9zZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEABeE5FTkBAACkAgAAFAAAAAAAAAAAAAAA AABKIwAAd29yZC93ZWJTZXR0aW5ncy54bWxQSwECLQAUAAYACAAAACEAIRjiroAIAACIQQAADwAA AAAAAAAAAAAAAAC1JAAAd29yZC9zdHlsZXMueG1sUEsBAi0AFAAGAAgAAAAhAGd0rgpfAQAAhgIA ABEAAAAAAAAAAAAAAAAAYi0AAGRvY1Byb3BzL2NvcmUueG1sUEsBAi0AFAAGAAgAAAAhAO/Fg5o6 AwAAxhsAABIAAAAAAAAAAAAAAAAA+C8AAHdvcmQvbnVtYmVyaW5nLnhtbFBLAQItABQABgAIAAAA IQAQ2yxb+AEAACcHAAASAAAAAAAAAAAAAAAAAGIzAAB3b3JkL2ZvbnRUYWJsZS54bWxQSwECLQAU AAYACAAAACEAVkRjLOkBAADlAwAAEAAAAAAAAAAAAAAAAACKNQAAZG9jUHJvcHMvYXBwLnhtbFBL BQYAAAAADAAMAAEDAACpOAAAAAA= --f46d04374abfd8f46904f843c9f2-- From nobody Wed Apr 30 10:16:01 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E5A31A6FEF for ; Wed, 30 Apr 2014 10:16:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3SexbVtuxqM for ; Wed, 30 Apr 2014 10:15:58 -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 9E4651A6FFE for ; Wed, 30 Apr 2014 10:15:58 -0700 (PDT) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta10.westchester.pa.mail.comcast.net with comcast id wGdx1n0040cZkys5AHFw8t; Wed, 30 Apr 2014 17:15:56 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta10.westchester.pa.mail.comcast.net with comcast id wHFw1n00L3ZTu2S3WHFwb7; Wed, 30 Apr 2014 17:15:56 +0000 Message-ID: <53612FCC.7000705@alum.mit.edu> Date: Wed, 30 Apr 2014 13:15:56 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Christer Holmberg , "dispatch@ietf.org" References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> 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=q20140121; t=1398878156; bh=6nhy5LiaiYsnsIfSfzAiI/aDddVVkEbml7HnLkZvhS4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=R0eYVzebvge1RswfGr3SXzAeVvvoNTZp55vQz7NuoxRejarteeX5GcvnxvLRHIr3X iWEB/F85kyjuzJKMbCIatZFzu9B06zoRneW2Oow9FziHf361lr5cf23Uoa8d6FVJcG hLqpIrtO7kkzMP7x/oEgkyuU2iYMnkVU3srrpk8ac0rCVOA78CSEhAbuBaeU4Ip4qM +80aB61kURZ+3e6ZI9dv/A2ndSr2Xva4pm4eMbVO/DPa9yqNSIf2sghcuX2Tq2Dmy8 6w+sS5iO7JgIQ9iJkFsBZe+mzzByYQtXeeVRoqo9emVOE46In3zRDuBRpEdx4fYmeL ySDf553rPW7PA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/U2wsnRlUMvp4eSwbW1MxNx2hif4 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 17:16:00 -0000 On 4/29/14 8:41 AM, Christer Holmberg wrote: > Hi Paul, > > See reply inline. > >> Well, I read this draft, but I don't think I understand it. >> >> I may *partially* understand it in the context of IMS. But I don't understand it in the abstract. >> >> In particular I don't understand what you mean by "traffic leg". What I do understand is that the signaling path >> of a request can be described by a route. When the request is sent the route is described, in part, by the Route >> header and the r-uri. When the request has reached the recipient, the route is described by the Via header. But >> the Route header may be incomplete, and the Via header may be obfuscate. But certainly the request ends up >> traversing some set of sip nodes starting with the UAC and ending with the UAS, and we can view it as the actual >> route even if it was never encoded anywhere. >> >> I *guess* you are proposing that this route can be *partitioned* into segments called "traffic legs", that these legs >> have differing behaviors, and that these behaviors can be enumerated and named. Is that right? > > Correct. > > >> Further, I guess you are asserting that it is useful to know which URIs of hops along the route are part of which traffic legs. > > Correct. Useful to whom? For what? (More on this below.) >> Then, the description of the parameter says the uri with the parameter is the *end* of a traffic leg with that name. It says nothing about which node or URI *starts* each leg. > > The each value description, the text says between which 3GPP nodes the traffic leg spans. There is no need to indicate the *start* in the signaling. There is no need because it is implicit? Or because it is not needed for the uses you have in mind? > If someone wants to use the mechanism in a non-3GPP environment, he/she of course needs to provide similar text for that specific environment. > > >> Suppose I have a route from Alice to Bob consisting of: >> >> Alice -> P1 -> P2 -> P3 -> P4 -> P5 -> P6 -> Bob >> >> When I partition this into traffic legs, do the boundaries between the partitions fall on the nodes or on the hops >> between the nodes? In other words, does a node that ends one leg also originate another leg? What if a request >> was sent in the opposite direction over the same path. How would the use of iotl parameters differ on the two? >> Apparently you also are assuming that the *sender* of a request knows when a URI it is adding to the request >> denotes the end of a traffic leg. (Could it not be possible that the sender doesn't know, but the recipient does?) > > In IMS the sender always knows. > > >> Another thing: Dale already asked about the IANA considerations - whether there are defined values. ISTM that in the context you have >> in mind (IMS) there are a fixed set of values that make sense, and further, that only certain combinations of those values make sense. >> In some other application, other values and combinations of values might make sense. > > Sure, and the ABNF does allow for additional values/combinations to be defined - either in the draft itself, or in future (we obviously need to define the procedure for defining new values). Yes. You probably wouldn't want just anybody defining a new value to be used in 3gpp networks. Somebody wanting to use this for some non-3gpp purpose would presumably need to define a whole new *set* of values to use. That does have implications on how these are defined. >> Most of what I mention above seems like stuff that ought to be addressed in the draft, one way or another. > > Sure - this is only the first version :) > > >> It also seems to me that there is some conceptual overlap between this draft and what INSIPID is doing. It too is concerned >> with requests and dialogs that traverse multiple legs, and has had difficulty clearly defining what it talking about. It is concerned >> largely with situations where the legs are defined by B2BUAs. I don't know if the legs you are talking about are the same or not. > > There is no relation with the session id. > > In addition, with session id the aim is to keep the same value end-to-end, which is not the case with iotl (as there may be multiple traffic legs on the path). I didn't mean to imply that there is any *direct* connection. But the notion of partitioning paths into legs shows up in multiple cases. I'm watching to see if there is any more general work that is needed. >> If B2BUAs (especially SBCs) are involved, is it important whether the iotl parameters are preserved e2e? > > The iotl parameter only needs to be preserved until it is "consumed" at the end of the traffic leg. That seems to open up another discussion. It is a continuation of the question I had above who uses the iotl parameter values, and for what. When you say that the parameter identifies the end of a leg, and is consumed at the end of the leg, that implies to me that this serves as a request that the node identified by the URI perform some action implied by the iotl value. If that is what this is about, then it should be spelled out clearly. Thanks, Paul > Regards, > > Christer > > > > > On 4/28/14 7:44 AM, Christer Holmberg wrote: >> Hi, >> >> We've submitted a new draft, draft-holmberg-dispatch-iotl-00. >> >> The draft defines a new SIP URI parameter, which can be used to >> associate a SIP URI with the end of a so called traffic leg, which is >> a specific part of a signaling path (see more in the draft for details). >> This information is very important in scenarios where the signaling >> traverse different operator networks, where a user can be located in >> its home network or in a visited network (in case of roaming), etc. >> >> The draft is needed for 3GPP, but we've tried to write it in a way so >> that it can also be applied to other environments. >> >> http://www.ietf.org/id/draft-holmberg-dispatch-iotl-00.txt >> >> Regards, >> >> Christer >> >> >> >> _______________________________________________ >> 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 nobody Wed Apr 30 12:01:35 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB261A888D for ; Wed, 30 Apr 2014 12:01:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynBUbndl2u6t for ; Wed, 30 Apr 2014 12:01:25 -0700 (PDT) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id E92E41A096C for ; Wed, 30 Apr 2014 12:01:12 -0700 (PDT) Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta02.westchester.pa.mail.comcast.net with comcast id wD331n0020vyq2s51K1BNK; Wed, 30 Apr 2014 19:01:11 +0000 Received: from hobgoblin.ariadne.com ([24.34.72.61]) by omta05.westchester.pa.mail.comcast.net with comcast id wK1A1n00u1KKtkw3RK1Alq; Wed, 30 Apr 2014 19:01:11 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id s3UJ1AWH013149 for ; Wed, 30 Apr 2014 15:01:10 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id s3UJ1Awf013148; Wed, 30 Apr 2014 15:01:10 -0400 Date: Wed, 30 Apr 2014 15:01:10 -0400 Message-Id: <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: dispatch@ietf.org In-reply-to: <53612FCC.7000705@alum.mit.edu> (pkyzivat@alum.mit.edu) References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1398884471; bh=g8AdN4pMrEhoMegJtkVYfVETPIicgeWW7ZhG7LjFNxc=; h=Received:Received:Received:Received:Date:Message-Id:From:To: Subject; b=sssU1cALvdrbtUGXiAjvhjh2L0MHfRUAd8X5vZ/I2p97ob7IGgH6SzeSphSBGYQHw BmOcQiv1gj9bNCQ1qFcdS6M3dqO4TurHEdr8xn7O8smoPS8cxl0dqZNWTGabHH84L+ eMY7V94/B88AdqlveQwypgUyIhplDVxWLa/zG8KSkOJoykt+DP1jKWHO9qcH5YCnPK 5GnZvhBn4TTWEb4PRQweUG2xai5KxEsMhfPZKdSOO+GGflOsAUW7O2wZgz1DvXizH5 YCGzv50nyZAKp+nfIi9LF81ge0YkKEhfsoQvFdPIfCWg7oK6+ivJ/UHuF6oa/1py1T qAke5a7a9EdoA== Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/Z0qJhFjhQQRcen9Ehhlu6jZ6EcU Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 19:01:32 -0000 As far as I can tell, the draft refers to "signaling path", but it does not distinguish whether the signaling path is the routing of a single dialog, or whether it is broken into multiple dialogs by B2BUAs. I don't think this changes the proposal technologically, but it should probably be stated explicitly somewhere. It *is* a requirement of the solution. It seems that the intention is that at any point, a progressing dialog-establishing or out-of-dialog request is labeled regarding which call leg it is within by the iotl parameter of the URI currently used for routing (the topmost Route or the request URI). This is a bit incorrect categorically, because: 1. it's not a property of the destination, its a property of the dialog, or part of the dialog 2. overlooking that, it's not really a property of the URI, its a modifier of how the URI is *used* (1) suggests that there should be a separate header to label the request. But that might be even more complex to define in order to be able to have a single dialog contain several call legs. (2) suggests that the iotl data should not be a URI parameter, but rather a header parameter. The Route header has header parameters, but the request-URI doesn't; I suppose the analogous item is the To header, which does have header parameters. Those solutions aren't satisfying, either. Dale From nobody Wed Apr 30 13:34:37 2014 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E701A889B for ; Wed, 30 Apr 2014 13:34:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSx-V5gpKTWP for ; Wed, 30 Apr 2014 13:34:34 -0700 (PDT) Received: from email1.corp.yaanatech.com (webmail10.yaanatech.com [63.128.177.10]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2381A09A6 for ; Wed, 30 Apr 2014 13:34:34 -0700 (PDT) Received: from EX2K10MB1.corp.yaanatech.com ([fe80::5568:c31d:f64a:f66a]) by ex2k10hub1.corp.yaanatech.com ([::1]) with mapi id 14.03.0123.003; Wed, 30 Apr 2014 13:34:32 -0700 From: Michael Hammer To: "worley@ariadne.com" , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 Thread-Index: Ac9i1jv/mFLedPbjTwav+N4oop+IjgAjA0EAACAyugAAO9xaAP//qJ4W///nWzA= Date: Wed, 30 Apr 2014 20:34:30 +0000 Message-ID: <00C069FD01E0324C9FFCADF539701DB3BBF79D0E@EX2K10MB1.corp.yaanatech.com> References: <7594FB04B1934943A5C02806D1A2204B1D2E20D2@ESESSMB209.ericsson.se> <535EC600.3010709@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D2E3F1B@ESESSMB209.ericsson.se> <53612FCC.7000705@alum.mit.edu> <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> In-Reply-To: <201404301901.s3UJ1Awf013148@hobgoblin.ariadne.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.17.100.149] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_020D_01CF6492.0EAC9D30" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dispatch/vaf72q7-d8e0U2LU5MhQSgvP848 Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Apr 2014 20:34:36 -0000 ------=_NextPart_000_020D_01CF6492.0EAC9D30 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dale, I don't think you can say it is part of the dialog, since it breaks depending on how middle-boxes manage dialogs. Could be orthogonal. I think you are on the right path though. Since this seems to be all about an attribute of the route, why wouldn't the Router header parameter be correct? ________________________________ Michael Hammer Principal Engineer michael.hammer@yaanatech.com Mobile: +1 408 202 9291 542 Gibraltar Drive Milpitas, CA 95035 USA www.yaanatech.com -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Dale R. Worley Sent: Wednesday, April 30, 2014 3:01 PM To: dispatch@ietf.org Subject: Re: [dispatch] Draft new: draft-holmberg-dispatch-iotl-00 As far as I can tell, the draft refers to "signaling path", but it does not distinguish whether the signaling path is the routing of a single dialog, or whether it is broken into multiple dialogs by B2BUAs. I don't think this changes the proposal technologically, but it should probably be stated explicitly somewhere. It *is* a requirement of the solution. It seems that the intention is that at any point, a progressing dialog-establishing or out-of-dialog request is labeled regarding which call leg it is within by the iotl parameter of the URI currently used for routing (the topmost Route or the request URI). This is a bit incorrect categorically, because: 1. it's not a property of the destination, its a property of the dialog, or part of the dialog 2. overlooking that, it's not really a property of the URI, its a modifier of how the URI is *used* (1) suggests that there should be a separate header to label the request. But that might be even more complex to define in order to be able to have a single dialog contain several call legs. (2) suggests that the iotl data should not be a URI parameter, but rather a header parameter. The Route header has header parameters, but the request-URI doesn't; I suppose the analogous item is the To header, which does have header parameters. Those solutions aren't satisfying, either. Dale _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ------=_NextPart_000_020D_01CF6492.0EAC9D30 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIR8DCCBBkw ggMBAhBhcMtJjF+YRSnnsKbZUFt6MA0GCSqGSIb3DQEBBQUAMIHKMQswCQYDVQQGEwJVUzEXMBUG A1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4 BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkx RTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBB dXRob3JpdHkgLSBHMzAeFw05OTEwMDEwMDAwMDBaFw0zNjA3MTYyMzU5NTlaMIHKMQswCQYDVQQG EwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJbmMuIC0gRm9yIGF1dGhvcml6ZWQg dXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDIgUHVibGljIFByaW1hcnkgQ2VydGlm aWNhdGlvbiBBdXRob3JpdHkgLSBHMzCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAK8K DcLVLNtnuS3llCfdpb7gsE2Ps2FWPNZ8w/TNPobLooji4dikacW14r/BpkdQXkY5i9WWurVvFL8Q zicTngVHmzF6E9gf2dMCN4utLEfwjoEGpw0wDOv3PA8gHdxyRu6lAshbw8lWaUzFGMGRewvVEwCb vO/DSD5GYCCFKtWQts2LoMwy3bf9QFWyUBxWrsyNd03HIE2nMXbvaJKKkB4IgVayrWmjUtDLHMQj PR+Z/kzoFmOOxgiO9jH20vrldt21HJKjSc3NAc1ozalpuqPrHQ2cpCCmwaDF0UZMF23SrGY/lozg hNQ2/yJZxfkRYKhfBH3yGvYlQmEPxEq4PokCAwEAATANBgkqhkiG9w0BAQUFAAOCAQEANCYVPMCN TUNJHb3pIZLXZpy33sW40ORdX3YiwCb5hDo6+Yy1++xg8ejOBLDI3acDjzDzmN+k5qQx39McC0bc ciA/ru4FPKQzPws5rHB4c0uZK98wwlSwqDtVof4WKM1CvXRugNsnRKfORF3UG5CYDR5ClLEALATQ dKMCBSJjY82DtfvBbWJraXX9XXBBufW/fN++wTJzIiGLWIF7FZF6uuNkSLB/+zYl2pXQ8SQUF90Y gGtGIzlU9Y5iCQQdlJCmm+Yl4kJFqriQrb4Ij6kLQhiUz3I54bFD4CjPt+dabBNrSbP/4xh8iYsz Xawz16f52jpVyVgQ+arvWrbPS0vfKjCCBmAwggVIoAMCAQICEHaFyweo4MwP0sVNjzk1sxIwDQYJ KoZIhvcNAQEFBQAwgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0G A1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMpIDE5OTkgVmVyaVNpZ24s IEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8VmVyaVNpZ24gQ2xhc3Mg MiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAtIEczMB4XDTExMDYwNzAw MDAwMFoXDTIxMDYwNjIzNTk1OVowgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBD b3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xh c3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFu dGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkwggEi MA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC3+D8MK4MjIIWmTUkBUTra3VAzvuMEpDo+o2Fm TDTC6HRwdUmlt0ns3bOSnN15DeK5+rg5PL6F44zvbXmjprcIv5xMvj6YjqzbfJor7AUoMF8pGzNN RNVw6FYimaY+nUJb6yOnY50tLLAuPxjzKc0aNomEksdXcFtwheY4oXxQ4zc4iGVba8s5KgSxgqoZ BP+gfz+j25FFdmaja/OFI15O2YVddaegFffBAHTg5cqUQmWawjd6i6hQrL+XdGd30TKnr43Lk6kl QrQwGnQK4iUQEMt0Z1UPyxT8QVAKpHxNCwv5Bak1+UWnMfGAu6LJPs52OeEq/3ZQ5+hRIt8tz7gz AgMBAAGjggI/MIICOzASBgNVHRMBAf8ECDAGAQH/AgEAMDQGA1UdHwQtMCswKaAnoCWGI2h0dHA6 Ly9jcmwudmVyaXNpZ24uY29tL3BjYTItZzMuY3JsMA4GA1UdDwEB/wQEAwIBBjApBgNVHREEIjAg pB4wHDEaMBgGA1UEAxMRVmVyaVNpZ25NUEtJLTItNTYwHQYDVR0OBBYEFNhIKahfKheS4vqee+9v YIP4uLjcMIHwBgNVHSMEgegwgeWhgdCkgc0wgcoxCzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazE6MDgGA1UECxMxKGMp IDE5OTkgVmVyaVNpZ24sIEluYy4gLSBGb3IgYXV0aG9yaXplZCB1c2Ugb25seTFFMEMGA1UEAxM8 VmVyaVNpZ24gQ2xhc3MgMiBQdWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eSAt IEczghBhcMtJjF+YRSnnsKbZUFt6MDQGCCsGAQUFBwEBBCgwJjAkBggrBgEFBQcwAYYYaHR0cDov L29jc3AudmVyaXNpZ24uY29tMGwGA1UdIARlMGMwYQYLYIZIAYb4RQEHFwIwUjAmBggrBgEFBQcC ARYaaHR0cDovL3d3dy5zeW1hdXRoLmNvbS9jcHMwKAYIKwYBBQUHAgIwHBoaaHR0cDovL3d3dy5z eW1hdXRoLmNvbS9ycGEwDQYJKoZIhvcNAQEFBQADggEBAKYqmwdAyez/s4joRdo00RcPKC23pYVn Mc3B5tUphjis4vBZGwzhoUXOJHjvacGwTGGiSNloT7r+dVQ3ulhp6sF2pTZC6p5meJAg2ZVqJHlU zd5aGoo7rhiVctAl2NJGvjQwp4Ce8VbOIB5sZ8lNT3mHieIugNae7SZhZaID0MXi8yi5K0lpgmfs 1ek0pC7cYiKkhU1I42oClPLN/eRnyEm8qtXH5zzeh7EQa10HXBnka6D0T5nL3LVbDMwy+WrkdMAq WDd5s/vNwzRv4XbdEAcAY4sHTicXkkebDr7eDROFEfyiL2V9zDqsHlRrVmfE7qWHIiMXK3BWw/Gu d1wnwTkwggdrMIIGU6ADAgECAhAG/Klcm5J55TO42VB6L0Z2MA0GCSqGSIb3DQEBBQUAMIHJMQsw CQYDVQQGEwJVUzEdMBsGA1UEChMUU3ltYW50ZWMgQ29ycG9yYXRpb24xHzAdBgNVBAsTFlN5bWFu dGVjIFRydXN0IE5ldHdvcmsxNTAzBgNVBAsTLENsYXNzIDIgTWFuYWdlZCBQS0kgSW5kaXZpZHVh bCBTdWJzY3JpYmVyIENBMUMwQQYDVQQDEzpTeW1hbnRlYyBDbGFzcyAyIFNoYXJlZCBJbnRlcm1l ZGlhdGUgQ2VydGlmaWNhdGUgQXV0aG9yaXR5MB4XDTE0MDMwNzAwMDAwMFoXDTE2MDMwNjIzNTk1 OVoweTEXMBUGA1UEAwwOTWljaGFlbCBIYW1tZXIxDzANBgNVBAsMBlMvTUlNRTEgMB4GA1UECgwX WWFhbmEgVGVjaG5vbG9naWVzLCBMTEMxKzApBgkqhkiG9w0BCQEWHG1pY2hhZWwuaGFtbWVyQHlh YW5hdGVjaC5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDDhrIoj3DQK9mYQmnm LZZey2IE3CFgP3uwRoHY3jUUGhoGkiUgBNLpJiZBvHE3LQDs5PTWE/sdZfdmabLzsDX3gk2bRbV1 3NQL0NmUdGjgP+ecdjgsUiZaiL5DwrM5aZajHnRkUyvaK/8YRholSnhdZBLCxDVMM9nziHeuuezB V+fenpY3Qe8NmEKHeYyXX2VSXKyFaQRBG+hW/c4XVxtq55Ja9DoC2yN9HEHT1Dxbp1J7MU8mJxZ2 sqLnuq9w8IIfx6hnP1gxESiylWao3IEYd9fESIVxQ+P3YOOzAvp2+zqwwQnBYGlfFgnohVFbeTP1 bqZ1U9i52w98bmGGypm3AgMBAAGjggOcMIIDmDAMBgNVHRMBAf8EAjAAMA4GA1UdDwEB/wQEAwIF oDAgBgNVHSUBAf8EFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwHQYDVR0OBBYEFFaFSmgtcRDwfRFi qt3Vq8LJCLn5MCcGA1UdEQQgMB6BHG1pY2hhZWwuaGFtbWVyQHlhYW5hdGVjaC5jb20wHwYDVR0j BBgwFoAU2EgpqF8qF5Li+p57729gg/i4uNwwggFxBggrBgEFBQcBAQSCAWMwggFfMCcGCCsGAQUF BzABhhtodHRwOi8vcGtpLW9jc3Auc3ltYXV0aC5jb20wggEyBggrBgEFBQcwAoaCASRsZGFwOi8v ZGlyZWN0b3J5LnZlcmlzaWduLmNvbS9DTiUyMCUzRCUyMFN5bWFudGVjJTIwQ2xhc3MlMjAyJTIw U2hhcmVkJTIwSW50ZXJtZWRpYXRlJTIwQ2VydGlmaWNhdGUlMjBBdXRob3JpdHklMkNPVSUyMCUz RCUyMENsYXNzJTIwMiUyME1hbmFnZWQlMjBQS0klMjBJbmRpdmlkdWFsJTIwU3Vic2NyaWJlciUy MENBJTJDT1UlMjAlM0QlMjBTeW1hbnRlYyUyMFRydXN0JTIwTmV0d29yayUyQ08lMjAlM0QlMjBT eW1hbnRlYyUyMENvcnBvcmF0aW9uJTJDQyUyMCUzRCUyMFVTP2NBQ2VydGlmaWNhdGU7YmluYXJ5 MF0GA1UdHwRWMFQwUqBQoE6GTGh0dHA6Ly9wa2ktY3JsLnN5bWF1dGguY29tL2NhXzA3YmI3ZDY0 NzdjZjRmNmJlOTZhZjFiMzZjYWJkMzE2L0xhdGVzdENSTC5jcmwwbAYDVR0gBGUwYzBhBgtghkgB hvhFAQcXAjBSMCYGCCsGAQUFBwIBFhpodHRwOi8vd3d3LnN5bWF1dGguY29tL2NwczAoBggrBgEF BQcCAjAcGhpodHRwOi8vd3d3LnN5bWF1dGguY29tL3JwYTBCBgkqhkiG9w0BCQ8ENTAzMAoGCCqG SIb3DQMHMAsGCWCGSAFlAwQBAjALBglghkgBZQMEARYwCwYJYIZIAWUDBAEqMCwGCmCGSAGG+EUB EAMEHjAcBhJghkgBhvhFARABAgIBAYabp24WBjE4NzIwOTA5BgpghkgBhvhFARAFBCswKQIBABYk YUhSMGNITTZMeTl3YTJrdGNtRXVjM2x0WVhWMGFDNWpiMjA9MA0GCSqGSIb3DQEBBQUAA4IBAQCb gnr/+BTv731e1vnbp5CumpK9um2FK5+6QQRkOknq48NjC4HcluiLkNJZNFc6lNUnDiaPFBGzAMFI FBZ55Io939W3O+q15R9PfXfZ18vkg/eRVr3ejw1jlD4DimLSb9xMtflheEzpTo4PmNBQOcbR6OQs EwrSlWWk6fhnPXHvuF9xJ+wlXKWFqP/BTiKH7i3weq3dcZn83HO4l1XhcxYPv5zSP+lFqCjh9Gu9 2NAvGhtegMbJ82IlM3edN+q8G890bnavQWhk/pO4bEqDKkLOKgr3ir6qZ6/qxhp8m3ADDHTcGv5n l4E9gG8v7NrV5iqBglGQYZoOA8RqKWpjGJMTMYIE+zCCBPcCAQEwgd4wgckxCzAJBgNVBAYTAlVT MR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlvbjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3Qg TmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5hZ2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmli ZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNzIDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0 aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZUHovRnYwCQYFKw4DAhoFAKCCAvEwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTQwNDMwMjAzNDI5WjAjBgkqhkiG 9w0BCQQxFgQUCZ2c55f9BJwAY3G6r4C38rVpsmAwgasGCSqGSIb3DQEJDzGBnTCBmjALBglghkgB ZQMEASowCwYJYIZIAWUDBAEWMAoGCCqGSIb3DQMHMAsGCWCGSAFlAwQBAjAOBggqhkiG9w0DAgIC AIAwBwYFKw4DAgcwDQYIKoZIhvcNAwICAUAwDQYIKoZIhvcNAwICASgwBwYFKw4DAhowCwYJYIZI AWUDBAIDMAsGCWCGSAFlAwQCAjALBglghkgBZQMEAgEwge8GCSsGAQQBgjcQBDGB4TCB3jCByTEL MAkGA1UEBhMCVVMxHTAbBgNVBAoTFFN5bWFudGVjIENvcnBvcmF0aW9uMR8wHQYDVQQLExZTeW1h bnRlYyBUcnVzdCBOZXR3b3JrMTUwMwYDVQQLEyxDbGFzcyAyIE1hbmFnZWQgUEtJIEluZGl2aWR1 YWwgU3Vic2NyaWJlciBDQTFDMEEGA1UEAxM6U3ltYW50ZWMgQ2xhc3MgMiBTaGFyZWQgSW50ZXJt ZWRpYXRlIENlcnRpZmljYXRlIEF1dGhvcml0eQIQBvypXJuSeeUzuNlQei9GdjCB8QYLKoZIhvcN AQkQAgsxgeGggd4wgckxCzAJBgNVBAYTAlVTMR0wGwYDVQQKExRTeW1hbnRlYyBDb3Jwb3JhdGlv bjEfMB0GA1UECxMWU3ltYW50ZWMgVHJ1c3QgTmV0d29yazE1MDMGA1UECxMsQ2xhc3MgMiBNYW5h Z2VkIFBLSSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0ExQzBBBgNVBAMTOlN5bWFudGVjIENsYXNz IDIgU2hhcmVkIEludGVybWVkaWF0ZSBDZXJ0aWZpY2F0ZSBBdXRob3JpdHkCEAb8qVybknnlM7jZ UHovRnYwDQYJKoZIhvcNAQEBBQAEggEAIk2flEAbV3JZ6DJ3rEVGTcK8SDa4hSIR+2rNmH6I+QAK wf4C0NdFl4DVNw+rYerXbuwKUSSIYrQC/Z1JGXhV+vMmIu0NVb3lB9eEwum4jmvH9s//IutegEhz 1Wa23TKD7MTXP7vVWBAFx/o7fVZDFykeavYuabxPv3TZQGUXjFslQAKkbtG6ByRlw3822E+vuDlK /gr/xWLiWl99Zdp3jnS1wxpUSGBUthRJUA9PLLUPJbxZ8cdnmV6WtHulX9qRLllrLK4/RLSItEgZ ilyt9Oi7EBfgorSQnaWv57o/Zr8nXaLGKQtQoyGPotOeCz4BmuQVuO9gNMAF7vv1PNoRQgAAAAAA AA== ------=_NextPart_000_020D_01CF6492.0EAC9D30--