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

[Kathleen Moriarty <[e-mail]>]

Hi Mirja,

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

On Fri, Feb 2, 2018 at 10:19 AM, Kathleen Moriarty
<[e-mail]> wrote:
> 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...?

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

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

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

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.

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

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

>>
>> 5) sec 3 rather describes how encryption is already used and doesn't not really
>> 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.

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

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

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

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.

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

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



-- 

Best regards,
Kathleen