From nobody Tue Nov 3 19:58:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 008F91A9039 for ; Tue, 3 Nov 2015 19:58:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xqcdWpNG-Bf8 for ; Tue, 3 Nov 2015 19:58:00 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [4.31.198.40]) by ietfa.amsl.com (Postfix) with ESMTP id 225771A90C6 for ; Tue, 3 Nov 2015 19:58:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3CA181E5A26 for ; Tue, 3 Nov 2015 19:57:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1oevgypxVVsg for ; Tue, 3 Nov 2015 19:57:22 -0800 (PST) Received: from t20010c40000030322d7bc757f975f6df.v6.meeting.ietf94.jp (t20010c40000030322d7bc757f975f6df.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3032:2d7b:c757:f975:f6df]) by c8a.amsl.com (Postfix) with ESMTPA id DB7EE1E5A25 for ; Tue, 3 Nov 2015 19:57:21 -0800 (PST) From: Alexa Morris Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Tue, 3 Nov 2015 19:57:58 -0800 Message-Id: To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Sendlaterdate: Tue, 3 Nov 2015 19:57:58 -0800 X-Mailer: Apple Mail (2.1878.6) Archived-At: Subject: [dispatch] Queue for DISPATCH Remote Attendees X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 03:58:02 -0000 If you are planning to participate in the DISPATCH session here at IETF = 94 today =97 either locally in Yokohama or as a remote participant =97 = we want to make sure that you are aware that the IETF is providing = remote participants with a fairly new way to ask questions or make = comments. In addition to using the Jabber room, for the DISPATCH session = there is also the opportunity for remote participants to enter a virtual = queue and ask questions directly into the meeting room.=20 This experimental queue was used in several sessions at IETF 92 and IETF = 93, so you may have already seen it in action. There will be two queues = for the DISPATCH session =97 a virtual queue and an actual (in-room) = queue. Remote attendees will log into the Meetecho platform and will = have a virtual mic line that they can enter if they have a question or = comment. In-room participants will continue to use normal mic lines.=20 Instructions for remote participants are at = http://ietf94.conf.meetecho.com/index.php/Remote_Participation.=20 Information on how to join the Meetecho session is at = http://ietf94.conf.meetecho.com/. Verify that you are WebRTC compliant (required to use the virtual queue) = by performing a self-test here: = http://ietf94.conf.meetecho.com/index.php/Self_Test.=20 Regards, Alexa ---------- Alexa Morris / Executive Director / IETF 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 Phone: +1.510.492.4089 / Fax: +1.510.492.4001 Email: amorris@amsl.com Managed by Association Management Solutions (AMS) Forum Management, Meeting and Event Planning www.amsl.com From nobody Tue Nov 3 20:06:11 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930951A90D3 for ; Tue, 3 Nov 2015 20:06:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8_Fb46ySkoT0 for ; Tue, 3 Nov 2015 20:06:07 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com [IPv6:2607:f8b0:400e:c03::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 37ED91A90C0 for ; Tue, 3 Nov 2015 20:06:07 -0800 (PST) Received: by padhx2 with SMTP id hx2so31397279pad.1 for ; Tue, 03 Nov 2015 20:06:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=wbBENnHBRUOSg6zTtc9dUWwSN9Aqwjze/A8SFQRDCog=; b=vaA28KkqTZdKZ+nq0TPC+yhFpqFLM3eJHQ/IAT/VJ4hHhK8cvSxDTMvwfJNlT2HXpU FOywCgnxwXV2vNB0WzWuDnTEYCt8qwg0dpw4lHyyfw6u0Jesxhi2RDRftC01jItlmmYm zdu3C8X8dp906rYFKfE8/uMYJlcqWkon+05EPRNTgxFqKlagAdE9tDKfN+peZ+nZhQ3v ykbRAitlTM6qToUjxDWwUCyABfcciNlQ7DAP0tuthmc9ysYBUobXpt2kWt6x7MxNL2XI FY53o/XyKYkrAtl2KLt6lAWztBxy1cpaD6kTAhXH0p1aJKkQPxmE/VfHKGndaLRlLUK9 wgBg== X-Received: by 10.68.213.99 with SMTP id nr3mr38034039pbc.107.1446609966888; Tue, 03 Nov 2015 20:06:06 -0800 (PST) Received: from RoniPC (t20010c4000003032fd96360715ab615e.v6.meeting.ietf94.jp. [2001:c40:0:3032:fd96:3607:15ab:615e]) by smtp.gmail.com with ESMTPSA id ey2sm32240339pbd.77.2015.11.03.20.06.04 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 03 Nov 2015 20:06:05 -0800 (PST) From: "Roni Even" To: "'Alan Johnston'" , References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> In-Reply-To: Date: Wed, 4 Nov 2015 06:05:56 +0200 Message-ID: <004101d116b6$1d3a3d30$57aeb790$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01D116C6.E0C493D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1yENlE6yHyEUvqkOwv7lEvrYecwFMUzNtnzd43UA= Content-Language: he Archived-At: Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:06:09 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0042_01D116C6.E0C493D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi, In my view this approach contradict section 6.11 of RFC5763 =20 Best Effort Encryption =20 =20 [RFC5479] describes a requirement for best-effort encryption where SRTP is used and where both endpoints support it and key negotiation succeeds, otherwise RTP is used. =20 [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as an alternative. This allows an offerer to express a preference for SRTP, but RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism. Implementations of this document MUST support [MMUSIC-SDP = ]. =20 =20 From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan = Johnston Sent: Wednesday, July 08, 2015 2:03 PM To: dispatch@ietf.org Subject: [dispatch] Fwd: I-D Action: = draft-johnston-dispatch-osrtp-00.txt =20 All, =20 Many of us have been talking about "Best Effort SRTP" for many years, = and there are a number of deployments. In addition, the IMTC has = recommended it, and the SIP Forum would like to recommend it in = SIPconnect 2.0 which for the first time includes SRTP media. With the = publication of RFC 7435 (https://tools.ietf.org/html/rfc7435), the IETF = has endorsed this approach as Opportunistic Security (OS), so it would = be nice to bring standards in line with industry practice. =20 Comments on the draft, "An Opportunistic Approach for Secure Real-time = Transport Protocol (OSRTP)" and the best way forward are most welcome! =20 - Alan - =20 ---------- Forwarded message ---------- From: Date: Mon, Jul 6, 2015 at 1:48 PM Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts = directories. Title : An Opportunistic Approach for Secure Real-time = Transport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andy Hutton Laura Liess Thomas Stach Filename : draft-johnston-dispatch-osrtp-00.txt Pages : 8 Date : 2015-07-06 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP is an implementation of Opportunistic Security, as defined in RFC 7435. OSRTP does not require advanced SDP extensions or features and is fully backwards compatible with existing secure and insecure implementations. OSRTP is not specific to any key management technique for SRTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 Please note that it may take a couple of minutes from the time of = 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 =20 ------=_NextPart_000_0042_01D116C6.E0C493D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi,

In my view this approach contradict section 6.11 of = RFC5763

 

Best = Effort Encryption

 

 

=C2=A0=C2=A0 [RFC5479] = describes a requirement for best-effort encryption = where

=C2=A0=C2=A0 SRTP is used and where both endpoints = support it and key negotiation

=C2=A0=C2=A0 succeeds, otherwise RTP is = used.

 

=C2=A0=C2=A0 [MMUSIC-SDP] = describes a mechanism that can signal both RTP and = SRTP

=C2=A0=C2=A0 as an alternative.=C2=A0 This allows an = offerer to express a preference

=C2=A0=C2=A0 for SRTP, but RTP is the default and will = be understood by endpoints

=C2=A0=C2=A0 that do not understand SRTP or this key = exchange mechanism.

=C2=A0=C2=A0 Implementations of this document MUST = support [MMUSIC-SDP].

 

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan = Johnston
Sent: Wednesday, July 08, 2015 2:03 PM
To: = dispatch@ietf.org
Subject: [dispatch] Fwd: I-D Action: = draft-johnston-dispatch-osrtp-00.txt

 

 

Comments on the draft, "An Opportunistic Approach = for Secure Real-time Transport Protocol (OSRTP)" and the best way = forward are most welcome!

 

- = Alan -

 

---------- Forwarded message ----------
From: = <internet-drafts@ietf.org>=
Date: Mon, Jul 6, 2015 at 1:48 PM
Subject: I-D Action: = draft-johnston-dispatch-osrtp-00.txt
To: i-d-announce@ietf.org


A New Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title    =        : An Opportunistic Approach for Secure = Real-time Transport Protocol (OSRTP)
        = Authors         : Alan Johnston
  =                     =     Bernard Aboba
            =               Andy Hutton
  =                     =     Laura Liess
            =               Thomas Stach
  =       Filename        : = draft-johnston-dispatch-osrtp-00.txt
        = Pages           : 8
    =     Date            : = 2015-07-06

Abstract:
   Opportunistic Secure = Real-time Transport Protocol (OSRTP) allows
   encrypted = media to be used in environments where support for
  =  encryption is not known in advance, and not required.  OSRTP = is an
   implementation of Opportunistic Security, as = defined in RFC 7435.
   OSRTP does not require advanced SDP = extensions or features and is
   fully backwards compatible = with existing secure and insecure
   implementations.  = OSRTP is not specific to any key management
   technique = for SRTP.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-johnston-dispatc= h-osrtp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-johnston-dispatch-osr= tp-00


Please note that it may take a couple of minutes = from the time of 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
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 

------=_NextPart_000_0042_01D116C6.E0C493D0-- From nobody Tue Nov 3 20:13:23 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 486851A911D for ; Tue, 3 Nov 2015 20:13:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ztRJWkF2rKFZ for ; Tue, 3 Nov 2015 20:13:19 -0800 (PST) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFCEF1A90C3 for ; Tue, 3 Nov 2015 20:13:18 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.nyi.internal (Postfix) with ESMTP id 028662033D for ; Tue, 3 Nov 2015 23:13:15 -0500 (EST) Received: from frontend2 ([10.202.2.161]) by compute2.internal (MEProxy); Tue, 03 Nov 2015 23:13:16 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=cc :content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-sasl-enc :x-sasl-enc; s=mesmtp; bh=XIwZNjsJvuadzxa84M0CEmETdMg=; b=IRLBpH KOtRfDi69yADPxfNGngHQ5flpajlVN+Ozm5zZLkmkvgTcZzPHAVynbsMuWs65xyk H0bj48FDgapVGSEtXilifSJ5IV7bxLekJdHj8eT/op7MQ17cNg0MNO1ravaeRhOO 9qtCktV1Ugin7h+AcczldefhrCq6yAxo8bIHk= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-sasl-enc:x-sasl-enc; s=smtpout; bh=XIwZNjsJvuadzxa 84M0CEmETdMg=; b=lEy2WM/nvOsvMf3qeXyHu6c9D5H73KZjliENJmzOMYcyx1p xLbzOUsD/LxwJvI9PGcDpNxIbaRUdEhNBp98+A3VracjpyF5+osI6cxv74o1lrxX IajekI5z9aqvkXZkimnpRGxHcBXPEtAEOcHq/hfPGP/cIULkqfVbrvSXZmeU= X-Sasl-enc: sF/dmveM4Wu4zckIxGvMSQtL0XnLP6IOZTocrkR9ZK3q 1446610395 Received: from [10.24.245.225] (unknown [128.107.241.190]) by mail.messagingengine.com (Postfix) with ESMTPA id A29C36800B6; Tue, 3 Nov 2015 23:13:14 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) From: Alissa Cooper In-Reply-To: Date: Wed, 4 Nov 2015 13:13:12 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <2B784013-1E7E-4249-B998-E6A3E26030C6@cooperw.in> References: To: Mary Barnes X-Mailer: Apple Mail (2.2104) Archived-At: Cc: DISPATCH Subject: Re: [dispatch] Proposed new DISPATCH WG charter X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:13:21 -0000 > On Oct 6, 2015, at 7:03 AM, Mary Barnes = wrote: >=20 > 5. Ensuring the new work considers the impact on security and privacy = of > both the network and the user. Here=E2=80=99s my suggested edit: 5. Ensuring the new work considers security and privacy. Alissa From nobody Tue Nov 3 20:46:21 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1E61AC3F2 for ; Tue, 3 Nov 2015 20:46:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2xzzW7BfEW-j for ; Tue, 3 Nov 2015 20:46:18 -0800 (PST) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 003541AC3EE for ; Tue, 3 Nov 2015 20:46:17 -0800 (PST) Received: by ykba4 with SMTP id a4so53555391ykb.3 for ; Tue, 03 Nov 2015 20:46:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=276riEWOAC5eu2zA9MBLkH5D10kBOXlTFobMwbkqyXc=; b=UZm4a7pfHstL7XmqJOK/9eRXKcTE+fmFKuY6xP111EbHZgmCnGgu0FdH71WRviYLNN Dh047v5AypLJzRSpVO/5jAdCG65e9LiTg13jUz2JF2WcVrbcq40HLHIIAmBynpc6KJbI Qjyn9ZYsxeBOnMcanwTyWcl9adcIhFLEc23/ty5j8VSVjTILHtcFJrqXcxGpkZO27wFi Vyo7TJdMluSftCajBtV/fNmyRqd5dd4z0iCPG1Fl4QreDlCrWsABIIAHB7UiS/QehwDD LTMPLe6cy5KpJrevuqnNEBnLK5+nPMjRujOtbIB1BHRMq2vSKscMufOmoyrIhf1gKdmb pT0Q== MIME-Version: 1.0 X-Received: by 10.129.79.132 with SMTP id d126mr23060168ywb.159.1446612377216; Tue, 03 Nov 2015 20:46:17 -0800 (PST) Received: by 10.37.29.86 with HTTP; Tue, 3 Nov 2015 20:46:17 -0800 (PST) Date: Tue, 3 Nov 2015 22:46:17 -0600 Message-ID: From: Mary Barnes To: DISPATCH Content-Type: multipart/alternative; boundary=001a114dcb00df340c0523afb0c9 Archived-At: Subject: [dispatch] New Version Notification for draft-nottingham-rfc5988bis-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:46:20 -0000 --001a114dcb00df340c0523afb0c9 Content-Type: text/plain; charset=UTF-8 FYI...this is the document that Mark mentioned at the beginning of the DISPATCH WG session today. Regards, Mary. ---------- Forwarded message ---------- From: Mark Nottingham Date: Tue, Nov 3, 2015 at 10:24 PM Subject: Fwd: New Version Notification for draft-nottingham-rfc5988bis-00.txt To: Cullen Jennings , Mary Barnes < mary.ietf.barnes@gmail.com> Here you go. > Begin forwarded message: > > From: internet-drafts@ietf.org > Subject: New Version Notification for draft-nottingham-rfc5988bis-00.txt > Date: 4 November 2015 1:22:05 pm GMT+9 > To: "Mark Nottingham" > > > A new version of I-D, draft-nottingham-rfc5988bis-00.txt > has been successfully submitted by Mark Nottingham and posted to the > IETF repository. > > Name: draft-nottingham-rfc5988bis > Revision: 00 > Title: Web Linking > Document date: 2015-11-04 > Group: Individual Submission > Pages: 17 > URL: https://www.ietf.org/internet-drafts/draft-nottingham-rfc5988bis-00.txt > Status: https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/ > Htmlized: https://tools.ietf.org/html/draft-nottingham-rfc5988bis-00 > > > Abstract: > This specification defines a way to indicate the relationships > between resources on the Web ("links") and the type of those > relationships ("link relation types"). > > It also defines the use of such links in HTTP headers with the Link > header field. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > -- Mark Nottingham https://www.mnot.net/ --001a114dcb00df340c0523afb0c9 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
FYI...this is the document that Mark mentioned at the begi= nning of the DISPATCH WG session today.

Regards,
Mary.

---------- Forwarded mess= age ----------
From: Mark Nottingham <= span dir=3D"ltr"><mnot@mnot.net>=
Date: Tue, Nov 3, 2015 at 10:24 PM
Subject: Fwd: New Version = Notification for draft-nottingham-rfc5988bis-00.txt
To: Cullen Jennings = <fluffy@cisco.com>, Mary Barn= es <mary.ietf.barnes@gmail= .com>


Here you go.

> Begin forwarded message:
>
> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-nottingham-rfc5988bis-00.t= xt
> Date: 4 November 2015 1:22:05 pm GMT+9
> To: "Mark Nottingham" <m= not@mnot.net>
>
>
> A new version of I-D, draft-nottingham-rfc5988bis-00.txt
> has been successfully submitted by Mark Nottingham and posted to the > IETF repository.
>
> Name:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0draft-nottingham-rfc5988bis
> Revision:=C2=A0 =C2=A0 =C2=A000
> Title:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Web Link= ing
> Document date:=C2=A0 =C2=A0 =C2=A0 =C2=A0 2015-11-04
> Group:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Individu= al Submission
> Pages:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 17
> URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draft-nottingham= -rfc5988bis-00.txt
> Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-nottingham-rfc5988bis/ > Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0h= ttps://tools.ietf.org/html/draft-nottingham-rfc5988bis-00
>
>
> Abstract:
>=C2=A0 =C2=A0This specification defines a way to indicate the relations= hips
>=C2=A0 =C2=A0between resources on the Web ("links") and the t= ype of those
>=C2=A0 =C2=A0relationships ("link relation types").
>
>=C2=A0 =C2=A0It also defines the use of such links in HTTP headers with= the Link
>=C2=A0 =C2=A0header field.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org. >
> The IETF Secretariat
>

--
Mark Nottingham=C2=A0 =C2=A0https://www.mnot.net/





