Subject: Comments on draft-ietf-tsvwg-byte-pkt-congest-04

From: Gorry Fairhurst <[email-masked]>
Date: Mon, 28 Mar 2011 17:34:38 +0200

draft-ietf-tsvwg-byte-pkt-congest-04

I enclose a review of the above draft.

This draft appears to tackle an important issue and makes clear
recommendations. I like the way these have been focussed into one
specific section. I think though there is work to be done to finalise
the text.

The document is proposed as Informational. The document's
recommendations impact other IETF working groups, notably TCPM. The
recommendations also expand on the usage of a number of other IETF
specification. A decision needs to be taken as to whether these
constitute actual document Updates to RFCs.

Best wishes,

Gorry

---

S 2.1

S 2.2 point 2
/it is strongly RECOMMENDED that it SHOULD be/
- I am not sure what strongly RECOMMENDED means in combination with
SHOULD. Would /SHOULD/ be sufficient?

S 2.3 point 2
/, this should be
        done by modifying TCP (Section 4.2.3), not network equipment./
- Is this a requirement, should it be /SHOULD/?

S 2.4 para 2
- This section seems to omit any RFC2119 requirement, please consider
what is required.

S 3.1
- This appears to conclude with a statement recommending the direction
of work within the TCPM working group. I don't personally see an issue
with this if TSVWG agrees, but is this conclusion also OK for the TCPM WG?

S 4.2.5
- I am little concerned that the IETF document will two specific
vendor's response to personal equerries without a reference. In this
case, I'm not sure that para 1 adds important facts and suggest this is
removed.

S 4.2.5
/Turning to our more formal survey/
- Was this survey performed by TSVWG or by the authors?
- I think the survey adds value, but I would much prefer to see this as
an appendix.

S 4.2.5
Para starting /Finally,/
- This para appears to be restatement. I would much prefer this to be
deleted and see all RFC 2119 recommendations in section 2.

S 5.2
- I would like to discuss the need for this section, and whether this
could be omitted.

Conclusion
- The current conclusion specifically delegates an issue to ICCRG on the
final line. I don't think this is strictly necessary. A better phrase
may be /ICCRG is currently chartered to work on these issues./

S Appendix A
- I would like to discuss the need for this section, and whether this
could be omitted.

Appendix B
- This describes MTU as a parameter. I do not understand this: It seems
that what actually matters is the packet size being used, not the
pre-configured maximum for a particular interface.

Editorial comments sent separately.