FW: ISSUE: Inappropriate use of RFC 2119 key word and misleading references

["Glen Zorn" <glenzorn@comcast.net>]

-----Original Message-----
From: Glen Zorn [mailto:gwz@net-zen.net] 
Sent: Thursday, October 22, 2009 5:32 PM
To: 'radiusext@ops.ietf.org'
Cc: 'radext-chairs@ietf.org'; 'iesg@ietf.org'; 'Alan DeKok';
gdweber@gmail.com
Subject: ISSUE: Inappropriate use of RFC 2119 key word and misleading
references

Description of issue:  Misleading references and invention of integer64 data
type

Submitter name: Glen Zorn

Submitter email address: gwz@net-zen.net

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:

The relevant section of the draft in question says:

   The integer64 type is used for the ARAP-
   Challenge-Response Attribute defined in [RFC2869] Section 5.15, and
   the Framed-Interface-Id Attribute defined in [RFC3162] Section 2.2.
   [RFC4675] Section 2.4 defines User-Priority-Table as 64-bits in
   length, but denotes it as type String.

   Given that attributes of type IPv6 address, IPv6 prefix, and
   integer64 are already in use, it is RECOMMENDED that RADIUS server
   implementations include support for these additional basic types, in
   addition to the types defined in [RFC2865].

This is what RFC 2869 says about the Value field of the
APAP-Challenge-Response Attribute:

   Value

      The Value field contains an 8 octet response to the dial-in
      client's challenge. The RADIUS server calculates this value by
      taking the dial-in client's challenge from the high order 8 octets
      of the ARAP-Password attribute and  performing DES encryption on
      this value with the authenticating user's password as the key. If
      the user's password is less than 8 octets in length, the password
      is padded at the end with NULL octets to a length of 8 before
      using it as a key.

If one takes the word "integer" as having its normal meaning it is obvious
that far from defining a 64-bit integer data type the only thing that the
ARAP-Challenge-Response attribute has in common with a 64-bit integer is its
length.  The same is true, in spades, for the Framed-Interface-Id Attribute:
the attribute was designed to carry the Interface-Identifier IPCOv6 option
(RFC 2472).  Glancing at section 4.1 of that document (it's too long to
quote here) makes it abundantly clear that the Interface-Id field of the
Framed-Interface-Id attribute was designed not as an integer but as a
specially formatted octet string.  Neither RFC 2869 nor RFC 3162 uses the
term "integer64", for good reason; interestingly, RFC 2869 _does_ define
data types, but "integer64" is not among the types defined (again, for good
reason).  Therefore, it is technically incorrect to claim that either of the
referenced RFCs defines an "integer64" data type.

Requested change:
Given that the "integer64" data type has never in fact been defined by any
RFC, either all mention of it must be removed from this draft or the text
changed to make clear that it is an invention of the author.




--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>