On Tue, 13 Feb 2007, Ted Lemon wrote:
> This is a DNSOP draft, so I don't think we *can* use MUST NOT.
I asked this before and got no answer. RFC2119 itself gives some
guidance:
"6. Guidance in the use of these Imperatives
"Imperatives of the type defined in this memo must be used with care
and sparingly. In particular, they MUST only be used where it is
actually required for interoperation or to limit behavior which has
potential for causing harm (e.g., limiting retransmisssions) For
example, they must not be used to try to impose a particular method
on implementors where the method is not required for
interoperability.
"7. Security Considerations
"These terms are frequently used to specify behavior with security
implications. The effects on security of not implementing a MUST or
SHOULD, or doing something the specification says MUST NOT or SHOULD
NOT be done may be very subtle. Document authors should take the time
to elaborate the security implications of not following
recommendations or requirements as most implementors will not have
had the benefit of the experience and discussion that produced the
specification."
My purpose in using these terms is to limit behavior which has the
potential for causing harm. Further, this text relates to security
issues. In the draft I'm writing, these three paragraphs are in the
"Security Considerations" section.
> My main problem with this whole conversation is that I think the
> draft already says this - it just doesn't say "MUST NOT" because it
> *can't*.
I think your are not looking hard enough for ambiguous language, and
considering how that language might be used in the future. I'd ask that
you review our offline conversation between 3/28/2005 and 4/2/2005, if
you have it. Similar issues apply here as I drew your attention to then.
> If you feel the wording is too weak, and the editor is willing to
> incorporate your wording, minus the MUST NOTs, I have no objection to
> that.
And do you agre with the present wording if it is permissible to include
the RFC2119 terms?
I do feel the wording is way too weak. Basically, everyone should
consider that if this document is approved as is, and Administrator A
blocks your email because, e.g., it has the word "dialup" in the reverse
mapping entry, then Administrator A will refer to this document as proof
of the reasonableness of his actions. Likewise, if the reverse mapping
doesn't exist, or doesn't "match" the forward mapping, etc, they will
also point to this document as justification for their behavior. One
will be left trying to prove that the ambiguous statements don't mean
what Administrator A asserts they mean, a position that is very
difficult.
Consider the recent exchange between Robert Story and Ted Lemon,
supposing after this draft is approved. As an exercise, try to show
that Administrator A, acting as Story described, has acted unreasonably
(as Lemon asserted) when Administrator A can quote the text of this
draft in his defense.
--Dean
--
Av8 Internet Prepared to pay a premium for better service?
www.av8.net faster, more reliable, better service
617 344 9000
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www1.ietf.org/mailman/listinfo/dnsop
