Routing Area Directorate

The Routing Area Directorate is an advisory group of routing experts selected by the Area Directors.

The notion of a directorate is defined in RFC 2418 as follows:

In many areas, the Area Directors have formed an advisory group or directorate. These comprise experienced members of the IETF and the technical community represented by the area. The specific name and the details of the role for each group differ from area to area, but the primary intent is that these groups assist the Area Director(s), e.g., with the review of specifications produced in the area.

What Does the Directorate Do?

The Routing Area Directorate is tasked to help the Routing Area Directors by performing specific tasks as set out below. Additional tasks may be added to this list over time.

  1. Review all documents submitted to the IESG for publication that have routing significance
    How is Review Triggered?
    1. Triggered by request for early review
      (by any AD or by any Routing Area WG chair)
    2. Triggered by document moving to 'publication requested' state
      (for routing area documents)
    3. Triggered by IETF last call
      (for non-routing area documents that get IETF last call)
    4. Triggered by entry on the IESG agenda
      (for other documents)
    Who Reviews Each Document?
    1. Each document is assigned to an individual member of the routing directorate
    2. Reviewer responds rapidly with decision "yes I will do it in appointed time", "yes I will do it but need more time", "no I cannot do it".
    Routing Directorate review is not a substitute for the ADs reviewing documents that have major routing area implications.
  2. Assist ADs with judgment issues when requested
    The ADs may send email to the routing directorate list when they have issues that they want help with.

How is Document Review Organized?

  1. Every Directorate member MUST notify the Routing Area Directorate Coordinator of periods of time when they will be unable to review documents (eg, due to vacation, travel, or whatever).
  2. The Routing Area Directorate Coordinator will determine which "triggered" documents are appropriate for review.
    This cannot require the Coordinator to review each document so the following relevance criteria will be applied.
    1. Some WGs are defined as "relevant to routing area" such that all their output will be reviewed. This will include:
      • All Routing Area WGs
      • Other key working groups as determined by the ADs
      • Some non-IETF WGs (such as the RRG) as determined by the ADs
    2. ADs in other areas may alert the Routing ADs if they feel that a document has relevance to the Routing Area, and may request early review.
    3. Documents that are not from a WG, but that nevertheless have an IETF last call are evaluated by the Routing Area Directorate Coordinator.
      • If the Coordinator determines that a review is needed, the review request is sent out as above.
      • If the Coordinator is unsure or decides "no", the Coordinator sends an email to the ADs. Either AD may request that a review is held.
    4. Documents that are not from a WG and do not have an IETF last must be assessed by the ADs who will request a review if necessary.
  3. The Routing Area Directorate Coordinator assigns each document that is triggered for review to a reviewer and issues a Review Request
    1. If a Routing Area Directorate member is also a WG chair, they will not be assigned any documents from the WG they chair.
      (It is assumed that they already review documents from own their WG).
    2. WG secretaries / administrators / routing advisors will not get assigned documents from the WGs they serve.
    3. Authors and contributors to a document will not be assigned that document for review.
  4. The Review Request includes:
    1. Deadline for completion of the review
    2. Specific procedures to follow (such as, where to send the response)
    3. Boilerplate text to include in response
    4. A list of things to look for and how to report them
  5. The reviewer must ACK within 24 hours "can review by deadline", "can review, but need additional time", or "can't review"
    1. No reply is interpretted as "can review by deadline".
    2. If a reviewer can't provide the review it is assigned to different reviewer.
    3. If a reviewer asks for additional time, the review may be assigned to a different reviewer if the extra time cannot be found.
    4. Reviewers will be expected to review three documents every six months (if requested) or risk being dropped from the Directorate.

