Last Call Review of draft-ietf-v6ops-clatip-02
review-ietf-v6ops-clatip-02-secdir-lc-hallam-baker-2014-06-05-00
Request | Review of | draft-ietf-v6ops-clatip |
---|---|---|
Requested revision | No specific revision (document currently at 04) | |
Type | Last Call Review | |
Team | Security Area Directorate (secdir) | |
Deadline | 2014-06-10 | |
Requested | 2014-05-30 | |
Authors | Cameron Byrne | |
I-D last updated | 2014-06-05 | |
Completed reviews |
Genart Last Call review of -02
by Russ Housley
(diff)
Genart Telechat review of -03 by Russ Housley (diff) Secdir Last Call review of -02 by Phillip Hallam-Baker (diff) |
|
Assignment | Reviewer | Phillip Hallam-Baker |
State | Completed | |
Request | Last Call review on draft-ietf-v6ops-clatip by Security Area Directorate Assigned | |
Reviewed revision | 02 (document currently at 04) | |
Result | Ready | |
Completed | 2014-06-05 |
review-ietf-v6ops-clatip-02-secdir-lc-hallam-baker-2014-06-05-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. 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. The document is simply an assignment request for a reserved IP address block for a scheme described in [RFC6333] and [RFC6877]. The block previously assigned to DSLite is now assigned to related, non-competing functions. The document would be rather easier to make sense of if the start and the end of the address range had been given. 192.0.0.0/29 is 192.0.0.0...192.0.0.7 This does not matter much because RFC6333 actually assigns specific addresses for specific functions within this range. Exhaustion is not really an issue since in extremis the response could be more tunnels.