Subject: Issues with draft-ietf-radext-extended-attributes-05.txt

From: "Glen Zorn" <[email-masked]>
Date: Thu, 25 Dec 2008 12:15:21 +0700

Hi, guys.  I would _really_ like to get this draft done, but none of the
outstanding issues are owned by myself & the issue owners haven't been very
forthcoming w/text.  So, in the interest alacrity, could I talk you into
doing a little more Chair-stuff?  Specifically, if you have comprehended WG
consensus on any/all of the issues, can you provide editing instructions to
me so that the issues may be closed & the document progressed?  TIA!

--
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: Bernard Aboba <[email-masked]>
Date: Wed, 24 Dec 2008 23:02:57 -0800

In general, it is the job of the editor to work with the Issue filters to
resolve review comments.  

While it is possible to issue a formal WG consensus call to resolve 
contentious issues, it is neither practical or necessary to go through 
this process for each of the open issues.  We have already had to 
engage that formal consensus process twice -- and that proved 
to be  extremely time consuming. 

In looking at the open issues, in most cases the remaining
areas of dispute are relatively minor, so that they are readily
resolvable between the editor and the Issue proposers.   

In one or two cases the issues are more substantial, but 
discussion has not yet clarified the problem.  In these 
situations more discussion is probably required. 

Here is my take on where each of the current open issues stands
and what could be done to move things along.   Given the current
status, it is hard to see why the majority of these issues could
not be closed by the IETF 74 submission deadline. 

Extended 
      Attributes 
      Issue Number
    Status
    Type
    Description
    Owner
  
    Issue 225
    Pending
    Technical
    
	Review
    Alan 
    DeKok
  
    Issue 251
    Pending
    Technical
    
	Review
    Bernard 
      Aboba
  
    Issue 278
    Pending
    Technical

	Comments
    Alan 
    DeKok

    Issue 279
    Pending
    Technical

	Comments
    Stefan 
	Winter

    Issue 287
    No Discussion
    Technical

	Comments
    Greg 
    Weber

    Issue 290
    No Discussion
    Technical
    
	RFC 
	4005bis Dependency
    Bernard 
	Aboba

    Issue 298
    No Discussion
    Technical

	Extended Attributes Restriction
    Bernard 
	Aboba

Issue 225 -- It would appear that the major point of contention here relates to the length field and 
fragmentation.  I believe that  this comment could be resolved by addition of some advice (a SHOULD
might suffice) on fragmentation usage for senders and support on receivers.   The ability to include
multiple attributes inside a VSA was allowed in RFC 2865, and so should not be a subject of dispute
for this document.  Given that this issue is nearly resolved, I would suggest that you and Alan
work out appropriate text. 

Issue 251 -- This relates to the need for IANA considerations text.  I can post a suggestion. 

Issue 278 -- The remaining portion of this issue relates to whether IANA can allocate Extended
Attributes 0-255, and if by doing so, confusion would be created with respect to existing
RADIUS attributes.  What is interesting about this discussion is that it only arose once the
size of the type field was expanded to 16 bits.  In general, we have not seen confusion
relating to use of VSAs with Type Code values which overlap the standards range (which
most do).  For example, do people confuse Example.com VSA #32 with the RADIUS 
NAS-Identifier attribute (32)?   Maybe this issue could be resolved by suggestion of appropriate
nomenclature.  For example, the term "<Attribute name> Extended Attribute (#)"
instead of today's usage "NAS-Identifier Attribute (32)".  

Issue 279 -- Stefan has made concrete suggestions for resolving the remaining aspects of this
issue.  My suggestion would be to either incorporate them or make a counter-proposal. 

Issue 290 -- This relates to the issue of Diameter support for non-standard VSA formats (which this
document now uses).   During IETF 73, we discussed one potential avenue for addressing this, which
would be to update RFC 4005 to enable use of Diameter AVP 26 for translation of RADIUS VSAs of
non-standard type.   This document would then normatively reference RFC 4005bis for a discussion
on translation of Extended Attributes.   Dave Mitton has expressed interest in working on the
RFC 4005 revision, so my suggestion would be to work with him on that. 

