When checking recent email, it became clear to me that the
DHC WG chairs (and WG) may not be aware of what is going on.
I have kept Margaret (your AD) up to date (or at least intended
to), but I do not know if she forwarded the status to Ralph or not.
So this is to try and make sure you know we are not sitting still
and to let you know where we are.
Ralph, feel free to forward to DHC WG if that seems useful.
The status and recent steps.
- Bernard (as one of the AAA-doctors) is has composed a summary of
the AAA-doctor review comments to revision 6.
- Bernard has posted those to the AAA-doctors mailing list.
I have added a copy below.
- Bernard has asked the AAA_doctors to check a few things:
- if his summary is correct
- if the responses provided by Ralph solved all/any issues
- to state which issues are still a problem
- I have just added the request that reviewiers also check the new
revision 7.
- When Bernard has the answers, he intends to make a final summary
of what the AAA-doctors believe are the remaining (if any) issues.
which we will then forward to the DHC WG chairs.
Hope everyone is up to date after this again.
Bernard, pls speak up if I put too much (more than you volunteered)
work in your lap.
Thanks,
Bert
-----Original Message-----
From: Bernard Aboba [mailto:aboba@internaut.com]
Sent: vrijdag 9 juli 2004 16:51
To: aaa-doctors@ops.ietf.org
Subject: Summary of feedback on draft-ietf-dhc-agent-opt-radius-06.txt
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.