From nobody Wed Jun 1 14:23:07 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D47A012B01F for ; Wed, 1 Jun 2016 14:23:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.32 X-Spam-Level: X-Spam-Status: No, score=-1.32 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 I92NDPrXo1us for ; Wed, 1 Jun 2016 14:23:00 -0700 (PDT) Received: from forward9h.cmail.yandex.net (forward9h.cmail.yandex.net [87.250.230.220]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 147EE12D617 for ; Wed, 1 Jun 2016 14:22:59 -0700 (PDT) Received: from mxback9h.mail.yandex.net (mxback9h.mail.yandex.net [84.201.186.18]) by forward9h.cmail.yandex.net (Yandex) with ESMTP id 24EF420F90; Thu, 2 Jun 2016 00:22:49 +0300 (MSK) Received: from web30h.yandex.ru (web30h.yandex.ru [84.201.187.164]) by mxback9h.mail.yandex.net (nwsmtp/Yandex) with ESMTP id NhhHQup8zl-MmlWDasI; Thu, 02 Jun 2016 00:22:48 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1464816168; bh=shfdJzkX7Nl1lXyCL4nWPEKyvH0A3JY5hNGdP81k6aI=; h=X-Yandex-Sender-Uid:From:To:Cc:Subject:MIME-Version:Message-Id: X-Mailer:Date:Content-Transfer-Encoding:Content-Type; b=KLY4KHmsZjUama/eYTcmcfnSFZQuC0HvgBNJ9wxhMafgBSFnJN3Ol+VvYaBdWbf9q ZTdnGM0UI6GLG7WYmU2CozDAfAL8nR/ADqCtSPujQNTW4TkselP14x7Vyd5AimPMkc vMPtIQr93VWng6l7mdEwcENjbDvgVSai8gCXw+v0= Authentication-Results: mxback9h.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 492863893 X-Yandex-Sender-Uid: 161206619 Received: by web30h.yandex.ru with HTTP; Thu, 02 Jun 2016 00:22:48 +0300 From: Anton Tveretin To: Adrian Hope-Bailie MIME-Version: 1.0 Message-Id: <1127651464816168@web30h.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 02 Jun 2016 02:22:48 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jun 2016 21:23:06 -0000 Hello Adrian, What's the difference (where's the border) between this WG and Payments WG? It seems to me there is an overlap with my format, NGMTP Class 9. Parts of it I publish on my site. The first is AC3H for Account Chain, the second is CoABoS for Certificate of Acceptance/Bill of Service. I hope to make it more readable soon :), better add some introductory memo. The elementary thing I consider a bank account as a legal contract. The contract is based on exchange of instruments (payment orders, advises, statements etc.) Regards, Anton. From nobody Thu Jun 2 07:16:16 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CFE212D735 for ; Thu, 2 Jun 2016 07:16:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com 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 nPJTE7sYKGmF for ; Thu, 2 Jun 2016 07:16:10 -0700 (PDT) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3B1412D1C7 for ; Thu, 2 Jun 2016 07:16:06 -0700 (PDT) Received: by mail-oi0-x230.google.com with SMTP id k23so79128162oih.0 for ; Thu, 02 Jun 2016 07:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=iDRax2VqwIeIDy7FUjEIBEFRWlvD8ykNimyxQwirQUI=; b=O1PON3a1g/AFRcHZfRBCUNV3WBgttkVvXuRdxThm5Cp3XxzI2TPwWE/bqU2xtZhuJB GBT2ItWghgCi7aP3piuRUejACRokfuAqPS8071sbixQNBw9/bRd2kY019qoeYGIqQKYc dLFTtmB/nK0plux0RrYW2hsmN/RauFGkkLXAg= 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; bh=iDRax2VqwIeIDy7FUjEIBEFRWlvD8ykNimyxQwirQUI=; b=d0jMhJpK13xPdKojnRym26XmyaxbKb57z10oxOILb3Q4oKj1JkTph8w6sHV+GxQd4j 1felQRNp5xPpNDG7nweEGRAtmM+3PFoJKONgK/JMPtFQBsF8VxWg30sGHAo19x/IXnpm 5GEmvHJvR9TPW9P4ASgkt626/XIAl0GSQGhs3Rw0C+iM3bBA53VmSfsl62QKsFdlBfKJ tabbTM1+qackULPwPWYfhcxFAZP91YFZ1F7aF7mCScuAXdRgAL6/X1DIrRDCYesTUJ21 iOUzKV78b5FA1noQmCI1tW9j9xlCcOKgL/1f/MPCZPE1CyLHpxZulwXiZ3fHaDDJYcGG 5JZA== X-Gm-Message-State: ALyK8tJQ8kxp56e7/cJ12gHCFf9HIxEznL5HqlSxKL52qK0h+VwGcqDrWP21bZ64fuYT1qqZ2dOSHmgpMe+myA== MIME-Version: 1.0 X-Received: by 10.202.173.215 with SMTP id w206mr23255812oie.10.1464876965895; Thu, 02 Jun 2016 07:16:05 -0700 (PDT) Received: by 10.202.81.5 with HTTP; Thu, 2 Jun 2016 07:16:05 -0700 (PDT) In-Reply-To: <1127651464816168@web30h.yandex.ru> References: <1127651464816168@web30h.yandex.ru> Date: Thu, 2 Jun 2016 16:16:05 +0200 Message-ID: From: Adrian Hope-Bailie To: Anton Tveretin Content-Type: multipart/alternative; boundary=001a113cf01031509505344c3f10 Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 14:16:14 -0000 --001a113cf01031509505344c3f10 Content-Type: text/plain; charset=UTF-8 Hi Anton, I wasn't aware of a Payments WG at IETF or of NGMTP. Can you provide a link to some resources or a mailing list archive so i can get myself up to speed? All I can find after some searching is a draft spec for a new mail-transport protocol (and then can't find any reference to "Class 9". Based on the description in your email I can speculate that the main differences are: 1. The base component of the Interledger is a ledger. It is simply a system that keeps a record of the current balances of a particular asset for one or more accounts. i.e. It is not just limited to bank accounts and does not concern itself with legal implications of balances changing in a ledger. 2. Interledger is specifically focused on payments, it is not a generic transport protocol that can be used to transfer digital assets, that is it's core function. 3. Interledger's architecture is modular (it's a protocol stack) and functions such as publishing and consuming Certificates of Acceptance or Bill of Service are handled right up in the application layer (possibly by a use case specific protocol). The majority of the work on Interledger is on the lower layers, ledgers, connectors and the protocols used to route payments and get quotes for payments. Adrian On 1 June 2016 at 23:22, Anton Tveretin wrote: > Hello Adrian, > What's the difference (where's the border) between this WG and Payments > WG? It seems to me there is an overlap with my format, NGMTP Class 9. Parts > of it I publish on my site. The first is AC3H for Account Chain, the second > is CoABoS for Certificate of Acceptance/Bill of Service. I hope to make it > more readable soon :), better add some introductory memo. > The elementary thing I consider a bank account as a legal contract. The > contract is based on exchange of instruments (payment orders, advises, > statements etc.) > Regards, > Anton. > --001a113cf01031509505344c3f10 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Anton,

I wasn't aware o= f a Payments WG at IETF or of NGMTP.
Can you provide a link to som= e resources or a mailing list archive so i can get myself up to speed?
<= br>
All I can find after some searching is a draft spec for a new= mail-transport protocol (and then can't find any reference to "Cl= ass 9".

Based on the description in your email= I can speculate that the main differences are:
  1. The base compone= nt of the Interledger is a ledger. It is simply a system that keeps a recor= d of the current balances of a particular asset for one or more accounts. i= .e. It is not just limited to bank accounts and does not concern itself wit= h legal implications of balances changing in a ledger.
  2. Interledger = is specifically focused on payments, it is not a generic transport protocol= that can be used to transfer digital assets, that is it's core functio= n.
  3. Interledger's architecture is modular (it's a protocol s= tack) and functions such as publishing and consuming Certificates of Accept= ance or Bill of Service are handled right up in the application layer (poss= ibly by a use case specific protocol). The majority of the work on Interled= ger is on the lower layers, ledgers, connectors and the protocols used to r= oute payments and get quotes for payments.

Adrian

<= br>

On 1 June 2016 at 23:22, Anton Tveretin <tveretinas@yandex.ru>= wrote:
Hello Adrian,
What's the difference (where's the border) between this WG and Paym= ents WG? It seems to me there is an overlap with my format, NGMTP Class 9. = Parts of it I publish on my site. The first is AC3H for Account Chain, the = second is CoABoS for Certificate of Acceptance/Bill of Service. I hope to m= ake it more readable soon :), better add some introductory memo.
The elementary thing I consider a bank account as a legal contract. The con= tract is based on exchange of instruments (payment orders, advises, stateme= nts etc.)
Regards,
Anton.

--001a113cf01031509505344c3f10-- From nobody Thu Jun 2 08:59:33 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1942812D5B0 for ; Thu, 2 Jun 2016 08:59:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 bDZj9tCzRUlv for ; Thu, 2 Jun 2016 08:59:26 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EA3A12D541 for ; Thu, 2 Jun 2016 08:59:26 -0700 (PDT) Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u52FxMP8004465 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 2 Jun 2016 10:59:23 -0500 (CDT) (envelope-from adam@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local To: Adrian Hope-Bailie , Anton Tveretin References: <1127651464816168@web30h.yandex.ru> From: Adam Roach Message-ID: <19db51ff-72ca-6769-22ca-3daf768b3fb7@nostrum.com> Date: Thu, 2 Jun 2016 10:59:21 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Jun 2016 15:59:28 -0000 On 6/2/16 09:16, Adrian Hope-Bailie wrote: > I wasn't aware of a Payments WG at IETF or of NGMTP. > Can you provide a link to some resources or a mailing list archive so > i can get myself up to speed? I'm not sure offhand which Working Group Anton is referring to. As far as I'm able to turn up, there have only been two working groups in the IETF's history that dealt squarely with payment-related technologies: The ISPP (Internet Secure Payments Protocol) WG concluded in January of 1997. The charter at its time of conclusion is here: https://datatracker.ietf.org/wg/ispp/charter/ The TRADE (Internet Open Trading Protocols) concluded in Feburary of 2005. The charter at its time of conclusion is here: https://datatracker.ietf.org/wg/trade/charter/ Both working groups predate any centrally-coordinated mailing list archiving by the IETF, and the archives of their mailing list discussions no longer appear to be online. They also date back to a period of time in which internet drafts were aggressively removed from the internet after their six-month expiration period, so tracing their work output to the generated RFCs is not terribly straightforward. TRADE's main output relic appears to be the Internet Open Trading Protocol (IOTP), documented in RFCs 2801 - 2803, and RFC 3504. There appears to have been an effort started to define a v2 of the protocol, but that work does not appear to have borne fruit. See also . I can't figure out whether ISPP produced any RFCs at all. /a From nobody Mon Jun 6 00:03:05 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5217012B030; Mon, 6 Jun 2016 00:03:03 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Meeting Session Request Tool\"" To: X-Test-IDTracker: no X-IETF-IDTracker: 6.21.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160606070303.20862.52717.idtracker@ietfa.amsl.com> Date: Mon, 06 Jun 2016 00:03:03 -0700 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org, dispatch-chairs@ietf.org Subject: [dispatch] dispatch - New Meeting Session Request for IETF 96 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 07:03:03 -0000 A new meeting session request has just been submitted by Murray Kucherawy, a Chair of the dispatch working group. --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Murray Kucherawy Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: appsawg apparea avtcore avtext bfcpbis clue core dbound ecrit insipid mmusic netvc p2psip payload rmcat rtcweb sipcore siprec stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Mon Jun 6 13:25:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 366CE12D1B8 for ; Mon, 6 Jun 2016 13:25:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 4Z96hAPXDR20 for ; Mon, 6 Jun 2016 13:25:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F1A912B03F for ; Mon, 6 Jun 2016 13:25:42 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u56KPfg8039481 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 6 Jun 2016 15:25:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "dispatch@ietf.org" Date: Mon, 06 Jun 2016 15:25:41 -0500 Message-ID: <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> In-Reply-To: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:25:45 -0000 Since no one complained, and a few people expressed support directly to me offline, I added that text to the proposed charter, along with adding RTCWEB to the list of groups in the "expected to coordinate with" paragraph. I will put this on the agenda for internal review on the next IESG telechat. That should not shut down discussion, so if people have further thoughts, please comment as soon as possible. Thanks! Ben. On 26 May 2016, at 19:55, Ben Campbell wrote: > Hi Jon, > > As an individual, I'm afraid the association of this effort with other > great unsolved problems (Great Unsolved Theories?) may be prophetic. > (Also, the implied acronym :-) ) I'd be happy if we just solved e2e > confidentiality. And I don't think we would be happy if we solved all > the other things and _not_ e2e confidentiality. > > It also seems to me that aligning identity models fits more with STIR > than with this group. > > That being said, what about something like the following: > > "While confidentiality is the first priority of the working group, it > may work on aligning these practices with WebRTC, for example by > defining best practices for ensuring recipients of media flows have > consented to receive such flows, in order to prevent or mitigate the > denial-of-service attack described in RFC 5245, section 18.5.1." > > Ben. > > On 26 May 2016, at 19:05, Peterson, Jon wrote: > >> It would be a fairly significant change to the proposed scope, but >> perhaps >> one that's warranted. >> >> I understand why you have some process caution here about scoping a >> consent mechanism to ICE at the outset, but if we're going to put >> this >> problem under SIPPRANDY's umbrella, I think it could make sense to >> set the >> explicit goal of getting a "grand unified theory" of VoIP security >> that >> would align the security of SIP and WebRTC. As we all know, WebRTC >> went >> down many of the paths that it did for the sake of backwards >> compatibility >> with SIP, and it would be a shame if the effort to interwork the two >> proved futile because of lack of e2e SRTP. Consent would be another >> prong >> of that. So maybe writing ICE in as a foregone conclusion in the >> service >> of that goal would let us skip some unnecessary deliberation. Getting >> plausible interworking with WebRTC could also provide some further >> incentive for implementers to crack open their SIP implementations. >> >> If a "grand unified theory" is the goal, then this also conforms >> nicely >> with Cullen's recent efforts to figure out how to get STIR and >> WebRTC's >> IdP aligned. As my strawman proposal for SIP media confidentiality >> had >> both a STIR story and an opportunistic story, we could argue that >> getting >> alignment of identity, consent, and encryption could be grouped under >> one >> effort, which is mostly about getting offer/answer to deal with those >> three things in a common way - especially as WebRTC IdP today conveys >> that >> identity information as an SDP attribute. >> >> Realigning Offers[/Answers]: The Grand Unified Theory? >> >> Jon Peterson >> Neustar, Inc. >> >> On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" >> wrote: >> >>> As early as 2005, we identified a class of DoS attack that would be >>> enabled by SIP systems, if widely deployed on the public internet. >>> Called the "Voice Hammer," this attack involves triggering >>> potentially >>> vast quantities of media traffic towards a target using normal SIP >>> call >>> setup procedures. >>> >>> While I don't think this is something that SIPBRANDY is required to >>> address, I would like it to be part of the discussion. I believe >>> this >>> makes sense for two reasons: (1) I expect the recommendations that >>> come >>> out of SIPBRANDY to require non-trivial endpoint changes, and it >>> would >>> be good to consider coupling breaking changes to each other so as to >>> minimize the number of potential modes of operation; and (2) the >>> issue >>> is fundamentally a security issue -- albeit of a different nature -- >>> which would seem to require the same set of expertise as the other >>> problems SIPBRANDY will work on. >>> >>> To that end, I propose adding the following sentence to the >>> "Objectives" >>> paragraph in the SIPBRANDY charter: >>> >>> "The working group may also define best practices for ensuring >>> recipients of media flows have consented to receive such flows, in >>> order >>> to prevent or mitigate the denial-of-service attack described in RFC >>> 5245, section 18.5.1." >>> >>> To be clear: I do not wish to presuppose that the solution to this >>> problem will be ICE, or that it even is required in order for the WG >>> to >>> declare success. I just want it to be available for consideration. >>> >>> /a >>> >>> _______________________________________________ >>> 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 > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jun 6 13:27:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B3C412D54F for ; Mon, 6 Jun 2016 13:27:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 KANHZIed0wd2 for ; Mon, 6 Jun 2016 13:27:06 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4404412D18F for ; Mon, 6 Jun 2016 13:27:06 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u56KR52o039723 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Mon, 6 Jun 2016 15:27:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "dispatch@ietf.org" Date: Mon, 06 Jun 2016 15:27:05 -0500 Message-ID: In-Reply-To: <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_B235CB0D-518B-4221-8BF1-7C19737BE5CD_=" X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jun 2016 20:27:08 -0000 --=_MailMate_B235CB0D-518B-4221-8BF1-7C19737BE5CD_= Content-Type: text/plain; format=flowed; markup=markdown The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . Ben. On 6 Jun 2016, at 15:25, Ben Campbell wrote: > Since no one complained, and a few people expressed support directly > to me offline, I added that text to the proposed charter, along with > adding RTCWEB to the list of groups in the "expected to coordinate > with" paragraph. > > I will put this on the agenda for internal review on the next IESG > telechat. That should not shut down discussion, so if people have > further thoughts, please comment as soon as possible. > > Thanks! > > Ben. > > On 26 May 2016, at 19:55, Ben Campbell wrote: > >> Hi Jon, >> >> As an individual, I'm afraid the association of this effort with >> other great unsolved problems (Great Unsolved Theories?) may be >> prophetic. (Also, the implied acronym :-) ) I'd be happy if we just >> solved e2e confidentiality. And I don't think we would be happy if we >> solved all the other things and _not_ e2e confidentiality. >> >> It also seems to me that aligning identity models fits more with STIR >> than with this group. >> >> That being said, what about something like the following: >> >> "While confidentiality is the first priority of the working group, it >> may work on aligning these practices with WebRTC, for example by >> defining best practices for ensuring recipients of media flows have >> consented to receive such flows, in order to prevent or mitigate the >> denial-of-service attack described in RFC 5245, section 18.5.1." >> >> Ben. >> >> On 26 May 2016, at 19:05, Peterson, Jon wrote: >> >>> It would be a fairly significant change to the proposed scope, but >>> perhaps >>> one that's warranted. >>> >>> I understand why you have some process caution here about scoping a >>> consent mechanism to ICE at the outset, but if we're going to put >>> this >>> problem under SIPPRANDY's umbrella, I think it could make sense to >>> set the >>> explicit goal of getting a "grand unified theory" of VoIP security >>> that >>> would align the security of SIP and WebRTC. As we all know, WebRTC >>> went >>> down many of the paths that it did for the sake of backwards >>> compatibility >>> with SIP, and it would be a shame if the effort to interwork the two >>> proved futile because of lack of e2e SRTP. Consent would be another >>> prong >>> of that. So maybe writing ICE in as a foregone conclusion in the >>> service >>> of that goal would let us skip some unnecessary deliberation. >>> Getting >>> plausible interworking with WebRTC could also provide some further >>> incentive for implementers to crack open their SIP implementations. >>> >>> If a "grand unified theory" is the goal, then this also conforms >>> nicely >>> with Cullen's recent efforts to figure out how to get STIR and >>> WebRTC's >>> IdP aligned. As my strawman proposal for SIP media confidentiality >>> had >>> both a STIR story and an opportunistic story, we could argue that >>> getting >>> alignment of identity, consent, and encryption could be grouped >>> under one >>> effort, which is mostly about getting offer/answer to deal with >>> those >>> three things in a common way - especially as WebRTC IdP today >>> conveys that >>> identity information as an SDP attribute. >>> >>> Realigning Offers[/Answers]: The Grand Unified Theory? >>> >>> Jon Peterson >>> Neustar, Inc. >>> >>> On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" >>> wrote: >>> >>>> As early as 2005, we identified a class of DoS attack that would be >>>> enabled by SIP systems, if widely deployed on the public internet. >>>> Called the "Voice Hammer," this attack involves triggering >>>> potentially >>>> vast quantities of media traffic towards a target using normal SIP >>>> call >>>> setup procedures. >>>> >>>> While I don't think this is something that SIPBRANDY is required to >>>> address, I would like it to be part of the discussion. I believe >>>> this >>>> makes sense for two reasons: (1) I expect the recommendations that >>>> come >>>> out of SIPBRANDY to require non-trivial endpoint changes, and it >>>> would >>>> be good to consider coupling breaking changes to each other so as >>>> to >>>> minimize the number of potential modes of operation; and (2) the >>>> issue >>>> is fundamentally a security issue -- albeit of a different nature >>>> -- >>>> which would seem to require the same set of expertise as the other >>>> problems SIPBRANDY will work on. >>>> >>>> To that end, I propose adding the following sentence to the >>>> "Objectives" >>>> paragraph in the SIPBRANDY charter: >>>> >>>> "The working group may also define best practices for ensuring >>>> recipients of media flows have consented to receive such flows, in >>>> order >>>> to prevent or mitigate the denial-of-service attack described in >>>> RFC >>>> 5245, section 18.5.1." >>>> >>>> To be clear: I do not wish to presuppose that the solution to this >>>> problem will be ICE, or that it even is required in order for the >>>> WG to >>>> declare success. I just want it to be available for consideration. >>>> >>>> /a >>>> >>>> _______________________________________________ >>>> 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 >> >> _______________________________________________ >> 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 --=_MailMate_B235CB0D-518B-4221-8BF1-7C19737BE5CD_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

The most recent proposed text is at https://datatracker.ietf.= org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed suppo= rt directly to me offline, I added that text to the proposed charter, alo= ng with adding RTCWEB to the list of groups in the "expected to coordinat= e with" paragraph.

I will put this on the agenda for internal review on the = next IESG telechat. That should not shut down discussion, so if people ha= ve further thoughts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effo= rt with other great unsolved problems (Great Unsolved Theories?) may be p= rophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved= e2e confidentiality. And I don't think we would be happy if we solved al= l the other things and not e2e confidentiality.

It also seems to me that aligning identity models fits mo= re with STIR than with this group.

That being said, what about something like the following:=

"While confidentiality is the first priority of the worki= ng group, it may work on aligning these practices with WebRTC, for exampl= e by defining best practices for ensuring recipients of media flows have = consented to receive such flows, in order to prevent or mitigate the deni= al-of-service attack described in RFC 5245, section 18.5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed s= cope, but perhaps
one that's warranted.

I understand why you have some process caution here about= scoping a
consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set th= e
explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibilit= y
with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong=
of that. So maybe writing ICE in as a foregone conclusion in the service<= br> of that goal would let us skip some unnecessary deliberation. Getting
= plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also c= onforms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting=
alignment of identity, consent, and encryption could be grouped under one=
effort, which is mostly about getting offer/answer to deal with those
= three things in a common way - especially as WebRTC IdP today conveys tha= t
identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" <dispatch-bounces@ietf.org on behalf of adam@nostrum.com> wrote:

As early as 2005, we identified a class of DoS attack tha= t would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures.

While I don't think this is something that SIPBRANDY is r= equired to
address, I would like it to be part of the discussion. I believe this
= makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to t= he "Objectives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ens= uring
recipients of media flows have consented to receive such flows, in order<= br> to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solutio= n to this
problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration.

/a

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

--=_MailMate_B235CB0D-518B-4221-8BF1-7C19737BE5CD_=-- From nobody Mon Jun 6 23:42:53 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDEDC127058 for ; Mon, 6 Jun 2016 23:42:51 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 1yvwgvzvt6Wf for ; Mon, 6 Jun 2016 23:42:48 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0602.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc09::602]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90A7A12D11E for ; Mon, 6 Jun 2016 23:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=DTUhcOZFJWTpOVadSzjGWqZPPhQbrtdAcuJij3JPb94=; b=uOtIqnZgMCTB6UiC8SXiY0N5riwXYH/5o7Fvq4vAOLIPN6pQCHaMHwCAeSunM6g48siXj4whfSpJimMc9GqJgYR/U926yvft1meC4PVX0pW5Q1jthpBDnRggHiJP/bAEB9zh5K6YM5ZNrMCnAwH6uRm4sBAbCdUzzWf7YfK8p5U= Received: from SN1PR0301MB1551.namprd03.prod.outlook.com (10.162.129.157) by SN1PR0301MB1550.namprd03.prod.outlook.com (10.162.129.156) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.506.9; Tue, 7 Jun 2016 06:42:44 +0000 Received: from SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) by SN1PR0301MB1551.namprd03.prod.outlook.com ([10.162.129.157]) with mapi id 15.01.0506.016; Tue, 7 Jun 2016 06:42:44 +0000 From: "Asveren, Tolga" To: Ben Campbell , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRttLzU7vf4MN9qkG+x6gAOAYZYJ/L6TKAgAAOCYCAEP5PgIAAAGSAgACrq0A= Date: Tue, 7 Jun 2016 06:42:44 +0000 Message-ID: References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=tasveren@sonusnet.com; x-originating-ip: [73.29.18.75] x-ms-office365-filtering-correlation-id: 09a00866-2a6c-4af8-5830-08d38e9eee94 x-microsoft-exchange-diagnostics: 1; SN1PR0301MB1550; 5:XWEpX6Tt637+jdz8V9oH1SMYYwvp7zuJaCuy59BrA5qFvV7s3iDO2V3FmNpQZOYXeqhe/LqP3TDRGkLwuUI7TER6dCqRgjHElNq58eoBQ7O0usmlaMk0IvcXlMn0YFVIo73jmkPXR3G058hRcDSGIA==; 24:BiNgE40HQeBcQWJNopUw1iSkvkToCMc7rYUjZiOTVaZCmOiUcTqEEezCYgW/Et6qBmU5SOYi58n9UITso+9pwFoESD/EwHN7ji8HgvBwsTA=; 7:nvkJSEbBfQUAtofvxBiILVsJfdpYvgOOpjDSDZMXORtEFFou9bfRHxUU3m0Le1eUNtrRaqsMeDWEoC/yFuVq3oRE6SZSg5T+23ppr3Ei5HchYHYRa9ny18zImAtljnOZB89Z+YDrwNSqR8yLMjElBvxJkhlNF/ZO/60OzL9rjEnaAHmkwTAjLkA3t2BfEJ5jeBcbuDKREqDTZwch1FbtCA== x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0301MB1550; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(192374486261705)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:SN1PR0301MB1550; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0301MB1550; x-forefront-prvs: 09669DB681 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(377454003)(199003)(189002)(24454002)(122556002)(11100500001)(77096005)(15975445007)(105586002)(106116001)(97736004)(19609705001)(2906002)(5001770100001)(106356001)(3280700002)(5008740100001)(5004730100002)(3660700001)(74316001)(10400500002)(19617315012)(19625215002)(107886002)(19300405004)(93886004)(189998001)(2501003)(66066001)(81166006)(5002640100001)(586003)(81156014)(8936002)(790700001)(102836003)(6116002)(33656002)(9686002)(86362001)(76576001)(3846002)(101416001)(8676002)(99286002)(19580395003)(92566002)(19580405001)(68736007)(16236675004)(50986999)(5003600100002)(54356999)(561944003)(76176999)(2900100001)(2950100001)(87936001); DIR:OUT; SFP:1101; SCL:1; SRVR:SN1PR0301MB1550; H:SN1PR0301MB1551.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_SN1PR0301MB15517B8E9491A8783FE71D3CB25D0SN1PR0301MB1551_" MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2016 06:42:44.5548 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0301MB1550 Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jun 2016 06:42:52 -0000 --_000_SN1PR0301MB15517B8E9491A8783FE71D3CB25D0SN1PR0301MB1551_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable FWIW, I would like to say that I concur with your statement "I'd be happy i= f we just solved e2e confidentiality. And I don't think we would be happy i= f we solved all the other things and not e2e confidentiality." And hope tha= t other targets won't jeopardize reaching the main goal. Thanks, Tolga From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell Sent: Monday, June 06, 2016 4:27 PM To: dispatch@ietf.org Subject: Re: [dispatch] SIPBRANDY and other dangers The most recent proposed text is at https://datatracker.ietf.org/doc/charte= r-ietf-sipbrandy/ . Ben. On 6 Jun 2016, at 15:25, Ben Campbell wrote: Since no one complained, and a few people expressed support directly to me = offline, I added that text to the proposed charter, along with adding RTCWE= B to the list of groups in the "expected to coordinate with" paragraph. I will put this on the agenda for internal review on the next IESG telechat= . That should not shut down discussion, so if people have further thoughts,= please comment as soon as possible. Thanks! Ben. On 26 May 2016, at 19:55, Ben Campbell wrote: Hi Jon, As an individual, I'm afraid the association of this effort with other grea= t unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the= implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. = And I don't think we would be happy if we solved all the other things and n= ot e2e confidentiality. It also seems to me that aligning identity models fits more with STIR than = with this group. That being said, what about something like the following: "While confidentiality is the first priority of the working group, it may w= ork on aligning these practices with WebRTC, for example by defining best p= ractices for ensuring recipients of media flows have consented to receive s= uch flows, in order to prevent or mitigate the denial-of-service attack des= cribed in RFC 5245, section 18.5.1." Ben. On 26 May 2016, at 19:05, Peterson, Jon wrote: It would be a fairly significant change to the proposed scope, but perhaps one that's warranted. I understand why you have some process caution here about scoping a consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set the explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibility with SIP, and it would be a shame if the effort to interwork the two proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting plausible interworking with WebRTC could also provide some further incentive for implementers to crack open their SIP implementations. If a "grand unified theory" is the goal, then this also conforms nicely with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those three things in a common way - especially as WebRTC IdP today conveys that identity information as an SDP attribute. Realigning Offers[/Answers]: The Grand Unified Theory? Jon Peterson Neustar, Inc. On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > wrote: As early as 2005, we identified a class of DoS attack that would be enabled by SIP systems, if widely deployed on the public internet. Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures. While I don't think this is something that SIPBRANDY is required to address, I would like it to be part of the discussion. I believe this makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature -- which would seem to require the same set of expertise as the other problems SIPBRANDY will work on. To that end, I propose adding the following sentence to the "Objectives" paragraph in the SIPBRANDY charter: "The working group may also define best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." To be clear: I do not wish to presuppose that the solution to this problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration. /a ________________________________ 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 ________________________________ 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 --_000_SN1PR0301MB15517B8E9491A8783FE71D3CB25D0SN1PR0301MB1551_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

FWIW, I would like to say that I conc= ur with your statement “I'd be happy if we just solved e2e confidenti= ality. And I don't think we would be happy if we solved all the other things and not e2e confidentiality.” And hope that oth= er targets won’t jeopardize reaching the main goal.=

 

Thanks,

Tolga

 

From: dispatch [mailto:dispatch-boun= ces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, June 06, 2016 4:27 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

 

The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed support directly to = me offline, I added that text to the proposed charter, along with adding RT= CWEB to the list of groups in the "expected to coordinate with" p= aragraph.

I will put this on the agenda for internal review on the next IESG telec= hat. That should not shut down discussion, so if people have further though= ts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effort with other g= reat unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, = the implied acronym :-) ) I'd be happy if we just solved e2e confidentialit= y. And I don't think we would be happy if we solved all the other things and not e2e confidentiali= ty.

It also seems to me that aligning identity models fits more with STIR th= an with this group.

That being said, what about something like the following:

"While confidentiality is the first priority of the working group, = it may work on aligning these practices with WebRTC, for example by definin= g best practices for ensuring recipients of media flows have consented to r= eceive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18= .5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed scope, but perha= ps
one that's warranted.

