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

["Last I. First" <gwz@cisco.com>]

At 10:04 AM 2/24/2003 -0500, Steven M. Bellovin wrote:
> In message
> <200302241448.h1OEmurC026462@rotala.raleigh.ibm.com>, Thomas Narten
> writes:
> >> If I understand this draft correctly, it represents the
> most
> >> pathetic and lame perversion of the IETF process I've ever
> seen.
> >
> >If you have something of substance to say, the above doesn't
> >communicate it very well.
> >
> >I'm serious.
>
> Glenn, that was my reaction, too.  I'm not sure what issue you're
> trying to raise.  BCP vs. Proposed?  That's the only thing I
> see.

Unfortunately, the only semi-technical issue with the draft is the use of
the term "allocated" in the last sentence of section 2.1,
paragraph 3: "A list of allocated RADIUS TypeCodes is given in
Appendix A.".  Since only Type Codes 1-5 and 11-13 were
actually allocated by RFC 2865 or, for that matter, by IANA (though the
IANA registry does mention Type Codes 6-10 as "unassigned" and
255 as reserved), the sentence probably should be changed to something
like "RADIUS Type Codes 1-5 and 11-13 were allocated in RFC 2865,
while Type Codes 6-10 and 14-52 are allocated by this document.  For
a list of Type Codes, see Appendix A".    This
wording would more clearly explain the apparent purpose of this document,
since aside from some minor changes in the way Attribute Codes are
assigned, the major change to RFC 2865 is in the "allocation"
of those Type Codes.  As you are no doubt aware, the author of this
draft is also a co-author of another draft
(draft-chiba-radius-dynamic-authorization-xx.txt) which was the object of
a recent IESG appeal.  That appeal was based upon the fact that RFC
2865 requires Standards Action for the allocation of new Type Codes,
since "a new Packet Type has considerable impact on
interoperability".  Interestingly, Bernard seems to agree with
this statement (maybe just for other people?), since the same words are
present in draft-aboba-radius-iana-01.txt.   Indeed, if
draft-aboba-radius-iana-01.txt is published as a Proposed Standard, it
will fulfill the letter of the law, and allocate the Type Codes used in
draft-chiba-radius-dynamic-authorization-xx.txt (among others).  I
doubt very much that it will satisfy the spirit of either RFC 2865 or of
BCP 26, though .  I had thought that when BCP 26 defined
"Standards Action" as meaning that "Values are assigned
only for Standards Track RFCs approved by the IESG." it meant that
something other than just the numbers would be defined in the
"Standards Track RFCs"; perhaps not.  I'm not sure if the
IESG goes on precedent, but this sure sets a neat one: Loathe to publish
your proprietary protocol?  Spec too lame for the Standards
Track?  IANA allocation blocked by some pesky RFC?   No
problem, just "update" that pesky RFC to include the numbers
you need!  To give a couple of random (but telling) examples,
draft-aboba-radius-iana-01.txt lists RFC 2882 as the reference for Type
Codes 29, 30 and 32.  Here is the _entire_ text explaining these
three Type Codes: 

5.2.  Authentication Modes

   Additional message types have been added to negotiate
passcode
   changes for token card servers.

    - Next Passcode
    - New PIN
    - Password Expired

   They allow the NAS or RADIUS server negotiate passcode
changes with
   an external security server.

That's it.  If anyone would like to explain to me how to
build independent, interoperable implementations (presumably the purpose
of standards) for those RADIUS messages, I'd love to hear it. 
Another example (also from RFC 2882, the cited reference in
draft-aboba-radius-iana-01.txt):

5.1.  Password Change

   Remotely requested password change operations were described
and
   proposed, but rejected by the working group.  None the
less, the
   feature is still deployed in a number of products.

   Message types:

    - Password Request
    - Password Ack or Reject

Here we have a set of messages (Type Codes 7-9) that were
_rejected_ (right or wrong) by an IETF WG legitimized as if by
magic!  What is the format of these messages?  What do they
contain?  One would likely have to dig through the same set of
vendor manuals as Dave Mitton did when he was writing RFC 2882 to find
that out.  I hope that I have clarified my use of the terms
"pathetic" and "lame" in my comment; however, my use
of the word "perversion" may not be quite clear.  My usage
of the word is derived from definition 2 of "pervert" in the
Merriam-Webster Online Dictionary (hardly authoritative, but what the
heck): "2 a : to divert to a wrong end or purpose :
MISUSE b : to twist
the meaning or sense of : MISINTERPRET
synonym see
DEBASE".

                --Steve Bellovin, http://www.research.att.com/~smb (me)
                http://www.wilyhacker.com (2nd edition of "Firewalls" book)