Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt

From: "Glen Zorn" <[email-masked]>
Date: Sun, 21 Dec 2008 20:11:31 +0700

FYI, in case you didn't see it.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Wednesday, December 17, 2008 5:30 PM
To: [email-masked]
Subject: I-D Action:draft-zorn-radius-pkmv1-03.txt 

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
Management Version 1 (PKMv1) Protocol Support
	Author(s)       : G. Zorn
	Filename        : draft-zorn-radius-pkmv1-03.txt
	Pages           : 15
	Date            : 2008-12-17

This document defines a set of RADIUS Attributes which are designed to
provide RADIUS support for IEEE 802.16 Privacy Key Management Version 1.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 22 Dec 2008 11:22:48 +0100

I would like to ask the WG chairs and the WG at large what are the plans
with this document following the response received from IEEE 802.16. 

Thanks and Regards,

Dan

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Glen Zorn
> Sent: Sunday, December 21, 2008 3:12 PM
> To: [email-masked]
> Subject: FW: I-D Action:draft-zorn-radius-pkmv1-03.txt 
> 
> A New Internet-Draft is available from the on-line 
> Internet-Drafts directories.
> 
> This document defines a set of RADIUS Attributes which are 
> designed to provide RADIUS support for IEEE 802.16 Privacy 
> Key Management Version 1.
> 
> Below is the data which will enable a MIME compliant mail 
> reader implementation to automatically retrieve the ASCII 
> version of the Internet-Draft.
> 

--
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: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 13:06:49 -0500

Dan Romascanu writes...

> I would like to ask the WG chairs and the WG at large what are
> the plans with this document following the response received from
> IEEE 802.16.

We should first ask Glen his intent / preferences.  Glen, what is your
preferred path to publish this draft?

As this draft has been deemed useful to IEEE 802.16 (at least to address
fielded deployments), the first question to ask is whether this work should
be taken on in the IETF, or whether it should be taken on in the IEEE (or as
a individual submission).  We have created a framework in which RADIUS
attributes that are of interest to particular SDOs, but not of general
interest to the Internet community, could be documented as SDO Specific
Attributes, using the RADIUS Extended Attribute format and the RADIUS Design
Guidelines.  This process may still require / desire expert review by the
RADEXT WG and/or the AAA Doctors.

OTOH, if the RADEXT WG is requested to invest substantial time in reviewing
this draft, it may make sense to publish this draft via the IETF process,
and thus as a RADEXT WG work item.  I don't have a strong opinion either
way.  If the WG chooses to take on this work, then it would need to be
appropriately prioritized w.r.t. the current deliverables, some of which
would be a prerequisite for either path (e.g. Design Guidelines and Extended
Attributes).

Regards,

Dave Nelson

---

From: "Glen Zorn" <[email-masked]>
Date: Mon, 29 Dec 2008 13:27:42 +0700

> preferred path to publish this draft?

Sorry for the slow response, I've been occupied with administrivia ;-).
Anyway, my preference hasn't changed since I sent my original request
(attached) to Dan over 2 months ago.

> Guidelines.  

Using Extended Attributes was my first choice but it is unfortunately
impossible to do this in any reasonable fashion using them; this was
established as unchangeable WG Consensus some time ago, as announced by Alan
Dekok (it _is_ interesting that RFCs can be updated & made obsolete &
decisions of even the highest courts may be overturned, all based on new
data, but WG Consensus cannot change -- who knew?).  Furthermore (& I
_really_ hate to say this) the attributes as they are have already been
implemented by at least 2 vendors and deployed.  

...

Subject: FW: I-D Action:draft-zorn-radius-pkmv1-01.txt
From: "Glen Zorn" <[email-masked]>
To: "'Dan Romascanu'" <[email-masked]>
Cc: "'Glen Zorn'" <[email-masked]>, "'Bernard Aboba'" <[email-masked]>, "'David B. Nelson'" <[email-masked]>
Date: Sat, 18 Oct 2008 14:31:45 +0700

Hi, Dan.  In the interest of timeliness, I'm wondering if I can interest you
in sponsoring this draft for publication.  I'm not at all averse to radext
WG review of the document but publishing it as a WG document would, in all
probability, take years; in fact, it might take years to get it in the
charter.  Thanks for your consideration.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
Sent: Saturday, October 18, 2008 2:00 PM
To: [email-masked]
Subject: I-D Action:draft-zorn-radius-pkmv1-01.txt 

	Title           : RADIUS Attributes for IEEE 802.16 Privacy Key