Issue 298 -- This issue relates to whether Extended Attributes are treated like VSAs or not.  For
implementations of this document, the answer is probably "no" -- they are treated like any other standard
attribute.  However, for implementations that don't support Extended Attributes, the answer is 
probably "yes" -- which has implications for Accounting-Responses (where VSAs are permitted, 
but few standard attributes) and  Disconnect-Responses (where VSAs may only be used for 
session identification).   So one question is whether this implies that a NAS should signal its
support for Extended Attributes in the Access-Request in some way -- so as to make it clear
to the RADIUS server how those attributes would be interpretted.   Given that the implications
of this issue (and therefore consensus) are still somewhat unclear, my recommendation would to 
continue discussion in hope of achieving clarity.

---

From: Alan DeKok <[email-masked]>
Date: Fri, 26 Dec 2008 10:37:35 +0100

> work out appropriate text.

  I'll see if I can suggest something.

> instead of today's usage "NAS-Identifier Attribute (32)". 

  I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  If we allow vendor-id to be zero, AND allow attributes 1..255 to mean
something new, this will cause problems for many implementations.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals.

  Alan DeKok.

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 14:02:04 -0500

Bernard Aboba writes...

> and what could be done to move things along. 

I'm going to break my comments into separate replies for each issue, and
revise the subject headers accordingly.  These will follow in subsequent
messages.

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 14:10:38 -0500

> Issue 278 -- The remaining portion of this issue relates to whether
> IANA can allocate Extended Attributes 0-255, and if by doing so, 
> confusion would be created with respect to existing RADIUS attributes.

> In general, we have not seen confusion relating to use of VSAs with
> Type Code values which overlap the standards range (which most do).

I think that Extended Attributes (for implementations which _know_ that they
_are_ Extended Attributes) are clearly not the same thing as Vendor Specific
Attributes.  Assuming that VSA rules and practices apply to Extended
Attributes is probably not the best way to go.   Carving out a reservation
for the legacy codes of 0-255 seems reasonable, especially in light of the
extended type code field.

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 14:24:32 -0500

> Issue 290 -- This relates to the issue of Diameter support for 
> non-standard VSA formats (which this document now uses).   During IETF 73,
> we discussed one potential avenue for addressing this, which would be
> to update RFC 4005 to enable use of Diameter AVP 26 for translation of
> RADIUS VSAs of non-standard type.

Would that be a RADEXT or DIME work item?

There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary.  That issue revolves around the use of
complex / structured data in the value field of attributes, i.e. the V of
the TLV.  I think we need to nail down that issue before we can effectively
close on the Design Guidelines and Extended Attributes drafts, as well as
recommended practice for Diameter Compatibility and the related text that
should accompany the definition of new RADIUS [Extended] Attributes.  There
was discussion of this issue in the RADEXT and DIME WG meetings at IETF-73
and in the AAA Doctors lunch meeting.  Amazingly, this "larger issue" topic
has been hotly debated, on and off, as far back as the original discussion
on chartering RADEXT, back around time of IETF-56 (or so)!

I'll pick that discussion up in another thread.

Suffice it to say that the "consensus of record" of the RADEXT WG on this
issue does not address the interests and concerns of a handful of
individuals, who continue to make a case for more robust and rich
functionality regarding complex / structured attributes.

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 14:36:18 -0500

> Issue 298 -- This issue relates to whether Extended Attributes are
> treated like VSAs or not.  For implementations of this document, the
answer
> is probably "no" -- they are treated like any other standard attribute.

I heartily agree!

> However, for implementations that don't support Extended Attributes,
> the answer is probably "yes" -- which has implications for 
> Accounting-Responses (where VSAs are permitted, but few standard
attributes)
> and Disconnect-Responses (where VSAs may only be used for session
identification).

I think we want to be very careful here.  The correct behavior for
implementations that have not included the Extended Attribute functionality
is to treat them as unrecognized / unknown VSAs, and to ignore them.  They
may be logged in some fashion, of course.  Whether they should be included
in RADIUS Accounting or Dynamic RADIUS packets as "unknown attributes" is
open to debate.

What I think should not happen is for Extended Attributes to be
"selectively" understood.  The implementation either "groks" the Extended
Attribute format, in which case the rules for standard attributes (or SDO
Specific Attributes) apply, or it simply sees them as unrecognized / unknown
VSAs, in which case the rules for unknown attributes apply.  We should not
encourage implementations to treat them as unknown for one purpose but known
for another.

