Skip to main content

Last Call Review of draft-ietf-v6ops-enterprise-incremental-ipv6-05
review-ietf-v6ops-enterprise-incremental-ipv6-05-opsdir-lc-taylor-2014-06-27-00

Request Review of draft-ietf-v6ops-enterprise-incremental-ipv6
Requested revision No specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-06-24
Requested 2014-06-02
Authors Kiran K. Chittimaneni , Tim Chown , Lee Howard , Victor Kuarsingh , Yanick Pouffary , Éric Vyncke
I-D last updated 2014-06-27
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Genart Telechat review of -05 by Robert Sparks (diff)
Secdir Last Call review of -05 by Steve Hanna (diff)
Opsdir Last Call review of -05 by Ron Bonica (diff)
Opsdir Last Call review of -05 by Tom Taylor (diff)
Assignment Reviewer Tom Taylor
State Completed
Request Last Call review on draft-ietf-v6ops-enterprise-incremental-ipv6 by Ops Directorate Assigned
Reviewed revision 05 (document currently at 06)
Result Has issues
Completed 2014-06-27
review-ietf-v6ops-enterprise-incremental-ipv6-05-opsdir-lc-taylor-2014-06-27-00
I have reviewed this document as part of the Operational directorate's 


ongoing effort to review all IETF documents being processed by the IESG.



These comments were written primarily for the benefit of the
operational area directors.   Document editors and WG chairs should
treat these comments just like any other last call comments.


Revision reviewed: draft-ietf-v6ops-enterprise-incremental-ipv6-05



Summary:  The Gen-Art review by Robert Sparks was noted. In the light of 


that review it did not seem worthwhile to make further editorial 


comments (but I'm sure the RFC Editor will propose changes in a number 


of places). Some minor substantive comments are given below.






ID Nits: complains about use of RFC 2119 capitalization without a 


corresponding incorporation of the RFC 2119 boilerplate. A number of the 


references need updating.




Comments:



1. In Section 2.2.1, the implicit assumption is that IPv6 readiness is a 


binary condition, rather than an accumulation of features that the IETF 


is still trying to adjust. The authors may wish to warn administrators 


that they cannot necessarily take vendors' assessment of IPv6-readiness 


at face value, because definitions of that state may vary. Instead, the 


administrator needs to develop a checklist of elements of IPv6 


implementation, and eventually will need to verify that these elements 


are functioning correctly, beginning in the vendor's lab if the IPv6 


capability is not already present in the field.






2. While smartphones and tablets are addressed explicitly in Section 


4.3, they are not mentioned in the lists of equipment given in the 


introductory sections 1 and 4. Just a suggestion that they be mentioned, 


perhaps as "mobile devices", so the reader doesn't get the impression 


that the advice in the document is dated.






3. Meta-comment: The hidden issue in Section 4.1 is the desire of 


enterprise administrators to control host configuration using DHCPv6 for 


security reasons, vs. the determination of a blocking plurality of IETF 


participants to reserve some configuration (e.g., default route) to 


basic IPv6 mechanisms only. IESG members who have not followed 


discussions of this topic should be aware that they were extensive, did 


not end in consensus, but did provoke expressions of frustration from 


enterprise-oriented operators, of the nature of: "Why should we bother 


to be here if you won't listen to us?".




Tom Taylor