Management Version 1 (PKMv1) Protocol Support
	Author(s)       : G. Zorn
	Filename        : draft-zorn-radius-pkmv1-01.txt
	Pages           : 14
	Date            : 2008-10-17

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-zorn-radius-pkmv1-01.txt

---

From: Alan DeKok <[email-masked]>
Date: Mon, 29 Dec 2008 08:53:21 +0100

Glen Zorn wrote:
> Dekok 

  I never said any such thing.

  In the past, people rejected the modifications you proposed.  This
forms the "WG consensus" that I have referred to.

  In the present, no one has agreed to make those modifications.

  In the future, if people *do* agree to make those modifications, that
would form "WG consensus", and I would be in no position to oppose it.

> (it _is_ interesting that RFCs can be updated & made obsolete &
> data, but WG Consensus cannot change -- who knew?).

  These spurious claims can't avoid the fact that you haven't succeeded
in changing the WG consensus to support your position.  Don't blame me.

  Alan DeKok.

---

From: "D. B. Nelson" <[email-masked]>
Date: Mon, 29 Dec 2008 09:13:15 -0500

Glen Zorn writes...

> Anyway, my preference hasn't changed since I sent my original
> request (attached) to Dan over 2 months ago.

And that preference would be that the draft simply be published as an
Informational RFC, via the AD Sponsorship route.

> Furthermore (& I _really_ hate to say this) the attributes as
> they are have already been implemented by at least 2 vendors
> and deployed.

I presume the attributes have been deployed as VSAs.  This draft requests
that IANA assign standard code space IDs to the attributes. I understand
that changing the deployed code to remove VSA headers and substitute
standard headers is not a lot of work, but it _is_ a code change.  Once you
open up the code for change...  well, change is change.

I suppose this draft could be published as documentation of existing
practice / fielded deployment, as an Informational RFC using the fielded VSA
assignments.

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 29 Dec 2008 21:37:28 -0800

> practice / fielded deployment, as an Informational RFC using the fielded VSA

Indeed, according to the Design Guidelines document, that is the *preferred*
approach, since it maximizes interoperability with existing implementations. 

Of course, this raises the question whether the existing attributes are allocated
in the IEEE 802 space (e.g. SDO-specific attributes), or in the Vendor-Space. 

However, in terms of the review process described in the Design Guidelines
document, it does not matter. 

> established as unchangeable WG Consensus some time ago, as announced by Alan
Given that this protocol has supposedly already been implemented by 2 vendors, 
why is the presence or absence of any feature within the Extended Attributes
document relevant?  Presumably a description of an existing implementation would
be self-contained, not requiring a normative reference to any work-in-progress,
assuming that the protocol is already implemented. 

> data, but WG Consensus cannot change -- who knew?).

What I don't understand is what "working group consensus" has to do with
publishing documentation of an existing implementation.   Presumably the only
criteria governing would be whether the document actually describes
what has been implemented. 

> in changing the WG consensus to support your position.  Don't blame me.
The "claims" in question here seem to have nothing whatever to do with the document
under discussion in this thread:  draft-zorn-radius-pkm1.   So before we get drawn
into a discussion of the validity of them, I'd first like to understand why they are even 
relevant.

If the goal here is to publish documentation of an existing implementation of RADIUS
attributes for IEEE 802.16a, then a request should be sent to the AAA-Doctors list
for a review.  Such a document need not become a RADEXT WG work item to be
eligible for publication.  Certainly that has not been the case for other such
documents, most recently RFC 4679.

---

From: "Glen Zorn" <[email-masked]>
Date: Tue, 30 Dec 2008 13:59:06 +0700

> I presume the attributes have been deployed as VSAs.  

I haven't seen the code so I don't know for sure, but my guess is that your
presumption would be incorrect.  Since multiple vendors are involved, this
is not a technically appropriate use of VSAs.

...

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 30 Dec 2008 11:10:51 +0100

> [mailto:[email-masked]] On Behalf Of D. B. Nelson
> Sent: Monday, December 29, 2008 4:13 PM
> Subject: RE: I-D Action:draft-zorn-radius-pkmv1-03.txt 
> 
> Glen Zorn writes...
> 
> And that preference would be that the draft simply be 
> published as an Informational RFC, via the AD Sponsorship route.
> 

I will accept taking this path if the WG is OK with it, but I would note
that I will ask anyway the WG to designate an expert reviewer for this
document and would expect people to comment at last call (or before). 

Glen, in order to start the AD-sponsoring process you need to find a
shepherd for this document, and he or she will need to submit a PROTO
write-up as per http://www.ietf.org/IESG/content/Indiv-Doc-Writeup.html

Thanks and Regards,

Dan

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 09:49:34 -0500

