Skip to main content

Last Call Review of draft-ietf-softwire-map-radius-23
review-ietf-softwire-map-radius-23-secdir-lc-eastlake-2019-05-31-00

Request Review of draft-ietf-softwire-map-radius
Requested revision No specific revision (document currently at 26)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2019-05-31
Requested 2019-05-17
Authors Sheng Jiang , Yu Fu , Chongfeng Xie , Tianxiang Li , Mohamed Boucadair
I-D last updated 2019-05-31
Completed reviews Intdir Telechat review of -22 by Bernie Volz (diff)
Opsdir Telechat review of -22 by Al Morton (diff)
Genart Last Call review of -23 by Joel M. Halpern (diff)
Opsdir Last Call review of -23 by Al Morton (diff)
Secdir Last Call review of -23 by Donald E. Eastlake 3rd (diff)
Genart Telechat review of -24 by Joel M. Halpern (diff)
Assignment Reviewer Donald E. Eastlake 3rd
State Completed
Request Last Call review on draft-ietf-softwire-map-radius by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Ac6qTBRpuiUAnlRQr-rEJABIw8g
Reviewed revision 23 (document currently at 26)
Result Has nits
Completed 2019-05-31
review-ietf-softwire-map-radius-23-secdir-lc-eastlake-2019-05-31-00
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  Document
editors and WG chairs should treat these comments just like any other last
call comments.

The summary of the review is Almost Ready.

This draft specifies new RADIUS attributes that correspond with DHCPv6
Options for a number of IPv4 over IPv6 protocols. The main scenario being
supported is that customer equipment connects to a Broadband Network
Gateway (BNG). The BNG then authenticates the user with a AAA server using
RADIUS. There is also a DHCPv6 server at the BNG and the value of relevant
DHCPv6 Options are populated at the BNG from the RADIUS attributes in the
response from the AAA server.

Section 6 provides Security Considerations. It consists almost entirely in
a list of references to security considerations in other RFCs.  This seems
pretty complete but reading it feels kind of scattered. It would be good if
a few sentences could be added and the maybe the material slightly
re-organized to make it clearer how the parts of the Security
Considerations fit together.

Trivia:

   - Although there isn't much questions here, I think it is usual when
   creating a registry that goes on an existing web page to identify that web
   page.
   - The acronyms BMR and DMR are only used once in the body of the
   document. Perhaps they could be dispensed with and only the spelled out
   version used at that one occurrence for each. There may be other acronyms
   like this.
   - lwAFTR should be expanded on first use.
   - There is a slightly awkward thing about the IANA Considerations
   section. The first sentence of Section 7 talks about requesting IANA to act
   but then each subsection redundantly requests action and, in fact Section
   7.1 request action at the start of each paragraph. Either (1) the first
   sentence should say something like "IANA is requested to perform the
   actions described in the subsections below." and all the other "request"
   wording should go away or (2) the first sentence should omit "request"
   wording and just say something like "IANA actions are discussed in the
   subsections below." and the "requests" left in the subsections.

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 1424 Pro Shop Court, Davenport, FL 33896 USA
 d3e3e3@gmail.com