Subject: Re: "Last Look" at the RADIUS Design Guidelines document

From: Avi Lior <[email-masked]>
Date: Sun, 17 Jan 2010 06:59:21 -0500

> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is thus misleading and should be fixed or removed.

  That statement is simply not true under any objective definition of
reality.
(Avi) but Alan I am paraphresing your own statement and now you are saying that that is not what you said????  Take a look at the previous email (I can't paste it cause I am on a bb)

----- Original Message -----
From: Alan DeKok <[email-masked]>
To: Avi Lior
Cc: David B. Nelson <[email-masked]>; [email-masked] <[email-masked]>
Sent: Sun Jan 17 05:54:42 2010
Subject: Re: "Last Look" at the RADIUS Design Guidelines document

Avi Lior wrote:
> But you didnt answer the question.

  The question I answered was "why doesn't the section on complex types
have any text about application layers".  My response was direct and to
the point.  *That* point.

  So... you switched the topic to "but complex attributes require code
changes!"  And "But Alan is *denying* they require code changes!"

  It's damning evidence as to how weak your position is.

> In the next paragraph you state "one of the fundamental goals of RADIUS protocol design...."  First what is the purpose of that paragraph - it really makes no recommendations what so ever.

  It explains the rationale behind the recommendations.  And it's
clearly useless, just like most of my responses here.

> Also based on the specific comment in this email dont you think that paragraph is missing some of the information you offer in this email.

  Nope.

> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is thus misleading and should be fixed or removed.

  That statement is simply not true under any objective definition of
reality.

  As before, I refer you to my earlier messages that discuss this exact
topic.

  Alan DeKok.
h�{.n�+���zwZ��,j��������ު笶�l��_��0��m��(�ۧ���r��z)ڲ)���b�欶�z���^���w&�r�zm���(��b��?��b�Ǳ�

---

From: Alan DeKok <[email-masked]>
Date: Sun, 17 Jan 2010 14:23:37 +0100

Avi Lior wrote:
> but Alan I am paraphresing your own statement

  I don't see how.  I said red, you say blue.  There's a teensy
difference between the two.

> and now you are saying that that is not what you said????

  I'm saying your paraphrasing doesn't match my words.  In fact, it's
nearly the opposite of what I said.

  The confusion here seems to be that you appear to believe:

 "complex attributes" == "external application processing of data".

  This is not true.  As my earlier messages said, many implementations
can process complex data themselves, and don't need external
applications to do that for them.

  This goes back to the root cause of the disagreement:  The document
explains one model of RADIUS.  You are arguing that this model is no
longer applicable.  You want to *require* a newer model.

  See Dave Nelsons message for a different response to this request.

  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: Avi Lior <[email-masked]>
Date: Sun, 17 Jan 2010 14:51:38 -0500

So here is the thread 

Your wrote....
> On 14-01-2010, at 11:16 , Alan DeKok wrote:
>> Your suggestion is *denying* the possibility that RADIUS servers can
>> process complex attributes themselves.  Some people have servers that
>> are capable of encoding and decoding complex types without resorting to
>> adding application layers.

In response I wrote....
> Because according to you, a RADIUS server can be constructed that can encode and decode complex types without resorting to adding application layers and presumably even new code.  The paragraph is…

Your response to the above....

 That statement is simply not true under any objective definition of reality.

My response....

(Avi) but Alan I am paraphresing your own statement 

Your response...

> difference between the two.

(avi) and now you are saying that that is not what you said???? 

Your response...

> nearly the opposite of what I said.

I dont know but I think this accurately reflects the conversation.

In any case.... you continued ....and I want to repsond to you.

> "complex attributes" == "external application processing of data".

No not at all.   
>  This is not true.

I agree.

>  As my earlier messages said, many implementations

Correct.
> longer applicable.  You want to *require* a newer model.

No the issue is that the document does not explain this model -- and I want it to.  In fact it says the opposite.  And once again I will put in the paragraph that is the offending paragraph....It needs to reflect the statement that complex types can also be handled by these RADIUS server without code change.

   One of the fundamental goals of the RADIUS protocol design was to
   allow RADIUS servers to be configured to support new attributes
   without requiring server code changes.  RADIUS server implementations
   typically provide support for basic data types, and define attributes
   in a data dictionary.  This architecture enables a new attribute to
   be supported by the addition of a dictionary entry, without requiring
   RADIUS server code changes.

You can simply add something like this to the end of that paragraph:

Complex attributes  may also be added to the dictionary such that the RADIUS server does not require code changes to process these attributes.

---

From: "Dave Nelson" <[email-masked]>
Date: Sun, 17 Jan 2010 15:08:28 -0500

> Complex attributes may also be added to the dictionary such that the
> RADIUS server does not require code changes to process these attributes.

This may be true of a class of newer RADIUS server implementations, those
with a "dynamic" data dictionary, but it is not true of another class of
more "traditional" RADIUS servers, and it's those that this section intends
to address.

As I said in a previous post, the plan is to recommend (via this BCP) that
newly design RADIUS attributes not contribute to rendering a significant
installed base of deployed RADIUS servers effectively obsolete.

If we were talking about VSAs, this wouldn't be a concern.  We're talking
about standards-tack attributes.  If all you have to worry about is the
class of "enhanced capability" RADIUS servers, then I would agree.  In the
IETF, we need to take a broader view, I think.

To repeat myself (this seems to be in vogue) it's a matter of either
revising the protocol or extending the protocol.  RADEXT has the charter to
do the latter and not the former.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Mon, 18 Jan 2010 11:34:22 +0100

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Dave Nelson
> Sent: 17 January 2010 21:08
> To: [email-masked]
> Subject: RE: "Last Look" at the RADIUS Design Guidelines document
> 
> This may be true of a class of newer RADIUS server 
> implementations, those with a "dynamic" data dictionary, but 
> it is not true of another class of more "traditional" RADIUS 
> servers, and it's those that this section intends to address.

This would precisely be what one calls an "implementation choice". I'd
again suggest that the Radius WG could do much better then trying to
deal with issues that are actually implementation issues, which does go
to the heart of a lot of the arguments on this thread.

-Woj.

> 
> As I said in a previous post, the plan is to recommend (via 
> this BCP) that newly design RADIUS attributes not contribute 
> to rendering a significant installed base of deployed RADIUS 
> servers effectively obsolete.
> 
> If we were talking about VSAs, this wouldn't be a concern.  
> We're talking about standards-tack attributes.  If all you 
> have to worry about is the class of "enhanced capability" 
> RADIUS servers, then I would agree.  In the IETF, we need to 
> take a broader view, I think.
> 
> To repeat myself (this seems to be in vogue) it's a matter of 
> either revising the protocol or extending the protocol.  
> RADEXT has the charter to do the latter and not the former.
> 
> 
> 
> --
> to unsubscribe send a message to 
> [email-masked] with the word 'unsubscribe' in 
> a single line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Mon, 18 Jan 2010 12:10:55 +0100

Wojciech Dec (wdec) wrote:
> This would precisely be what one calls an "implementation choice".

  Or "15 years of RADIUS practice".

> I'd

  Then my position has not been sufficiently clear.

  The issue is whether the document should describe only a subset of
implementations.

  There have been repeated statements that the document describes a
model which does not apply to current implementations.  These statements
are false.

  The follow-on requirement is to remove text which describes the
traditional model, and to insert text which describes a "modern" model.
 The resulting document would describe a significantly reduced subset of
RADIUS implementations.

  The document would cease to be a RADIUS BCP.  It would become an SDO
BCP, and would describe practices that are SDO specific.

  If you want such a document, go write it in an SDO.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Mon, 18 Jan 2010 10:34:00 -0500

>   If you want such a document, go write it in an SDO.

I'm not sure that's the best possible advice, either.  The "preferred future
state" is a more unified RADIUS data model, not a more fragment one.

While SDOs are certainly free to follow specific guidelines for RADIUS work
that is SDO-specific, I'm not aware that we have SDO-specific RADIUS server
implementations.  Or at the very least, we would likely run into the same
set of issues when attempting to deploy these new attributes on legacy
RADIUS servers.  For that reason, I'm not sure such a "walled garden"
approach would really work.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 01:59:23 +0100

> state" is a more unified RADIUS data model, not a more fragment one.

  I agree that's the preferred future state.  But the "extended
attributes" document which defines IETF RADIUS complex types isn't finished.

  The guidelines document can therefore discuss nothing more than the
current state of RADIUS: basic data types, and "ad hoc" complex types
(RFC 4679, 5090, etc.)

  I have no objection to adding complex types in this WG.  But it hasn't
happened yet, and the "guidelines" document isn't the place to define them.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Mon, 18 Jan 2010 23:05:48 -0500

See inline...

> more "traditional" RADIUS servers, and it's those that this section intends

It should be made clear.  Maybe it says that somewhere in the document. 

As a minimum it must be clearly stated that the intent of the BCP is to protect legacy. 
"the recommendation of this BCP are applicable in deployements that utilize legacy RADIUS servers/clients...."

Define legacy RADIUS servers/clients and I would be okay.

IMO the BCP should make a distinction and address both legacy and newer RADIUS servers.  Bu

> about standards-tack attributes.
Okay then we should make sure that the document makes this clear.

Perhaps we can clarify this -- In section 2.1 and section 2.2 or in section 2.0

>  If all you have to worry about is the
Which is fine but I think you have to document this distinction.  That is a problem with this BCP only people who read these long email threads will understand what is really going on.  If the intent is to protect the existing radius base then we should be clear about that.

---

From: Avi Lior <[email-masked]>
Date: Tue, 19 Jan 2010 00:26:53 -0500

>  Or "15 years of RADIUS practice".

Some people have evolved their RADIUS practice....

>  The issue is whether the document should describe only a subset of

It is describing a subset -- and its not clear that its doing that.

> model which does not apply to current implementations.  These statements

That is true.  Some vendors and deployments are totally happy with legacy RADIUS servers/clients.

> The resulting document would describe a significantly reduced subset of
If you want to cover legacy then be very explicit about that.

If you want to cover both then there is more work to do.

>  If you want such a document, go write it in an SDO.
IETF is an SDO by David's argument or yours - cant remember which.

But I would be okay if the document clearly stated in "Blinking 50 pt font" that it is applicable to deployements that utilize legacy RADIUS servers/clients....in the abstract and the applicability section.

---

From: Avi Lior <[email-masked]>
Date: Tue, 19 Jan 2010 00:28:23 -0500

See inline...

> more "traditional" RADIUS servers, and it's those that this section intends
Okay...
Okay then we should make sure that the document makes this clear.
The problem is the document talks about SDOs.  SDO work on VSAs not standard track attributes. 

>From the abstract we have:
"reviewers of future RADIUS attribute specifications, both within the
   IETF as well as other Standards Development Organizations (SDOs)."

> IETF, we need to take a broader view, I think.
Which is fine but I think you have to document this distinction.  That is a problem with this BCP only people who read these long email threads will understand what is really going on.

---

From: Avi Lior <[email-masked]>
Date: Tue, 19 Jan 2010 00:26:54 -0500

> current state of RADIUS: basic data types, and "ad hoc" complex types
The current state of RADIUS is not the legacy state that the BCP seems to be about either. As you pointed out - it applies to 40% of the market.  Lets me totally clear what this BCP is for....

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 00:48:46 -0500

> Which is fine but I think you have to document this distinction.
> That is a problem with this BCP only people who read these long
> email threads will understand what is really going on.  If the 
> intent is to protect the existing radius base then we should be
> clear about that.

The primary intent is to promote *extension* of the RADIUS protocol rather
than *revision* of the RADIUS protocol.  That is to say, to use
well-accepted mechanisms for forward-backward protocol extensions, rather
than simply revising the data model without any concern about compatibility
with existing deployments.  This is the way that IETF-Standards track
protocols are "evolved", via extension, rather than via revision.  Certainly
interoperability with a broad range of implementations, some of which may
qualify for the term "legacy", is an important factor.  That's one reason
that vendors like to implement standards -- they don't expect them to change
in non-backward-compatible ways over time.

There are examples of protocol revision in the IETF, of course, such as IPv4
and IPv6, but that's not what we're about here.  We already have RADIUS V2
and it's called Diameter.

I fail to understand the point of most of the arguments against this BCP,
unless it's to "protect" a "revised" dialect of RADIUS as implemented in
some "modern" RADIUS server implementations.  If RADIUS has become
fragmented into non-interoperable dialects, I think that would be very sad
indeed.  In that case, I don't see the advantage of legitimizing that
fragmentation by trying to "gut" the core recommendations of this BCP or to
narrow its scope to some "legacy" or "historic" segment of the RADIUS server
market.  It seems to me that's where this discussion is ultimately leading
us.

Have I missed an important point somewhere?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 07:44:36 +0100

Avi Lior wrote:
> The current state of RADIUS is not the legacy state that the BCP seems
> to be about either. As you pointed out - it applies to 40% of the market.

  Stop lying about what I said.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Tue, 19 Jan 2010 02:22:47 -0500

In an email long ago I  wrote:
>>> Not the old RADIUS model but rather the one that we are all living
>>> with today.  That model is not really different then Diameter.

This was your reply to the above:

 40% (or more) of current RADIUS deployments would disagree.
On 19-01-2010, at 14:44 , Alan DeKok wrote:

Can you explain why you think I was lying???

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 08:38:12 +0100

>  40% (or more) of current RADIUS deployments would disagree.

  i.e. 40% don't have "extended" capabilities.

  This is *not* the same thing as saying that the other 60% lack
"traditional" capabilities, and are therefore not addressed by the document.

  Take a logic course.

> Can you explain why you think I was lying???

  There are two ways to lie convincingly.  One is to tell the truth, and
make it sound like a lie.  Another is to tell *part* of the truth, and
make it sound like the *whole* truth.

  On Jan. 14, I sent a message containing the text:

---
  As I have said repeatedly, the document addresses the capabilities of
100% of the deployments.
---

  Which directly refutes your claim that I said the document applies to
only a subset of the deployments.

  However, if you really believe that the document does not address
*any* capabilities of 60% of RADIUS deployments, then this is great
news!  You have just defined those deployments as *not* implementing
RADIUS.  Your objections to a *RADIUS* BCP are therefore no longer
applicable, and can be summarily rejected.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Tue, 19 Jan 2010 03:15:56 -0500

>  i.e. 40% don't have "extended" capabilities.

What do you mean by "extended" capabilities?

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 10:15:52 +0100

> What do you mean by "extended" capabilities?

  Can we just stop this game?

  Alan DeKok.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 19 Jan 2010 10:27:08 +0100

Would it be possible for Alan and Avi to take it from this point of the
discussion and try to write and agree on a few paragraphs of text which
describe what this BCP covers and what is not covered and left out
possibly for future work? 

Dan

> [mailto:[email-masked]] On Behalf Of Avi Lior
> Sent: Tuesday, January 19, 2010 6:06 AM
> To: Dave Nelson
> Cc: [email-masked]
> > This may be true of a class of newer RADIUS server implementations, 
> > those with a "dynamic" data dictionary, but it is not true 
> of another 
> > class of more "traditional" RADIUS servers, and it's those 
> that this 
> > section intends to address.
> 
> "the recommendation of this BCP are applicable in 
> deployements that utilize legacy RADIUS servers/clients...."
> 
> this BCP) 
> > that newly design RADIUS attributes not contribute to rendering a 
> > significant installed base of deployed RADIUS servers 
> effectively obsolete.
> > 
> > If we were talking about VSAs, this wouldn't be a concern.  We're 
> > talking about standards-tack attributes.
> >  If all you have to worry about is the class of "enhanced 
> capability" 
> > RADIUS servers, then I would agree.  In the IETF, we need to take a 
> > broader view, I think.
> Which is fine but I think you have to document this 
> distinction.  That is a problem with this BCP only people who 
> read these long email threads will understand what is really 
> going on.  If the intent is to protect the existing radius 
> base then we should be clear about that.  
> 
> 
> --

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 10:40:22 +0100

> Sent: 19 January 2010 06:49
> > That is a problem with this BCP only people who read these 
> long email 
> > threads will understand what is really going on.  If the 
> intent is to 
> > protect the existing radius base then we should be clear about that.
> 
> The primary intent is to promote *extension* of the RADIUS 
> protocol rather than *revision* of the RADIUS protocol.  That 
> is to say, to use well-accepted mechanisms for 
> forward-backward protocol extensions, rather than simply 
> revising the data model without any concern about 
> compatibility with existing deployments.  This is the way 
> that IETF-Standards track protocols are "evolved", via 
> extension, rather than via revision.  Certainly 
> interoperability with a broad range of implementations, some 
> of which may qualify for the term "legacy", is an important 
> factor.  That's one reason that vendors like to implement 
> standards -- they don't expect them to change in 
> non-backward-compatible ways over time.
> 
> There are examples of protocol revision in the IETF, of 
> course, such as IPv4 and IPv6, but that's not what we're 
> about here.  We already have RADIUS V2 and it's called Diameter.
> 
> I fail to understand the point of most of the arguments 
> against this BCP, unless it's to "protect" a "revised" 
> dialect of RADIUS as implemented in some "modern" RADIUS 
> server implementations.  If RADIUS has become fragmented into 
> non-interoperable dialects, I think that would be very sad 
> indeed.  In that case, I don't see the advantage of 

Woj> The BCP steers to protect more radius server *implementations* and
not protocol interoperability. That's evidenced by the talk of Radius
implementations of % figures in this thread.  
It's not unreasonable to expect that whoever wants to use a complex
attribute (against the recommendations of this BCP will at this stage)
will a) upgrade all their clients (1000s) and b) check their radius
server + make changes if needed. Given that a) is a task of several
orders of magnitude larger than b), it would seem that the stance to
protect old radius server implementations at all costs is highly
unbalanced. 
To put it in other words; if a radius server does not support an
attribute that is deemed useful by an operator, it will get changed,
period. 
The point is thus, that the main value of Radius is in what the protocol
does and not entirely in in how it does it. With the BCP, without a
reference to "historic" or some other term to describe that server
segment, we're constraining the "how" for all time to come without
giving a path to evolve the "what".

