|
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document includes quotes from pre-5738 RFCs. Should we be using the new "pre-5738" boilerplate? It is RECOMMENDED that SDOs and vendors seek review of RADIUS attribute specifications from the IETF. However, when specifications are SDO specific, re-use existing data types, and follow these guidelines, they do not require IETF review. . . . The advice in this document applies to attributes used to encode service-provisioning or authentication data. RADIUS protocol changes, or specification of attributes (such as Service-Type) that can be used to, in effect, provide new RADIUS commands require greater expertise and deeper review, as do changes to the RADIUS operational model, as described in Section 3.3 . Such changes SHOULD NOT be undertaken outside the IETF and when handled within the IETF require "IETF Consensus" for adoption, as noted in [RFC3575] Section 2.1. This would seem to suggest that support for new authentication mechanisms can be standardized outside the IETF, as long as the guidelines are followed. Also, the use of SHOULD NOT implies that there are circumstances in which protocol changes or new commands can be standardized outside the IETF. Is this what was intended? Note that the Vendor type field in the recommended VSA format is only a single octet, like the RADIUS type field. While this limitation results in an efficient encoding, there are situations in which a vendor or SDO will eventually wish to define more than 255 attributes. Also, an SDO can be comprised of multiple subgroups, each of whom can desire autonomy over the definition of attributes within their group. In such a situation, a 16-bit Vendor type field would be more appropriate: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Vendor-Id +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Vendor-Id (cont) | Vendor type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vendor length | Attribute-Specific... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ If additional functionality is required, the format defined in [EXTEN] SHOULD be used. Since [EXTEN] defines extensions to the standard RADIUS attribute space and this section is talking about VSAs, the reference is a bit confusing. Is the intent to suggest that VSAs other than type 0 can also use the [EXTEN] format? As a last resort, where the above techniques cannot be made to work, it may be possible to apply the techniques described in [RFC4821] to discovery the maximum supported RADIUS packet size on the path between a RADIUS client and a home server. s/discovery/discover/ Even though the type is Text, the rest of the description indicates that it is a complex attribute: Since accounting data is typically only written to stable storage without examination, does the reasoning against complex attributes really apply here? |