[AVTCORE] Lars Eggert's Discuss on draft-ietf-avtcore-cryptex-06: (with DISCUSS and COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert 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:
----------------------------------------------------------------------

This document seems to have unresolved IANA issues. Holding a DISCUSS
until we can confirm on the telechat that a resolution is in progress.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks to Linda Dunbar for the General Area Review Team (Gen-ART) review
(https://mailarchive.ietf.org/arch/msg/gen-art/OSDyO_tiu5StDZyyJjwRP-Nvj-M).

-------------------------------------------------------------------------------
COMMENT
-------------------------------------------------------------------------------

Section 1.2, paragraph 1
>    [RFC6904] was proposed in 2013 as a solution to the problem of
>    unprotected header extension values.  However, it has not seen
>    significant adoption, and has a few technical shortcomings.


Would it be time to deprecate 6904? (Also see Paul's DISCUSS and Alavaro's
comment.)

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Term "master"; alternatives might be "active", "central", "initiator",
   "leader", "main", "orchestrator", "parent", "primary", "server"

-------------------------------------------------------------------------------
NIT
-------------------------------------------------------------------------------

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

Section 5.1, paragraph 1
>    When the mechanism defined by this specification has been negotiated,
>    sending a RTP packet that has any CSRCs or contains any {RFC8285}}
>    header extensions follows the steps below.  This mechanism MUST NOT
>    be used with header extensions other than the [RFC8285] variety.


Likely Markdown nit: {RFC8285}}

Reference [RFC4566] to RFC4566, which was obsoleted by RFC8866 (this may be on
purpose).

Section 5, paragraph 0
> fication has been negotiated, sending a RTP packet that has any CSRCs or cont
>                                       ^
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

Section 5.1, paragraph 4
> ecryption Procedure, and passed to the the next layer to process the packet a
>                                    ^^^^^^^
Possible typo: you repeated a word.

Section 6.2, paragraph 9
> ence number and SSRC identifier. Accordingly these values are also not encryp
>                                  ^^^^^^^^^^^
A comma may be missing after the conjunctive/linking adverb "Accordingly".