Glen Zorn writes...

> I haven't seen the code so I don't know for sure, but my guess
> is that your presumption would be incorrect.  Since multiple 
> vendors are involved, this is not a technically appropriate 
> use of VSAs.

So perhaps the implementers used code points in the "Private Use" range (192
- 240)?  Please don't tell me that they poached code points under IANA
control.  :-(  That would be pretty egregious. 

In any event, changes to the code would need to be made, no?

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 10:57:43 -0500

Dan Romascanu writes...

> I will accept taking this path if the WG is OK with it, but I would
> note that I will ask anyway the WG to designate an expert reviewer
> for this document and would expect people to comment at last call
> (or before).

There are two issues which would slow the progress this draft as a RADEXT WG
work item: (1) if the WG members were not sufficiently interested in 802.16
key management to engage in active review and commentary and (2) if the
draft were to be entangled in the debate over whether or not to support
complex, structured attributes.

I can't predict (1) but I can predict (2).  One snippet from the draft
reads:

      The PKM-Config-Settings Attribute is 30 octets in length and
      consists of seven independent fields, each of type integer
      [RFC2865].
 
This tell us right up front that the draft is using complex / structured
attributes, in this case a fixed length array of integer values.  As
currently constituted, the RADIUS Design Guidelines draft discourages such
attribute design for attributes in the "classic" RADIUS attribute ID space.
This draft is requesting allocation from that space.

We had a similar problem with the GEOPRIV Location Attributes draft.  That
document has moved on, but the basic tension between its attribute design
and the recommendations of the Design Guidelines was never fully resolved.

While the Design Guidelines draft is up for IESG approval, and represents
the consensus opinion of the RADEXT WG in the matter of attribute design,
there is still some disquiet.  Most recently, Hannes Tschofenig posted some
commentary regarding the issue of Diameter AVP compatibility that directly
hinges on this thorny issue of complex / structured attributes.

My observation is that there are still drafts being written that do not
follow the RADIUS Design Guidelines, even though that document is basically
a "done deal".  I assume that means that developers find the guidelines too
restrictive for their particular applications or their particular design
preferences.   I can only assume that this will continue, even after the
RADIUS Design Guidelines draft is published as a BCP.  Sigh.

With regard to the example quoted above, the recommended design would be
seven separate attributes of type Integer.  If we take the scarcity issue
off the table for a moment, the only downside would be encoding
inefficiency, i.e. the seven integer values would take up more space in the
RADIUS PDU.  Glen Zorn, in particular, has continually suggested to the WG
that applications are bumping up against the limitation of RADIUS PDU
length.  I suppose an application that is including multiple X.509
certificates in a RADIUS packet may indeed have this problem.

I will take some time to read the current draft and offer some comments.
What am I to do about attributes that don't follow the RADIUS Design
Guidelines?  This promises to be the GEOPRIV debate all over again.  We can
simply turn a blind eye, and let the draft go via the individual submission
route, but what kind of precedent are we setting if we start bypassing
RADIUS Design Guidelines right out of the gate?

If we have design rules or guidelines, they ought to mean something.  That
requires we either reject drafts that don't comply or we enhance the
guidelines so that all reasonable-minded developers can live within their
restrictions.  Anything else is pretty silly, IMHO.

We thought that the RADIUS Extended Attribute format would be a way out of
this mess, i.e. that it would support a sufficient (albeit limited) way to
encode complex / structured attributes.  The Design Guidelines draft is
largely silent on how to design Extended Attributes; that guidance is to be
included in the Extended Attributes draft.

The RADEXT WG consensus of Extended Attributes is that the current tagging
mechanism is sufficient to permit the representation of structured
attributes.  Glen has told us in various postings that that format is not
sufficient (acceptable) to accommodate the need of the PKMV1 draft we are
discussing.  So, we see the draft using "classic" attributes in a way not
supported by the RADIUS Design Guidelines draft.

I think something has to change, or we're in for a lot of future silliness.
I personally have supported a more robust format for Extended Attributes
that would better accommodate the [perceived] need for structured and
complex attribute design.  However, that's not where the WG consensus lies.
That's fine.  But what are we to do with draft submissions that find neither
the Extended Attribute format nor the guidance of the RADIUS Design
Guidelines for "classic" attributes acceptable to their purpose?  Should we
(or some appointed Expert Reviewer) reject those drafts and attempt to block
their publication?

If the motivation in the developer community to design, publish and deploy
complex, structured attributes is sufficiently strong, and the IETF does not
provide a reasonable format or alternative, we're in for a lot more heated
debates.

Let me put it this way: What would MIB Module designers do if there were no
tables available in SMI and there was no SEQUENCE OF syntax?  :-)

