Last Call Review of draft-ietf-6man-rfc1981bis-04
review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04-00

Request Review of draft-ietf-6man-rfc1981bis
Requested rev. no specific revision (document currently at 08)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2017-03-01
Requested 2017-02-01
Other Reviews Intdir Early review of -03 by Donald Eastlake (diff)
Secdir Last Call review of -04 by Rifaat Shekh-Yusef (diff)
Genart Last Call review of -04 by Stewart Bryant (diff)
Tsvart Telechat review of -04 by Joseph Touch (diff)
Rtgdir Last Call review of -06 by Ines Robles (diff)
Secdir Telechat review of -06 by Rifaat Shekh-Yusef (diff)
Genart Telechat review of -06 by Stewart Bryant (diff)
Review State Completed
Reviewer Susan Hares
Review review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/2bZxXfgdPg8bxfVBrrqkPxKF1Eg
Reviewed rev. 04 (document currently at 08)
Review result Has Issues
Last updated 2017-03-04

Review
review-ietf-6man-rfc1981bis-04-opsdir-lc-hares-2017-03-04

ack, Steve,Jeffrey, and Bob: 

Thank you for taking on this important revision to the document.  I hope my comments help to improve the document so this important change can ge deployed. 

I have reviewed this as part of the routing directorate review.  This review should be treated as any IETF LC comments.  

Sue Hares 

RTG-DIR Review 

Status: I have three concern plus editorial nits. 

#1 - Concern 1 is technical regarding the interaction with the MTU option in ND/SEND plus 
 ditorial nits.  See the comments below.  I am not an ND/SEND Expert, please have an imoplementer look at the requirements. 

Concern: I cannot tell how this interacts with the ND/SEND protocol in the following areas below. 
 1) Neighbor Unreachability Detection is used for all paths between hosts
   and neighboring nodes, including host-to-host, host-to-router, and
   router-to-host communication.
   
   If the source node is on the link and the destination node available
   through the router, and the router is in the process of sending a 
   MTU option to increase the size?  How does your algorithm work? 
   
   Are the packetization layer notified? 
   Is the original value a stale notification over time?  
   You indicate it MUST NOT be done in less than 5 minutes, and that 
   10 minutes is the norm. 
   
   Is 10 minutes really the best response time for this particular case?    
   Or did I miss something in your draft? 
     
   
2) Assume the same situation as #1, but the 
   router sends an MTU option to decrease the size. 
   
   In this case, the router is sending information that 
   the MTU has changed, but the first indication for the 
   end system is based on a Packet-too-Big Message after sending. 
   

3) For a multicast packet (3000 bytes), assume that 
the multicast path reaches two different routers (router-a 
and router-b).  Assume the on-link MTU is 3500 bytes, but the 
previous router-A and router-B MTU is 2500 bytes.  

Router-a responds to the packet with 10ms sending a 
MTU option that changes the MTU to support this packet. Router-B sends a redirect 
for multicast address to Router-A after 30 ms.  

What happens to your path calculation?  
Is this again, the 5 minutes (minimum) and 10 minute normal to 
reset this value. 

4) What happens if the ND process is instantiated by
SEND protocol, and the host does not contain the appropriate 
certification information to timely updates? 

Again, the host guessing at the appropriate value? 


#2 - Concern 2 - How does SEND's implementation of MTU option. 
mitigate or have no effect on this MTU.  Is there a recommendation 
that should be made in section 6.  Again, please ask a SEND expert 
for review. 

#3 - Concern 3 - content of document 
 
This document has two parts: protocol requirements and implementation requirements. 
8 paragraphs (1 page) indicates the IPv6 specification and 6 pages gives the implementation? 

Why did this get split in to 2 documents?  Even if this was a bis, document would it not 
be better to provide minimal specification for the protocol change and a larger document 
with implementation information. 

I'm fine with the WG/ADs deciding, this is the way the document has to go forward -- but the question should be asked. 

Editorial nits:  
#1 nit - section 5.2 page 8, paragraph beginning 

Old /Note: if the /
New/Note: If the/ 

#2 nit - section 5.2 page 9 paragraph begin 

Old /Note: even if/ 
New /Note: Even if/ 

#3 nit - section 5.3 page 10 paragraph beginning 

Old /Note: an implementation/
New/Note: An implementation/