Bernard Aboba [mailto:bernard_aboba@hotmail.com] writes: WRT this document,
section 6 of RFC 2119 (sorry about the typo above) seems relevant: 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. [BA]
Are there specific uses of normative language in the document that you believe
are inappropriate? With the caveat that it’s been some time since I read the
draft, based upon my last review I’d have to say virtually all the uses
of RFC 2119 requirements language in the document are problematic. I plan
to go through the note in depth again this week. There is a lot of
nonsense in it which I had mistakenly considered innocuous blather, easily
ignored (they are “guidelines”, after all). However, at
some point during the final discussions before the publication of RFC 5580 I realized
that the document, far from being a set of harmless suggestions on style, was in
fact a club to be used by pompous asses to keep people from getting real work
done. If you recall, my major arguments against the attributes defined in
5580 were based upon non-compliance w/the Design Guidelines document (yes, that
would make me one of those pompous asses & I would like to take this
opportunity to apologize to the authors of RFC 5580, the geopriv WG and the
IESG for my misguided behavior). In fact, though, there was nothing
technically wrong with the geopriv attributes: they would have worked just
fine, thank you. Their only sin was deviation from a set of rules based
upon a highly suspect historical characterization of RADIUS development and a
simplistic (if not downright primitive processing model). At any rate,
removing the RFC 2119 language from the draft would go a long way toward making
the document truly harmless. |