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

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 26 Jan 2011 19:38:31 +0000

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?

---

From: Fernando Gont <[email-masked]>
Date: Wed, 26 Jan 2011 17:11:13 -0300

Hi, Gorry,

Thanks so much for your feedback. Should I resubmit as draft-ietf once I
address these?

Please find my comments inline...

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

Ok, will do.

> - change to "was", since we now declare this as historic?

Should I put the whole sentence in past tense? i.e. "defined... which was"?

> - perhaps we should just say the year - i.e. 1995.

Will do.

> effectively does this, including endpoints that do not constitute

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/.

> - Could we say "This document hereby"...

Will do.

> /message (type 4, code 0), which is /

Ditto -- past tense for the whole thing?

> - 'noted', 'suggested', and 'deprecated'?

Depending on what's your take for the other instances... but yes, I
think that would sound good to me.

> 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?

> "memo" historic (RFC1016). See what others think.

So no changes here, right?

-- 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.

> - 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

I think "these are important to understand this document", which would
make them "normative"...

Thanks!

Best regards,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 26 Jan 2011 20:58:29 +0000

See in-line...

> Should I put the whole sentence in past tense? i.e. "defined... which was"?
I'd suggest so.
> TCP/deprecates the use of ICMP Source Quench messages by all IPv4 nodes/.
Let's discuss that one on the list!
> about hosts, not routers.
We could update router behaviour too, if TSVWG wants. It's a transport 
signal.
> So no changes here, right?
That's my "non-chair" position too :-)

> consensus as a result of the discussions on ICMP SQ on this mailing-list.
OK
>> - Neither RFC 5681 nor RFC3136 mention SQ - do these have to be a
I meant ECN, not 3136.

> I think "these are important to understand this document", which would
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.

> 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

---

From: <[email-masked]>
Date: Wed, 26 Jan 2011 19:07:01 -0500

> We could update router behaviour too, if TSVWG wants. It's a transport

I strongly suggest doing this once and deprecating Source Quench everywhere.
If that means updating additional RFCs, I have no problem with doing so.

Thanks,
--David

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Gorry Fairhurst
> Sent: Wednesday, January 26, 2011 3:58 PM
> To: Fernando Gont
> Cc: tsvwg list
> Subject: Re: Source Quench NiTs : (draft-gont-tsvwg-source-quench-01)
> 
> See in-line...
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 27 Jan 2011 10:41:18 +0200

> If that means updating additional RFCs, I have no problem with doing so.

+1

It probably means that we need to joint last-call this with INT and RTG, but that is not a problem.

Lars