--001a114dcb00df340c0523afb0c9-- From nobody Tue Nov 3 20:52:29 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1851AC419 for ; Tue, 3 Nov 2015 20:52:28 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eXnmFSMm9cud for ; Tue, 3 Nov 2015 20:52:17 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 9FE301AC418 for ; Tue, 3 Nov 2015 20:52:17 -0800 (PST) Received: from dhcp-25-140.meeting.ietf94.jp ([133.93.25.140]:50366) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1Ztq3S-0002Pb-A0; Wed, 04 Nov 2015 04:52:14 +0000 To: Mary Barnes , dispatch@ietf.org References: From: Bob Briscoe Message-ID: <56398EFA.5040902@bobbriscoe.net> Date: Wed, 4 Nov 2015 04:52:10 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: [dispatch] link for video within Ultra-Low Delay slot for DISPATCH Remote Attendees X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:52:28 -0000 Mary, Dispatchers, Remote attendees will/may not be able to see the video that will be used as part of the final slot in the current Dispatch session: "Ultra-Low Queuing Delay for all Applications" If necessary, here are the two videos available off the Web: Mary, if you need these for the proceedings in some other way, just shout. Bob On 04/11/15 03:57, Alexa Morris wrote: > If you are planning to participate in the DISPATCH session here at IETF 94 today — either locally in Yokohama or as a remote participant — we want to make sure that you are aware that the IETF is providing remote participants with a fairly new way to ask questions or make comments. In addition to using the Jabber room, for the DISPATCH session there is also the opportunity for remote participants to enter a virtual queue and ask questions directly into the meeting room. > > This experimental queue was used in several sessions at IETF 92 and IETF 93, so you may have already seen it in action. There will be two queues for the DISPATCH session — a virtual queue and an actual (in-room) queue. Remote attendees will log into the Meetecho platform and will have a virtual mic line that they can enter if they have a question or comment. In-room participants will continue to use normal mic lines. > > Instructions for remote participants are at http://ietf94.conf.meetecho.com/index.php/Remote_Participation. > > Information on how to join the Meetecho session is at http://ietf94.conf.meetecho.com/. > > Verify that you are WebRTC compliant (required to use the virtual queue) by performing a self-test here: http://ietf94.conf.meetecho.com/index.php/Self_Test. > > Regards, > Alexa > > ---------- > Alexa Morris / Executive Director / IETF > 48377 Fremont Blvd., Suite 117, Fremont, CA 94538 > Phone: +1.510.492.4089 / Fax: +1.510.492.4001 > Email: amorris@amsl.com > > Managed by Association Management Solutions (AMS) > Forum Management, Meeting and Event Planning > www.amsl.com > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Tue Nov 3 20:58:37 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A7CE1AC43A for ; Tue, 3 Nov 2015 20:58:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05IHRyjtOcW2 for ; Tue, 3 Nov 2015 20:58:34 -0800 (PST) Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 914801AC438 for ; Tue, 3 Nov 2015 20:58:34 -0800 (PST) Received: from dhcp-25-168.meeting.ietf94.jp (unknown [133.93.25.168]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 4A0DC509BE for ; Tue, 3 Nov 2015 23:58:32 -0500 (EST) From: Mark Nottingham Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <851BF5F7-02C7-42BB-985D-A1E20EFAE478@mnot.net> Date: Wed, 4 Nov 2015 13:58:30 +0900 To: dispatch@ietf.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2104\)) X-Mailer: Apple Mail (2.2104) Archived-At: Subject: [dispatch] Content Security Policy Directive Registry X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 04:58:36 -0000 As discussed in the meeting: https://tools.ietf.org/html/draft-west-webappsec-csp-reg -- Mark Nottingham https://www.mnot.net/ From nobody Wed Nov 4 02:52:45 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 482E51B2D20 for ; Wed, 4 Nov 2015 02:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OXlbec0QTYoY for ; Wed, 4 Nov 2015 02:52:42 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::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 F2F081B2D18 for ; Wed, 4 Nov 2015 02:52:41 -0800 (PST) Received: by qkcl124 with SMTP id l124so18232494qkc.3 for ; Wed, 04 Nov 2015 02:52:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=N5XK5RIBmjNsA+K2jBY7lj335Urn3KFdKP2AmBxo8Wg=; b=MK3nqA5oTncG4gFEZgyIEg+rfspvRnr5pDt3+Xa846gJwW4ezsoDBWfgdHReVb637p yxDZRk2ZL/E5JOfZ3mvEiVgJuCrBn5sSFJZeinXNSkJ5CYdvTYLsjzObiNqGeWpweCk6 DvJaBwlifCHrcz9lfTDlDtzw7GCh40K0U2u3KFa4qsHDHnQ54j4WDjuK7/1K5cq9OPuH Fedn1XYVZmVeaM6JS83xdwoZehRZcvZpr00M3X2x6RIRDHrsben+g+21pdWVn1Q3D8dm KRauZ617MGgOxo6T8oR6/xKRO3rGSZ0fNNeichHYiKO5LR8YYFfoBkIoZqVsvn/5fMZw 9AMQ== MIME-Version: 1.0 X-Received: by 10.55.18.40 with SMTP id c40mr662910qkh.99.1446634361202; Wed, 04 Nov 2015 02:52:41 -0800 (PST) Received: by 10.55.39.82 with HTTP; Wed, 4 Nov 2015 02:52:41 -0800 (PST) In-Reply-To: <004101d116b6$1d3a3d30$57aeb790$@gmail.com> References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> <004101d116b6$1d3a3d30$57aeb790$@gmail.com> Date: Wed, 4 Nov 2015 11:52:41 +0100 Message-ID: From: Laura Liess To: Roni Even Content-Type: multipart/alternative; boundary=001a114764d238339f0523b4cf6d Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 10:52:44 -0000 --001a114764d238339f0523b4cf6d Content-Type: text/plain; charset=UTF-8 Hi Roni, [MMUSIC-SDP ] is now RFC 5939 and it seems to be a MUST for implementations of the RFC 5763 (SRTP with DTLS). At Deutsche Telekom we plan to connect SIP-PBXe in the near future using SRTP with SDES. We are not aware of any existing SIP-PBX which supports RFC 5763, most existing SIP-PBXs suport different flavors of the kaplan-draft. RFC 5763 seems to be too complex so that PBX vendors are not willing to support it, at least in connection with SDES. This is also the case for our service provider call control vendors. So, a less complex mechanism is needed for best effort SRTP. Thank you Laura 2015-11-04 5:05 GMT+01:00 Roni Even : > Hi, > > In my view this approach contradict section 6.11 of RFC5763 > > > > *Best Effort Encryption* > > > > > > [RFC5479] describes a requirement for best-effort encryption where > > SRTP is used and where both endpoints support it and key negotiation > > succeeds, otherwise RTP is used. > > > > [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP > > as an alternative. This allows an offerer to express a preference > > for SRTP, but RTP is the default and will be understood by endpoints > > that do not understand SRTP or this key exchange mechanism. > > Implementations of this document MUST support [MMUSIC-SDP > ]. > > > > > > *From:* dispatch [mailto:dispatch-bounces@ietf.org] *On Behalf Of *Alan > Johnston > *Sent:* Wednesday, July 08, 2015 2:03 PM > *To:* dispatch@ietf.org > *Subject:* [dispatch] Fwd: I-D Action: > draft-johnston-dispatch-osrtp-00.txt > > > > All, > > > > Many of us have been talking about "Best Effort SRTP" for many years, and > there are a number of deployments. In addition, the IMTC has recommended > it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which > for the first time includes SRTP media. With the publication of RFC 7435 ( > https://tools.ietf.org/html/rfc7435), the IETF has endorsed this approach > as Opportunistic Security (OS), so it would be nice to bring standards in > line with industry practice. > > > > Comments on the draft, "An Opportunistic Approach for Secure Real-time > Transport Protocol (OSRTP)" and the best way forward are most welcome! > > > > - Alan - > > > > ---------- Forwarded message ---------- > From: > Date: Mon, Jul 6, 2015 at 1:48 PM > Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt > To: i-d-announce@ietf.org > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : An Opportunistic Approach for Secure Real-time > Transport Protocol (OSRTP) > Authors : Alan Johnston > Bernard Aboba > Andy Hutton > Laura Liess > Thomas Stach > Filename : draft-johnston-dispatch-osrtp-00.txt > Pages : 8 > Date : 2015-07-06 > > Abstract: > Opportunistic Secure Real-time Transport Protocol (OSRTP) allows > encrypted media to be used in environments where support for > encryption is not known in advance, and not required. OSRTP is an > implementation of Opportunistic Security, as defined in RFC 7435. > OSRTP does not require advanced SDP extensions or features and is > fully backwards compatible with existing secure and insecure > implementations. OSRTP is not specific to any key management > technique for SRTP. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 > > > Please note that it may take a couple of minutes from the time of > 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 > > > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > --001a114764d238339f0523b4cf6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Roni,

[MMUSIC-SDP= ] is now RFC 5939 and it seems to be a MUST for implementations of the= =C2=A0 RFC 5763 (SRTP with DTLS).

At Deutsche Telekom we pla= n to connect SIP-PBXe in the near future using SRTP with SDES.=C2=A0 We are= not aware of any existing SIP-PBX which supports RFC 5763, most existing S= IP-PBXs suport different flavors of the kaplan-draft. RFC 5763 seems to be = too complex so that PBX vendors are not willing to support it, at least in = connection with SDES. This is also the case for our service provider call c= ontrol vendors.=C2=A0 So, a less complex mechanism is needed for best effor= t SRTP.

Thank you
Laura

2015-11-04 5:05 GMT+01:00 Roni Even= <ron.even.tlv@gmail.com>:

Hi,

In my view this approach contradi= ct section 6.11 of RFC5763

<= span style=3D"font-size:11.0pt;font-family:"Calibri","sans-s= erif";color:#1f497d">=C2=A0

Best Effort Encryption

=C2=A0

= =C2=A0

=C2=A0=C2= =A0 [RFC5479] describes a requ= irement for best-effort encryption where

=C2=A0=C2=A0 SRTP is used and where both endpoints sup= port it and key negotiation

= =C2=A0=C2=A0 succeeds, otherwise RTP is used.

=C2=A0

=C2=A0=C2=A0 [MM= USIC-SDP] describes a mechanism that can signal both RTP and SRTP

=C2=A0=C2=A0 as an alternat= ive.=C2=A0 This allows an offerer to express a preference

=C2=A0=C2=A0 for SRTP, but RTP is the d= efault and will be understood by endpoints

=C2=A0=C2=A0 that do not understand SRTP or this key e= xchange mechanism.

=C2= =A0=C2=A0 Implementations of this document MUST support [MMUSIC-SDP].

=C2=A0

=C2=A0

From: dispatch [mailto:dispatch-bounces@ietf.org] On = Behalf Of Alan Johnston
Sent: Wednesday, July 08, 2015 2:03 P= M
To: disp= atch@ietf.org
Subject: [dispatch] Fwd: I-D Action: draft-john= ston-dispatch-osrtp-00.txt

<= p class=3D"MsoNormal">=C2=A0

All,

=C2=A0