-Woj.

> legitimizing that fragmentation by trying to "gut" the core 
> recommendations of this BCP or to narrow its scope to some 
> "legacy" or "historic" segment of the RADIUS server market.  
> It seems to me that's where this discussion is ultimately leading us.
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 11:10:01 +0100

Typo correction inline... 

> [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
> Sent: 19 January 2010 10:40
> To: Dave Nelson; [email-masked]
> > The primary intent is to promote *extension* of the RADIUS protocol 
> > rather than *revision* of the RADIUS protocol.  That is to 
> say, to use 
> > well-accepted mechanisms for forward-backward protocol extensions, 
> > rather than simply revising the data model without any 
> concern about 
> > compatibility with existing deployments.  This is the way that 
> > IETF-Standards track protocols are "evolved", via extension, rather 
> > than via revision.  Certainly interoperability with a broad 
> range of 
> > implementations, some of which may qualify for the term 
> "legacy", is 
> > an important factor.  That's one reason that vendors like 
> to implement 
> course, such 
> > as IPv4 and IPv6, but that's not what we're about here.  We already 
> > have RADIUS V2 and it's called Diameter.
> > 
> against this 
> > BCP, unless it's to "protect" a "revised"
> > dialect of RADIUS as implemented in some "modern" RADIUS server 
> > implementations.  If RADIUS has become fragmented into 
> not protocol interoperability. That's evidenced by the talk 
> of Radius implementations of % figures in this thread.  
> It's not unreasonable to expect that whoever wants to use a 
> complex attribute (against the recommendations of this BCP 
> at this stage) will a) upgrade all their clients (1000s) 
> and b) check their radius server + make changes if needed. 
> Given that a) is a task of several orders of magnitude larger 
> than b), it would seem that the stance to protect old radius 
> server implementations at all costs is highly unbalanced. 
> To put it in other words; if a radius server does not support 
> an attribute that is deemed useful by an operator, it will 
> get changed, period. 
> The point is thus, that the main value of Radius is in what 
> the protocol does and not entirely in in how 
*servers* do it. With 
> the BCP, without a reference to "historic" or some other term 
> to describe that server segment, we're constraining the "how" 
> for all time to come without giving a path to evolve the "what".
> 
> -Woj.
> 
> "legacy" or 
> > "historic" segment of the RADIUS server market.
> > [email-masked] with the word 'unsubscribe' 
> in a single 
> > line as the message text body.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 11:13:02 +0100

