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

From: Mirja Kühlewind <[email-masked]>
Date: Fri, 02 Feb 2018 06:30:52 -0800

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.

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 2 Feb 2018 10:19:09 -0500

> https://datatracker.ietf.org/doc/draft-mm-wg-effect-encrypt/

Thanks, Mirja.  I agree.  We were hesitant to change the text more
after the extensive IESG round of comments since we wanted to keep it
close to what people agreed on so this wouldn't take too long to get
out if modifications caused problems.

Best regards,
Kathleen

-- 

Best regards,
Kathleen

---

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Feb 2018 22:02:55 -0500

Hi Mirja,

Now back to your comments.  Thanks again for your assistance with
recommendations to reshape section 2 and other sections.

> out if modifications caused problems.

This update was made previously as DSCP no longer appears in the document.

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

This has been changed, differential treatment is in section 2.2.2 and
caching in 2.2.5.

>> is not specific to mobile networks.

This change appears to have been made already.  This is now section
2.3.1 and there's only one mention of mobile content filtering, which
reads to me that this particular description could be any
network-based content filtering solution, so I'll make that adjustment
too.  Here's the change adding the second sentence:

    In a mobile network content filtering usually occurs in the core network.
    With other networks, content filtering could occur in the core
network or at the edge.

>> 2.1.3 under Traffic Monitoring and move all other subsections of 2.1 one level

This has all been changed in a previous version, some with your guidance.

>> discuss any effects of increased use of encryption.

Section 3.2.1 includes some examples where they are still working
through the 'impact'.  The other sections are examples of where this
has already been worked through, so a positive in how you can go
forward managing encrypted networks.  Storage providers, for instance,
increased logging and reporting capabilities to ensure customers could
make this customer requested shift.

>> while it's not for network operators. However, it would still be good to better

We'll take a look at this, it's just a little difficult to merge. Thanks.

>> information is used and what would happen if this information would go away.

Section 6.2 and 6.3 go into this a bit more now with specifics on TLS
1.3 and expected changes with adopted drafts.

>> document to understand this section.

I'm wondering if this is an old comment since section 7 has been
reworked to only include the old 7.1.4?

Thanks again for your additional suggestions.

-- 

Best regards,
Kathleen