Skip to main content

Common Remote Authentication Dial In User Service (RADIUS) Implementation Issues and Suggested Fixes
draft-ietf-radext-fixes-08

Yes

(Cullen Jennings)
(Dan Romascanu)

No Objection

(David Ward)
(Jon Peterson)
(Lars Eggert)
(Lisa Dusseault)
(Magnus Westerlund)
(Mark Townsley)
(Ron Bonica)

Note: This ballot was opened for revision 08 and is now closed.

Cullen Jennings Former IESG member
Yes
Yes () Unknown

                            
Dan Romascanu Former IESG member
Yes
Yes () Unknown

                            
Jari Arkko Former IESG member
(was Discuss) Yes
Yes (2007-09-04) Unknown
> The CPE may also require a delegated prefix for its own use, if it is
> decrementing the Time To Live (TTL) field of IP headers.  In that
> case, it should be delegated a prefix by the NAS via the Delegated-
> IPv6-Prefix attribute.  [RFC4818].  If the CPE is not decrementing
> TTL, it does not require a delegated prefix.

Time To Live is called Hop Limit in IPv6, and since this is
an IPv6 specific Section, perhaps this is the name that you
should use.
Chris Newman Former IESG member
No Objection
No Objection (2007-07-05) Unknown
Editorial:
>   inclusion of an Event-Timestampt attribute, for example, then
s/Event-Timestampt/Event-Timestamp/
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jon Peterson Former IESG member
No Objection
No Objection () Unknown

                            
Lars Eggert Former IESG member
(was Discuss) No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Mark Townsley Former IESG member
No Objection
No Objection () Unknown

                            
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Sam Hartman Former IESG member
No Objection
No Objection (2007-07-05) Unknown
I am concerned about how this draft seems to break the ability to
negotiate future extensions.  In particular the recommendation that
client should treat access-accept with unknown attributes as
access-reject seems problematic.  However this issue seems to have
been discussed sufficiently so this is only a comment.
Tim Polk Former IESG member
No Objection
No Objection (2007-07-03) Unknown
I personally find this text in the last sentence in section 2.1.1 to be unclear:

"neither including an authentication attribute nor a Service-Type attribute"

I suggest rewriting this sentence, deleting the double negative for clarity.