[AVTCORE] Paul Wouters' Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)
Paul Wouters via Datatracker <noreply@ietf.org> Wed, 15 June 2022 11:28 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: avt@ietf.org
Delivered-To: avt@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E48C14F725; Wed, 15 Jun 2022 04:28:24 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Paul Wouters via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-avtcore-cryptex@ietf.org, avtcore-chairs@ietf.org, avt@ietf.org, bernard.aboba@gmail.com, bernard.aboba@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 8.3.1
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Paul Wouters <paul.wouters@aiven.io>
Message-ID: <165529250428.45302.11885634090621500579@ietfa.amsl.com>
Date: Wed, 15 Jun 2022 04:28:24 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/PvlDFMawiWXR707PiAAhdHQ2-Zc>
Subject: [AVTCORE] Paul Wouters' Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.39
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 Jun 2022 11:28:24 -0000
Paul Wouters has entered the following ballot position for draft-ietf-avtcore-cryptex-06: 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/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-avtcore-cryptex/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- Thanks for this document. It is clear, and I appreciate reading the rationale of the proposed solution. Just one discuss item: Peers MAY negotiate both Cryptex and the header extension mechanism defined in [RFC6904] via signaling, and if both mechanisms are supported, either one can be used for any given packet. However, if a packet is encrypted with Cryptex, it MUST NOT also use [RFC6904] header extension encryption, and vice versa. Why this complexity? Based on the Section 1, Cryptex is much more preferred. Why allow "either one can be used for any given packet" instead of saying if both are negotiated, Cryptex SHOULD be used? Or why not stronger, if both peers support Cryptex, RFC6904 SHOULD NOT (MUST NOT?) be used? ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- The Shepherds write-up with respect to IPR shows two authors confirming they have filed "all required disclosures" but does not list whether this means "there are non", "there are some, compatible with IETF" or that there is "disclosed, incompatible with IETF". The Shepherds write up does state no disclosures are filed. I find the two authors' response a bit odd. Section 1.2 describes a problem of "using a few more bytes", but how is that a real problem? Does it really matter? The other reasons stated seem real issues to me but the "few more bytes" seems fairly harmless? we felt Who or what is "we"? Probably rewrite to "It was considered" or something? Alternatively, if the implementation considers the use of this specification mandatory and the "defined by profile" field does not match one of the values defined above, it SHOULD stop the processing of the RTP packet and report an error for the RTP stream. Why is this not a MUST stop ? If it is mandatory, what is an example where it can continue processing an RTP packet without the mandatory requirement? It seems Section 3 could be just a last paragraph of the Introduction? Nits: Section 1.1 first line misses "(SRTP)" acronym CSRC not expanded before first use. Section 1.2 "RFC6904" is not properly linked Section 4's title could be improved, eg "Signaling of Cryptex Support" Section 4's opening line could be simplified eg: Cryptex support is indicated via the new "a=cryptex" Session Description Protocol (SDP) attribute. SDP not expanded on first use BUNDLE is not expanded (or linked to a reference) on first use. [RFC8285] in Section 5 is not a proper link I personally dislike "+-+-+-+-+-+-+-+-+-+-+-+-+-+-+" and prefer the less christmas tree "+------+----------+" style diagram :)
- [AVTCORE] Paul Wouters' Discuss on draft-ietf-avt… Paul Wouters via Datatracker