[MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Adam Roach <adam@nostrum.com> Wed, 16 August 2017 23:06 UTC
Return-Path: <adam@nostrum.com>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9514F132480; Wed, 16 Aug 2017 16:06:31 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-dtls-sdp@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.58.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <150292479151.11986.12302184246173787021.idtracker@ietfa.amsl.com>
Date: Wed, 16 Aug 2017 16:06:31 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/GbugjQyzQ83SquLdEev9IcLUQNw>
Subject: [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2017 23:06:32 -0000
Adam Roach has entered the following ballot position for draft-ietf-mmusic-dtls-sdp-28: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-mmusic-dtls-sdp/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 5.4 says: NOTE: A new DTLS association can be established based on changes in either an SDP offer or answer. When communicating with legacy endpoints, an offerer can receive an answer that includes the same fingerprint set and setup role. A new DTLS association MUST still be established if such an answer was received as a response to an offer which requested the establishment of a new DTLS association. Unless I've misunderstood something important, this isn't going to work with legacy implementations, unless you also specify that an "offer which requested the establishment of a new DTLS association" must also change something else that the legacy answerer will recognize as requiring a new DTLS association. For example, if I send a re-offer with a changed tls-id but the same fingerprint, setup, and transport, the far end will have no reason to think it needs to establish a new DTLS association. So I'll sit there waiting for a new association to be established, and the remote side will never send one. This doesn't seem backwards-compatible. At the very least, more text needs to be added explaining how this is intended to work. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- I agree with the core assertion of EKR's DISCUSS: this document needs to be aligned with JSEP. I think we're going to need a little additional work figuring out which document needs to change where they disagree. In addition to those areas he highlights in his DISCUSS, the following text is also in conflict: DTLS-SDP: "the offerer and answerer generate their own local 'tls-id' attribute values, and the combination of both values identify the DTLS association." JSEP: "If this is an answer, the tls-id value, if present, MUST be the same as in the offer." I would think the long-form title of this document should include "TLS," to reflect that it also contains TLS-related procedures. Section 1: "...but currently there is no way..." will not age well once this is an RFC. Suggest "...previously, there was no way..." or somesuch. Section 2 uses RFC 2119 boilerplate, and then the very next sentence uses a non-normative "must." I would strongly recommend moving to RFC 8174 boilerplate. The conventional name for DTLS-SRTP is "DTLS-SRTP" -- please change replace "SRTP-DTLS" with "DTLS-SRTP" everywhere it appears. The last paragraph in section 5.4 starts with "NOTE" (which implementors frequently read as non-normative) and then contains a normative statement. Suggest removing "NOTE:" Please expand the following acronyms upon first use and in the title; see https://www.rfc-editor.org/materials/abbrev.expansion.txt for guidance. - SDP - Session Description Protocol - DTLS - Datagram Transport Layer Security - TLS - Transport Layer Security - ICE - Interactive Connectivity Establishment - SCTP - Stream Control Transmission Protocol - SRTP - Secure Realtime Transport Protocol - UDPTL - UDP Transport Layer
- [MMUSIC] Adam Roach's Discuss on draft-ietf-mmusi… Adam Roach
- Re: [MMUSIC] Adam Roach's Discuss on draft-ietf-m… Roman Shpount
- Re: [MMUSIC] Adam Roach's Discuss on draft-ietf-m… Adam Roach