[Perc] Barry Leiba's No Objection on draft-ietf-perc-double-10: (with COMMENT)

[Barry Leiba via Datatracker <[e-mail]>]

Barry Leiba has entered the following ballot position for
draft-ietf-perc-double-10: No Objection

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-perc-double/



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

— Section 2 —

In the definition of “hop-by-hop”:
The definition of “end-to-end” says there can be more than one distributor. 
So, can’t a hop also be distributor to distributor (not involving an endpoint)?

Also, the definition is really of “hop”, rather than of “hop-by-hop”, isn’t it?

— Section 3 —

   The RECOMMENDED cipher for the hop-by-hop and end-to-end algorithm is
   AES-GCM.  Other combinations of SRTP ciphers that support the
   procedures in this document can be added to the IANA registry.

Is there an implication that the cipher used MUST be one that is in the
registry?  If so, it should say that.

   o  the SSRC is the same for both the inner and out outer algorithms

Extra word “out”.

   If the Media Distributor is to be able to modify header fields but
   not decrypt the payload, then it must have cryptographic key for the
  outer algorithm, but not the inner (end-to-end) algorithm.

Missing article, “the cryptographic key”.

— Section 4 —

   to verify the E2E integrity of the packet.

Because you explicitly define “end-to-end” and generally use that term (24
times), I suggest being consistent and not using “E2E” (5 times) also. 
Alternatively, you could add “or E2E” to the definition in Section 2. 
(Similarly for “HBH”.)

— Section 5.2 —

Doesn’t bullet 4 contradict 3?  If I’m allowed to change something back to its
original value and drop it from the OHB, then I’m clearly changing information
in the OHB.  Maybe a little rewording would be useful.

— Section 8 —

   These algorithm provide
   for authenticated encryption and will consume additional processing

Should be “These algorithms”.

— Section 10.1 —

   The SRTP transform parameters for each of these protection are:

The word “protection” isn’t right.  Do you want “protection profiles” here?