Subject: [Perc] Adam Roach's Yes on draft-ietf-perc-private-media-framework-10: (with COMMENT)

From: Adam Roach via Datatracker <[email-masked]>
Date: Mon, 13 May 2019 15:33:21 -0700

Adam Roach has entered the following ballot position for
draft-ietf-perc-private-media-framework-10: Yes

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-private-media-framework/

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

I'm glad to see this work finally ready for publication. As I've already
given several rounds of input on this document, I have only minor
editorial comments.
---------------------------------------------------------------------------

§2:

>  This may
>  include embedded user conferencing equipment or browsers on
>  computers, media gateways, MCUs, media recording device and more that
>  are in the trusted domain for a given deployment.

Nit: "...media recording devices, and more..."
                   pluralize _/  \_ add comma

---------------------------------------------------------------------------

§2:

>  In the context of
>  WebRTC...

Please add an informative citation to https://www.w3.org/TR/webrtc/

---------------------------------------------------------------------------

§2:

>  It operates according to the Selective
>  Forwarding Middlebox RTP topologies [RFC7667] per the constraints
>  defined by the PERC system, which includes, but not limited to,

Nit: "...but is not limited to..."

---------------------------------------------------------------------------

§6.1:

Nit: The keys are described in the sections that follow in the order
they are typically acquired, but listed in a different order in Figure 4.
This confused me for several moments. Consider reordering Figure 4 to match
the order in which the keys are described.

---------------------------------------------------------------------------

---

From: "Paul E. Jones" <[email-masked]>
Date: Tue, 14 May 2019 01:19:03 +0000

Thanks, Adam.  All good comments that I've made locally.  The changes 
will appear in the next revision.

Note that section 6.5 also has keys in a different order.  Since that 
deals with multiple HBH keys, I'm not sure that it makes sense to 
re-order the table, since I can't get a 1:1 mapping.  However, I'm happy 
to move anything around if you thinks it lends to readability.

Paul

------ Original Message ------
From: "Adam Roach via Datatracker" <[email-masked]>
To: "The IESG" <[email-masked]>
Cc: [email-masked]; "Nils Ohlmeier" 
<[email-masked]>; [email-masked]; [email-masked]; 
[email-masked]
Sent: 5/13/2019 6:33:21 PM
Subject: Adam Roach's Yes on draft-ietf-perc-private-media-framework-10: 
(with COMMENT)

---

From: Adam Roach <[email-masked]>
Date: Tue, 14 May 2019 17:43:17 -0500

> will appear in the next revision.

Thanks!

> re-order the table, since I can't get a 1:1 mapping. However, I'm 
> happy to move anything around if you thinks it lends to readability.

Sure. The problem here is that the document looks like this:

>     The keysare described in the order in which they would typically be acquired.
>
>     The various keys used in PERC are shown in Figure 4 below.
>
>      +-----------+----------------------------------------------------+
>      | Key       |Description                                         |
>      +-----------+----------------------------------------------------+
>      | KEK       | Key shared by all endpoints and used to encrypt    |
>      | (EKT Key) | each endpoint's E2E SRTP master key so receiving   |
>      |           | endpoints can decrypt media.                       |
>      +-----------+----------------------------------------------------+
>      | HBH Key   | SRTP master key used to encrypt media hop-by-hop.  |
>      +-----------+----------------------------------------------------+
>      | E2E Key   | SRTP master key used to encrypt media end-to-end.  |
>      +-----------+----------------------------------------------------+

So you have the statement "...are described in the order..." 
*immediately* followed by a table with a header labeled "Description" -- 
and that table is *not* in the order specified.

So it's not as much a matter of making all of the keys always appearing 
in the same order, as much as not having this confusing juxtaposition.

/a