How is the Directorate Formed?

  1. Directorate members are assigned to the Directorate by the Routing Area Directors.
  2. There is an expectation that Routing Directorate membership will not be limited to 'old-time routing gods from years past'. It is assumed that the Directorate will include younger and newer participants who are interested in 'learning while doing work'.
  3. Each assignment is for a three year term.
  4. The terms are staggered so that approximately 1/3 of the directorate members have their term end each year.
  5. When the Directorate is first established members of the Directorate will be assigned either one year, two years, or three years in their first term.
    When first being signed up, members MAY request a shorter term if they would prefer to start with a shorter commitment.
  6. When a member's term expires, the Routing ADs may replace the person whose term expires, may reappoint the same person, or may reduce the size of the Directorate.
    There is no expectation that the same person will either want to be returned, or will be returned.
  7. The three year term serves as the limit of the commitment of a Directorate member, but also serves as a way to return Directorate members to the community.
  8. In deciding whether to reappoint a member whose term has expired, the routing ADs may consider the quantity of work that they have done, the ADs' impression of the quality of the work, and the comments from the authors regarding the reviews.
  9. Routing ADs can assign additional members to the Directorate whenever they want to, subject to willingness of people to serve.
  10. Both ADs need to agree in order to assign a member to the Directorate.

How Are the Directorate Members Rewarded?

  1. This is a way for routing experts to contribute to the routing area, and for people to learn more about the routing area and to get the gratitude of the routing directors.
  2. Routing Area Directorate Members will be listed on a public web page.
  3. Routing directorate members can put this fact on their resume, and NomCom can take this into account for future appointments. ADs can also take this into account in choosing WG chairs.
  4. The ADs may (at their discretion) try to find a way to show their gratitude (for example, through the purchase and distribution of beer).

Area Directors being advised:

  • Adrian Farrel (adrian at olddog.co.uk)
  • Stewart Bryant (stbryant at cisco.com)

Routing Area Directorate Coordinator

  • Deborah Brungard (db3546 at att.com)

Backup Routing Area Directorate Coordinator

  • Dan Li (danli at huawei.com)

The Directorate currently includes the following advisors:

Name Email Affiliation Term End Date
Stig Venaas stig at venaas.com Cisco 31 December 2014
Ross Callon rcallon at juniper.net Juniper Networks 31 December 2014
Julien Meuric julien.meuric at orange.com Orange 31 December 2012
John Scudder jgs at juniper.net Juniper Networks 31 December 2012
Dimitri Papadimitriou Dimitri.Papadimitriou at alcatel-lucent.com Alcatel-Lucent 31 December 2014
Loa Andersson loa at pi.nu Ericson 31 December 2014
Lou Berger lberger at labn.net LabN Consulting 31 December 2012
David Sinicrope david.sinicrope at ericsson.com Ericsson 31 December 2013
Acee Lindem acee.lindem at ericsson.com Ericsson 31 December 2013
Mike Shand mshand at cisco.com Cisco 31 December 2012
Nabil Bitar nabil.n.bitar at verizon.com Verizon 31 December 2013
Enke Chen enkechen at cisco.com Cisco 31 December 2012
John Drake jdrake at juniper.net Juniper Networks 31 December 2013
Joel Halpern jmh at joelhalpern.com Ericsson 31 December 2012
Young Lee leeyoung at huawei.com Huawei 31 December 2014
Danny McPherson danny at tcb.net VeriSign 31 December 2012
Ben Niven-Jenkins ben at niven-jenkins.co.uk Velocix 31 December 2014
Abhay Roy akr at cisco.com Cisco 31 December 2012
Jamal Hadi Salim hadi at mojatatu.com Mojatatu Networks 31 December 2013
Tomonori Takeda takeda.tomonori at lab.ntt.co.jp NTT 31 December 2014
Thomas Morin thomas.morin at orange.com Orange 31 December 2013
Russ White russw at riw.us 31 December 2013
Matthew Bocci matthew.bocci at alcatel-lucent.com Alcatel Lucent 31 December 2014
Alia Atlas akatlas at juniper.net Juniper Networks 31 December 2012
Jia He hejia at huawei.com Huawei Technologies 31 December 2013
Thomas Clausen thomas at thomasclausen.org Ecole Polytechnique 31 December 2014
Eric Gray eric.gray at ericsson.com Ericsson 31 December 2012
Alvaro Retena alvaro.retena at hp.com Hewlett-Packard 31 December 2014
Martin Vigoureux martin.vigoureux at alcatel-lucent.com Alcatel-Lucent 31 December 2012
Sasha Vainshtein alexander.vainshtein at ecitele.com ECI Telecommunications 31 December 2014
Dan Frost danfrost at cisco.com Cisco 31 December 2012
Geoff Huston gih at apnic.net APNIC 31 December 2013
Les Ginsberg ginsberg at cisco.com Cisco 31 December 2014