> So one question is whether this implies that a NAS should signal its
> support for Extended Attributes in the Access-Request in some way -- 
> so as to make it clear to the RADIUS server how those attributes would
> be interpreted.  

I think we should make that feature a MUST.

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 15:34:41 -0500

Alan DeKok writes...
 
> is often done by setting vendor-id=0.

In hind sight, that was a very inconvenient thing for implements to have
done, although I can see its attraction in terms of abstracting properties
of various classes of attributes.

> something new, this will cause problems for many implementations.

I suggested at two different IETF meetings that using a Vendor ID of 0 might
be problematic.  I envisioned just this sort of scenario.  No one seemed to
see the same issues, since my suggestion gathered no support.  :-)  We could
revisit the use of 0 and assign some other, non-zero, PEN.

> into the extended-attribute format, which was one of Glens goals.

Or we could reserve the legacy values 0..255.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Dec 2008 13:42:02 -0800

Alan DeKok said:

"I was thinking also API's.  Some systems have internal API's that
add/delete/lookup attributes based on a key.  The key is (vendor-id,
attribute).  The problem is that looking up traditional RFC attributes
is often done by setting vendor-id=0.

  Using 1..255 also prevents the grouping of standard RFC attributes
into the extended-attribute format, which was one of Glens goals."

There are multiple issues here, I think:

a. Whether existing implementations will have a problem with a vendor-id
of zero, regardless of the size of the type code space, and the attribute
numbering;  

b. Whether the *combination* of a vendor-id of zero along with attribute
usage 1-255 can cause problems; 

If we have problem a, then the fix would be to assign the IETF a non-zero
Vendor-Id; merely prohibiting attributes 1-255 would not do the trick. 

If we only have problem b, then we could prohibit attributes 1-255 from
being assigned.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Dec 2008 13:51:14 -0800

David Nelson said:

"Would that be a RADEXT or DIME work item?"

It would probably be a DIME WG work item, assuming that they are willing to
take it.
However, before making progress on that we would need a viable proposal (and
a document 
that references it). 

David Nelson also said:

"There is a larger issue here, currently being discussed as part of the
RADIUS Design Guidelines commentary."

Is there an IETF last call comment on the Guidelines document relating to
this? 
I've been trying to keep the tracker up to date on the last call issues, but
I suspect I may be missing some. 

"I think we need to nail down that issue before we can effectively
close on the Design Guidelines and Extended Attributes drafts"

Since Extended Attributes uses Attribute 26, I had assumed that it
inherits all the capabilities of that attribute.  RFC 2865, Section
5.26 says:

      Multiple subattributes MAY be encoded within a single Vendor-
      Specific attribute, although they do not have to be.

---

From: "Bernard Aboba" <[email-masked]>
Date: Fri, 26 Dec 2008 13:53:31 -0800

David Nelson said:

"I think we want to be very careful here.  The correct behavior for

for another."

[BA] Very well put.  Care to take a shot at providing text to resolve the
issue?

[BA] That seems sensible to me.  The question is how to do it.  Maybe
include
an Extended Attribute of Type 1 with a NUL in it within an Access-Request?

---

From: "D. B. Nelson" <[email-masked]>
Date: Fri, 26 Dec 2008 18:25:44 -0500

Bernard Aboba writes...

> Is there an IETF last call comment on the Guidelines document relating
> to this?

Yes.  I believe Hannes raised the issue.  Maybe others.

> inherits all the capabilities of that attribute.

Yes and no.  Basically, RFC 2865 allows VSAs to contain _anything_ in the
"value" portion of the attribute that will fit into 253 (more or less)
octets.  There is a recommended format, and multiple instances in the
recommended format may be included, but so may anything else.

For the purpose of the Extended Attribute, I think we absolutely must
retract the "but so may anything else" portion, and stick to the format as
defined in the Extended Attributes draft.

Of course, I suppose that one could have a Vendor Specific Extended
Attribute.  :-)

---

From: Alan DeKok <[email-masked]>
Date: Sat, 27 Dec 2008 17:07:12 +0100

> of zero, regardless of the size of the type code space, and the attribute

  I can think of at least one that does.  I'm not sure anyone else is
going to admit that their implementation is less than perfect. :)

> If we only have problem b, then we could prohibit attributes 1-255 from

  That would be the solution with the minimum changes.

  Alan DeKok.