I understand why you have some process caution here about scoping a
consent mechanism to ICE at the outset, but if we're going to put this
problem under SIPPRANDY's umbrella, I think it could make sense to set the<= br> explicit goal of getting a "grand unified theory" of VoIP securit= y that
would align the security of SIP and WebRTC. As we all know, WebRTC went
down many of the paths that it did for the sake of backwards compatibility<= br> with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting
plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also confor= ms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's
IdP aligned. As my strawman proposal for SIP media confidentiality had
both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those
three things in a common way - especially as WebRTC IdP today conveys that<= br> identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<dispatch-bounces@ietf.org on behalf of adam@nostrum.com>= wrote:

As early as 2005, we identified a class of DoS attack that would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potent= ially
vast quantities of media traffic towards a target using normal SIP call
setup procedures.

While I don't think this is something that SIPBRANDY is required to
address, I would like it to be part of the discussion. I believe this
makes sense for two reasons: (1) I expect the recommendations that come
out of SIPBRANDY to require non-trivial endpoint changes, and it would
be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue
is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to the "Object= ives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ensuring
recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solution to this
problem will be ICE, or that it even is required in order for the WG to
declare success. I just want it to be available for consideration.

/a

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

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

--_000_SN1PR0301MB15517B8E9491A8783FE71D3CB25D0SN1PR0301MB1551_-- From nobody Wed Jun 8 08:11:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0E6012D9CD for ; Wed, 8 Jun 2016 08:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 c4fl-pusXxgQ for ; Wed, 8 Jun 2016 08:11:42 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC24E12D9C8 for ; Wed, 8 Jun 2016 08:11:42 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58FBfwf073397 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 10:11:42 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Asveren, Tolga" Date: Wed, 08 Jun 2016 10:11:46 -0500 Message-ID: <3C6056AB-A640-418C-A871-F6F5308B6AEF@nostrum.com> In-Reply-To: References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_C9AC168B-7DEA-4643-8818-A2838DF00C1F_=" X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 15:11:45 -0000 --=_MailMate_C9AC168B-7DEA-4643-8818-A2838DF00C1F_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable On 7 Jun 2016, at 1:42, Asveren, Tolga wrote: > FWIW, I would like to say that I concur with your statement "I'd be = > happy if we just solved e2e confidentiality. And I don't think we = > would be happy if we solved all the other things and not e2e = > confidentiality." And hope that other targets won't jeopardize = > reaching the main goal. I have hopes that the mention of that work having priority, along with = the chair and AD attention, will mitigate that risk. Ben. > > Thanks, > Tolga > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben = > Campbell > Sent: Monday, June 06, 2016 4:27 PM > To: dispatch@ietf.org > Subject: Re: [dispatch] SIPBRANDY and other dangers > > > The most recent proposed text is at = > https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . > > Ben. > > On 6 Jun 2016, at 15:25, Ben Campbell wrote: > > Since no one complained, and a few people expressed support directly = > to me offline, I added that text to the proposed charter, along with = > adding RTCWEB to the list of groups in the "expected to coordinate = > with" paragraph. > > I will put this on the agenda for internal review on the next IESG = > telechat. That should not shut down discussion, so if people have = > further thoughts, please comment as soon as possible. > > Thanks! > > Ben. > > On 26 May 2016, at 19:55, Ben Campbell wrote: > > Hi Jon, > > As an individual, I'm afraid the association of this effort with other = > great unsolved problems (Great Unsolved Theories?) may be prophetic. = > (Also, the implied acronym :-) ) I'd be happy if we just solved e2e = > confidentiality. And I don't think we would be happy if we solved all = > the other things and not e2e confidentiality. > > It also seems to me that aligning identity models fits more with STIR = > than with this group. > > That being said, what about something like the following: > > "While confidentiality is the first priority of the working group, it = > may work on aligning these practices with WebRTC, for example by = > defining best practices for ensuring recipients of media flows have = > consented to receive such flows, in order to prevent or mitigate the = > denial-of-service attack described in RFC 5245, section 18.5.1." > > Ben. > > On 26 May 2016, at 19:05, Peterson, Jon wrote: > > It would be a fairly significant change to the proposed scope, but = > perhaps > one that's warranted. > > I understand why you have some process caution here about scoping a > consent mechanism to ICE at the outset, but if we're going to put this > problem under SIPPRANDY's umbrella, I think it could make sense to set = > the > explicit goal of getting a "grand unified theory" of VoIP security = > that > would align the security of SIP and WebRTC. As we all know, WebRTC = > went > down many of the paths that it did for the sake of backwards = > compatibility > with SIP, and it would be a shame if the effort to interwork the two > proved futile because of lack of e2e SRTP. Consent would be another = > prong > of that. So maybe writing ICE in as a foregone conclusion in the = > service > of that goal would let us skip some unnecessary deliberation. Getting > plausible interworking with WebRTC could also provide some further > incentive for implementers to crack open their SIP implementations. > > If a "grand unified theory" is the goal, then this also conforms = > nicely > with Cullen's recent efforts to figure out how to get STIR and = > WebRTC's > IdP aligned. As my strawman proposal for SIP media confidentiality had > both a STIR story and an opportunistic story, we could argue that = > getting > alignment of identity, consent, and encryption could be grouped under = > one > effort, which is mostly about getting offer/answer to deal with those > three things in a common way - especially as WebRTC IdP today conveys = > that > identity information as an SDP attribute. > > Realigning Offers[/Answers]: The Grand Unified Theory? > > Jon Peterson > Neustar, Inc. > > On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > adam@nostrum.com> = > wrote: > > As early as 2005, we identified a class of DoS attack that would be > enabled by SIP systems, if widely deployed on the public internet. > Called the "Voice Hammer," this attack involves triggering potentially > vast quantities of media traffic towards a target using normal SIP = > call > setup procedures. > > While I don't think this is something that SIPBRANDY is required to > address, I would like it to be part of the discussion. I believe this > makes sense for two reasons: (1) I expect the recommendations that = > come > out of SIPBRANDY to require non-trivial endpoint changes, and it would > be good to consider coupling breaking changes to each other so as to > minimize the number of potential modes of operation; and (2) the issue > is fundamentally a security issue -- albeit of a different nature -- > which would seem to require the same set of expertise as the other > problems SIPBRANDY will work on. > > To that end, I propose adding the following sentence to the = > "Objectives" > paragraph in the SIPBRANDY charter: > > "The working group may also define best practices for ensuring > recipients of media flows have consented to receive such flows, in = > order > to prevent or mitigate the denial-of-service attack described in RFC > 5245, section 18.5.1." > > To be clear: I do not wish to presuppose that the solution to this > problem will be ICE, or that it even is required in order for the WG = > to > declare success. I just want it to be available for consideration. > > /a > > ________________________________ > > 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 > > ________________________________ > > 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_C9AC168B-7DEA-4643-8818-A2838DF00C1F_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 7 Jun 2016, at 1:42, Asveren, Tolga wrote:

FWIW, I would like to say that I concur with your stateme= nt "I'd be happy if we just solved e2e confidentiality. And I don't think= we would be happy if we solved all the other things and not e2e confiden= tiality." And hope that other targets won't jeopardize reaching the main = goal.

I have hopes that the mention of that work having priorit= y, along with the chair and AD attention, will mitigate that risk.

Ben.

Thanks,
Tolga

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: Monday, June 06, 2016 4:27 PM
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

The most recent proposed text is at https://datatracker.ietf.= org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed suppo= rt directly to me offline, I added that text to the proposed charter, alo= ng with adding RTCWEB to the list of groups in the "expected to coordinat= e with" paragraph.

I will put this on the agenda for internal review on the = next IESG telechat. That should not shut down discussion, so if people ha= ve further thoughts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effo= rt with other great unsolved problems (Great Unsolved Theories?) may be p= rophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved= e2e confidentiality. And I don't think we would be happy if we solved al= l the other things and not e2e confidentiality.

It also seems to me that aligning identity models fits mo= re with STIR than with this group.

That being said, what about something like the following:=

"While confidentiality is the first priority of the worki= ng group, it may work on aligning these practices with WebRTC, for exampl= e by defining best practices for ensuring recipients of media flows have = consented to receive such flows, in order to prevent or mitigate the deni= al-of-service attack described in RFC 5245, section 18.5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed s= cope, but perhaps
one that's warranted.

I understand why you have some process caution here about= scoping a
consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set th= e
explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibilit= y
with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong=
of that. So maybe writing ICE in as a foregone conclusion in the service<= br> of that goal would let us skip some unnecessary deliberation. Getting
= plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also c= onforms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting=
alignment of identity, consent, and encryption could be grouped under one=
effort, which is mostly about getting offer/answer to deal with those
= three things in a common way - especially as WebRTC IdP today conveys tha= t
identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" <dispatch-bounces@ietf.org on behalf of adam@nostrum.com<mailto:dis= patch-bounces@ietf.org%20on%20behalf%20of%20adam@nostrum.com>> wrot= e:

As early as 2005, we identified a class of DoS attack tha= t would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures.

While I don't think this is something that SIPBRANDY is r= equired to
address, I would like it to be part of the discussion. I believe this
= makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to t= he "Objectives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ens= uring
recipients of media flows have consented to receive such flows, in order<= br> to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solutio= n to this
problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration.

/a

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

--=_MailMate_C9AC168B-7DEA-4643-8818-A2838DF00C1F_=-- From nobody Wed Jun 8 10:00:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1962412D7AF for ; Wed, 8 Jun 2016 10:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 UyIAMtHLMD8C for ; Wed, 8 Jun 2016 10:00:23 -0700 (PDT) Received: from smtp96.iad3a.emailsrvr.com (smtp96.iad3a.emailsrvr.com [173.203.187.96]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0BCD12D764 for ; Wed, 8 Jun 2016 10:00:14 -0700 (PDT) Received: from smtp5.relay.iad3a.emailsrvr.com (localhost.localdomain [127.0.0.1]) by smtp5.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id F41CF80225 for ; Wed, 8 Jun 2016 13:00:13 -0400 (EDT) X-Auth-ID: fluffy@iii.ca Received: by smtp5.relay.iad3a.emailsrvr.com (Authenticated sender: fluffy-AT-iii.ca) with ESMTPSA id 6D83A800D8 for ; Wed, 8 Jun 2016 13:00:13 -0400 (EDT) X-Sender-Id: fluffy@iii.ca Received: from [192.168.4.100] ([UNAVAILABLE]. [128.107.241.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA) by 0.0.0.0:465 (trex/5.5.4); Wed, 08 Jun 2016 13:00:13 -0400 From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Wed, 8 Jun 2016 11:00:16 -0600 References: <20160607143317.13664.96093.idtracker@ietfa.amsl.com> To: DISPATCH list Message-Id: Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) Archived-At: Subject: [dispatch] Fwd: NomCom 2016-2017 Second Call for Volunteers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 17:00:25 -0000 Please consider volunteering. > Begin forwarded message: >=20 > From: NomCom Chair 2016 > Subject: NomCom 2016-2017 Second Call for Volunteers > Date: June 7, 2016 at 8:33:17 AM MDT > To: "IETF Announcement List" > Reply-To: ietf@ietf.org >=20 > Subject: NomCom 2016-2017 Second Call for Volunteers >=20 > The IETF nomcom appoints individuals to fill the open slots on the = IAOC,=20 > the IAB, and the IESG. >=20 > Ten voting members for the nomcom are selected in a verifiably random = way > from a pool of volunteers. The more volunteers, the better chance we = have of > choosing a random yet representative cross section of the IETF = population. >=20 > The details of the operation of the nomcom can be found in RFC 7437, = and > BCP10/RFC3797 details the selection algorithm. >=20 > Volunteers must have attended 3 of the past 5 IETF meetings. As = specified > in RFC 7437, that means three out of the five past meetings up to the = time > this email announcement goes out to start the solicitation of = volunteers. > The five meetings out of which you must have attended *three* are: >=20 > IETF =3D 91 (Honolulu) \ > 92 (Dallas) \ > 93 (Prague) -*** ANY THREE! > 94 (Yokohama) / > 95 (Buenos Aires) / >=20 >=20 > If you qualify, please volunteer. Before you decide to volunteer, = please > remember that anyone appointed to this Nomcom will not be considered = as a > candidate for any of the positions that the 2016 - 2017 Nomcom is > responsible for filling. >=20 > The list of people and posts whose terms end with the March 2017 IETF > meeting, and thus the positions for which this nomcom is responsible, = are >=20 > IAOC: >=20 > Lou Berger >=20 > IAB: >=20 > Ralph Droms* > Russ Housley* > Robert Sparks > Andrew Sullivan > Dave Thaler > Suzanne Woolf >=20 > IESG: >=20 > Jari Arkko (GEN) > Deborah Brungard (RTG) > Ben Campbell (ART) > Spencer Dawkins (TSV) > Stephen Farrell (SEC)* > Joel Jaeggli (OPS)* > Terry Manderson (INT) > Alvaro Retana (RTG) >=20 >=20 > All appointments are for 2 years. The ART and Routing areas have 3 ADs = and > the General area has 1; all other areas have 2 ADs. Thus, all areas = (with > the exception of GEN) have at least one continuing AD. Current members > tagged with a * have indicated that they will not accept another = nomination > to serve in their current role. >=20 > The primary activity for this nomcom will begin in July 2016 and = should be > completed in January 2017. The nomcom will have regularly scheduled > conference calls to ensure progress. There will be activities to = collect > requirements from the community, review candidate questionnaires, = review > feedback from community members about candidates, and talk to = candidates. >=20 > While being a nomcom member does require some time commitment it is = also a > very rewarding experience. >=20 > As a member of the nomcom it is very important that you be able to = attend > IETF97 (Seoul) to conduct interviews. Being at IETF96 (Berlin) is = useful for > orientation. Being at IETF98 is not essential. >=20 > Please volunteer by sending me an email before 23:59 UTC June 20, = 2016, as > follows: >=20 > To: nomcom-chair-2016@ietf.org > Subject: Nomcom 2016-17 Volunteer >=20 > Please include the following information in the email body: >=20 > Your Full Name: __________ > // as you write it on the IETF registration form > Current Primary Affiliation: > // Typically what goes in the Company field > // in the IETF Registration Form > Emails: _______________ > // All email addresses used to register for the past 5 IETF meetings > // Preferred email address first > Telephone: _______________________ > // For confirmation if selected >=20 > You should expect an email response from me within 5 business days = stating > whether or not you are qualified. If you don't receive this response, > please re-send your email with the tag "RESEND"" added to the subject = line. >=20 > If you are not yet sure if you would like to volunteer, please = consider that > nomcom members play a very important role in shaping the leadership of = the > IETF. Questions by email or voice are welcome. Volunteering for the = nomcom > is a great way to contribute to the IETF! >=20 > You can find a detailed timeline on the nomcom web site at: >=20 > https://datatracker.ietf.org/nomcom/2016/ >=20 > I will be publishing details of the randomness seeds to be used for = the=20 > RFC 3797 selection process within the next few weeks. >=20 > Thank you! >=20 > Lucy Lynch > llynch@civil-tongue.net > nomcom-chair-2016@ietf.org >=20 From nobody Wed Jun 8 13:07:59 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3CC012D7E0 for ; Wed, 8 Jun 2016 13:07:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 2V16BjSg1nZa for ; Wed, 8 Jun 2016 13:07:55 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D991312D7DD for ; Wed, 8 Jun 2016 13:07:54 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58K7sLq098667 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Wed, 8 Jun 2016 15:07:54 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "dispatch@ietf.org" Date: Wed, 08 Jun 2016 15:07:59 -0500 Message-ID: In-Reply-To: References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_9A89B289-03C6-40CA-AC8F-DFBF63DF7EBC_=" X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:07:58 -0000 --=_MailMate_9A89B289-03C6-40CA-AC8F-DFBF63DF7EBC_= Content-Type: text/plain; format=flowed; markup=markdown I just made a minor update to say that SIPBRANDY may consider compatibility with aspects of PERC, and added PERC to the collaboration list. This is in response to some offline comments. I invite comments (still to dispatch) about whether we should include that addition, or if we need any stronger requirements in that area. Thanks! Ben. On 6 Jun 2016, at 15:27, Ben Campbell wrote: > The most recent proposed text is at > https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . > > Ben. > > On 6 Jun 2016, at 15:25, Ben Campbell wrote: > >> Since no one complained, and a few people expressed support directly >> to me offline, I added that text to the proposed charter, along with >> adding RTCWEB to the list of groups in the "expected to coordinate >> with" paragraph. >> >> I will put this on the agenda for internal review on the next IESG >> telechat. That should not shut down discussion, so if people have >> further thoughts, please comment as soon as possible. >> >> Thanks! >> >> Ben. >> >> On 26 May 2016, at 19:55, Ben Campbell wrote: >> >>> Hi Jon, >>> >>> As an individual, I'm afraid the association of this effort with >>> other great unsolved problems (Great Unsolved Theories?) may be >>> prophetic. (Also, the implied acronym :-) ) I'd be happy if we just >>> solved e2e confidentiality. And I don't think we would be happy if >>> we solved all the other things and _not_ e2e confidentiality. >>> >>> It also seems to me that aligning identity models fits more with >>> STIR than with this group. >>> >>> That being said, what about something like the following: >>> >>> "While confidentiality is the first priority of the working group, >>> it may work on aligning these practices with WebRTC, for example by >>> defining best practices for ensuring recipients of media flows have >>> consented to receive such flows, in order to prevent or mitigate the >>> denial-of-service attack described in RFC 5245, section 18.5.1." >>> >>> Ben. >>> >>> On 26 May 2016, at 19:05, Peterson, Jon wrote: >>> >>>> It would be a fairly significant change to the proposed scope, but >>>> perhaps >>>> one that's warranted. >>>> >>>> I understand why you have some process caution here about scoping a >>>> consent mechanism to ICE at the outset, but if we're going to put >>>> this >>>> problem under SIPPRANDY's umbrella, I think it could make sense to >>>> set the >>>> explicit goal of getting a "grand unified theory" of VoIP security >>>> that >>>> would align the security of SIP and WebRTC. As we all know, WebRTC >>>> went >>>> down many of the paths that it did for the sake of backwards >>>> compatibility >>>> with SIP, and it would be a shame if the effort to interwork the >>>> two >>>> proved futile because of lack of e2e SRTP. Consent would be another >>>> prong >>>> of that. So maybe writing ICE in as a foregone conclusion in the >>>> service >>>> of that goal would let us skip some unnecessary deliberation. >>>> Getting >>>> plausible interworking with WebRTC could also provide some further >>>> incentive for implementers to crack open their SIP implementations. >>>> >>>> If a "grand unified theory" is the goal, then this also conforms >>>> nicely >>>> with Cullen's recent efforts to figure out how to get STIR and >>>> WebRTC's >>>> IdP aligned. As my strawman proposal for SIP media confidentiality >>>> had >>>> both a STIR story and an opportunistic story, we could argue that >>>> getting >>>> alignment of identity, consent, and encryption could be grouped >>>> under one >>>> effort, which is mostly about getting offer/answer to deal with >>>> those >>>> three things in a common way - especially as WebRTC IdP today >>>> conveys that >>>> identity information as an SDP attribute. >>>> >>>> Realigning Offers[/Answers]: The Grand Unified Theory? >>>> >>>> Jon Peterson >>>> Neustar, Inc. >>>> >>>> On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" >>>> wrote: >>>> >>>>> As early as 2005, we identified a class of DoS attack that would >>>>> be >>>>> enabled by SIP systems, if widely deployed on the public internet. >>>>> Called the "Voice Hammer," this attack involves triggering >>>>> potentially >>>>> vast quantities of media traffic towards a target using normal SIP >>>>> call >>>>> setup procedures. >>>>> >>>>> While I don't think this is something that SIPBRANDY is required >>>>> to >>>>> address, I would like it to be part of the discussion. I believe >>>>> this >>>>> makes sense for two reasons: (1) I expect the recommendations that >>>>> come >>>>> out of SIPBRANDY to require non-trivial endpoint changes, and it >>>>> would >>>>> be good to consider coupling breaking changes to each other so as >>>>> to >>>>> minimize the number of potential modes of operation; and (2) the >>>>> issue >>>>> is fundamentally a security issue -- albeit of a different nature >>>>> -- >>>>> which would seem to require the same set of expertise as the other >>>>> problems SIPBRANDY will work on. >>>>> >>>>> To that end, I propose adding the following sentence to the >>>>> "Objectives" >>>>> paragraph in the SIPBRANDY charter: >>>>> >>>>> "The working group may also define best practices for ensuring >>>>> recipients of media flows have consented to receive such flows, in >>>>> order >>>>> to prevent or mitigate the denial-of-service attack described in >>>>> RFC >>>>> 5245, section 18.5.1." >>>>> >>>>> To be clear: I do not wish to presuppose that the solution to this >>>>> problem will be ICE, or that it even is required in order for the >>>>> WG to >>>>> declare success. I just want it to be available for consideration. >>>>> >>>>> /a >>>>> >>>>> _______________________________________________ >>>>> 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 >>> >>> _______________________________________________ >>> 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 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_9A89B289-03C6-40CA-AC8F-DFBF63DF7EBC_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

I just made a minor update to say that SIPBRANDY may cons= ider compatibility with aspects of PERC, and added PERC to the collaborat= ion list. This is in response to some offline comments.

I invite comments (still to dispatch) about whether we sh= ould include that addition, or if we need any stronger requirements in th= at area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

The most recent proposed text is at https://datatracker.ietf.= org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed suppo= rt directly to me offline, I added that text to the proposed charter, alo= ng with adding RTCWEB to the list of groups in the "expected to coordinat= e with" paragraph.

I will put this on the agenda for internal review on the = next IESG telechat. That should not shut down discussion, so if people ha= ve further thoughts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effo= rt with other great unsolved problems (Great Unsolved Theories?) may be p= rophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved= e2e confidentiality. And I don't think we would be happy if we solved al= l the other things and not e2e confidentiality.

It also seems to me that aligning identity models fits mo= re with STIR than with this group.

That being said, what about something like the following:=

"While confidentiality is the first priority of the worki= ng group, it may work on aligning these practices with WebRTC, for exampl= e by defining best practices for ensuring recipients of media flows have = consented to receive such flows, in order to prevent or mitigate the deni= al-of-service attack described in RFC 5245, section 18.5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed s= cope, but perhaps
one that's warranted.

I understand why you have some process caution here about= scoping a
consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set th= e
explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibilit= y
with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong=
of that. So maybe writing ICE in as a foregone conclusion in the service<= br> of that goal would let us skip some unnecessary deliberation. Getting
= plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also c= onforms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting=
alignment of identity, consent, and encryption could be grouped under one=
effort, which is mostly about getting offer/answer to deal with those
= three things in a common way - especially as WebRTC IdP today conveys tha= t
identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" <dispatch-bounces@ietf.org on behalf of adam@nostrum.com> wrote:

As early as 2005, we identified a class of DoS attack tha= t would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures.

While I don't think this is something that SIPBRANDY is r= equired to
address, I would like it to be part of the discussion. I believe this
= makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to t= he "Objectives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ens= uring
recipients of media flows have consented to receive such flows, in order<= br> to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solutio= n to this
problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration.

/a

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

--=_MailMate_9A89B289-03C6-40CA-AC8F-DFBF63DF7EBC_=-- From nobody Wed Jun 8 13:14:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA33612D739 for ; Wed, 8 Jun 2016 13:14:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 jvpDsOTYB4Ia for ; Wed, 8 Jun 2016 13:14:51 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE4412D53A for ; Wed, 8 Jun 2016 13:14:50 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-6f-57587cb8444e Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id BB.E7.12516.8BC78575; Wed, 8 Jun 2016 22:14:48 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC005.ericsson.se ([153.88.183.33]) with mapi id 14.03.0294.000; Wed, 8 Jun 2016 22:14:47 +0200 From: Christer Holmberg To: Ben Campbell , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRwcF0BunBBKhwwEuBy+zhpHNiUZ/gAOGg Date: Wed, 8 Jun 2016 20:14:47 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804432C@ESESSMB209.ericsson.se> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3804432CESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOIsWRmVeSWpSXmKPExsUyM2K7ou6Omohwg63NWhbzO0+zWyydtIDV gcljyZKfTB6zdj5hCWCK4rJJSc3JLEst0rdL4Mp4cnsmW8GVaYwV+9b9YW9gPNnI2MXIySEh YCJx+ux6FghbTOLCvfVsXYxcHEICRxgl/mzvgHIWM0qsWNnA3sXIwcEmYCHR/U8bpEFEwFti /rYPYM3CAsYSPxqOMkLETSSaLjUxQdhGEkum7WMGsVkEVCS+HpnGCmLzCvhKbNwN0gsyfz+T xKeHB8EGcQrYS7RfnsoOYjMCXfT91BqwQcwC4hK3nsxngrhUQGLJnvPMELaoxMvH/1ghbCWJ tYe3s0DU50us3rSKCWKZoMTJmU9YJjCKzEIyahaSsllIyiDiOhILdn9ig7C1JZYtfM0MY585 8JgJWXwBI/sqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMDoOrjlt+4OxtWvHQ8xCnAwKvHw PnAODxdiTSwrrsw9xCjBwawkwhtUFREuxJuSWFmVWpQfX1Sak1p8iFGag0VJnNf/pWK4kEB6 YklqdmpqQWoRTJaJg1OqgbFy3VSZI2qLChM2FLff0r5gsotl3vsN9/ZNeWThl9D1Moh/w+We dhdlxgkxbifybm1lynLTaY3mvSBTMs3jxYynu842BCQcvFcxc9nlfA2P06f3PT+XfO3HmqN3 d+jO+LrA/HOAeph58ZVUDu4Pl57Mk9+x9UdG459XW1ZVGUssuBqles10MqeQEktxRqKhFnNR cSIAMOupi6oCAAA= Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:14:54 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3804432CESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Since intermediaries are listed as one problem for achieving end-to-end SRT= P, would it be useful to reference RFC 7879 as one input for the work? Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 08 June 2016 23:08 To: dispatch@ietf.org Subject: Re: [dispatch] SIPBRANDY and other dangers I just made a minor update to say that SIPBRANDY may consider compatibility= with aspects of PERC, and added PERC to the collaboration list. This is in= response to some offline comments. I invite comments (still to dispatch) about whether we should include that = addition, or if we need any stronger requirements in that area. Thanks! Ben. On 6 Jun 2016, at 15:27, Ben Campbell wrote: The most recent proposed text is at https://datatracker.ietf.org/doc/charte= r-ietf-sipbrandy/ . Ben. On 6 Jun 2016, at 15:25, Ben Campbell wrote: Since no one complained, and a few people expressed support directly to me = offline, I added that text to the proposed charter, along with adding RTCWE= B to the list of groups in the "expected to coordinate with" paragraph. I will put this on the agenda for internal review on the next IESG telechat= . That should not shut down discussion, so if people have further thoughts,= please comment as soon as possible. Thanks! Ben. On 26 May 2016, at 19:55, Ben Campbell wrote: Hi Jon, As an individual, I'm afraid the association of this effort with other grea= t unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the= implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. = And I don't think we would be happy if we solved all the other things and n= ot e2e confidentiality. It also seems to me that aligning identity models fits more with STIR than = with this group. That being said, what about something like the following: "While confidentiality is the first priority of the working group, it may w= ork on aligning these practices with WebRTC, for example by defining best p= ractices for ensuring recipients of media flows have consented to receive s= uch flows, in order to prevent or mitigate the denial-of-service attack des= cribed in RFC 5245, section 18.5.1." Ben. On 26 May 2016, at 19:05, Peterson, Jon wrote: It would be a fairly significant change to the proposed scope, but perhaps one that's warranted. I understand why you have some process caution here about scoping a consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set the explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibility with SIP, and it would be a shame if the effort to interwork the two proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting plausible interworking with WebRTC could also provide some further incentive for implementers to crack open their SIP implementations. If a "grand unified theory" is the goal, then this also conforms nicely with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those three things in a common way - especially as WebRTC IdP today conveys that identity information as an SDP attribute. Realigning Offers[/Answers]: The Grand Unified Theory? Jon Peterson Neustar, Inc. On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > wrote: As early as 2005, we identified a class of DoS attack that would be enabled by SIP systems, if widely deployed on the public internet. Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures. While I don't think this is something that SIPBRANDY is required to address, I would like it to be part of the discussion. I believe this makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature -- which would seem to require the same set of expertise as the other problems SIPBRANDY will work on. To that end, I propose adding the following sentence to the "Objectives" paragraph in the SIPBRANDY charter: "The working group may also define best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." To be clear: I do not wish to presuppose that the solution to this problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration. /a ________________________________ 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 ________________________________ 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 ________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_7594FB04B1934943A5C02806D1A2204B3804432CESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Since inte= rmediaries are listed as one problem for achieving end-to-end SRTP, would i= t be useful to reference RFC 7879 as one input for the work?

 = ;

Regards,

 = ;

Christer

 

From: = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 08 June 2016 23:08
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

 

I just made a minor update to say that SIPBRANDY may consider compatibil= ity with aspects of PERC, and added PERC to the collaboration list. This is= in response to some offline comments.

I invite comments (still to dispatch) about whether we should include th= at addition, or if we need any stronger requirements in that area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed support directly to = me offline, I added that text to the proposed charter, along with adding RT= CWEB to the list of groups in the "expected to coordinate with" p= aragraph.

I will put this on the agenda for internal review on the next IESG telec= hat. That should not shut down discussion, so if people have further though= ts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effort with other g= reat unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, = the implied acronym :-) ) I'd be happy if we just solved e2e confidentialit= y. And I don't think we would be happy if we solved all the other things and not e2e confidentiali= ty.

It also seems to me that aligning identity models fits more with STIR th= an with this group.

That being said, what about something like the following:

"While confidentiality is the first priority of the working group, = it may work on aligning these practices with WebRTC, for example by definin= g best practices for ensuring recipients of media flows have consented to r= eceive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18= .5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed scope, but perha= ps
one that's warranted.

I understand why you have some process caution here about scoping a
consent mechanism to ICE at the outset, but if we're going to put this
problem under SIPPRANDY's umbrella, I think it could make sense to set the<= br> explicit goal of getting a "grand unified theory" of VoIP securit= y that
would align the security of SIP and WebRTC. As we all know, WebRTC went
down many of the paths that it did for the sake of backwards compatibility<= br> with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting
plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also confor= ms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's
IdP aligned. As my strawman proposal for SIP media confidentiality had
both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those
three things in a common way - especially as WebRTC IdP today conveys that<= br> identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<dispatch-bounces@ietf.org on behalf of adam@nostrum.com>= wrote:

As early as 2005, we identified a class of DoS attack that would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potent= ially
vast quantities of media traffic towards a target using normal SIP call
setup procedures.

While I don't think this is something that SIPBRANDY is required to
address, I would like it to be part of the discussion. I believe this
makes sense for two reasons: (1) I expect the recommendations that come
out of SIPBRANDY to require non-trivial endpoint changes, and it would
be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue
is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to the "Object= ives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ensuring
recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solution to this
problem will be ICE, or that it even is required in order for the WG to
declare success. I just want it to be available for consideration.

/a

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

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

dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_7594FB04B1934943A5C02806D1A2204B3804432CESESSMB209erics_-- From nobody Wed Jun 8 13:25:49 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D14F12D0BD for ; Wed, 8 Jun 2016 13:25:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 1HtcXPfvH5cW for ; Wed, 8 Jun 2016 13:25:46 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14A4F12B00C for ; Wed, 8 Jun 2016 13:25:46 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u58KPff0000384 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Jun 2016 15:25:41 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Christer Holmberg" Date: Wed, 08 Jun 2016 15:25:46 -0500 Message-ID: <7AD1F7BA-4F56-44FA-AD0C-DD58B70223A4@nostrum.com> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B3804432C@ESESSMB209.ericsson.se> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B3804432C@ESESSMB209.ericsson.se> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_4E2CACD5-B091-4B59-86D9-AD6F6B0A815C_=" Content-Transfer-Encoding: 8bit X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:25:47 -0000 --=_MailMate_4E2CACD5-B091-4B59-86D9-AD6F6B0A815C_= Content-Type: text/plain; charset=utf-8; format=flowed; markup=markdown Content-Transfer-Encoding: 8bit On 8 Jun 2016, at 15:14, Christer Holmberg wrote: > Hi, >   > Since intermediaries are listed as one problem for achieving > end-to-end SRTP, would it be useful to reference RFC 7879 as one input > for the work? >   I am of a mixed mind on that, since RFC 7879 mainly gives guidance to b2bua implementers on how not to break things. OTOH, it may make sense for SIPBRANDY to make assumptions about intermediaries adhering to that guidance. Also, not specifically mentioning an RFC doesn't _prevent_ the working group from thinking about it if it makes sense. Does anyone else have thought on this? Thanks! Ben. --=_MailMate_4E2CACD5-B091-4B59-86D9-AD6F6B0A815C_= Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

On 8 Jun 2016, at 15:14, Christer Holmberg wrote:

Hi,
=C2=A0
Since intermediaries are listed as one problem for achieving end-to-end S= RTP, would it be useful to reference RFC 7879 as one input for the work?<= br> =C2=A0

I am of a mixed mind on that, since RFC 7879 mainly gives= guidance to b2bua implementers on how not to break things. OTOH, it may = make sense for SIPBRANDY to make assumptions about intermediaries adherin= g to that guidance.

Also, not specifically mentioning an RFC doesn't prev= ent the working group from thinking about it if it makes sense.

Does anyone else have thought on this?

Thanks!

Ben.

--=_MailMate_4E2CACD5-B091-4B59-86D9-AD6F6B0A815C_=-- From nobody Wed Jun 8 13:28:42 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CDA912B00C for ; Wed, 8 Jun 2016 13:28:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 5aYdPwUwdqqQ for ; Wed, 8 Jun 2016 13:28:37 -0700 (PDT) Received: from forward4m.cmail.yandex.net (forward4m.cmail.yandex.net [IPv6:2a02:6b8:b030::1b]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B468012B063 for ; Wed, 8 Jun 2016 13:28:36 -0700 (PDT) Received: from mxback3m.mail.yandex.net (mxback3m.mail.yandex.net [37.140.138.63]) by forward4m.cmail.yandex.net (Yandex) with ESMTP id D8D14213D5; Wed, 8 Jun 2016 23:28:33 +0300 (MSK) Received: from web30m.yandex.ru (web30m.yandex.ru [37.140.138.121]) by mxback3m.mail.yandex.net (nwsmtp/Yandex) with ESMTP id OjiYYCWWv1-SWZ0rD6u; Wed, 08 Jun 2016 23:28:32 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1465417712; bh=xssPpjKN0GeWm65XmZgCuuVGFh21RwLitypkeYmh/Wk=; h=X-Yandex-Sender-Uid:From:To:Cc:In-Reply-To:References:Subject: MIME-Version:Message-Id:X-Mailer:Date:Content-Transfer-Encoding: Content-Type; b=vbwYveCokfr/+LpaTZmN8lEgt8HMpiRoyM6iL9H958Q+VSYk85Hexwul75AJPgPCm r5i9bOCrpiliL640w3dTT1RYLWkLAZkQuKKLT/ya6wHmjUO7JIR5V1cCwaSxZUiFxl o7XXMD+SWYOaGFVlbopxT7b7fMEArzvf8f8LQ4Lk= Authentication-Results: mxback3m.mail.yandex.net; dkim=pass header.i=@yandex.ru X-Yandex-Suid-Status: 1 0,1 0,1 0,1 492863893 X-Yandex-Sender-Uid: 161206619 Received: by web30m.yandex.ru with HTTP; Wed, 08 Jun 2016 23:28:32 +0300 From: =?utf-8?B?0KLQstC10YDQtdGC0LjQvSDQkNC90YLQvtC9INCh0LXRgNCz0LXQtdCy0LjRhw==?= To: Adam Roach , Adrian Hope-Bailie In-Reply-To: <19db51ff-72ca-6769-22ca-3daf768b3fb7@nostrum.com> References: <1127651464816168@web30h.yandex.ru> <19db51ff-72ca-6769-22ca-3daf768b3fb7@nostrum.com> MIME-Version: 1.0 Message-Id: <567581465417712@web30m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 09 Jun 2016 01:28:32 +0500 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 20:28:40 -0000 Surely, I refer to the Payment WG at W3C. I did not know about efforts here. But ISPP charter reminds me of a problem. There is good software to manage business accounts (based on digital signatures), but not for non-business accounts, and something strange for e-money. But in practice, there could be no difference between B2B and B2C. When I pay to my ISP, this is B2B payment if I use the Net for business, or B2C if I do not. But the amount is the same, really nothing changes. So "retail payments" is a non-existing problem. Possibly this is the reason why ISPP could not produce anything. I publish NGMTP specs at . Currently, only "account chain" is there. Possibly, we should discuss some decisions in Q&A format. 02.06.2016, 20:59, "Adam Roach" : >  On 6/2/16 09:16, Adrian Hope-Bailie wrote: >>   I wasn't aware of a Payments WG at IETF or of NGMTP. >>   Can you provide a link to some resources or a mailing list archive so >>   i can get myself up to speed? > >  I'm not sure offhand which Working Group Anton is referring to. As far >  as I'm able to turn up, there have only been two working groups in the >  IETF's history that dealt squarely with payment-related technologies: > >  The ISPP (Internet Secure Payments Protocol) WG concluded in January of >  1997. The charter at its time of conclusion is here: >  https://datatracker.ietf.org/wg/ispp/charter/ > >  The TRADE (Internet Open Trading Protocols) concluded in Feburary of >  2005. The charter at its time of conclusion is here: >  https://datatracker.ietf.org/wg/trade/charter/ > >  Both working groups predate any centrally-coordinated mailing list >  archiving by the IETF, and the archives of their mailing list >  discussions no longer appear to be online. They also date back to a >  period of time in which internet drafts were aggressively removed from >  the internet after their six-month expiration period, so tracing their >  work output to the generated RFCs is not terribly straightforward. > >  TRADE's main output relic appears to be the Internet Open Trading >  Protocol (IOTP), documented in RFCs 2801 - 2803, and RFC 3504. There >  appears to have been an effort started to define a v2 of the protocol, >  but that work does not appear to have borne fruit. See also >  . > >  I can't figure out whether ISPP produced any RFCs at all. > >  /a From nobody Wed Jun 8 15:14:21 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3308312D0AB for ; Wed, 8 Jun 2016 15:14:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.72 X-Spam-Level: X-Spam-Status: No, score=-2.72 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cooperw.in header.b=ah0faeYt; dkim=pass (1024-bit key) header.d=messagingengine.com header.b=jXAHKRNz 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 Py3MCMXFr2ER for ; Wed, 8 Jun 2016 15:14:18 -0700 (PDT) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9B5C12D0A7 for ; Wed, 8 Jun 2016 15:14:18 -0700 (PDT) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 1962E20988; Wed, 8 Jun 2016 18:14:18 -0400 (EDT) Received: from frontend1 ([10.202.2.160]) by compute7.internal (MEProxy); Wed, 08 Jun 2016 18:14:18 -0400 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-type:date:from:in-reply-to:message-id:mime-version :references:subject:to:x-sasl-enc:x-sasl-enc; s=mesmtp; bh=MiinX HE5DDbarqHY+dMuzPzKClE=; b=ah0faeYt++YiVAAapWwbcMF9waqTDxLbYwqbC vtUHaTptSgbTQ37cBmKU1LuunFH6s5+i0gR7BjOnZspFCq56zto2QWpIbQPLQw92 2P8O0y0jy5/v/RLMLdQR8WUAH8senY7Emqg2iMFikay9mGaP/8tF5F9n2taKkciB SuCil4= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=smtpout; bh=MiinXHE5DDbarqHY+dMuzPzKClE=; b=jXAHK RNzXZ6AAwVzNQ0JRDybFU+kQ+yRhHbCK/ZXcI03CrOb2zrQsuL0KXTVhQejhsPqn bS0yK5/WWlzxfVMGWUTncby1iPiouTl7FvXlrj5A4yJl7/PV/ExAucAYsKr+tWh2 vEEu4Z80RBRlTn5DOz2lUwdJKKbdi9iDSCSUrM= X-Sasl-enc: FVF3c+xOPVQC2KPX8DmjV6C6cB1Aq4nv2t235bU4I/Jl 1465424057 Received: from dhcp-171-68-20-12.cisco.com (dhcp-171-68-20-12.cisco.com [171.68.20.12]) by mail.messagingengine.com (Postfix) with ESMTPA id 68B01F29FB; Wed, 8 Jun 2016 18:14:17 -0400 (EDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_AB32391C-14BB-45D1-8E3D-3E9FBFF68727" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Alissa Cooper In-Reply-To: <7AD1F7BA-4F56-44FA-AD0C-DD58B70223A4@nostrum.com> Date: Wed, 8 Jun 2016 15:14:17 -0700 Message-Id: <80AD085D-E566-4396-88DD-051F6308E3A9@cooperw.in> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <7594FB04B1934943A5C02806D1A2204B3804432C@ESESSMB209.ericsson.se> <7AD1F7BA-4F56-44FA-AD0C-DD58B70223A4@nostrum.com> To: Ben Campbell X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jun 2016 22:14:20 -0000 --Apple-Mail=_AB32391C-14BB-45D1-8E3D-3E9FBFF68727 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 8, 2016, at 1:25 PM, Ben Campbell wrote: >=20 > On 8 Jun 2016, at 15:14, Christer Holmberg wrote: >=20 > Hi, > =20 > Since intermediaries are listed as one problem for achieving = end-to-end SRTP, would it be useful to reference RFC 7879 as one input = for the work? > =20 >=20 > I am of a mixed mind on that, since RFC 7879 mainly gives guidance to = b2bua implementers on how not to break things. OTOH, it may make sense = for SIPBRANDY to make assumptions about intermediaries adhering to that = guidance. >=20 > Also, not specifically mentioning an RFC doesn't prevent the working = group from thinking about it if it makes sense. >=20 >=20 Right. For that reason I don=E2=80=99t think an explicit mention is = necessary. Alissa > Does anyone else have thought on this? >=20 > Thanks! >=20 > Ben. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --Apple-Mail=_AB32391C-14BB-45D1-8E3D-3E9FBFF68727 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Jun 8, 2016, at 1:25 PM, Ben Campbell <ben@nostrum.com> = wrote:

On 8 Jun 2016, at 15:14, = Christer Holmberg wrote:

Hi,
 
Since intermediaries are listed as one problem for achieving end-to-end = SRTP, would it be useful to reference RFC 7879 as one input for the = work?
 

I am of a mixed mind on that, = since RFC 7879 mainly gives guidance to b2bua implementers on how not to = break things. OTOH, it may make sense for SIPBRANDY to make assumptions = about intermediaries adhering to that guidance.

Also, not specifically mentioning an RFC doesn't prevent the working group from thinking about it if it = makes sense.



Right. For that reason I don=E2=80=99t think an = explicit mention is necessary.

Alissa

Does anyone else have thought on this?

Thanks!

Ben.

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

= --Apple-Mail=_AB32391C-14BB-45D1-8E3D-3E9FBFF68727-- From nobody Thu Jun 9 03:17:23 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B247C12B043 for ; Thu, 9 Jun 2016 03:17:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.345 X-Spam-Level: X-Spam-Status: No, score=-3.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 5XUP3PVzou_Q for ; Thu, 9 Jun 2016 03:17:19 -0700 (PDT) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91DAF12D09C for ; Thu, 9 Jun 2016 03:17:18 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx12.unify.com (Server) with ESMTP id D76C923F0488; Thu, 9 Jun 2016 12:17:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Thu, 9 Jun 2016 12:17:16 +0200 From: "Hutton, Andrew" To: Ben Campbell , "dispatch@ietf.org" Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRwcF60/hPlBkaI0Caeu/dKs02fp/g6qRQ Date: Thu, 9 Jun 2016 10:17:16 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF26136699MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 10:17:22 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF26136699MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The updated charter states "the WG may consider compatibility with aspects = of PERC" but does not give any further guidance as to why this might be nec= essary unlike the text in the same paragraph referring to WebRTC and MMUSIC= which does give some reasons why some consideration might be needed. In the case of PERC I think it is important to note that a SIP endpoint mus= t be able to negotiate using SDP offer/answer either a two party (SIPBrandy= ) or a multi-party session (PERC) without prior knowledge of which one will= be used. I think it would be useful to have this in the charter to make i= t clear, any other views on this? Regards Andy From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 08 June 2016 21:08 To: dispatch@ietf.org Subject: Re: [dispatch] SIPBRANDY and other dangers I just made a minor update to say that SIPBRANDY may consider compatibility= with aspects of PERC, and added PERC to the collaboration list. This is in= response to some offline comments. I invite comments (still to dispatch) about whether we should include that = addition, or if we need any stronger requirements in that area. Thanks! Ben. On 6 Jun 2016, at 15:27, Ben Campbell wrote: The most recent proposed text is at https://datatracker.ietf.org/doc/charte= r-ietf-sipbrandy/ . Ben. On 6 Jun 2016, at 15:25, Ben Campbell wrote: Since no one complained, and a few people expressed support directly to me = offline, I added that text to the proposed charter, along with adding RTCWE= B to the list of groups in the "expected to coordinate with" paragraph. I will put this on the agenda for internal review on the next IESG telechat= . That should not shut down discussion, so if people have further thoughts,= please comment as soon as possible. Thanks! Ben. On 26 May 2016, at 19:55, Ben Campbell wrote: Hi Jon, As an individual, I'm afraid the association of this effort with other grea= t unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the= implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. = And I don't think we would be happy if we solved all the other things and n= ot e2e confidentiality. It also seems to me that aligning identity models fits more with STIR than = with this group. That being said, what about something like the following: "While confidentiality is the first priority of the working group, it may w= ork on aligning these practices with WebRTC, for example by defining best p= ractices for ensuring recipients of media flows have consented to receive s= uch flows, in order to prevent or mitigate the denial-of-service attack des= cribed in RFC 5245, section 18.5.1." Ben. On 26 May 2016, at 19:05, Peterson, Jon wrote: It would be a fairly significant change to the proposed scope, but perhaps one that's warranted. I understand why you have some process caution here about scoping a consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set the explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibility with SIP, and it would be a shame if the effort to interwork the two proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting plausible interworking with WebRTC could also provide some further incentive for implementers to crack open their SIP implementations. If a "grand unified theory" is the goal, then this also conforms nicely with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those three things in a common way - especially as WebRTC IdP today conveys that identity information as an SDP attribute. Realigning Offers[/Answers]: The Grand Unified Theory? Jon Peterson Neustar, Inc. On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > wrote: As early as 2005, we identified a class of DoS attack that would be enabled by SIP systems, if widely deployed on the public internet. Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures. While I don't think this is something that SIPBRANDY is required to address, I would like it to be part of the discussion. I believe this makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature -- which would seem to require the same set of expertise as the other problems SIPBRANDY will work on. To that end, I propose adding the following sentence to the "Objectives" paragraph in the SIPBRANDY charter: "The working group may also define best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." To be clear: I do not wish to presuppose that the solution to this problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration. /a ________________________________ 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 ________________________________ 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 ________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_9F33F40F6F2CD847824537F3C4E37DDF26136699MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The updated charter state= s “the WG may consider compatibility with aspects of PERC” but = does not give any further guidance as to why this might be necessary unlike the text in the same paragraph referring to WebRTC and MMUSIC which= does give some reasons why some consideration might be needed.<= /span>

 <= /p>

In the case of PERC I thi= nk it is important to note that a SIP endpoint must be able to negotiate us= ing SDP offer/answer either a two party (SIPBrandy) or a multi-party session (PERC) without prior knowledge of which one will be us= ed.  I think it would be useful to have this in the charter to make it= clear, any other views on this?

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: dispatch= [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 08 June 2016 21:08
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

 

I just made a minor update to say that SIPBRANDY may consider compatibil= ity with aspects of PERC, and added PERC to the collaboration list. This is= in response to some offline comments.

I invite comments (still to dispatch) about whether we should include th= at addition, or if we need any stronger requirements in that area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed support directly to = me offline, I added that text to the proposed charter, along with adding RT= CWEB to the list of groups in the "expected to coordinate with" p= aragraph.

I will put this on the agenda for internal review on the next IESG telec= hat. That should not shut down discussion, so if people have further though= ts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effort with other g= reat unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, = the implied acronym :-) ) I'd be happy if we just solved e2e confidentialit= y. And I don't think we would be happy if we solved all the other things and not e2e confidentiali= ty.

It also seems to me that aligning identity models fits more with STIR th= an with this group.

That being said, what about something like the following:

"While confidentiality is the first priority of the working group, = it may work on aligning these practices with WebRTC, for example by definin= g best practices for ensuring recipients of media flows have consented to r= eceive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18= .5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed scope, but perha= ps
one that's warranted.

I understand why you have some process caution here about scoping a
consent mechanism to ICE at the outset, but if we're going to put this
problem under SIPPRANDY's umbrella, I think it could make sense to set the<= br> explicit goal of getting a "grand unified theory" of VoIP securit= y that
would align the security of SIP and WebRTC. As we all know, WebRTC went
down many of the paths that it did for the sake of backwards compatibility<= br> with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting
plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also confor= ms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's
IdP aligned. As my strawman proposal for SIP media confidentiality had
both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those
three things in a common way - especially as WebRTC IdP today conveys that<= br> identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<dispatch-bounces@ietf.org on behalf of adam@nostrum.com>= wrote:

As early as 2005, we identified a class of DoS attack that would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potent= ially
vast quantities of media traffic towards a target using normal SIP call
setup procedures.

While I don't think this is something that SIPBRANDY is required to
address, I would like it to be part of the discussion. I believe this
makes sense for two reasons: (1) I expect the recommendations that come
out of SIPBRANDY to require non-trivial endpoint changes, and it would
be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue
is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to the "Object= ives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ensuring
recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solution to this
problem will be ICE, or that it even is required in order for the WG to
declare success. I just want it to be available for consideration.

/a

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

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

dispatch mailing list
dispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_9F33F40F6F2CD847824537F3C4E37DDF26136699MCHP04MSXglobal_-- From nobody Thu Jun 9 09:29:11 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE89E12D815 for ; Thu, 9 Jun 2016 09:29:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 s81NaCtJsNcR for ; Thu, 9 Jun 2016 09:29:08 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A75DA12D769 for ; Thu, 9 Jun 2016 09:29:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4804; q=dns/txt; s=iport; t=1465489748; x=1466699348; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=cslqptpZLOEFK8mn76qhX5uG+O/7S+vWZ7wXRwocZpQ=; b=KBAVmNR+nJM9DoSCNSuFe9pEFkc6kbRv3S0nFYCuCowB8eCzPtQtOEO8 GEYLofHhr8NaJcsNML3oAnKSVYwNAjg4FnTLc3N18ZJlCnyEb6D3YUQ99 O4GMPxuH9FYrHa23erChDVqgvYWctVRJQRb60tGkLM4lDyO2GuZtRt0Kc 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQDkmFlX/5JdJa1egz5WfQaCNrheg?= =?us-ascii?q?QdzFw2CPByCTUoCHIEbOBQBAQEBAQEBZSeERQEBAQMBAQEBIBE6EAsCAQYCGAI?= =?us-ascii?q?CERUCAgIlAQoVEAIEExSIAQMPCA4DkAmdHZEKAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBHIEBhx0Igk6EEhEBHBcogkIrgi4FkyeFLgGGAoU1gm+KYoQ+j2QBHjaCBxy?= =?us-ascii?q?BS24BiFI2fwEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208";a="113515750" Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 09 Jun 2016 16:28:52 +0000 Received: from XCH-RTP-001.cisco.com (xch-rtp-001.cisco.com [64.101.220.141]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u59GSqwp032247 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Jun 2016 16:28:52 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 12:28:51 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 12:28:51 -0400 From: "Cullen Jennings (fluffy)" To: DISPATCH list Thread-Topic: [dispatch] Introducing the Interledger Protocol Thread-Index: AQHRwmwB0Pqtjbt+z0WyqUEGKFbalg== Date: Thu, 9 Jun 2016 16:28:51 +0000 Message-ID: <9BD348A9-CFA2-4213-9C6B-B4FE368A8EB4@cisco.com> References: <1127651464816168@web30h.yandex.ru> <19db51ff-72ca-6769-22ca-3daf768b3fb7@nostrum.com> <567581465417712@web30m.yandex.ru> In-Reply-To: <567581465417712@web30m.yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:29:11 -0000 DQpKdXN0IGFzIHNvbWUgcmFuZG9tIGxpbmtzIHRoYXQgbWlnaHQgYmUgdXNlZnVsIGZvciBJRVRG IGZvbGtzIC4uDQoNCllvdSBjYW4gZmluZCBtb3JlIGluZm8gYWJvdXQgVzNDIHBheW1lbnRzIFdH IGF0IA0KaHR0cHM6Ly93d3cudzMub3JnL1BheW1lbnRzL1dHLw0KDQpJdCBkb2VzIG5vdCBzZWVt IHRvIGhhdmUgbXVjaCB0byBkbyB3aXRoIHdoYXQgaXMgcHJvcG9zZWQgaGVyZS4gDQoNCk5vdGUg dGhlcmUgaXMgYSBXM0MgY29tbXVuaXR5IGdyb3VwIGZvciB0aGUgaW50ZXJsZWRnZXIgd29yay4g VGhpcyBpcyByb3VnaGx5IGVxdWl2YWxlbnQgdG8gdGhlIElFVEYgbm9uIFdHIGVtYWlsIGxpc3Qg YW5kIGRvZXMgbm90IGluZGljYXRlIGFuIGVuZG9yc2VtZW50IG9yIGNvdXJzZSBvZiBhY3Rpb24g Zm9yIHRoZSBXM0MuIEl0IGlzIGF0IA0KDQpodHRwczovL3d3dy53My5vcmcvY29tbXVuaXR5L2lu dGVybGVkZ2VyLw0KDQpJdCdzIG5vdCBjbGVhciB0byBtZSBob3cgeW91IGpvaW4gdGhlIG1haWxp bmcgbGlzdCB3aXRob3V0IGFncmVlaW5nIHRvIGNlcnRhaW4gbGVnYWwgdGVybXMgYnV0IHRoZSBh cmNoaXZlcyBzZWVtIHRvIGJlIHB1YmxpYyBhdCANCg0KaHR0cHM6Ly9saXN0cy53My5vcmcvQXJj aGl2ZXMvUHVibGljL3B1YmxpYy1pbnRlcmxlZGdlci8NCg0KDQoNCj4gT24gSnVuIDgsIDIwMTYs IGF0IDI6MjggUE0sINCi0LLQtdGA0LXRgtC40L0g0JDQvdGC0L7QvSDQodC10YDQs9C10LXQstC4 0YcgPHR2ZXJldGluYXNAeWFuZGV4LnJ1PiB3cm90ZToNCj4gDQo+IFN1cmVseSwgSSByZWZlciB0 byB0aGUgUGF5bWVudCBXRyBhdCBXM0MuDQo+IEkgZGlkIG5vdCBrbm93IGFib3V0IGVmZm9ydHMg aGVyZS4gQnV0IElTUFAgY2hhcnRlciByZW1pbmRzIG1lIG9mIGEgcHJvYmxlbS4NCj4gVGhlcmUg aXMgZ29vZCBzb2Z0d2FyZSB0byBtYW5hZ2UgYnVzaW5lc3MgYWNjb3VudHMgKGJhc2VkIG9uIGRp Z2l0YWwgc2lnbmF0dXJlcyksIGJ1dCBub3QgZm9yIG5vbi1idXNpbmVzcyBhY2NvdW50cywgYW5k IHNvbWV0aGluZyBzdHJhbmdlIGZvciBlLW1vbmV5LiBCdXQgaW4gcHJhY3RpY2UsIHRoZXJlIGNv dWxkIGJlIG5vIGRpZmZlcmVuY2UgYmV0d2VlbiBCMkIgYW5kIEIyQy4gV2hlbiBJIHBheSB0byBt eSBJU1AsIHRoaXMgaXMgQjJCIHBheW1lbnQgaWYgSSB1c2UgdGhlIE5ldCBmb3IgYnVzaW5lc3Ms IG9yIEIyQyBpZiBJIGRvIG5vdC4gQnV0IHRoZSBhbW91bnQgaXMgdGhlIHNhbWUsIHJlYWxseSBu b3RoaW5nIGNoYW5nZXMuDQo+IFNvICJyZXRhaWwgcGF5bWVudHMiIGlzIGEgbm9uLWV4aXN0aW5n IHByb2JsZW0uIFBvc3NpYmx5IHRoaXMgaXMgdGhlIHJlYXNvbiB3aHkgSVNQUCBjb3VsZCBub3Qg cHJvZHVjZSBhbnl0aGluZy4NCj4gDQo+IEkgcHVibGlzaCBOR01UUCBzcGVjcyBhdCA8aHR0cDov L3d3dy5maXQtcnVsZXoubmFyb2QucnUvbmdtdHAvPi4gQ3VycmVudGx5LCBvbmx5ICJhY2NvdW50 IGNoYWluIiBpcyB0aGVyZS4NCj4gUG9zc2libHksIHdlIHNob3VsZCBkaXNjdXNzIHNvbWUgZGVj aXNpb25zIGluIFEmQSBmb3JtYXQuDQo+IA0KPiAwMi4wNi4yMDE2LCAyMDo1OSwgIkFkYW0gUm9h Y2giIDxhZGFtQG5vc3RydW0uY29tPjoNCj4+ICBPbiA2LzIvMTYgMDk6MTYsIEFkcmlhbiBIb3Bl LUJhaWxpZSB3cm90ZToNCj4+PiAgIEkgd2Fzbid0IGF3YXJlIG9mIGEgUGF5bWVudHMgV0cgYXQg SUVURiBvciBvZiBOR01UUC4NCj4+PiAgIENhbiB5b3UgcHJvdmlkZSBhIGxpbmsgdG8gc29tZSBy ZXNvdXJjZXMgb3IgYSBtYWlsaW5nIGxpc3QgYXJjaGl2ZSBzbw0KPj4+ICAgaSBjYW4gZ2V0IG15 c2VsZiB1cCB0byBzcGVlZD8NCj4+IA0KPj4gIEknbSBub3Qgc3VyZSBvZmZoYW5kIHdoaWNoIFdv cmtpbmcgR3JvdXAgQW50b24gaXMgcmVmZXJyaW5nIHRvLiBBcyBmYXINCj4+ICBhcyBJJ20gYWJs ZSB0byB0dXJuIHVwLCB0aGVyZSBoYXZlIG9ubHkgYmVlbiB0d28gd29ya2luZyBncm91cHMgaW4g dGhlDQo+PiAgSUVURidzIGhpc3RvcnkgdGhhdCBkZWFsdCBzcXVhcmVseSB3aXRoIHBheW1lbnQt cmVsYXRlZCB0ZWNobm9sb2dpZXM6DQo+PiANCj4+ICBUaGUgSVNQUCAoSW50ZXJuZXQgU2VjdXJl IFBheW1lbnRzIFByb3RvY29sKSBXRyBjb25jbHVkZWQgaW4gSmFudWFyeSBvZg0KPj4gIDE5OTcu IFRoZSBjaGFydGVyIGF0IGl0cyB0aW1lIG9mIGNvbmNsdXNpb24gaXMgaGVyZToNCj4+ICBodHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL3dnL2lzcHAvY2hhcnRlci8NCj4+IA0KPj4gIFRoZSBU UkFERSAoSW50ZXJuZXQgT3BlbiBUcmFkaW5nIFByb3RvY29scykgY29uY2x1ZGVkIGluIEZlYnVy YXJ5IG9mDQo+PiAgMjAwNS4gVGhlIGNoYXJ0ZXIgYXQgaXRzIHRpbWUgb2YgY29uY2x1c2lvbiBp cyBoZXJlOg0KPj4gIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvd2cvdHJhZGUvY2hhcnRl ci8NCj4+IA0KPj4gIEJvdGggd29ya2luZyBncm91cHMgcHJlZGF0ZSBhbnkgY2VudHJhbGx5LWNv b3JkaW5hdGVkIG1haWxpbmcgbGlzdA0KPj4gIGFyY2hpdmluZyBieSB0aGUgSUVURiwgYW5kIHRo ZSBhcmNoaXZlcyBvZiB0aGVpciBtYWlsaW5nIGxpc3QNCj4+ICBkaXNjdXNzaW9ucyBubyBsb25n ZXIgYXBwZWFyIHRvIGJlIG9ubGluZS4gVGhleSBhbHNvIGRhdGUgYmFjayB0byBhDQo+PiAgcGVy aW9kIG9mIHRpbWUgaW4gd2hpY2ggaW50ZXJuZXQgZHJhZnRzIHdlcmUgYWdncmVzc2l2ZWx5IHJl bW92ZWQgZnJvbQ0KPj4gIHRoZSBpbnRlcm5ldCBhZnRlciB0aGVpciBzaXgtbW9udGggZXhwaXJh dGlvbiBwZXJpb2QsIHNvIHRyYWNpbmcgdGhlaXINCj4+ICB3b3JrIG91dHB1dCB0byB0aGUgZ2Vu ZXJhdGVkIFJGQ3MgaXMgbm90IHRlcnJpYmx5IHN0cmFpZ2h0Zm9yd2FyZC4NCj4+IA0KPj4gIFRS QURFJ3MgbWFpbiBvdXRwdXQgcmVsaWMgYXBwZWFycyB0byBiZSB0aGUgSW50ZXJuZXQgT3BlbiBU cmFkaW5nDQo+PiAgUHJvdG9jb2wgKElPVFApLCBkb2N1bWVudGVkIGluIFJGQ3MgMjgwMSAtIDI4 MDMsIGFuZCBSRkMgMzUwNC4gVGhlcmUNCj4+ICBhcHBlYXJzIHRvIGhhdmUgYmVlbiBhbiBlZmZv cnQgc3RhcnRlZCB0byBkZWZpbmUgYSB2MiBvZiB0aGUgcHJvdG9jb2wsDQo+PiAgYnV0IHRoYXQg d29yayBkb2VzIG5vdCBhcHBlYXIgdG8gaGF2ZSBib3JuZSBmcnVpdC4gU2VlIGFsc28NCj4+ICA8 aHR0cHM6Ly9tYWlsYXJjaGl2ZS5pZXRmLm9yZy9hcmNoL21zZy9hcHBzLWRpc2N1c3MvSXJBWjRT Tjk5V0hDTEVpaTdnWnZUUGliVE5ZPi4NCj4+IA0KPj4gIEkgY2FuJ3QgZmlndXJlIG91dCB3aGV0 aGVyIElTUFAgcHJvZHVjZWQgYW55IFJGQ3MgYXQgYWxsLg0KPj4gDQo+PiAgL2ENCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IGRpc3BhdGNo IG1haWxpbmcgbGlzdA0KPiBkaXNwYXRjaEBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL2Rpc3BhdGNoDQoNCg== From nobody Thu Jun 9 09:32:02 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CFEF12D81E for ; Thu, 9 Jun 2016 09:32:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 QB39dbm4txKj for ; Thu, 9 Jun 2016 09:32:00 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E10D212D78E for ; Thu, 9 Jun 2016 09:31:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=776; q=dns/txt; s=iport; t=1465489919; x=1466699519; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=mL37KLu41x+DS7puyCz/5p2TMLly1aa3ZcqrI7ej3wg=; b=MMT0Xez6aB3cnhgHYy5hwEfPQEB9VzkdJBnK3VKtFjqZCeiDaq/jT96j HKn5T6BSW5rwQGU1BeWucdomEQQqrtUiTOC4a1vT6TwZFptEZc20WlHxp slI7TBBCDUgdi8VmCo4JzZ4zvoZxW9SmvfYedJ6qXuXOkNaDgZETYtj9L k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D3AQDkmFlX/4YNJK1egz6BUwa5BYIPg?= =?us-ascii?q?XqGEwKBNzgUAQEBAQEBAWUnhEUBAQEDATo/BQsCAQgYHhAyJQIEDgUbiAwIvkE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAQEBAQEciB4Igk6EQIMsgi4FmFUBjiaNfoEij2QBH?= =?us-ascii?q?jaDbm6JCX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,445,1459814400"; d="scan'208";a="113367435" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Jun 2016 16:31:59 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u59GVwoq023507 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 9 Jun 2016 16:31:59 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 9 Jun 2016 12:31:58 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1104.009; Thu, 9 Jun 2016 12:31:58 -0400 From: "Cullen Jennings (fluffy)" To: "Hutton, Andrew" Thread-Topic: [dispatch] Proposed SIPBRANDY Charter Thread-Index: AQHRwmxx/BiE1XiKWkmEylZSfoULeg== Date: Thu, 9 Jun 2016 16:31:57 +0000 Message-ID: References: <7CF2C263-55C1-4565-BE9F-92858F895757@nostrum.com> <5ec31a4e-936d-0b6f-03e4-6a69fe67468d@alum.mit.edu> <9F33F40F6F2CD847824537F3C4E37DDF2610B22A@MCHP04MSX.global-ad.net> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF2610B22A@MCHP04MSX.global-ad.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.20.249.165] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Proposed SIPBRANDY Charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:32:01 -0000 > On May 20, 2016, at 4:57 AM, Hutton, Andrew wro= te: >=20 > On: 19 May 2016 22:24 Paul Kyzivat wrote: >=20 >=20 >> I didn't hear the BA discussions, so I'm shooting blind here. >>=20 >> Is there any intention for this to yield something that can be >> interworked with webrtc (one webrtc endpoint, one sip endpoint) while >> still getting e2e SRTP? >>=20 >> If so, that ought to be stated because it will constrain the solution >> space. >>=20 >=20 > I also don't think this was discussed in the meeting but I would support = having it stated as a goal. >=20 > Andy +1=20 And as a side note, I suspect anything that resulted in something that woul= d not work with WebRTC would cause many people to be very unhappy.=20 From nobody Thu Jun 9 09:57:10 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DB9912D8A0 for ; Thu, 9 Jun 2016 09:57:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Q4B4mM6IEVGA for ; Thu, 9 Jun 2016 09:57:07 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE8412D098 for ; Thu, 9 Jun 2016 09:57:06 -0700 (PDT) X-AuditID: c1b4fb2d-f79936d0000030e4-87-57599fe1794d Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 35.E7.12516.1EF99575; Thu, 9 Jun 2016 18:57:05 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC003.ericsson.se ([153.88.183.27]) with mapi id 14.03.0294.000; Thu, 9 Jun 2016 18:57:05 +0200 From: Christer Holmberg To: "dispatch@ietf.org" Thread-Topic: Draft new version: draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AdHCb25gtydQswivSm2+Gs9THNdHjQ== Date: Thu, 9 Jun 2016 16:57:04 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B38045FEA@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.149] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B38045FEAESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMIsWRmVeSWpSXmKPExsUyM2K7tO7D+ZHhBudmy1pMP/OX0WJ+52l2 i60vVrNYLJ20gNWica6dA6vHlycvmTx2zrrL7rFkyU8mj1k7n7B4fLn8mS2ANYrLJiU1J7Ms tUjfLoErY/2Pj4wFE/QqGlY+Z21gbNXsYuTkkBAwkdiwbTc7hC0mceHeerYuRi4OIYEjjBIX G3pZIZzFjBK35/8EquLgYBOwkOj+pw3SICKgLXF0VRczSA2zwGZGiZvnVzKD1AgLeEo8bLSF qAmQWLlnHSOErSdxbWMr2DIWARWJ46efg9m8Ar4Sp5c/ZwGxGYGO+H5qDROIzSwgLnHryXwm iOMEJJbsOc8MYYtKvHz8jxXCVpJYe3g7C8haZoF8ic0fWSBGCkqcnPmEZQKj8Cwkk2YhVM1C UgVRoiOxYPcnNghbW2LZwtfMMPaZA4+ZkMUXMLKvYhQtTi0uzk03MtZLLcpMLi7Oz9PLSy3Z xAiMuoNbfuvuYFz92vEQowAHoxIPb8LUiHAh1sSy4srcQ4wSHMxKIrxs8yLDhXhTEiurUovy 44tKc1KLDzFKc7AoifP6v1QMFxJITyxJzU5NLUgtgskycXBKNTC65uXOXjGndcO6aY1GabH1 bRuMPkWo3veuvfnnVajnM07vvefi751KrzKacnxTLG+sijJH8kUno/fX9rwqrVzlpxKZbrql mr899eSLRtlCsXQjbdXfCfoh2WEfr6VtUJshvfD3Qu9tU55P8WC1W/botFCrXNHkUwWVJsFa q7i0FWXvP1mye6kSS3FGoqEWc1FxIgDlrvAMtgIAAA== Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , Ben Campbell , Ted Hardie Subject: [dispatch] Draft new version: draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 16:57:09 -0000 --_000_7594FB04B1934943A5C02806D1A2204B38045FEAESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Based on the feedback given in BA, we have submitted a new version (-01) dr= aft-holmberg-dispatch-mcptt-rp-namespace. The changes are: 1) Applicability statement added, scoping the solution to 3GPP (reques= ted by Ted Hardie) 2) Priority levels starting from 0 value For the GitHub lovers: https://github.com/cdh4u/draft-mcptt-namespace (Personal repo) Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B38045FEAESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Based on the feedback given in BA, we have submitted= a new version (-01) draft-holmberg-dispatch-mcptt-rp-namespace.=

 

