Re: [Technical Errata Reported] RFC3162 (1923)

[Alan DeKok <aland@deployingradius.com>]

Glen Zorn wrote:
>> RADEXT WG,
>>
>> Please advise on the Technical Errata below.
> 
> The idea that the formal data type (if any) of a field in a RADIUS attribute
> can be changed by changing the name of the field is so bizarre 

  That it could only have been invented by Glen.

> as to be
> almost unbelievable.  Even if it wasn't so incredibly BASIC, the idea is not
> supported by any explicit text in any RADIUS-related RFC.

  RFC 2865 defines "address" as "32 bit value, most significant octet
first.".

  RFC 3162 uses "address" to define a field as "The Address field is 16
octets.".

  The two statements disagree by the most naive reading of the
definitions.  The only way to claim that the RFC 3162 "Address" is
compatible with the RFC 2865 "Address" is to assert that "4 == 16".

  But, of course, that would be too obviously delusional.  So that isn't
the best way to "refute" the errata.  Instead, the best way is to
completely misconstrue the errata, and claim that the discussion is
about something else entirely!

  If you're trying to maintain a *sane* position, then a 16 octet
"address" field is obviously incompatible with the definition of a
4-octet address field.  The sane solution would be to:

a) create a *new* definition of "ipv6 address" that is different from
the 4-octet "address" field for IPv4 addresses,,

  or

b) use the RFC 2865 type "string" for something that doesn't meet the "4
octet" definition of the "address" field.

  My prediction is that Glen will claim that there is no conflict.  This
is as much as admitting that he believes "4 == 16".


  Alan DeKok.

--
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/>