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.