The changes are:

 

1)      Applicability statement added, scoping the solution= to 3GPP (requested by Ted Hardie)

2)      Priority levels starting from 0 value

 

For the GitHub lovers:

 

https://github.com/cdh4u/draft-mcptt-namespace   =      (Personal repo)

 

Regards,

 

Christer

--_000_7594FB04B1934943A5C02806D1A2204B38045FEAESESSMB209erics_-- From nobody Thu Jun 9 13:37:43 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0754312D0B3 for ; Thu, 9 Jun 2016 13:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 dVxJdqho1-a1 for ; Thu, 9 Jun 2016 13:37:39 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76B5512D0E8 for ; Thu, 9 Jun 2016 13:37:39 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u59KbcDQ089779 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 9 Jun 2016 15:37:38 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Hutton, Andrew" Date: Thu, 09 Jun 2016 15:37:47 -0500 Message-ID: <4F089A43-39F3-42B3-B059-51E0069ECF17@nostrum.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_9DFA4EF3-A3FC-468B-B82F-A12E35784EDC_=" X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jun 2016 20:37:42 -0000 --=_MailMate_9DFA4EF3-A3FC-468B-B82F-A12E35784EDC_= Content-Type: text/plain; format=flowed; markup=markdown Content-Transfer-Encoding: quoted-printable On 9 Jun 2016, at 5:17, Hutton, Andrew wrote: > The upda > ted charter states "the WG may consider compatibility with aspects of = > PERC" but does not give any further guidance as to why this might be = > necessary unlike the text in the same paragraph referring to WebRTC = > and MMUSIC which does give some reasons why some consideration might = > be needed. > > In the case of PERC I think it is important to note that a SIP = > endpoint must be able to negotiate using SDP offer/answer either a two = > party (SIPBrandy) or a multi-party session (PERC) without prior = > knowledge of which one will be used. I think it would be useful to = > have this in the charter to make it clear, any other views on this? Speaking as an individual, I don't think that requirement belongs in the = charter. I'd rather leave it to the working group to do the right thing, = and I'm not convinced we know for sure what that right thing is at this = point in the process. I think there's a real risk of over constraining = things if we are not careful. If others have an opinion, please speak up asap. Thanks! Ben. > > Regards > Andy > > > > > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben = > Campbell > Sent: 08 June 2016 21:08 > To: dispatch@ietf.org > Subject: Re: [dispatch] SIPBRANDY and other dangers > > > I just made a minor update to say that SIPBRANDY may consider = > compatibility with aspects of PERC, and added PERC to the = > collaboration list. This is in response to some offline comments. > > I invite comments (still to dispatch) about whether we should include = > that addition, or if we need any stronger requirements in that area. > > Thanks! > > Ben. > > On 6 Jun 2016, at 15:27, Ben Campbell wrote: > > The most recent proposed text is at = > https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . > > Ben. > > On 6 Jun 2016, at 15:25, Ben Campbell wrote: > > Since no one complained, and a few people expressed support directly = > to me offline, I added that text to the proposed charter, along with = > adding RTCWEB to the list of groups in the "expected to coordinate = > with" paragraph. > > I will put this on the agenda for internal review on the next IESG = > telechat. That should not shut down discussion, so if people have = > further thoughts, please comment as soon as possible. > > Thanks! > > Ben. > > On 26 May 2016, at 19:55, Ben Campbell wrote: > > Hi Jon, > > As an individual, I'm afraid the association of this effort with other = > great unsolved problems (Great Unsolved Theories?) may be prophetic. = > (Also, the implied acronym :-) ) I'd be happy if we just solved e2e = > confidentiality. And I don't think we would be happy if we solved all = > the other things and not e2e confidentiality. > > It also seems to me that aligning identity models fits more with STIR = > than with this group. > > That being said, what about something like the following: > > "While confidentiality is the first priority of the working group, it = > may work on aligning these practices with WebRTC, for example by = > defining best practices for ensuring recipients of media flows have = > consented to receive such flows, in order to prevent or mitigate the = > denial-of-service attack described in RFC 5245, section 18.5.1." > > Ben. > > On 26 May 2016, at 19:05, Peterson, Jon wrote: > > It would be a fairly significant change to the proposed scope, but = > perhaps > one that's warranted. > > I understand why you have some process caution here about scoping a > consent mechanism to ICE at the outset, but if we're going to put this > problem under SIPPRANDY's umbrella, I think it could make sense to set = > the > explicit goal of getting a "grand unified theory" of VoIP security = > that > would align the security of SIP and WebRTC. As we all know, WebRTC = > went > down many of the paths that it did for the sake of backwards = > compatibility > with SIP, and it would be a shame if the effort to interwork the two > proved futile because of lack of e2e SRTP. Consent would be another = > prong > of that. So maybe writing ICE in as a foregone conclusion in the = > service > of that goal would let us skip some unnecessary deliberation. Getting > plausible interworking with WebRTC could also provide some further > incentive for implementers to crack open their SIP implementations. > > If a "grand unified theory" is the goal, then this also conforms = > nicely > with Cullen's recent efforts to figure out how to get STIR and = > WebRTC's > IdP aligned. As my strawman proposal for SIP media confidentiality had > both a STIR story and an opportunistic story, we could argue that = > getting > alignment of identity, consent, and encryption could be grouped under = > one > effort, which is mostly about getting offer/answer to deal with those > three things in a common way - especially as WebRTC IdP today conveys = > that > identity information as an SDP attribute. > > Realigning Offers[/Answers]: The Grand Unified Theory? > > Jon Peterson > Neustar, Inc. > > On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > adam@nostrum.com> = > wrote: > > As early as 2005, we identified a class of DoS attack that would be > enabled by SIP systems, if widely deployed on the public internet. > Called the "Voice Hammer," this attack involves triggering potentially > vast quantities of media traffic towards a target using normal SIP = > call > setup procedures. > > While I don't think this is something that SIPBRANDY is required to > address, I would like it to be part of the discussion. I believe this > makes sense for two reasons: (1) I expect the recommendations that = > come > out of SIPBRANDY to require non-trivial endpoint changes, and it would > be good to consider coupling breaking changes to each other so as to > minimize the number of potential modes of operation; and (2) the issue > is fundamentally a security issue -- albeit of a different nature -- > which would seem to require the same set of expertise as the other > problems SIPBRANDY will work on. > > To that end, I propose adding the following sentence to the = > "Objectives" > paragraph in the SIPBRANDY charter: > > "The working group may also define best practices for ensuring > recipients of media flows have consented to receive such flows, in = > order > to prevent or mitigate the denial-of-service attack described in RFC > 5245, section 18.5.1." > > To be clear: I do not wish to presuppose that the solution to this > problem will be ICE, or that it even is required in order for the WG = > to > declare success. I just want it to be available for consideration. > > /a > > ________________________________ > > 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 > > ________________________________ > > 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 > > ________________________________ > > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch --=_MailMate_9DFA4EF3-A3FC-468B-B82F-A12E35784EDC_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

On 9 Jun 2016, at 5:17, Hutton, Andrew wrote:

The upda
ted charter states "the WG may consider compatibility with aspects of PER= C" but does not give any further guidance as to why this might be necessa= ry unlike the text in the same paragraph referring to WebRTC and MMUSIC w= hich does give some reasons why some consideration might be needed.

In the case of PERC I think it is important to note that = a SIP endpoint must be able to negotiate using SDP offer/answer either a = two party (SIPBrandy) or a multi-party session (PERC) without prior knowl= edge of which one will be used. I think it would be useful to have this = in the charter to make it clear, any other views on this?

Speaking as an individual, I don't think that requirement= belongs in the charter. I'd rather leave it to the working group to do t= he right thing, and I'm not convinced we know for sure what that right th= ing is at this point in the process. I think there's a real risk of over = constraining things if we are not careful.

If others have an opinion, please speak up asap.

Thanks!

Ben.

Regards
Andy

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 08 June 2016 21:08
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

I just made a minor update to say that SIPBRANDY may cons= ider compatibility with aspects of PERC, and added PERC to the collaborat= ion list. This is in response to some offline comments.

I invite comments (still to dispatch) about whether we sh= ould include that addition, or if we need any stronger requirements in th= at area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

The most recent proposed text is at https://datatracker.ietf.= org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed suppo= rt directly to me offline, I added that text to the proposed charter, alo= ng with adding RTCWEB to the list of groups in the "expected to coordinat= e with" paragraph.

I will put this on the agenda for internal review on the = next IESG telechat. That should not shut down discussion, so if people ha= ve further thoughts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effo= rt with other great unsolved problems (Great Unsolved Theories?) may be p= rophetic. (Also, the implied acronym :-) ) I'd be happy if we just solved= e2e confidentiality. And I don't think we would be happy if we solved al= l the other things and not e2e confidentiality.

It also seems to me that aligning identity models fits mo= re with STIR than with this group.

That being said, what about something like the following:=

"While confidentiality is the first priority of the worki= ng group, it may work on aligning these practices with WebRTC, for exampl= e by defining best practices for ensuring recipients of media flows have = consented to receive such flows, in order to prevent or mitigate the deni= al-of-service attack described in RFC 5245, section 18.5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed s= cope, but perhaps
one that's warranted.

I understand why you have some process caution here about= scoping a
consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set th= e
explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibilit= y
with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong=
of that. So maybe writing ICE in as a foregone conclusion in the service<= br> of that goal would let us skip some unnecessary deliberation. Getting
= plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also c= onforms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting=
alignment of identity, consent, and encryption could be grouped under one=
effort, which is mostly about getting offer/answer to deal with those
= three things in a common way - especially as WebRTC IdP today conveys tha= t
identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" <dispatch-bounces@ietf.org on behalf of adam@nostrum.com<mailto:dis= patch-bounces@ietf.org%20on%20behalf%20of%20adam@nostrum.com>> wrot= e:

As early as 2005, we identified a class of DoS attack tha= t would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures.

While I don't think this is something that SIPBRANDY is r= equired to
address, I would like it to be part of the discussion. I believe this
= makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to t= he "Objectives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ens= uring
recipients of media flows have consented to receive such flows, in order<= br> to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solutio= n to this
problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration.

/a

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ie= tf.org/mailman/listinfo/dispatch