Wojciech Dec (wdec) wrote:
> attribute (against the recommendations of this BCP

  The BCP recommends against complex attributes when the traditional
data types would be sufficient for expressing the data.

  Where traditional data types are insufficient, the BCP allows complex
types.

  I agree.

> giving a path to evolve the "what".

  The BCP gives such a path: complex types are permitted.

  See Appendix B for a series of reviews of existing attributes.  The
reviews say things like:

... Therefore, this complex data type is acceptable in this situation.

  I have no idea how anyone can conclude that it forbids complex types.

  Alan DeKok.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 14:14:46 +0100

> possibly for future work? 

  The document already says what it covers.  To summarize:

1) RADIUS has traditionally had a few simple data types which are used
   by most attributes (90% or more)

2) A small percentage of attributes have "complex" types that
   are not one of the "simple" types defined in (1)

3) The BCP recommends continuing practice (1) where possible

4) the BCP explicitly acknowledges that there are situations where
   practice (2) is acceptable.

5) the BCP does not forbid anyone from engaging in practice (2)

  That's really it.  I'm not sure how to reach a common ground that
excludes any of the above points.

  All of the discussion of dictionaries and server capabilities is
secondary to the above points.

  We *could* add text about "modern" servers.  It would look like:

---
  Many servers can define attributes via more powerful methods than the
