Summary of feedback on draft-ietf-dhc-agent-opt-radius-06.txt

[Bernard Aboba <aboba@internaut.com>]

I've gone back over the archives of the AAA-Doctors list in order to
retrieve the comments that were submitted, in an attempt to categorize
them.  The AAA-Doctors mailing list archive is found at:
http://ops.ietf.org/lists/aaa-doctors/2004/maillist.html

Since the mailing list archive is public, my assumption is that any
comments posted were intended to be public, rather than anonymous.

On April 28, 2004, Bert Wijnen sent a message to the AAA-Doctors list
requesting a review of draft-ietf-dhc-agentopt-radius-06.txt:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00005.html

Comments came back from the following individuals and were incorporated in
Draft Tracker on May 24, 2004:

1. Bernard Aboba:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00006.html

2. David Nelson:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00007.html

3. Greg Weber:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00008.html

4. Ashwin Palekar:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00009.html

5. Paul Funk:
http://ops.ietf.org/lists/aaa-doctors/2004/msg00010.html
http://ops.ietf.org/lists/aaa-doctors/2004/msg00011.html

The comments related to the following issues:

1. Negotiation of NAS/RADIUS server support (David Nelson, Ashwin Palekar)
The issue raised is that the draft does not specify a mechanism by which
the RADIUS server can know if the NAS supports this specification.  This
issue is in part related to Issue 8, which proposes addition of a RADIUS
attribute that might allow a NAS to signal support for this specification.

2. Handling of truncation (Bernard Aboba, David Nelson, Ashwin Palekar,
Paul Funk)

This issue relates to limiting the maximum size of the attributes
returned by the RADIUS server.  The comments suggest that the limitations
be relaxed.  This comment relates to Issue #1 in part because without
negotiation there is no way for a RADIUS server to know what that the
maximum packet size is less than the 4096 specified in RFC 2865.

3. Normative language updating or contradicting RFC 2865 (Bernard Aboba,
David Nelson, Greg Weber)

In a number of places, the draft specifies changes to the behavior of RFC
2865, using normative language.  There are also places where the draft
contradicts itself with respect to use of attributes in Access-Requests
rather than in the Access-Accept.  This comment suggests that the
normative language be removed and that the contradictions be resolved.

4. Conflicts between DHCP and RADIUS server IP address allocation (David
Nelson)

This is a request for clarification of the relationship between RADIUS
server IP address allocation (via Framed-IP-Address) and DHCP server
allocation.  Section 4 does not include Framed-IP-Address in the list
of RADIUS server attributes, so I believe this comment is asking about
what will happen if Framed-IP-Address is returned.  I think the answer is
that the DHCP server will ignore it and assign a potentially different
address.

5. Compatibility with User-Name privacy & Multiple identities (David
Nelson, Ashwin Palekar)

The question here relates to situations in which the User-Name is kept
private ("@example.com") or in which the EAP identity is different from
the User-Name.  For example, there is a new proposal for addition of a
"billable identity" attribute in RADEXT WG.  Should this new "billable
identity" attribute be included in the list in Section 4?

6. Lifetime of authorization data (Greg Weber)
This comment relates to how long the authorization data may be cached at
the NAS before it goes stale.  It is possible that the Session-Time
attribute may help with this.

7. Correlation (Greg Weber)
This comment relates to how RADIUS & DHCP requests can be linked,
presumably for debugging purposes.  Section 4 includes
Acct-Session-Id or Acct-Multi-Session-Id in the list of potential
attributes, so this may be part of the answer.

8. Alternative approach: New RADIUS attribute for DHCP options (Ashwin
   Palekar, Paul Funk)

This comment suggests the creation of a new RADIUS attribute in order to
allow the server to explicitly indicate which attributes are to be sent to
the DHCP server. It may relate to Issue #1 in that if such an attribute
were created, it might be possible for the NAS to use it to indicate
support for the specification.

9. Editorial issues (David Nelson)

This issue related to an editorial NIT within one of the figures.