Last Call Review of draft-ietf-mpls-ipv6-only-gap-02

Request Review of draft-ietf-mpls-ipv6-only-gap
Requested rev. no specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-10-27
Requested 2014-10-16
Other Reviews Genart Last Call review of -02 by Francis Dupont (diff)
Genart Telechat review of -03 by Francis Dupont (diff)
Secdir Last Call review of -02 by Tobias Gondrom (diff)
Rtgdir Early review of -01 by Alvaro Retana (diff)
Review State Completed
Reviewer Tim Chown
Review review-ietf-mpls-ipv6-only-gap-02-opsdir-lc-chown-2014-10-30
Posted at
Reviewed rev. 02 (document currently at 04)
Review result Has Nits
Draft last updated 2014-10-30
Review completed: 2014-10-30



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."




] specifies a set of