Skip to main content

Last Call Review of draft-ietf-v6ops-rfc3316bis-03
review-ietf-v6ops-rfc3316bis-03-secdir-lc-kaufman-2013-09-05-00

Request Review of draft-ietf-v6ops-rfc3316bis
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2013-09-02
Requested 2013-08-22
Authors Jouni Korhonen , Jari Arkko , Teemu Savolainen , Suresh Krishnan
I-D last updated 2013-09-05
Completed reviews Genart Last Call review of -03 by Alexey Melnikov (diff)
Genart Telechat review of -04 by Alexey Melnikov (diff)
Secdir Last Call review of -03 by Charlie Kaufman (diff)
Assignment Reviewer Charlie Kaufman
State Completed
Request Last Call review on draft-ietf-v6ops-rfc3316bis by Security Area Directorate Assigned
Reviewed revision 03 (document currently at 06)
Result Has nits
Completed 2013-09-05
review-ietf-v6ops-rfc3316bis-03-secdir-lc-kaufman-2013-09-05-00

Resending with corrected mailing list name (if replying, please reply to this
copy).



From:

 Charlie Kaufman

Sent:

 Friday, August 30, 2013 10:10 AM

To:

 secdir at ietf.org; iesg at ietf.org; 'draft-ietf-v6ofs-rfc3316bis at
 tools.ietf.org'

Subject:

 secdir review of draft-ietf-v6ops-rfc3316bis-03



I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written primarily for the benefit of the security area
directors.  Document
 editors and WG chairs should treat these comments just like any other last
 call comments.



This Informational (if approved) RFC is a cleanup update and refresh of RFC
3316, which discusses how to implement IPv6 on 3GPP Cellular hosts. It
incorporates several RFCs that have come out since RFC 3316 along with other
clarifications.
 There is a substantial Security Considerations section dealing with security
 considerations for dealing with a cellular environment, but this document
 mostly references other RFCs and does not introduce any security issues of its
 own.



Minor (non-security) issues:



This document does not use the MUST and SHOULD conventions of most RFCs. I’ve
long believed these were inappropriate for Informational RFCs, but this is the
first time I’ve seen anyone agree with me and remove them.



There are many places where referenced RFCs are not placed in brackets (e.g.
“RFC 5095” instead of [RFC5095].



I found 2 typos:

Page 5: “build-in” -> “built-in”

Page 17: “causes no hard” -> “causes no harm”



                --Charlie