Guidelines Document Discussion

["Bernard Aboba" <bernard_aboba@hotmail.com>]

After IETF 68, I spent some time reading the current guidelines document and 
thinking about how we should proceed to revise it.

One of the things that struck me about the current document is that it 
assumes that the differences in data model between the IETF Standard space 
and the VSA space represent a long term problem which needs to be resolved.

Part of the reasoning is that without converging the data models, it may be 
difficult for RADIUS attributes specified using VSAs to be standardized 
without requiring changes to the standard data model.

At IETF 66, we had a discussion about this, and there was considerable 
resistance to the notion of extending the RADIUS data model to sync up 
better with the VSA data model.

Even if there were to be some convergence of the standard and VSA data 
models, it strikes me that this convergence might only be temporary, since a 
vendor or SDO using the VSA space can define their own attribute format as 
well as attributes.

As a result, it strikes me that the Guidelines document probably needs to 
accept that the RADIUS standard and VSA data models are currently different 
and are likely to remain so.  The document also needs to recognize the 
reality of today's VSA usage in other ways.

RFC 2865 Section 5.26 characterizes VSAs as follows:

     This Attribute is available to allow vendors to support their own
     extended Attributes not suitable for general usage.  It MUST not
     affect the operation of the RADIUS protocol.

     Servers not equipped to interpret the vendor-specific information
     sent by a client MUST ignore it (although it may be reported).
     Clients which do not receive desired vendor-specific information
     SHOULD make an attempt to operate without it, although they may do
     so (and report they are doing so) in a degraded mode.

These two paragraphs, which occur within the core of the RADIUS 
specification [RFC2865] hold up quite well even today.

The characterization of VSAs as "not suitable for general usage" is 
consistent with specifications created by SDOs for specific uses.  An 
example is RFC 4679 created by the DSL Forum.  It would also fit VSAs 
defined by IEEE 802 that are specific to the IEEE 802 family of protocols, 
such as those defined in RFC 4675.  The point made in the second sentence is 
that VSAs are just attirbutes and do not affect the RADIUS protocol itself; 
this would preclude SDOs from creating their own RADIUS dialects.

Note that this section does not talk about interoperability.  That 
discussion occurs in RFC 2865, Section 6.2:

  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.

While this paragraph has been used to argue that SDO usage of VSAs has gone 
beyond the original intent of RFC 2865, on comparing this paragraph with 
those in Section 5.26, I am not sure.  Since this paragraph comes from the 
IANA considerations section, it is really talking about the circumstances in 
which vendors (which would include SDOs) should be encouraged to use VSAs 
rather than requesting an allocation from the standards space.  However, 
this is not the only situation in which use of VSAs would make sense; the 
"not for general use" description from Section 5.26 is more comprehensive.

If we are to adjust to the idea that the standards data model and the VSA 
data model will not necessarily converge,  I think we will also need to 
adjust to a potentially larger role for VSAs, as well as thinking about the 
long-term relationship between the IETF and SDOs which utilize the RADIUS 
protocol.

Within the SNMP community, the need for an efficient and scalable approach 
to non-IETF MIB development has been evident for quite a while.  As 
described in RFC 4663, it is most efficient for MIBs to be developed within 
the standards organizations developing the protocols that require 
management, since handling MIB work in a separate standards body results in 
additional travel and coordination costs which are difficult to justify.  To 
help ensure quality, the IETF can provide assistance in the form of 
Guidelines documents and reviews provided by a Doctor team, and of course 
the IETF continues to assert change control over the SNMP protocol.

It strikes me that RADIUS VSA usage may face a similar evolution, and that 
such a parth, if successfully traveled, should not be cause for dismay.   As 
we have discovered, there may be circumstances in which a particular RADIUS 
attribute set may be easier to define within a VSA space than within the 
standards space.  Rather than trying to fit a square peg into a round hole 
by modifying the document to work with the existing RADIUS standard data 
model, it is simpler to retain use of VSAs.

If we were writing an equivalent paragraph to the VSA allocation description 
found in RFC 2865 Section 6.2 today, I think we might include more instances 
in which allocation of VSAs is desirable.  For example:

* Where interoperability is useful but usage is confined to a specific 
access mechanism or SDO specification;
* Where allocation of a large number of attributes is required (>5?)
* Where data types are required that fall outside of the usage defined in 
the Guidelines document;

We might also include circumstances in which VSA usage would be strongly 
discouraged:

* Where the VSAs represent a change to the RADIUS protocol.  This would 
include definition of new commands or operational modes.

I would suggest that the Guidelines document needs to tackle this and other 
issues arising from the usage of VSAs.



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