Subject: FW: ISSUE: Inappropriate usage of RFC 2119 key words

From: "Glen Zorn" <[email-masked]>
Date: Thu, 22 Oct 2009 16:37:18 +0700

-----Original Message-----
From: Glen Zorn [mailto:[email-masked]] 
Sent: Thursday, October 22, 2009 12:39 PM
To: [email-masked]'
Cc: [email-masked]'
Subject: ISSUE: Inappropriate usage of RFC 2119 key words

Description of issue:  Inappropriate usage of RFC 2119 key words
Submitter name: Glen Zorn

Submitter email address: [email-masked]

Date first submitted: 22 October 2009

Document: draft-ietf-radext-design-09

Comment type: T

Priority: S

Section: 2.1.1

Rationale/Explanation of issue:
Section 6 of RFC 2119 states:

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 retransmissions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

The section of the draft in question says:

   It is worth noting that since RADIUS only supports unsigned integers
   of 32 or 64 bits, attributes using signed integer data types or
   unsigned integer types of other sizes will require code changes, and
   SHOULD be avoided.

It is difficult to see how either harm or interoperability problems could
arise from correctly implemented code changes; indeed, this appears to be a
classic case of the use of RFC 2119 keywords to "try to impose a particular
method on implementors where the method is not required for
interoperability".

Requested change:
Since the only rationale offered for the prohibition is the spurious one of
avoiding code changes (something that is certainly implementation-specific),
the section should be removed altogether.

--
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: Alan DeKok <[email-masked]>
Date: Fri, 23 Oct 2009 07:56:57 +0200

> method on implementors where the method is not required for

  I welcome suggestions for how implementations can *meaningfully*
interoperate when they have different interpretations for an attribute.

  i.e. one defines an attribute to be "signed 24-bit integer counter,
little endian", and the other doesn't support that data type.

  None of the meanings of the novel integer type (e.g. counter) can be
used by the second implementation.  It can only treat the field as
"string of undistinguished octets".

  Therefore, they cannot be said to inter-operate according to the
definition of the attribute.

  The alternative is to interpret "inter-operate" as "sends / receives
opaque data without agreeing on the format, meaning, or processing of
that data".  If that is our definition of the word, then we can say that
DHCP inter-operates with RADIUS.  And the term loses all meaning.

> the section should be removed altogether.

  This issue should be rejected.

  RADIUS specifications define format, meaning, interpretations, and
processing requirements for attributes.  Two implementations that
disagree about an attribute can inter-operate at the RADIUS level by
exchanging RADIUS packets.  They cannot be said have interoperable
implementations of the attribute.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 23 Oct 2009 04:15:00 -0700

Glen Zorn said:

> method on implementers where the method is not required for
> interoperability".

The issue being described here is not one between RADIUS clients and
servers that implement the attribute, but rather between
a RADIUS client that implements the attribute and a RADIUS server
that does not support the attribute or the new type. 

If instead of using an unsigned 32 bit integer, an 8, 16 or 24 bit integer 
is used or a signed integer, then existing RADIUS servers will not be able 
to support the newly defined data type without a code change.  
While existing RADIUS servers could send the newly defined types as a 
String, this would force network administrators to enter the attributes in 
hex form.  This would be likely to cause errors in configuration, particularly
in the case of signed integers. 

However, an issue has been raised about whether RADIUS does in fact
support 64-bit integers, or whether the data types used in previous
attributes were either special types (e.g. Interface ID) or 64-bit
octet strings. 

If WG consensus is that RADIUS does not today support 64-bit
integers, the choices would be as follows:

1. Recommend the addition of the 64-bit integer data type to
implementations; 

2. Remove the reference to 64-bit integers in the above paragraph.

---

From: "Glen Zorn" <[email-masked]>
Date: Sat, 24 Oct 2009 20:08:59 +0700

> interoperate when they have different interpretations for an attribute.

What, if anything, do you imagine that has to do with my comment?

...

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Oct 2009 21:09:06 +0200

> Alan DeKok [mailto:[email-masked]] writes:
..
> What, if anything, do you imagine that has to do with my comment?

  It's a complex logic chain, explained in my previous message.

  The suggestion that specifications SHOULD re-use existing data types
means that implementations can re-use those data types for new
specifications.  Since the data types are already inter-operable, adding
new attributes of the same data type means a high likelihood of
inter-operability.

  Or... we give up on the idea of data types (as has been insinuated
here), and new specs do whatever they want.  Since the old
implementations don't know about those new data types, they won't
implement them, and the systems won't be inter-operable.

  And to repeat: Yes, they will be able to exchange RADIUS packets.  No,
they will not be able to agree on the format, meaning, interpretations,
and processing requirements for attributes.

  e.g. An implementation that doesn't support Message-Authenticator
cannot be meaningfully said to be interoperable with another one that
requires Message-Authenticator for EAP sessions.

  RADIUS has had attribute interoperability problems for over a decade.
 Why are there still questions about it?

  Alan DeKok.

---

From: "Glen Zorn" <[email-masked]>
Date: Sun, 25 Oct 2009 09:52:08 +0700

> here), 

Nothing is being insinuated: AFAICT, the only justification for most of the
prescriptions in the draft is that to so otherwise requires code changes in
some implementations.  My rather clear question was "What harm does a
correctly implemented code change have do to interoperability?"  I think
that the answer is obvious (none), which may explain your need to avoid
answering it at all costs ;-).

> and new specs do whatever they want.  Since the old

Without changes to code (or in a more reasonable system, to a (auxiliary)
dictionary).

> requires Message-Authenticator for EAP sessions.

Excellent example!  Section 3.1 of RFC 3579 says "the Message-Authenticator
attribute MUST be used to protect all Access-Request, Access-Challenge,
Access-Accept, and Access-Reject packets containing an EAP-Message
attribute".  So you seem to be saying that the fact that an implementation
that is compliant with RFC 3579 won't interoperate with one that isn't
compliant is, amazingly, a bug rather than a feature!

>   RADIUS has had attribute interoperability problems for over a decade.

If so, isn't the answer to require more detailed and specific attribute
definitions rather than attempting to homogenize everything (often
inappropriately, as I pointed out with the "integer64" concoction)?

...