--=_MailMate_9DFA4EF3-A3FC-468B-B82F-A12E35784EDC_=-- From nobody Fri Jun 10 02:47:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5B8F212D190 for ; Fri, 10 Jun 2016 02:47:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 AwbZcBtnuisx for ; Fri, 10 Jun 2016 02:47:22 -0700 (PDT) Received: from mx11.unify.com (mx11.unify.com [62.134.46.9]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 164EE12D992 for ; Fri, 10 Jun 2016 02:47:18 -0700 (PDT) Received: from MCHP01HTC.global-ad.net (unknown [172.29.42.234]) by mx11.unify.com (Server) with ESMTP id 2111B1EB84A8; Fri, 10 Jun 2016 11:47:16 +0200 (CEST) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP01HTC.global-ad.net ([172.29.42.234]) with mapi id 14.03.0279.002; Fri, 10 Jun 2016 11:47:15 +0200 From: "Hutton, Andrew" To: Ben Campbell Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRwcF60/hPlBkaI0Caeu/dKs02fp/g6qRQgACN4oCAAPuFMA== Date: Fri, 10 Jun 2016 09:47:15 +0000 Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF26139546@MCHP04MSX.global-ad.net> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> <4F089A43-39F3-42B3-B059-51E0069ECF17@nostrum.com> In-Reply-To: <4F089A43-39F3-42B3-B059-51E0069ECF17@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [172.29.42.225] Content-Type: multipart/alternative; boundary="_000_9F33F40F6F2CD847824537F3C4E37DDF26139546MCHP04MSXglobal_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 09:47:25 -0000 --_000_9F33F40F6F2CD847824537F3C4E37DDF26139546MCHP04MSXglobal_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable My concern is that we have one group looking at SIP media security for mult= i-party sessions (PERC) and another looking at SIP media security for two p= arty sessions (SIPBRANDY) and neither of the WG charters state that the wor= k needs to be coordinated. It might be obvious that they will be coordinated and that the same people = will probably work on both and I assume that everybody would be sad if they= came up with incompatible solutions but personally I think it would be goo= d for the charter to say something about this. However if I am alone on th= is and we want to leave it to the working groups to work it out then I can = live with that. Regards Andy From: Ben Campbell [mailto:ben@nostrum.com] Sent: 09 June 2016 21:38 To: Hutton, Andrew Cc: dispatch@ietf.org Subject: Re: [dispatch] SIPBRANDY and other dangers On 9 Jun 2016, at 5:17, Hutton, Andrew wrote: The upda ted charter states "the WG may consider compatibility with aspects of PERC"= but does not give any further guidance as to why this might be necessary u= nlike the text in the same paragraph referring to WebRTC and MMUSIC which d= oes give some reasons why some consideration might be needed. In the case of PERC I think it is important to note that a SIP endpoint mus= t be able to negotiate using SDP offer/answer either a two party (SIPBrandy= ) or a multi-party session (PERC) without prior knowledge of which one will= be used. I think it would be useful to have this in the charter to make it= clear, any other views on this? Speaking as an individual, I don't think that requirement belongs in the ch= arter. I'd rather leave it to the working group to do the right thing, and = I'm not convinced we know for sure what that right thing is at this point i= n the process. I think there's a real risk of over constraining things if w= e are not careful. If others have an opinion, please speak up asap. Thanks! Ben. Regards Andy From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Ben Campbell Sent: 08 June 2016 21:08 To: dispatch@ietf.org Subject: Re: [dispatch] SIPBRANDY and other dangers I just made a minor update to say that SIPBRANDY may consider compatibility= with aspects of PERC, and added PERC to the collaboration list. This is in= response to some offline comments. I invite comments (still to dispatch) about whether we should include that = addition, or if we need any stronger requirements in that area. Thanks! Ben. On 6 Jun 2016, at 15:27, Ben Campbell wrote: The most recent proposed text is at https://datatracker.ietf.org/doc/charte= r-ietf-sipbrandy/ . Ben. On 6 Jun 2016, at 15:25, Ben Campbell wrote: Since no one complained, and a few people expressed support directly to me = offline, I added that text to the proposed charter, along with adding RTCWE= B to the list of groups in the "expected to coordinate with" paragraph. I will put this on the agenda for internal review on the next IESG telechat= . That should not shut down discussion, so if people have further thoughts,= please comment as soon as possible. Thanks! Ben. On 26 May 2016, at 19:55, Ben Campbell wrote: Hi Jon, As an individual, I'm afraid the association of this effort with other grea= t unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, the= implied acronym :-) ) I'd be happy if we just solved e2e confidentiality. = And I don't think we would be happy if we solved all the other things and n= ot e2e confidentiality. It also seems to me that aligning identity models fits more with STIR than = with this group. That being said, what about something like the following: "While confidentiality is the first priority of the working group, it may w= ork on aligning these practices with WebRTC, for example by defining best p= ractices for ensuring recipients of media flows have consented to receive s= uch flows, in order to prevent or mitigate the denial-of-service attack des= cribed in RFC 5245, section 18.5.1." Ben. On 26 May 2016, at 19:05, Peterson, Jon wrote: It would be a fairly significant change to the proposed scope, but perhaps one that's warranted. I understand why you have some process caution here about scoping a consent mechanism to ICE at the outset, but if we're going to put this problem under SIPPRANDY's umbrella, I think it could make sense to set the explicit goal of getting a "grand unified theory" of VoIP security that would align the security of SIP and WebRTC. As we all know, WebRTC went down many of the paths that it did for the sake of backwards compatibility with SIP, and it would be a shame if the effort to interwork the two proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting plausible interworking with WebRTC could also provide some further incentive for implementers to crack open their SIP implementations. If a "grand unified theory" is the goal, then this also conforms nicely with Cullen's recent efforts to figure out how to get STIR and WebRTC's IdP aligned. As my strawman proposal for SIP media confidentiality had both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those three things in a common way - especially as WebRTC IdP today conveys that identity information as an SDP attribute. Realigning Offers[/Answers]: The Grand Unified Theory? Jon Peterson Neustar, Inc. On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" >> wrote: As early as 2005, we identified a class of DoS attack that would be enabled by SIP systems, if widely deployed on the public internet. Called the "Voice Hammer," this attack involves triggering potentially vast quantities of media traffic towards a target using normal SIP call setup procedures. While I don't think this is something that SIPBRANDY is required to address, I would like it to be part of the discussion. I believe this makes sense for two reasons: (1) I expect the recommendations that come out of SIPBRANDY to require non-trivial endpoint changes, and it would be good to consider coupling breaking changes to each other so as to minimize the number of potential modes of operation; and (2) the issue is fundamentally a security issue -- albeit of a different nature -- which would seem to require the same set of expertise as the other problems SIPBRANDY will work on. To that end, I propose adding the following sentence to the "Objectives" paragraph in the SIPBRANDY charter: "The working group may also define best practices for ensuring recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18.5.1." To be clear: I do not wish to presuppose that the solution to this problem will be ICE, or that it even is required in order for the WG to declare success. I just want it to be available for consideration. /a ________________________________ dispatch mailing list dispatch@ietf.orgdispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ________________________________ dispatch mailing list dispatch@ietf.orgdispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ________________________________ dispatch mailing list dispatch@ietf.orgdispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ________________________________ dispatch mailing list dispatch@ietf.orgdispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch ________________________________ dispatch mailing list dispatch@ietf.orgdispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch --_000_9F33F40F6F2CD847824537F3C4E37DDF26139546MCHP04MSXglobal_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

My concern is that we hav= e one group looking at SIP media security for multi-party sessions (PERC) a= nd another looking at SIP media security for two party sessions (SIPBRANDY) and neither of the WG charters state that the work needs to be= coordinated.

 <= /p>

It might be obvious that = they will be coordinated and that the same people will probably work on bot= h and I assume that everybody would be sad if they came up with incompatible solutions but personally I think it would be good for= the charter to say something about this.  However if I am alone on th= is and we want to leave it to the working groups to work it out then I can = live with that.

 <= /p>

Regards=

Andy

 <= /p>

 <= /p>

 <= /p>

From: Ben Camp= bell [mailto:ben@nostrum.com]
Sent: 09 June 2016 21:38
To: Hutton, Andrew
Cc: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

 

On 9 Jun 2016, at 5:17, Hutton, Andrew wrote:

The upda
ted charter states "the WG may consider compatibility with aspects of = PERC" but does not give any further guidance as to why this might be n= ecessary unlike the text in the same paragraph referring to WebRTC and MMUS= IC which does give some reasons why some consideration might be needed.

In the case of PERC I think it is important to note that a SIP endpoint = must be able to negotiate using SDP offer/answer either a two party (SIPBra= ndy) or a multi-party session (PERC) without prior knowledge of which one w= ill be used. I think it would be useful to have this in the charter to make it clear, any other views on th= is?

Speaking as an individual, I don't think that requirement belongs in the= charter. I'd rather leave it to the working group to do the right thing, a= nd I'm not convinced we know for sure what that right thing is at this poin= t in the process. I think there's a real risk of over constraining things if we are not careful.<= /p>

If others have an opinion, please speak up asap.

Thanks!

Ben.

Regards
Andy

From: dispatch [mailto:disp= atch-bounces@ietf.org] On Behalf Of Ben Campbell
Sent: 08 June 2016 21:08
To: dispatch@ietf.org
Subject: Re: [dispatch] SIPBRANDY and other dangers

I just made a minor update to say that SIPBRANDY may consider compatibil= ity with aspects of PERC, and added PERC to the collaboration list. This is= in response to some offline comments.

I invite comments (still to dispatch) about whether we should include th= at addition, or if we need any stronger requirements in that area.

Thanks!

Ben.

On 6 Jun 2016, at 15:27, Ben Campbell wrote:

The most recent proposed text is at https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ .

Ben.

On 6 Jun 2016, at 15:25, Ben Campbell wrote:

Since no one complained, and a few people expressed support directly to = me offline, I added that text to the proposed charter, along with adding RT= CWEB to the list of groups in the "expected to coordinate with" p= aragraph.

I will put this on the agenda for internal review on the next IESG telec= hat. That should not shut down discussion, so if people have further though= ts, please comment as soon as possible.

Thanks!

Ben.

On 26 May 2016, at 19:55, Ben Campbell wrote:

Hi Jon,

As an individual, I'm afraid the association of this effort with other g= reat unsolved problems (Great Unsolved Theories?) may be prophetic. (Also, = the implied acronym :-) ) I'd be happy if we just solved e2e confidentialit= y. And I don't think we would be happy if we solved all the other things and not e2e confidentiality.<= /o:p>

It also seems to me that aligning identity models fits more with STIR th= an with this group.

That being said, what about something like the following:

"While confidentiality is the first priority of the working group, = it may work on aligning these practices with WebRTC, for example by definin= g best practices for ensuring recipients of media flows have consented to r= eceive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC 5245, section 18= .5.1."

Ben.

On 26 May 2016, at 19:05, Peterson, Jon wrote:

It would be a fairly significant change to the proposed scope, but perha= ps
one that's warranted.

I understand why you have some process caution here about scoping a
consent mechanism to ICE at the outset, but if we're going to put this
problem under SIPPRANDY's umbrella, I think it could make sense to set the<= br> explicit goal of getting a "grand unified theory" of VoIP securit= y that
would align the security of SIP and WebRTC. As we all know, WebRTC went
down many of the paths that it did for the sake of backwards compatibility<= br> with SIP, and it would be a shame if the effort to interwork the two
proved futile because of lack of e2e SRTP. Consent would be another prong of that. So maybe writing ICE in as a foregone conclusion in the service of that goal would let us skip some unnecessary deliberation. Getting
plausible interworking with WebRTC could also provide some further
incentive for implementers to crack open their SIP implementations.

If a "grand unified theory" is the goal, then this also confor= ms nicely
with Cullen's recent efforts to figure out how to get STIR and WebRTC's
IdP aligned. As my strawman proposal for SIP media confidentiality had
both a STIR story and an opportunistic story, we could argue that getting alignment of identity, consent, and encryption could be grouped under one effort, which is mostly about getting offer/answer to deal with those
three things in a common way - especially as WebRTC IdP today conveys that<= br> identity information as an SDP attribute.

Realigning Offers[/Answers]: The Grand Unified Theory?

Jon Peterson
Neustar, Inc.

On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach"
<dispatch-bounces@ietf.org on behalf of adam@nostrum.com<mailto= :dispatch-bounces@ietf.org%20on%20behalf%20of%20adam@nostrum.com>>= ; wrote:

As early as 2005, we identified a class of DoS attack that would be
enabled by SIP systems, if widely deployed on the public internet.
Called the "Voice Hammer," this attack involves triggering potent= ially
vast quantities of media traffic towards a target using normal SIP call
setup procedures.

While I don't think this is something that SIPBRANDY is required to
address, I would like it to be part of the discussion. I believe this
makes sense for two reasons: (1) I expect the recommendations that come
out of SIPBRANDY to require non-trivial endpoint changes, and it would
be good to consider coupling breaking changes to each other so as to
minimize the number of potential modes of operation; and (2) the issue
is fundamentally a security issue -- albeit of a different nature --
which would seem to require the same set of expertise as the other
problems SIPBRANDY will work on.

To that end, I propose adding the following sentence to the "Object= ives"
paragraph in the SIPBRANDY charter:

"The working group may also define best practices for ensuring
recipients of media flows have consented to receive such flows, in order to prevent or mitigate the denial-of-service attack described in RFC
5245, section 18.5.1."

To be clear: I do not wish to presuppose that the solution to this
problem will be ICE, or that it even is required in order for the WG to
declare success. I just want it to be available for consideration.

/a

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

dispatch mailing list
dispatch@ietf.orgdispatch@ietf.org
https://www.ietf= .org/mailman/listinfo/dispatch

--_000_9F33F40F6F2CD847824537F3C4E37DDF26139546MCHP04MSXglobal_-- From nobody Fri Jun 10 03:11:14 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09A5312D878 for ; Fri, 10 Jun 2016 03:11:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopebailie.com 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 ECHFlJhiWudJ for ; Fri, 10 Jun 2016 03:11:10 -0700 (PDT) Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35D9B12B05C for ; Fri, 10 Jun 2016 03:11:08 -0700 (PDT) Received: by mail-oi0-x231.google.com with SMTP id p204so105075494oih.3 for ; Fri, 10 Jun 2016 03:11:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopebailie.com; s=google; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Q0LEpS9Y2Xmo4Dv5QJGNPZ8kK+zL5K+cXBxeJhuvzOs=; b=EQx1ac+IeYt+bh4OulNXjMOgHtvWpnUh9XCgZuQAwlWFuof1P9nydVC6BdREA/TbgW GvrDMZ+XJAVNws3CTxCIFbfswXHmdBYHm1xKRq7BGa1oaeWEcsLsk9pUBl/rhKX0rt+u b7QlxTNheBH/tdHcInZlxd8pzx1DR1hYiNvpM= 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:from:date :message-id:subject:to:cc; bh=Q0LEpS9Y2Xmo4Dv5QJGNPZ8kK+zL5K+cXBxeJhuvzOs=; b=l3YLD933pJdNESV/puXGEkD9VothDusZV//viwuOo/pcc8hYiN0DMfeHMAVklOhwW2 crQl/BajtGUOt8xCYpG7QqYJdIvg+aDbwUSW5ipakHUD+sZDBLOskbsjjsWictAhwmSk xcCZtkCMeduRg20ZPxwAD/gdXFpPknG2iVNoUrT7k00tzNCIzeVQkgcBUK7hcPHjMxJ7 7czFqyrN3hcr+ysoDvqAfs0rgBNnjhllHmyCslG6BsCU3/OT4VYsw/RS6RCuRoNCbzLy mtn44/SvLLaRYtl6RuINZSfgR8BBce6OvG2aoY6IGNmrlWbA/vZ0mp6l8BUQmoKvu2kv IXXw== X-Gm-Message-State: ALyK8tL1C05t4wP1a5Ip75S7kKAJXxRMiJsq716Hx2wREqXSxmTHKeOvKgcFYy+E/cgyVs0Mc0ObulJPq6Vjcw== X-Received: by 10.202.73.11 with SMTP id w11mr439362oia.139.1465553467494; Fri, 10 Jun 2016 03:11:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.202.1.138 with HTTP; Fri, 10 Jun 2016 03:11:06 -0700 (PDT) In-Reply-To: <9BD348A9-CFA2-4213-9C6B-B4FE368A8EB4@cisco.com> References: <1127651464816168@web30h.yandex.ru> <19db51ff-72ca-6769-22ca-3daf768b3fb7@nostrum.com> <567581465417712@web30m.yandex.ru> <9BD348A9-CFA2-4213-9C6B-B4FE368A8EB4@cisco.com> From: Adrian Hope-Bailie Date: Fri, 10 Jun 2016 12:11:06 +0200 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a113db17ad47db90534e9c1be Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] Introducing the Interledger Protocol X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 10:11:13 -0000 --001a113db17ad47db90534e9c1be Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I co-chair the Web Payments WG and the Interledger Payments CG at W3C so happy to dig into the difference if there is any confusion. Briefly, the Payments WG has a very specific mandate as explained in it's charter. [1] I would summarize this as defining a mechanism for a machine readable payment request to be handled by some mediator system (usually a user agent) on the Web and if necessary passed on to a payment application capable of handling that request and returning a response. This work is completely payment method agnostic and intended to simply define standard interfaces and message formats for the exchange of information in initiating payment. The first deliverables of this WG are a browser API for handling payment requests and there are other specs in the works for an HTTP API, a payment app registration/invocation standard and a number of message definitions for well known payment methods like card payments, and SEPA based payments. In contrast the Interledger work is an attempt to define an entirely new payment method/scheme specifically for the Internet. It is a ground up protocol stack for actually making a payment (including settlement of funds) that is not specific to a payment network or ledger/custodian system= . We think of Interledger as the TCP/IP for digital assets, where TCP/IP moves packets Interledger moves money. We have proposed a BoF session for Berlin and I will be able to dive deeper into the work of both groups if there is interest. [1] - https://www.w3.org/Payments/WG/charter-201510.html On 9 June 2016 at 18:28, Cullen Jennings (fluffy) wrote: > > Just as some random links that might be useful for IETF folks .. > > You can find more info about W3C payments WG at > https://www.w3.org/Payments/WG/ > > It does not seem to have much to do with what is proposed here. > > Note there is a W3C community group for the interledger work. This is > roughly equivalent to the IETF non WG email list and does not indicate an > endorsement or course of action for the W3C. It is at > > https://www.w3.org/community/interledger/ > > It's not clear to me how you join the mailing list without agreeing to > certain legal terms but the archives seem to be public at > > https://lists.w3.org/Archives/Public/public-interledger/ > > > > > On Jun 8, 2016, at 2:28 PM, =D0=A2=D0=B2=D0=B5=D1=80=D0=B5=D1=82=D0=B8= =D0=BD =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B5= =D0=B2=D0=B8=D1=87 < > tveretinas@yandex.ru> wrote: > > > > Surely, I refer to the Payment WG at W3C. > > I did not know about efforts here. But ISPP charter reminds me of a > problem. > > There is good software to manage business accounts (based on digital > signatures), but not for non-business accounts, and something strange for > e-money. But in practice, there could be no difference between B2B and B2= C. > When I pay to my ISP, this is B2B payment if I use the Net for business, = or > B2C if I do not. But the amount is the same, really nothing changes. > > So "retail payments" is a non-existing problem. Possibly this is the > reason why ISPP could not produce anything. > > > > I publish NGMTP specs at . > Currently, only "account chain" is there. > > Possibly, we should discuss some decisions in Q&A format. > > > > 02.06.2016, 20:59, "Adam Roach" : > >> On 6/2/16 09:16, Adrian Hope-Bailie wrote: > >>> I wasn't aware of a Payments WG at IETF or of NGMTP. > >>> Can you provide a link to some resources or a mailing list archive = so > >>> i can get myself up to speed? > >> > >> I'm not sure offhand which Working Group Anton is referring to. As fa= r > >> as I'm able to turn up, there have only been two working groups in th= e > >> IETF's history that dealt squarely with payment-related technologies: > >> > >> The ISPP (Internet Secure Payments Protocol) WG concluded in January = of > >> 1997. The charter at its time of conclusion is here: > >> https://datatracker.ietf.org/wg/ispp/charter/ > >> > >> The TRADE (Internet Open Trading Protocols) concluded in Feburary of > >> 2005. The charter at its time of conclusion is here: > >> https://datatracker.ietf.org/wg/trade/charter/ > >> > >> Both working groups predate any centrally-coordinated mailing list > >> archiving by the IETF, and the archives of their mailing list > >> discussions no longer appear to be online. They also date back to a > >> period of time in which internet drafts were aggressively removed fro= m > >> the internet after their six-month expiration period, so tracing thei= r > >> work output to the generated RFCs is not terribly straightforward. > >> > >> TRADE's main output relic appears to be the Internet Open Trading > >> Protocol (IOTP), documented in RFCs 2801 - 2803, and RFC 3504. There > >> appears to have been an effort started to define a v2 of the protocol= , > >> but that work does not appear to have borne fruit. See also > >> < > https://mailarchive.ietf.org/arch/msg/apps-discuss/IrAZ4SN99WHCLEii7gZvTP= ibTNY > >. > >> > >> I can't figure out whether ISPP produced any RFCs at all. > >> > >> /a > > > > _______________________________________________ > > 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 > --001a113db17ad47db90534e9c1be Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I co-chair the Web Paym= ents WG and the Interledger Payments CG at W3C so happy to dig into the dif= ference if there is any confusion.

Briefly, the Payments WG ha= s a very specific mandate as explained in it's charter. [1]

I would summarize this as defining a mechanism for a machine readable pay= ment request to be handled by some mediator system (usually a user agent) o= n the Web and if necessary passed on to a payment application capable of ha= ndling that request and returning a response.

This work is com= pletely payment method agnostic and intended to simply define standard inte= rfaces and message formats for the exchange of information in initiating pa= yment.

The first deliverables of this WG are a browser API for= handling payment requests and there are other specs in the works for an HT= TP API, a payment app registration/invocation standard and a number of mess= age definitions for well known payment methods like card payments, and SEPA= based payments.

In contrast the Interledger work is an attemp= t to define an entirely new payment method/scheme specifically for the Inte= rnet. It is a ground up protocol stack for actually making a payment (inclu= ding settlement of funds) that is not specific to a payment network or ledg= er/custodian system.

We think of Interledger as the TCP/IP for= digital assets, where TCP/IP moves packets Interledger moves money.
We have proposed a BoF session for Berlin and I will be able to dive= deeper into the work of both groups if there is interest.

On 9 June 2016 at 18:28, Cullen Jennings (fluffy) <f= luffy@cisco.com> wrote:
Just as some random links that might be useful for IETF folks ..

You can find more info about W3C payments WG at
https://www.w3.org/Payments/WG/

It does not seem to have much to do with what is proposed here.

Note there is a W3C community group for the interledger work. This is rough= ly equivalent to the IETF non WG email list and does not indicate an endors= ement or course of action for the W3C. It is at

https://www.w3.org/community/interledger/

It's not clear to me how you join the mailing list without agreeing to = certain legal terms but the archives seem to be public at

https://lists.w3.org/Archives/Public/public-= interledger/



> On Jun 8, 2016, at 2:28 PM, =D0=A2=D0=B2=D0=B5=D1=80=D0=B5=D1=82=D0=B8= =D0=BD =D0=90=D0=BD=D1=82=D0=BE=D0=BD =D0=A1=D0=B5=D1=80=D0=B3=D0=B5=D0=B5= =D0=B2=D0=B8=D1=87 <tveretinas@y= andex.ru> wrote:
>
> Surely, I refer to the Payment WG at W3C.
> I did not know about efforts here. But ISPP charter reminds me of a pr= oblem.
> There is good software to manage business accounts (based on digital s= ignatures), but not for non-business accounts, and something strange for e-= money. But in practice, there could be no difference between B2B and B2C. W= hen I pay to my ISP, this is B2B payment if I use the Net for business, or = B2C if I do not. But the amount is the same, really nothing changes.
> So "retail payments" is a non-existing problem. Possibly thi= s is the reason why ISPP could not produce anything.
>
> I publish NGMTP specs at <http://www.fit-rulez.narod.ru/= ngmtp/>. Currently, only "account chain" is there.
> Possibly, we should discuss some decisions in Q&A format.
>
> 02.06.2016, 20:59, "Adam Roach" <adam@nostrum.com>:
>>=C2=A0 On 6/2/16 09:16, Adrian Hope-Bailie wrote:
>>>=C2=A0 =C2=A0I wasn't aware of a Payments WG at IETF or of = NGMTP.
>>>=C2=A0 =C2=A0Can you provide a link to some resources or a mail= ing list archive so
>>>=C2=A0 =C2=A0i can get myself up to speed?
>>
>>=C2=A0 I'm not sure offhand which Working Group Anton is referr= ing to. As far
>>=C2=A0 as I'm able to turn up, there have only been two working= groups in the
>>=C2=A0 IETF's history that dealt squarely with payment-related = technologies:
>>
>>=C2=A0 The ISPP (Internet Secure Payments Protocol) WG concluded in= January of
>>=C2=A0 1997. The charter at its time of conclusion is here:
>>=C2=A0 https://datatracker.ietf.org/wg/ispp/cha= rter/
>>
>>=C2=A0 The TRADE (Internet Open Trading Protocols) concluded in Feb= urary of
>>=C2=A0 2005. The charter at its time of conclusion is here:
>>=C2=A0 https://datatracker.ietf.org/wg/trade/c= harter/
>>
>>=C2=A0 Both working groups predate any centrally-coordinated mailin= g list
>>=C2=A0 archiving by the IETF, and the archives of their mailing lis= t
>>=C2=A0 discussions no longer appear to be online. They also date ba= ck to a
>>=C2=A0 period of time in which internet drafts were aggressively re= moved from
>>=C2=A0 the internet after their six-month expiration period, so tra= cing their
>>=C2=A0 work output to the generated RFCs is not terribly straightfo= rward.
>>
>>=C2=A0 TRADE's main output relic appears to be the Internet Ope= n Trading
>>=C2=A0 Protocol (IOTP), documented in RFCs 2801 - 2803, and RFC 350= 4. There
>>=C2=A0 appears to have been an effort started to define a v2 of the= protocol,
>>=C2=A0 but that work does not appear to have borne fruit. See also<= br> >>=C2=A0 <htt= ps://mailarchive.ietf.org/arch/msg/apps-discuss/IrAZ4SN99WHCLEii7gZvTPibTNY= >.
>>
>>=C2=A0 I can't figure out whether ISPP produced any RFCs at all= .
>>
>>=C2=A0 /a
>
> _______________________________________________
> 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

--001a113db17ad47db90534e9c1be-- From nobody Fri Jun 10 12:17:56 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7F2912D113; Fri, 10 Jun 2016 12:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.699 X-Spam-Level: X-Spam-Status: No, score=-102.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 4oa9xDhtEb0Q; Fri, 10 Jun 2016 12:17:53 -0700 (PDT) Received: from mail-oi0-x232.google.com (mail-oi0-x232.google.com [IPv6:2607:f8b0:4003:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0488F12D13E; Fri, 10 Jun 2016 12:17:52 -0700 (PDT) Received: by mail-oi0-x232.google.com with SMTP id k23so127004987oih.0; Fri, 10 Jun 2016 12:17:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:cc; bh=FM8J2whsdyWYdf+tvj8KdSoMvG3sbHryzzBgxSwRv5E=; b=g0YhOwOYWRW/iYdqlWGjTMPdLs2TsOXZrhFMTJVSICWUri/k/GdeBJeIWt1A+ogLBM NIvlEg2hsC2zFoDpsEbhwUExr0kHSbAP7Skv4usdPOjuV3awfyNw80yIOyPm5KK0pOnM YzzsObPE33vR3CjkDp6Rbx4ro0fTot9dVn7uHw3bIyjpJ7hnWSsdIftEPghsFGdrQOD7 Wbe4S0RRTnUH1E/4wnqK+3jqptBU8NmU5pL+gx6RrXzR+uA99e25kPZ8jXjdWqdD4ShU FxwnoTaXAU0zrH3RA0lLh2YxSAgigEYcw6XztVOBj/txT0HugLreB6jXdLex8wpCj7XX 3zoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=FM8J2whsdyWYdf+tvj8KdSoMvG3sbHryzzBgxSwRv5E=; b=fK6kU3975x3/sq+YjnW3NcxRZbcPR4VkPgnKXHXiNPmWFz0XUHeBAaOoPRsKL8aNsJ /q0VuLHGN/Zn9Xtt7uy/GeoI+XYqPaElIllNzv5HrMrVacKH6hT3++IlW0XPRqvgG6jy 81whZuKHSsuMfIEASxzPcLeCeBQh+eijj5p5ALrtldguviYeX5ki3JaK/ffigiscXFC+ 7eU/ecBGrCGzCcKgbNNVGW39SjVhT4p/aLMQpGj6xXx/xQVGYNB+9Bp91iI+BExpICuf pXO+jNKRzDD5TxWWzXfRvXz5x33j1H8kcxkbaLFqI7SHR8aNrnnVG1hlpaePIPVPpQDG RAgA== X-Gm-Message-State: ALyK8tLqX8x2boqhLQkrlxsZUohKu/SdICrnv5vt43SXcqiUequAuXl9xAX5QiU85AVLGdoPzf0bTmUlrn6ufA== X-Received: by 10.202.219.86 with SMTP id s83mr2164219oig.167.1465586272345; Fri, 10 Jun 2016 12:17:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.47.101 with HTTP; Fri, 10 Jun 2016 12:17:51 -0700 (PDT) From: Mary Barnes Date: Fri, 10 Jun 2016 14:17:51 -0500 Message-ID: To: DISPATCH Content-Type: multipart/alternative; boundary=001a113d506826a2f60534f1655c Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , ART ADs Subject: [dispatch] Reminder: DISPATCH deadlines for IETF-96 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 19:17:55 -0000 --001a113d506826a2f60534f1655c Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, As a reminder, the following are the deadlines for IETF-96: - June 10, 2016. Cutoff date to notify the chairs/DISPATCH WG of plans to submit a proposal. (draft deadline =E2=80=93 4 weeks) - June 17, 2016. Cutoff for charter proposals for topics.(draft deadline = =E2=80=93 3 weeks) - June 24, 2016. Announcement of topics that have been dispatched for IETF-95. (draft deadline =E2=80=93 2 weeks) - July 8, 2016. Draft deadline. At this point, the only new topic put forth is Inter-ledger, for which an official Bof has been proposed. Please let the chairs know ASAP if you have a topic for which you would like f2f discussion. Regards, Mary. --001a113d506826a2f60534f1655c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

As a reminder, the following ar= e the deadlines for IETF-96:
- June 10, 2016. Cutoff date to= notify the chairs/DISPATCH WG of plans to submit a proposal. (draft deadli= ne =E2=80=93 4 weeks)
- June 17, 2016. Cutoff for charter proposa= ls for topics.(draft deadline =E2=80=93 3 weeks)
- June 24, 2016.= Announcement of topics that have been dispatched for IETF-95. (draft deadl= ine =E2=80=93 2 weeks)
- July 8, 2016. Draft deadline.

At this point, the only new topic put forth is Inter-l= edger, for which an official Bof has been proposed.=C2=A0 Please let the ch= airs know ASAP if you have a topic for which you would like f2f discussion.=

Regards,
Mary.

--001a113d506826a2f60534f1655c-- From nobody Fri Jun 10 15:41:34 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6172C12B063 for ; Fri, 10 Jun 2016 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 rU5rq-2H3YtJ for ; Fri, 10 Jun 2016 15:41:31 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EABC012B00B for ; Fri, 10 Jun 2016 15:41:30 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5AMfTct034463 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2016 17:41:30 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: draft-pd-dispatch-msrp-websocket.all@tools.ietf.org Date: Fri, 10 Jun 2016 17:41:29 -0500 Message-ID: <9957D411-C669-4490-9198-18F27A5650A7@nostrum.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="=_MailMate_E810A3B9-B1DB-4D86-969F-2CA6C9DC86BB_=" X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: DISPATCH Subject: [dispatch] AD Evaluation of draft-pd-dispatch-msrp-websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 22:41:32 -0000 --=_MailMate_E810A3B9-B1DB-4D86-969F-2CA6C9DC86BB_= Content-Type: text/plain; format=flowed; markup=markdown Hi, This is my AD Evaluation of draft-pd-dispatch-msrp-websocket. I have a few editorial comments, but nothing that should block going to IETF last call. I will request the last call shortly. Thanks! Ben. ----------------------- -1, last paragraph: Consider citing RFC4976 for "MSRP relay". (I also suggest citations to 4975 and 4976 when you talk about "normal" clients and relays. -5.1, first paragraph: "...messages MUST be routed via an MSRP WebSocket Server" This seems more a statement of fact than a normative requirement. That is, it is an implication of the fact that websocket clients cannot directly connect to other websocket clients. Please consider removing the upper-case MUST. - 5.3.1. 4th paragraph (1st after numbered list): s/event/even --=_MailMate_E810A3B9-B1DB-4D86-969F-2CA6C9DC86BB_= Content-Type: text/html Content-Transfer-Encoding: quoted-printable

Hi,

This is my AD Evaluation of draft-pd-dispatch-msrp-websoc= ket. I have a few editorial comments, but nothing that should block going= to IETF last call. I will request the last call shortly.

Thanks!

Ben.

-1, last paragraph: Consider citing RFC4976 for "MSRP rel= ay". (I also suggest citations to 4975 and 4976 when you talk about "norm= al" clients and relays.

-5.1, first paragraph: "...messages MUST be routed
via an MSRP WebSocket Server"

This seems more a statement of fact than a normative requ= irement. That is, it is an implication of the fact that websocket clients= cannot directly connect to other websocket clients. Please consider remo= ving the upper-case MUST.

  • 5.3.1. 4th paragraph (1st after numbered list): s/event/even
--=_MailMate_E810A3B9-B1DB-4D86-969F-2CA6C9DC86BB_=-- From nobody Fri Jun 10 15:52:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90E9712D9BC for ; Fri, 10 Jun 2016 15:52:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 j6FZ5aa-IIXN for ; Fri, 10 Jun 2016 15:52:09 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 451E012D7E2 for ; Fri, 10 Jun 2016 15:52:09 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5AMq8AZ035311 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 10 Jun 2016 17:52:08 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: draft-pd-dispatch-msrp-websocket.all@tools.ietf.org Date: Fri, 10 Jun 2016 17:52:08 -0500 Message-ID: In-Reply-To: <9957D411-C669-4490-9198-18F27A5650A7@nostrum.com> References: <9957D411-C669-4490-9198-18F27A5650A7@nostrum.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] AD Evaluation of draft-pd-dispatch-msrp-websocket X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jun 2016 22:52:11 -0000 One more thing: IDNits emits the following: -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at http://trustee.ietf.org/license-info for more information.) . Is any part of the document that old? I suspect this is due to the update of 4975 and 4976. Do you incorporate substantial text or examples from those RFCs? If not, I'm not sure we need the disclaimer. (I vaguely recall discussing this before, but maybe that was for a different MSRP related draft.) Ben. On 10 Jun 2016, at 17:41, Ben Campbell wrote: > Hi, > > This is my AD Evaluation of draft-pd-dispatch-msrp-websocket. I have a > few editorial comments, but nothing that should block going to IETF > last call. I will request the last call shortly. > > Thanks! > > Ben. > > ----------------------- > > -1, last paragraph: Consider citing RFC4976 for "MSRP relay". (I also > suggest citations to 4975 and 4976 when you talk about "normal" > clients and relays. > > -5.1, first paragraph: "...messages MUST be routed > via an MSRP WebSocket Server" > > This seems more a statement of fact than a normative requirement. That > is, it is an implication of the fact that websocket clients cannot > directly connect to other websocket clients. Please consider removing > the upper-case MUST. > > - 5.3.1. 4th paragraph (1st after numbered list): s/event/even From nobody Mon Jun 13 06:33:12 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3EF412D0A0 for ; Mon, 13 Jun 2016 06:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 YbqHGHEKarTP for ; Mon, 13 Jun 2016 06:33:08 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 942DB12D0A2 for ; Mon, 13 Jun 2016 06:33:08 -0700 (PDT) Received: from [10.10.1.2] ([162.216.46.118]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5DDX5X1086577 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Mon, 13 Jun 2016 08:33:07 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host [162.216.46.118] claimed to be [10.10.1.2] From: "Ben Campbell" To: "Hutton, Andrew" Date: Mon, 13 Jun 2016 14:33:05 +0100 Message-ID: <5F1BFF8C-4A67-469B-92B5-A825C83C2A3F@nostrum.com> In-Reply-To: <9F33F40F6F2CD847824537F3C4E37DDF26139546@MCHP04MSX.global-ad.net> References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> <4F089A43-39F3-42B3-B059-51E0069ECF17@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26139546@MCHP04MSX.global-ad.net> MIME-Version: 1.0 Content-Type: text/plain; format=flowed Content-Transfer-Encoding: quoted-printable X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 13:33:11 -0000 The latest revision of the proposed SIPBRANDY charter includes PERC in = the list of groups to be coordinated with. Is that insufficient? (It = seems like overkill to revise the PERC charter just to mention = coordination with SIPBRANDY). Ben. On 10 Jun 2016, at 10:47, Hutton, Andrew wrote: > My concern is that we have one group looking at SIP media security for = > multi-party sessions (PERC) and another looking at SIP media security = > for two party sessions (SIPBRANDY) and neither of the WG charters = > state that the work needs to be coordinated. > > It might be obvious that they will be coordinated and that the same = > people will probably work on both and I assume that everybody would be = > sad if they came up with incompatible solutions but personally I think = > it would be good for the charter to say something about this. However = > if I am alone on this and we want to leave it to the working groups to = > work it out then I can live with that. > > Regards > Andy > > > > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 09 June 2016 21:38 > To: Hutton, Andrew > Cc: dispatch@ietf.org > Subject: Re: [dispatch] SIPBRANDY and other dangers > > > On 9 Jun 2016, at 5:17, Hutton, Andrew wrote: > > The upda > ted charter states "the WG may consider compatibility with aspects of = > PERC" but does not give any further guidance as to why this might be = > necessary unlike the text in the same paragraph referring to WebRTC = > and MMUSIC which does give some reasons why some consideration might = > be needed. > > In the case of PERC I think it is important to note that a SIP = > endpoint must be able to negotiate using SDP offer/answer either a two = > party (SIPBrandy) or a multi-party session (PERC) without prior = > knowledge of which one will be used. I think it would be useful to = > have this in the charter to make it clear, any other views on this? > > Speaking as an individual, I don't think that requirement belongs in = > the charter. I'd rather leave it to the working group to do the right = > thing, and I'm not convinced we know for sure what that right thing is = > at this point in the process. I think there's a real risk of over = > constraining things if we are not careful. > > If others have an opinion, please speak up asap. > > Thanks! > > Ben. > > Regards > Andy > > From: dispatch = > [mailto:dispatch-bounces@ietf.org] = > On Behalf Of Ben Campbell > Sent: 08 June 2016 21:08 > To: dispatch@ietf.org > Subject: Re: [dispatch] SIPBRANDY and other dangers > > I just made a minor update to say that SIPBRANDY may consider = > compatibility with aspects of PERC, and added PERC to the = > collaboration list. This is in response to some offline comments. > > I invite comments (still to dispatch) about whether we should include = > that addition, or if we need any stronger requirements in that area. > > Thanks! > > Ben. > > On 6 Jun 2016, at 15:27, Ben Campbell wrote: > > The most recent proposed text is at = > https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . > > Ben. > > On 6 Jun 2016, at 15:25, Ben Campbell wrote: > > Since no one complained, and a few people expressed support directly = > to me offline, I added that text to the proposed charter, along with = > adding RTCWEB to the list of groups in the "expected to coordinate = > with" paragraph. > > I will put this on the agenda for internal review on the next IESG = > telechat. That should not shut down discussion, so if people have = > further thoughts, please comment as soon as possible. > > Thanks! > > Ben. > > On 26 May 2016, at 19:55, Ben Campbell wrote: > > Hi Jon, > > As an individual, I'm afraid the association of this effort with other = > great unsolved problems (Great Unsolved Theories?) may be prophetic. = > (Also, the implied acronym :-) ) I'd be happy if we just solved e2e = > confidentiality. And I don't think we would be happy if we solved all = > the other things and not e2e confidentiality. > > It also seems to me that aligning identity models fits more with STIR = > than with this group. > > That being said, what about something like the following: > > "While confidentiality is the first priority of the working group, it = > may work on aligning these practices with WebRTC, for example by = > defining best practices for ensuring recipients of media flows have = > consented to receive such flows, in order to prevent or mitigate the = > denial-of-service attack described in RFC 5245, section 18.5.1." > > Ben. > > On 26 May 2016, at 19:05, Peterson, Jon wrote: > > It would be a fairly significant change to the proposed scope, but = > perhaps > one that's warranted. > > I understand why you have some process caution here about scoping a > consent mechanism to ICE at the outset, but if we're going to put this > problem under SIPPRANDY's umbrella, I think it could make sense to set = > the > explicit goal of getting a "grand unified theory" of VoIP security = > that > would align the security of SIP and WebRTC. As we all know, WebRTC = > went > down many of the paths that it did for the sake of backwards = > compatibility > with SIP, and it would be a shame if the effort to interwork the two > proved futile because of lack of e2e SRTP. Consent would be another = > prong > of that. So maybe writing ICE in as a foregone conclusion in the = > service > of that goal would let us skip some unnecessary deliberation. Getting > plausible interworking with WebRTC could also provide some further > incentive for implementers to crack open their SIP implementations. > > If a "grand unified theory" is the goal, then this also conforms = > nicely > with Cullen's recent efforts to figure out how to get STIR and = > WebRTC's > IdP aligned. As my strawman proposal for SIP media confidentiality had > both a STIR story and an opportunistic story, we could argue that = > getting > alignment of identity, consent, and encryption could be grouped under = > one > effort, which is mostly about getting offer/answer to deal with those > three things in a common way - especially as WebRTC IdP today conveys = > that > identity information as an SDP attribute. > > Realigning Offers[/Answers]: The Grand Unified Theory? > > Jon Peterson > Neustar, Inc. > > On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" > adam@nostrum.com>> = > wrote: > > As early as 2005, we identified a class of DoS attack that would be > enabled by SIP systems, if widely deployed on the public internet. > Called the "Voice Hammer," this attack involves triggering potentially > vast quantities of media traffic towards a target using normal SIP = > call > setup procedures. > > While I don't think this is something that SIPBRANDY is required to > address, I would like it to be part of the discussion. I believe this > makes sense for two reasons: (1) I expect the recommendations that = > come > out of SIPBRANDY to require non-trivial endpoint changes, and it would > be good to consider coupling breaking changes to each other so as to > minimize the number of potential modes of operation; and (2) the issue > is fundamentally a security issue -- albeit of a different nature -- > which would seem to require the same set of expertise as the other > problems SIPBRANDY will work on. > > To that end, I propose adding the following sentence to the = > "Objectives" > paragraph in the SIPBRANDY charter: > > "The working group may also define best practices for ensuring > recipients of media flows have consented to receive such flows, in = > order > to prevent or mitigate the denial-of-service attack described in RFC > 5245, section 18.5.1." > > To be clear: I do not wish to presuppose that the solution to this > problem will be ICE, or that it even is required in order for the WG = > to > declare success. I just want it to be available for consideration. > > /a > > ________________________________ > > dispatch mailing list > dispatch@ietf.orgdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > ________________________________ > > dispatch mailing list > dispatch@ietf.orgdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > ________________________________ > > dispatch mailing list > dispatch@ietf.orgdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > ________________________________ > > dispatch mailing list > dispatch@ietf.orgdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > ________________________________ > > dispatch mailing list > dispatch@ietf.orgdispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From sunsinha@cisco.com Mon Jun 13 10:02:29 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E3F8112B044; Mon, 13 Jun 2016 10:02:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.946 X-Spam-Level: X-Spam-Status: No, score=-15.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 y-Hs32urrL6r; Mon, 13 Jun 2016 10:02:28 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493C512B02D; Mon, 13 Jun 2016 10:02:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5439; q=dns/txt; s=iport; t=1465837348; x=1467046948; h=from:to:cc:subject:date:message-id:mime-version; bh=/DWJfVKr2JF10D0z/nKTu8LEkxmgz645FjnGnPRk/ss=; b=Ew6OGMCRu08EHcsvQj8QYE2J5O2rYi0ryAWJwFMkrSd0GjKUeuKu/TJc qqN5pgSk9L20vH3ZFKlJa9Fg7TaHwGi2duqyZxQ12IUPmZgCQzj4fYawm ZhVF2EoRiQCTnsGjmXaGFXbvB5hj/PUjbBkNOLkyHbS9kH5bfniY8YFsU Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AYAgDF5l5X/4kNJK1bgnBOVoEDtiWFA?= =?us-ascii?q?IF5hheBLzgUAQEBAQEBAWUnhFEtTBIBbRMmAQQBDQ2IKLhtAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBHIUQig6FcQWYYQEWjgqPJ49tAR42g26Jd38BAQE?= X-IronPort-AV: E=Sophos;i="5.26,467,1459814400"; d="scan'208,217";a="114742925" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 13 Jun 2016 17:02:26 +0000 Received: from XCH-RCD-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u5DH2QYs006679 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 13 Jun 2016 17:02:26 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 13 Jun 2016 12:02:25 -0500 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.009; Mon, 13 Jun 2016 12:02:25 -0500 From: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" To: "dispatch@ietf.org" , "dispatch-chairs@ietf.org" Thread-Topic: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt Thread-Index: AdHFlJEhaneqYG0URxe35EkgjfJfqA== Date: Mon, 13 Jun 2016 17:02:25 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.65.91.96] Content-Type: multipart/alternative; boundary="_000_a1ddab8922844440858788515c4e0009XCHALN015ciscocom_" MIME-Version: 1.0 Archived-At: Cc: "Sankar Raman V -X \(sramanv - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco\)" Subject: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:06:04 -0000 --_000_a1ddab8922844440858788515c4e0009XCHALN015ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We've submitted a new draft, draft-sunil-sankar-dispatch-sip-incr-00.txt. The purpose of the draft is to register a new optional tag called "incr" as= an extension for the SIP Message indicating that only those header(s) will= be present in the subsequent request or response whose attribute is change= d. This is necessary to increase the processing speed of any proxy server a= nd also prevents fragmentation of messages over UDP and provides congestion Regards, Sunil Sinha --_000_a1ddab8922844440858788515c4e0009XCHALN015ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We’ve submitted a new draft, draft-sunil-sankar-dispa= tch-sip-incr-00.txt.

 

The purpose of the draft is to register a ne= w optional tag called "incr" as an extension for the SIP Message = indicating that only those header(s) will be present in the subsequent request or response whose attribute is changed. This is nec= essary to increase the processing speed of any proxy server and also preven= ts fragmentation of messages over UDP and provides congestion

 

Regards,

Sunil Sinha

 

--_000_a1ddab8922844440858788515c4e0009XCHALN015ciscocom_-- From nobody Mon Jun 13 10:08:04 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C61E312D8B3 for ; Mon, 13 Jun 2016 10:08:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.601 X-Spam-Level: X-Spam-Status: No, score=-102.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 VZkC66sBVRGA for ; Mon, 13 Jun 2016 10:07:59 -0700 (PDT) Received: from mx0b-0018ba01.pphosted.com (mx0b-0018ba01.pphosted.com [67.231.157.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B7D012D8AD for ; Mon, 13 Jun 2016 10:07:59 -0700 (PDT) Received: from pps.filterd (m0078668.ppops.net [127.0.0.1]) by mx0b-0018ba01.pphosted.com (8.16.0.17/8.16.0.17) with SMTP id u5DH2jag008485; Mon, 13 Jun 2016 13:07:58 -0400 Received: from stntexhc12.cis.neustar.com ([156.154.17.216]) by mx0b-0018ba01.pphosted.com with ESMTP id 23gdejca8g-2 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NOT); Mon, 13 Jun 2016 13:07:58 -0400 Received: from STNTEXMB10.cis.neustar.com ([169.254.5.94]) by stntexhc12.cis.neustar.com ([::1]) with mapi id 14.03.0279.002; Mon, 13 Jun 2016 13:07:55 -0400 From: "Peterson, Jon" To: Ben Campbell , "Hutton, Andrew" Thread-Topic: [dispatch] SIPBRANDY and other dangers Thread-Index: AQHRttLyF0uzizBeHk2yQZGrEmJB3Z/LtuEAgACDaICAEP5PgIAAAGSAgAMfVICAAO1JAIAArV+AgADck4CABPYXgP//xrkA Date: Mon, 13 Jun 2016 17:07:54 +0000 Message-ID: References: <5F1BA997-5CC7-46D5-A2D7-9D6E5885FEFC@nostrum.com> <379A6659-7102-4043-AE58-DF8F4C1C5E1A@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26136699@MCHP04MSX.global-ad.net> <4F089A43-39F3-42B3-B059-51E0069ECF17@nostrum.com> <9F33F40F6F2CD847824537F3C4E37DDF26139546@MCHP04MSX.global-ad.net> <5F1BFF8C-4A67-469B-92B5-A825C83C2A3F@nostrum.com> In-Reply-To: <5F1BFF8C-4A67-469B-92B5-A825C83C2A3F@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.6.3.160329 x-originating-ip: [10.96.12.185] Content-Type: text/plain; charset="us-ascii" Content-ID: <8A25E6578870D44CB6A942CBD29EBEF6@neustar.biz> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2016-06-13_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1604210000 definitions=main-1606130191 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] SIPBRANDY and other dangers X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:08:02 -0000 I'd like to think this would be sufficient. At a high level I agree that the best practices for media confidentiality in SIP should take into account any standards we've developed that facilitate end-to-end confidentiality through various kinds of media intermediaries, including conference bridges. But in terms of the charter, I don't think it needs anything more than a requirement for coordination between the groups. Jon Peterson Neustar, Inc. On 6/13/16, 6:33 AM, "dispatch on behalf of Ben Campbell" wrote: >The latest revision of the proposed SIPBRANDY charter includes PERC in >the list of groups to be coordinated with. Is that insufficient? (It >seems like overkill to revise the PERC charter just to mention >coordination with SIPBRANDY). > >Ben. > >On 10 Jun 2016, at 10:47, Hutton, Andrew wrote: > >> My concern is that we have one group looking at SIP media security for >> multi-party sessions (PERC) and another looking at SIP media security >> for two party sessions (SIPBRANDY) and neither of the WG charters >> state that the work needs to be coordinated. >> >> It might be obvious that they will be coordinated and that the same >> people will probably work on both and I assume that everybody would be >> sad if they came up with incompatible solutions but personally I think >> it would be good for the charter to say something about this. However >> if I am alone on this and we want to leave it to the working groups to >> work it out then I can live with that. >> >> Regards >> Andy >> >> >> >> From: Ben Campbell [mailto:ben@nostrum.com] >> Sent: 09 June 2016 21:38 >> To: Hutton, Andrew >> Cc: dispatch@ietf.org >> Subject: Re: [dispatch] SIPBRANDY and other dangers >> >> >> On 9 Jun 2016, at 5:17, Hutton, Andrew wrote: >> >> The upda >> ted charter states "the WG may consider compatibility with aspects of >> PERC" but does not give any further guidance as to why this might be >> necessary unlike the text in the same paragraph referring to WebRTC >> and MMUSIC which does give some reasons why some consideration might >> be needed. >> >> In the case of PERC I think it is important to note that a SIP >> endpoint must be able to negotiate using SDP offer/answer either a two >> party (SIPBrandy) or a multi-party session (PERC) without prior >> knowledge of which one will be used. I think it would be useful to >> have this in the charter to make it clear, any other views on this? >> >> Speaking as an individual, I don't think that requirement belongs in >> the charter. I'd rather leave it to the working group to do the right >> thing, and I'm not convinced we know for sure what that right thing is >> at this point in the process. I think there's a real risk of over >> constraining things if we are not careful. >> >> If others have an opinion, please speak up asap. >> >> Thanks! >> >> Ben. >> >> Regards >> Andy >> >> From: dispatch=20 >> [mailto:dispatch-bounces@ietf.org] >> On Behalf Of Ben Campbell >> Sent: 08 June 2016 21:08 >> To: dispatch@ietf.org >> Subject: Re: [dispatch] SIPBRANDY and other dangers >> >> I just made a minor update to say that SIPBRANDY may consider >> compatibility with aspects of PERC, and added PERC to the >> collaboration list. This is in response to some offline comments. >> >> I invite comments (still to dispatch) about whether we should include >> that addition, or if we need any stronger requirements in that area. >> >> Thanks! >> >> Ben. >> >> On 6 Jun 2016, at 15:27, Ben Campbell wrote: >> >> The most recent proposed text is at >> https://datatracker.ietf.org/doc/charter-ietf-sipbrandy/ . >> >> Ben. >> >> On 6 Jun 2016, at 15:25, Ben Campbell wrote: >> >> Since no one complained, and a few people expressed support directly >> to me offline, I added that text to the proposed charter, along with >> adding RTCWEB to the list of groups in the "expected to coordinate >> with" paragraph. >> >> I will put this on the agenda for internal review on the next IESG >> telechat. That should not shut down discussion, so if people have >> further thoughts, please comment as soon as possible. >> >> Thanks! >> >> Ben. >> >> On 26 May 2016, at 19:55, Ben Campbell wrote: >> >> Hi Jon, >> >> As an individual, I'm afraid the association of this effort with other >> great unsolved problems (Great Unsolved Theories?) may be prophetic. >> (Also, the implied acronym :-) ) I'd be happy if we just solved e2e >> confidentiality. And I don't think we would be happy if we solved all >> the other things and not e2e confidentiality. >> >> It also seems to me that aligning identity models fits more with STIR >> than with this group. >> >> That being said, what about something like the following: >> >> "While confidentiality is the first priority of the working group, it >> may work on aligning these practices with WebRTC, for example by >> defining best practices for ensuring recipients of media flows have >> consented to receive such flows, in order to prevent or mitigate the >> denial-of-service attack described in RFC 5245, section 18.5.1." >> >> Ben. >> >> On 26 May 2016, at 19:05, Peterson, Jon wrote: >> >> It would be a fairly significant change to the proposed scope, but >> perhaps >> one that's warranted. >> >> I understand why you have some process caution here about scoping a >> consent mechanism to ICE at the outset, but if we're going to put this >> problem under SIPPRANDY's umbrella, I think it could make sense to set >> the >> explicit goal of getting a "grand unified theory" of VoIP security >> that >> would align the security of SIP and WebRTC. As we all know, WebRTC >> went >> down many of the paths that it did for the sake of backwards >> compatibility >> with SIP, and it would be a shame if the effort to interwork the two >> proved futile because of lack of e2e SRTP. Consent would be another >> prong >> of that. So maybe writing ICE in as a foregone conclusion in the >> service >> of that goal would let us skip some unnecessary deliberation. Getting >> plausible interworking with WebRTC could also provide some further >> incentive for implementers to crack open their SIP implementations. >> >> If a "grand unified theory" is the goal, then this also conforms >> nicely >> with Cullen's recent efforts to figure out how to get STIR and >> WebRTC's >> IdP aligned. As my strawman proposal for SIP media confidentiality had >> both a STIR story and an opportunistic story, we could argue that >> getting >> alignment of identity, consent, and encryption could be grouped under >> one >> effort, which is mostly about getting offer/answer to deal with those >> three things in a common way - especially as WebRTC IdP today conveys >> that >> identity information as an SDP attribute. >> >> Realigning Offers[/Answers]: The Grand Unified Theory? >> >> Jon Peterson >> Neustar, Inc. >> >> On 5/25/16, 3:15 PM, "dispatch on behalf of Adam Roach" >> >=20 >>adam@nostrum.com>am@nostrum.com>@nostrum.com%3cmailto:dispatch-bounces@ietf.org%20on%20behalf%20of%20adam >>@nostrum.com>>>=20 >> wrote: >> >> As early as 2005, we identified a class of DoS attack that would be >> enabled by SIP systems, if widely deployed on the public internet. >> Called the "Voice Hammer," this attack involves triggering potentially >> vast quantities of media traffic towards a target using normal SIP >> call >> setup procedures. >> >> While I don't think this is something that SIPBRANDY is required to >> address, I would like it to be part of the discussion. I believe this >> makes sense for two reasons: (1) I expect the recommendations that >> come >> out of SIPBRANDY to require non-trivial endpoint changes, and it would >> be good to consider coupling breaking changes to each other so as to >> minimize the number of potential modes of operation; and (2) the issue >> is fundamentally a security issue -- albeit of a different nature -- >> which would seem to require the same set of expertise as the other >> problems SIPBRANDY will work on. >> >> To that end, I propose adding the following sentence to the >> "Objectives" >> paragraph in the SIPBRANDY charter: >> >> "The working group may also define best practices for ensuring >> recipients of media flows have consented to receive such flows, in >> order >> to prevent or mitigate the denial-of-service attack described in RFC >> 5245, section 18.5.1." >> >> To be clear: I do not wish to presuppose that the solution to this >> problem will be ICE, or that it even is required in order for the WG >> to >> declare success. I just want it to be available for consideration. >> >> /a >> >> ________________________________ >> >> dispatch mailing list >>=20 >>dispatch@ietf.orgdispatch@ietf.org>tch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> ________________________________ >> >> dispatch mailing list >>=20 >>dispatch@ietf.orgdispatch@ietf.org>tch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> ________________________________ >> >> dispatch mailing list >>=20 >>dispatch@ietf.orgdispatch@ietf.org>tch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> ________________________________ >> >> dispatch mailing list >>=20 >>dispatch@ietf.orgdispatch@ietf.org>tch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch >> >> ________________________________ >> >> dispatch mailing list >>=20 >>dispatch@ietf.orgdispatch@ietf.org>tch@ietf.org> >> https://www.ietf.org/mailman/listinfo/dispatch >> _______________________________________________ >> 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 Mon Jun 13 10:33:26 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E61D012D8C9; Mon, 13 Jun 2016 10:33:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 u3pjyeDkg9EG; Mon, 13 Jun 2016 10:33:23 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 858F912D86E; Mon, 13 Jun 2016 10:33:22 -0700 (PDT) X-AuditID: c1b4fb25-f79f26d00000327e-f9-575eee605a96 Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 78.03.12926.06EEE575; Mon, 13 Jun 2016 19:33:20 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.154]) by ESESSHC014.ericsson.se ([153.88.183.60]) with mapi id 14.03.0294.000; Mon, 13 Jun 2016 19:32:49 +0200 From: Christer Holmberg To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" , "dispatch@ietf.org" , "dispatch-chairs@ietf.org" Thread-Topic: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt Thread-Index: AdHFlJEhaneqYG0URxe35EkgjfJfqAABASRA Date: Mon, 13 Jun 2016 17:32:49 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B3804F3F6@ESESSMB209.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.150] Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B3804F3F6ESESSMB209erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyM2K7jW7Cu7hwg2XdahZ7Xz9lsVg6aQGr xZQre9gsDs5sZnJg8ZjyeyOrx5IlP5kCmKK4bFJSczLLUov07RK4Mh7dfchesMi1YsXXDsYG xna7LkZODgkBE4lPt6awQ9hiEhfurWfrYuTiEBI4wiixYMd6RghnCaPEwT2nWLoYOTjYBCwk uv9pg8RFBC4wSty+94ERpJtZIFNi3vHLbCC2sECAxOXvIPWcQEWBEnc+fmCHsI0kjrfNBIuz CKhKrN5xAqyXV8BX4uj6tUwgtpCAi8TjeyfAbE4BV4l5XV/AahiBrvt+ag0TxC5xiVtP5jNB XC0gsWTPeWYIW1Ti5eN/rBC2ksSK7ZegbsuXOPHjFjvELkGJkzOfsExgFJ2FZNQsJGWzkJRB xHUkFuz+xAZha0ssW/iaGcY+c+AxE7L4Akb2VYyixanFSbnpRsZ6qUWZycXF+Xl6eaklmxiB UXhwy2/VHYyX3zgeYhTgYFTi4U24HRsuxJpYVlyZe4hRgoNZSYR35tu4cCHelMTKqtSi/Pii 0pzU4kOM0hwsSuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2MMXtvavzueXT8q5Fdoflc7Yg5 3HsTLFat7t6+hrEw6ODRuVnPNbi4i7e+a+YUy1Pg3L9lSX3e76CE7xcZz67eahuQI2dq4W6t YXR7a7r4vsj5atPvB7Ru5/c2aJD29Nl8uXtVbfDnFztXXmLl+Sby+yj/scrwRaX5Xgu+3urM Eqop3n79m6WqEktxRqKhFnNRcSIArKEAP74CAAA= Archived-At: Cc: "Sankar Raman V -X \(sramanv - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco\)" Subject: Re: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:33:25 -0000 --_000_7594FB04B1934943A5C02806D1A2204B3804F3F6ESESSMB209erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, In my experience, there aren't many "unnecessary" headers in mid-dialog req= uests. But, if you think there are, some examples would be useful. Also, just because header values don't change, it doesn't mean they aren't = needed, in order to maintain state. For example, the Route headers are need= ed in case there are call-stateless proxies along the path. Regards, Christer From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Sunil Kumar = Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco) Sent: 13 June 2016 20:02 To: dispatch@ietf.org; dispatch-chairs@ietf.org Cc: Sankar Raman V -X (sramanv - SCARLET WIRELESS INDIA PRIVATE LIMITED at = Cisco) Subject: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt Hi, We've submitted a new draft, draft-sunil-sankar-dispatch-sip-incr-00.txt. The purpose of the draft is to register a new optional tag called "incr" as= an extension for the SIP Message indicating that only those header(s) will= be present in the subsequent request or response whose attribute is change= d. This is necessary to increase the processing speed of any proxy server a= nd also prevents fragmentation of messages over UDP and provides congestion Regards, Sunil Sinha --_000_7594FB04B1934943A5C02806D1A2204B3804F3F6ESESSMB209erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

In my experience, there aren’t many “unnecessary” he= aders in mid-dialog requests. But, if you think there are, some examples wo= uld be useful.

 

Also, just because header values don’t change, it doesn’t = mean they aren’t needed, in order to maintain state. For example, the= Route headers are needed in case there are call-stateless proxies along the path.

 

Regards,

 

Christer

 

From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA= PRIVATE LIMITED at Cisco)
Sent: 13 June 2016 20:02
To: dispatch@ietf.org; dispatch-chairs@ietf.org
Cc: Sankar Raman V -X (sramanv - SCARLET WIRELESS INDIA PRIVATE LIMI= TED at Cisco) <sramanv@cisco.com>
Subject: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-= 00.txt

 

Hi,

 

We’ve submitted a new draft, draft-sun= il-sankar-dispatch-sip-incr-00.txt.

 

The purpose of the draft is to register a new optional tag = called "incr" as an extension for the SIP Message indicating that= only those header(s) will be present in the subsequent request or response whose attribute is changed. This is necessary to incre= ase the processing speed of any proxy server and also prevents fragmentatio= n of messages over UDP and provides congestion

 

Regards,

Sunil Sinha

 

--_000_7594FB04B1934943A5C02806D1A2204B3804F3F6ESESSMB209erics_-- From nobody Mon Jun 13 10:52:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 148E012D8D6 for ; Mon, 13 Jun 2016 10:52:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 8N5SiPn1cE9T for ; Mon, 13 Jun 2016 10:52:10 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 961E112D8D5 for ; Mon, 13 Jun 2016 10:52:08 -0700 (PDT) Received: from resomta-ch2-14v.sys.comcast.net ([69.252.207.110]) by resqmta-ch2-03v.sys.comcast.net with SMTP id CW0Pb8Z0qSVL4CW1vbFgS3; Mon, 13 Jun 2016 17:52:07 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465840327; bh=1M/8xccbnzVvTifzh2jy90JgGuXrlpJdv184DajCJpQ=; h=Received:Received:Received:Received:From:To:Subject:Date: Message-ID; b=LVIjHyLpnNUO40w9dIhJQs4QryU/opueQN54WznQHMCETuOLTsYPlFUBgr3KX+x2E r72cjU31ISxYNjOt+EsBZTNdIaJodg7GWu/f/t75cBj6+PEV/j+Ek1Q5PFQ7TrFzIs gTArfiBBVuzAICi/I0Gc8cQ4sGQVkSwHXe3pMqX7O/0aBHaoWPqzAjf65ltY2hWle9 m0D77vuQW7kb1oh6ArrsjRsFhCnvFaRhJ/45QQhn1QAotTRJ1DVZFNnhtfBHl+44Sr tb0DLmO0s1VHi6g9qSogb3LeY/CZw+snRWAqmj1BYcsyDToX2b4TFNGYS59tSnLWqw h/V5N6yH47P2w== Received: from hobgoblin.ariadne.com ([73.143.237.82]) by resomta-ch2-14v.sys.comcast.net with comcast id 6Hs61t00Z1nMCLR01Hs71o; Mon, 13 Jun 2016 17:52:07 +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 u5DHq6Z7005433; Mon, 13 Jun 2016 13:52:06 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u5DHq68j005430; Mon, 13 Jun 2016 13:52:06 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: "Sunil Kumar Sinha -X \(sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco\)" In-Reply-To: (sunsinha@cisco.com) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 13 Jun 2016 13:52:05 -0400 Message-ID: <87a8ipx9h6.fsf@hobgoblin.ariadne.com> Archived-At: Cc: dispatch@ietf.org, sramanv@cisco.com Subject: Re: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 17:52:11 -0000 "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" writes: > The purpose of the draft is to register a new optional tag called > "incr" as an extension for the SIP Message indicating that only those > header(s) will be present in the subsequent request or response whose > attribute is changed. This is necessary to increase the processing > speed of any proxy server and also prevents fragmentation of messages > over UDP and provides congestion It's not clear to me how valuable this would be. The bandwidth needs of calls are dominated by the media, not the signaling, so compressing the signaling is not particularly useful. If the signaling travels a different path, then there might be some benefit. It's not clear to me how the mechanism would work. An example would be very helpful. In particular, how does it handle the case when a header "Header: value" appears in message 1 and then the "Header" does *not* appear in message 2 -- as described by the draft, there's no way to designate "'Header' is not present" if the previous message contained 'Header'. Or is the mechanism dependent on no header having an empty value? Unless you require all proxies to be dialog-stateful, then you have to make sure that headers that must be inspected by proxies are exempted from incremental processing. The draft doesn't seem to be clear about which headers are exempted. It provides the list To, From, CSeq, Call-ID, Max-Forwards and Via, but among them, only Max-Forwards must be examined by proxies. However, Proxy-Require must be examined by proxies but is not included in the list. What happens when a message from one UA to another is completely lost? If the UAS does not receive request CSeq 2, then it has no way of reversing the incremental encoding of request CSeq 3. How does this mechanism compare in practice to SigComp (RFC 3320 etc.)? A web search suggests that SigComp is used in IMS, so there should be solid information on the use of SigComp in practice. Dale From nobody Mon Jun 13 11:22:27 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0759E12D910 for ; Mon, 13 Jun 2016 11:22:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 3DCCNJZxUuRl for ; Mon, 13 Jun 2016 11:22:02 -0700 (PDT) Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9982412D8F9 for ; Mon, 13 Jun 2016 11:21:45 -0700 (PDT) Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-08v.sys.comcast.net with SMTP id CWOpbTM2AlVqICWUabT7EM; Mon, 13 Jun 2016 18:21:44 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1465842104; bh=AmgQH2MqaOlyh7/MJWGbilzsqivGkE+8+FfuVaUkY+g=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=ddKA1gGtKq6UT0lE2DyDbwfDSxUXY0fwi76rxCTUy5nsaA3wgkzH3XDIPuXl2bWC8 uzk1poyeVBFKSlRfWICGdon6HtVkrWjQRfFCXsgXLRM2vlz7D//EvbbpGqHaEk7MYu ZeDjxsmb3BLf77oQWicftHkVM51mM/U5n/leZSOF/rptFu8nam09H5oVrvhwMT1wCS CP7poek51etsxXhu6RFavUpqV9UN6tYeLH+bhsjUUQfN0hELDiomxhddWEepw+NN7O oxtD2lcrcQbodfU9yOdgPPhVH4xUN+lzQmhTmg9+JSHfaDvpI6BnlispPVETcyCvzv zyARyPWvCBxZQ== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-09v.sys.comcast.net with comcast id 6JMk1t00D3KdFy101JMkfQ; Mon, 13 Jun 2016 18:21:44 +0000 To: dispatch@ietf.org References: From: Paul Kyzivat Message-ID: <76ff146d-1ac1-8396-630f-26a1131931be@alum.mit.edu> Date: Mon, 13 Jun 2016 14:21:42 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [dispatch] Draft new: draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 18:22:12 -0000 As others have already asked, I would like to see some specific examples of how you see this being useful. IIUC, this proposal is intended to apply within a dialog. I think it implies a change in what constitutes dialog state, adding a number of new items to the state - namely the value of all the header fields in every message transmitted within the dialog. That is a very large change, even if it is only required of those supporting the option. Also as has been mentioned, some fields in messages are used by proxies. They don't have a say in the option negotiation, but they will be impacted if it is negotiated. To avoid this you would need to Proxy-Require the option to verify that all proxies can handle it. And this would severely limit the applicability of the feature. As already noted, sip messages typically make a negligible contribution to the overall bandwidth used by a session, so I don't consider than a useful justification. And reducing message size to avoid fragmentation is only helpful if it is always used. When this is an optional feature you still have to design your application to work when it isn't used. And many other factors continue to increase the likely size of sip messages so that solutions that work with large messages are needed. Trying to keep messages within a PDU is probably futile. Is there some reason other than message size to motivate this? Thanks, Paul On 6/13/16 1:02 PM, Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco) wrote: > Hi, > > > > We’ve submitted a new draft, draft-sunil-sankar-dispatch-sip-incr-00.txt. > > > > The purpose of the draft is to register a new optional tag called "incr" > as an extension for the SIP Message indicating that only those header(s) > will be present in the subsequent request or response whose attribute is > changed. This is necessary to increase the processing speed of any proxy > server and also prevents fragmentation of messages over UDP and provides > congestion > > > > Regards, > > Sunil Sinha > > > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Mon Jun 13 11:51:39 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF4BE12D934 for ; Mon, 13 Jun 2016 11:51:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 TGjlsqwawDlf for ; Mon, 13 Jun 2016 11:51:36 -0700 (PDT) Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4681412D11B for ; Mon, 13 Jun 2016 11:51:36 -0700 (PDT) Received: by mail-qg0-x22c.google.com with SMTP id v76so41032974qgv.3 for ; Mon, 13 Jun 2016 11:51:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:mime-version:thread-index:date:message-id:subject:to; bh=Cs1Iwv9Bh9SGS6kOZBn9Q+1IWebIBi5HwO9GwJMGi9I=; b=Pf0E4zC/Ae+KPz/YEeNQDVcVG9oSvh7lpjyJ62kc3qQ2kPQz1lh9KHFgIl3mPCaCJO WIKG4HLuIj8HPu+zLP4DCkxq+pH/WXQtONKivL91y1gYyWsiUqF7IXxzr4W6WBBR/2vk DuTeFmEDYJ9h8ylmMtqG83hCrZSelpi5Zyr5ztozkaRAneE4IxiFOtQwLrC6Kdx9cTf0 r0WLGfX0BokpDxRyuo3aDYmGY8nWLU+KlF27mkVWVGyBR2uWQFgzDwbGG5G4oILPgK4U B63LTCuhKNQz6bzfk2noqlU35nkk4L++QXnYRfQc3rxht0oDEeN7Y0IIa7cLhb/CXTV0 2tCw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:mime-version:thread-index:date:message-id :subject:to; bh=Cs1Iwv9Bh9SGS6kOZBn9Q+1IWebIBi5HwO9GwJMGi9I=; b=FDHzxgPvXQfGzKIaCCDmSUMtihmnWNBFBi6g19QuDxJ8Oqd/25a9ap+8h98yRFfGRo jnG+MaNqLg/2lKSWT3282HR/FbnpG2Tafq0D0khrAsDujvI65TaaikGGRBjNTkqmhquQ /aWGNpCFFWWtXEepxgvxeO2GPPHmFcXj5HiW3sczq00ruqv372FJl9OWwjZqFLs7qS0p 8E8PR16AdFlfqBhuvCAeixkJt1QxV1AU0YBhCQ1N3wMcSLfQxPsLKSAO4s0LPrZHcHm4 I5OlAPrtczanGUq6s07oD3xIAbIJU9DczeB/VxXC8UacoRltd0CV5Dn5juXbjnR0phEc 1HDA== X-Gm-Message-State: ALyK8tKRwGiZYv21c4l4Krfnl5Y/X/nVT56BXhatav2mVhwT04FydhopHGOYGP0SOZfiTPfZTs0wBpXqSHAissMd X-Received: by 10.140.160.135 with SMTP id g129mr15826653qhg.47.1465843895340; Mon, 13 Jun 2016 11:51:35 -0700 (PDT) From: Brett Tate MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdHFpIp+JGIflJvcSz+AQCRgZF5YkA== Date: Mon, 13 Jun 2016 14:51:34 -0400 Message-ID: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" , dispatch@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 18:51:38 -0000 Hi, The following are a few comments concerning draft-sunil-sankar-dispatch-sip-incr-00. Thanks, Brett ------ 1) The draft should clarify the relation to SHOULD and MUST within other RFCs concerning header inclusion. Section 6.1 appears to indicate that you can ignore MUST statements within other RFCs concerning the need to include a specific a header. However, I'm currently unsure if section 4 next-to-last sentence supports or conflicts with that mandate. 2) You might want to reword section 4 to use normative language. 3) How would this draft interact with RFC 4028 from refresh -versus- deactivation perspective? 4) How would this draft interact with draft-ietf-insipid-session-id since the presence of the Session-ID is to help debug the call flow? 5) You should clarify that transaction specific headers such as Supported, Require, Proxy-Require, and Content-Length need to be included again. From nobody Mon Jun 13 13:32:55 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 065CF12D83B for ; Mon, 13 Jun 2016 13:32:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=sonusnetworks.onmicrosoft.com 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 AIjMVsMjX6cD for ; Mon, 13 Jun 2016 13:32:51 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0086.outbound.protection.outlook.com [65.55.169.86]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC62012D9DB for ; Mon, 13 Jun 2016 13:32:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-sonusnet-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RaeUmSx1nkkuVBwn0L6PApYEMPwckpCf610RLORjS1Y=; b=fK2k3oA+Xs7ak5+2vSvGCCiOVbeGTRLg86kKRHe9tLx7h952V7drcPnwd856ruGD9vZTykjCtbAoKexzz7mQVOUeUEt22H+U8EyXOd0Nv+P6AO8V+nEC1KERbbXVPyfglSFg9jjSLvZRUt4h8+RZfUMpwq8hvQwAL2izs53s8Ng= Received: from CY1PR03MB2156.namprd03.prod.outlook.com (10.166.206.141) by CY1PR03MB2155.namprd03.prod.outlook.com (10.166.206.140) with Microsoft SMTP Server (TLS) id 15.1.501.7; Mon, 13 Jun 2016 20:32:46 +0000 Received: from CY1PR03MB2156.namprd03.prod.outlook.com ([10.166.206.141]) by CY1PR03MB2156.namprd03.prod.outlook.com ([10.166.206.141]) with mapi id 15.01.0506.017; Mon, 13 Jun 2016 20:32:46 +0000 From: "Neelakantan, Neel" To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" , "dispatch@ietf.org" Thread-Topic: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question Thread-Index: AdHFpIp+JGIflJvcSz+AQCRgZF5YkAADJf0w Date: Mon, 13 Jun 2016 20:32:46 +0000 Message-ID: References: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> In-Reply-To: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=nneelakantan@sonusnet.com; x-originating-ip: [12.171.83.97] x-ms-office365-filtering-correlation-id: 1f64ec16-292e-4311-799a-08d393c9e153 x-microsoft-exchange-diagnostics: 1; CY1PR03MB2155; 5:uUqpYsz51y6W06bJGDpJygItznqXjuCEj+bSW4vQ3Uf1UxAoZIuzYDYlm3Wj8tjm2Q4iYdfMPo8lRNoIbizt4+ilnWwgL9e2/zY0HGFySJNjADEMF2T2Mfnx6yf1/z+JYzgtx+coiRMOxwT4ReJ/ow==; 24:WB0FoI1/reSXc4APRtV7B9AxFCcxbw20M5qV/LScZuttfhgKOPleGfADHX5fxr0Hqs31gPlb/w1bJEaxPtFAfuE8fAzkHrWEECL3tt8LkPs=; 7:L/BoEZ9c4N1oA9012ak6uhS4epD2i7Bvygmkru5LZ9Zi479t7hPt2VNuw/MCfzYcenfVfU6Pb8K2V8yZLF+nzboddCJS+Vc8lgLc7FC4bTVCjcfmB19IM4kB1Ual/DHFVPHBns0kwItnlVQKZ30TPJMybvOE4sI/gZuNnArbGP7+3p32GsPdLk6pL3LxYm6PiiumPAQTvIQ9ixmvlBCWPLXlIEFIv/H3OvZOQpN9Y4Q= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR03MB2155; x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(35073007944872)(95692535739014); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:CY1PR03MB2155; BCL:0; PCL:0; RULEID:; SRVR:CY1PR03MB2155; x-forefront-prvs: 0972DEC1D9 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(7916002)(199003)(377454003)(13464003)(189002)(19580395003)(68736007)(11100500001)(9686002)(19580405001)(2501003)(5008740100001)(81166006)(106116001)(10400500002)(76576001)(2950100001)(101416001)(5004730100002)(77096005)(15975445007)(92566002)(122556002)(6116002)(3280700002)(66066001)(586003)(54356999)(50986999)(2906002)(230783001)(2900100001)(76176999)(99286002)(97736004)(3660700001)(87936001)(189998001)(86362001)(561944003)(5003600100002)(5002640100001)(5001770100001)(551934003)(102836003)(74316001)(3846002)(33656002)(107886002)(8936002)(81156014)(106356001)(105586002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY1PR03MB2155; H:CY1PR03MB2156.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: sonusnet.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sonusnet.com X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jun 2016 20:32:46.4612 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR03MB2155 Archived-At: Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 20:32:54 -0000 Hi, There are number of issues with this draft. =20 1) The CSeq should be contiguous, but 3261 allow the UAS to accept non-cont= iguous CSeq if higher than the previous ones. 2) As others have pointed out, there are number of use cases, that rely on = adding or removing a header in subsequent examples (Session Exipres, Route/= Record-Route, Authentication headers, etc). 3) If UDP fragmentation is an issue, then TCP shall be used. 4) When new headers are introduced in a newer RFC, it provides a way to dea= l with headers that are absent. This proposal may have to deal with such f= uture extensions. Thanks, Neel. > -----Original Message----- > From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Brett Tate > Sent: Monday, June 13, 2016 1:52 PM > To: Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE > LIMITED at Cisco) ; dispatch@ietf.org > Subject: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and > question >=20 > Hi, >=20 > The following are a few comments concerning draft-sunil-sankar-dispatch- > sip-incr-00. >=20 > Thanks, > Brett >=20 > ------ >=20 > 1) The draft should clarify the relation to SHOULD and MUST within other > RFCs concerning header inclusion. Section 6.1 appears to indicate that y= ou > can ignore MUST statements within other RFCs concerning the need to > include a specific a header. However, I'm currently unsure if section 4 = next- > to-last sentence supports or conflicts with that mandate. >=20 > 2) You might want to reword section 4 to use normative language. >=20 > 3) How would this draft interact with RFC 4028 from refresh -versus- > deactivation perspective? >=20 > 4) How would this draft interact with draft-ietf-insipid-session-id since= the > presence of the Session-ID is to help debug the call flow? >=20 > 5) You should clarify that transaction specific headers such as Supported= , > Require, Proxy-Require, and Content-Length need to be included again. >=20 > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch From nobody Mon Jun 13 14:30:15 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A96712DA55 for ; Mon, 13 Jun 2016 14:30:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 5j4YJgeYMZVt for ; Mon, 13 Jun 2016 14:30:12 -0700 (PDT) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF43212DA4B for ; Mon, 13 Jun 2016 14:30:11 -0700 (PDT) Received: by mail-wm0-x236.google.com with SMTP id n184so95822342wmn.1 for ; Mon, 13 Jun 2016 14:30:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8bLbkx6v3+dPB98QTCwHCfQ27kbF3w2XR2XZyUWWYmU=; b=rHzTJ3DLPEQr3cEhbdWsC2wUIPupJ1xxiiy442yDDEhiEZxy/bNj51D05rAiSADxWP yeZox3PxvHA5l+FsMHLuRO1ulSKlH7sE83GK1Q2CkviZrdpeksAP0QZ8pygL8lpwwucW LTcqnP8Zy26OTLZORDLhfbwKQX+X7FSMMaVFjYoIJZiYCxzHg1lJguuE3U3Bu1cPatSq 0dSXMPdCJcyHPSJBx3jaOt5/HQKUxqpKbhcHfm4+4nqzRNQQdkX3WJw+Kg3DG8WiWBGX KuC48z+M8SrhbFWD4sHKmq5ThYUqQKnZdukNCTAmW5bc1aJJW/VxvHLYuE3ercxvwQlw LihQ== 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:from:date :message-id:subject:to:cc; bh=8bLbkx6v3+dPB98QTCwHCfQ27kbF3w2XR2XZyUWWYmU=; b=Ob5oH3xcpHaTCYw2+9xAIK04VCWAojRWek483GhFacdBgq66K2qVOtbDeEz8Cd+pzG ZcdtuL+xKRehLDeZQK8LlQ1xz6NRm2v6Mpi06xy2WllEHPm2EIbSFkwOBQ+36O6iOiBJ jTVlwd5GXElOTS+9Y3PVcj1bOEv4yjHfGj15g4ZepVcom6FNntw5SieeHGLXvmmT1ln2 rixkzy9XjnkxBI6RYnD7hvn31/NLTwYZ7fk31AJJiXKEmNOAnygUyULleMLeDqzC0xXs O5gcSLhpNswVmlaWm4wDr2DuPRB2qRIV95sXalKIo67uuwoqb2Aj+aCdA3lFyjy6tjVI z/eg== X-Gm-Message-State: ALyK8tLlpfAb9MmcOP7Yyxv30ALSCEKzn1BPGmbkMgwR3EPGDhXbU6tNViEUs507+TCbrhym4FfAtDwxOB/sVQ== X-Received: by 10.28.150.138 with SMTP id y132mr2951563wmd.103.1465853410527; Mon, 13 Jun 2016 14:30:10 -0700 (PDT) MIME-Version: 1.0 Received: by 10.194.80.100 with HTTP; Mon, 13 Jun 2016 14:30:09 -0700 (PDT) In-Reply-To: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> References: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> From: Ranjit Avasarala Date: Mon, 13 Jun 2016 16:30:09 -0500 Message-ID: To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" Content-Type: multipart/alternative; boundary=001a114b3b0cd3cf5505352f975e Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jun 2016 21:30:14 -0000 --001a114b3b0cd3cf5505352f975e Content-Type: text/plain; charset=UTF-8 Hi Sunil my initial comments on this draft Section 1 1. the intial SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers and not 6. E.g To, From, Call-ID, CSeq, Contact, Max-Forwards and Via. In addition there could be more headers like Content-Type, Content-Length, etc 2. Instead of jointly - which actually is used for 2 headers and not for many. so you should use the word - together or all of them . 3. Also I don't think the main motivation of providing more headers in a SIP message is to actually find a facility though the actual intent is to better describe the session or indicate support for a certain capability or service and mandate some feature (long list...) 4. Also I do not think we can conclude whether the headers are needed or not before and after session is established. every header that is part of the SIP message has certain significance and it is put if there is a need. so we can not generalize saying that prior to session establishment more headers are needed and after session less. 5. if you think it is burden on the bandwidth, the messages can be compressed. More comments as I review Thanks Ranjit On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate wrote: > Hi, > > The following are a few comments concerning > draft-sunil-sankar-dispatch-sip-incr-00. > > Thanks, > Brett > > ------ > > 1) The draft should clarify the relation to SHOULD and MUST within other > RFCs concerning header inclusion. Section 6.1 appears to indicate that > you can ignore MUST statements within other RFCs concerning the need to > include a specific a header. However, I'm currently unsure if section 4 > next-to-last sentence supports or conflicts with that mandate. > > 2) You might want to reword section 4 to use normative language. > > 3) How would this draft interact with RFC 4028 from refresh -versus- > deactivation perspective? > > 4) How would this draft interact with draft-ietf-insipid-session-id since > the presence of the Session-ID is to help debug the call flow? > > 5) You should clarify that transaction specific headers such as Supported, > Require, Proxy-Require, and Content-Length need to be included again. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a114b3b0cd3cf5505352f975e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Sunil

my initial comments on this dr= aft

Section 1

1. the inti= al SIP message e.g REGISTER or INVITE contains atleast 7 mandatory headers = and not 6.=C2=A0 E.g =C2=A0To, From, Call-ID, CSeq, Contact,=C2=A0
=C2=A0 =C2=A0 Max-Forwards and Via.=C2=A0 In addition there could be more= headers like Content-Type, Content-Length, etc=C2=A0
2. Instead = of jointly - which actually is used for 2 headers and not for many. =C2=A0s= o you should use the word - together or all of them .
3. Also I d= on't think the main motivation of providing more headers in a SIP messa= ge is to actually find a facility though the actual intent is to better=C2= =A0
=C2=A0 =C2=A0 describe the session or indicate support for a = certain capability or service and mandate some feature (long list...)=C2=A0=
4. Also I do not think we can conclude whether the headers are n= eeded or not before and after session is established. =C2=A0every header th= at is part of the
=C2=A0 =C2=A0 SIP message has certain significa= nce and it is put if there is a need. so we can not generalize saying that = prior to session establishment more headers
=C2=A0 =C2=A0 are nee= ded and after session less.
5. if you think it is burden on the b= andwidth, the messages can be compressed.

More com= ments as I review

Thanks
Ranjit








On Mon, Jun 13, 2016 at 1:51 PM, Brett Tate <brett@broa= dsoft.com> wrote:
Hi,

The following are a few comments concerning
draft-sunil-sankar-dispatch-sip-incr-00.

Thanks,
Brett

------

1) The draft should clarify the relation to SHOULD and MUST within other RFCs concerning header inclusion.=C2=A0 Section 6.1 appears to indicate tha= t
you can ignore MUST statements within other RFCs concerning the need to
include a specific a header.=C2=A0 However, I'm currently unsure if sec= tion 4
next-to-last sentence supports or conflicts with that mandate.

2) You might want to reword section 4 to use normative language.

3) How would this draft interact with RFC 4028 from refresh -versus-
deactivation perspective?

4) How would this draft interact with draft-ietf-insipid-session-id since the presence of the Session-ID is to help debug the call flow?

