[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tsvwg] draft-ietf-tsvwg-ecn-tunnel-04 - Editorial comments.



Gorry,

Thanks for yet another conscientious review. I agree with all your comments, but I have sometimes solved the problems you point out in different ways to those suggested.

I've prepared new text, but I'll wait until the moratorium on I-Ds lifts before posting. I still have to cut down the length of some of the Appendices as you point out.

One comment inline...

At 09:15 06/11/2009, Gorry Fairhurst wrote:


In addition, I have a few minor comments on rev -04 below:

---
Abstract:
- I found the sentence that starts below to be a little hard to read, rephrasing would be helpful:
"The new rules propagate the ECN field whether..."
---
Abstract:
- There seems some recommendations buried in section 7, if these are useful they may benefit from a mention in the abstract, such as:

"RFC 4774 permits the Diffserv codepoint (DSCP) [RFC2474] to
'switch in' alternative behaviours for marking the ECN field and requires new methods to consider the implications of tunnel encapsulated packets. Section 7 of this document extends the considerations in section 5.4 of RFC 4774."
<see comments email for discussion on Section 7>
---
Section 3:
- Typo, :
"inAppendix A"
   ^
---
Section 4:
NiT:
"If absolutely necessary..."
    ^^^^^^^^^^
- Perhaps it is strong enough to say "necessary"? or to move the NOT RECOMMENDED to the start of the paragraph to emphasise this.
---
Section 5.1:
- This section makes a claim that some codepoint..
"has never been used on the Internet"
- Rather than face a pedantic correction with a corner case, it may be safer just to say "is not known to have been used"...
- The same comment applies to 5.2.
---
Section 5.1:
"However, this is such a remote possibility that in general.. are NOT REQUIRED to implement." - The in "in general" part worries me. I think this should be expressed more clearly, since it contains some RFC 2119 keywords.
---
Section 5.3.2:
- This section reads better, but still repeats a little the covert channel theme.

I've suppressed the last mention in 5.3.1 but left 5.3.2 as is - I couldn't remove them without removing the intended sense.

---
Section 7:
- separate email.
---
Section 10:
- Para starting:
"The new rules...
- I think the last sentence would read better without a "But" at the start.
---
Section 12:
- This section could be removed as we move to a WGLC, or marked for later RFC-Ed removal.
---
Appendix B.1:
- Para starting:
"ECN at the IP layer..."
This para finishes with:
"Therefore the goals of IPsec and ECN are incompatible."
- I don't mind if this stays as it is written, but it does sound a kind of philosophical view, and seems odd to me.
---
Appendix D:
- I wonder if thus Appendix could be more concise? (e.g. it does repeat the covert channel case). Given this is now standards-action can we compact some of this?
---
Appendix E:
- This appendix was usefult to dervive the Spec. It now appears to repeat what is now said earlier, and I suspect much of this text is not needed here and would already be covered in [I-D.ietf-pcn-marking-behaviour] - which I now think is also scheduled for publication by PCN.
---




________________________________________________________________
Bob Briscoe, BT Innovate & Design