Subject: FW: [Technical Errata Reported] RFC3162 (1923)

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 25 Oct 2009 11:27:28 +0100

RADEXT WG,

Please advise on the Technical Errata below. 

Thanks and Regards,

Dan

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
RFC Errata System
Sent: Thursday, October 22, 2009 3:19 PM
To: [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [Technical Errata Reported] RFC3162 (1923)

The following errata report has been submitted for RFC3162, "RADIUS and
IPv6".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3162&eid=1923

--------------------------------------
Type: Technical
Reported by: Alan DeKok <[email-masked]>

Section: 2.1

Original Text
-------------
   Address

      The Address field is 16 octets.

Corrected Text
--------------
String

  The field is 16 octets

Notes
-----
As Glen notes in:

http://ops.ietf.org/lists/radiusext/2009/msg00540.html

Using "ipv6 address" for a data type in RADIUS is wrong.

RFC 3162 (among others Glen wrote) contradict his current position.
Those documents use data types for the "value" field of RADIUS
attributes that have not been defined in RFC 2865.  As such, they should
either:

a) make it clear that they define a new data type, and be marked as
"Updates: 2865"

  or

b) use the data types in RFC 2865.

  Or even better, maintain an internally consistent set of beliefs, and
leave RFC 3162 alone.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please use
"Reply All" to discuss whether it should be verified or rejected. When a
decision is reached, the verifying party (IESG) can log in to change the
status and edit the report, if necessary. 

--------------------------------------
RFC3162 (draft-aboba-radius-ipv6-10)
--------------------------------------
Title               : RADIUS and IPv6
Publication Date    : August 2001
Author(s)           : B. Aboba, G. Zorn, D. Mitton
Category            : PROPOSED STANDARD
Source              : Legacy
Area                : Legacy
Stream              : IETF
Verifying Party     : IESG

--
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, 25 Oct 2009 21:50:59 +0700

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

...

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Oct 2009 13:49:59 -0700

Speaking for myself without my chair hat on, I am not sympathetic to this errata. 

RFC 3162 uses the type "Address" in a context that makes it fairly clear that it is talking about a new data type for IPv6 addresses, rather than the existing IPv4 address type defined in RFC 2865.  

Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data types, so I don't believe that this was required in RFC 3162 or any other document. 

There are other instances in RFC 3162 we have been discussing, where the data type used may not be clear (such as Interface-ID), but this specific instance doesn't seem ambiguous. 

> Subject: FW: [Technical Errata Reported] RFC3162 (1923)
> Date: Sun, 25 Oct 2009 11:27:28 +0100
> From: [email-masked]
> To: [email-masked]
> 
> RADEXT WG,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Oct 2009 09:28:40 +0100

Based on the opinions expressed by you and Glen, do I hear a consensus
to reject this errata? 
 
Dan

________________________________

	From: Bernard Aboba [mailto:[email-masked]] 
	Sent: Sunday, October 25, 2009 10:50 PM
	To: Romascanu, Dan (Dan); [email-masked]
	Subject: RE: [Technical Errata Reported] RFC3162 (1923)

	Speaking for myself without my chair hat on, I am not
sympathetic to this errata. 
	
	RFC 3162 uses the type "Address" in a context that makes it
fairly clear that it is talking about a new data type for IPv6
addresses, rather than the existing IPv4 address type defined in RFC
2865.  
	
	Previous RADIUS RFCs did not "Update: RFC 2865" when introducing
new data types, so I don't believe that this was required in RFC 3162 or
any other document. 
	
	There are other instances in RFC 3162 we have been discussing,
where the data type used may not be clear (such as Interface-ID), but
this specific instance doesn't seem ambiguous.

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Oct 2009 19:56:40 +0700

Dan Romascanu  <mailto:[mailto://[email-masked]%5d>
[mailto://[email-masked]] writes:

Based on the opinions expressed by you and Glen, do I hear a consensus to
reject this errata? 

I think that Bernard & I agree that it should be rejected, though for
different reasons.  Whether that makes a consensus is a matter of opinion, I
suppose.

Dan

.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 26 Oct 2009 14:05:44 +0100

Of course. 
 
The reasons will be listed in the motivation. If somebody disagrees with
the reasons exposed I expect comments on this. 
 
Dan

	From: Glen Zorn [mailto:[email-masked]] 
	Sent: Monday, October 26, 2009 2:57 PM
	To: Romascanu, Dan (Dan)
	Cc: 'Bernard Aboba'; [email-masked]
	Subject: RE: [Technical Errata Reported] RFC3162 (1923)

	Dan Romascanu [mailto://[email-masked]]
<mailto:[mailto://[email-masked]%5d>  writes:

	Based on the opinions expressed by you and Glen, do I hear a
consensus to reject this errata? 

	I think that Bernard & I agree that it should be rejected,
though for different reasons.  Whether that makes a consensus is a
matter of opinion, I suppose.

	Dan

		...

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 26 Oct 2009 20:11:11 +0700

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

Speaking for myself without my chair hat on, I am not sympathetic to this
errata. 

RFC 3162 uses the type "Address" in a context that makes it fairly clear
that it is talking about a new data type for IPv6 addresses, rather than the
existing IPv4 address type defined in RFC 2865.  
OK, just to satisfy my own mind, were you guys aware at the time that we
were "defining a new RADIUS data type"?  I know that I wasn't: I just
thought that, gosh, "Address" is a good thing to call a field that holds an
address.  I don't recall any conversation about it amongst us (or in the WG)
at the time; was it just so obvious that it didn't even bear mention?  Put
another way, am I the only moron on the planet that was completely unaware
of the "Da Vinci Code" aspects of the RADIUS RFCs (esp. 2865)?
Previous RADIUS RFCs did not "Update: RFC 2865" when introducing new data
types, so I don't believe that this was required in RFC 3162 or any other
document. 
Actually, had I understood that we were, in fact, altering the set of RADIUS
data types at the time I probably would have suggested updating 2865.
There are other instances in RFC 3162 we have been discussing, where the
data type used may not be clear (such as Interface-ID), but this specific
instance doesn't seem ambiguous. 
.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Oct 2009 16:47:15 -0400

> Speaking for myself without my chair hat on, I am not sympathetic to

  Neither am I, quite frankly.

  But it gives Glen a choice that is difficult to make:

a) fix RFC 3162 to use the RFC 2865 data types

  or

b) agree that IPv6 data types were defined by him in RADIUS,
   and that the design guidelines document doesn't "invent" that type

  I'm tired of specious and internally inconsistent arguments.  I would
like to make progress without being accused of thinking I'm god, or of
inventing decade-old RADIUS traditions.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Oct 2009 17:14:27 -0400

Glen Zorn wrote:
> 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

  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.