Issue: Use of the term "extended" within the Design Guidelines Document

[Bernard Aboba <bernard_aboba@hotmail.com>]

> At the risk of putting words in Hannes' mouth, I'm pretty sure that the
> draft he believes gives the impression that Extended Attributes can easily
> support the Diameter AVP structure _is_ the Design Guidelines draft; as he
> points out, it would be impossible for a reasonable person to get that idea
> from the Extended Attributes draft.

Looking at the Design Guidelines document, the term "extended"
is used in a number of contexts.  This may explain some of the
questions that Hannes raised. 

For example, in Section 2.2, the term is used to refer to the Extended Attributes document: 
2.2.  Extended RADIUS Attributes

   The extended RADIUS attribute document [EXTEN] defines a number of
   extensions to RADIUS.  The standard attribute space is extended by
   permitting standard allocations from within a specific subset of the
   VSA space; the format of extended attributes is defined; and extended
   data types are defined within that format.

   New specifications seeking to extend the standard RADIUS data model
   SHOULD examine [EXTEN] to see if their needs fit within the extended
   RADIUS data model.

In Section 3.1.2, the term is used to refer to RADIUS VSAs in general:

   As discussed in [RFC2865] Section 5.26, the vendor space is intended
   for vendors to support their own extended attributes not suitable for
   general use. 

In Section A.1.2, the term "Extended" is used to refer to data types. 
However, it is not clear whether this advice is only applicable to
RADIUS standard attributes (which I believe is the case), or whether
it applies to VSAs or SDO-specific attributes. 

A.1.2. Extended data types

   Where possible, the data types defined above in Section A.1.1 SHOULD
   be used.  The extended data types defined in [EXTEN] SHOULD be used
   only where there is no clear method of expressing the data using
   existing types.

   Does the data fit within the extended RADIUS data model, as outlined
   below?  If so, it SHOULD be encapsulated in a [EXTEN] format RADIUS
   VSA.

      * Attributes grouped into a logical container.
        This does not include nested groups.
      * Attributes requiring the transport of more than 247 octets of
        Text or String data.  This includes the opaque encapsulation
        of data structures defined outside of RADIUS.  See also Section
        A.1.3, below.

In Section A.5, the term "extended" is used to refer to SDO-specific
data types:

   Note that the points listed above do not relax the recommendations
   discussed in this document.  Instead, they recognize that the RADIUS
   data model has limitations.  In certain situations where
   interoperability can be strongly constrained, a data model extended
   by the SDO or vendor MAY be used.  

The term is also used in Section B.8, this time in reference to the
Extended Attributes document:

   Future specifications that attempt to obtain similar
   functionality SHOULD use the extended types from [EXTEN].

Overall, in looking over this text, there does seem to be some possibility
of confusion relating to the applicability of the document (which I believe
only applies to attributes within the RADIUS standard attribute space). 

However, none of the above text would seem capable of leading a reader
to believe that the Diameter AVP format was supported.  Or am I missing
something? 



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