Skip to main content

Last Call Review of draft-sheffer-rfc6982bis-
review-sheffer-rfc6982bis-opsdir-lc-vyncke-2016-06-13-00

Request Review of draft-sheffer-rfc6982bis
Requested revision No specific revision (document currently at 03)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2016-05-31
Requested 2016-04-18
Authors Yaron Sheffer , Adrian Farrel
I-D last updated 2016-06-13
Completed reviews Secdir Last Call review of -00 by Adam W. Montville (diff)
Opsdir Last Call review of -?? by Éric Vyncke
Assignment Reviewer Éric Vyncke
State Completed
Request Last Call review on draft-sheffer-rfc6982bis by Ops Directorate Assigned
Result Has nits
Completed 2016-06-13
review-sheffer-rfc6982bis-opsdir-lc-vyncke-2016-06-13-00

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 with the intent of improving the operational aspects of
the IETF drafts. Comments that
 are not addressed in last call may be included in AD reviews during the IESG
 review.  Document editors and WG chairs should treat these comments just like
 any other last call comments.

[The review was asked for -01 but since then -03 has been published, so,
reviewing the latest one]

Abstract:

This document describes a simple non mandatory process that allows authors of
Internet-Drafts to record the status of known implementations by including an
Implementation Status section (which would be removed before publication as
RFC). The intended
 status is BCP.

Here is my review:

Section 2: it states "this section can contain information about the
interoperability of any or all of the implementations", rather than "can", I
would suggest the use of "should" because the goal of having multiple
implementations is exactly to test for
 interoperability.

In the same vein, quite often a protocol specification I-D has companion I-Ds
about management (yang model for example), i would suggest that this section
also includes either information about those companion I-Ds or a link to the
relevant section of
 the companion I-Ds.

Section 3 about alternative formats, it is indeed nice to leave the door open
to any future tool to keep track of implementations outside of an I-D section:
this is probably more flexible, easier to update and more scalable. At the
expense perhaps of lack
 of control?

Section 4, I like the aspect of using this section to make interoperability
test.

Hope it helps to polish this nice idea,

-éric