[OPSAWG] Mirja Kühlewind's No Objection on draft-mm-wg-effect-encrypt-17: (with COMMENT)

[Mirja Kühlewind <[e-mail]>]

Mirja Kühlewind 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:
----------------------------------------------------------------------

Really thanks a lot for all the work on this document! I changed my position
from discuss to no objection with these edits now because I think there are
still things that could be improved to make the document more useful. However,
I also think that it is important to publish this document soonish and I don't
think any additional delay would help the message significantly.

-------------------------------
Old comment for the record:
-------------------------------

I would be a 'Yes' because I think this document is very valuable, however, I
think it could be structured better to provide more value. The document is
rather long and has some redundancy due to the structure: while sections 2.-4.
are split based on the type of network operator, sections 5. and 6. are split
based on the protocol layer. Further I think section 2 could be further
extended because there are more cases to cover, also see (section 3 of)
https://tools.ietf.org/html/draft-dolson-plus-middlebox-benefits-03. See for
more concrete and mostly editorial comments below:

1) sec 2.1.1: "The definition of a flow will be based on a
   combination of header fields, often as many as five for 5-tuple flows
  (including addresses and ports for source and destination, and one
   additional field such as the DSCP or other priority marking)."
Usually the 5th field is the protocol number; I'm not aware of any load
balancers that look at DSCP...?

2) sec 2.1.4 seems to cover two different cases: caching and differential
treatment

3) sec 2.1.6. should probably be called "Content Filtering" and "Mobility
Middlebox Content Filtering" should be an own subsection, as parental filtering
is not specific to mobile networks.

4) I don't really understand why sec 2.1.7 "Access and Policy Enforcement" is a
subsection of 2.1 "Middlebox Monitoring". Was that on purpose or an error?
Actually I don't really understand the structure of section 2 at all. What's
the difference between 2.1 and 2.2? I would group section 2.1.1, 2.1.2, and
2.1.3 under Traffic Monitoring and move all other subsections of 2.1 one level
up...

5) sec 3 rather describes how encryption is already used and doesn't not really
discuss any effects of increased use of encryption.

6) there is quite some overlap between section 2 and 4.1.3. as the problems on
monitoring/troubleshoot are the same for enterprise network and other networks;
the only difference is that in enterprises TLS interception may be acceptable
while it's not for network operators. However, it would still be good to better
align these sections.

7) section 6 only describes with information is visible but not how and if this
information is used and what would happen if this information would go away.

8) section 7 should be integrated in the introduction because it sets the
context for this document and it's not needed to have read the rest of the
document to understand this section.