Subject: Re: IPv6 Address Option

From: Bernard Aboba <[email-masked]>
Date: Sat, 26 Sep 2009 23:41:19 -0700

>"New attributes SHOULD NOT use this tagging method...".  Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that described in RFC 2868.  So does the Design Guidelines advice even apply here?  Perhaps the Design Guidelilnes document should be more clear about exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT applies to.

---

From: Alan DeKok <[email-masked]>
Date: Sun, 27 Sep 2009 09:14:25 +0200

Bernard Aboba wrote:
> The tagging scheme in draft-lourdelet does not have the same flaws as
> that described in RFC 2868.  So does the Design Guidelines advice even
> apply here?

  The draft-lourdelet document defines a new data type.  8-bit tag,
followed by 32-bit integer.  While this is arguably better than the RFC
2868 form, it still is a new data type.  And the document discourages
new data types.

  As with most protocol design, there is room for an intelligent
application of checks and balances.  The issues associated with defining
a new data type should be weighed against the issues associated with
re-using a deprecated data type.

  An application of intelligence is suggested.  A thoughtless
application of the guidelines is not appropriate, as is a thoughtless
rejection of it.  I will note that the *only* "MUST" text in the
document is:

   1) provisioning of new services MUST be done in the IETF

   2) service provisioning MUST NOT be done in Access-Reject.

  All other "MUST" text in the documents are quotes from other RFCs.

  Hence, the suggestions of the guidelines documents are SHOULD, SHOULD
NOT, etc.  A reviewer following the guidelines document is perfectly
free to *not* follow its suggestions, if he believes that doing so would
be worse than the alternatives.

  Maybe the document needs to say:

   In order to meet these objectives, this document needs to cover not
   only the science of attribute design, but also the art.  As a result,
   in addition to covering the most frequently encountered issues, this
   document attempts to provide some of the considerations motivating
   the guidelines.  Reviewers are expected to weigh the cost and
   benefits of following or ignoring the guidelines, as nearly all
   suggestions here are of the form "SHOULD" or "SHOULD NOT".  The
   intent is for the guidelines to help authors create better documents.
   This intent means that reviewers can choose to ignore some of the
   recommendations herein.  When this is done, their review MUST be
   accompanied by an explanation as to why the guidelines were not
   followed, and why following the guidelines would have resulted in
   a worse architecture.

>  Perhaps the Design Guidelilnes document should be more
> clear about exactly what the flaws were in the RFC 2868 scheme that the
> SHOULD NOT applies to. 

  Or, it could say that the tagging mechanism MAY be used when none of
the above limitations apply.

  Alan DeKok.

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 27 Sep 2009 14:36:16 +0700

Bernard Aboba  <mailto:[mailto://[email-masked]%5d>

>"New attributes SHOULD NOT use this tagging method...". Which is it?

The tagging scheme in draft-lourdelet does not have the same flaws as that
described in RFC 2868.  So does the Design Guidelines advice even apply
here?  Perhaps the Design Guidelilnes document should be more clear about
exactly what the flaws were in the RFC 2868 scheme that the SHOULD NOT
applies to.  

Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 00:46:36 -0700

> 2868 form, it still is a new data type.  And the document discourages

OK.  So the issue is not the use of RFC 2868 tags. 

>    followed, and why following the guidelines would have resulted in

Personally, I don't think this text is necessary; RFC 2119 defines the
meaning of SHOULD. 

> the above limitations apply.

Or, it might describe how a single octet tagging scheme might avoid the
problems of RFC 2868.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 00:48:38 -0700

Somebody should note (might
as well be me) that since the 1) the document is not a protocol specification
& 2) the intended status is BCP, the use of RFC 2118 keywords is inappropriate
to begin with.

[BA] Where does it say that BCPs can't contain normative keywords?  Lots of other BCPs seem to use them.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 27 Sep 2009 15:57:45 +0700

Bernard Aboba [mailto:[email-masked]] writes:
Somebody should note (might as well be me) that since the 1) the document is
not a protocol specification & 2) the intended status is BCP, the use of RFC
2118 keywords is inappropriate to begin with.

[BA] Where does it say that BCPs can't contain normative keywords?  Lots of
other BCPs seem to use them. 

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.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 27 Sep 2009 08:58:00 -0700

WRT this document, section 6 of RFC 2119 (sorry about the typo
above) seems relevant:

   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?

---

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

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.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2009 08:05:57 +0200

Glen Zorn wrote:
> Somebody should note (might as well be me) that since the 1) the
> document is not a protocol specification & 2) the intended status is
> BCP, the use of RFC 2118 keywords is inappropriate to begin with.

  Here's a list of RFCs that:

    (a) are Status: BCP
    (b) have the word "guidelines" in their title
    (c) use RFC 2119 keywords
    (d) are relatively recent

	http://tools.ietf.org/html/rfc3470

	http://tools.ietf.org/html/rfc3552

	http://tools.ietf.org/html/rfc4107

	http://tools.ietf.org/html/rfc4181

	http://tools.ietf.org/html/rfc4395

	http://tools.ietf.org/html/rfc5226

	http://tools.ietf.org/html/rfc5405

	http://tools.ietf.org/html/rfc5625

  That's 8 documents in about 5 minutes of work.  I think your claim has
been proven false.  The design guidelines document is following the
current practice of the IETF.  The only way to disprove this is outright
denial.

  Alan DeKok.

---

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

> current practice of the IETF.  The only way to disprove this is

Speaking of which, perhaps you would like to address section 6 of RFC 2119.
Glad you've decided to do a little research once in a while, BTW ;-): you
have provided a treasure trove of material for RFC Errata.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2009 09:38:38 +0200

> Speaking of which, perhaps you would like to address section 6 of RFC 2119.

  You haven't pointed out which portions of the design guidelines
document violate that section.  You have had multiple opportunities to
do so.

  I don't see why I should address non-existent issues.

  Alan DeKok.

---

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

> document violate that section.  You have had multiple opportunities to

See attachment.

>   I don't see why I should address non-existent issues.

Subject: RE: IPv6 Address Option
From: "Glen Zorn" <[email-masked]>
To: "'Bernard Aboba'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Date: Mon, 28 Sep 2009 08:28:14 +0700

   interoperability.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 28 Sep 2009 11:30:58 +0200

>> document violate that section.  You have had multiple opportunities to

  I don't count "virtually all of the document is wrong" as a useful
comment.  It doesn't propose anything that can be done to the document
to correct the alleged flaws.

  Alan DeKok.