Subject: Comments on draft-mm-wg-effect-encrypt rev 12

From: G Fairhurst <[email-masked]>
Date: Mon, 27 Nov 2017 15:29:52 +0100

Thank you for revising this draft I have read in detail several previous 
versions of this ID. I thought thart the much earlier versions were more 
annecdotal, but in the latest version the writing style if much more 
considered and probably better suits the needs of the IETF in 
documenting this space. I believe the current version is nearly ready to 
publish.

Specific comments (one major):

Section 1.2 (para 5)
- space needed before [RFC3550].
- /the/ needed before RTP/RTCP.

Section 1.2 (final para)
- I agree with what is written, but equally I would agree with the 
converse - and I think it is worth considering also stating that 
encryption has benefit to some application providers have noted benefits 
in avoiding out-dated in-network enhancement.

Section 2.1.3 (para 1)
-/This technique is sometimes used with clear text or encrypted sessions/
At least to me, I didn't really understand that sentence and what it was 
trying to say.

Section 3.2.1 (bullet 2)
- /causes of excess response time/
Should this be excessive?

Section 3.2.1 (final para)
- /Until application logging is sufficient ... will remain a gap/
I'm not quite sure what this intended to say: do you think loigs will 
provide equivalent function eventually? or is it better to say at 
present they do not provide that equivalent function?

Section 3.3.2.1
- Expand Data at Rest in the title?

Section 3.3.3.1
- There is a single sentence para at the start, that sort of intro 
sentence does not seem to exist in other subsections of the document?

Section 6.2
- /Soltuions/ spelling? (there are other spelling mistakes that would be 
caught by a spell checker).

Section 7.2 (bullet c).
- Here I have onetechnical comment;

I am really not sure what the implied issue is with DSCP-marking. I 
suspect that the text may be indicating that a network node can not use 
a Multi-Field (MF) classifier to assert a DSCP for traffic that is 
classified into a flow group with specific QoS properties... but the 
current text seems misleading. Because actually if the traffic *IS* 
DSCP-marked, and the network honours the DSCPs being used, then 
DSCP-based QoS *can* be used with encypted traffic.

And I think it would be super good to say this, because I recall old 
IPsec "guidance" that tried to assert traffic should not reveal a DSCP. 
This is of course a security/performance trade-off.

Section 7.3 (bullet 2).
- may be worth noting that QCI is a sub-IP property, just to avoid 
potential misunderstandings.

Best wishes,

Gorry