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

From: Alan DeKok <[email-masked]>
Date: Fri, 02 Jan 2009 16:15:13 +0100

Given the recent discussion on this document, can we pull it out of
IETF last call, and edit it within this WG again?

  I think there are a fair number of changes to make.

  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: "Dave Nelson" <[email-masked]>
Date: Fri, 2 Jan 2009 10:58:16 -0500

Alan DeKok writes...

> Given the recent discussion on this document, can we pull it out
> of IETF last call, and edit it within this WG again?

After some offline discussion with our AD, Dan Romascanu, it seems the path
we take will depend on the complexity of the changes.  Minor edits to add
clarification can be done as part of the IESG review process, e.g. handled
by RFC Editor Notes.

I think before pulling the draft back, let's see a proposed set of editing
instructions on the list, e.g. s/foo/bar, and see how bad the damage is.

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Jan 2009 13:30:29 -0800

> instructions on the list, e.g. s/foo/bar, and see how bad the damage is.

The best way to go about this is for the editor to post proposed resolutions 
to the list  for the open issues.  We can then see how the discussion
goes, and can track the status of the issues and the magnitude of changes
required as things progress. 

Whether we have to pull the draft back to the WG depends
on the magnitude of the changes and the degree of WG consensus 
behind them. 

In order to evaluate this, it would be helpful for the editor to maintain
a "strawman" version of the document-in-progress on a public website 
(I can supply space if required).  The "strawman" can be updated as 
Issues are closed, and we can then judge from the number and 
substance of the "diffs" what the next step will be. 

The ultimate goal should be to get a new version of the document posted
to the I-D archive by the IETF 74 deadline (early March).  We can then
go over the next steps at IETF 74.

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 2 Jan 2009 16:41:38 -0500

Bernard Aboba writes...

> The ultimate goal should be to get a new version of the document
> posted to the I-D archive by the IETF 74 deadline (early March).

Ever the optimist, I was hoping it might be done much sooner.  :-)

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 2 Jan 2009 14:23:50 -0800

> Ever the optimist, I was hoping it might be done much sooner.  :-)

There's no penalty for exceeding expectations :)

---

From: Alan DeKok <[email-masked]>
Date: Sun, 04 Jan 2009 10:26:50 +0100

Bernard Aboba wrote:
> For example, the Design Guidelines document, by articulating the RADIUS Design Guidelines,
> allows, and even *encourages* SDOs to create their own RADIUS attribute specifications.  

  I think this philosophy needs to be articulated more strongly in the
document.  I will post suggested text.

> So, as I read it, the goal of the Design Guidelines document isn't to lead to further ossification
> of the IETF process  -- but rather to a more productive and cooperative relationship
> between the IETF and SDOs.   For example. the guidelines on complex attributes only 
> apply to the RADIUS standard attribute space, not to the Extended Attribute space, or 
> to SDO-Specific attributes.   So as I read it, the document isn't saying "you can't do 
> this for an SDO-specific purpose", but rather, "if you wish to create attributes that are 
> unlikely to be widely deployed outside your SDO, do so using SDO-specific attributes 
> so as to to minimize impact on existing implementations". 

  I will make that point more strongly in the document.

> Discussion of Extended Attribute design is out of scope of the Design Guidelines
> document.  However, it *is* in scope for the Extended Attributes document.

  We could make it clearer that the this document allows [EXTENDED]
attributes, too.

> By looking at all existing RADIUS implementations, I am sure we could find 
> support for a considerable number of additional data types.  However, the
> question being considered by this document is not "what is the union of
> all implemented RADIUS datatypes", but rather "what is the likely 
> intersection of data types used in RADIUS standard attributes".  
> That question has been answered by examining existing RADIUS RFCs. 

  I agree.  Implementations use other data types primarily for
compliance with non-IETF RADIUS specifications.  I don't see anyone
implementing data types that aren't necessary.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 05 Jan 2009 12:30:51 +0100

> instructions on the list, e.g. s/foo/bar, and see how bad the damage is.

  Please see http://ietf.freeradius.org for some proposed changes.  I've
started from the current IETF draft, and modified it from there.  The
changes are grouped conceptually:

  (a) external review
  (b) applicability
  (c) clarification on data types

  There are 3 proposed drafts, with HTML diffs between them.

  If the changes are acceptable, we can merge them into a -06 version.
Otherwise, we can discuss the changes until they are acceptable.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 22 Jan 2009 16:22:00 +0100

>   Please see http://ietf.freeradius.org for some proposed changes.

  Any comments?  A number of people have read the pages, but the list
stays quiet...

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 22 Jan 2009 13:22:58 -0500

> stays quiet...

The changes look good to me.