The Routing Area Directorate can be reached at rtg-dir@ietf.org.

Routing Directorate Review Output

The Routing Directorate output is in the form of emails. As far as possible, those emails follow a template so that it is easy for recipients to process them.

Routing Directorate Review Template

To:

  • rtg-ads@tools.ietf.org

Cc:

  • rtg-dir@ietf.org;
  • draft-name.all@tools.ietf.org;

Subject:

  • RtgDir review: draft-name-version.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-name-version.txt
Reviewer: your-name
Review Date: date
IETF LC End Date: date-if-known
Intended Status: copy-from-I-D

Summary:

  1. Choose from this list...
    1. No issues found. This document is ready for publication.
    2. This document is basically ready for publication, but has nits that should be considered prior to publication.
    3. I have some minor concerns about this document that I think should be resolved before publication.
    4. I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.

Comments:

  • Please supply an overview of the draft quality and readability.
  • Include anything else that you think will be helpful toward understanding your review.

Major Issues:

  • Major issues are the type of concerns that will result in the document being blocked until they are resolved. The Routing ADs will become involved.
  • Please include all of the major issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts).
  • If you find no major issues, please write: "No major issues found."

Minor Issues:

  • Minor issues are concerns about clarity or technical accuracy that should be discussed and resolved before publication, but which would normally be resolved between the authors and the reviewers.
  • Please include all of the minor issues you have found. Give as much context information as possible (e.g., section numbers, paragraph counts).
  • If you find no minor issues, please write: "No minor issues found."

Nits:

  • Nits are editorial or layout items. They are things that would ideally be resolved before publication to make the document more readable, and may be raised now to save the RFC Editor work.
  • Usually a reviewer will not be looking for this type of issue, but may find some in the course of their review.
  • Please try to avoid raising esoteric questions of English usage. The RFC Editor will spot these, and it is not a wise use of time to discuss these things.
  • If you find no nits, please leave this section out.

Sample Routing Directorate Review

To: rtg-ads@tools.ietf.org
Cc: rtg-dir@ietf.org; draft-ietf-pce-p2mp-reqs.all@tools.ietf.org
Subject: RtgDir review: draft-ietf-pce-p2mp-reqs-03.txt

Hello,

I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.

Document: draft-ietf-pcep-p2mp-reqs-03.txt
Reviewer: Albert N. Other
Review Date: 25 January 2010
IETF LC End Date: 27 January 2010
Intended Status: Informational

Summary:
I have some minor concerns about this document that I think should be resolved before publication.

Comments:
This document is clearly written and easy to understand. The requirements are numbered, which is helpful. I would have prefered to see more figures, but this is a matter of style.
This is the first PCE document I have reviewed, so I went back and read some of the previous RFCs. It may mean that my review is not sufficiently in-depth.

Major Issues:
No major issues found.

Minor Issues:
Section 2.1.10 : requirement R11
I found the term "reoptimization" confusing. It begs the question of whether the objective is to find an optimum path for the LSP or to place the LSP for the optimum use of the network. Indeed, "optimum" may, itself, be open to interpretation.
Can you include some clarification of these terms, possibly by reference to other documents if they have already been defined in the PCE context.

Nits:
Section 2
s/seciton/section/