From Draft Tracker:
DISCUSSES AND COMMENTS:
======================
Ralph Droms:
Comment [2009-04-20]:
Trivial: does the "text" data type include a trailing '\0' byte? I ask because
there has been confusion about this point in DHCP options and it might be good
to make the convention explicit.
Lars Eggert:
Comment [2009-04-20]:
Section 2.1.1, paragraph 2:
> The Length field in the RADIUS packet header is defined in [RFC2865]
> Section 3. It is noted there that the maximum length of a RADIUS
> packet is 4096 octets. As a result, attribute designers SHOULD NOT
> assume that a RADIUS implementation can successfully process RADIUS
> packets larger than 4096 octets.
You may want to point out that even with messages less than 4096 but
larger than the PMTU, persistent IP fragmentation will be incurred,
which makes communication much more brittle, and might even want to
suggest that therefore RADIUS messages should be kept as small as
possible. See RFC5405 Section 3.2.
Adrian Farrel:
Comment [2009-04-18]:
Trivial, but...
Section 2.1.1 says that some address data types are in "network
byte order" while others are "most significant octet first". Is there a reason
for this difference?
I wonder if the text in seciton 4 should be stronger. You have...
This document does not require that the IANA update any existing
registry or create any new registry, but includes information that
affects the IANA, for example:
* includes guidelines that recommend against allocation from the
RADIUS standard attribute space in other SDO RADIUS Attribute
specifications.
But, in fact, IANA are bound by the registry rules already laid down and cannot
make allocations except following IETF process as defined by RFC 3575.
Russ Housley:
Comment [2009-04-20]:
The Gen-ART Review by Gonzalo Camarillo on 8 April 2009 provides some
editorial suggestions.
ID nits complains that reference [8] appears in Appendix B.6 but not
in the References.
The Introduction Section should be a non-normative section. However,
Section 1.1 uses normative statements (RECOMMENDED and NOT
RECOMMENDED) before those terms are defined in Section 1.3.
The acronym AAA should be expanded.
When referring to the appendixes, I think the draft should talk about
appendixes, not about sections. For example, it should talk about
Appendix A.5, not about Section A.5.
Alexey Melnikov:
Comment [2009-04-21]:
This is a fine document. Some minor comments:
3.3. RADIUS Operational Model
The RADIUS operational model includes several assumptions:
* The RADIUS protocol is stateless;
* Provisioning of services is not possible within an
Access-Reject;
* Distinction between authorization checks and user
authentication;
* Authentication and integrity protection of RADIUS packets;
* The RADIUS protocol is a Request/Response protocol.
* Packet length restriction.
Half of this list is comprised from full sentences, the other half is not. I
would appreciate if you can make this consistent, otherwise it
is difficult to
read/understand.
Robert Sparks:
Comment [2009-04-22]:
"the above procedure" in 3.1.1 (page 17) could be hard to follow for some
readers. Recommend providing a more explicit pointer.
|