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

[Gorry Fairhurst <[e-mail]>]

See in-line...

On 26/01/2011 20:11, Fernando Gont wrote:
> Hi, Gorry,
>
> Thanks so much for your feedback. Should I resubmit as draft-ietf once I
> address these?
>
> Please find my comments inline...
>
> On 26/01/2011 04:38 p.m., Gorry Fairhurst wrote:
>> Abstract:
>>
>> I recommend you add more detail here, saying what documents are updated.
>
> Ok, will do.
>
>
>
>> 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?
>
> Should I put the whole sentence in past tense? i.e. "defined... which was"?
>
I'd suggest so.
>
>>
>> /for a long time/
>> - perhaps we should just say the year - i.e. 1995.
>
> Will do.
>
>
>
>> /   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.
>
> Well, the point is that other than the minor updates to RFC1812, this
> document formally deprecates the reaction to SQ by TCP -- right now,
> e.g. TCP is still required to slow down upon receipt of ICMP SQ.
>
> If others weigh in, and agree on that, I could s/deprecates reaction to
> ICMP Source Quench messages by transport protocols such as
> TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/.
>
Let's discuss that one on the list!
>
>
>> Section 3:
>>
>> /We hereby/
>> - Could we say "This document hereby"...
>
> Will do.
>
>
>
>> /message (type 4, code 0), which is /
>> - see note on intro.
>
> Ditto -- past tense for the whole thing?
>
>
>
>> /[RFC1812] notes that research suggests/.../and formally deprecates/
>> - 'noted', 'suggested', and 'deprecated'?
>
> Depending on what's your take for the other instances... but yes, I
> think that would sound good to me.
>
>
>
>> /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."
>
> The point is that this is a specific update to RFC 1122, which talks
> about hosts, not routers.
>
> Thoughts?
>
We could update router behaviour too, if TSVWG wants. It's a transport 
signal.
>
>
>> Section 6.:
>>
>> - My first thoughts are also that it is good to make this
>> "memo" historic (RFC1016). See what others think.
>
> So no changes here, right?
>
That's my "non-chair" position too :-)

> -- FWIW, what's in the current version of the I-D is what I've sensed as
> consensus as a result of the discussions on ICMP SQ on this mailing-list.
>
OK
>
>> References:
>>
>> - I'm not sure that [RFC4443] is normative. Please check.
>
> Yes, I think that in this case it could be informative. Will do.
>
>
>
>> - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a
>> normative reference?
>
I meant ECN, not 3136.

> I think "these are important to understand this document", which would
> make them "normative"...
>
Although you need to understand them, the changes you are making do not 
modify these documents, so I'd still say they are not normative - but we 
can handle later in LC.

> Thanks!
>
> Best regards,
 >
I'd suggest you do all the changes you feel confident with, and we can 
discuss any remaining issues on the list. Can you summarise any 
remaining points you recall?


Finally, with my "Chair" hat on:

You may upload the next version as a WG I-D.

Gorry