5) You should clarify that transaction specific headers such as Supported,<= br> Require, Proxy-Require, and Content-Length need to be included again.

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

--001a114b3b0cd3cf5505352f975e-- From nobody Tue Jun 14 04:22:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CBA1200A0 for ; Tue, 14 Jun 2016 04:22:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.22 X-Spam-Level: X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.onmicrosoft.com 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 G6OQzyYZ8qHO for ; Tue, 14 Jun 2016 04:22:34 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 12FA712D1B1 for ; Tue, 14 Jun 2016 04:22:33 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-68-575fe8f7a868 Received: from ESESSHC007.ericsson.se (Unknown_Domain [153.88.183.39]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 8E.AC.18043.7F8EF575; Tue, 14 Jun 2016 13:22:31 +0200 (CEST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.39) with Microsoft SMTP Server (TLS) id 14.3.294.0; Tue, 14 Jun 2016 13:22:31 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.onmicrosoft.com; s=selector1-ericsson-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=HsmrTSuRghcvbDHH0k33wgxEMdxNxlvhigEgom7VCYk=; b=jhsrcy4J7ggqlYIaMUdnZy7+7KPLIzt1VAgl/njPpVOpgYzhRwQFMGIHNMqKkS42v1DU02/SDtmgDBM3f7b0cLl2k52MIVGEOmUaVgJY0NtOh9ByaBwzhMUIS6G28BnJZco+/1jI13SJCpKl+epfcb7BImsdUMMbrhKuL+v8Bt4= Received: from AM3PR07MB305.eurprd07.prod.outlook.com (2a01:111:e400:881b::13) by AM3PR07MB308.eurprd07.prod.outlook.com (2a01:111:e400:881b::19) with Microsoft SMTP Server (TLS) id 15.1.506.9; Tue, 14 Jun 2016 11:22:30 +0000 Received: from AM3PR07MB305.eurprd07.prod.outlook.com ([fe80::506c:c80b:1f20:ef6a]) by AM3PR07MB305.eurprd07.prod.outlook.com ([fe80::506c:c80b:1f20:ef6a%18]) with mapi id 15.01.0506.017; Tue, 14 Jun 2016 11:22:30 +0000 From: =?iso-8859-1?Q?J=F6rgen_Axell?= To: Christer Holmberg , "dispatch@ietf.org" Thread-Topic: [dispatch] Draft new version: draft-holmberg-dispatch-mcptt-rp-namespace-01 Thread-Index: AdHCb25gtydQswivSm2+Gs9THNdHjQDv0L2g Date: Tue, 14 Jun 2016 11:22:30 +0000 Message-ID: References: <7594FB04B1934943A5C02806D1A2204B38045FEA@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B38045FEA@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=jorgen.axell@ericsson.com; x-originating-ip: [192.176.1.90] x-ms-office365-filtering-correlation-id: 454fecb3-7756-4c44-7c32-08d394462c76 x-microsoft-exchange-diagnostics: 1; AM3PR07MB308; 5:yTfjDIdBS+cMa5eZFQYV3drf2CWCdC0lyKU9EsEGJeTn1Pu1pv3ccAJxUSVCCf0AL4+agynaaLEHU6OQgzal6zNzgAm5iLZDAPYtZ5tETGQDnA9du+aXPwXmY0y6qPOUXBHzSFgcz4RdiwWcrBB3mg==; 24:DUJdHubJGJ5EEAbYKmwbF2xJv/GOzY/pSbxMrJGsE43bQdkDTw4ly1gexJ94Lhnt5gPYlfhlowNE30DumkA01/5oJj4d2yVWdY/8EBkPnEQ=; 7:0V60LXY4BLy1CYXL83WqYscNTZtI7JpYlB7WZxVkIQ4qMA2dsOVGlPzo+uLJLGfAGMxr0MsaHLZsV2/tft8Tyhl1Gbek4iX9Pf/5ei+y/x++YaKGvSc3v4LqN/8oB5dZbY+/YlTy8ykA3ucPIqLvU4fC4l0Yfm36KbEvtFol+zbgieB0zk2sI59wW9X3JnXz/yP0jI31lkwpQPzSeD64Ev738fkp4tzi4WyZGPXEhLA= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:AM3PR07MB308; x-ld-processed: 92e84ceb-fbfd-47ab-be52-080c6b87953f,ExtAddr x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(166708455590820)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046); SRVR:AM3PR07MB308; BCL:0; PCL:0; RULEID:; SRVR:AM3PR07MB308; x-forefront-prvs: 09730BD177 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(7916002)(199003)(189002)(19617315012)(5250100002)(86362001)(4326007)(66066001)(8666004)(230783001)(2906002)(106356001)(105586002)(586003)(19300405004)(3846002)(11100500001)(102836003)(6116002)(790700001)(7906002)(2501003)(8936002)(9686002)(16236675004)(19580405001)(5004730100002)(19625215002)(5002640100001)(19580395003)(76176999)(54356999)(74316001)(2950100001)(189998001)(2900100001)(87936001)(76576001)(15975445007)(33656002)(3280700002)(101416001)(5008740100001)(92566002)(81166006)(81156014)(50986999)(97736004)(3660700001)(5003600100002)(68736007)(5001770100001)(7059030); DIR:OUT; SFP:1101; SCL:1; SRVR:AM3PR07MB308; H:AM3PR07MB305.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_AM3PR07MB3050A169FE5E0B4A8467D09E0540AM3PR07MB305eurprd_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Jun 2016 11:22:30.2549 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM3PR07MB308 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA02SbUhTURjHObt3d1dpcVu+PJkfaqCJppb1YWRJItXITPukqKgjL7p0TnZN VIISMdjM1EzSlWg1rZbrRcxaqOlQ0pkvvb9oZrjKpRmkYemQdncM/PZ7/s//POf/HA5NSJ4J fWhlTh6ryVFkSyl3si7h4bbgxenU+B1jreGyth8VAlmDdlAkezB9m5Q1XWgUyorrI2T2/vz9 lLz6yW9CbtZ/FMkNhr8CeWXVH1KuN9tI+cLLeSqOSnTfm85mK/NZTWhEmnvm0mMzmdsdWuB4 FXAGnQvUIZoGZjf0mgt1yM2JXjA6cZfSIXdawvQieHujGOGiH4HVXknyBcmUEzBt7Vm1fUEw /qJGhIvPCN41vRXwwygmEl6vOEQ8ezAKGL5202UimGoBfDV2EnxjI5MIi/N3SGxKgoWWLpIP 5cGEwcA9JS+TjB986R9HPIudduPcFQFvkTAx8Kban5fdmKNgbC5zXYWcOyxaW1wRCMYbPtga BHg3BgwdIwRmT7BPrQixPxn6hp5T+Cm2QPnLRGyJgeHG767EwBhJaO+YWZ1zAErNDoR5L9SW XSLwWSXYzGosR4NdWyHEZ00ISu+OULjhC/rLk6tDl4VQOV8qqERB+jVZMauhvXqc1LtW3gAD dTYS6yHwruYihTkImq/OEJiDoXbFQq7VG5HIiDw5luNUGWFhIaxGeZzj1DkhOWxeK3L+sZ62 5T2PUM+3SAtiaCRdJ57cnhovESryuUKVBQFNSD3Ehq9OSZyuKCxiNepUzclslrOgzTQp9RbH 2rfGS5gMRR6bxbK5rOZ/V0C7+ZxBplqvoevB3jUJye17lg+ff4M+DZye+BVQYrPcmhhWxaYM Nd8Zf976an1f1IJl8P2hpx2+JSpa+p5Kis7yi3o9pQ4wHZPoUowFuXP1Jq3fqON+jX+IUlKV tk/T1XnWMKmTqLp39Z2sUhyxjp2YDz+YdWri51hUUWqcdml20CdodpOU5DIVOwMJDaf4B/iB bDxfAwAA Archived-At: Cc: "dispatch-chairs@tools.ietf.org" , Ben Campbell , Ted Hardie , "Baruh.Hason@motorolasolutions.com" Subject: Re: [dispatch] Draft new version: draft-holmberg-dispatch-mcptt-rp-namespace-01 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2016 11:22:36 -0000 --_000_AM3PR07MB3050A169FE5E0B4A8467D09E0540AM3PR07MB305eurprd_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Bullet 2) was requested by Baruh Hason in 3GPP. I seem to have forgot to me= ntion that the names was also changed from mcptt1 and mcptt2 to mcpttp and = mcpttq as suggested by Dale Worley. Regards, J=F6rgen From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Hol= mberg Sent: 09 June 2016 18:57 To: dispatch@ietf.org Cc: dispatch-chairs@tools.ietf.org; Ben Campbell; Ted Hardie Subject: [dispatch] Draft new version: draft-holmberg-dispatch-mcptt-rp-nam= espace-01 Hi, Based on the feedback given in BA, we have submitted a new version (-01) dr= aft-holmberg-dispatch-mcptt-rp-namespace. The changes are: 1) Applicability statement added, scoping the solution to 3GPP (reques= ted by Ted Hardie) 2) Priority levels starting from 0 value For the GitHub lovers: https://github.com/cdh4u/draft-mcptt-namespace (Personal repo) Regards, Christer --_000_AM3PR07MB3050A169FE5E0B4A8467D09E0540AM3PR07MB305eurprd_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Bullet 2) was requeste= d by Baruh Hason in 3GPP. I seem to have forgot to mention that the names w= as also changed from mcptt1 and mcptt2 to mcpttp and mcpttq as suggested by= Dale Worley.

 

