Subject: Issue 312: Normative Reference to Extended Attributes Document

From: Bernard Aboba <[email-masked]>
Date: Wed, 2 Sep 2009 16:51:45 -0700

HTML clipboardIssue 312: Normative Reference to Extended Attributes Document

Submitter name: Bernard Aboba  

Submitter email address: [email-masked] 

Date first submitted: July 31, 2009  

Reference: 

Document: 
Design-Guidelines 

Comment type: Editorial 

Priority: S  

Section: 2.2, 3, 6.1  

Rationale/Explanation of issue:

In Section 2.2 and 3 the Design Guidelines document contains normative 
language relating to the Extended Attributes document.  This has resulted 
in a normative dependency on that document.  Given that the Extended 
Attributes document is not yet completed, and can contain its own usage 
guidelines, is the normative reference appropriate? 

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.From Section 
3: 

   Recent extensions to the RADIUS data model such as [EXTEN] make it
   possible to minimize the use of complex attributes.  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.
Proposed Resolution: Discuss

 EMAILING FOR THE GREATER GOOD
Join me

---

From: Alan DeKok <[email-masked]>
Date: Thu, 03 Sep 2009 15:27:54 +0200

Bernard Aboba wrote:
> language relating to the Extended Attributes document.  This has
> resulted in a normative dependency on that document.  Given that the
> Extended Attributes document is not yet completed, and can contain its
> own usage guidelines, is the normative reference appropriate?

  No.  The reference should be informative.

  I think it would be OK to simply move the [EXTEN] document from the
"normative" to "informative" section of the references.  Nothing in the
design guideline documents depends on [EXTEN], so there's no reason to
have a normative dependency.

  Alan DeKok.

--
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: Fri, 04 Sep 2009 10:21:02 +0200

Bernard Aboba wrote:
> The reason why we ended up with a normative reference was because there
> were normative statements preceeding the reference.  So I don't think it's
> enough just to change the reference to informative; you'll also need to
> change
> the text.

  I think it's simplest to simply remove all references to the extended
attributes document.  We can then mark it as updating the design
guidelines document, to permit the extended attribute format.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 04 Sep 2009 22:50:03 +0200

Bernard Aboba wrote:
>> The design guidelines document can talk about things that exist today.
>> if other documents add new RADIUS functionality, they can mention that
>> they update the design guidelines document.
> 
> Seems reasonable to me.  Could you post a proposal on text to be deleted?

  All text that references [EXTEN], or extended attributes. A quick pass
through the document yeilds:

   Specifications that do not follow the
   guidelines articulated herein or in [EXTEN] are NOT RECOMMENDED.
->
   Specifications that do not follow the
   guidelines articulated herein are NOT RECOMMENDED.
   Changes to the RADIUS data model are NOT
   RECOMMENDED, but if performed, SHOULD follow the IETF process.

  i.e. we can't retro-actively forbid the various SDOs from adding all
kinds of stuff to the data model.

   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.  New attributes SHOULD use the grouping
   method described in [EXTEN].
->
   New attributes SHOULD NOT use this tagging method because of the
   limitations described above.

2.2.  Extended RADIUS Attributes
->
	<delete the entire section>

  In Section 2.3:

   If additional functionality is required, the format defined in
   [EXTEN] SHOULD be used, with a non-zero Vendor-Id field.
->
	<delete the above text.

  In Section 3:

->
	<delete the above text>

  Alan DeKok.