Skip to main content

Last Call Review of draft-crocker-id-adoption-05

Request Review of draft-crocker-id-adoption
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2014-02-04
Requested 2014-01-09
Authors Adrian Farrel , Dave Crocker
I-D last updated 2014-02-04
Completed reviews Genart Last Call review of -05 by Robert Sparks (diff)
Opsdir Last Call review of -05 by Dan Romascanu (diff)
Secdir Last Call review of -05 by Klaas Wierenga (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Last Call review on draft-crocker-id-adoption by Ops Directorate Assigned
Reviewed revision 05 (document currently at 09)
Result Ready
Completed 2014-02-04

This is the OPS-DIR review of draft-crocker-id-adoption. The version that I
reviewed is


The OPS-DIR reviews are focused on the operational and manageability aspects of
the documents using RFC 5706 as guidance. Please consider these comments
together with the other IETF Last Call comments.

This document  Informational RFC status. It discussed the handling of the
documents that become working group items and the process of initial
submissions. It is a useful and clearly written document which does not deal
with specific operational
 or manageability aspects, thus RFC 5706 considerations do not apply. Also,
 from my experience, the OPS area presents no issues that are specific and
 different from the ones in other areas. Addressing the comments below could
 clarify and improve some of the document details, but are not blocking.


In section 1.1 I found:

   Creation or adoption

   of a draft by a working group -- as well as substantive changes to

   the document -- need to represent working group rough consensus.

I am not sure what the -– notation intents to convey. Why not just dropping it?


In section 2.2 the last bulleted item in the list of ‘basic considerations for
adoption’ is:


Is there strong working group support for working on the draft?

Any reason for mentioning here ‘strong working group support’ rather than
‘rough consensus’?


I believe that the document should avoid giving the impression that it provides
yet another definition of the rough consensus, as the text in section 2.2 might
lead some people to believe:

   Rough consensus:    Working group agreement to adopt is not

         required to be unanimous.

I would rather point to RFC 1603 (which talks about the rough consensus in a WG
as the dominant view of the WG as determined by the chairs) or to


In section 4 I found:

   Absent charter restrictions, a working group is free to create new

   documents.  It is not required that all drafts start as the effort of

   an individual.  Of course the criteria for brand new documents are

   likely to be the same as for those imported into the working group

   with the additional and obvious requirement that the working group

   chairs will need to appoint authors/editors before any work can


This text slightly puzzles me. Creating from scratch documents that are
directly WG documents is not (I believe) a common practice. Moreover, it begs
the question about how are some of the criteria for adoption in 2.2 which refer
explicitly to a ‘document’ verified.


I understand and agree with the intent of the authors to accommodate various
levels of maturity for initial WG documents. I would be careful however to
avoid pushing this to the extreme of providing only an outline with no content
at all. Maybe some text in section 4 explaining that a WG submission is
expected to be more than just a placeholder and should have some minimal
content would help.


The text in section 5.2 reflects the fact that the issue of competing drafts
has been looked in carefully by the authors. I wonder whether they considered
mentioning the (quite wide-spread) practice by which chairs invite
contributions to be submitted by a certain date, or at least the intention to
submit contributions be announced by a certain date – this limiting the risks
and adverse effects of last minute ‘surprises’.