Subject: draft-ietf-tsvwg-source-quench: SHOULD NOT vs. MUST NOT

From: Fernando Gont <[email-masked]>
Date: Wed, 22 Jun 2011 01:00:08 -0300

Folks,

During the Beijing IETF, and in a corridor meeting in Prague, Scott
Bradner noted that the source quench I-D should deprecate ICMP SQ with a
"MUST NOT" rather than a "SHOULD NOT".

Since this is the only remaining "issue" with this I-D, and sending this
note (CC'ing Scott), such that he has the opportunity to make his point,
and have the wg decide whether to leave the I-D as is (i.e., deprecating
ICMP SQ with "SHOULD NOT"s), or change the requirements language as
suggested by Scott.

Thanks!

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

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 22 Jun 2011 06:44:18 -0400

SHOULD-NOT is fine if you can imagine that someone would have a real reason
to send a SQ - if so it should be explained, if not please use MUST-NOT

from RFC 2119

4. SHOULD NOT   This phrase, or the phrase "NOT RECOMMENDED" mean that
   there may exist valid reasons in particular circumstances when the
   particular behavior is acceptable or even useful, but the full
   implications should be understood and the case carefully weighed
   before implementing any behavior described with this label.

Scott

---

From: Scott Brim <[email-masked]>
Date: Wed, 22 Jun 2011 08:54:55 -0400

For example, if you're allowing for existing implementations.

---

From: "Scott O. Bradner" <[email-masked]>
Date: Wed, 22 Jun 2011 09:20:04 -0400

if one wanted to be anal one could say that "new implementations MUST NOT...." but
I expect just saying MUST NOT wold be understood to apply to software created after
the RFC was published

Scott