RADIUS Design Guidelines
draft-ietf-radext-design-19

Comment updated for new revision No issues found Thanks for addressing my previous comments

2. Guidelines Attributes within the standard space are appropriate for this purpose, and are allocated via IANA as described in [RFC3575]. Since the standard space represents a finite resource, and is the only attribute space available for use by IETF working groups, vendors and SDOs are encouraged to utilize the VSA space, rather than requesting allocation of attributes from the standard space. Usage of attribute type codes reserved for standard attributes is considered anti-social behavior and is strongly discouraged. In the last sentence: I think you meant "Unauthorized usage of attribute type codes ..." 

I do agree that for functionality FOO, both the functionality itself and the MIB, RADIUS, etc. work should take place in the same standards body. However, Section 3.1 could have said a couple of additional things as well: The issues of attribute space and choice of forum are distinct; there is no reason why IETF couldn't use its own vendor code, for instance. The section also does not mention one of the potential drawbacks of SDO-driven development model: it is easy to come up with a number of different solutions to the same generic problem, as opposed to finding a common solution.

> RADIUS Design Guidelines Since this document actually describes design guidelines for RADIUS *attributes*, the title isn't really accurate. Maybe "Design Guidelines for RADIUS Attributes"? Section 1., paragraph 5: > Reviewers of RADIUS spcifications are expected to be familiar with Nit: s/spcifications/specifications/ Section 2.1.1, paragraph 3: > Even when packets are less than 4096 octets, they may be larger than > the Path Maximum Transmission Unit (PMTU). Any packet larger than > the PMTU will be fragmented, making communications more brittle as > firewalls and filtering devices often discard fragments. Transport > of fragmented UDP packets appears to be a poorly tested code path on > network devices. Some devices appear to be incapable of transporting > fragmented UDP packets, making it difficult to deploy RADIUS in a > network where those devices are deployed. We RECOMMEND that RADIUS > messages be kept as small possible. Thanks for addressing my comment from 2009 in the new version! (You may also want to point the reader at RFC5405, Section 3.2 here.) Section 3.2.3., paragraph 4: > administator to enter the data as well-known types, rather than Nit: s/administator/administrator/ Section 5., paragraph 6: > IPSec. See [RFC3579] Section 4, and [RFC3580] Section 5 for a more Nit: s/IPSec./IPsec./ Appendix A, paragraph 15: > Section A.2.2 descibes more complex data types which should be Nit: s/descibes/describes/ 

"the above procedure" in 3.1.1 (page 17) could be hard to follow for some readers. Recommend providing a more explicit pointer.