Shepherd writeup
rfc7956-14

(1) What type of RFC is being requested (BCP, Proposed Standard,
    Internet Standard, Informational, Experimental, or Historic)? Why
    is this the proper type of RFC? Is this type of RFC indicated in
    the title page header?

The target status is Protposed Standard. This document extends the
TRILL Protocol which is a Proposed Standard. The title page header
says "Standards Track".

(2) The IESG approval announcement includes a Document Announcement
    Write-Up. Please provide such a Document Announcement
    Write-Up. The approval announcement contains the following
    sections:

Technical Summary:

TRILL provides optimum routing for layer 2 traffic. A centralized
gateway solution is typically used for layer 3 inter-subnet traffic
forwarding in a TRILL campus but has the following issues:
   1. Sub-optimum forwarding paths for inter-subnet traffic.
   2. A centralized gateway may need to support a very large number of
      gateway interfaces in a data center, one per tenant per data
      label used by that tenant, to provide interconnect functionality
      for all the layer 2 virtual networks in a TRILL campus.
   3. A traffic bottleneck at the gateway.

This document specifies an optional TRILL distributed gateway solution
that resolves these centralized gateway issues.

Working Group Summary:

   There has been good support from the working group to advance this
   work. There have been no changes in the concept or basic
   architecture since it was adopted as a WG draft.

Document Quality:

   This document is of high quality. It has received numerous reviews
   including the RTG DIR QA review here:
   http://www.ietf.org/mail-archive/web/trill/current/msg07133.html
   Implementations are planned by IPinfusion and Huawei.

Personnel:

   Document Shepherd:  Donald Eastlake
   Responsible Area Director:  Alia Atlas
  WG Chairs: Jon Hudson, Sue Hares
 RTG-DIR QA person: Susan Hares 
http://www.ietf.org/mail-archive/web/rtg-dir/current/msg02783.html


(3) Briefly describe the review of this document that was performed by
    the Document Shepherd.

I have carefully review the document previously and did a final check
resulting in the recommendations at
http://www.ietf.org/mail-archive/web/trill/current/msg07085.html. These
have been incorporated into revision -09.

(4) Does the document Shepherd have any concerns about the depth or
    breadth of the reviews that have been performed?

No. As well as the other reviews, Alia Atlas did an early AD review
and her comments were resolved.
  
(5) Do portions of the document need review from a particular or from
    broader perspective, e.g., security, operational complexity, AAA,
    DNS, DHCP, XML, or internationalization?

Final Routing Directorate review needs to be done.

(6) Describe any specific concerns or issues that the Document
    Shepherd has with this document that the Responsible Area Director
    and/or the IESG should be aware of?

No special concerns or issues.

(7) Has each author confirmed that any and all appropriate IPR
    disclosures required for full conformance with the provisions of
    BCP 78 and BCP 79 have already been filed.

Yes.

(8) Has an IPR disclosure been filed that references this document? If
    so, summarize any WG discussion and conclusion regarding the IPR
    disclosures.

Weiquo Hao IPR
https://mailarchive.ietf.org/arch/msg/trill/PvZ_oIJV4qFyCrNCVAf2ibLKgXg

Yizhou Li IPR:
https://mailarchive.ietf.org/arch/msg/trill/XKFEnGyrDNdR9WGLFFREzxMv-Wk

Frank Xialiang
https://mailarchive.ietf.org/arch/msg/trill/9R3AMezrAz1Bb-zf-AdQbKhm0vo

Muhammad Durrani  (mdurrani@cisco.com)
https://mailarchive.ietf.org/arch/msg/trill/FCgebA1Kfe5X2ZhmZs2c5lVMLVc

 P. Sivamurugan
11/14/2016 at 1:07am - I am not aware of any IPR

 Andrew  Qu
11/4/2015 at 1:27am  - I am not aware of any IPR 
No.

(9) How solid is the WG consensus behind this document? Does it
    represent the strong concurrence of a few individuals, with others
    being silent, or does the WG as a whole understand and agree with
    it?

There is broad support for this document.

(10) Has anyone threatened an appeal or otherwise indicated extreme
     discontent?

No.

(11) Identify any ID nits the Document Shepherd has found in this
     document. (See http://www.ietf.org/tools/idnits/ and the
     Internet-Drafts Checklist).

The nits checker incorrectly flags the reference to the ISO/IEC
IS-IS standard as a possible downref and incorrectly flags some ASCII
art that uses pound sign ("#") as possible code.

(12) Describe how the document meets any required formal review
     criteria, such as the MIB Doctor, media type, and URI type
     reviews.

No such review required.

(13) Have all references within this document been identified as
     either normative or informative?

Yes.

(14) Are there normative references to documents that are not ready
     for advancement or are otherwise in an unclear state? If such
     normative references exist, what is the plan for their
     completion?

There is a reference to draft-ietf-trill-rfc7180bis but it has been
approved for publication as a Proposed Standard RFC and is in the RFC
Editor's queue.

(15) Are there downward normative references references (see RFC
     3967)?

There are no actual downward normative references. (The nits checker
warns about the reference to the ISO/IEC IS-IS standard as a possible
downward reference.)

(16) Will publication of this document change the status of any
     existing RFCs.

This document does not change the status of any existing RFC.

(17) Describe the Document Shepherd's review of the IANA
     considerations section, especially with regard to its consistency
     with the body of the document. Confirm that all protocol
     extensions that the document makes are associated with the
     appropriate reservations in IANA registries. Confirm that any
     referenced IANA registries have been clearly identified. Confirm
     that newly created IANA registries include a detailed
     specification of the initial contents for the registry, that
     allocations procedures for future registrations are defined, and
     a reasonable name for the new registry has been suggested (see
     RFC 5226).

The Shepherd has paid close attention to the IANA Considerations
section and that section incorporates earlier Shepherd comments. There
are appropriate code point reservations for all protocol extensions in
this document, the relevanr IANA registries are clearly identified.
This document does not creat any new IANA registries.

(18) List any new IANA registries that require Expert Review for
     future allocations.

This document does not create any new IANA registries.

(19) Describe reviews and automated checks performed by the Document
     Shepherd to validate sections of the document written in a formal
     language, such as XML code, BNF rules, MIB definitions, etc.

No such automated checks are required.
Back