Regards,

J=F6rgen

 

From:= dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Christer Holmberg Sent: 09 June 2016 18:57
To: dispatch@ietf.org
Cc: dispatch-chairs@tools.ietf.org; Ben Campbell; Ted Hardie
Subject: [dispatch] Draft new version: draft-holmberg-dispatch-mcptt= -rp-namespace-01

 

Hi,

 

Based on the feedback given in BA, we have submitted= a new version (-01) draft-holmberg-dispatch-mcptt-rp-namespace.=

 

The changes are:

 

1)      Applicability statement added, scoping the solution to 3GPP (request= ed by Ted Hardie)

2)      Priority levels starting from 0 value

 

For the GitHub lovers:

 

https://github.com/cdh4u/draft-mcptt-namespace   =      (Personal repo)

 

Regards,

 

Christer

--_000_AM3PR07MB3050A169FE5E0B4A8467D09E0540AM3PR07MB305eurprd_-- From nobody Thu Jun 16 15:50:17 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 285D012DC06 for ; Thu, 16 Jun 2016 15:50:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 fKZJDQ9lDK5r for ; Thu, 16 Jun 2016 15:50:15 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DBC512D79F for ; Thu, 16 Jun 2016 15:50:15 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5GMo5bR060642 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 16 Jun 2016 17:50:05 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Gonzalo Camarillo" , "Jon Peterson" , "Alan Johnston" , DISPATCH Date: Thu, 16 Jun 2016 17:50:14 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Subject: [dispatch] Updates to the SIPBRANDY charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jun 2016 22:50:16 -0000 Hi, I made a minor change to the SIPBRANDY charter due to IESG review. Specifically, I changed "requirements" to "gaps" in the part about sending any protocol work to other wgs. This was due to some concerns that we avoid anything that could be interpreted as chartering "requirements" documents to be published as RFCs. I also added milestones for the non-optional bits. We can worry about milestones for optional work later. The dates at best educated guesses. If anyone has some more scientific guesses, please let me know. The IESG approved the charter for external review pending these changes. Unless I hear otherwise from one of you really soon now, I plan to release this version to external review sometime tomorrow. There will still be a chance for feedback during the review period. Thanks! Ben. From nobody Fri Jun 24 03:03:48 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3DA12D131 for ; Fri, 24 Jun 2016 03:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.221 X-Spam-Level: X-Spam-Status: No, score=-104.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=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 tNEH-bwryZyE for ; Fri, 24 Jun 2016 03:03:44 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F4C112D0DF for ; Fri, 24 Jun 2016 03:03:43 -0700 (PDT) X-AuditID: c1b4fb3a-f79386d00000467b-b4-576d057db85b Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.183.30]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 62.19.18043.D750D675; Fri, 24 Jun 2016 12:03:42 +0200 (CEST) Received: from [148.135.149.68] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.32) with Microsoft SMTP Server id 14.3.294.0; Fri, 24 Jun 2016 12:03:41 +0200 To: Ben Campbell , Jon Peterson , Alan Johnston , DISPATCH References: From: Gonzalo Camarillo Message-ID: Date: Fri, 24 Jun 2016 13:03:41 +0300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM2K7nG4da264wYMeNouZra0sFvM7T7Nb LJ20gNXiTIOlA4vHzll32T2WLPnJ5LGj4Tmzx6ydT1gCWKK4bFJSczLLUov07RK4MubNXchS 8J+94s/5S0wNjCvYuhg5OSQETCTezHvPDmGLSVy4tx4ozsUhJHCEUWLTyktQzhpGiXdHzoJ1 CAvoSnQcescOkhARmMYo0dAymbGLkQOoyk5i3ZZwkBo2AQuJLbfus4DYvAL2EueuXWYFsVkE VCVmX7sNFhcViJFovH2YHaJGUOLkzCdgcU6g+s8fV4LFmQUMJI4smsMKYctLbH87hxnEFhLQ llj+rIVlAqPALCTts5C0zELSsoCReRWjaHFqcXFuupGRXmpRZnJxcX6eXl5qySZGYPge3PLb agfjweeOhxgFOBiVeHgXKOeEC7EmlhVX5h5ilOBgVhLhfc+cGy7Em5JYWZValB9fVJqTWnyI UZqDRUmc1/+lYriQQHpiSWp2ampBahFMlomDU6qBsZ9t9YHdvdHST+btdp38+MLCD9M9mCau 6yt0un0qLb951n69gsPhKhqePFoi4iUvw/v3PNKxsLr65tYaphK/0pgpOzNEvwg+tuxZGZL9 alFa8//TFo9v8tvahkgeaN0/93/3zkmVWfcLJsleqZ8fq90gXt8YaFBzYrZQT3eYV9CjLQcD TnluUmIpzkg01GIuKk4EAGdOAdRbAgAA Archived-At: Subject: Re: [dispatch] Updates to the SIPBRANDY charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 10:03:46 -0000 Thanks, Ben. The IESG is going to discuss the final charter on June 30th, right? Cheers, Gonzalo On 17/06/2016 1:50 AM, Ben Campbell wrote: > Hi, > > I made a minor change to the SIPBRANDY charter due to IESG review. > Specifically, I changed "requirements" to "gaps" in the part about > sending any protocol work to other wgs. This was due to some concerns > that we avoid anything that could be interpreted as chartering > "requirements" documents to be published as RFCs. > > I also added milestones for the non-optional bits. We can worry about > milestones for optional work later. The dates at best educated guesses. > If anyone has some more scientific guesses, please let me know. > > The IESG approved the charter for external review pending these changes. > Unless I hear otherwise from one of you really soon now, I plan to > release this version to external review sometime tomorrow. There will > still be a chance for feedback during the review period. > > Thanks! > > Ben. From nobody Fri Jun 24 09:05:02 2016 Return-Path: X-Original-To: dispatch@ietf.org Delivered-To: dispatch@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E128C12DCC1; Fri, 24 Jun 2016 09:00:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , X-Test-IDTracker: no X-IETF-IDTracker: 6.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160624160050.10933.83786.idtracker@ietfa.amsl.com> Date: Fri, 24 Jun 2016 09:00:50 -0700 Archived-At: Cc: ben@nostrum.com, dispatch@ietf.org Subject: [dispatch] dispatch - Requested session has been scheduled for IETF 96 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 16:00:51 -0000 Dear Murray Kucherawy, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. dispatch Session 1 (2:30:00) Monday, Morning Session I 1000-1230 Room Name: Potsdam II size: 175 --------------------------------------------- Special Note: Combined with ARTAREA Request Information: --------------------------------------------------------- Working Group Name: Dispatch Area Name: Applications and Real-Time Area Session Requester: Murray Kucherawy Number of Sessions: 1 Length of Session(s): 2.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: appsawg apparea avtcore avtext bfcpbis clue core dbound ecrit insipid mmusic netvc p2psip payload rmcat rtcweb sipcore siprec stir stox straw webpush xrblock Second Priority: tram tsvwg tsvarea opsarea lmap Special Requests: Please schedule in the 1st slot on Monday morning, list the meeting as coupled with ARTAREA, and avoid the same kind of conflicts with other area meetings and any Bofs and potential new ART WGs. --------------------------------------------------------- From nobody Fri Jun 24 13:00:39 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4AE312D608 for ; Fri, 24 Jun 2016 13:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 H-MY04r5x9aW for ; Fri, 24 Jun 2016 13:00:36 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 493D912D589 for ; Fri, 24 Jun 2016 13:00:36 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5OK0JQR036363 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 24 Jun 2016 15:00:29 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Gonzalo Camarillo" Date: Fri, 24 Jun 2016 15:00:30 -0500 Message-ID: In-Reply-To: References: MIME-Version: 1.0 X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Updates to the SIPBRANDY charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jun 2016 20:00:37 -0000 On 24 Jun 2016, at 5:03, Gonzalo Camarillo wrote: > Thanks, Ben. The IESG is going to discuss the final charter on June > 30th, right? That is correct. Thanks! Ben. > > Cheers, > > Gonzalo > > On 17/06/2016 1:50 AM, Ben Campbell wrote: >> Hi, >> >> I made a minor change to the SIPBRANDY charter due to IESG review. >> Specifically, I changed "requirements" to "gaps" in the part about >> sending any protocol work to other wgs. This was due to some concerns >> that we avoid anything that could be interpreted as chartering >> "requirements" documents to be published as RFCs. >> >> I also added milestones for the non-optional bits. We can worry about >> milestones for optional work later. The dates at best educated guesses. >> If anyone has some more scientific guesses, please let me know. >> >> The IESG approved the charter for external review pending these changes. >> Unless I hear otherwise from one of you really soon now, I plan to >> release this version to external review sometime tomorrow. There will >> still be a chance for feedback during the review period. >> >> Thanks! >> >> Ben. From nobody Tue Jun 28 07:03:02 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61FF112B00F for ; Tue, 28 Jun 2016 07:03:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 T4n7ULkFUj1V for ; Tue, 28 Jun 2016 07:02:56 -0700 (PDT) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1ACA12D182 for ; Tue, 28 Jun 2016 07:02:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1894; q=dns/txt; s=iport; t=1467122575; x=1468332175; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=5FlC2xShZWL1Y7hy3qSqyslOzkE7GCK/kUpmsFLznwg=; b=a7VWOtDpeG7FUk0eJN+pWuVNvwLZ65sRnmsZmsKtRbWZfb3OMy8Ir++b HE32CTBRgYrRhAoQJ4r8BVcwJEETUnm1H0nx+4nYT0JLXLnStQ0O2BGQP cEksn5wiYSTx6c+01bdxmnqpFhb8s4kdPlTtwvZZXLjFO6frpXiUbR0qM 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAgB/gnJX/4gNJK1bgz5WfQa6KoF7F?= =?us-ascii?q?wuFLEoCHIETOBQBAQEBAQEBZSeETAEBAQMBAQEBIBE6BAwLAgEIGAICJgICAiU?= =?us-ascii?q?LFRACBAESiCgIDrJLkDIBAQEBAQEBAQEBAQEBAQEBAQEBAQEXBYEBhx4Igk6HQ?= =?us-ascii?q?SuCLwWZAgGOOY8kj34BHjaDcG6IMX8BAQE?= X-IronPort-AV: E=Sophos;i="5.26,541,1459814400"; d="scan'208";a="291062457" Received: from alln-core-3.cisco.com ([173.36.13.136]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 28 Jun 2016 14:02:55 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u5SE2snh014131 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Tue, 28 Jun 2016 14:02:54 GMT Received: from xch-rtp-004.cisco.com (64.101.220.144) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 28 Jun 2016 10:02:53 -0400 Received: from xch-rtp-004.cisco.com ([64.101.220.144]) by XCH-RTP-004.cisco.com ([64.101.220.144]) with mapi id 15.00.1210.000; Tue, 28 Jun 2016 10:02:53 -0400 From: "Cullen Jennings (fluffy)" To: "Sunil Kumar Sinha -X (sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco)" , DISPATCH list Thread-Topic: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question Thread-Index: AQHR0UXDhwB9+JGwHE6hRPheWX7ojg== Date: Tue, 28 Jun 2016 14:02:53 +0000 Message-ID: References: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> In-Reply-To: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.110.222] Content-Type: text/plain; charset="utf-8" Content-ID: <9AB098932A008545B157B4E6BB9E164E@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jun 2016 14:03:01 -0000 DQpEb2VzIENpc2NvIG9yIGFueW9uZSBlbHNlIHBsYW4gdG8gaW1wbGVtZW50IHRoaXMgZHJhZnQg aW4gdGhlaXIgcHJvZHVjdHM/IEnigJltIHNrZXB0aWNhbCB0aGlzIHdvdWxkIGltcHJvdmUgcGVy Zm9ybWFuY2Ugb3ZlciBjYWNoZWQgcGFyc2luZyBhcHByb2FjaGVzLiANCg0KDQoNCj4gT24gSnVu IDEzLCAyMDE2LCBhdCA5OjUxIFBNLCBCcmV0dCBUYXRlIDxicmV0dEBicm9hZHNvZnQuY29tPiB3 cm90ZToNCj4gDQo+IEhpLA0KPiANCj4gVGhlIGZvbGxvd2luZyBhcmUgYSBmZXcgY29tbWVudHMg Y29uY2VybmluZw0KPiBkcmFmdC1zdW5pbC1zYW5rYXItZGlzcGF0Y2gtc2lwLWluY3ItMDAuDQo+ IA0KPiBUaGFua3MsDQo+IEJyZXR0DQo+IA0KPiAtLS0tLS0NCj4gDQo+IDEpIFRoZSBkcmFmdCBz aG91bGQgY2xhcmlmeSB0aGUgcmVsYXRpb24gdG8gU0hPVUxEIGFuZCBNVVNUIHdpdGhpbiBvdGhl cg0KPiBSRkNzIGNvbmNlcm5pbmcgaGVhZGVyIGluY2x1c2lvbi4gIFNlY3Rpb24gNi4xIGFwcGVh cnMgdG8gaW5kaWNhdGUgdGhhdA0KPiB5b3UgY2FuIGlnbm9yZSBNVVNUIHN0YXRlbWVudHMgd2l0 aGluIG90aGVyIFJGQ3MgY29uY2VybmluZyB0aGUgbmVlZCB0bw0KPiBpbmNsdWRlIGEgc3BlY2lm aWMgYSBoZWFkZXIuICBIb3dldmVyLCBJJ20gY3VycmVudGx5IHVuc3VyZSBpZiBzZWN0aW9uIDQN Cj4gbmV4dC10by1sYXN0IHNlbnRlbmNlIHN1cHBvcnRzIG9yIGNvbmZsaWN0cyB3aXRoIHRoYXQg bWFuZGF0ZS4NCj4gDQo+IDIpIFlvdSBtaWdodCB3YW50IHRvIHJld29yZCBzZWN0aW9uIDQgdG8g dXNlIG5vcm1hdGl2ZSBsYW5ndWFnZS4NCj4gDQo+IDMpIEhvdyB3b3VsZCB0aGlzIGRyYWZ0IGlu dGVyYWN0IHdpdGggUkZDIDQwMjggZnJvbSByZWZyZXNoIC12ZXJzdXMtDQo+IGRlYWN0aXZhdGlv biBwZXJzcGVjdGl2ZT8NCj4gDQo+IDQpIEhvdyB3b3VsZCB0aGlzIGRyYWZ0IGludGVyYWN0IHdp dGggZHJhZnQtaWV0Zi1pbnNpcGlkLXNlc3Npb24taWQgc2luY2UNCj4gdGhlIHByZXNlbmNlIG9m IHRoZSBTZXNzaW9uLUlEIGlzIHRvIGhlbHAgZGVidWcgdGhlIGNhbGwgZmxvdz8NCj4gDQo+IDUp IFlvdSBzaG91bGQgY2xhcmlmeSB0aGF0IHRyYW5zYWN0aW9uIHNwZWNpZmljIGhlYWRlcnMgc3Vj aCBhcyBTdXBwb3J0ZWQsDQo+IFJlcXVpcmUsIFByb3h5LVJlcXVpcmUsIGFuZCBDb250ZW50LUxl bmd0aCBuZWVkIHRvIGJlIGluY2x1ZGVkIGFnYWluLg0KPiANCj4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZGlzcGF0Y2ggbWFpbGluZyBsaXN0DQo+ IGRpc3BhdGNoQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vZGlzcGF0Y2gNCg0K From nobody Wed Jun 29 22:40:58 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9471112DA12 for ; Wed, 29 Jun 2016 22:40:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 SZsGB6rkbiGM for ; Wed, 29 Jun 2016 22:40:54 -0700 (PDT) Received: from mail-vk0-x232.google.com (mail-vk0-x232.google.com [IPv6:2607:f8b0:400c:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2064912D9FB for ; Wed, 29 Jun 2016 22:40:54 -0700 (PDT) Received: by mail-vk0-x232.google.com with SMTP id u68so52845720vkf.2 for ; Wed, 29 Jun 2016 22:40:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0EDLVPkv8jqe0/SksHKAapzhIGr9IfYedk8zRnGxFww=; b=Jk/DDIcgUoDZSHVqIraehVXiL3sHxxNgcvwS5sfZOGR3dVlbVsNHRqssoP+CtWz1iZ Zi2/eXnfxBEjwMn9om6TutUwY/he5+lLkRR5XNYhOQFNzEHttbq/+Ygk+R9qiZJxTl57 cUJkiHsf1n1t+D+zFpcG3Wsc9Q5pTN7XBJEF3j1Fs6LyVzewxFvHAJ72XKaqnOX7EDpA M+aIbJgyodw+FQ7h+Hv6+Rtn36USduRbN+E4gDWip/no+zRQS2bjKoBpJqbR1ikYK4Y7 I9cpRIVv4qjKeN4aQQuXlAV77Jqnd4aGSeoMt+bSFceqr6FEi0K5ZUqjj6F8+SkHPafI xrxQ== 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:from:date :message-id:subject:to:cc; bh=0EDLVPkv8jqe0/SksHKAapzhIGr9IfYedk8zRnGxFww=; b=LgxcfUlB5spIPThh36TR2tEQVsi0sTEGMKKofDsCmYbOpVhW6CWW84lXJLYGCq1prC TygAb9/xQzItaVN4X7LeqtU//83AUOtZX22pp3Dzsk795NZsJLYVHiCZtyHGHL9OE9mf 9yHw6BU7Zs8OsnF2D7BpSnMifnaCdc/biYZJusisIOsbVjcfGTylZoFhjsuA2sHwar/b XbghbE2G5dEYvbzjyRG6fqBiji2y4QiKiu7OBbv9THIzWQERlPB2WpIjy5GYJK+MBtS5 YKggemQ38qJFdeWjTkpHcXA89uMJKhldZWq2VklD0igZBZ1SEGT+9pzowoDbyHEJNz79 sWTw== X-Gm-Message-State: ALyK8tIKlflxnziXWwMsjRmTZLLZ69kqMUdtb50YbkHjHe1I9nxCO/8+CdJqpFmEFWSZ+Uj95urs0cwQjVD99g== X-Received: by 10.176.3.114 with SMTP id 105mr5740890uat.122.1467265253198; Wed, 29 Jun 2016 22:40:53 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.73.202 with HTTP; Wed, 29 Jun 2016 22:40:52 -0700 (PDT) In-Reply-To: References: <3dfdc76b723c199cf9ca5ed97cb2f16e@mail.gmail.com> From: sunil sinha Date: Thu, 30 Jun 2016 11:10:52 +0530 Message-ID: To: "Cullen Jennings (fluffy)" Content-Type: multipart/alternative; boundary=001a113d15d835525b0536785098 Archived-At: Cc: DISPATCH list , "Sunil Kumar Sinha -X \(sunsinha - SCARLET WIRELESS INDIA PRIVATE LIMITED at Cisco\)" Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00: comments and question X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 05:40:57 -0000 --001a113d15d835525b0536785098 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I don't think at this point Cisco or anyone else plan to implement this draft in their product. Thanks & Regards sunil On Tue, Jun 28, 2016 at 7:32 PM, Cullen Jennings (fluffy) wrote: > > Does Cisco or anyone else plan to implement this draft in their products? > I=E2=80=99m skeptical this would improve performance over cached parsing = approaches. > > > > > On Jun 13, 2016, at 9:51 PM, Brett Tate wrote: > > > > Hi, > > > > The following are a few comments concerning > > draft-sunil-sankar-dispatch-sip-incr-00. > > > > Thanks, > > Brett > > > > ------ > > > > 1) The draft should clarify the relation to SHOULD and MUST within othe= r > > RFCs concerning header inclusion. Section 6.1 appears to indicate that > > you can ignore MUST statements within other RFCs concerning the need to > > include a specific a header. However, I'm currently unsure if section = 4 > > next-to-last sentence supports or conflicts with that mandate. > > > > 2) You might want to reword section 4 to use normative language. > > > > 3) How would this draft interact with RFC 4028 from refresh -versus- > > deactivation perspective? > > > > 4) How would this draft interact with draft-ietf-insipid-session-id sin= ce > > the presence of the Session-ID is to help debug the call flow? > > > > 5) You should clarify that transaction specific headers such as > Supported, > > Require, Proxy-Require, and Content-Length need to be included again. > > > > _______________________________________________ > > 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 > --001a113d15d835525b0536785098 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
=C2=A0
I don't think at this point C= isco or anyone else plan to implement this draft in their product.

Thanks & Regards
sunil

On Tue, Jun 28, 2016 at= 7:32 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:<= br>

Does Cisco or anyone else plan to implement this draft in their products? I= =E2=80=99m skeptical this would improve performance over cached parsing app= roaches.



> On Jun 13, 2016, at 9:51 PM, Brett Tate <brett@broadsoft.com> wrote:
>
> Hi,
>
> The following are a few comments concerning
> draft-sunil-sankar-dispatch-sip-incr-00.
>
> Thanks,
> Brett
>
> ------
>
> 1) The draft should clarify the relation to SHOULD and MUST within oth= er
> RFCs concerning header inclusion.=C2=A0 Section 6.1 appears to indicat= e that
> you can ignore MUST statements within other RFCs concerning the need t= o
> include a specific a header.=C2=A0 However, I'm currently unsure i= f section 4
> next-to-last sentence supports or conflicts with that mandate.
>
> 2) You might want to reword section 4 to use normative language.
>
> 3) How would this draft interact with RFC 4028 from refresh -versus- > deactivation perspective?
>
> 4) How would this draft interact with draft-ietf-insipid-session-id si= nce
> the presence of the Session-ID is to help debug the call flow?
>
> 5) You should clarify that transaction specific headers such as Suppor= ted,
> Require, Proxy-Require, and Content-Length need to be included again.<= br> >
> _______________________________________________
> 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