traditional RADIUS dictionaries.  However, this capability does not
change the above recommendation to prefer simple types over complex ones.
---

  That's the point of contention.  We could *remove* all of the text in
the document about traditional dictionaries, and insert pages of text
describing how wonderful "modern"" systems are.  It doesn't *matter* how
capable or how incapable the implementations are.

  The BCP will still recommend simple designs over complex ones.

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 08:38:30 -0500

> Woj> The BCP steers to protect more radius server *implementations*
> and not protocol interoperability.

I think you perhaps underestimate the role that standards play in
maintaining multi-vendor interoperability, not only at a given snap-shot in
time, e.g. at a plug-fest, but over time in the marketplace, such that
various generations of product implemented to the same standard continue to
interoperate over time -- in the case of long-standing "legacy" protocols
like RADIUS, over a very long time.

> attribute that is deemed useful by an operator, it will get changed,

One reason that customers like standards is that they provide a "level
playing field".  While it's true that customers sometimes value increased or
specific functionality over standardization and interchangeability, in my
experience they will always opt for the more widely interoperable product
when it meets their needs.  There is an inherent value in a strict standards
process.

> does and not entirely in in how it does it.

I disagree heartily.  The value in RADIUS (as defined in the Standard-Track
RFC series) is exactly in how it does it, at least in terms of all of the
on-the-wire encodings.  That's what differentiates a standard protocol from
a proprietary protocol.

