[radext] AD review of draft-ietf-radext-ieee802ext-09

[Benoit Claise <[e-mail]>]

Dear all,

Glad that this document finally makes progress.

 From the writeup (https://datatracker.ietf.org/doc/draft-ietf-radext-ieee802ext/shepherdwriteup/) I see:

    (6) Describe any specific concerns or issues that the Document Shepherd
    has with this document that the Responsible Area Director and/or the
    IESG should be aware of? For example, perhaps he or she is uncomfortable
    with certain parts of the document, or has concerns whether there really
    is a need for it. In any event, if the WG has discussed those issues and
    has indicated that it still wishes to advance the document, detail those
    concerns here.

        The document (informatively) references to RFC4005 on its Diameter
        considerations. The RFC4005 will soon be obsoleted by RFC4005bis.
        The RFC4005bis also deprecates the RADIUS-Diameter automated
        translation, which is discussed in detail in Section 4 Diameter Considerations.

        The shepherd would recommend removing entire Section 4, since
        RADIUS-Diameter considerations are not really endorsed anymore.

        Furthermore, Section 4 uses Diameter AVP Flag rules as defined in RFC3588,
        which has already been obsoleted by RFC6733 and there the AVP Flag rules
        are less due to e.g. deprecation of Diameter in-band security.



I would actually prefer to keep the section 4, because the AVPs are 
allocated in the range 1-255.
However, RFC 4005bis must be mentioned as well.
This specific point is also discussed in draft-ietf-dime-app-design-guide-21

     Guidelines for implementing a RADIUS-Diameter translation agent
     were put into the Diameter NASREQ Application RFC 4005.
     However, it was acknowledged that such translation mechanism was not
     so obvious and deeper protocol analysis was required to ensure
     efficient interworking between RADIUS and Diameter.  Moreover, the
     interworking requirements depend on the functionalities provided by
     the Diameter application under specification, and a case-by-case
     analysis is required.
     As a consequence, all the material related to RADIUS-to-Diameter translation has been
     removed from the new version of the Diameter NASREQ application specification
     [RFC4005bis], which deprecates RFC4005

Feel free to synchronize with Lionel Morand, the 
draft-ietf-dime-app-design-guide-21 editor, who is currently working on 
a revised text

Regarding this point below, I agree with Jouni, can you please make the 
change to be in line with the RFC 6733 format (for example, RFC 6733 
doesn't have encryption)

    Furthermore, Section 4 uses Diameter AVP Flag rules as defined in RFC3588,
    which has already been obsoleted by RFC6733 and there the AVP Flag rules
    are less due to e.g. deprecation of Diameter in-band security.


EDITORIAL
The guidelines in RFC 3580 are still valid, right?

OLD:
    "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
    Usage Guidelines" [RFC3580] provided guidelines for the use of the
    Remote Authentication Dialin User Service (RADIUS) within networks
    utilizing IEEE 802 local area networks.
NEW:
  "IEEE 802.1X Remote Authentication Dial In User Service (RADIUS)
    Usage Guidelines" [RFC3580]_provides_guidelines for the use of the
    Remote Authentication Dialin User Service (RADIUS) within networks
    utilizing IEEE 802 local area networks.

Regards, Benoit