Subject: (radius) draft-schulzrinne-sipping-radius-accounting-00.txt

From: Ignacio Goyret <[email-masked]>
Date: Thu, 21 Feb 2002 10:04:56 -0800

From the draft:

>5.3 NAS-Port
>
>   The NAS-Port attribute indicates the port number of the SIP Server
>   that provides service to the user. This is usually 5060. This
>   attribute MUST be present in Accounting-Request packets.
>

This use of the attribute is quite different from the usual use for this
attribute. I strongly suggest that you obtain a *new* attribute for this
use.

BTW, you should change the numbers you assigned to all the SIP-* attributes
and request numbers from IANA to avoid conflicts and interoperability issues.
At least as far as www.iana.org is concerned, IANA has not assigned any of
those numbers (see http://www.iana.org/assignments/radius-types)

-
To unsubscribe, email [email-masked]' with
'unsubscribe ietf-radius' in the body of the message.

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 21 Feb 2002 10:16:30 -0800

At 01:07 PM 2/21/02 -0500, Henning Schulzrinne wrote:
>> >   that provides service to the user. This is usually 5060.
>> 
>What is the usual use for this parameter? I couldn't quite figure it
>out.

From RFC 2865:

>5.5.  NAS-Port
>
>   Description
>
>      This Attribute indicates the physical port number of the NAS which
>      is authenticating the user.  It is only used in Access-Request
>      packets.  Note that this is using "port" in its sense of a
>      physical connection on the NAS, not in the sense of a TCP or UDP
>      port number.

It indicates a _physical port number_ not a TCP or UDP port, as you are
using it.

If you want to use it to indicate a TCP or UDP (or whatever other protocol)
port number, use a different attribute.

>The Internet Draft was meant as the necessary documentation, after we
>get the bugs fixed and have some expert feedback.

In that case, use VSAs until your bugs are ironed out. Otherwise, it will cause
endless confusion and all kinds of interoperability problems in the future
(was the attribute SIP-xyz value 100 (draft) or 101 (later assigned by IANA) ?)

-

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 21 Feb 2002 11:16:46 -0800 (PST)

Enclosed below find Section 6 of RFC 2865, which specifies the IANA
considerations for RADIUS. Note that release of blocks of attributes
require IETF Consensus (and permission from IANA).

-----------------------------------------------------------------------

6.  IANA Considerations

   This section provides guidance to the Internet Assigned Numbers
   Authority (IANA) regarding registration of values related to the
   RADIUS protocol, in accordance with BCP 26 [RFC2434].

   There are three name spaces in RADIUS that require registration:
   Packet Type Codes, Attribute Types, and Attribute Values (for certain
   Attributes).

   RADIUS is not intended as a general-purpose Network Access Server
   (NAS) management protocol, and allocations should not be made for
   purposes unrelated to Authentication, Authorization or Accounting.

6.1.  Definition of Terms

   The following terms are used here with the meanings defined in
   BCP 26: "name space", "assigned value", "registration".

   The following policies are used here with the meanings defined in
   BCP 26: "Private Use", "First Come First Served", "Expert Review",
   "Specification Required", "IETF Consensus", "Standards Action".

6.2.  Recommended Registration Policies

   For registration requests where a Designated Expert should be
   consulted, the IESG Area Director for Operations should appoint the
   Designated Expert.

   For registration requests requiring Expert Review, the ietf-radius
   mailing list should be consulted.

   Packet Type Codes have a range from 1 to 254, of which 1-5,11-13 have
   been allocated.  Because a new Packet Type has considerable impact on
   interoperability, a new Packet Type Code requires Standards Action,
   and should be allocated starting at 14.

   Attribute Types have a range from 1 to 255, and are the scarcest
   resource in RADIUS, thus must be allocated with care.  Attributes
   1-53,55,60-88,90-91 have been allocated, with 17 and 21 available for
   re-use.  Attributes 17, 21, 54, 56-59, 89, 92-191 may be allocated
   following Expert Review, with Specification Required.  Release of
   blocks of Attribute Types (more than 3 at a time for a given purpose)
   should require IETF Consensus.  It is recommended that attributes 17
   and 21 be used only after all others are exhausted.

   Note that RADIUS defines a mechanism for Vendor-Specific extensions
   (Attribute 26) and the use of that should be encouraged instead of
   allocation of global attribute types, for functions specific only to
   one vendor's implementation of RADIUS, where no interoperability is
   deemed useful.

   As stated in the "Attributes" section above:

      "[Attribute Type] Values 192-223 are reserved for experimental
      use, values 224-240 are reserved for implementation-specific use,
      and values 241-255 are reserved and should not be used."

   Therefore Attribute values 192-240 are considered Private Use, and
   values 241-255 require Standards Action.

   Certain attributes (for example, NAS-Port-Type) in RADIUS define a
   list of values to correspond with various meanings.  There can be 4
   billion (2^32) values for each attribute. Adding additional values to
   the list can be done on a First Come, First Served basis by the IANA.

-