> With the BCP, without a reference to "historic" or some other term
> to describe that server segment, we're constraining the "how" for all
> time to come without giving a path to evolve the "what".

I don't think that the RADEXT WG is chartered to deprecate "traditional"
RADIUS, and its on-the-wire data model, to "historic" status.  I will point
out that the RADEXT WG indeed *has* a mechanism for changing the "how".
That mechanism is the RADIUS Extended Attribute document.

My guess as to why that mechanism isn't universally seen as "the way
forward" is that (a) the draft is currently stagnant, for lack of editorial
initiative, and (b) there are already implementations of the advanced
features using the traditional attribute format, in some cases in a way that
the BCP would not recommend.

We can easily address the former issue, by redirecting some energy from this
debate toward finishing the RADIUS Extended Attributes document.
Unfortunately, I see no easy way to alleviate the latter issue.  Well, there
*is* a way, I suppose, and that's to limit the scope of applicability of the
BCP.  I don't believe that's the "right thing to do".

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 15:35:58 +0100

> Sent: 19 January 2010 14:39
> I think you perhaps underestimate the role that standards 
> play in maintaining multi-vendor interoperability, not only 
> at a given snap-shot in time, e.g. at a plug-fest, but over 
> time in the marketplace, such that various generations of 
> product implemented to the same standard continue to 
> interoperate over time -- in the case of long-standing 
> "legacy" protocols like RADIUS, over a very long time.

I think you're confusing protocol with implementation. An interoperable
protocol and a standard implementation are different things. One can
(and does!) have plenty of protocols that are multi-vendor
interoperabile without a standardized implementation, and one can have a
standard implementation that is NOT interoperable (case in hand, Radius
server implementation A does not support attribute Z which another
radius server implemented in the same way does).
To say it differently, whether one codes up a Radius server to use a
data-type cast dictionary or not, it is not what makes the server
interoperable with other Radius devices. 
> One reason that customers like standards is that they provide 
> a "level playing field".  While it's true that customers 
> sometimes value increased or specific functionality over 
> standardization and interchangeability, in my experience they 
> will always opt for the more widely interoperable product 
> when it meets their needs.  There is an inherent value in a 
> strict standards process.

I see no point in defending an *implementation* as a standard, why do
you?

> 
> > The point is thus, that the main value of Radius is in what the 
> > protocol does and not entirely in in how it does it.
> 
> I disagree heartily.  The value in RADIUS (as defined in the 
> Standard-Track RFC series) is exactly in how it does it, at 
> least in terms of all of the on-the-wire encodings.  That's 
> what differentiates a standard protocol from a proprietary protocol.

