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 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. In my view the document is ready for publication, though the ADs should be sure they are happy with the general nature of the text - see the three points below. My knowledge of MPLS is not deep enough to know if all gaps have been identified. I note that the current -02 version had a Last Call issued on 13th October, with no comments on it in the list archive. 1) Is it OK to publish the gap analysis as a ‘snapshot’ document? The document as presented is a snapshot of gaps in IPv6-only MPLS operation. There has been some previous discussion of the draft regarding whether it should be published or kept as a ‘living document’ tracking the status of the gaps being closed. I think publishing is fine, but I would recommend (as was done in 6renum for example) that the open gaps are taken to a new draft which does get updated as the gaps are addressed. 2) Are the proposed gap solutions viable? It’s not clear to me whether all the proposed gap solutions have consensus and are viable, or are just current best ideas. It might be worth making this clearer, but that could equally be done in a separate draft as suggested above, allowing this draft to be published as is. 3) Should the gaps be discussed in line or presented in an appendix? Another consideration to be made here is whether the gaps should be identified in the current style, i.e. in line with the body of the text, or pushed to an appendix. This was discussed for the -01 version, and in my view the current style of discussion in line with a summary table at the end is fine.  Finally, there are some minor style nits which I assume the RFC Editor should catch/check, in particular the way that 'double references’ appear, e.g." RFC3107 [ RFC3107 ] specifies a set of ” ...  Tim