Many of us have been talking abo= ut "Best Effort SRTP" for many years, and there are a number of d= eployments.=C2=A0 In addition, the IMTC has recommended it, and the SIP For= um would like to recommend it in SIPconnect 2.0 which for the first time in= cludes SRTP media.=C2=A0 With the publication of RFC 7435 (https://tools.ietf.org/ht= ml/rfc7435), the IETF has endorsed this approach as Opportunistic Secur= ity (OS), so it would be nice to bring standards in line with industry prac= tice.

=C2=A0

Comments on the draft, "An Opp= ortunistic Approach for Secure Real-time Transport Protocol (OSRTP)" a= nd the best way forward are most welcome!

=C2=A0

- Alan -

=C2=A0<= u>

---------- Forwarded message --= --------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 6, 2015 at 1:48= PM
Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
To: i-d-announce@ietf.o= rg



A New Internet-Draft is available from the on-line In= ternet-Drafts directories.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Title=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: An Opportunistic Approach for Secur= e Real-time Transport Protocol (OSRTP)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Autho= rs=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: Alan Johnston
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Bern= ard Aboba
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andy Hutton
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Laura Liess
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 Thomas Stach
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Filename=C2= =A0 =C2=A0 =C2=A0 =C2=A0 : draft-johnston-dispatch-osrtp-00.txt
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 Pages=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0: 8
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 Date=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 := 2015-07-06

Abstract:
=C2=A0 =C2=A0Opportunistic Secure Real-time= Transport Protocol (OSRTP) allows
=C2=A0 =C2=A0encrypted media to be us= ed in environments where support for
=C2=A0 =C2=A0encryption is not know= n in advance, and not required.=C2=A0 OSRTP is an
=C2=A0 =C2=A0implement= ation of Opportunistic Security, as defined in RFC 7435.
=C2=A0 =C2=A0OS= RTP does not require advanced SDP extensions or features and is
=C2=A0 = =C2=A0fully backwards compatible with existing secure and insecure
=C2= =A0 =C2=A0implementations.=C2=A0 OSRTP is not specific to any key managemen= t
=C2=A0 =C2=A0technique for SRTP.


The IETF datatracker statu= s page for this draft is:
https://datatracker.ietf.or= g/doc/draft-johnston-dispatch-osrtp/

There's also a htmlized= version available at:
https://tools.ietf.org/html/draft= -johnston-dispatch-osrtp-00


Please note that it may take a c= ouple of minutes from the time of submission
until the htmlized version = and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymo= us 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.or= g/ietf/1shadow-sites.txt

= =C2=A0


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


--001a114764d238339f0523b4cf6d-- From nobody Wed Nov 4 05:31:04 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36DC21B2F4B for ; Wed, 4 Nov 2015 05:31:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.609 X-Spam-Level: X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XDWXxnnYi6TD for ; Wed, 4 Nov 2015 05:31:00 -0800 (PST) Received: from mx12.unify.com (mx12.unify.com [62.134.46.10]) by ietfa.amsl.com (Postfix) with ESMTP id 036E11B2F45 for ; Wed, 4 Nov 2015 05:31:00 -0800 (PST) Received: from MCHP02HTC.global-ad.net (unknown [172.29.42.235]) by mx12.unify.com (Server) with ESMTP id 24ADD23F04B3; Wed, 4 Nov 2015 14:30:59 +0100 (CET) Received: from MCHP04MSX.global-ad.net ([169.254.37.243]) by MCHP02HTC.global-ad.net ([172.29.42.235]) with mapi id 14.03.0248.002; Wed, 4 Nov 2015 14:30:58 +0100 From: "Hutton, Andrew" To: Laura Liess Thread-Topic: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt Thread-Index: AQF1yENlE6yHyEUvqkOwv7lEvrYecwFMUzNtnzd43UCAAGEZgIAAPP02 Date: Wed, 4 Nov 2015 13:30:57 +0000 Message-ID: References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> <004101d116b6$1d3a3d30$57aeb790$@gmail.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: Content-Type: multipart/alternative; boundary="_000_DE7D80A9792A45FCB7974DE272FF1003unifycom_" MIME-Version: 1.0 Archived-At: Cc: "dispatch@ietf.org" Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 13:31:03 -0000 --_000_DE7D80A9792A45FCB7974DE272FF1003unifycom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Agree with Laura what we are doing here is aligning existing implementation= s that already exist in the field and document that in and RFC so that we c= an move forward with regard to deployment of SRTP in SIP Trunking environme= nts. Currently RFC 5763 is not supported at all in this environment and I have n= ot heard a single voice in support of using SDP capability negotiation for = SIP Trunking. Moving forward with the draft is our best chance of seeing SRTP start to be= deployed with SIP Trunking. Andy On 4 Nov 2015, at 19:52, Laura Liess > wrote: Hi Roni, [MMUSIC-SDP] is now RFC= 5939 and it seems to be a MUST for implementations of the RFC 5763 (SRTP = with DTLS). At Deutsche Telekom we plan to connect SIP-PBXe in the near future using SR= TP with SDES. We are not aware of any existing SIP-PBX which supports RFC = 5763, most existing SIP-PBXs suport different flavors of the kaplan-draft. = RFC 5763 seems to be too complex so that PBX vendors are not willing to sup= port it, at least in connection with SDES. This is also the case for our se= rvice provider call control vendors. So, a less complex mechanism is neede= d for best effort SRTP. Thank you Laura 2015-11-04 5:05 GMT+01:00 Roni Even >: Hi, In my view this approach contradict section 6.11 of RFC5763 Best Effort Encryption [RFC5479] describes a requirement for best-effort encryption where SRTP is used and where both endpoints support it and key negotiation succeeds, otherwise RTP is used. [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as an alternative. This allows an offerer to express a preference for SRTP, but RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism. Implementations of this document MUST support [MMUSIC-SDP]. From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Wednesday, July 08, 2015 2:03 PM To: dispatch@ietf.org Subject: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt All, Many of us have been talking about "Best Effort SRTP" for many years, and t= here are a number of deployments. In addition, the IMTC has recommended it= , and the SIP Forum would like to recommend it in SIPconnect 2.0 which for = the first time includes SRTP media. With the publication of RFC 7435 (http= s://tools.ietf.org/html/rfc7435), the IETF has endorsed this approach as Op= portunistic Security (OS), so it would be nice to bring standards in line w= ith industry practice. Comments on the draft, "An Opportunistic Approach for Secure Real-time Tran= sport Protocol (OSRTP)" and the best way forward are most welcome! - Alan - ---------- Forwarded message ---------- From: > Date: Mon, Jul 6, 2015 at 1:48 PM Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : An Opportunistic Approach for Secure Real-time Tr= ansport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andy Hutton Laura Liess Thomas Stach Filename : draft-johnston-dispatch-osrtp-00.txt Pages : 8 Date : 2015-07-06 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP is an implementation of Opportunistic Security, as defined in RFC 7435. OSRTP does not require advanced SDP extensions or features and is fully backwards compatible with existing secure and insecure implementations. OSRTP is not specific to any key management technique for SRTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 Please note that it may take a couple of minutes from the time of submissio= n 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 _______________________________________________ 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_DE7D80A9792A45FCB7974DE272FF1003unifycom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Agree with Laura what we are doing here is aligning existing implement= ations that already exist in the field and document that in and RFC so that= we can move forward with regard to deployment of SRTP in SIP Trunking envi= ronments.

Currently RFC 5763 is not supported at all i= n this environment and I have not heard a single voice in support of using = SDP capability negotiation for SIP Trunking.

Moving forward with the draft is our best ch= ance of seeing SRTP start to be deployed with SIP Trunking.

Andy





On 4 Nov 2015, at 19:52, Laura Liess <laura.liess.dt@googlemail.com> wrote:

Hi Roni,

[MMUSIC-SDP] is now RFC 5939 and it seems to be a MUST for = implementations of the  RFC 5763 (SRTP with DTLS).

At Deutsche Telekom we plan to connect SIP-PBXe in the near future using SR= TP with SDES.  We are not aware of any existing SIP-PBX which supports= RFC 5763, most existing SIP-PBXs suport different flavors of the kaplan-dr= aft. RFC 5763 seems to be too complex so that PBX vendors are not willing to support it, at least in connection = with SDES. This is also the case for our service provider call control vend= ors.  So, a less complex mechanism is needed for best effort SRTP.

Thank you
Laura

2015-11-04 5:05 GMT+01:00 Roni Even <r= on.even.tlv@gmail.com>:

Hi,<= /p>

In my view this approach = contradict section 6.11 of RFC5763

 

Best Effort Encryption=

 

 

   [RFC5479] describes a requirement for best-effort encryption wh= ere

   SRTP is used and where both endpo= ints support it and key negotiation

   succeeds, otherwise RTP is used.<= u>

 

   [MMUSIC-SDP] describes a mechanism that can signal both RTP = and SRTP

   as an alternative.  This all= ows an offerer to express a preference

   for SRTP, but RTP is the default = and will be understood by endpoints

   that do not understand SRTP or th= is key exchange mechanism.

   Implementations of this document = MUST support [MMUSIC-SDP].

 

 

From: dispatch= [mailto:dis= patch-bounces@ietf.org] On Behalf Of Alan Johnston
Sent: Wednesday, July 08, 2015 2:03 PM
To: dispatch@= ietf.org
Subject: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-0= 0.txt

 

All,

 

Many of us have been talking about "Best Effort= SRTP" for many years, and there are a number of deployments.  In= addition, the IMTC has recommended it, and the SIP Forum would like to rec= ommend it in SIPconnect 2.0 which for the first time includes SRTP media.  With the publication of RFC 7435 (https://tools.ietf.org= /html/rfc7435), the IETF has endorsed this approach as Opportunistic Se= curity (OS), so it would be nice to bring standards in line with industry practice.

 

Comments on the draft, "An Opportunistic Approa= ch for Secure Real-time Transport Protocol (OSRTP)" and the best way f= orward are most welcome!

 

- Alan -

 

---------- Forwarded message ----------
From: <int= ernet-drafts@ietf.org>
Date: Mon, Jul 6, 2015 at 1:48 PM
Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


        Title           := An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)<= br>         Authors         : Alan= Johnston
                     = ;     Bernard Aboba
                     = ;     Andy Hutton
                     = ;     Laura Liess
                     = ;     Thomas Stach
        Filename        : draft-joh= nston-dispatch-osrtp-00.txt
        Pages           := 8
        Date            := 2015-07-06

Abstract:
   Opportunistic Secure Real-time Transport Protocol (OSRTP) allo= ws
   encrypted media to be used in environments where support for    encryption is not known in advance, and not required.  OS= RTP is an
   implementation of Opportunistic Security, as defined in RFC 74= 35.
   OSRTP does not require advanced SDP extensions or features and= is
   fully backwards compatible with existing secure and insecure    implementations.  OSRTP is not specific to any key manage= ment
   technique for SRTP.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-johnston-dispatch= -osrtp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-0= 0


Please note that it may take a couple of minutes from the time of submissio= n
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@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announc= e
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 


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


_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://ww= w.ietf.org/mailman/listinfo/dispatch
--_000_DE7D80A9792A45FCB7974DE272FF1003unifycom_-- From nobody Wed Nov 4 13:52:24 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E18041B3430 for ; Wed, 4 Nov 2015 13:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruHAtNGdc8cE for ; Wed, 4 Nov 2015 13:52:19 -0800 (PST) Received: from mail-pa0-x234.google.com (mail-pa0-x234.google.com [IPv6:2607:f8b0:400e:c03::234]) (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 A31CC1B342E for ; Wed, 4 Nov 2015 13:52:19 -0800 (PST) Received: by pasz6 with SMTP id z6so66475974pas.2 for ; Wed, 04 Nov 2015 13:52:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-type:thread-index:content-language; bh=/wWfTrMQOfkjFU2OY8PE+IZKU8umDW0sUTsOvYciYcQ=; b=KIFWw2NSQrD7gdwvXIedj9RbwIVXCxsGIL/OE/lPBc3K0HVVUpcZe/WtEPNMHjo3Ct 18TLP5sneMxZ1iHgeA6uXCnzl2AYnMybvSwKk1JNk3HkQQukwRgtW95DCPc3VKkY6Yuy 3FbrnJNO0RCtJlsbj5VsuCa8qLUmleKohHlL7h1MvesQXSGZc9lmeotq73varotRWwF3 loMNjPyWowtwWYTP6BFPHzlApf2NF34UcyOV1jDKcC6XoEmY/eHpIZvbso+mk41TX9at DuRWc/ALnPEWu9vvb5GqFa6RtRsObAH9G/v7H2S/yAAH9n+rAuv53RZ9rlD2tsXL9IRn 60mw== X-Received: by 10.68.65.67 with SMTP id v3mr4861662pbs.69.1446673938930; Wed, 04 Nov 2015 13:52:18 -0800 (PST) Received: from RoniPC (122x210x83x163.ap122.ftth.ucom.ne.jp. [122.210.83.163]) by smtp.gmail.com with ESMTPSA id cx5sm3846239pbc.50.2015.11.04.13.52.15 (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 04 Nov 2015 13:52:17 -0800 (PST) From: "Roni Even" To: "'Hutton, Andrew'" , "'Laura Liess'" References: <20150706184857.15450.31472.idtracker@ietfa.amsl.com> <004101d116b6$1d3a3d30$57aeb790$@gmail.com>, In-Reply-To: Date: Wed, 4 Nov 2015 23:52:04 +0200 Message-ID: <00f901d1174b$0ecc6f80$2c654e80$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00FA_01D1175B.D25873D0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF1yENlE6yHyEUvqkOwv7lEvrYecwFMUzNtAZtPprMBkWr3FwMwf4LcnwW4o0A= Content-Language: he Archived-At: Cc: dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Nov 2015 21:52:23 -0000 This is a multipart message in MIME format. ------=_NextPart_000_00FA_01D1175B.D25873D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit HI, My concern is about having inconsistency in the standards. If you go ahead with OSRTP there is a need also to update RFC5763 accordingly Roni From: Hutton, Andrew [mailto:andrew.hutton@unify.com] Sent: Wednesday, November 04, 2015 3:31 PM To: Laura Liess Cc: Roni Even; dispatch@ietf.org Subject: Re: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt Agree with Laura what we are doing here is aligning existing implementations that already exist in the field and document that in and RFC so that we can move forward with regard to deployment of SRTP in SIP Trunking environments. Currently RFC 5763 is not supported at all in this environment and I have not heard a single voice in support of using SDP capability negotiation for SIP Trunking. Moving forward with the draft is our best chance of seeing SRTP start to be deployed with SIP Trunking. Andy On 4 Nov 2015, at 19:52, Laura Liess wrote: Hi Roni, [MMUSIC-SDP ] is now RFC 5939 and it seems to be a MUST for implementations of the RFC 5763 (SRTP with DTLS). At Deutsche Telekom we plan to connect SIP-PBXe in the near future using SRTP with SDES. We are not aware of any existing SIP-PBX which supports RFC 5763, most existing SIP-PBXs suport different flavors of the kaplan-draft. RFC 5763 seems to be too complex so that PBX vendors are not willing to support it, at least in connection with SDES. This is also the case for our service provider call control vendors. So, a less complex mechanism is needed for best effort SRTP. Thank you Laura 2015-11-04 5:05 GMT+01:00 Roni Even : Hi, In my view this approach contradict section 6.11 of RFC5763 Best Effort Encryption [RFC5479] describes a requirement for best-effort encryption where SRTP is used and where both endpoints support it and key negotiation succeeds, otherwise RTP is used. [MMUSIC-SDP] describes a mechanism that can signal both RTP and SRTP as an alternative. This allows an offerer to express a preference for SRTP, but RTP is the default and will be understood by endpoints that do not understand SRTP or this key exchange mechanism. Implementations of this document MUST support [MMUSIC-SDP ]. From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of Alan Johnston Sent: Wednesday, July 08, 2015 2:03 PM To: dispatch@ietf.org Subject: [dispatch] Fwd: I-D Action: draft-johnston-dispatch-osrtp-00.txt All, Many of us have been talking about "Best Effort SRTP" for many years, and there are a number of deployments. In addition, the IMTC has recommended it, and the SIP Forum would like to recommend it in SIPconnect 2.0 which for the first time includes SRTP media. With the publication of RFC 7435 (https://tools.ietf.org/html/rfc7435), the IETF has endorsed this approach as Opportunistic Security (OS), so it would be nice to bring standards in line with industry practice. Comments on the draft, "An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP)" and the best way forward are most welcome! - Alan - ---------- Forwarded message ---------- From: Date: Mon, Jul 6, 2015 at 1:48 PM Subject: I-D Action: draft-johnston-dispatch-osrtp-00.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : An Opportunistic Approach for Secure Real-time Transport Protocol (OSRTP) Authors : Alan Johnston Bernard Aboba Andy Hutton Laura Liess Thomas Stach Filename : draft-johnston-dispatch-osrtp-00.txt Pages : 8 Date : 2015-07-06 Abstract: Opportunistic Secure Real-time Transport Protocol (OSRTP) allows encrypted media to be used in environments where support for encryption is not known in advance, and not required. OSRTP is an implementation of Opportunistic Security, as defined in RFC 7435. OSRTP does not require advanced SDP extensions or features and is fully backwards compatible with existing secure and insecure implementations. OSRTP is not specific to any key management technique for SRTP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-johnston-dispatch-osrtp-00 Please note that it may take a couple of minutes from the time of 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 _______________________________________________ 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 ------=_NextPart_000_00FA_01D1175B.D25873D0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

HI,

My concern is about having inconsistency in the standards. If you go = ahead with OSRTP there is a need also to update RFC5763 = accordingly

Roni

 

From:= = Hutton, Andrew [mailto:andrew.hutton@unify.com]
Sent: = Wednesday, November 04, 2015 3:31 PM
To: Laura = Liess
Cc: Roni Even; dispatch@ietf.org
Subject: Re: = [dispatch] Fwd: I-D Action: = draft-johnston-dispatch-osrtp-00.txt

 

Agree = with Laura what we are doing here is aligning existing implementations = that already exist in the field and document that in and RFC so that we = can move forward with regard to deployment of SRTP in SIP Trunking = environments.

 

Currently RFC 5763 is not = supported at all in this environment and I have not heard a single voice = in support of using SDP capability negotiation for SIP = Trunking.

 

Moving forward with the = draft is our best chance of seeing SRTP start to be deployed with SIP = Trunking.

 

Andy

 

 

 

 


On 4 Nov 2015, at 19:52, Laura Liess = <laura.liess.dt@googlemail.c= om> wrote:

<= p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Hi = Roni,

[MMUSIC-SDP] is now RFC 5939 and it seems to be a = MUST for implementations of the  RFC 5763 (SRTP with DTLS). =

At Deutsche Telekom we plan to connect SIP-PBXe in the near = future using SRTP with SDES.  We are not aware of any existing = SIP-PBX which supports RFC 5763, most existing SIP-PBXs suport different = flavors of the kaplan-draft. RFC 5763 seems to be too complex so that = PBX vendors are not willing to support it, at least in connection with = SDES. This is also the case for our service provider call control = vendors.  So, a less complex mechanism is needed for best effort = SRTP.

Thank = you

Laura =

 

2015-11-04 5:05 GMT+01:00 Roni Even <ron.even.tlv@gmail.com>:

Hi,

In my view this approach contradict section 6.11 of = RFC5763

 

Best = Effort Encryption

 

 

   [RFC5479] describes a = requirement for best-effort encryption where

   SRTP is used and where both endpoints = support it and key negotiation

   succeeds, otherwise RTP is = used.

 

   [MMUSIC-SDP] describes a = mechanism that can signal both RTP and SRTP

   as an alternative.  This allows an = offerer to express a preference

   for SRTP, but RTP is the default and will = be understood by endpoints

   that do not understand SRTP or this key = exchange mechanism.

   Implementations of this document MUST = support [MMUSIC-SDP].

 

 

From:= = dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of = Alan Johnston
Sent: Wednesday, July 08, 2015 2:03 = PM
To: dispatch@ietf.org
Subject: [dispatch] = Fwd: I-D Action: = draft-johnston-dispatch-osrtp-00.txt

 <= /o:p>

All,

 <= /o:p>

Many of us = have been talking about "Best Effort SRTP" for many years, and = there are a number of deployments.  In addition, the IMTC has = recommended it, and the SIP Forum would like to recommend it in = SIPconnect 2.0 which for the first time includes SRTP media.  With = the publication of RFC 7435 (https://tools.ietf.org/html/rfc7435), the IETF has = endorsed this approach as Opportunistic Security (OS), so it would be = nice to bring standards in line with industry = practice.

 <= /o:p>

Comments on = the draft, "An Opportunistic Approach for Secure Real-time = Transport Protocol (OSRTP)" and the best way forward are most = welcome!

 <= /o:p>

- Alan = -

 <= /o:p>

---------- = Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Mon, Jul 6, = 2015 at 1:48 PM
Subject: I-D Action: = draft-johnston-dispatch-osrtp-00.txt
To: i-d-announce@ietf.org



A New = Internet-Draft is available from the on-line Internet-Drafts = directories.


        Title    =        : An Opportunistic Approach for Secure = Real-time Transport Protocol (OSRTP)
        = Authors         : Alan Johnston
  =                     =     Bernard Aboba
            =               Andy Hutton
  =                     =     Laura Liess
            =               Thomas Stach
  =       Filename        : = draft-johnston-dispatch-osrtp-00.txt
        = Pages           : 8
    =     Date            : = 2015-07-06

Abstract:
   Opportunistic Secure = Real-time Transport Protocol (OSRTP) allows
   encrypted = media to be used in environments where support for
  =  encryption is not known in advance, and not required.  OSRTP = is an
   implementation of Opportunistic Security, as = defined in RFC 7435.
   OSRTP does not require advanced SDP = extensions or features and is
   fully backwards compatible = with existing secure and insecure
   implementations.  = OSRTP is not specific to any key management
   technique = for SRTP.


The IETF datatracker status page for this draft = is:
https://datatracker.ietf.org/doc/draft-johnston-dispatc= h-osrtp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-johnston-dispatch-osr= tp-00


Please note that it may take a couple of minutes = from the time of 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
I= nternet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

 <= /o:p>


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

 

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

= ------=_NextPart_000_00FA_01D1175B.D25873D0-- From nobody Wed Nov 4 21:48:36 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FCAB1B3962 for ; Wed, 4 Nov 2015 21:04:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.2 X-Spam-Level: **** X-Spam-Status: No, score=4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, CHARSET_FARAWAY_HEADER=3.2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jk_Y6VcCbxIC for ; Wed, 4 Nov 2015 21:04:50 -0800 (PST) Received: from forward18m.cmail.yandex.net (forward18m.cmail.yandex.net [IPv6:2a02:6b8:b030::9f]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B05861B395E for ; Wed, 4 Nov 2015 21:04:47 -0800 (PST) Received: from web10m.yandex.ru (web10m.yandex.ru [37.140.138.101]) by forward18m.cmail.yandex.net (Yandex) with ESMTP id 85E78213B3; Thu, 5 Nov 2015 08:04:44 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web10m.yandex.ru (Yandex) with ESMTP id CBBE124A19B7; Thu, 5 Nov 2015 08:04:43 +0300 (MSK) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1446699884; bh=cq0uzmCu4R3USLmf0D6zgqtYcI/bS056Pem5u3X+PCg=; h=From:To:Cc:Subject:Date; b=ad4lQCcPLf175betc8JykqFNNNzWxqgmeXEFsnuQJ7GyNgai8V9m0btCjlxiTVdrf hasPtKTMAK+I2CbdSNZklUY2gx0nMesPtsCL0JCi29NCgVBTp1XK3XF3XwzCskDqWj UI/tg6L1aqJIXJDE+psrHIE4D+bHiK9ud2cvZFws= Received: by web10m.yandex.ru with HTTP; Thu, 05 Nov 2015 08:04:43 +0300 From: =?koi8-r?B?9NfF0sXUyc4g4c7Uz84g88XSx8XF18ne?= To: Cullen Jennings MIME-Version: 1.0 Message-Id: <1251491446699883@web10m.yandex.ru> X-Mailer: Yamail [ http://yandex.ru ] 5.0 Date: Thu, 05 Nov 2015 10:04:43 +0500 Content-Transfer-Encoding: 7bit Content-Type: text/plain Archived-At: X-Mailman-Approved-At: Wed, 04 Nov 2015 21:48:35 -0800 Cc: DISPATCH list Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 05:04:53 -0000 Dear Cullen, Could you please cite the reasons for that drafts (draft-mahy-sip-remote-cc, draft-mahy-mmusic-mbus-remotecc)? I have checked several drafts, all of them were either withdrawn or abandoned by authors. I have not found any drafts rejected by the IETF. Regards, Anton. From nobody Wed Nov 4 22:01:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8A8F1B2F6E for ; Wed, 4 Nov 2015 22:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sexjoyBsBCP0 for ; Wed, 4 Nov 2015 22:00:55 -0800 (PST) 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 F0FE21B2F6B for ; Wed, 4 Nov 2015 22:00:54 -0800 (PST) Received: from dhcp-24-116.meeting.ietf94.jp (t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA560qne047791 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 5 Nov 2015 00:00:54 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8] claimed to be dhcp-24-116.meeting.ietf94.jp To: DISPATCH list From: "A. Jean Mahoney" Message-ID: <563AF093.5070903@nostrum.com> Date: Thu, 5 Nov 2015 15:00:51 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] dispatch 94 meeting notes - summary X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:01:02 -0000 Hi all, Below are summary notes from the meeting in Yokohama. Thanks, Jean DISPATCH WG - IETF 94 - November 2015 Wednesday, July 22, 2015 Location: Room 502 Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy Note takers: Jean Mahoney and Richard Barnes Jabber Scribe: Jonathan Lennox Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html --------------------------------------------------------- 13:00-13:10 Agenda and Status Presenter: Mary Barnes Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf Mary announced that DISPATCH now has three chairs. Murray Kucherawy has joined from the former Apps area. The agenda was updated with the removal of the HTTP problem statement presentation. Mark Nottingham announced that he was updating RFC 5988, Web Linking (draft-nottingham-rfc5988bis), and would bring it to the list when it was ready. ACTION: Mark Nottingham to bring RFC5988bis to the list when ready. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/t7M03TQsr8qScwkxxkY9sTirwnc Mary reminded the room that Dispatch has earlier deadlines for IETF meetings. However work can be dispatched on list, and doesn't have to wait for a meeting. --------------------------------------------------------- 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG) https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk Presenter: Mary Barnes Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf Robert Sparks pointed out that red text in otherwise black text was not an effective highlighting mechanism for people with colorblindness. Barry Leiba emphasized that DISPATCH would not do any standards work. The only work would be simple administrative tasks like creating drafts for IANA registration. Alissa Cooper thought the wording "The privacy of the network" was strange and will send text. ACTION: Alissa Cooper to send feedback on the Charter to the list. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/ldp8MwSy6NOoEafVOs3YbXautO0 Murray said that people liked the Monday appsawg meeting when WGs gave status, and that there will be an ART area general meeting to summarize wg status in Buenos Aires. Ben Campbell clarified that the summaries will cover new work and highlights, not everything worked on since the last meeting. No one else had comments on the charter. --------------------------------------------------------- 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport Protocol Presenter: Alan Johnston Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ charter proposal: https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf Martin Thomson had a correction for slide 8: Approach Continued, saying that we rely on authenticated signaling channel for DTLS-SRTP. Jonathan Lennox said that the point of opportunistic security was that, although it might allow MITM, it was better than nothing. Magnus Westerlund wasn't sure if MIKEY would work. ACTION: Verify which, if any, MIKEY modes work. Jon said that the weakest security option could be picked and it could be problematic. Alan said the draft could use feedback on the security options and it listed alternatives, not preferences. Jon wanted to ensure all options listed were appropriate. Jonathan requested that the motivational text include why no one uses Cap-Neg, which had the same goal as this draft, and asked if this document would obsolete Cap-Neg. Cullen, as chair, said that the draft would be dispatched, and although a charter was included in the presentation, a working group was not going to be created. Alan asked for solid reviews. Roni Even said that RFC 5763 would need to be updated. Christer Holmberg supported this work, saying that it goes hand-in-hand with DTLS-SDP. Richard Barnes was uncomfortable with including SDES in the options and would prefer it removed. He did not believe the draft should be a BCP since anything in the middle could downgrade the security. He also felt that, due to differences between AVP and SAVP, complexity would be introduced. Alan pointed out that most secure devices use SDES and that restricting SDES would leave them out. Jonathan Lennox pointed out a limitation with early media. ACTION: Alan to document the early media limitation. A participant from Deutsche Telekom supported this work, and spoke against Cap-Neg. Jonathan and Christer said that the work should be done in MMUSIC. Cullen didn't want the room to focus on where the work should be done, but on whether the work should be done. Charles Eckel supported this work, and said that he had an implementation. Mary, as chair, took a hum: Should we do the work in the ART area? many hums and hums in the Jabber room. Should we not work on this problem? one hum RESULTS of hum: strong consensus for the ART area doing the work. Richard reiterated that the middle could force security down and said allowing calls to go through can create barriers to implementing security since it doesn't motivate people to fix the security issue. Richard recommended creating minimum security requirements. Jon wanted the ability to vote security options "off the island", but understood Alan's response to SDES. Jon said that the negotiation mechanism could be separate from a security BCP. Richard did not want the draft to be considered a BCP, and wanted caveats that it was a transition technology. Charles said that causing calls to fail will cause security not to be turned on. When both sides can support it, it can be turned on without disrupting calls. Alan Ford supported this work. Jonathan mentioned an extension [ajm: that I missed], but Alan said that it didn't solve the problem. Richard pointed out that web browsers show open or closed lock icons to indicate the security state; phones don't have those icons. Cullen and Mary said some do. Richard wanted it to be clear that the user may not receive indication of the security state. --------------------------------------------------------- 13:55-14:10 HTTP problem statement Presenter: Mark Nottingham Document: https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt Not covered --------------------------------------------------------- 14:10-14:25 The font Primary Content type Presenter: Mark Nottingham on behalf of W3C Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf Mark said that there was support in apps-discuss, but no one wrote the draft, but W3C wants it to happen now and they wrote the draft. John Levine, Sean Leonard, Tony Hansen asked if there was a community that wanted it and would implement it. Wendy Seltzer said there was an active web fonts group in W3C that want to use this and was working on drafts. Martin said that fonts were approaching Turing complete and suspicion was warranted. Richard said that browsers determine if content is safe based on media type, and that it may not be safe to put fonts in a primary content type. Barry said that fonts fit the model of a top level type. Barry supported the work and it would go to a new working group. The work had to be standards track. Murray and Cullen, as chairs, said that the next step is for people interested in the work to create a charter. Then the chairs would look at the charter. Mark was happy with the plan. ACTION: People interested in font Primary Content type to create a charter for the work. --------------------------------------------------------- draft-west-webappsec-csp-reg Mark asked if draft-west-webappsec-csp-reg, which is requesting a registry for CSP directives, could be AD sponsored. Murray, as chair, felt that the draft fell under house-keeping and could be done in DISPATCH. Barry, as AD, said that he would let the chairs decide, and would AD-sponsor if they decided not to handle it in DISPATCH. Alissa, as AD, saw no reason to do the work in the independent stream. Richard was fine with doing the work in DISPATCH. ACTION: WG to review draft-west-webappsec-csp-reg and send comments to the list. ACTION: Mark to send a pointer to the list. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0 --------------------------------------------------------- 14:25-14:40 Ultra Low Latency for realtime applications Presenter: Koen De Schepper Proposal (including related drafts): https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf Mary, as chair, pointed out that the presentation was informational, and a decision was not needed. Richard asked if the application needed to do anything. Koen said only TCP stacks needed to be updated to support scalable TCP. Ben thought it was interesting, but that the room could not determine cost or implications. He felt it was a TSV topic. Koen agreed. Bob Briscoe clarified that scalable TCP can only be used in a data center, since it's too aggressive, and pushes other traffic out of the way. The queuing system would enable use outside of the data center. ACTION: Bob Briscoe to send pointers to the list. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc --------------------------------------------------------- Wrap-up Cullen announced that draft-west-webappsec-csp-reg, which was just dispatched, was already in LC. Richard said that the work was dispatched with dispatch. From nobody Wed Nov 4 22:02:03 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A3A61B3A19 for ; Wed, 4 Nov 2015 22:02:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H4ChElyB9JOH for ; Wed, 4 Nov 2015 22:01:59 -0800 (PST) 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 3E82B1B2F6E for ; Wed, 4 Nov 2015 22:01:59 -0800 (PST) Received: from dhcp-24-116.meeting.ietf94.jp (t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA561vKM047852 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for ; Thu, 5 Nov 2015 00:01:58 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t20010c4000003024403981f85519aab8.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:4039:81f8:5519:aab8] claimed to be dhcp-24-116.meeting.ietf94.jp To: DISPATCH list From: "A. Jean Mahoney" Message-ID: <563AF0D4.40308@nostrum.com> Date: Thu, 5 Nov 2015 15:01:56 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [dispatch] dispatch 94 meeting notes - raw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:02:02 -0000 Hi all, Below are my raw notes. Comments I missed are marked with ellipses (...) Thanks, Jean DISPATCH WG - IETF 94 - November 2015 Wednesday, July 22, 2015 Location: Room 502 Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy Note takers: Jean Mahoney and Richard Barnes Jabber Scribe: Jonathan Lennox Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html --------------------------------------------------------- 13:00-13:10 Agenda and Status Presenter: Mary Barnes Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf slide 1: Title Mary - We now have three Chairs. Murray has joined since we've added Apps. slide 2: Note well slide 3: Agenda Mary - the agenda has been updated. HTTP problem statement will not be presented. slide 4: Other topics Cullen - Mark Nottingham to talk about a W3C/IETF joint doc. Mark Nottingham - I'm updating RFC 5988, Web Linking (draft-nottingham-rfc5988bis), I will bring to dispatch when ready. slide 5: Deadlines Mary - Note that Dispatch has earlier deadlines for meetings. However we can dispatch on the list, and don't have to wait for a meeting. --------------------------------------------------------- 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG) https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk Presenter: Mary Barnes Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf slide 6: Updated DISPATCH WG Charter Mary - New items highlighted in red. Robert Sparks - don't use red to highlight text. Mary - why? Cullen - doesn't work with colorblindness. Barry Leiba - To be clear, we will not do any standards work here, just simple admin stuff like putting out docs to get IANA registration. No standards work. Alissa Cooper - on the guiding principles, "The privacy of the network"? That's kinda weird. I may suggest an editorial change. Murray - Appsawg isn't meeting this time. There are 3 docs left and then we close down the wg. Feedback received on appsawg - people liked the monday meeting. We'll reinstate that in Buenos Aires - there will be an ART area general meeting to summarize wg status. Ben Campbell - the summaries will over new work and highlights, not summarizing everything worked on since the last meeting. Mary - any other comments on the charter? No other comments on charter. --------------------------------------------------------- 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport Protocol Presenter: Alan Johnston Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ charter proposal: https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf slide 1: Title slide 2: Opportunistic Security (OS) slide 3: History of this Topic slide 4: Acknowledgement slide 5: Why now? slide 6: Why not just publish draft-kaplan-mmusic-best-effort-srtp? slide 7: Approach slide 8: Approach Continued Martin Thomson - a correction: we rely on authenticated signaling channel for DTLS-SRTP. Jonathan Lennox - the point of opportunistic security, it might allow MITM but better than nothing. Jon - they could still sign if they resurrected ... Magnus Westerlund - I don't know if MIKEY works. It's listed in the draft. Alan Johnston - some MIKEY modes may work, maybe not all. Magnus - that needs to be checked. Jon - something can get to pick the weakest security, this is problematic. Alan - could use feedback on that option. The draft just lists alternatives, not preferences. Jon - need to make sure that all 4 options are appropriate, then. Or vote them off the island. Alan - or let the implementors pick. slide 9: Example: Success slide 10: Example: Failure Jonathan - everyone hates cap-neg. You could solve this problem with cap-neg, but no one does. This was the original motivation for cap-neg. Provide some history on it, add to motivation text. Cullen as chair - We will dispatch the draft, not create a wg. The key question is, do we want to proceed with something of this shape? Can we not discuss the details of the charter, just talk about whether we work on this? Then can discuss details. Skip to slide 15. slide 11: Charter Text 1/4 slide 12: Charter Text 2/4 slide 13: Charter Text 3/4 slide 14: Charter Text 4/4 slide 15: Needed Next Steps Alan - the draft needs solid reviews. Roni Even - We'll need to update 5763 - best effort with cap-neg. Christer Holmberg - I support this. We'll need to connect it to DTLS-SDP, they go hand in hand. Richard Barnes - I tried to get some security guys here. We missed the opportunity to call security recommendations downgradable security. Anyone in the middle can force things to the weakest security, which should not be best practice. In the security considerations, we should capture that you should be ok with weakest option. It makes me uncomfortable to include SDES in here. I would feel better if it removed. I'm concerned - there's a diff between AVP and SAVP - we may adopt complexity. Alan - Most secure devices out there use SDES. Restricting SDES would leave them out. Jonathan Lennox - second best current practice. early media - can't distinguish between SDP .... With DTLS - you can tell. Alan - We need to document the early media limitation. Jonathan Lennox - probably best wg for this is mmusic. ... ??? from DT - we support this work. We have some use cases where it's more important to get the call through than to secure it. cap-neg is additional work. We don't want cap-neg. It's easier to support this. Christer - The work should be done in mmusic. It's offer/answer for opportunistic security. Cullen as chair - Don't focus on where it gets done. Should we do it? Jonathan Lennox - Can this draft obsolete cap-neg? Cullen - cap-neg can be obsoleted all by itself. It doesn't need another draft to obsolete it. Charles Eckel - I would like to see this work happen. It has worked well for us. We didn't want to bring it to the IETF. Mary as chair - Let's take a hum: Should we do the work in the ART area? many hums Should we not work on this problem? one hum Cullen - strong consensus for: we should be doing this work. RESULTS of hum: strong consensus for the ART area doing the work. Richard - In the middle they can force things down. It creates barriers to implementing security. In the community that wants to move to a secure state, create minimum security requirements. We don't treat HTTPS as mixed content - we want people to fix them. If the call completes even if security doesn't' happen, no motivation to fix. Jon - If we can vote somethings off the island. I understand your response to SDES. That will be the tough discussion. We can create a negotiation mechanism that is different from a BCP. Richard - This should not be considered a BCP. This should be heavily caveated as a transition tech. Charles - Securing the media won't be turned on because calls will fail because the security fails. You can turn it on and it will work sometimes, in the future you can turn it on. Both sides support it, and turn it on and it never comes into play. Alan Ford - I support this work Jonathan Lennox - seems like an easy extension. ... Alan - that's different and doesn't solve our problem. Richard - we've had opportunistic security proposals for web. Browsers show lock icons. Do you get the lock icon if it's secured? Phones don't have such icons. Cullen / Mary - some do. Alan - you give no indications to the user. Richard - maybe we can be clear about that. Jonathan Lennox - there were hums for doing the work in the jabber room slide 16: Path Forward --------------------------------------------------------- 13:55-14:10 HTTP problem statement Presenter: Mark Nottingham Document: https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt Not covered --------------------------------------------------------- 14:10-14:25 The font Primary Content type Presenter: Mark Nottingham on behalf of W3C Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf slide 1: Title Font media type - top level slide 2: Formats for fonts slide 3: Martin - on the first point, fonts are approaching turing complete. Suspicion is warranted. slide 4: Mark - There was support in apps-discuss, but no one wrote the draft. W3C wants it to happen and they wrote the draft. John Levine - media types need someone to implement them. What's their plan? Mark - W3C community seems keen. They want a unique place for font formats. Levine - If no one has an implementation plan, it won't be used. Here's an example. application/gzip didn't exist until a few months ago when someone needed. If there are people ready to implement it - that 's great. Mark - i's my impression but don't know. Sean Leonard - I've had to implement a top level media type. This is the 3rd attempt for font media type. I question the interest to get it all the way to though to publishing. The barrier to register top level media type is too high. Need to think about it before issuing the registration. For example text/plain. Have a short draft about it first. Richard - about who wants this, mixed content specs, active and passive content is based on top level media type. Browsers determine if its safe based on media type. This may not be a safe thing to put in there. Look forward to the media session. Wendy Seltzer - there's an active web fonts wg. They would like to use this. They have been working on drafts. Tony Hansen - It does need the relevant community to actually finish the work. If they don't, then it doesn't happen, plain and simple. Barry - the model for when you want a top level type. There's something common with some subtype. Fonts fit in that model. The fact is that people are looking at this, then let's do this. Mark - so the W3C needs to participate. Sean Leander - where does this work fit? Barry - AD sponsored or WG. Since nothing fits, it would go to a new working group. Has to be standards track. Murray - next step is to work on the charter. Cullen - forming a working group shouldn't be hard or complicated. Need people interested in the work and working on the charter. Then the chairs will look at the charter. Then get the draft going forward. Happy? You don't look happy. Mark - I'm happy. Cullen - For the minutes: Mark's happy. ACTION: People interested in font Primary Content type to create a charter for the work. Mark - there's another draft by Mike West (draft-west-webappsec-csp-reg) requesting a registry for CSP directives. Very simple and straightforward. W3C doesn't have a registry capability. Can that be AD sponsored? Murray - I think that falls under house keeping and can be done in DISPATCH. Barry - I'll let the chairs decide and I'll AD sponsor if not. Alissa - I just opened the draft, I see no reason to do this in independent stream. Cullen - read and send comments to the list. Richard - seems fine to me. Mary - Mark, send mail to the list point to the draft. ACTION: Mark to send a pointer to the list. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0 ACTION: WG to review and send comments to the list. --------------------------------------------------------- 14:25-14:40 Ultra Low Latency for realtime applications Presenter: Koen De Schepper Proposal (including related drafts): https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 Presentation: https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf slide 1: Title slide 2: Super Fast Internet? slide 3: Super Fast User Experience slide 4: Better TCP Exists, but is not compatible with the current Internet slide 5: Comparison of Classic TCP and Scalable TCP Cloud Hosted Interactive Panoramic Video slide 6: Comparison of Classic TCP and Scalable TCP Cloud Hosted Interactive Panoramic Video slide 7: Comparison of Classic TCP and Scalable TCP Cloud Hosted Interactive Panoramic Video slide 8: Why Dispatch? slide 9: Simple Solution in the network: DualQ AQM provides low latency marking and Compatibility slide 10: Demo on a Real BB Residential Testbed slide 11: Demo on a Real BB Residential Testbed slide 12: Improved Web browsing Experience slide 13: HTTP Adaptive Streaming (HAS) Experiments slide 14: HTTP Adaptive Streaming (HAS) Experiments slide 15: Using Just a Scalable TCP connection for Realtime and interactive services? slide 16: Questions Mary - this is just a informational thing, not a decision. Richard - what does this look like from an app point of view? Koen - TCP stacks are upgraded to support this. The Windows data center server does this. Only a change in the operating system, apps don't have to set anything. It's easy. Ben - it's interesting. This room can't just the cost or implications, though. This is a TSV thing. Koen - it's a transport area decision. Agree. Andrew Allen - Does it require support at both ends? Koen - Yes Andrew - You were talking about other improvements that can't be used? Are there other solutions? Koen - I was talking about this - scalable TCP, but it can't be used yet. Bob Briscoe - you missed this point - this can only be used in a data center, they are too aggressive, they push other traffic out of the way. With the queueing system, you would be able to use it. Cullen - send the pointers to the list so people can learn more. ACTION: Bob Briscoe to send pointers to the list. DONE: https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc --------------------------------------------------------- Wrap-up Cullen - draft-west-webappsec-csp-reg, which was just dispatched, is already in LC. Murray - wrote the draft, put in LC, dispatched in less than 2 weeks. Richard - dispatched with dispatch From nobody Wed Nov 4 22:06:32 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 937D11ACD56 for ; Wed, 4 Nov 2015 22:06:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c4Al9mpOdQY8 for ; Wed, 4 Nov 2015 22:06:30 -0800 (PST) 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 CC2D31ACD4E for ; Wed, 4 Nov 2015 22:06:29 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-04-563af1e331bb Received: from ESESSHC015.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 87.E5.05274.3E1FA365; Thu, 5 Nov 2015 07:06:28 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.202]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.03.0248.002; Thu, 5 Nov 2015 07:06:27 +0100 From: Christer Holmberg To: =?koi8-r?B?9NfF0sXUyc4g4c7Uz84g88XSx8XF18ne?= , Cullen Jennings Thread-Topic: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt Thread-Index: AQHRF42ezYhlWoWvtUWAGLPPAHGzcp6M8MoA Date: Thu, 5 Nov 2015 06:06:27 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37BDA852@ESESSMB209.ericsson.se> References: <1251491446699883@web10m.yandex.ru> In-Reply-To: <1251491446699883@web10m.yandex.ru> 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: text/plain; charset="koi8-r" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprIIsWRmVeSWpSXmKPExsUyM+Jvre6Tj1ZhBpMuMlssnbSA1eLD+h+M Fh+Pv2B3YPZYsuQnk8fl8x8ZPQ439LMEMEdx2aSk5mSWpRbp2yVwZWxdeoKpYDNHxYq3axkb GBvZuxg5OSQETCQ6/q+HssUkLtxbz9bFyMUhJHCEUeLVk2Y2kISQwGJGieM9Ll2MHBxsAhYS 3f+0QcIiAtkSp3e1M4LYzAKqEudPdTKD2MICSRJnJrUwQdQkS+x6tZgRwjaSWL36ApjNIqAi sXvWSbAaXgFficmfnrBDrNKXaPv7mgXE5hQwkHi7Zx9YPSPQbd9PrWGC2CUucevJfCaImwUk luw5zwxhi0q8fPyPFcJWklix/RLUbVoS+7p+MEPY2hLLFr5mhtgrKHFy5hOWCYxis5CMnYWk ZRaSlllIWhYwsqxiFC1OLU7KTTcy1kstykwuLs7P08tLLdnECIyog1t+q+5gvPzG8RCjAAej Eg/vh16rMCHWxLLiytxDjBIczEoivAUzgUK8KYmVValF+fFFpTmpxYcYpTlYlMR5m5kehAoJ pCeWpGanphakFsFkmTg4pRoY6ze2/r+c1c9SsXPOR/OFsY5XVm7c84jLv3POha1CuwSbpvUI tM87+lHsrremYttVjd4Fli1NntsfyTAUKXLXyF3yn/bZynvCxuBV/pUtdbO8X/w8vETx/fnZ Zz46Nz94tq54Tz93TJb2O7fi/7saIn13Pd7k/2n1XtU0LybVg1Z9da3rbt01UGIpzkg01GIu Kk4EALYZizSkAgAA Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-dispatch-remote-01.txt X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 06:06:31 -0000 Hi, I don't think IETF normally "rejects" drafts. IETF may decide not to WG ado= pt a draft, but the draft will still remain in the archives. So, if you want to know the reasons why a draft didn't move forward, you ne= ed to look for the associated e-mail/meeting discussions. Regards, Christer -----Original Message----- From: dispatch [mailto:dispatch-bounces@ietf.org] On Behalf Of ???????? ???= ?? ????????? Sent: 05 November 2015 07:05 To: Cullen Jennings Cc: DISPATCH list Subject: Re: [dispatch] (Fwd) New Version Notification for draft-tveretin-d= ispatch-remote-01.txt Dear Cullen, Could you please cite the reasons for that drafts (draft-mahy-sip-remote-cc= , draft-mahy-mmusic-mbus-remotecc)? I have checked several drafts, all of them were either withdrawn or abandon= ed by authors. I have not found any drafts rejected by the IETF. Regards, Anton. _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Thu Nov 5 00:59:43 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CF851A8AB3 for ; Thu, 5 Nov 2015 00:59:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbnFS6hgQ58Y for ; Thu, 5 Nov 2015 00:59:37 -0800 (PST) Received: from mail-yk0-x22b.google.com (mail-yk0-x22b.google.com [IPv6:2607:f8b0:4002:c07::22b]) (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 088C31A8A97 for ; Thu, 5 Nov 2015 00:59:37 -0800 (PST) Received: by ykdr3 with SMTP id r3so119519465ykd.1 for ; Thu, 05 Nov 2015 00:59:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=nhfWqdTqdima4vykQKKoAJyi3zYzbNt1nU2o1LNq9cA=; b=Bnj//DNzdnVBtyOrUVMOADWKGl0XfJgawnLCQBaKxRreMihdzJDdjp5OkvQUnrIPQ7 B/XYymlAR9tmWU6KjXvycg4z9ieKck5/OBhM0jyDx0/VdL3yrSGq88enfPxhmyPacWTy 4eh1fjokRGi2f129EORcHlzZTr58aaqXD3QDPGw8i9cNeqVB1bItRwjiQIx4UEEXvJKb XUQLP0uH0JQQfQ2y+kwHZ1SQw6Ck95s4Ojo220p358NIrK04yX8sGkpPxZRyfnvSCEj1 fvJh42HwG4CC1mkk2iRh5bQ5Eki/OmwvxBukH2fTFNKQH6BdTjyXR5UeQzNro271cqjE wSBA== MIME-Version: 1.0 X-Received: by 10.129.77.68 with SMTP id a65mr333726ywb.322.1446713976230; Thu, 05 Nov 2015 00:59:36 -0800 (PST) Received: by 10.37.29.86 with HTTP; Thu, 5 Nov 2015 00:59:36 -0800 (PST) In-Reply-To: <563AF093.5070903@nostrum.com> References: <563AF093.5070903@nostrum.com> Date: Thu, 5 Nov 2015 02:59:36 -0600 Message-ID: From: Mary Barnes To: "A. Jean Mahoney" Content-Type: multipart/alternative; boundary=001a1140b770a51e750523c758b0 Archived-At: Cc: DISPATCH list Subject: Re: [dispatch] dispatch 94 meeting notes - summary X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 08:59:41 -0000 --001a1140b770a51e750523c758b0 Content-Type: text/plain; charset=UTF-8 Thank you Jean - this is awesome! Mary. On Thu, Nov 5, 2015 at 12:00 AM, A. Jean Mahoney wrote: > Hi all, > > Below are summary notes from the meeting in Yokohama. > > Thanks, > > Jean > > > DISPATCH WG - IETF 94 - November 2015 > > Wednesday, July 22, 2015 > Location: Room 502 > > Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy > > Note takers: Jean Mahoney and Richard Barnes > Jabber Scribe: Jonathan Lennox > Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html > > --------------------------------------------------------- > 13:00-13:10 Agenda and Status > Presenter: Mary Barnes > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf > > > Mary announced that DISPATCH now has three chairs. Murray Kucherawy has > joined from the former Apps area. > > The agenda was updated with the removal of the HTTP problem statement > presentation. > > Mark Nottingham announced that he was updating RFC 5988, Web Linking > (draft-nottingham-rfc5988bis), and would bring it to the list when it was > ready. > > ACTION: Mark Nottingham to bring RFC5988bis to the list when ready. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/t7M03TQsr8qScwkxxkY9sTirwnc > > Mary reminded the room that Dispatch has earlier deadlines for IETF > meetings. However work can be dispatched on list, and doesn't have to wait > for a meeting. > > > > --------------------------------------------------------- > 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG) > https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk > Presenter: Mary Barnes > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf > > > Robert Sparks pointed out that red text in otherwise black text was not an > effective highlighting mechanism for people with colorblindness. > > Barry Leiba emphasized that DISPATCH would not do any standards work. The > only work would be simple administrative tasks like creating drafts for > IANA registration. > > Alissa Cooper thought the wording "The privacy of the network" was strange > and will send text. > > ACTION: Alissa Cooper to send feedback on the Charter to the list. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/ldp8MwSy6NOoEafVOs3YbXautO0 > > Murray said that people liked the Monday appsawg meeting when WGs gave > status, and that there will be an ART area general meeting to summarize wg > status in Buenos Aires. Ben Campbell clarified that the summaries will > cover new work and highlights, not everything worked on since the last > meeting. > > No one else had comments on the charter. > > > --------------------------------------------------------- > 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport > Protocol > Presenter: Alan Johnston > Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ > charter proposal: > https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf > > > Martin Thomson had a correction for slide 8: Approach Continued, saying > that we rely on authenticated signaling channel for DTLS-SRTP. > > Jonathan Lennox said that the point of opportunistic security was that, > although it might allow MITM, it was better than nothing. > > Magnus Westerlund wasn't sure if MIKEY would work. > > ACTION: Verify which, if any, MIKEY modes work. > > Jon said that the weakest security option could be picked and it could be > problematic. Alan said the draft could use feedback on the security options > and it listed alternatives, not preferences. Jon wanted to ensure all > options listed were appropriate. > > Jonathan requested that the motivational text include why no one uses > Cap-Neg, which had the same goal as this draft, and asked if this document > would obsolete Cap-Neg. > > Cullen, as chair, said that the draft would be dispatched, and although a > charter was included in the presentation, a working group was not going to > be created. > > Alan asked for solid reviews. > > Roni Even said that RFC 5763 would need to be updated. > > Christer Holmberg supported this work, saying that it goes hand-in-hand > with DTLS-SDP. > > Richard Barnes was uncomfortable with including SDES in the options and > would prefer it removed. He did not believe the draft should be a BCP since > anything in the middle could downgrade the security. He also felt that, due > to differences between AVP and SAVP, complexity would be introduced. > > Alan pointed out that most secure devices use SDES and that restricting > SDES would leave them out. > > Jonathan Lennox pointed out a limitation with early media. > > ACTION: Alan to document the early media limitation. > > A participant from Deutsche Telekom supported this work, and spoke against > Cap-Neg. > > Jonathan and Christer said that the work should be done in MMUSIC. Cullen > didn't want the room to focus on where the work should be done, but on > whether the work should be done. > > Charles Eckel supported this work, and said that he had an implementation. > > Mary, as chair, took a hum: > > Should we do the work in the ART area? many hums and hums in the Jabber > room. > > Should we not work on this problem? one hum > > RESULTS of hum: strong consensus for the ART area doing the work. > > Richard reiterated that the middle could force security down and said > allowing calls to go through can create barriers to implementing security > since it doesn't motivate people to fix the security issue. Richard > recommended creating minimum security requirements. > > Jon wanted the ability to vote security options "off the island", but > understood Alan's response to SDES. Jon said that the negotiation mechanism > could be separate from a security BCP. > > Richard did not want the draft to be considered a BCP, and wanted caveats > that it was a transition technology. > > Charles said that causing calls to fail will cause security not to be > turned on. When both sides can support it, it can be turned on without > disrupting calls. > > Alan Ford supported this work. > > Jonathan mentioned an extension [ajm: that I missed], but Alan said that > it didn't solve the problem. > > Richard pointed out that web browsers show open or closed lock icons to > indicate the security state; phones don't have those icons. Cullen and Mary > said some do. Richard wanted it to be clear that the user may not receive > indication of the security state. > > > --------------------------------------------------------- > 13:55-14:10 HTTP problem statement > Presenter: Mark Nottingham > Document: > https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt > > > Not covered > > > --------------------------------------------------------- > 14:10-14:25 The font Primary Content type > Presenter: Mark Nottingham on behalf of W3C > Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf > > > Mark said that there was support in apps-discuss, but no one wrote the > draft, but W3C wants it to happen now and they wrote the draft. > > John Levine, Sean Leonard, Tony Hansen asked if there was a community that > wanted it and would implement it. Wendy Seltzer said there was an active > web fonts group in W3C that want to use this and was working on drafts. > > Martin said that fonts were approaching Turing complete and suspicion was > warranted. Richard said that browsers determine if content is safe based on > media type, and that it may not be safe to put fonts in a primary content > type. > > Barry said that fonts fit the model of a top level type. Barry supported > the work and it would go to a new working group. The work had to be > standards track. > > Murray and Cullen, as chairs, said that the next step is for people > interested in the work to create a charter. Then the chairs would look at > the charter. Mark was happy with the plan. > > ACTION: People interested in font Primary Content type to create a charter > for the work. > > > --------------------------------------------------------- > draft-west-webappsec-csp-reg > > Mark asked if draft-west-webappsec-csp-reg, which is requesting a registry > for CSP directives, could be AD sponsored. > > Murray, as chair, felt that the draft fell under house-keeping and could > be done in DISPATCH. Barry, as AD, said that he would let the chairs > decide, and would AD-sponsor if they decided not to handle it in DISPATCH. > Alissa, as AD, saw no reason to do the work in the independent stream. > Richard was fine with doing the work in DISPATCH. > > ACTION: WG to review draft-west-webappsec-csp-reg and send comments to the > list. > > ACTION: Mark to send a pointer to the list. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0 > > > --------------------------------------------------------- > 14:25-14:40 Ultra Low Latency for realtime applications > Presenter: Koen De Schepper > Proposal (including related drafts): > https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf > > > Mary, as chair, pointed out that the presentation was informational, and a > decision was not needed. > > Richard asked if the application needed to do anything. Koen said only TCP > stacks needed to be updated to support scalable TCP. > > Ben thought it was interesting, but that the room could not determine cost > or implications. He felt it was a TSV topic. Koen agreed. > > Bob Briscoe clarified that scalable TCP can only be used in a data center, > since it's too aggressive, and pushes other traffic out of the way. The > queuing system would enable use outside of the data center. > > ACTION: Bob Briscoe to send pointers to the list. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc > > > --------------------------------------------------------- > Wrap-up > > > Cullen announced that draft-west-webappsec-csp-reg, which was just > dispatched, was already in LC. > > Richard said that the work was dispatched with dispatch. > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > --001a1140b770a51e750523c758b0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Thank you Jean - this is awesome!

Mary.=

On Th= u, Nov 5, 2015 at 12:00 AM, A. Jean Mahoney <mahoney@nostrum.com&g= t; wrote:
Hi all,

Below are summary notes from the meeting in Yokohama.

Thanks,

Jean


DISPATCH WG - IETF 94 -=C2=A0 November 2015

Wednesday, July 22, 2015
Location: Room 502

Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy

Note takers: Jean Mahoney and Richard Barnes
Jabber Scribe: Jonathan Lennox
Jabber log: http://www.ietf.org/jabber/logs/= dispatch/2015-11-04.html

---------------------------------------------------------
13:00-13:10=C2=A0 Agenda and Status
Presenter: Mary Barnes
Presentation: https://www.ietf.or= g/proceedings/94/slides/slides-94-dispatch-1.pdf


Mary announced that DISPATCH now has three chairs. Murray Kucherawy has joi= ned from the former Apps area.

The agenda was updated with the removal of the HTTP problem statement prese= ntation.

Mark Nottingham announced that he was updating RFC 5988, Web Linking (draft= -nottingham-rfc5988bis), and would bring it to the list when it was ready.<= br>
ACTION: Mark Nottingham to bring RFC5988bis to the list when ready.
DONE: https://mailarchive.= ietf.org/arch/msg/dispatch/t7M03TQsr8qScwkxxkY9sTirwnc

Mary reminded the room that Dispatch has earlier deadlines for IETF meeting= s. However work can be dispatched on list, and doesn't have to wait for= a meeting.



---------------------------------------------------------
13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG)
https://mailarchive.ietf.o= rg/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk
Presenter: Mary Barnes
Presentation: https://www.ietf.or= g/proceedings/94/slides/slides-94-dispatch-1.pdf


Robert Sparks pointed out that red text in otherwise black text was not an = effective highlighting mechanism for people with colorblindness.

Barry Leiba emphasized that DISPATCH would not do any standards work. The o= nly work would be simple administrative tasks like creating drafts for IANA= registration.

Alissa Cooper thought the wording "The privacy of the network" wa= s strange and will send text.

ACTION: Alissa Cooper to send feedback on the Charter to the list.
DONE: https://mailarchive.= ietf.org/arch/msg/dispatch/ldp8MwSy6NOoEafVOs3YbXautO0

Murray said that people liked the Monday appsawg meeting when WGs gave stat= us, and that there will be an ART area general meeting to summarize wg stat= us in Buenos Aires. Ben Campbell clarified that the summaries will cover ne= w work and highlights, not everything worked on since the last meeting.

No one else had comments on the charter.


---------------------------------------------------------
13:25-13:55 An Opportunistic Approach for Secure Real-time Transport Protoc= ol
Presenter: Alan Johnston
Document: http://datatracker.ietf.org/= doc/draft-johnston-dispatch-osrtp/
charter proposal: https://= mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g
Presentation: https://www.ietf.or= g/proceedings/94/slides/slides-94-dispatch-0.pdf


Martin Thomson had a correction for slide 8: Approach Continued, saying tha= t we rely on authenticated signaling channel for DTLS-SRTP.

Jonathan Lennox said that the point of opportunistic security was that, alt= hough it might allow MITM, it was better than nothing.

Magnus Westerlund wasn't sure if MIKEY would work.

ACTION: Verify which, if any, MIKEY modes work.

Jon said that the weakest security option could be picked and it could be p= roblematic. Alan said the draft could use feedback on the security options = and it listed alternatives, not preferences. Jon wanted to ensure all optio= ns listed were appropriate.

Jonathan requested that the motivational text include why no one uses Cap-N= eg, which had the same goal as this draft, and asked if this document would= obsolete Cap-Neg.

Cullen, as chair, said that the draft would be dispatched, and although a c= harter was included in the presentation, a working group was not going to b= e created.

Alan asked for solid reviews.

Roni Even said that RFC 5763 would need to be updated.

Christer Holmberg supported this work, saying that it goes hand-in-hand wit= h DTLS-SDP.

Richard Barnes was uncomfortable with including SDES in the options and wou= ld prefer it removed. He did not believe the draft should be a BCP since an= ything in the middle could downgrade the security. He also felt that, due t= o differences between AVP and SAVP, complexity would be introduced.

Alan pointed out that most secure devices use SDES and that restricting SDE= S would leave them out.

Jonathan Lennox pointed out a limitation with early media.

ACTION: Alan to document the early media limitation.

A participant from Deutsche Telekom supported this work, and spoke against = Cap-Neg.

Jonathan and Christer said that the work should be done in MMUSIC. Cullen d= idn't want the room to focus on where the work should be done, but on w= hether the work should be done.

Charles Eckel supported this work, and said that he had an implementation.<= br>
Mary, as chair, took a hum:

Should we do the work in the ART area? many hums and hums in the Jabber roo= m.

Should we not work on this problem? one hum

RESULTS of hum: strong consensus for the ART area doing the work.

Richard reiterated that the middle could force security down and said allow= ing calls to go through can create barriers to implementing security since = it doesn't motivate people to fix the security issue. Richard recommend= ed creating minimum security requirements.

Jon wanted the ability to vote security options "off the island",= but understood Alan's response to SDES. Jon said that the negotiation = mechanism could be separate from a security BCP.

Richard did not want the draft to be considered a BCP, and wanted caveats t= hat it was a transition technology.

Charles said that causing calls to fail will cause security not to be turne= d on. When both sides can support it, it can be turned on without disruptin= g calls.

Alan Ford supported this work.

Jonathan mentioned an extension [ajm: that I missed], but Alan said that it= didn't solve the problem.

Richard pointed out that web browsers show open or closed lock icons to ind= icate the security state; phones don't have those icons. Cullen and Mar= y said some do. Richard wanted it to be clear that the user may not receive= indication of the security state.


---------------------------------------------------------
13:55-14:10 HTTP problem statement
Presenter: Mark Nottingham
Document: https://www.ietf.org/a= rchive/id/draft-nottingham-http-problem-07.txt


Not covered


---------------------------------------------------------
14:10-14:25 The font Primary Content type
Presenter: Mark Nottingham on behalf of W3C
Document: https://tools.ietf.org/html/draft= -lilley-font-toplevel-00
Presentation: https://www.ietf.or= g/proceedings/94/slides/slides-94-dispatch-3.pdf


Mark said that there was support in apps-discuss, but no one wrote the draf= t, but W3C wants it to happen now and they wrote the draft.

John Levine, Sean Leonard, Tony Hansen asked if there was a community that = wanted it and would implement it. Wendy Seltzer said there was an active we= b fonts group in W3C that want to use this and was working on drafts.

Martin said that fonts were approaching Turing complete and suspicion was w= arranted. Richard said that browsers determine if content is safe based on = media type, and that it may not be safe to put fonts in a primary content t= ype.

Barry said that fonts fit the model of a top level type. Barry supported th= e work and it would go to a new working group. The work had to be standards= track.

Murray and Cullen, as chairs, said that the next step is for people interes= ted in the work to create a charter. Then the chairs would look at the char= ter. Mark was happy with the plan.

ACTION: People interested in font Primary Content type to create a charter = for the work.


---------------------------------------------------------
draft-west-webappsec-csp-reg

Mark asked if draft-west-webappsec-csp-reg, which is requesting a registry = for CSP directives, could be AD sponsored.

Murray, as chair, felt that the draft fell under house-keeping and could be= done in DISPATCH. Barry, as AD, said that he would let the chairs decide, = and would AD-sponsor if they decided not to handle it in DISPATCH. Alissa, = as AD, saw no reason to do the work in the independent stream. Richard was = fine with doing the work in DISPATCH.

ACTION: WG to review draft-west-webappsec-csp-reg and send comments to the = list.

ACTION: Mark to send a pointer to the list.
DONE: https://mailarchive.= ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0


---------------------------------------------------------
14:25-14:40=C2=A0 Ultra Low Latency for realtime applications
Presenter: Koen De Schepper
Proposal (including related drafts):
https://mailarchive.ietf.o= rg/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8
Presentation: https://www.ietf.or= g/proceedings/94/slides/slides-94-dispatch-2.pdf


Mary, as chair, pointed out that the presentation was informational, and a = decision was not needed.

Richard asked if the application needed to do anything. Koen said only TCP = stacks needed to be updated to support scalable TCP.

Ben thought it was interesting, but that the room could not determine cost = or implications. He felt it was a TSV topic. Koen agreed.

Bob Briscoe clarified that scalable TCP can only be used in a data center, = since it's too aggressive, and pushes other traffic out of the way. The= queuing system would enable use outside of the data center.

ACTION: Bob Briscoe to send pointers to the list.
DONE: https://mailarchive.= ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc


---------------------------------------------------------
Wrap-up


Cullen announced that draft-west-webappsec-csp-reg, which was just dispatch= ed, was already in LC.

Richard said that the work was dispatched with dispatch.

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

--001a1140b770a51e750523c758b0-- From nobody Thu Nov 5 01:42:24 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE0EB1A9067 for ; Thu, 5 Nov 2015 01:42:17 -0800 (PST) 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hNiL-u2djSLm for ; Thu, 5 Nov 2015 01:42:11 -0800 (PST) Received: from server.dnsblock1.com (server.dnsblock1.com [85.13.236.178]) (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 5DEC11A9084 for ; Thu, 5 Nov 2015 01:42:10 -0800 (PST) Received: from dhcp-25-140.meeting.ietf94.jp ([133.93.25.140]:43672) by server.dnsblock1.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.86) (envelope-from ) id 1ZuH3X-0004nC-La; Thu, 05 Nov 2015 09:42:08 +0000 To: "A. Jean Mahoney" , DISPATCH list References: <563AF0D4.40308@nostrum.com> From: Bob Briscoe Message-ID: <563B246C.1000502@bobbriscoe.net> Date: Thu, 5 Nov 2015 09:42:04 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563AF0D4.40308@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server.dnsblock1.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - bobbriscoe.net X-Get-Message-Sender-Via: server.dnsblock1.com: authenticated_id: in@bobbriscoe.net X-Authenticated-Sender: server.dnsblock1.com: in@bobbriscoe.net Archived-At: Subject: Re: [dispatch] dispatch 94 meeting notes - raw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 09:42:18 -0000 Jean, See one correction inline... (just before wrap up)... On 05/11/15 06:01, A. Jean Mahoney wrote: > Hi all, > > Below are my raw notes. Comments I missed are marked with ellipses (...) > > Thanks, > > Jean > > > DISPATCH WG - IETF 94 - November 2015 > > Wednesday, July 22, 2015 > Location: Room 502 > > Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy > > Note takers: Jean Mahoney and Richard Barnes > Jabber Scribe: Jonathan Lennox > Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html > > --------------------------------------------------------- > 13:00-13:10 Agenda and Status > Presenter: Mary Barnes > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf > > slide 1: Title > > Mary - We now have three Chairs. Murray has joined since we've added > Apps. > > slide 2: Note well > > slide 3: Agenda > > Mary - the agenda has been updated. HTTP problem statement will not be > presented. > > slide 4: Other topics > > Cullen - Mark Nottingham to talk about a W3C/IETF joint doc. > > Mark Nottingham - I'm updating RFC 5988, Web Linking > (draft-nottingham-rfc5988bis), I will bring to dispatch when ready. > > slide 5: Deadlines > > Mary - Note that Dispatch has earlier deadlines for meetings. However > we can dispatch on the list, and don't have to wait for a meeting. > > > > --------------------------------------------------------- > 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG) > https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk > > Presenter: Mary Barnes > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf > > > slide 6: Updated DISPATCH WG Charter > > Mary - New items highlighted in red. > > Robert Sparks - don't use red to highlight text. > > Mary - why? > > Cullen - doesn't work with colorblindness. > > Barry Leiba - To be clear, we will not do any standards work here, > just simple admin stuff like putting out docs to get IANA > registration. No standards work. > > Alissa Cooper - on the guiding principles, "The privacy of the > network"? That's kinda weird. I may suggest an editorial change. > > Murray - Appsawg isn't meeting this time. There are 3 docs left and > then we close down the wg. Feedback received on appsawg - people liked > the monday meeting. We'll reinstate that in Buenos Aires - there will > be an ART area general meeting to summarize wg status. > > Ben Campbell - the summaries will over new work and highlights, not > summarizing everything worked on since the last meeting. > > Mary - any other comments on the charter? > > No other comments on charter. > > > > --------------------------------------------------------- > 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport > Protocol > Presenter: Alan Johnston > Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ > charter proposal: > https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf > > > slide 1: Title > > slide 2: Opportunistic Security (OS) > > slide 3: History of this Topic > > slide 4: Acknowledgement > > slide 5: Why now? > > slide 6: Why not just publish draft-kaplan-mmusic-best-effort-srtp? > > slide 7: Approach > > slide 8: Approach Continued > > Martin Thomson - a correction: we rely on authenticated signaling > channel for DTLS-SRTP. > > Jonathan Lennox - the point of opportunistic security, it might allow > MITM but better than nothing. > > Jon - they could still sign if they resurrected ... > > Magnus Westerlund - I don't know if MIKEY works. It's listed in the > draft. > > Alan Johnston - some MIKEY modes may work, maybe not all. > > Magnus - that needs to be checked. > > Jon - something can get to pick the weakest security, this is > problematic. > > Alan - could use feedback on that option. The draft just lists > alternatives, not preferences. > > Jon - need to make sure that all 4 options are appropriate, then. Or > vote them off the island. > > Alan - or let the implementors pick. > > slide 9: Example: Success > > slide 10: Example: Failure > > Jonathan - everyone hates cap-neg. You could solve this problem with > cap-neg, but no one does. This was the original motivation for > cap-neg. Provide some history on it, add to motivation text. > > Cullen as chair - We will dispatch the draft, not create a wg. The key > question is, do we want to proceed with something of this shape? Can > we not discuss the details of the charter, just talk about whether we > work on this? Then can discuss details. Skip to slide 15. > > slide 11: Charter Text 1/4 > > slide 12: Charter Text 2/4 > > slide 13: Charter Text 3/4 > > slide 14: Charter Text 4/4 > > slide 15: Needed Next Steps > > Alan - the draft needs solid reviews. > > Roni Even - We'll need to update 5763 - best effort with cap-neg. > > Christer Holmberg - I support this. We'll need to connect it to > DTLS-SDP, they go hand in hand. > > Richard Barnes - I tried to get some security guys here. We missed the > opportunity to call security recommendations downgradable security. > Anyone in the middle can force things to the weakest security, which > should not be best practice. In the security considerations, we should > capture that you should be ok with weakest option. It makes me > uncomfortable to include SDES in here. I would feel better if it > removed. I'm concerned - there's a diff between AVP and SAVP - we may > adopt complexity. > > Alan - Most secure devices out there use SDES. Restricting SDES would > leave them out. > > Jonathan Lennox - second best current practice. early media - can't > distinguish between SDP .... With DTLS - you can tell. > > Alan - We need to document the early media limitation. > > Jonathan Lennox - probably best wg for this is mmusic. ... > > ??? from DT - we support this work. We have some use cases where it's > more important to get the call through than to secure it. cap-neg is > additional work. We don't want cap-neg. It's easier to support this. > > Christer - The work should be done in mmusic. It's offer/answer for > opportunistic security. > > Cullen as chair - Don't focus on where it gets done. Should we do it? > > Jonathan Lennox - Can this draft obsolete cap-neg? > > Cullen - cap-neg can be obsoleted all by itself. It doesn't need > another draft to obsolete it. > > Charles Eckel - I would like to see this work happen. It has worked > well for us. We didn't want to bring it to the IETF. > > Mary as chair - Let's take a hum: > > Should we do the work in the ART area? many hums > > Should we not work on this problem? one hum > > Cullen - strong consensus for: we should be doing this work. > > RESULTS of hum: strong consensus for the ART area doing the work. > > > Richard - In the middle they can force things down. It creates > barriers to implementing security. In the community that wants to move > to a secure state, create minimum security requirements. We don't > treat HTTPS as mixed content - we want people to fix them. If the call > completes even if security doesn't' happen, no motivation to fix. > > Jon - If we can vote somethings off the island. I understand your > response to SDES. That will be the tough discussion. We can create a > negotiation mechanism that is different from a BCP. > > Richard - This should not be considered a BCP. This should be heavily > caveated as a transition tech. > > Charles - Securing the media won't be turned on because calls will > fail because the security fails. You can turn it on and it will work > sometimes, in the future you can turn it on. Both sides support it, > and turn it on and it never comes into play. > > Alan Ford - I support this work > > Jonathan Lennox - seems like an easy extension. ... > > Alan - that's different and doesn't solve our problem. > > Richard - we've had opportunistic security proposals for web. Browsers > show lock icons. Do you get the lock icon if it's secured? Phones > don't have such icons. > > Cullen / Mary - some do. > > Alan - you give no indications to the user. > > Richard - maybe we can be clear about that. > > Jonathan Lennox - there were hums for doing the work in the jabber room > > > slide 16: Path Forward > > > > --------------------------------------------------------- > 13:55-14:10 HTTP problem statement > Presenter: Mark Nottingham > Document: > https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt > > > Not covered > > > > > --------------------------------------------------------- > 14:10-14:25 The font Primary Content type > Presenter: Mark Nottingham on behalf of W3C > Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf > > slide 1: Title > > Font media type - top level > > slide 2: > > Formats for fonts > > > slide 3: > > Martin - on the first point, fonts are approaching turing complete. > Suspicion is warranted. > > slide 4: > > Mark - There was support in apps-discuss, but no one wrote the draft. > W3C wants it to happen and they wrote the draft. > > John Levine - media types need someone to implement them. What's their > plan? > > Mark - W3C community seems keen. They want a unique place for font > formats. > > Levine - If no one has an implementation plan, it won't be used. > Here's an example. application/gzip didn't exist until a few months > ago when someone needed. If there are people ready to implement it - > that 's great. > > Mark - i's my impression but don't know. > > Sean Leonard - I've had to implement a top level media type. This is > the 3rd attempt for font media type. I question the interest to get it > all the way to though to publishing. The barrier to register top level > media type is too high. Need to think about it before issuing the > registration. For example text/plain. Have a short draft about it first. > > Richard - about who wants this, mixed content specs, active and > passive content is based on top level media type. Browsers determine > if its safe based on media type. This may not be a safe thing to put > in there. > > Look forward to the media session. > > Wendy Seltzer - there's an active web fonts wg. They would like to use > this. They have been working on drafts. > > Tony Hansen - It does need the relevant community to actually finish > the work. If they don't, then it doesn't happen, plain and simple. > > Barry - the model for when you want a top level type. There's > something common with some subtype. Fonts fit in that model. The fact > is that people are looking at this, then let's do this. > > Mark - so the W3C needs to participate. > > Sean Leander - where does this work fit? > > Barry - AD sponsored or WG. Since nothing fits, it would go to a new > working group. Has to be standards track. > > Murray - next step is to work on the charter. > > Cullen - forming a working group shouldn't be hard or complicated. > Need people interested in the work and working on the charter. Then > the chairs will look at the charter. Then get the draft going forward. > Happy? You don't look happy. > > Mark - I'm happy. > > Cullen - For the minutes: Mark's happy. > > ACTION: People interested in font Primary Content type to create a > charter for the work. > > > Mark - there's another draft by Mike West > (draft-west-webappsec-csp-reg) requesting a registry for CSP > directives. Very simple and straightforward. W3C doesn't have a > registry capability. Can that be AD sponsored? > > Murray - I think that falls under house keeping and can be done in > DISPATCH. > > Barry - I'll let the chairs decide and I'll AD sponsor if not. > > Alissa - I just opened the draft, I see no reason to do this in > independent stream. > > Cullen - read and send comments to the list. > > Richard - seems fine to me. > > Mary - Mark, send mail to the list point to the draft. > > ACTION: Mark to send a pointer to the list. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0 > > ACTION: WG to review and send comments to the list. > > --------------------------------------------------------- > 14:25-14:40 Ultra Low Latency for realtime applications > Presenter: Koen De Schepper > Proposal (including related drafts): > https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 > > Presentation: > https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf > > slide 1: Title > > slide 2: Super Fast Internet? > > slide 3: Super Fast User Experience > > slide 4: Better TCP Exists, but is not compatible with the current > Internet > > slide 5: Comparison of Classic TCP and Scalable TCP Cloud Hosted > Interactive Panoramic Video > > slide 6: Comparison of Classic TCP and Scalable TCP Cloud Hosted > Interactive Panoramic Video > > slide 7: Comparison of Classic TCP and Scalable TCP Cloud Hosted > Interactive Panoramic Video > > slide 8: Why Dispatch? > > slide 9: Simple Solution in the network: DualQ AQM provides low > latency marking and Compatibility > > slide 10: Demo on a Real BB Residential Testbed > > slide 11: Demo on a Real BB Residential Testbed > > slide 12: Improved Web browsing Experience > > slide 13: HTTP Adaptive Streaming (HAS) Experiments > > slide 14: HTTP Adaptive Streaming (HAS) Experiments > > slide 15: Using Just a Scalable TCP connection for Realtime and > interactive services? > > slide 16: Questions > > Mary - this is just a informational thing, not a decision. > > Richard - what does this look like from an app point of view? > > Koen - TCP stacks are upgraded to support this. The Windows data > center server does this. Only a change in the operating system, apps > don't have to set anything. It's easy. > > Ben - it's interesting. This room can't just the cost or implications, > though. This is a TSV thing. > > Koen - it's a transport area decision. Agree. > > Andrew Allen - Does it require support at both ends? > > Koen - Yes > > Andrew - You were talking about other improvements that can't be used? > Are there other solutions? > > Koen - I was talking about this - scalable TCP, but it can't be used yet. > > Bob Briscoe - you missed this point - this can only be used in a data > center, they are too aggressive, they push other traffic out of the > way. With the queueing system, you would be able to use it. > > Cullen - send the pointers to the list so people can learn more. > > ACTION: Bob Briscoe to send pointers to the list. > DONE: > https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc I sent a better link to the ML during the session, which includes the videos shown during the presentation: Bob > > > --------------------------------------------------------- > Wrap-up > > > Cullen - draft-west-webappsec-csp-reg, which was just dispatched, is > already in LC. > > Murray - wrote the draft, put in LC, dispatched in less than 2 weeks. > > Richard - dispatched with dispatch > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > > -- > ________________________________________________________________ > Bob Briscoe http://bobbriscoe.net/ From nobody Thu Nov 5 14:46:49 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 213481B3473 for ; Thu, 5 Nov 2015 14:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ley6FPOVd-J1 for ; Thu, 5 Nov 2015 14:46:44 -0800 (PST) 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 8862C1B3470 for ; Thu, 5 Nov 2015 14:46:44 -0800 (PST) Received: from dhcp-24-116.meeting.ietf94.jp (t20010c4000003024b1e1988d5fd1aff2.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:b1e1:988d:5fd1:aff2]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tA5MjxIo059793 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Thu, 5 Nov 2015 16:46:00 -0600 (CST) (envelope-from mahoney@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host t20010c4000003024b1e1988d5fd1aff2.v6.meeting.ietf94.jp [IPv6:2001:c40:0:3024:b1e1:988d:5fd1:aff2] claimed to be dhcp-24-116.meeting.ietf94.jp To: Bob Briscoe , DISPATCH list References: <563AF0D4.40308@nostrum.com> <563B246C.1000502@bobbriscoe.net> From: "A. Jean Mahoney" Message-ID: <563BDC27.9040301@nostrum.com> Date: Fri, 6 Nov 2015 07:45:59 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <563B246C.1000502@bobbriscoe.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [dispatch] dispatch 94 meeting notes - raw X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Nov 2015 22:46:48 -0000 Thanks for the correction! On 11/5/15 6:42 PM, Bob Briscoe wrote: > Jean, > > See one correction inline... (just before wrap up)... > > On 05/11/15 06:01, A. Jean Mahoney wrote: >> Hi all, >> >> Below are my raw notes. Comments I missed are marked with ellipses (...) >> >> Thanks, >> >> Jean >> >> >> DISPATCH WG - IETF 94 - November 2015 >> >> Wednesday, July 22, 2015 >> Location: Room 502 >> >> Chairs: Mary Barnes, Cullen Jennings, Murray Kucherawy >> >> Note takers: Jean Mahoney and Richard Barnes >> Jabber Scribe: Jonathan Lennox >> Jabber log: http://www.ietf.org/jabber/logs/dispatch/2015-11-04.html >> >> --------------------------------------------------------- >> 13:00-13:10 Agenda and Status >> Presenter: Mary Barnes >> Presentation: >> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf >> >> slide 1: Title >> >> Mary - We now have three Chairs. Murray has joined since we've added >> Apps. >> >> slide 2: Note well >> >> slide 3: Agenda >> >> Mary - the agenda has been updated. HTTP problem statement will not be >> presented. >> >> slide 4: Other topics >> >> Cullen - Mark Nottingham to talk about a W3C/IETF joint doc. >> >> Mark Nottingham - I'm updating RFC 5988, Web Linking >> (draft-nottingham-rfc5988bis), I will bring to dispatch when ready. >> >> slide 5: Deadlines >> >> Mary - Note that Dispatch has earlier deadlines for meetings. However >> we can dispatch on the list, and don't have to wait for a meeting. >> >> >> >> --------------------------------------------------------- >> 13:10-13:25 *Updated* DISPATCH WG charter (chairs, WG) >> https://mailarchive.ietf.org/arch/msg/dispatch/BhiAC1FENumiAa9NKpNxiB1Fwdk >> >> Presenter: Mary Barnes >> Presentation: >> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-1.pdf >> >> >> slide 6: Updated DISPATCH WG Charter >> >> Mary - New items highlighted in red. >> >> Robert Sparks - don't use red to highlight text. >> >> Mary - why? >> >> Cullen - doesn't work with colorblindness. >> >> Barry Leiba - To be clear, we will not do any standards work here, >> just simple admin stuff like putting out docs to get IANA >> registration. No standards work. >> >> Alissa Cooper - on the guiding principles, "The privacy of the >> network"? That's kinda weird. I may suggest an editorial change. >> >> Murray - Appsawg isn't meeting this time. There are 3 docs left and >> then we close down the wg. Feedback received on appsawg - people liked >> the monday meeting. We'll reinstate that in Buenos Aires - there will >> be an ART area general meeting to summarize wg status. >> >> Ben Campbell - the summaries will over new work and highlights, not >> summarizing everything worked on since the last meeting. >> >> Mary - any other comments on the charter? >> >> No other comments on charter. >> >> >> >> --------------------------------------------------------- >> 13:25-13:55 An Opportunistic Approach for Secure Real-time Transport >> Protocol >> Presenter: Alan Johnston >> Document: http://datatracker.ietf.org/doc/draft-johnston-dispatch-osrtp/ >> charter proposal: >> https://mailarchive.ietf.org/arch/msg/dispatch/u4-gTan844X8_Vs0JVLWGbIg47g >> >> Presentation: >> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-0.pdf >> >> >> slide 1: Title >> >> slide 2: Opportunistic Security (OS) >> >> slide 3: History of this Topic >> >> slide 4: Acknowledgement >> >> slide 5: Why now? >> >> slide 6: Why not just publish draft-kaplan-mmusic-best-effort-srtp? >> >> slide 7: Approach >> >> slide 8: Approach Continued >> >> Martin Thomson - a correction: we rely on authenticated signaling >> channel for DTLS-SRTP. >> >> Jonathan Lennox - the point of opportunistic security, it might allow >> MITM but better than nothing. >> >> Jon - they could still sign if they resurrected ... >> >> Magnus Westerlund - I don't know if MIKEY works. It's listed in the >> draft. >> >> Alan Johnston - some MIKEY modes may work, maybe not all. >> >> Magnus - that needs to be checked. >> >> Jon - something can get to pick the weakest security, this is >> problematic. >> >> Alan - could use feedback on that option. The draft just lists >> alternatives, not preferences. >> >> Jon - need to make sure that all 4 options are appropriate, then. Or >> vote them off the island. >> >> Alan - or let the implementors pick. >> >> slide 9: Example: Success >> >> slide 10: Example: Failure >> >> Jonathan - everyone hates cap-neg. You could solve this problem with >> cap-neg, but no one does. This was the original motivation for >> cap-neg. Provide some history on it, add to motivation text. >> >> Cullen as chair - We will dispatch the draft, not create a wg. The key >> question is, do we want to proceed with something of this shape? Can >> we not discuss the details of the charter, just talk about whether we >> work on this? Then can discuss details. Skip to slide 15. >> >> slide 11: Charter Text 1/4 >> >> slide 12: Charter Text 2/4 >> >> slide 13: Charter Text 3/4 >> >> slide 14: Charter Text 4/4 >> >> slide 15: Needed Next Steps >> >> Alan - the draft needs solid reviews. >> >> Roni Even - We'll need to update 5763 - best effort with cap-neg. >> >> Christer Holmberg - I support this. We'll need to connect it to >> DTLS-SDP, they go hand in hand. >> >> Richard Barnes - I tried to get some security guys here. We missed the >> opportunity to call security recommendations downgradable security. >> Anyone in the middle can force things to the weakest security, which >> should not be best practice. In the security considerations, we should >> capture that you should be ok with weakest option. It makes me >> uncomfortable to include SDES in here. I would feel better if it >> removed. I'm concerned - there's a diff between AVP and SAVP - we may >> adopt complexity. >> >> Alan - Most secure devices out there use SDES. Restricting SDES would >> leave them out. >> >> Jonathan Lennox - second best current practice. early media - can't >> distinguish between SDP .... With DTLS - you can tell. >> >> Alan - We need to document the early media limitation. >> >> Jonathan Lennox - probably best wg for this is mmusic. ... >> >> ??? from DT - we support this work. We have some use cases where it's >> more important to get the call through than to secure it. cap-neg is >> additional work. We don't want cap-neg. It's easier to support this. >> >> Christer - The work should be done in mmusic. It's offer/answer for >> opportunistic security. >> >> Cullen as chair - Don't focus on where it gets done. Should we do it? >> >> Jonathan Lennox - Can this draft obsolete cap-neg? >> >> Cullen - cap-neg can be obsoleted all by itself. It doesn't need >> another draft to obsolete it. >> >> Charles Eckel - I would like to see this work happen. It has worked >> well for us. We didn't want to bring it to the IETF. >> >> Mary as chair - Let's take a hum: >> >> Should we do the work in the ART area? many hums >> >> Should we not work on this problem? one hum >> >> Cullen - strong consensus for: we should be doing this work. >> >> RESULTS of hum: strong consensus for the ART area doing the work. >> >> >> Richard - In the middle they can force things down. It creates >> barriers to implementing security. In the community that wants to move >> to a secure state, create minimum security requirements. We don't >> treat HTTPS as mixed content - we want people to fix them. If the call >> completes even if security doesn't' happen, no motivation to fix. >> >> Jon - If we can vote somethings off the island. I understand your >> response to SDES. That will be the tough discussion. We can create a >> negotiation mechanism that is different from a BCP. >> >> Richard - This should not be considered a BCP. This should be heavily >> caveated as a transition tech. >> >> Charles - Securing the media won't be turned on because calls will >> fail because the security fails. You can turn it on and it will work >> sometimes, in the future you can turn it on. Both sides support it, >> and turn it on and it never comes into play. >> >> Alan Ford - I support this work >> >> Jonathan Lennox - seems like an easy extension. ... >> >> Alan - that's different and doesn't solve our problem. >> >> Richard - we've had opportunistic security proposals for web. Browsers >> show lock icons. Do you get the lock icon if it's secured? Phones >> don't have such icons. >> >> Cullen / Mary - some do. >> >> Alan - you give no indications to the user. >> >> Richard - maybe we can be clear about that. >> >> Jonathan Lennox - there were hums for doing the work in the jabber room >> >> >> slide 16: Path Forward >> >> >> >> --------------------------------------------------------- >> 13:55-14:10 HTTP problem statement >> Presenter: Mark Nottingham >> Document: >> https://www.ietf.org/archive/id/draft-nottingham-http-problem-07.txt >> >> >> Not covered >> >> >> >> >> --------------------------------------------------------- >> 14:10-14:25 The font Primary Content type >> Presenter: Mark Nottingham on behalf of W3C >> Document: https://tools.ietf.org/html/draft-lilley-font-toplevel-00 >> Presentation: >> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-3.pdf >> >> slide 1: Title >> >> Font media type - top level >> >> slide 2: >> >> Formats for fonts >> >> >> slide 3: >> >> Martin - on the first point, fonts are approaching turing complete. >> Suspicion is warranted. >> >> slide 4: >> >> Mark - There was support in apps-discuss, but no one wrote the draft. >> W3C wants it to happen and they wrote the draft. >> >> John Levine - media types need someone to implement them. What's their >> plan? >> >> Mark - W3C community seems keen. They want a unique place for font >> formats. >> >> Levine - If no one has an implementation plan, it won't be used. >> Here's an example. application/gzip didn't exist until a few months >> ago when someone needed. If there are people ready to implement it - >> that 's great. >> >> Mark - i's my impression but don't know. >> >> Sean Leonard - I've had to implement a top level media type. This is >> the 3rd attempt for font media type. I question the interest to get it >> all the way to though to publishing. The barrier to register top level >> media type is too high. Need to think about it before issuing the >> registration. For example text/plain. Have a short draft about it first. >> >> Richard - about who wants this, mixed content specs, active and >> passive content is based on top level media type. Browsers determine >> if its safe based on media type. This may not be a safe thing to put >> in there. >> >> Look forward to the media session. >> >> Wendy Seltzer - there's an active web fonts wg. They would like to use >> this. They have been working on drafts. >> >> Tony Hansen - It does need the relevant community to actually finish >> the work. If they don't, then it doesn't happen, plain and simple. >> >> Barry - the model for when you want a top level type. There's >> something common with some subtype. Fonts fit in that model. The fact >> is that people are looking at this, then let's do this. >> >> Mark - so the W3C needs to participate. >> >> Sean Leander - where does this work fit? >> >> Barry - AD sponsored or WG. Since nothing fits, it would go to a new >> working group. Has to be standards track. >> >> Murray - next step is to work on the charter. >> >> Cullen - forming a working group shouldn't be hard or complicated. >> Need people interested in the work and working on the charter. Then >> the chairs will look at the charter. Then get the draft going forward. >> Happy? You don't look happy. >> >> Mark - I'm happy. >> >> Cullen - For the minutes: Mark's happy. >> >> ACTION: People interested in font Primary Content type to create a >> charter for the work. >> >> >> Mark - there's another draft by Mike West >> (draft-west-webappsec-csp-reg) requesting a registry for CSP >> directives. Very simple and straightforward. W3C doesn't have a >> registry capability. Can that be AD sponsored? >> >> Murray - I think that falls under house keeping and can be done in >> DISPATCH. >> >> Barry - I'll let the chairs decide and I'll AD sponsor if not. >> >> Alissa - I just opened the draft, I see no reason to do this in >> independent stream. >> >> Cullen - read and send comments to the list. >> >> Richard - seems fine to me. >> >> Mary - Mark, send mail to the list point to the draft. >> >> ACTION: Mark to send a pointer to the list. >> DONE: >> https://mailarchive.ietf.org/arch/msg/dispatch/SOfXJMCaId3kg2GfSIpoCR8IQe0 >> >> >> ACTION: WG to review and send comments to the list. >> >> --------------------------------------------------------- >> 14:25-14:40 Ultra Low Latency for realtime applications >> Presenter: Koen De Schepper >> Proposal (including related drafts): >> https://mailarchive.ietf.org/arch/msg/dispatch/vn2Ew1MsmvnCeizFVx5dBoYS0z8 >> >> Presentation: >> https://www.ietf.org/proceedings/94/slides/slides-94-dispatch-2.pdf >> >> slide 1: Title >> >> slide 2: Super Fast Internet? >> >> slide 3: Super Fast User Experience >> >> slide 4: Better TCP Exists, but is not compatible with the current >> Internet >> >> slide 5: Comparison of Classic TCP and Scalable TCP Cloud Hosted >> Interactive Panoramic Video >> >> slide 6: Comparison of Classic TCP and Scalable TCP Cloud Hosted >> Interactive Panoramic Video >> >> slide 7: Comparison of Classic TCP and Scalable TCP Cloud Hosted >> Interactive Panoramic Video >> >> slide 8: Why Dispatch? >> >> slide 9: Simple Solution in the network: DualQ AQM provides low >> latency marking and Compatibility >> >> slide 10: Demo on a Real BB Residential Testbed >> >> slide 11: Demo on a Real BB Residential Testbed >> >> slide 12: Improved Web browsing Experience >> >> slide 13: HTTP Adaptive Streaming (HAS) Experiments >> >> slide 14: HTTP Adaptive Streaming (HAS) Experiments >> >> slide 15: Using Just a Scalable TCP connection for Realtime and >> interactive services? >> >> slide 16: Questions >> >> Mary - this is just a informational thing, not a decision. >> >> Richard - what does this look like from an app point of view? >> >> Koen - TCP stacks are upgraded to support this. The Windows data >> center server does this. Only a change in the operating system, apps >> don't have to set anything. It's easy. >> >> Ben - it's interesting. This room can't just the cost or implications, >> though. This is a TSV thing. >> >> Koen - it's a transport area decision. Agree. >> >> Andrew Allen - Does it require support at both ends? >> >> Koen - Yes >> >> Andrew - You were talking about other improvements that can't be used? >> Are there other solutions? >> >> Koen - I was talking about this - scalable TCP, but it can't be used yet. >> >> Bob Briscoe - you missed this point - this can only be used in a data >> center, they are too aggressive, they push other traffic out of the >> way. With the queueing system, you would be able to use it. >> >> Cullen - send the pointers to the list so people can learn more. >> >> ACTION: Bob Briscoe to send pointers to the list. >> DONE: >> https://mailarchive.ietf.org/arch/msg/dispatch/VDPX0Hzj21vbQJ7N9C9n-iVuafc >> > I sent a better link to the ML during the session, which includes the > videos shown during the presentation: > > > > > Bob > >> >> >> --------------------------------------------------------- >> Wrap-up >> >> >> Cullen - draft-west-webappsec-csp-reg, which was just dispatched, is >> already in LC. >> >> Murray - wrote the draft, put in LC, dispatched in less than 2 weeks. >> >> Richard - dispatched with dispatch >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> -- >> ________________________________________________________________ >> Bob Briscoe http://bobbriscoe.net/ From nobody Fri Nov 20 07:07:52 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12BDA1B321F for ; Fri, 20 Nov 2015 07:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.585] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hkd7K3XKwL-i for ; Fri, 20 Nov 2015 07:07:46 -0800 (PST) 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 14DD11B322F for ; Fri, 20 Nov 2015 07:07:36 -0800 (PST) Received: from [10.0.1.10] (cpe-70-119-203-4.tx.res.rr.com [70.119.203.4]) (authenticated bits=0) by nostrum.com (8.15.2/8.14.9) with ESMTPSA id tAKF7ZW2015737 (version=TLSv1 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Fri, 20 Nov 2015 09:07:35 -0600 (CST) (envelope-from ben@nostrum.com) X-Authentication-Warning: raven.nostrum.com: Host cpe-70-119-203-4.tx.res.rr.com [70.119.203.4] claimed to be [10.0.1.10] From: "Ben Campbell" To: DISPATCH Date: Fri, 20 Nov 2015 09:07:35 -0600 Message-ID: <1B9066A1-5130-44D2-B2CB-D869111ECC86@nostrum.com> References: <20151120052258.5F6D2180205@rfc-editor.org> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5180) Archived-At: Subject: [dispatch] Fwd: [Technical Errata Reported] RFC7315 (4540) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 15:07:51 -0000 Hi, Do others agree with this errata report? Thanks! Ben. Forwarded message: > From: RFC Errata System > To: r.jesske@telekom.de, drage@alcatel-lucent.com, > christer.holmberg@ericsson.com, iesg@ietf.org > Cc: dongo.yi@lge.com, rfc-editor@rfc-editor.org > Subject: [Technical Errata Reported] RFC7315 (4540) > Date: Thu, 19 Nov 2015 21:22:58 -0800 (PST) > > The following errata report has been submitted for RFC7315, > "Private Header (P-Header) Extensions to the Session Initiation > Protocol (SIP) for the 3GPP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4540 > > -------------------------------------- > Type: Technical > Reported by: Dongo Yi > > Section: 5.1 > > Original Text > ------------- > 5.1. P-Associated-URI Header Syntax > > > The syntax of the P-Associated-URI header field is described as > follows: > > P-Associated-URI = \\"P-Associated-URI\\" HCOLON > [p-aso-uri-spec] > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > > Corrected Text > -------------- > 5.1. P-Associated-URI Header Syntax > > > The syntax of the P-Associated-URI header field is described as > follows: > > P-Associated-URI = \\"P-Associated-URI\\" HCOLON > (p-aso-uri-spec) > *(COMMA p-aso-uri-spec) > p-aso-uri-spec = name-addr *(SEMI ai-param) > ai-param = generic-param > > > Notes > ----- > P-Associated-URI cannot include an empty header value (which was able > to be included according to RFC 3455) > > - Background. > > The policy of P-Associated-URI has been updated from RFC 3455. > RFC 3455 : 4.1.2.2 Procedures at the registrar > ... > In case the address-of-record under registration does not have any > other SIP or SIPS URIs associated, the registrar MUST include an > empty P-Associated-URI header value. > > > RFC 7315 : 4.1.2.2 Procedures at the Registrar > ... > If the address-of-record under registration does not have any > associated URIs, the P-Associated-URI header field SHALL NOT be > included. > ... > > Moreover, we can say RFC 3455 has same errata based on this analysis. > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC7315 (draft-drage-sipping-rfc3455bis-14) > -------------------------------------- > Title : Private Header (P-Header) Extensions to the > Session Initiation Protocol (SIP) for the 3GPP > Publication Date : July 2014 > Author(s) : R. Jesske, K. Drage, C. Holmberg > Category : INFORMATIONAL > Source : IETF - NON WORKING GROUP > Area : N/A > Stream : IETF > Verifying Party : IESG > From nobody Fri Nov 20 07:35:09 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4FC61B2A41 for ; Fri, 20 Nov 2015 07:35:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.235 X-Spam-Level: X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXeq9hZaspDQ for ; Fri, 20 Nov 2015 07:35:06 -0800 (PST) Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55A8C1B2A40 for ; Fri, 20 Nov 2015 07:35:06 -0800 (PST) Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-10v.sys.comcast.net with comcast id jraj1r0032S2Q5R01rb525; Fri, 20 Nov 2015 15:35:05 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-16v.sys.comcast.net with comcast id jrb51r0013KdFy101rb5yX; Fri, 20 Nov 2015 15:35:05 +0000 To: dispatch@ietf.org References: <20151120052258.5F6D2180205@rfc-editor.org> <1B9066A1-5130-44D2-B2CB-D869111ECC86@nostrum.com> From: Paul Kyzivat Message-ID: <564F3DA8.4010806@alum.mit.edu> Date: Fri, 20 Nov 2015 10:35:04 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <1B9066A1-5130-44D2-B2CB-D869111ECC86@nostrum.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1448033705; bh=o2T17qtdd7c+53CdP6F/s1awTn+gWGC0wHpSeU4A9E0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=iBXh22xMnTfma3fTSX8cQGy7eiGrUqluN3ZTEJPKpm63iY+BFOQ1dzdxEvtgZJnkz gDHdPLk5Vin+wq0QdNLJSlktkfNRi2UgJVfnNJUQK5F2nenEbvAoMczt8awMRCNiFS 9t/wOTiyMMIc78FfB0tqtyPjI/UkVHxuUo1vVt0kDaNDB8TRNcSpAahHqPzlks5SPs NMql8TlmHSZlzDb9khpwyKe6y2ZAIseoGJIca0IbTkxWsGIPuwSKvAmXYku23ze6t1 Abn1vS+i4AsyWgexuUxSRhFZTZ7jOg8D6XHG6bQnMOq4+/HFOeRSudJgSe7mEBB73M 7S2WF6+fIftbQ== Archived-At: Subject: Re: [dispatch] Fwd: [Technical Errata Reported] RFC7315 (4540) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 15:35:08 -0000 On 11/20/15 10:07 AM, Ben Campbell wrote: > Hi, > > Do others agree with this errata report? IIUC, 7315 has revised the usage so that the optionality of the URI is no longer needed. But the current definition still *works* with 7315. (The feature being proposed for removal won't be used.) So I don't see that there is an error to fix. The "fix" will mean that implementations using 3455 could fail to interoperate with implementations using 7315. ISTM it would be better to leave the syntax unchanged, but add text indicating that use with an empty URI is deprecated, but should be accepted for backward compatibility. Thanks, Paul > Thanks! > > Ben. > > Forwarded message: > >> From: RFC Errata System >> To: r.jesske@telekom.de, drage@alcatel-lucent.com, >> christer.holmberg@ericsson.com, iesg@ietf.org >> Cc: dongo.yi@lge.com, rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC7315 (4540) >> Date: Thu, 19 Nov 2015 21:22:58 -0800 (PST) >> >> The following errata report has been submitted for RFC7315, >> "Private Header (P-Header) Extensions to the Session Initiation >> Protocol (SIP) for the 3GPP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=7315&eid=4540 >> >> -------------------------------------- >> Type: Technical >> Reported by: Dongo Yi >> >> Section: 5.1 >> >> Original Text >> ------------- >> 5.1. P-Associated-URI Header Syntax >> >> >> The syntax of the P-Associated-URI header field is described as >> follows: >> >> P-Associated-URI = \\"P-Associated-URI\\" HCOLON >> [p-aso-uri-spec] >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec = name-addr *(SEMI ai-param) >> ai-param = generic-param >> >> >> Corrected Text >> -------------- >> 5.1. P-Associated-URI Header Syntax >> >> >> The syntax of the P-Associated-URI header field is described as >> follows: >> >> P-Associated-URI = \\"P-Associated-URI\\" HCOLON >> (p-aso-uri-spec) >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec = name-addr *(SEMI ai-param) >> ai-param = generic-param >> >> >> Notes >> ----- >> P-Associated-URI cannot include an empty header value (which was able >> to be included according to RFC 3455) >> >> - Background. >> >> The policy of P-Associated-URI has been updated from RFC 3455. >> RFC 3455 : 4.1.2.2 Procedures at the registrar >> ... >> In case the address-of-record under registration does not have any >> other SIP or SIPS URIs associated, the registrar MUST include an >> empty P-Associated-URI header value. >> >> >> RFC 7315 : 4.1.2.2 Procedures at the Registrar >> ... >> If the address-of-record under registration does not have any >> associated URIs, the P-Associated-URI header field SHALL NOT be >> included. >> ... >> >> Moreover, we can say RFC 3455 has same errata based on this analysis. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7315 (draft-drage-sipping-rfc3455bis-14) >> -------------------------------------- >> Title : Private Header (P-Header) Extensions to the >> Session Initiation Protocol (SIP) for the 3GPP >> Publication Date : July 2014 >> Author(s) : R. Jesske, K. Drage, C. Holmberg >> Category : INFORMATIONAL >> Source : IETF - NON WORKING GROUP >> Area : N/A >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > From nobody Fri Nov 20 11:37:35 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A5991B2E0C for ; Fri, 20 Nov 2015 11:37:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QF_ABv_aQltd for ; Fri, 20 Nov 2015 11:37:32 -0800 (PST) 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 913901B2E05 for ; Fri, 20 Nov 2015 11:37:31 -0800 (PST) X-AuditID: c1b4fb25-f79a26d00000149a-5f-564f7679f15a Received: from ESESSHC024.ericsson.se (Unknown_Domain [153.88.183.90]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 3D.1A.05274.9767F465; Fri, 20 Nov 2015 20:37:29 +0100 (CET) Received: from ESESSMB209.ericsson.se ([169.254.9.142]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.03.0248.002; Fri, 20 Nov 2015 20:37:29 +0100 From: Christer Holmberg To: Paul Kyzivat , "dispatch@ietf.org" Thread-Topic: [dispatch] Fwd: [Technical Errata Reported] RFC7315 (4540) Thread-Index: AQHRI1O3ftTLy0FWn0KYpvGefxIro56lA9B4///20gCAAFDK8A== Date: Fri, 20 Nov 2015 19:37:28 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B37C5B3EC@ESESSMB209.ericsson.se> References: <20151120052258.5F6D2180205@rfc-editor.org> <1B9066A1-5130-44D2-B2CB-D869111ECC86@nostrum.com> <564F3DA8.4010806@alum.mit.edu> In-Reply-To: <564F3DA8.4010806@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrDLMWRmVeSWpSXmKPExsUyM2J7lG5lmX+Ywapl+hZLJy1gtVix4QCr A5PH3/cfmDyWLPnJFMAUxWWTkpqTWZZapG+XwJXR9Gkla8F/lYrbn14zNzAel+li5OCQEDCR OPBFoouRE8gUk7hwbz1bFyMXh5DAYUaJtf/3MkI4SxglDjdvYQRpYBOwkOj+pw3SICIQLHHw 8E4WEFtYwF3izqrZLBBxD4l7qzYyQ9hOEnu6d4HFWQRUJc5tv8sKYvMK+Eo0b/zJCjG/j1Hi 2YwV7CAJTgEdiQV3J4E1MwJd9P3UGiYQm1lAXOLWk/lMEJcKSCzZc54ZwhaVePn4HyuErSTR uOQJK0Q90Jzdn9ggbG2JZQtfM0MsFpQ4OfMJywRG0VlIxs5C0jILScssJC0LGFlWMYoWpxYn 5aYbGeulFmUmFxfn5+nlpZZsYgTGycEtv1V3MF5+43iIUYCDUYmH10DGL0yINbGsuDL3EKME B7OSCO+Bd0Ah3pTEyqrUovz4otKc1OJDjNIcLErivM1MD0KFBNITS1KzU1MLUotgskwcnFIN jBlKB0yss8/I/s7e/GXZ4f3mgeV23cnX/fVfx87s7rm/VlhCwzKpfNWq3NIb+5v36x3+JzzH 6nqG3ZzuJwEX38avPiY171ym2qUq03m8uWHzZhzzYxUJvHRUZ9WcN7dVcyT2f7/C4NDdkK3E sG31U4aZf7ZF5rkVfI8IWVv7/col0zsmsitaliuxFGckGmoxFxUnAgBu4EW6jwIAAA== Archived-At: Subject: Re: [dispatch] Fwd: [Technical Errata Reported] RFC7315 (4540) X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Nov 2015 19:37:34 -0000 Hi, >>> Do others agree with this errata report? >> >> IIUC, 7315 has revised the usage so that the optionality of the URI is n= o longer needed. But the current definition still *works* with 7315.=20 >> (The feature being proposed for removal won't be used.) So I don't see t= hat there is an error to fix. The "fix" will mean that implementations=20 >> using 3455 could fail to interoperate with implementations using 7315. > > ISTM it would be better to leave the syntax unchanged, but add text indic= ating that use with an empty URI is deprecated, but should be accepted for = backward compatibility. An empty URI means that there are no associated URIs. Perhaps an entity wan= ts to explicitly indicate that - showing that the PAU mechanism is supporte= d, but that there are no associated URIs. I am not sure why we should depre= cate that. However, note that the following syntax allows the following: P-Associated-URI:, <----- Note the comma before the URI. Regards, Christer > Forwarded message: > >> From: RFC Errata System >> To: r.jesske@telekom.de, drage@alcatel-lucent.com,=20 >> christer.holmberg@ericsson.com, iesg@ietf.org >> Cc: dongo.yi@lge.com, rfc-editor@rfc-editor.org >> Subject: [Technical Errata Reported] RFC7315 (4540) >> Date: Thu, 19 Nov 2015 21:22:58 -0800 (PST) >> >> The following errata report has been submitted for RFC7315, "Private=20 >> Header (P-Header) Extensions to the Session Initiation Protocol (SIP)=20 >> for the 3GPP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=3D7315&eid=3D4540 >> >> -------------------------------------- >> Type: Technical >> Reported by: Dongo Yi >> >> Section: 5.1 >> >> Original Text >> ------------- >> 5.1. P-Associated-URI Header Syntax >> >> >> The syntax of the P-Associated-URI header field is described as >> follows: >> >> P-Associated-URI =3D \\"P-Associated-URI\\" HCOLON >> [p-aso-uri-spec] >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec =3D name-addr *(SEMI ai-param) >> ai-param =3D generic-param >> >> >> Corrected Text >> -------------- >> 5.1. P-Associated-URI Header Syntax >> >> >> The syntax of the P-Associated-URI header field is described as >> follows: >> >> P-Associated-URI =3D \\"P-Associated-URI\\" HCOLON >> (p-aso-uri-spec) >> *(COMMA p-aso-uri-spec) >> p-aso-uri-spec =3D name-addr *(SEMI ai-param) >> ai-param =3D generic-param >> >> >> Notes >> ----- >> P-Associated-URI cannot include an empty header value (which was able=20 >> to be included according to RFC 3455) >> >> - Background. >> >> The policy of P-Associated-URI has been updated from RFC 3455. >> RFC 3455 : 4.1.2.2 Procedures at the registrar ... >> In case the address-of-record under registration does not have any=20 >> other SIP or SIPS URIs associated, the registrar MUST include an=20 >> empty P-Associated-URI header value. >> >> >> RFC 7315 : 4.1.2.2 Procedures at the Registrar ... >> If the address-of-record under registration does not have any=20 >> associated URIs, the P-Associated-URI header field SHALL NOT be=20 >> included. >> ... >> >> Moreover, we can say RFC 3455 has same errata based on this analysis. >> >> Instructions: >> ------------- >> This erratum is currently posted as "Reported". If necessary, please=20 >> use "Reply All" to discuss whether it should be verified or rejected.=20 >> When a decision is reached, the verifying party (IESG) can log in to=20 >> change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC7315 (draft-drage-sipping-rfc3455bis-14) >> -------------------------------------- >> Title : Private Header (P-Header) Extensions to the >> Session Initiation Protocol (SIP) for the 3GPP >> Publication Date : July 2014 >> Author(s) : R. Jesske, K. Drage, C. Holmberg >> Category : INFORMATIONAL >> Source : IETF - NON WORKING GROUP >> Area : N/A >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > dispatch mailing list > dispatch@ietf.org > https://www.ietf.org/mailman/listinfo/dispatch > _______________________________________________ dispatch mailing list dispatch@ietf.org https://www.ietf.org/mailman/listinfo/dispatch From nobody Sun Nov 22 02:07:02 2015 Return-Path: X-Original-To: dispatch@ietfa.amsl.com Delivered-To: dispatch@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 038121B2CF7 for ; Sun, 22 Nov 2015 02:07:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.701 X-Spam-Level: X-Spam-Status: No, score=-4.701 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, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JZC9B-mAGknu for ; Sun, 22 Nov 2015 02:06:59 -0800 (PST) Received: from smtp3.hushmail.com (smtp3.hushmail.com [65.39.178.200]) (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 CBD311B2CEC for ; Sun, 22 Nov 2015 02:06:59 -0800 (PST) Received: from smtp3.hushmail.com (localhost [127.0.0.1]) by smtp3.hushmail.com (Postfix) with SMTP id 435F8E019D for ; Sun, 22 Nov 2015 10:06:59 +0000 (UTC) X-hush-tls-connected: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed; d=hush.com; h=date:to:subject:from; s=hush; bh=xbYu+A0gqwMnwi8nQrtv9knUhxfWT7EUhfmaDC9QVnk=; b=RAoyvkfj95LgbZh2szIZ4CD5Qid1zV8NZw+klVFvpmsM2ky7ZZHDD+/Vg42h7rbJbL6N35UZ0L3SIx/hBySL0fwjGyLCh6Z1Cic0/KqV3cVRroHHdKOxFDdCLby4PspjgG/RdutvqPm2q7dgkBlkVAbNv7N9l3rnZbqMuJx/52Va4hIjneAGzgiIgok0CDcsmFhguBHbjZPI13gcvS89QNGHfzzAo8YW+7FsyZVzFx8TM7455Fr1T+A/Ce2ZVkZnJGRzKpIpyj+jdUEHs8O0xLi14fU9lMyAkqcvHexjZs9eL10gj52VNVUPLiViDVqCvMSvKRRYUi38zJ5/l6fG1A== Received: from smtp.hushmail.com (w7.hushmail.com [65.39.178.32]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp3.hushmail.com (Postfix) with ESMTPS for ; Sun, 22 Nov 2015 10:06:59 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 22B2240590; Sun, 22 Nov 2015 10:06:59 +0000 (UTC) MIME-Version: 1.0 Date: Sun, 22 Nov 2015 05:06:58 -0500 To: dispatch@ietf.org From: "Samir Srivastava" Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20151122100659.22B2240590@smtp.hushmail.com> Archived-At: Subject: [dispatch] Discussion Invitation X-BeenThere: dispatch@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DISPATCH Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Nov 2015 10:07:01 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, I would like to invite the discussion on https://tools.ietf.org/html/draft-srivastava-dispatch-avoidance-of- threats-00 Did anyone read it when it was submitted ? It looks interesting. Thanks Samir Idiot -----BEGIN PGP SIGNATURE----- Charset: UTF8 Note: This signature can be verified at https://www.hushtools.com/verify Version: Hush 3.0 wpwEAQMCAAYFAlZRk8MACgkQvdot3LfSFCRHfQP/TSzMDtAi+VtAs3/aRhC5PXCGuozO kUnNbqfkuoai4xkMrNYecYKcrnEX4+G5FmUrnU2y6cEvvDQxiIOmJTfHQ7+MkbU0JA8T aNaGWLPhWVSdGYXqWkZ3mly7hWRTXlZ/UTNw1DX456rEKfnpFWMDgNd4Fe/GkzEisE1h 9rxc54g= =TyVf -----END PGP SIGNATURE-----