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