Re: Summary of proposed changes to draft-gont-tsvwg-source-quench

["DeSimone, Antonio" <[e-mail]>]

On 12/1/10 4:56 PM, "Fernando Gont" <[e-mail]> wrote:

Fernando,

Looks good.

> Please respond to each of these:
> 
> 1) Do *not* update the "SHOULD NOT generate ICMP SQ" in RFC 1812 to
> "MUST NOT generate ICMP SQ".

agree--consenting implementations and all that...

> 2) Update the text in RFC 1812 that states "A router MAY ignore any ICMP
> Source Quench messages it receives".
> 
> The resulting text would s/MAY/SHOULD/. This would align the
> requirements for routers with the requirements for hosts (of ignoring
> ICMP SQs)

agree

> 3) Update the text in RFC 1122 that states "If a Source Quench message
> is received, the IP layer MUST report it to the transport layer (or ICMP
> processing)."
> 
> The resulting text would read: "If a Source Quench message is received,
> the IP layer MAY silently discard it.

agree

> 4) Update the security considerations section noting that most host
> implementation currently ignore ICMP SQ (as noted in RFC 5927), and
> mention that they could be filtered at firewalls if deemed necessary (no
> normative language here, though)

agree

> 5) Have this document obsolete RFC 1016 (Prue, W., and J. Postel, "The
> Source Quench Introduced Delay (SQuID)")

It's not a big deal either way, but I'd just leave RFC1016 out of it.  It's
just, as it says, a crazy idea.

I think I made the comment before that some of this is academic.  In that
sense I agree with Fred's opinion that much of this is not likely to affect
real implementations.  However, if we're going to produce an update I think
we should be a complete as practical, especially if there are MUST
statements in standards related to SQ--that's why I brought up 1122.  For
better or for worse, there are people who take a "checklist" approach to RFC
compliance.  Actually, almost never for better :).