RE: Proposed Resolution of Issue #320: REJECT

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

Bernard Aboba [mailto://bernard_aboba@hotmail.com] writes:

> Alan DeKok said:
> 
> "  This issue should be rejected out of hand.  The concept of "data
> types" goes back to the beginning of RADIUS, and was part of the
> original protocol specification."
> 
> Given that the Design Guidelines document has already been approved for
> publication by the IESG, 

In actual point of fact, this assertion is incorrect: the Issue Tracker
shows that the draft in question is in the state "IESG Evaluation",
sub-state "AD Followup"; this does not translate to "approved for
publication".  In fact, the description of the "AD Followup" sub-state
suggests that the resolution of issues is no longer up to the WG Chairs: "A
generic substate indicating that the shepherding AD has the action item to
determine appropriate next steps. In particular, the appropriate steps (and
the corresponding next state or substate) depend entirely on the nature of
the issues that were raised and can only be decided with active involvement
of the shepherding AD."

> the bar for making changes is extremely high.

I'm sorry, I would have thought that the bar for publication of a document
as an RFC would have been considerably higher.

> 
> In this case, that bar does not appear to have been reached.
> RFC 3162 defines several attributes as being of type "address".

Where?  The expected phrase would be "is of type address" or something
similar, which doesn't appear in the document.  It does, however, _name_ a
single attribute as "NAS-IPv6-Address but that is stated simp0ly to be "16
octets".  Furthermore, the description of the Login-IPv6-Host attribute (one
of the attributes which draft-ietf-radext-design-09 cites as justification
for an "IPv6 Address" data type) specifies special meanings for 2 values of
the "Address" field.  Do all "IPv6 Address" data types have the same
semantics?  If not, then draft-ietf-radext-design-09 is in error.

> Since the addresses in question were IPv6 addresses, and RFC 2865
> utilizes the IPv4 address type for similar attributes within IPv4,

Hmm.  The practice of making bald assertions of opinion without basis in
fact seems to be contagious ;-).  As many people have noted over the years,
although RFC2865 defines the "address" data type, no attributes are defined
to be of type "address" in that document.

> it is not much of a stretch to conclude that RFC 3162 defines the
> IPv6 address type.

One can conclude virtually anything if one begins with a false premise...

> 
> Therefore I would propose that Issue 320 be resolved as REJECT.
> 
> 
> 
> 
> 
> 
> 
> 
> --
> 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/>


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