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

["Dave Nelson" <d.b.nelson@comcast.net>]

Dan Romascanu 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).

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.



--
to unsubscribe send a message to radiusext-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/radiusext/>