As per my corrected mail, I meant "how Radius servers do it" (is the
"how" that doesn't matter)

> 
> > With the BCP, without a reference to "historic" or some 
> other term to 
> > describe that server segment, we're constraining the "how" for all 
> RADIUS, and its on-the-wire data model, to "historic" status. 
>  I will point out that the RADEXT WG indeed *has* a mechanism 
> for changing the "how".

Well, I don't think anyone proposed that. Instead, the proposal at least
as I understood it to be (and support), is that the design guidelines
should not be used as bar/ban/stick on complex attributes design and
should have text to that effect. And, as already pointed out by Avi,
placing such work in the extended attribute doc without any change to
the current wording of the BCP is an issue.
> 
> My guess as to why that mechanism isn't universally seen as 
> "the way forward" is that (a) the draft is currently 
> stagnant, for lack of editorial initiative, and (b) there are 
> already implementations of the advanced features using the 
> traditional attribute format, in some cases in a way that the 
> BCP would not recommend.

An old IETF mantra used to say that running code matters. The fact that
there are multi-vendor production networks that use a galore of complex
attributes, albeit custom defined is perhpas evidence to how off-course
the WG has gone in this area. It would be nice to give the customizers
some structure/guidance instead...

> 
> We can easily address the former issue, by redirecting some 
> energy from this debate toward finishing the RADIUS Extended 
> Attributes document.
> *is* a way, I suppose, and that's to limit the scope of 
> applicability of the BCP.  I don't believe that's the "right 
> thing to do".

The current set-up looks like to me like this: During the (undoubtedly
lengthy) discussions around complex attributes under the "extended
attributes" banner, someone will claim "these attributes don't work with
my foobar radius server implementation and are against the BCP of the WG
itself". Even after such design, one will have a BCP that says one thing
and another doc something else. This will be confusing to anyone trying
to make sense of it.
Why don't you see this as an issue?

-Woj.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 16:27:26 +0100

Wojciech Dec (wdec) wrote:
> should have text to that effect.

  It does not bar complex attributes.

  It *does* recommend against complex systems where simpler ones would
suffice.  This is an engineering practice going back 50+ years.

> itself".

  Which will be false.

  Multiple people supporting the guidelines document have agreed that
complex attributes belong in the "extended attributes" document.  Use
*that* to defend the push for complex attributes.

> Even after such design, one will have a BCP that says one thing

  You're putting a pretty low bar on the intelligence of anyone reading
the RFCs.  The IETF has a process where one document can be marked as
"updating" another.  WG progress shouldn't stop because one person is
confused about how that works.

  Alan DeKok.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 10:42:40 -0500

On Jan 19, 2010, at 9:35 AM, Wojciech Dec (wdec) wrote:

> It would be nice to give the customizers some structure/guidance  
> instead...

Exactly!  We appear to agree on the goal.  I think we may still  
disagree on the specific content of that guidance.  My recommendation  
for guidance content is the BCP (pretty much as it stands) for  
"traditional" RADIUS attributes and the RADUS Extended Attribute  
format for additional levels of customization.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 16:56:39 +0100

> 
>   Multiple people supporting the guidelines document have 

Who would that be?

> agreed that complex attributes belong in the "extended 
> attributes" document.  Use

Having a BCP document which states "don't do it", along with some
dubious arguments (eg security) really doesn't help.

> 
> > Even after such design, one will have a BCP that says one thing and 
> > another doc something else. This will be confusing to 
> anyone trying to 
> > make sense of it.
> 
>   You're putting a pretty low bar on the intelligence of 
> anyone reading the RFCs.  The IETF has a process where one 
> document can be marked as "updating" another.  WG progress 
> shouldn't stop because one person is confused about how that works.

Given that an update to the BCP is planned before it's even been
published makes one wonder as to whether it's good to have it published
in its current form. Which this thread is all about.

-Woj.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 11:07:45 -0500

> in its current form. Which this thread is all about.

I think you misunderstood Alan's comment.  The WG arrived at the  
consensus position that the BCP should address "traditional" RADIUS  
only and that any guidelines for the Extended Attribute format usage  
should be included in that document.  This is a document modularity  
and separation of concerns issue, not a statement about the  
correctness or longevity of the BCP.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 17:14:36 +0100

You carefully deleted the real argument that I had in my message:

>>  It *does* recommend against complex systems where simpler ones
>> would suffice.  This is an engineering practice going back 50+ years.

  Was that intentional, or accidental?

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 18:24:28 +0100

> [mailto:[email-masked]] On Behalf Of David B. Nelson
> Sent: 19 January 2010 17:08
> > published makes one wonder as to whether it's good to have it 
> > published in its current form. Which this thread is all about.
> 
> I think you misunderstood Alan's comment.  The WG arrived at 
> the consensus position that the BCP should address 
> "traditional" RADIUS only and that any guidelines for the 
> Extended Attribute format usage should be included in that 
> document.  This is a document modularity and separation of 
> concerns issue, not a statement about the correctness or 
> longevity of the BCP.

It comes down to what "tradional" means. Legacy is not too far off a
similar word, so what's wrong with saying "the recommendation of this
BCP are applicable in deployements that utilize legacy RADIUS
servers/clients...."?

BTW The original comment said "The IETF has a process where one document
can be marked as "updating" another", in the context of the BCP and
extended attributes drafts. That doesn't leave much room for
misinterpretation.

-Woj.

---

From: "David B. Nelson" <[email-masked]>
Date: Tue, 19 Jan 2010 13:21:54 -0500

On Jan 19, 2010, at 12:24 PM, Wojciech Dec (wdec) wrote:

> It comes down to what "tradional" means.

Traditional means what RFC 2865 *says*, exclusive of what various  
people assume / assert it allows by virtue of what it fails explicitly  
prohibit.

> Legacy is not too far off a similar word, so what's wrong with  
> saying "the recommendation
> of this BCP are applicable in deployements that utilize legacy  
> RADIUS servers/clients...."?

Why would we want to limit the scope in *that* way?  Legacy is close  
to "historic" and I don't think that the IETF has consensus to dismiss  
a class of RADIUS deployments as "legacy", "historic" or generally of  
lesser relevance.

> extended attributes drafts. That doesn't leave much room for  

You're parsing specific words in a single reply out of a very long  
thread, as if they were court testimony or holy writ.  I'm telling you  
*why* the documents are broken down the way they are, as matter of WG  
consensus.

What Alan means is that we need not be overly concerned about what the  
BCP might inadvertently be construed to say about the usage of  
Extended Attributes, because the Extended Attributes document will  
provide its *own* usage guidelines for those attributes.  Nothing more.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 19 Jan 2010 20:04:22 +0100

> From: Alan DeKok [mailto:[email-masked]] 
> Sent: 19 January 2010 17:15
> To: Wojciech Dec (wdec)
> Cc: Dave Nelson; [email-masked]

Yes, it was intentional because:
a) Expressing complex data using simple attributes generally requires an
elaborate rule set to be present, which happens to be where the
complexity is. It so happens that radius doesn't robustly define such
rules, and even simple ones like tags are flagged as an issue (in the
BCP no less). Thus using simple attributes actually makes the system
(composed of protocol + whatever sits on top) more complex and less
robust because it's the custom "on top" piece that has to encode any
such rules. The BCP doesn't hence provide useful guidance on how simple
attributes can be constructed to do something more complex, but we know
that.
B) it was a rather flippant remark

