Subject: Issue: Data Type Advice

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Dec 2008 12:32:30 -0800

Issue: Data Type Advice

Submitter name:  Bernard Aboba

Submitter email address: [email-masked]

Date first submitted: December 30, 2008  

Reference: 

Document:  GUIDELINES

Comment type: Technical

Priority:  S

Section:  Appendix A.1.1

Rationale/Explanation of issue:

Section A.1.1 reads: 
   Does the data fit within the existing RADIUS data model, as outlined
   below?  If so, it SHOULD be encapsulated in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA.

As noted in an earlier issue, Appendix B does not cover data types utilized within RADIUS VSAs, 
only the data types in standard RADIUS attributes.   Therefore the "existing RADIUS data model
as outlined below" is really just the data model for standard RADIUS attributes.   On that basis
the sentence might better read:

   Does the data fit within the RADIUS standard attribute data model, as outlined
   below?  If so, it MAY be encapsulated either in a [RFC2865] format RADIUS
   attribute, or in a [RFC2865] format RADIUS VSA.

Assuming that the promised survey of ad-hoc data model extensions is actually included in the
document, then this could be referenced to in a subsequent sentence:

   Does the data fit utilize ad-hoc extensions to the RADIUS data model, as outlined
   in below?  If so, it SHOULD be encapsulated in a RADIUS VSA or an Extended
   Attribute [EXTENDED].  

Given this, it would appear that Section A.1.1 is recommending that RADIUS VSAs only

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 16:33:04 -0500

Bernard Aboba writes...

> Therefore the "existing RADIUS data model as outlined below" is really
> just the data model for standard RADIUS attributes. 

Well, characterizing various ad-hoc extensions as part of a data model seems
to me to de-value the term "data model".  :-)

>   Does the data fit within the RADIUS standard attribute data model,
>   as outlined below?  If so, it MAY be encapsulated either in a [RFC2865]
>   format RADIUS attribute, or in a [RFC2865] format RADIUS VSA.

OK.

>   Does the data fit utilize ad-hoc extensions to the RADIUS data model,
>   as outlined in below?  If so, it SHOULD be encapsulated in a RADIUS VSA 
>   or an Extended Attribute [EXTENDED].

While it may be feasible to group the ad-hoc extensions into a handful of
categories, I'm not sure what benefit this provides.  Anything *other* than
the (limited) standard data model is automatically an ad-hoc extension,
right?  Do we need to provide examples?

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>

---

From: Alan DeKok <[email-masked]>
Date: Tue, 30 Dec 2008 22:58:19 +0100

> to me to de-value the term "data model".  :-)

  Most vendors are smart/lazy enough to re-use the existing data types.
 The guidelines draft is intended to encourage this behavior, and to
discourage "complex" types that are little more than simple collation of
existing data types.

  It is intended to encourage SDO specifications that re-use existing
data types.  These specifications should *not* need IETF review.

  Specifications that are SDO specific, and do *not* re-use existing
types are SDO specific, and do not need IETF review.

  Much of this is already in the document.  What can we do to clarify
the text to avoid repeated questions?

> right?  Do we need to provide examples?

  I would say no.

  The most I would do is to provide horrific examples of what *not* to
do.  i.e. putting arbitrary text strings into the "data" portion of a
VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Dec 2008 14:02:51 -0800

> right?  Do we need to provide examples?

Once the ad-hoc extensions are included in Appendix B, as is claimed in
Section 1, then several questions arise:

* Which, if any, of these additional data types are suitable for use in Extended
Attributes?

* Which, if any, of these additional data types are appropriate for use in 
SDO-specific attributes?

* Which, if any, of these additional data types are appropriate for use in VSAs? 

Presumably, the answer to these questions might be different.  

It is possible that some of these questions may be left to other documents;
for example, the Extended Attributes document could deal with the data
model appropriate to those attributes (incorporating Section A.1.2 from
Design Guidelines, for example).  

It is also possible that some of these questions may be explicitly ruled out
of scope.  But if so, that needs to be made clear within Section 1.1, which
deals with Applicability.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Dec 2008 14:06:21 -0800

> the text to avoid repeated questions?

I'd suggest that a revision of Section 1.1 is needed to clarify this.  Right now,
this section seems to suggest that SDO specifications utilizing existing
RADIUS standard data types can avail themselves of IETF review.  Also,
as David notes, the document can be read as suggesting IETF review
of all SDO RADIUS attribute documents.  
 
> VSA (no... no VSA-type/VSA-length/VSA-data... just Vendor-Id/text..)

Describing why this is a bad idea would probably be useful.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 18:39:44 -0500

Bernard Aboba writes...

> Right now, this section seems to suggest that SDO specifications utilizing
> existing RADIUS standard data types can avail themselves of IETF review.

Yes, but what does that mean?  Designated Expert?  AAA Doctors?  Certainly
not IETF Last Call.

> Also, as David notes, the document can be read as suggesting IETF review

What is the current practice with MIB Modules?  Are MIB Doctors assigned to
assist non-IETF SDOs with authoring/reviewing their MIB Modules?  I bet Dan
Romascanu can enlighten us here.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Dec 2008 16:15:41 -0800

> Yes, but what does that mean?  Designated Expert?  AAA Doctors?  Certainly

Why not?  RFC 3580 went through IETF last call, when it was included as
an Appendix in IEEE 802.1X-2004. 

> Romascanu can enlighten us here.

RFC 4663 discusses this.  The short answer I believe is "yes".