Skip to main content

Last Call Review of draft-ietf-mpls-ipv6-only-gap-02
review-ietf-mpls-ipv6-only-gap-02-opsdir-lc-chown-2014-10-30-00

Request Review of draft-ietf-mpls-ipv6-only-gap
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-10-27
Requested 2014-10-16
Authors Wesley George , Carlos Pignataro
I-D last updated 2014-10-30
Completed 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)
Opsdir Last Call review of -02 by Tim Chown (diff)
Rtgdir Early review of -01 by Alvaro Retana (diff)
Assignment Reviewer Tim Chown
State Completed
Request Last Call review on draft-ietf-mpls-ipv6-only-gap by Ops Directorate Assigned
Reviewed revision 02 (document currently at 04)
Result Has nits
Completed 2014-10-30
review-ietf-mpls-ipv6-only-gap-02-opsdir-lc-chown-2014-10-30-00
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