-Woj.

---

From: Alan DeKok <[email-masked]>
Date: Tue, 19 Jan 2010 21:45:18 +0100

Wojciech Dec (wdec) wrote:
> elaborate rule set to be present,

  A raft of existing RFCs would seem to disprove that idea.

> B) it was a rather flippant remark

  I suppose if you don't care that what you say is true, flippant
remarks are apropos.

  Alan DeKok.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 20 Jan 2010 09:19:29 +0100

> Sent: 19 January 2010 21:45
> To: Wojciech Dec (wdec)
> > a) Expressing complex data using simple attributes 
> generally requires 
> > an elaborate rule set to be present,
> 

Just by making attributes simple does not mean that the complexity of
representing an elaborate data structure goes away - it's moved
elsewhere. 
Furthermore, no Radius RFC does the job satisfactorily, vide rfc 5090. 

-Woj.

---

From: "Dave Nelson" <[email-masked]>
Date: Wed, 20 Jan 2010 07:30:27 -0500

Wojciech Dec writes...

> Just by making attributes simple does not mean that the complexity
> of representing an elaborate data structure goes away - it's moved
> elsewhere. Furthermore, no Radius RFC does the job satisfactorily...

RADIUS was not designed to represent complicated provisioning data, data
sets with lots of inter-related elements, in any reasonably compact,
efficient and standardized format.  That's why I personally hold out hope
that the RADIUS Extended Attribute work will seriously address that issue
and will do so soon.  To say that it's overdue is an understatement.

---

From: Avi Lior <[email-masked]>
Date: Thu, 21 Jan 2010 23:24:26 -0500

> and will do so soon.  To say that it's overdue is an understatement.

But things are now different.  So it goes back to stating clearly what is this document really about.  
Is it to protect existing legacy deployments or is it to provide guidelines to new RADIUS designs.

I would think that the BCP that would be published today will be reflecting the new RADIUS designs but if that is not the case then we need to be clear about the applicability of this document.  I am okay with a BCP that applies to protecting traditional RADIUS usage but we need to be clear about it.

Can we start with this then...

---

From: Alan DeKok <[email-masked]>
Date: Fri, 22 Jan 2010 08:29:10 +0100

> Can we start with this then...

  I see your false dichotomy and raise you one:

  Is the purpose of your post to be intentionally offensive, or did you
simply not see the dozens of posts explaining the document?

  Alan DeKok.

---

From: "Dave Nelson" <[email-masked]>
Date: Fri, 22 Jan 2010 08:50:51 -0500

Avi Lior writes...

> I would think that the BCP that would be published today
> will be reflecting the new RADIUS designs but if that is not
> the case then we need to be clear about the applicability of
> this document.  I am okay with a BCP that applies to protecting
> traditional RADIUS usage but we need to be clear about it.
> 

I'm not sure what this really means.  I *suspect* that it provides a
convenient way to dismiss the document as being irrelevant when doing new
RADIUS work in "walled gardens" of "current technology" RADIUS server
deployments.

The thing about protocols is that they are simply words on paper.  A
*protocol* can not be said to have the property of multi-vendor
interoperability.  Only *implementations* of protocols can be tested to see
if interoperability is obtained.  Given that multi-vendor interoperability
is a key concern of IETF Standards-Track protocols, we can't dispense with
discussing implementations.

If a sufficient number of implementations take advantage of any given
property of a protocol, such the simplicity of that protocol's data model,
that property, e.g. the data model, becomes an integral element of the
protocol.

That's the case here.  The simple data model is an inherent property of the
RADIUS protocol by virtue of many implementations having relied upon it, if
for no other reason.  If we want to expand the data model, to be more rich
and complex, we therefore need to either revise or extend the protocol.

IMO, We can't simply say that the past is irrelevant, and we're going to
define a new version of the protocol that works well with a class of newly
designed implementations.  That would violate the basic tenets of
multi-vendor interoperability.

I'm all *for* expanding the RADIUS data model.  In fact, my personal
preferences in that regard extend beyond what the WG has achieved consensus
to support.  However, we need to do that within the constraints of a
reasonable protocol evolution methodology.  Either we add a protocol version
number negotiation methodology or we use an "escape" mechanism such as the
Extended Attribute format.

I think that simply ignoring the interoperability considerations of a
significant class of implementations, by labeling them "traditional",
legacy" or "historic" (or any other synonym) is the wrong thing to do.

---

From: Avi Lior <[email-masked]>
Date: Fri, 22 Jan 2010 17:53:06 -0500

The tone of your responses is what I find offensive....

No Alan, the purpose of all my post it to get the document to be the best possible document.  One would start wondering what is the purpose of your posts...is it to protect your implementation, you beloved FreeRadius...hmmmmm I think it is.

We have seen this type of shameless self promoting from you before: one just needs to look at the section 2.1.2 of RFC5080 with its shameless taunting of what a wonderful job FreeRadius did.  NOT really actually ... a pretty obvious non-novel solution.  Such text has no place in an RFC. 

I am trying to keep this professional and not personal. You persist with personal, patronizing attacks on me and my comments...but if you want to continue down the lines of personal attacks and the chairs and AD are obviously happy with this...then I have better things to do.

If I were the only one that is raising these issues I would just walk away.  But I am NOT the only one.  So stop the personal attacks on my criticism of this body of work.

And to Bernard, and David act like chairs.

And to Dan, Bernard, David and Alan....I take you to the BAD email discussion with Glen. This is a caustic WG...Great job guys.

---

