Gunter Van de Velde firstname.lastname@example.org
Operational directorate reviews are solicited primarily to help the area directors improve their efficiency, particularly when preparing for IESG telechats, allowing them to focus on (potentially) troublesome documents and spend less time on the trouble-free ones. The ADs read the reviews, and really appreciate the time and effort that goes into them.
Improving the documents is an important, but clearly not the primary, purpose. An additional goal is to expose the OPS Directorate reviewers' to work going on in other parts of the IETF. Reviews from OPS Directorate members do not, in and of themselves, cause the IESG to block a document, but they are taken very seriously. The reviews may, however, provide advice to the OPS ADs or convince other IESG members to challenge or block a document. The reviews, particularly those conducted in IETF last call and earlier, may also help the document editors improve their documents.
Assignments are usually sent out weekly middle of the week (Tuesday-Wednesday). If you are not able to perform this review, please respond to the assignment request using the IETF datatracker (i.e. https://datatracker.ietf.org/doc/draft-xya-foobar/) to decline the review request. This allows to keep track of your non-availability to re-assign the review.
Please try to complete reviews by the end of IETF last call, allowing the authors to respond to comments well in advance of the IESG telechat. In any case, have your review (or re-review in case of new versions) done by the Friday before the Thursday telechat.
As a general rule, reviews after the telechat date are not useful, but check the draft tracker to see if the document has been deferred.
The most important item is to give the ADs a sense of how important it is that they pay attention to the document.
A Check-list of possible questions/topics to address in an OPS Directorate review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review.
Once you have been assigned a document, you are generally expected to stay with that document through completion, even if additional reviewers are assigned. Accordingly, when a document you've already reviewed is revised or is scheduled for the IESG telechat, the secretary may assign it to you again for a recheck. This re-review will happen on either special request of an interested party, or when the original review request identified significant operational issues. These reassignments will be flagged with a new assignment email and a new datatracker review allocation.
Look to see if the draft has changed since the last call review and briefly let the ADs know if any identified showstopper problems have been fixed or still remain (please CC email@example.com as well, for tracking). Feel free to include your original review, just to make it easier to find. Particularly on these returning items, remember that http://tools.ietf.org has precomputed diffs for WG docs.
When an OPS-DIR review request has been completed it must be shared with the operational directorate team and be marked as completed in datatracker.
Sharing with the operational directorate team is achieved by placing the document name in the Subject line, and start a new thread. Start a new OPS Directorate threat (as opposed to replying to an old one, for example your previous review) as the OPS Directorate secretary will only check the new threads on the OPS Directorate list to find your review, and mark your review done in datatracker. Send all reviews, including "no problem" reviews, firstname.lastname@example.org, and < draftname >.email@example.com. The latter alias reaches draft editors, chairs, and others listed in the ID tracker's notification field. The review thread should now be visible in the operational directorate email archive located at https://www.ietf.org/mail-archive/web/ops-dir/current/maillist.html.
Next, IETF datatracker should to be accessed by the OPS-DIR reviewer to log the OPS-DIR review request completion. The datatracker can be found for each individual review request, using a similar structure as follows https://datatracker.ietf.org/doc/draft-xya-foobar/. The datatracker is used to log and track the state of each review request. The completed review request can identify a draft as “Ready”, “Not Ready”, “Has Nits”, “Has Issues” or “Serious Issues”. In addition, the email archive URL containing the completed OPS-DIR review must be inserted into datatracker to complete the review request.
If you discover an important issue that would require feedback from the entire IETF community, you may send to firstname.lastname@example.org instead of (or in addition to) the other mailing lists. If there's something you want to share only with the ADs, send a separate, ADDITIONAL, message to them, flagged as private, but also send a note to the broader world, as above.
Here's some sample boilerplate, if you care to use it:
Reviewer: Your Name Review Result: Ready/Not Ready/Has Nits/Has Issues/Serious Issues 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.
It would be useful to include in the email the general summary whether the draft is Ready, Ready with nits, Ready with issues, Almost ready and Not ready.
Ready means you do not have any real comments to the document. Ready with nits means there was something in the document which might require new revision, for example typo, or changing language more readable, but not something that really would require ADs to put discuss on the document. Ready with issues means there is something in the document that might require ADs to put discuss on the document, or which they need to check more carefully, i.e. some kind of security issue.
FYI, all existing aliases, along with its members, are documented at http://tools.ietf.org/draft/aliases.
WG chairs may be reached at email@example.com.
Replace draftname by draft-ietf-wg-topic (without -xx version):
|draftname@…||Draft authors (for now, could change)|
|draftname.chairs@…||WG Chairs (if the draft is a WG draft)|
|draftname.notify@…||The addresses entered into the tracker's email notification field for the draft|
|draftname.ad@…||The sponsoring AD, if the draft has gone to the IESG|
|draftname.all@…||All of the above, merged into one alias|
The WG chair can request and early review of the document he feels is almost ready (usually after WG LC or similar), just to get early feedback on the document before the IETF LC. These early requests are marked with 'E' in the assignment email, and they should be done during next two weeks or so to be useful for the WG. Their reviews should be sent to the same places than other reviewers, but it is very important to include the < draftname >.firstname.lastname@example.org so the reviews go the WG Chairs. You may also include the WG list if you want, but WG chairs can also forward your reviews there.
It’s expected that early reviews will imply multiple new draft versions. So the reviewer must be ready to follow this draft for some time.
For some background information on this experiment, see EarlyReview.
We have about forty-five reviewers in the pool. First half of 2013 indicated about 35 reviews per month.
Accordingly, we should each be assigned one new document approximately every four to six weeks. Note that one document might easily come up two or more times (e.g., during Early review, then again during IETF last call and when placed on the telechat agenda).
The secretary is using the Area review tool for round-robin assignments. This tool is also available for the reviewers at OpsDir ART Tools. There is also list of opsdir members. Note that this list may differ vary slightly from the current mailing list membership, and the list used in the actual assignment tool. Inform the OPS Directorate secretary to take action if there is an inconsistency on your behalf, so that it can be corrected.
Feel free to send email@example.com and any requests regarding your own OPS Directorate workload (e.g., "this document can easily be split into three segments, could you assign two more people", "I'm going on holiday, don't give me any assignments until September 2nd", "I'm bored, give me more to do"). While we're happy to accommodate your schedule, more notice will make it easier to reassign the review to someone else.
The flags are autogenerated using following rules:
|Al Morton||acmorton@…||Performance OPS and Management|
|Carlos Marcelo Martinez Cagnazzo||carlosm3011@…|
|Eric Vyncke||evyncke@…||IPv6, security, enterprise/commercial|
|Fred Baker||fredbaker.ietf@…||IPv6, Routing, QoS, NAT, AQM|
|Gunter Van de Velde||gunter.van_de_velde@…||IPv6 and Routing|
|Joel Jaeggli||joelja@…||operations, routing, internet, DNS|
|Jouni Korhonen||jouni.nospam@…||IPv6, Mobility, Diameter, DNS, DHCPv6, and if needed 3GPP EPC related topics except SIP (no SIP!!)|
|Linda Dunbar||ldunbar@…||DHCP, DNS, Internet, Routing, Identity, firewall, policy, etc. no MIB please|
|Mehmet Ersue||mehmet.ersue@…||O&M and Transport prio 2: Internet, App and RAI，on vacation until Jan 7|
|Susan Hares||shares@…||Routing (all WGs), netconf, netmod, yang modules, MIBs, IPv6, DHCP, DNS, some security areas|
|Tim Chown||tjc@…||IPv6, multicast|
|Tina Tsou||tina.tsou@…||Internet, Routing|
|Will(Shucheng) Liu||liushucheng@…||SDN/NFV related, IPv6, security, IoT, ICN (will be on vacation in Feb.)|
|Zitao Wang (Michael)||wangzitao@…||SDN/NFV related, netconf, netmod, yang modules.|
A Check-list of possible questions/topics to address in an OPS-DIR review may be found in Appendix A of RFC 5706. Only include the questions that apply to your review.
The content of this page was last updated on 2019-07-29. It was migrated from the old Trac wiki on 2022-12-19.