Subject: Re: [Geopriv] IPv6 Address Option

From: "Glen Zorn" <[email-masked]>
Date: Mon, 28 Sep 2009 08:28:14 +0700

Bernard Aboba [mailto:[email-masked]]  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.