Subject: [radext] Status of extensions document?

From: Alan DeKok <[email-masked]>
Date: Wed, 21 Dec 2011 08:15:54 -0500

I haven't seen any comments on the latest draft.

  There were some typos from Leaf, and IANA comments from Bernard.  Have
they been addressed to the WGs satisfaction?

  Having the document move forward would be a wonderful xmas present.

  Alan DeKok.

_______________________________________________
radext mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/radext

---

From: Leaf yeh <[email-masked]>
Date: Fri, 23 Dec 2011 09:39:40 +0000

Has the WG concluded on the concern against

'IANA is requested to move the "Unassigned" values in the range 144-191 from "Unassigned" to "Deprecated'.

in section 9.1 of draft-ietf-radext-radius-extensions-03?

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, December 21, 2011 9:16 PM
To: 'radext mailing list'
Subject: [radext] Status of extensions document?

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Fri, 23 Dec 2011 09:39:40 +0000

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan DeKok
Sent: Wednesday, December 21, 2011 9:16 PM
To: 'radext mailing list'
Subject: [radext] Status of extensions document?

  Alan DeKok.

---

From: Leaf yeh <[email-masked]>
Date: Sat, 24 Dec 2011 04:06:38 +0000

FYI - In fact, the type code of the Radius attribute, 144, seems to have been assigned. (http://www.iana.org/assignments/radius-types/radius-types.xml)

-----Original Message-----
From: Leaf yeh
Sent: Friday, December 23, 2011 5:41 PM
To: 'Alan DeKok'; 'radext mailing list'
Subject: RE: [radext] Status of extensions document?

Best Regards,

Leaf

-----Original Message-----

  Alan DeKok.

radext mailing list

[email-masked]

---

From: Leaf yeh <[email-masked]>
Date: Sat, 24 Dec 2011 04:06:38 +0000

-----Original Message-----
From: Leaf yeh
Sent: Friday, December 23, 2011 5:41 PM
To: 'Alan DeKok'; 'radext mailing list'
Subject: RE: [radext] Status of extensions document?

Best Regards,

Leaf

-----Original Message-----

  Alan DeKok.

radext mailing list

[email-masked]

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Dec 2011 09:05:05 -0500

Leaf yeh wrote:
> FYI - In fact, the type code of the Radius attribute, 144, seems to have
> been assigned.
> (http://www.iana.org/assignments/radius-types/radius-types.xml)

  Which is why the text says to move the *UNASSIGNED* values.

  Since 144 is not *UNASSIGNED*, there is no problem.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Dec 2011 09:05:05 -0500

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Dec 2011 10:57:58 -0500

Dave Nelson wrote:
> What's the purpose of this?  To preclude any additional "classic" RADIUS
> attributes from being defined?

  Not to preclude, but to deprecate them.  The goal is to use the new
attributes where possible.

>  I thought the consensus was to prvide
> guidance on when to use "classic" attributes and when to use "extended"
> attributes.

  The document does that.

>  Theare a any number of applications asn uses cases that I
> can Imagine whnere a sinple "classic" RADIUS attribute works just fine,
> so long as the number space lasts.  Why force the issue?

  If we don't suggest that documents use the new format, they won't.
Deprecating the old space gives incentive to use the new space.

  Again, the document doesn't *prevent* use of the old space.  It just
suggests that there are few reasons for using it.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 24 Dec 2011 10:57:58 -0500

The document does that.

  Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Dec 2011 08:31:56 -0800

> attributes where possible.

Deprecation of a registry is not defined in RFC 5226, so it's not clear how IANA can carry that out in practice.

> suggests that there are few reasons for using it.

Since this draft doesn't update RFC 3575, it can be argued that no changes are made to legacy allocations.  However, the request for deprecation will create confusion.

---

From: Bernard Aboba <[email-masked]>
Date: Sun, 25 Dec 2011 08:31:56 -0800

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Dec 2011 09:26:43 -0500

> Deprecation of a registry is not defined in RFC 5226, so it's not clear how IANA can carry that out in practice.

  Then the entries should be marked "reserved".

> Since this draft doesn't update RFC 3575, it can be argued that no changes are made to legacy allocations.  However, the request for deprecation will create confusion. 

  The latest version of the draft (1 month ago) does update 3575.  It
also updates the IANA section to address your other concerns.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Dec 2011 09:26:43 -0500

Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Dec 2011 10:21:36 -0800

Updating RFC 3575 and marking non-allocated entries as "reserved" would be well understood by IANA.  This would cause them to refuse to allocate any attributes from the "reserved" space, effectively closing the RADIUS "standards" space to further use, effective immediately.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 26 Dec 2011 10:21:36 -0800

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Dec 2011 13:39:09 -0500

Bernard Aboba wrote:
> Updating RFC 3575 and marking non-allocated entries as "reserved" would
> be well understood by IANA.  This would cause them to refuse to allocate
> any attributes from the "reserved" space, effectively closing the RADIUS
> "standards" space to further use, effective immediately.

  Honestly, I might be OK with that.

  As an alternative, how do we update the registry to (a) create the new
extended space, and (b) suggest that people should *use* it?

  I'm open to suggestions.  Much of the discussion on this list has been
to shoot down new ideas.  So I understand why people are hesitant to
propose anything positive.

  There's currently a strong push to use the standard space for
everything, even new standards which would be better served by using the
extended format.  The excuse is "the extended format isn't published",
or "it isn't implemented"

  It's a circular argument (as has been pointed out repeatedly).  Yet
it's appealing, because it lets people ignore the problem for another
few years.  It lets people delay updating their implementations.  After
all, 400-500 lines of code for the extended format is just too
complicated to add to an implementation.

  I propose that we simply discard the extensions document.  Instead, we
should just keep allocating from the standard space.  Then, when all
attributes have been allocated, we should panic.

  Or... maybe there's a more intelligent alternative.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 26 Dec 2011 13:39:09 -0500

Alan DeKok.

---

From: Dave Nelson <[email-masked]>
Date: Sat, 24 Dec 2011 09:40:48 -0500

What's the purpose of this?  To preclude any additional "classic" RADIUS
attributes from being defined?  I thought the consensus was to prvide
guidance on when to use "classic" attributes and when to use "extended"
attributes.  Theare a any number of applications asn uses cases that I can
Imagine whnere a sinple "classic" RADIUS attribute works just fine, so long
as the number space lasts.  Why force the issue?

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Dave Nelson <[email-masked]>
Date: Sat, 24 Dec 2011 09:40:48 -0500

Regards,

Dave

David B. Nelson
Sr. Software Architect
Elbrys Networks, Inc.
www.elbrys.com
+1.603.570.2636

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Dec 2011 23:37:21 -0800

> extended space, and (b) suggest that people should *use* it?
[BA]  I'd suggest that the document create the new extended space, and:
1. Enable attribute requests to be allocated from the new space upon request; 2. Require that "large" (e.g. >10) attribute requests be allocated only from the new space (to prevent attribute hoarding); 3. Prescribe that attributes automatically be allocated from the new space once the "standards" space is exhausted; 
> or "it isn't implemented"

[BA] Both of those objections can be overcome by publishing the document and implementing the format. 
> few years. 
[BA]  It might take a few years to get the extensions widely implemented so that's not so bad by itself. 
However, I would be upset if a few "large" requests were to exhaust the standards space before that point.  
> It lets people delay updating their implementations.  After
[BA] It's not just implementing, there is also deployment to consider.  Even if all RADIUS servers implementedextensions today, it could still take 3-4 years to get the new servers widely deployed.  

>   I propose that we simply discard the extensions document. 
[BA] No need to go that far.  It's a useful document, it should be published. 
> Instead, we should just keep allocating from the standard space.  Then, when all
[BA] The two are not mutually exclusive.  We can publish the extension document, then keep allocating from the standards space, and in a few years, panic. 
Based on recent experience with IPv6, this is a time-honored technique.

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 28 Dec 2011 23:37:21 -0800

---

From: Leaf yeh <[email-masked]>
Date: Thu, 29 Dec 2011 11:28:36 +0000

I also support to publish draft-ietf-radext-radius-extensions.
At least I need data type of Integer64 for the definition of IPv4 or IPv6 traffic statistics in my individual draft.

Another comment for the further discussion:

Do we really need around 1k (4*240) in the new type space got from 241.* to 244.* for the Extended-Type?
I guess the design of 241.* (or plus 242.*) might be enough to meet the current requirement or situation.

From: Bernard Aboba [mailto:[email-masked]]
Sent: Thursday, December 29, 2011 3:37 PM
To: Alan DeKok
Cc: [email-masked]; [email-masked]; Leaf yeh
Subject: RE: [radext] Status of extensions document?

> extended space, and (b) suggest that people should *use* it?

[BA]  I'd suggest that the document create the new extended space,
and:

1. Enable attribute requests to be allocated from the new space upon request;
2. Require that "large" (e.g. >10) attribute requests be allocated only from the new space (to prevent attribute hoarding);
3. Prescribe that attributes automatically be allocated from the new space once the "standards" space is exhausted;

> complicated to add to an implementation.

[BA] It's not just implementing, there is also deployment to consider.  Even if all RADIUS servers implemented
extensions today, it could still take 3-4 years to get the new servers widely deployed.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 29 Dec 2011 11:28:36 +0000

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 12:00:23 -0500

> to 244.* for the Extended-Type?

  Not really.  The only reason to allocate many is to remove the
perception that the type space was precious.  With 1K attributes
available, specifications can freely allocate attributes for all needs.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 12:00:23 -0500

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 12:09:14 -0500

Bernard Aboba wrote:
> 2. Require that "large" (e.g. >10) attribute requests be allocated only
> from the new space (to prevent attribute hoarding); 
> 3. Prescribe that attributes automatically be allocated from the new
> space once the "standards" space is exhausted; 

  I've updated the document as above.  There is a new text in Section 6
(guidelines for spec authors), and Section 9 (IANA considerations) to
address this.

  The document also updates RFC6158 (it didn't before), and contains
text updating the guidelines in specific sections of RFC 6158.

> extensions today, it could still take 3-4 years to get the new servers

  Yes.

> [BA] The two are not mutually exclusive.  We can publish the extension
> document, then keep allocating from the standards space, and in a few
> years, panic. 
> 

  :)

  The draft submission tool appears to be down.  I've put a new version
of the document at:

http://git.freeradius.org/ietf/draft-ietf-radext-radius-extensions-04.txt

  I'll try submitting it again next week.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 12:09:14 -0500

Yes.

  :)

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 29 Dec 2011 17:44:48 +0000 (UTC)

Bernard writes...

> 2. Require that "large" (e.g. >10) attribute requests be 
> allocated only from the new space (to prevent attribute hoarding);
> 3. Prescribe that attributes automatically be allocated from the
> new space once the "standards" space is exhausted;

I think that's a more workable approach.
 
> > everything, even new standards which would be better served by using
> > the extended format. The excuse is "the extended format isn't
> > published", or "it isn't implemented"
> 
> 

Indeed.  This has to be a make-before-break kind of transition, and until there is sufficient industry experience with the extended attribute format and sufficient deployment of infrastructure using it, effectively obsoleting the classic attribute format for new uses is premature. 

> [BA] No need to go that far. It's a useful document, it should be

It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit.  Do we have a practical way to tie allocation in either space to the outcome of a design guidelines review? 

-- Dave

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 29 Dec 2011 17:44:48 +0000 (UTC)

Bernard writes...

 

-- Dave

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 29 Dec 2011 17:48:51 +0000 (UTC)

Alan DeKok writes...
 
> (guidelines for spec authors), and Section 9 (IANA considerations) to

You weren't going to wait for just a bit more discussion and consensus-building on the list?  ;-)

Process aside, I think this is the correct approach.

> text updating the guidelines in specific sections of RFC 6158.

Yeah.  I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review?

-- Dave

---

From: "David B. Nelson" <[email-masked]>
Date: Thu, 29 Dec 2011 17:48:51 +0000 (UTC)

Alan DeKok writes...

-- Dave

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 13:13:02 -0500

> It should be published, and via the design guidelines process developers should be encouraged to use the extended attribute format when the classic attribute format would be a force-fit.  Do we hav…

  The document updates RFC 6158, and adds new guidelines.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 13:13:02 -0500

Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 13:17:18 -0500

> You weren't going to wait for just a bit more discussion and consensus-building on the list?  ;-)

  The consensus is clear: allow allocations from the standard space.

> Yeah.  I'll take a look at that, along the lines of the question I asked in my previous post: Can allocation policy be effectively tied to guidelines review?

  Yes.  The document does that.

  When the submission tool starts working again, I'll submit the draft.
 A "diff" view between -03 and -04 is instructive.  There are a number
of new sections dealing with guidelines, and more clarity WRT the IANA
Considerations.

  The new text came about because I reviewed the document with an eye to
concerns raised on this list.  I realized that it didn't update RC 6158,
even though it had a simple "guidelines" section.  Then, it needed
explicit changes to the guidelines of 6158, to make it clear that the
new formats are now allowed.

  Then based on Bernard's suggestion, the IANA considerations section
was re-worked to give very detailed description of what to do.  The
Guidelines section was also re-worked to have normative text reflecting
the IANA allocation strategies.

  Over all, I think the document is more precise in what it's trying to do.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Thu, 29 Dec 2011 13:17:18 -0500

Alan DeKok.

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 31 Dec 2011 11:36:31 -0800

A question: shouldn't the document be Standards Track?

---

From: Bernard Aboba <[email-masked]>
Date: Sat, 31 Dec 2011 11:36:31 -0800

---

From: Alan DeKok <[email-masked]>
Date: Sat, 31 Dec 2011 16:25:27 -0500

> A question: shouldn't the document be Standards Track?

  Hmm... yes, I think.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Sat, 31 Dec 2011 16:25:27 -0500

Hmm... yes, I think.

  Alan DeKok.