Telechat Review of draft-ietf-softwire-mesh-multicast-23

Request Review of draft-ietf-softwire-mesh-multicast
Requested rev. no specific revision (document currently at 25)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2018-09-25
Requested 2018-09-10
Authors Mingwei Xu, Yong Cui, Jianping Wu, Shu Yang, Chris Metz
Draft last updated 2018-09-21
Completed reviews Rtgdir Last Call review of -22 by Nicolai Leymann (diff)
Tsvart Last Call review of -22 by Joseph Touch (diff)
Genart Last Call review of -22 by Brian Carpenter (diff)
Genart Telechat review of -23 by Brian Carpenter (diff)
Assignment Reviewer Brian Carpenter 
State Completed
Review review-ietf-softwire-mesh-multicast-23-genart-telechat-carpenter-2018-09-21
Reviewed rev. 23 (document currently at 25)
Review result Ready with Issues
Review completed: 2018-09-21


Gen-ART telechat review of draft-ietf-softwire-mesh-multicast-23

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at

Document: draft-ietf-softwire-mesh-multicast-23.txt
Reviewer: Brian Carpenter
Review Date: 2018-09-22
IETF LC End Date: 2018-09-06
IESG Telechat date: 2018-09-27 

Summary: Ready with issues


Thank you for handling my Last Call comments. I am mentioning my previous
issue again in case the IESG thinks any further change is needed.


"7.3.  Fragmentation

   The encapsulation performed by an upstream AFBR will increase the
   size of packets.  As a result, the outgoing I-IP link MTU may not
   accommodate the larger packet size.  It is not always possible for
   core operators to increase the MTU of every link, thus fragmentation
   after encapsulation and reassembling of encapsulated packets MUST be
   supported by AFBRs [RFC5565].  The specific requirements for
   fragmentation and tunnel configuration COULD be referred to in
   [I-D.ietf-intarea-tunnels], which is under revision currently."

This text is significantly improved. However, I still wonder, if I-IP is
IPv6, how does the originator of the IPv6 packet (the AFBR) know that it
needs to include a fragment header? In addition to the discussion in
[I-D.ietf-intarea-tunnels], isn't it necessary to specify that PMTUD
should be enabled and that ICMPv6 packets must not be filtered?


Please change COULD to SHOULD in the above paragraph.