I'm seeking suggestions for a way forward, not only for this draft, but for
other similar ones to come.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 11:26:52 -0500

Bernard Aboba writes...

> If the goal here is to publish documentation of an existing 
> implementation of RADIUS attributes for IEEE 802.16a, then a request
> should be sent to the AAA-Doctors list for a review.

Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 30 Dec 2008 10:33:07 -0800

> vendors are involved, this is not a technically appropriate 

No. The Design Guidelines document was written in part to dispel
this misconception.  VSAs (specifically those allocated to
SDOs such as IEEE 802) are not only technically appropriate 
for this use, they are the recommended approach for use
in documents (such as this one) which describe SDO-specific
uses of RADIUS.  

If this point is not being made crystal clear in the Design
Guidelines document, then we need to change the text until
it is. 

Forcing SDOs to put documents on the IETF standards track
merely so that they can obtain request allocation of standard RADIUS
attributes for SDO-specific uses of RADIUS makes no sense.

---

From: "Bernard Aboba" <[email-masked]>
Date: Tue, 30 Dec 2008 10:38:21 -0800

David Nelson said:

"Should such a review include analysis of compliance with the RADIUS Design
Guidelines?  Are you assuming that the guidelines apply only after they are
finally published as a BCP?"

The RADIUS design guidelines only apply to documents that are requesting
allocation of RADIUS standard attributes.  If this document were to 
allocate its attributes from the IEEE 802 attribute space, then I don't
believe that conformance to Design Guidelines would be required.

---

From: "Dave Nelson" <[email-masked]>
Date: Tue, 30 Dec 2008 14:11:11 -0500

Bernard Aboba writes...

> The RADIUS design guidelines only apply to documents that are 
> requesting allocation of RADIUS standard attributes.

That's not what it says.  What it actually says is:

   Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their
   RADIUS work within the IETF is inherently inefficient and 
   unscalable.  By articulating guidelines for RADIUS attribute 
   design, this document enables SDOs to design their own RADIUS 
   attributes within the Vendor-Specific Attribute (VSA) space,
   seeking review from the IETF.

It specifically indicates that the guidelines apply to SDO-defined
attributes, and I think this was the general intent all along -- to provide
design guidance so that high-quality RADUS work could occur both within the
IETF and within other SDOs.

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 30 Dec 2008 11:59:55 -0800

> IETF and within other SDOs.

I think that this may in part explain some of Hannes' (and others) objections to the document. 

Given the widely divergent interpretations of the document applicability, it would seem that we
will need to develop an applicability statement section so that the scope (and intent) of the
document is clear.

---

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

Bernard Aboba writes...

> Given the widely divergent interpretations of the document applicability,
> it would seem that we will need to develop an applicability statement 
> section so that the scope (and intent) of the document is clear. 

Uh...  There *is* an applicability statement, Section 1.1 Applicability.
:-)

I previously quoted part of it.  Here's the complete section:

1.1.  Applicability

   As RADIUS has become more widely accepted as a management protocol,
   its usage has become more prevalent, both within the IETF as well as
   within other SDOs.  Given the expanded utilization of RADIUS, it has
   become apparent that requiring SDOs to accomplish all their RADIUS
   work within the IETF is inherently inefficient and unscalable.  By
   articulating guidelines for RADIUS attribute design, this document
   enables SDOs to design their own RADIUS attributes within the Vendor-
   Specific Attribute (VSA) space, seeking review from the IETF.  In
   order to enable IETF review of SDO RADIUS attribute specifications,
   the authors recommend that:

      * SDOs make their RADIUS attribute specifications publicly
      available;

      * SDOs request review of RADIUS attribute specifications by
      sending email to the AAA Doctors [DOCTORS] or equivalent mailing
      list;

      * IETF and SDO RADIUS attribute specifications are reviewed
      according to the guidelines proposed in this document;

      * Reviews of specifications are posted to the RADEXT WG mailing
      list, the AAA Doctors mailing list [DOCTORS] or another IETF
      mailing list suggested by the Operations & Management Area
      Directors of the IETF.

   The advice in this document applies to attributes used to encode
   service-provisioning or authentication data.  RADIUS protocol
   changes, or specification of attributes (such as Service-Type) that
   can be used to, in effect, provide new RADIUS commands require
   greater expertise and deeper review, as do changes to the RADIUS
   operational model, as described in Section 3.3 .  Such changes should
   not be undertaken outside the IETF and when handled within the IETF
   require "IETF Consensus" for adoption, as noted in [RFC3575] Section
   2.1.