Date: Wed, 13 Aug 2008 13:13:46 -0500
From: "Spencer Dawkins" <spencer(_at_)wonderhamster(_dot_)org>
Message-ID:
<0ed001c8fd70$55714430$ad600240(_at_)china(_dot_)huawei(_dot_)com>
| I'm actually OK with the process that Dave is not OK with, because I'm
| assuming that "public vetting" can also be retroactive - as long as the
| IESG announces rules publicly,
I'm not.
The big difference is what consensus is needed to achieve what.
In the cases of even mildly controversial changes, and isn't
everything, the question is whether it requires (rough) consensus
to make the change, or requires (rough) consensus to overturn the
change.
Personally, I believe we need to achieve some form of agreement
before any changes, and not fall into the trap of: "it's done,
and some (enough) people believe it is OK, so there's no consensus
to not do it."
For what it's worth, on the issue that has been under discussion,
I see no harm at all in having documents list IPR claims they're
aware of, so long as they don't pretend to claim that those are
the only possible IPR claims. For example, in the early 90's,
it would have been entirely reasonable for a doc proposing use of
RSA public key technology to note the patent status, in the doc.
Requiring that such information be only on the web page is just
plain absurd.
So, for example, in this case, I wouldn't like anything to be
pretending to say that IPR claims are not allowed in docs, unless
we first achieve a consensus doc that says that. Similarly
no claims that only the domain names in 2606 can be (even just
"usually" used as example in docs, unless we have a consensus doc
that says that.)
I have no problem with pointing out things that are common (or even
just seen more than once) errors, that no-one would rationally ever
do deliberately (like using ABNF, or anything else, and failing to
reference its definition) - that is, helping people remember to
check for the things that are easy to overlook.
But no new rules, for everything that isn't just noise, you need to
be able to cite the precise text in some standards track RFC, or BCP
that justifies exactly what you're planning on requiring. No matter
how rational you, or anyone, believes the proposed rule is.
If that doesn't exist, it needs to be made to happen, first.
kre
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf