[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Last Call: IANA Considerations for RADIUS to Proposed Standard


--On 24. februar 2003 18:54 -0800 "Last I. First" <gwz@cisco.com> wrote:


At 01:49 PM 2/24/2003 -0500, Steven M. Bellovin wrote:

Thanks; that helps.

No problem.  I have doubts about the effectiveness of my comments, since
the draft had apparently been discussed already w/Harald & Allison, but
perhaps my new IETF career is captain of the Light Brigade ;-).
I'm not strongly attached to any particular solution here; my previous comments are attached below - as you can see, not all of them made the draft....

I must
note once more, though, that this kind of nonsense is just what could
have been avoided but instead was virtually guaranteed by the outlawing
of vendor-specific commands in Diameter...
the opposing flame is of course that vendor-specific codes would have allowed us to have standardized labelled non-interoperability rather than standards-violating non-interoperability; but we've been around that bush so many times that the grass is all worn out by now....

[note - I'm CCing Bernard]

mumble.

it does not solve the matter of the zorn appeal (but seems to assume that
DynAuth will be standards-tracked, since it refers it - that's fine with
me).

worse, it leaves the status of the numbers in 2882 unclear (and unlisted).

off-the-top-of-my-head suggestion for a resolution, since this document
will be a standards action:


add a table, referencing RFC 2882, that says:

This document reserves the following packet type numbers, defined in [RFC
2882], and instructs IANA to list them in the registry of packet types:


         6 Accounting Status
                  (now Interim Accounting [5])
         7 Password Request
         8 Password Ack
         9 Password Reject
         10 Accounting Message

         21 Resource Free Request
         22 Resource Free Response
         23 Resource Query Request
         24 Resource Query Response
         25 Alternate Resource Reclaim Request
         26 NAS Reboot Request
         27 NAS Reboot Response

         29 Next Passcode
         30 New Pin
         31 Terminate Session
         32 Password Expired
         33 Event Request
         34 Event Response

         50 IP Address Allocate
         51 IP Address Release

These have no meaning defined by an IETF standards-track protocol, but
are reserved until an IETF standards-track protocol defines a meaning for
them. They will not be handed out in response to new requests until the
set of numbers is exhausted. This is being done to avoid interoperability
problems with software that implements nonstandard RADIUS extensions that
are or have been in use on the Internet.

Note that codes 40-44, which are also listed in [RFC 2882], are defined
in [DynAuth].



--On tirsdag, februar 11, 2003 09:24:03 -0500 Randy Bush <randy@psg.com>
wrote:


A New Internet-Draft is available from the on-line Internet-Drafts
directories.
    Title       : IANA Considerations for Remote Authentication Dial In
                  User Service (RADIUS)
    Author(s)   : B. Aboba
    Filename    : draft-aboba-radius-iana-00.txt
    Date        : 2003-2-10
	
this will be going for ps, with an ietf-wide last call.  i am inclined
to rush this through, as we are having radius parm allocation issues
with ieee and others.

your guidance is solicited

randy