[MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)
Alissa Cooper via Datatracker <noreply@ietf.org> Tue, 28 May 2019 19:35 UTC
Return-Path: <noreply@ietf.org>
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 203BE120019; Tue, 28 May 2019 12:35:32 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alissa Cooper via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mmusic-rfc4566bis@ietf.org, mmusic-chairs@ietf.org, fandreas@cisco.com, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.97.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Alissa Cooper <alissa@cooperw.in>
Message-ID: <155907213212.25802.10923362703417281306.idtracker@ietfa.amsl.com>
Date: Tue, 28 May 2019 12:35:32 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/PFOnQPwr6DijDuzwthaRH2TtOTw>
Subject: [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mmusic-rfc4566bis-35: (with DISCUSS and COMMENT)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 28 May 2019 19:35:32 -0000
Alissa Cooper has entered the following ballot position for draft-ietf-mmusic-rfc4566bis-35: 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-rfc4566bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Section 8.2.8: "In the RFC specifications that register new values for SDP "media", "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the authors MUST include the following information for IANA to place in the appropriate registry:" It doesn't look like all the fields that are listed after this text actually appear in the registries. For some of these I don't see why the information would be put into the registries (e.g., contact name, contact email address, since those appear in the RFCs themselves). I think this needs to be clarified. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 5.1: Since both this document and RFC 4566 specify version 0 and this version makes semantic and syntactic changes, does that mean the protocol versioning is non-functional? Or if not, what kinds of changes would require a new version number? Section 7: "Use of the "k=" line poses a significant security risk, since it conveys session encryption keys in the clear. SDP MUST NOT be used to convey keying material, unless it can be guaranteed that the channel over which the SDP is delivered is both private and authenticated. Moreover, the "k=" line provides no way to indicate or negotiate cryptographic key algorithms. As it provides for only a single symmetric key, rather than separate keys for confidentiality and integrity, its utility is severely limited. The "k=" line MUST NOT be used, as discussed in Section 5.12." It's odd to me that this text was retained from RFC 4566 as-is, except for the last sentence. I would have expected this to lead with something like 'Use of the "k=" line is obsolete due to security risk.' And then perhaps some of the rest of the text could remain by way of explanation why it was obsoleted. Section 8.2.8: "IANA may refer any registration to the IESG for review, and may request revisions to be made before a registration will be made." This is trivially true and would be better left out, using RFC 8126 as the definitive guidance instead.
- [MMUSIC] Alissa Cooper's Discuss on draft-ietf-mm… Alissa Cooper via Datatracker
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Paul Kyzivat
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Adam Roach
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Paul Kyzivat
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Adam Roach
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Barry Leiba
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Alissa Cooper
- Re: [MMUSIC] Alissa Cooper's Discuss on draft-iet… Paul Kyzivat