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

[Kathleen Moriarty <[e-mail]>]

On Fri, Feb 2, 2018 at 9:30 AM, Mirja Kühlewind <[e-mail]> wrote:
> 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.

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

>
> -------------------------------
> 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.
>
>



-- 

Best regards,
Kathleen