|
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: dromasca@avaya.com > To: radiusext@ops.ietf.org > > RADEXT WG, > > Please advise on the Technical Errata below. > > Thanks and Regards, > > Dan > > > > -----Original Message----- > From: iesg-bounces@ietf.org [mailto:iesg-bounces@ietf.org] On Behalf Of > RFC Errata System > Sent: Thursday, October 22, 2009 3:19 PM > To: bernarda@microsoft.com; gwz@cisco.com; iesg@iesg.org > Cc: aland@freeradius.org; rfc-editor@rfc-editor.org > 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 <aland@freeradius.org> > > 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 radiusext-request@ops.ietf.org with > the word 'unsubscribe' in a single line as the message text body. > archive: <http://psg.com/lists/radiusext/> |