Last Call Review of draft-ietf-dime-4over6-provisioning-03
review-ietf-dime-4over6-provisioning-03-opsdir-lc-chown-2015-08-06-00

Request Review of draft-ietf-dime-4over6-provisioning
Requested rev. no specific revision (document currently at 06)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2015-08-04
Requested 2015-07-06
Authors Cathy Zhou, Tom Taylor, Qiong Sun, Mohamed Boucadair
Draft last updated 2015-08-06
Completed reviews Genart Last Call review of -03 by Russ Housley (diff)
Opsdir Last Call review of -03 by Tim Chown (diff)
Assignment Reviewer Tim Chown 
State Completed
Review review-ietf-dime-4over6-provisioning-03-opsdir-lc-chown-2015-08-06
Reviewed rev. 03 (document currently at 06)
Review result Has Nits
Review completed: 2015-08-06

Review
review-ietf-dime-4over6-provisioning-03-opsdir-lc-chown-2015-08-06

Hi,

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 with the intent of improving the 
operational aspects of the IETF drafts. Comments that are not 
addressed in last call may be included in AD reviews during the IESG 
review.  Document editors and WG chairs should treat these comments 
just like any other last call comments. 

The draft describes information that needs to be provisioned on a CPE
to support IPv4 in IPv6 tunnelling via a number of transition techniques,
specifically DS-Lite, Lightweight 4over6, and MAP-E. It also includes
consideration of IPv4 multicast. The result is a list of Attribute-Value
Pairs (AVPs) to be carried within the Diameter protocol.

Overall, I believe the document is Ready. Despite its nature (as a list
of definitions) it generally reads very well.

There are some minor typos, and items to be checked, as listed below,
some of which would no doubt be picked up by the RFC Editor:

1. Section 2.1 line 4, should be “provisions” (plural).

2. Section 2.5, line 5 of second bullet point, “IPv4” not “Pv4”.

3. Section 3.3.2. I found the third paragraph a little clumsy to read;
   perhaps clarify the SSM prefix of ff3x::/32 in effect being a /96?. 
   Also, do you mean bits 33-95 here, or bits 32-95 (twice)?

4. Section 3.5, Figure 5. Should the vertical lines be below 8 and 16,
   rather than below 7 and 15?

5. Section 6 reads a little strangely, in that it says in 6.1 “hey, you can
   mitm Diameter”, then 6.2 says “you MUST use TLS/IPsec avoiding
   intermediate nodes”. Seems a little conflicting in outlook?

6. Two transition drafts cited in the text are now published as RFC 7596 
   and RFC 7597.

Best wishes,
Tim