[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 :)