Source Quench NiTs : (draft-gont-tsvwg-source-quench-01)

[Gorry Fairhurst <[e-mail]>]

As a TSVWG list member, I enclose some comments on this draft to help 
prepare draft-ietf-tsvwg-source-quench-00.

Best wishes,

Gorry

-----

Abstract:

I recommend you add more detail here, saying what documents are updated.

Introduction:

/The ICMP specification [RFC0792] defines the ICMPv4 Source Quench
    message (type 4, code 0), which is /
                                    ^^
- change to "was", since we now declare this as historic?

/for a long time/
- perhaps we should just say the year - i.e. 1995.

/   This document formally deprecates reaction to ICMP Source Quench
    messages by transport protocols such as TCP./
- Should we consider deprecating it for all IPv4 nodes? I think it 
effectively does this, including endpoints that do not constitute 
transports.

Section 3:

/We hereby/
- Could we say "This document hereby"...

/message (type 4, code 0), which is /
- see note on intro.

/[RFC1812] notes that research suggests/.../and formally deprecates/
- 'noted', 'suggested', and 'deprecated'?

/If Source Quench message is received,/
    ^
- insert 'a'.

/the IP layer MAY silently discard it./
- I support Fred Baker's comment, in "IMHO, any IP system SHOULD ignore
a source quench that it receives."

Section 6.:

- My first thoughts are also that it is good to make this
"memo" historic (RFC1016). See what others think.

References:

- I'm not sure that [RFC4443] is normative. Please check.

- Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a
normative reference?