[OPSAWG] Adam Roach's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Adam Roach <[e-mail]>]

Adam Roach has entered the following ballot position for
draft-mm-wg-effect-encrypt-17: 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-mm-wg-effect-encrypt/



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

Thanks for all the work that has gone into this document. The framing and tone
is much improved over -10, and the reorganization of section 7 into the rest
of the document helps a lot. I do have a handful of comments. In particular,
I think the omission in section 2.3.4 is very important; however, I
wanted to clear my discuss and trust the sponsoring AD to do the right thing
here rather than re-issuing a different discuss position.

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

§2.1.2 -- I am surprised that there is so much discussion of fields that are
not generally encrypted in practice (e.g., RTP headers, TCP headers). It may
be worth distinguishing between session-layer, transport-layer and
network-layer security.

(I think I mentioned this in my initial review, and saw neither a response nor a
document change in reaction to it.)

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

§2.2.3 -- This section reads like a set of unfinished "notes to self" for the
authors' later use. Minimally, I would suggest restructuring the sentence
fragments in this section into sentences. I will also note that section 2
indicates that the following sections will discuss both (a) purpose of the
technique, and (b) fields used to achieve this purpose. This section appears
to lack the latter.

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

§2.2.5:

>   For example, network caching of popular content at a
>   location close to the requesting user can improve delivery efficiency
>   (both in terms of lower request response times and reduced use of
>   International Internet links when content is remotely located), and
>   authorized parties acting on their behalf use DPI in combination with
>   content distribution networks to determine if they can intervene
>   effectively.  Caching was first supported in [RFC1945] and continued
>   in the recent update of "Hypertext Transfer Protocol (HTTP/1.1):
>   Caching" in [RFC7234].

The transition from the general case of caching to the specific case of HTTP
proxy caching (and the subsequent change back to the general case) seems
rather abrupt. Consider splitting the HTTP proxy caching out into a separate
paragraph.

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

§2.2.5:

>   The Enhanced Multimedia Broadcast/
>   Multicast Services (3GPP eMBMS) - trusted edge proxies facilitate
>   delivering same stream to different users, using either unicast or
>   multicast depending on channel conditions to the user.

This passage also reads like outline notes rather than a finished document.

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

§2.2.5:

>   preserving end-to-end security: AMT, for instance, allows CDNs to

Please expand "AMT".

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

§2.2.7:

>    A goal is protecting end-user
>    data -- but at the same time not making the network inoperable or
>    unmanageable.

I fear this sentence falls back to the hyperbolic tone that plagued version
-10 of this document. I suggest something more along the lines of "...not
forcing changes to the way networks have historically been operated and
managed" or something similar.

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

§2.3.2:

>   The customer may need
>   call customer care to find out the reason, both an inconvenience
>   to the customer and additional overhead to the mobile network service
>   provider.

I believe this is false. Please remove this assertion or support it with a
citation.

To my knowledge, standard operating procedure for mobile networks (based on my
personal experience on two different post-paid US carriers and probably half a
dozen pre-paid non-US carriers) is that users are sent an SMS message
explaining the situation. I think the statement above overstates the
inconvenience to both users and operators, and consequently runs the risk of
causing protocol designers to evaluate the impact incorrectly.

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

§2.3.4:

>   Third parties use
>   the inserted information for analytics, customization, advertising,
>   to bill the customer, or to selectively allow or block content.

This is much improved over the previous formulation, but it leaves out a simple
factual statement that is highly relevant when designers are evaluating the
impact of encryption on this behavior. In fact, I would argue that it leaves
out the *most* notable use of these headers: cross-site user tracking. I
suggest amending the list to something like:

    Third parties use the inserted information for analytics, customization,
    advertising, cross-site tracking of users, to bill the customer, or to
    selectively allow or block content.

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

§3.3:

>   encryption approach described below.  In most cases, solution have
>   been identified to provide encryption while ensuring management

Nit: "...solutions have..."


---------------------------------------------------------------------------
§3.2.2 and §5.1:

Nit: s/SPAM/spam/g