On Fri, 16 Feb 2007, Andrew Sullivan wrote:
> On Wed, Feb 14, 2007 at 10:52:45PM -0500, Dean Anderson wrote:
>
> > I asked this before and got no answer. RFC2119 itself gives some
> > guidance:
>
> I don't think that's exactly true. I pointed out that, as far as I
> know, this document is intended to be an informational document, which
> means that it will not specify any standards.
While this fact is true, this fact isn't relevant to the question posed.
On January 8, 2007, I posted a list of examples of published
informational RFCs that include this language. That demonstrates that
RFC2119 language is allowed in informational RFC's.
> I asked for advice (or dissent) from our colleagues on this list, and
> received nothing, so I assume that others agree. The relevant bits of
> [RFC2119] are ones you actually quote:
Silence is agreement? Perhaps silence means they agree with me. I take
silence to mean that no one claims to know the authoritative answer.
But the chairs did not respond, and it was their guidance I was
expecting.
> > "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
>
>
> > My purpose in using these terms is to limit behavior which has the
> > potential for causing harm.
>
> So far as I can see, you haven't demonstrated that the "harm" you are
> talking about is the same as the "harm" that 2119 is talking about.
Security vulnerabilities are included as harms that 2119 is talking
about. You haven't refuted the statements I proposed putting in the
Security Considerations section. I suggest you also review the thread
entitled "Tangible harm caused by in-addr-required ". Rather than repeat
that thread in its entirety, I think this comment by Kevin Darcy is
still quite pertinent:
At 10:01 PM 9/12/01, Kevin Darcy wrote:
>I oppose adoption/advancement of the draft. Not only are the security
>justifications null and void, I think they actually *detract* from the
>other justifications inasmuch as they promote/encourage bad security
>practices and/or risk creating a False Sense of Security.
> That is, you might think it a foolish thing to draw any conclusions
> from reverse tree data; that does not mean that others, with different
> experiences or situations, would in their cases reach the same
> conclusion.
Indeed, logic does mean that other rational persons would reach the same
logical conclusions. Mathematical logic doesn't change due to
experience or situation which are irrelevant to the assertions. The only
relevant issue here is that Administrator A has no authority over Site
B, and that doesn't change due to the experience or situation of
Administrator A.
This is exactly the distinction between rational and irrational. Others,
as I have recited, have proved that such conclusions aren't logically
grounded. There are no experiences or situations where security
conclusions can be logically drawn from the reverse mapping of another
site.
You haven't proved such conclusions are logically grounded in any
situation involving other sites. You haven't cited any flaws in the
logic. Your defense is to assert that one is _entitled_ to act
irrationally. One may be entitled, as a free person, to act
irrationally, but one is not entitled to describe irrational acts as
being rational in a professional document. Doing so makes the document
a fiction--a charade rather than truth.
> I believe the draft allows both cases to be considered.
Every case can be considered. However, the irrational cases have to be
described as being irrational, using terms that would imply or
specifically state the irrationality. You describe them as rational,
which is misleading and confusing.
I think your choice is to either drop them altogether (as Ed Lewis
suggested in 2003), or describe them accurately as being irrational and
unjustified by any facts or logic. I think history has shown you will
willfully refuse to do either of these alternatives. Including
misleading descriptions will lead to well-justified objections. Of
course, the third option is to drop the draft in favor of another draft.
I support that approach, and will shortly be submitting an alternate
document for consideration.
--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