From: "David B. Nelson" <[email-masked]>
Date: Fri, 22 Jan 2010 18:45:00 -0500

> The tone of your responses is what I find offensive....

I think that the participants in this discussion are effectively at an  
impasse, that is to say they are talking past each other, attempting  
to make and re-make their points without actually listening to  
others.  That causes patience to fray and the tone to become "edgy".   
Let's try to dial this down a little.

> One would start wondering what is the purpose of your posts...

I think there may be multiple agendas to "protect" something, and as  
is sadly too often the case in standards body debates, the purpose of  
the debate is to "win", not to edify.

> ... the chairs and AD are obviously happy with this...

I see no evidence that the chairs or AD are *happy* about this.    
Bernard has already issued a tongue-in-cheek remark about the  
"frankness" of the discussion.  That was a polite hint.

> ...I take you to the BAD email discussion with Glen.

Exactly why are you attempting to drag poor Glen into this debate?  :-)

---

From: Alan DeKok <[email-masked]>
Date: Sat, 23 Jan 2010 00:54:26 +0100

> The tone of your responses is what I find offensive....

  Describing competing products as "legacy" wasn't meant as a put-down,
of course.  Describing people as "shameless" wasn't negative, either.

> No Alan, the purpose of all my post it to get the document to be the best possible document.  One would start wondering what is the purpose of your posts...is it to protect your implementation, you…

  You mean that I'm the first vendor in the history of the IETF who is
trying to influence the standards process?  I'm glad I made history.

> If I were the only one that is raising these issues I would just walk away.  But I am NOT the only one.  So stop the personal attacks on my criticism of this body of work.

  Your messages have consistently denigrated other peoples products and
their reasons for recommending simplicity in engineering design.

  This is *despite* the clear agreement of me and others that the RADIUS
model should be updated to meet your needs.

  If you want to keep this on a technical level, the only disagreement
we have is whether or not the updated model is described in this
document or in another one.

  Since the WG already has a document that extends RADIUS, I don't see
why that text should be in a BCP.  Just update the extension document,
and let the BCP move forward.

  Merging the two documents into one would require a charter update, as
both have charter milestones.  If you really want that to happen, stop
trying to "fix" the BCP, and propose instead that the WG be
re-chartered.  If you don't want to merge the two documents, then you
cannot have any objections to the BCP, as all of your concerns are
addressed in the extensions document.

  Alan DeKok.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Sun, 24 Jan 2010 08:49:22 +0100

The AD is unhappy with all discussions that are inefficient and
sometimes are taking personal tones. 

I am making again an appeal to all the participants in the discussion to
focus on the professional aspects of the debate and to abstain from
remarks that can be interpreted as personal. 

I am also reminding the proposal that I have made a week ago. Can you
get together (maybe the two of you - Alan and Avi) and create text to be
added to the current document about what this BCP covers, and what it
does not cover and may be in the scope of future work? Get WG consensus
on this text, have this BCP approved, and recharter the Working Group to
work on what is not covered by the BCP like adding complex types. 

Thanks and Regards,

Dan

> From: Avi Lior [mailto:[email-masked]] 
> Sent: Saturday, January 23, 2010 12:53 AM
> To: Alan DeKok; David Nelson; Bernard Aboba; Romascanu, Dan (Dan)
> Cc: [email-masked]; Glen Zorn
> No Alan, the purpose of all my post it to get the document to 
> be the best possible document.  One would start wondering 
> what is the purpose of your posts...is it to protect your 
> implementation, you beloved FreeRadius...hmmmmm I think it is.
> 
> We have seen this type of shameless self promoting from you 
> before: one just needs to look at the section 2.1.2 of 
> RFC5080 with its shameless taunting of what a wonderful job 
> FreeRadius did.  NOT really actually ... a pretty obvious 
> non-novel solution.  Such text has no place in an RFC. 
> 
> I am trying to keep this professional and not personal. You 
> persist with personal, patronizing attacks on me and my 
> comments...but if you want to continue down the lines of 
> personal attacks and the chairs and AD are obviously happy 
> with this...then I have better things to do.
> 
> If I were the only one that is raising these issues I would 
> just walk away.  But I am NOT the only one.  So stop the 
> personal attacks on my criticism of this body of work.
> 
> And to Dan, Bernard, David and Alan....I take you to the BAD 
> email discussion with Glen. This is a caustic WG...Great job guys.
> 
>

---

From: Alan DeKok <[email-masked]>
Date: Sun, 24 Jan 2010 10:09:55 +0100

Romascanu, Dan (Dan) wrote:
> does not cover and may be in the scope of future work?

  Proposed text is available:

http://git.freeradius.org/ietf/draft-ietf-radext-design-11.txt

  It doesn't address of all Avi's suggestions, but it covers most.

  I'd like to see a review, and suggestions for what else needs addressing.

  Alan DeKok.

---

From: Avi Lior <[email-masked]>
Date: Sun, 24 Jan 2010 08:43:56 -0500

Thank you -- I will provide a review.

---

From: Avi Lior <[email-masked]>
Date: Sun, 24 Jan 2010 08:41:31 -0500

I dont disagree with most of what you are saying...but I want to focus back to the point...

In an exchange on Jan 18 David Nelson wrote...

"This may be true of a class of newer RADIUS server implementations, those
with a "dynamic" data dictionary, but it is not true of another class of
more "traditional" RADIUS servers, and it's those that this section intends
to address."

The document should clearly state what you wrote...otherwise, it will create confusion - as you can see...

Or improve the text to encompass all different types of models/deployments/implementations ... I don't think you want to do that.

But what is clearly not acceptable is to leave the document as is.