--001a113d15d835525b0536785098-- From nobody Thu Jun 30 05:28:46 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC7512D13D for ; Thu, 30 Jun 2016 05:28:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=yandex.ru 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 ckKVM3i9K780 for ; Thu, 30 Jun 2016 05:28:36 -0700 (PDT) Received: from forward12m.cmail.yandex.net (forward12m.cmail.yandex.net [IPv6:2a02:6b8:b030::99]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49E1512D0DB for ; Thu, 30 Jun 2016 05:28:35 -0700 (PDT) Received: from mxback4m.mail.yandex.net (mxback4m.mail.yandex.net [37.140.138.64]) by forward12m.cmail.yandex.net (Yandex) with ESMTP id AD70F212A4; Thu, 30 Jun 2016 15:28:32 +0300 (MSK) Received: from web4m.yandex.ru (web4m.yandex.ru [37.140.138.95]) by mxback4m.mail.yandex.net (nwsmtp/Yandex) with ESMTP id rInB0zEGPb-SWYW0X91; Thu, 30 Jun 2016 15:28:32 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1467289712; bh=9PmOLbeWWww2rpMGpUpOwhnG6vwpLoX1Yb18H+mE95M=; h=From:To:Cc:Subject:MIME-Version:Message-Id:X-Mailer:Date: Content-Transfer-Encoding:Content-Type; b=A5KcZKeXpJE5i0p1Bwl0hg6YP73exeM32SVzM0u5ruobLBsRadqRXNCTbmRJ/lxQK 3bLXw1knPcEpQrIVFb3q2+OR9CeQ/P+SRd10MjoL+XgZtPzH2Cr8QoTxdc72UuUgsk h1D1kBbPrLeNpGS5UVQ3IdD4/xOiG8nU90wntWEc= Authentication-Results: mxback4m.mail.yandex.net; dkim=pass header.i=@yandex.ru Received: by web4m.yandex.ru with HTTP; Thu, 30 Jun 2016 15:28:32 +0300 From: Anton Tveretin To: "sunsinha@cisco.com" , "sramanv@cisco.com" MIME-Version: 1.0 Message-Id: <87681467289712@web4m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 30 Jun 2016 17:28:32 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 12:28:44 -0000 Hi, I really agree that currently SIP is highly redundant and suffers from poor design. There is more than network traffic; larger message takes significantly more CPU cycles and memory for both parsing and producing. Thus, reducing message size would increase throughput. But I don't see how to introduce that into current version without breaking compatibility. I suggest keeping this optimization for a new version (say, 2.5) of SIP. I could write more examples of SIP redundancy and poor design. Regards, Anton From nobody Thu Jun 30 06:48:57 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589B512D095 for ; Thu, 30 Jun 2016 06:48:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.935 X-Spam-Level: X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net 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 C7jx8oKv5EOS for ; Thu, 30 Jun 2016 06:48:54 -0700 (PDT) Received: from resqmta-ch2-03v.sys.comcast.net (resqmta-ch2-03v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:35]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23B4512B068 for ; Thu, 30 Jun 2016 06:48:53 -0700 (PDT) Received: from resomta-ch2-17v.sys.comcast.net ([69.252.207.113]) by resqmta-ch2-03v.sys.comcast.net with SMTP id IcIKbY3X8SVL4IcKqb67TF; Thu, 30 Jun 2016 13:48:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1467294532; bh=50i3LZ/S0Yr3z4LP8zgrkPz+Ftv19BCVrBa3NmYsu1Q=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=t4SwSCHm6J8D4YbaX2u2frbTdHhM/mcoOwgiFeJGv08jI3fU96UUMQ4dldEs4yjnp TwhX1Bk3e2Z+WRlgi0pijzMugbzWNuwL1XnRE6V3E4hE4OIhnXQhNoIEEL50Wu8n4x P2I0RrGaVlmCUjfQ+ZEM7Ca4gnAmhwUEsAjgIXccJHF1O9zM0u8l9PAZaC61HAj5Cc Fody3FNO1zjgoB9dMMfrE34ZTS0wHrpDG1exASlvhNZ6fYLqZhirUsMKAuqbCVM9s/ QGoUb2qaWbqpre+lJUqyjwPyXe1BJLAyWtUz7sZJ1RpNLf4RxpFwC38oMYkWJ6Leyx OIymdvOMav47w== Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-17v.sys.comcast.net with comcast id D1os1t0043KdFy1011osAn; Thu, 30 Jun 2016 13:48:52 +0000 To: dispatch@ietf.org References: <87681467289712@web4m.yandex.ru> From: Paul Kyzivat Message-ID: Date: Thu, 30 Jun 2016 09:48:50 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.1.0 MIME-Version: 1.0 In-Reply-To: <87681467289712@web4m.yandex.ru> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 13:48:55 -0000 On 6/30/16 8:28 AM, Anton Tveretin wrote: > Hi, > I really agree that currently SIP is highly redundant and suffers from poor design. > There is more than network traffic; larger message takes significantly more CPU cycles and memory for both parsing and producing. Thus, reducing message size would increase throughput. > But I don't see how to introduce that into current version without breaking compatibility. I suggest keeping this optimization for a new version (say, 2.5) of SIP. > I could write more examples of SIP redundancy and poor design. I think most people who know sip well have a long list of things they would change if they were starting over. But that isn't a sufficient reason to do a new version. For that, there would need to be a significant community of competent people willing to do the work and a probable business model for introducing the result. I don't see either of those being present any time soon. It seems more likely to me that sip will be superseded by something quite different, like webrtc. Thanks, Paul From nobody Thu Jun 30 07:22:54 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 002D712D095 for ; Thu, 30 Jun 2016 07:22:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=broadsoft-com.20150623.gappssmtp.com 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 Q5vnUK_0knqD for ; Thu, 30 Jun 2016 07:22:50 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9776012D0BD for ; Thu, 30 Jun 2016 07:22:50 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o76so33786617qke.0 for ; Thu, 30 Jun 2016 07:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=broadsoft-com.20150623.gappssmtp.com; s=20150623; h=from:references:in-reply-to:mime-version:thread-index:date :message-id:subject:to; bh=jaroUzzcDvITjOazMogMNk1GX49J/5DWsdgduyh+uWw=; b=kj2GUBUWqy5iLn5000HEqqCVebaPhxSdUB77jCzHI2894cBH0o9DE+0HOZJRrF27eU pw/pJRxSt733xlbI35FYt4WnR7ZtEB0LWpzPBMNz1ZnFqjzsSNscv6GVInMwuxKjaBvp Pvpeg/q2KNE75hCtpyFDf8AfJNbR7H+B0UBlGF26h61iOM5SgyJjCgwaahCzy3xvIo0T /MsbzAgpcnsb/fXO10P+rRBQQo4WOg+ETRl3xmvHCJx49fC5K/g0V8P3sAteYV9MgZ8b QNAA9PaCUaZmioyVC57quJyhiHHVPb3ONtDkVP7XxBNYh5+Q34INyQ+Be6ekPc9vjIrF pdmA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:references:in-reply-to:mime-version :thread-index:date:message-id:subject:to; bh=jaroUzzcDvITjOazMogMNk1GX49J/5DWsdgduyh+uWw=; b=cm98CcEE4H25l/jqBK4nl7+cg3VAPpAUdGHxryDd0tJLcwJPtxZULi+5+bhNTwOdom xeRZW/TocKQETN8sr1lUadTpBevi2YBXg8bF3Oy+CbsxS+zy5D8pkzAJZYBeJHBBI67n LgO+TI8UY8Dylx2cbBdWT17wksP0+KeIBR4QKDK6QYdVxITAp5Eb89w7TpF2YDI1JS7U oEVudy15R5q9xcUAXi2m3uTLgaApEhtzZZ8Ox2bBmINa0QhOAJWPY/SRedoVmuvCiXFR TV7L9eYu59qoGOob6kYlCsP8x5LOBpllJZgjcoZ21Cnzbb9G8GhnommTwCl0rsBmBMNs p+Qg== X-Gm-Message-State: ALyK8tJX13KrgWj2rvjZbn7DxXY1/clzrrvlZgGf9/a/pqbZs+YbmT1D/bpzbjTnmHNVGhm/hy6d9OcbfA/EVIYg X-Received: by 10.55.27.98 with SMTP id b95mr19678053qkb.146.1467296569801; Thu, 30 Jun 2016 07:22:49 -0700 (PDT) From: Brett Tate References: <87681467289712@web4m.yandex.ru> In-Reply-To: <87681467289712@web4m.yandex.ru> MIME-Version: 1.0 X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIt41zmVfRi7f6tNsud9pTlrwSOu59J4d/Q Date: Thu, 30 Jun 2016 10:22:49 -0400 Message-ID: <3f52184774005d8fedbcbcd1c438d8b2@mail.gmail.com> To: Anton Tveretin , DISPATCH list Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: Re: [dispatch] draft-sunil-sankar-dispatch-sip-incr-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 14:22:53 -0000 > larger message takes significantly more CPU cycles and > memory for both parsing and producing. Thus, reducing > message size would increase throughput. > But I don't see how to introduce that into current > version without breaking compatibility. I suggest keeping > this optimization for a new version (say, 2.5) of SIP. Version 2.5? We could skip to SIPv4 as described within my favorite April 1 draft: draft-kaplan-sip-four-oh. :) Draft-kaplan-sip-four-oh section 10.3 even discusses the deprecation of many headers which could help reduce the size of SIP messages. Similarly, the SCU layer discussed within section 16 could reduce the message size by 95.5%. https://tools.ietf.org/id/draft-kaplan-sip-four-oh-00.txt From nobody Thu Jun 30 10:57:22 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D9CE12DB2A; Thu, 30 Jun 2016 10:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -115.947 X-Spam-Level: X-Spam-Status: No, score=-115.947 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com 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 hkqh_iZ6fGfr; Thu, 30 Jun 2016 10:57:17 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71A0712D91E; Thu, 30 Jun 2016 10:57:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3407; q=dns/txt; s=iport; t=1467309437; x=1468519037; h=from:to:cc:subject:date:message-id:mime-version; bh=Rj4bkLpd8LBi377qec5mfGhoYGzg0hVmPYVTp5s1aP4=; b=J1Y7GvoeBlRLrGNxgcvsOTn/KDh9Sq0YEAiTM9RxTz3twe4OKf0U1/Nx xnr5LkLk6ltd8teCQ5GQL5/Jc3A58xMdf9CDTmEpJfSC7abYaXZKXM2n/ 5yqiH413xhPgwpSbq8G+ZJzEi2UQggEFjq1LRP3cQBvmMRfXeSt3bslIZ 8=; X-Files: signature.asc : 833 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOBQAVXXVX/4QNJK1bgz5WgQO5R4F8h?= =?us-ascii?q?heBPjkTAQEBAQEBAWUnhE4EAWsOBQ0BgQAnBAENE4gaCMNmAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBDg6IH4cAg0KCLwWZCwGDLYFsiSeBaogEhTyQBAEfATSDcIkwf?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.26,553,1459814400"; d="asc'?scan'208";a="120830481" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 30 Jun 2016 17:57:16 +0000 Received: from XCH-ALN-014.cisco.com (xch-aln-014.cisco.com [173.36.7.24]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u5UHvGak016186 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 30 Jun 2016 17:57:16 GMT Received: from xch-rcd-013.cisco.com (173.37.102.23) by XCH-ALN-014.cisco.com (173.36.7.24) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 30 Jun 2016 12:57:15 -0500 Received: from xch-rcd-013.cisco.com ([173.37.102.23]) by XCH-RCD-013.cisco.com ([173.37.102.23]) with mapi id 15.00.1210.000; Thu, 30 Jun 2016 12:57:15 -0500 From: "Fred Baker (fred)" To: "draft-pd-dispatch-msrp-websocket.all@ietf.org" , "ops-dir@ietf.org" Thread-Topic: Ops Directorate review of draft-pd-dispatch-msrp-websocket-12 Thread-Index: AQHR0vjWEmY7TvkZWUWZFVDYVLHs4A== Date: Thu, 30 Jun 2016 17:57:15 +0000 Message-ID: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3124) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.19.64.115] Content-Type: multipart/signed; boundary="Apple-Mail=_92F2B441-D702-41F5-B2AB-32E27654C7F3"; protocol="application/pgp-signature"; micalg=pgp-sha1 MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 17:57:19 -0000 --Apple-Mail=_92F2B441-D702-41F5-B2AB-32E27654C7F3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I am reviewing this document as part of the Operational directorate's = ongoing effort to review all IETF documents being processed by the IESG. = These comments were written with the intent of improving the operational = aspects of the IETF drafts. Comments that are not addressed in last call = may be included in AD reviews during the IESG review. Document editors = and WG chairs should treat these comments just like any other last call = comments. I have a few questions regarding the document. My perception, which may = or may not be correct, is that it targets down-rev protocols - http/s = 1.1 and TLS 1.2, the former of which has been obsoleted and replaced and = the latter is (I'm told) about to be. I'm fine with having those as = options, but it seems like publishing this without references to the = current technology means that it will need to be updated or replaced = soon with a document that does. Note that I am not registering these as objections; I think this is a = conversation that needs to be had, but if the consensus of people more = expert than myself in this technology is to stay down-rev, I'm OK with = it. > 1. Introduction >=20 > The WebSocket [RFC6455] protocol enables message exchange between > clients and servers on top of a persistent TCP connection = (optionally > secured with TLS [RFC5246]). The initial protocol handshake makes > use of HTTP [RFC7230] semantics, allowing the WebSocket protocol to > reuse existing HTTP infrastructure. I understand HTTP 1.1 (which is to say "pipelined TCP"), but I was = surprised to not read about RFC 7540 HTTP 2.0 (Secure TCP). Is there a = reason to not allow for the latter, at least as an option? > 3. WebSocket Protocol Overview >=20 > The WebSocket protocol [RFC6455] is a transport layer on top of TCP > (optionally secured with TLS [RFC5246]) in which both client and > server exchange message units in both directions. Is this extensible to TLS 1.3, which I'm told is in the offing? That = would obsolete RFC 5246. --Apple-Mail=_92F2B441-D702-41F5-B2AB-32E27654C7F3 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - http://gpgtools.org iQIVAwUBV3Vde0ayAOS/EQ8MAQKZvRAAk0S2wm+nrcW3iBbFzkncd2yFksrseZlZ MPbckaCLLE2i8oYj5k+tyH8AZ02Ne63fjpagM3VCrijxJO6H1VYbvAL5wHG7QFw8 vY7idaaKw7oldJAE4PeH1ZUgvqnIoCH2Trd6g6pcn92tI1rLrbX2b2WVZotoU4Rf pAZmy7fv6tC7lnFeBAdnqYuSb+zSPXxfzhigp0fLCTq8tnsgWSQGUFJh6x+qwf1y xIwTs4Iz7UPVVfslVH0ANaMjd2URnkOs9gBHWVkLylJ4fi5+qCiVofP1HiDorQQ4 LYdmE7BX7DwU+mAnXutRnCmhc+J0Z0RCNW+L+uwuKSfxh4x8Xgy9kpFtr0B8PUIE AAMU5LhXlwS4YWB/LlEOJe2xYemDpbH0DDWJCWxdu9MWTzwk4RUWBWnfTUJ8h2Jp B4I/PDnvp5h6K/GQiPC15PmVWkh4AnpeX/U9EiQVKZxBpN4QaYPAvcTzcTy1I9zM 59E2YbE0gtXOjGO6WfXPdo3ILg9U7QQI2CG9TR4qW3j9sXaH/MQmDximAto6v9/B 6WFQ4BYq/UIPU0AgTbJLkFXXxz66Oqt9gzoAkN/xtTwFwZaR2UeFzpKuUgrjn7kE 2x3O7piBsHjXqa/1Q35pu/7tvxuUUebV9/dpYkdqiiVQHz9jnSJ2sCLdNFDhAri1 43dxfiC8DC4= =5UbB -----END PGP SIGNATURE----- --Apple-Mail=_92F2B441-D702-41F5-B2AB-32E27654C7F3-- From nobody Thu Jun 30 11:57:37 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E8C012D10E; Thu, 30 Jun 2016 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.326 X-Spam-Level: X-Spam-Status: No, score=-3.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=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 IOLrHGTP0-vY; Thu, 30 Jun 2016 11:57:30 -0700 (PDT) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD91F12B012; Thu, 30 Jun 2016 11:57:30 -0700 (PDT) Received: from [10.0.1.4] (cpe-66-25-7-22.tx.res.rr.com [66.25.7.22]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id u5UIvP9H009324 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 30 Jun 2016 13:57:26 -0500 (CDT) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-66-25-7-22.tx.res.rr.com [66.25.7.22] claimed to be [10.0.1.4] From: "Ben Campbell" To: "Fred Baker" Date: Thu, 30 Jun 2016 13:57:25 -0500 Message-ID: <527B64C7-DB2C-49DA-9AD5-5DE420513816@nostrum.com> In-Reply-To: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com> References: <71C83619-87E7-4C92-83A0-3834A6B6931C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.4r5234) Archived-At: Cc: "ops-dir@ietf.org" , "dispatch@ietf.org" , "draft-pd-dispatch-msrp-websocket.all@ietf.org" Subject: Re: [dispatch] Ops Directorate review of draft-pd-dispatch-msrp-websocket-12 X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 18:57:32 -0000 Hi Fred, thanks for your review! I think there may be room for tuning the language and citations a bit (I will let the authors address details), but the text that you quote is intended as an overview of WebSocket, not normative text about how you do MSRP over WebSocket. I think the best that _this_ draft can do is describe WebSocket as it exists now. Nothing in those sections should be taken to constrain how WebSocket might be updated to adapt to things like TLS 1.3 or HTTP/2. Alexey: Any thoughts on this from the perpective of an RFC 6455 author? Thanks! Ben. On 30 Jun 2016, at 12:57, Fred Baker (fred) wrote: > I am reviewing this document as part of the Operational directorate's > ongoing effort to review all IETF documents being processed by the > IESG. These comments were written with the intent of improving the > operational aspects of the IETF drafts. Comments that are not > addressed in last call may be included in AD reviews during the IESG > review. Document editors and WG chairs should treat these comments > just like any other last call comments. > > I have a few questions regarding the document. My perception, which > may or may not be correct, is that it targets down-rev protocols - > http/s 1.1 and TLS 1.2, the former of which has been obsoleted and > replaced and the latter is (I'm told) about to be. I'm fine with > having those as options, but it seems like publishing this without > references to the current technology means that it will need to be > updated or replaced soon with a document that does. > > Note that I am not registering these as objections; I think this is a > conversation that needs to be had, but if the consensus of people more > expert than myself in this technology is to stay down-rev, I'm OK with > it. > >> 1. Introduction >> >> The WebSocket [RFC6455] protocol enables message exchange between >> clients and servers on top of a persistent TCP connection >> (optionally >> secured with TLS [RFC5246]). The initial protocol handshake makes >> use of HTTP [RFC7230] semantics, allowing the WebSocket protocol >> to >> reuse existing HTTP infrastructure. > > I understand HTTP 1.1 (which is to say "pipelined TCP"), but I was > surprised to not read about RFC 7540 HTTP 2.0 (Secure TCP). Is there a > reason to not allow for the latter, at least as an option? > >> 3. WebSocket Protocol Overview >> >> The WebSocket protocol [RFC6455] is a transport layer on top of >> TCP >> (optionally secured with TLS [RFC5246]) in which both client and >> server exchange message units in both directions. > > Is this extensible to TLS 1.3, which I'm told is in the offing? That > would obsolete RFC 5246. From nobody Thu Jun 30 13:52:28 2016 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3AB12B00D for ; Thu, 30 Jun 2016 13:52:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.791 X-Spam-Level: X-Spam-Status: No, score=-1.791 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=thinkingcat.com 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 e7QNcdXiPo4O for ; Thu, 30 Jun 2016 13:52:24 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (sub4.mail.dreamhost.com [69.163.253.135]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9EDCA128874 for ; Thu, 30 Jun 2016 13:52:24 -0700 (PDT) Received: from homiemail-a113.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTP id 4B1B120058DB3; Thu, 30 Jun 2016 13:52:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=thinkingcat.com; h=from:to :subject:date:message-id:references:mime-version:content-type :content-transfer-encoding; s=thinkingcat.com; bh=xAnYvmJEcxPxXM FLPdBK/iT3doU=; b=d62RqMT5/WylFIBMTLvaQ8G8bAoJLRfiNInB6OCIg4pjtd dOXMi6Pvwx86yo4LJP3z1HAKqvlyrSjHjEeswsCrtewziczBxwvZUY5g7viE32B2 9C79838KQJYcg27gpP9x7FaBlvdnJJZUWwcjs2gO1azlgGcBsnuStHn2SLZyU= Received: from [192.168.1.102] (stjhnbsu0nw-142167225015.pppoe-dynamic.High-Speed.nb.bellaliant.net [142.167.225.15]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: leslie@oceanpurl.net) by homiemail-a113.g.dreamhost.com (Postfix) with ESMTPSA id 5F1F420058DAB; Thu, 30 Jun 2016 13:52:23 -0700 (PDT) From: "Leslie Daigle" To: dispatch@ietf.org, "Deen, Glenn" Date: Thu, 30 Jun 2016 16:52:21 -0400 Message-ID: References: <20160630201932.29483.64571.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed X-Mailer: MailMate (1.9.4r5234) Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [dispatch] Video, from glass to glass Fwd: I-D Action: draft-deen-daigle-ggie-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Jun 2016 20:52:27 -0000 Hi, Glenn (cc=E2=80=99ed) and I have asked for some time on the DISPATCH agen= da to=20 talk through the Glass to Glass Internet Ecosystem work that has been=20 touched on at the W3C and that we=E2=80=99ve been discussing in corridors= for=20 a couple of IETF meetings now. Please see below for the announcement of the updated GGIE overview=20 Internet-Draft: draft-deen-daigle-ggie-01.txt . Depending on how much=20 the typo in the title destroys my sleep, there may shortly be an -02 :^)=20 . There is a companion Internet-Draft that will be submitted next week=20 that details the proposed =E2=80=9Cmedia encoding network=E2=80=9D for MP= EG-DASH. From the BoF description we submitted: Description: Video is without rival the top use of Internet=20 bandwidth, and its ever growing demand for more bandwidth easily out=20 paces the new capacity being added both globally and regionally with no=20 let up in sight. The Glass to Glass Internet Ecosystem (GGIE) approach posits that=20 streamed content delivery can be viewed like a composed flow combining=20 many parts with playback composed of one or more component streams from=20 one or more addresses to one or more devices over one or more networks. We have identified 3 high level gaps that are relevant at the IETF: How applications identify, search for & refer to content How devices locate and address video sources How application level identifiers & network level identifiers are=20 mapped to one another On the whole, this work potentially spans several areas within the IETF=20 =E2=80=94 Applications (realtime or general infrastructure) and Routing. = =20 We=E2=80=99re chiefly looking for feedback and input to chisel out approa= ches=20 specific IETF work items and appropriate paths to pursue them. There will also be a demo of some of the =E2=80=9Cmedia encoded=20 network=E2=80=9D-based video delivery at Bits & Bites in Berlin. Feedback appreciated. Leslie (and Glenn). --=20 ------------------------------------------------------------------- Leslie Daigle Principal, ThinkingCat Enterprises LLC ldaigle@thinkingcat.com ------------------------------------------------------------------- Forwarded message: > From: internet-drafts@ietf.org > To: i-d-announce@ietf.org > Subject: I-D Action: draft-deen-daigle-ggie-01.txt > Date: Thu, 30 Jun 2016 13:19:32 -0700 > > > A New Internet-Draft is available from the on-line Internet-Drafts=20 > directories. > > > Title : Glass to Glass Internet Ecosysten=20 > Introduction > Authors : Glenn Deen > Leslie Daigle > Filename : draft-deen-daigle-ggie-01.txt > Pages : 21 > Date : 2016-06-30 > > Abstract: > This document introduces the Glass to Glass Internet Ecosystem > (GGIE). GGIE's purpose is to improve how the Internet is used=20 > create > and consume video, both amateur and professional, reflecting that=20 > the > line between amateur and professional video technology is > increasingly blurred. Glass to Glass refers to the entire video > ecosystem, from the camera lens to the viewing screen. As the name > implies, GGIE's scope is the entire video ecosystem from capture, > through the steps of editing, packaging, distributed and searching, > and finally viewing. GGIE is not a complete end to end=20 > architecture > or solution, it provides foundational elements that can serve as > building blocks for new Internet video innovation. > > This is a companion effort to the GGIE W3C Taskforce in the W3C Web > and TV Interest Group. > > This document is being discussed on the ggie@ietf.org mailing list. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-deen-daigle-ggie/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-deen-daigle-ggie-01 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-deen-daigle-ggie-01 > > > Please note that it may take a couple of minutes from the time of=20 > submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt