Skip to main content

Shepherd writeup
draft-ietf-trill-pseudonode-nickname

(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?

   This is targeted at Proposed Standard as indicated on the title
   page.  This document specifies protocol behavior of TRILL switches
   to implement active-active services at the TRILL edge using a
   pseudo-nickname to represent an edge group of RBridges.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary:

   Active-active access at the TRILL edge is the extension of flow
   level multi-pathing and rapid fail-over service available in the
   interior of a TRILL campus to end stations that are multiply
   connected to a TRILL campus edge as discussed in RFC 7379. In this
   document, a Virtual RBridge's pseudo-nickname represents the edge
   RBridge group providing active-active access to such an end
   station.

Working Group Summary:

   Early discussion in the TRILL WG favored a pseudo-node nickname
   approach similar to that in this draft. Later analysis resulted in
   the three alternatives described in the Introduction to
   draft-ietf-trill-aa-multi-attach. Two of these, which can be
   deployed simultaneously in a TRILL campus, are being advanced by
   the WG, an evolved version of alternative 1 using a pseudo-nickname
   in this draft and alternative 3 in draft-ietf-trill-aa-multi-
   attach.

   There was good WG support for this draft.
 
Document Quality:

   This document was developed by the WG over a two-year period. The
   document is of good quality and is being implemented.
   
Personnel:

   Document Shepherd: Donald Eastlake, 3rd
   Responsible Area Director: Alia Atlas

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

   The Shepherd has reviewed this document at various stages and
   provided feedback. The most recent and formal Shepherd review is
   here:
   http://www.ietf.org/mail-archive/web/trill/current/msg06637.html 

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

   No.

(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?

   No.

(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.

(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.

   Two IPR disclosures have been filed against this draft.  See
   https://datatracker.ietf.org/ipr/2083/ and
   https://datatracker.ietf.org/ipr/2444/
   These IPR disclosures were not noted in the first WG Last Call on
   this draft and a 2nd WG Last Call was specifically held due to that
   oversight. There were no objections.

(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?

   Many members of the WG have been involved in the development of
   strategies to provide active-active support at the TRILL edge
   [RFC7379]. This draft represents the original direction decided by
   the original active-active design team coordinated by Tissa
   Senevirathne.  Consensus for this draft continues to be reasonably
   broad.

(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.

   There are no actual nits. The nits checker complains about
   non-RFC5735-compliant IPv4 addresses, but these are references to
   level 4 sections in other documents.

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

   No formal 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?

   This document has normative references to draft-ietf-trill-cmt and
   draft-ietf-trill-rfc7180bis both of which have passed WG Last Call.

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

   No, although there is a reference to the ISO/IEC IS-IS standard
   about which the nits checker warns.

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

   No.

(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 IANA Considerations were carefully compared with the rest of
   the text. It requests appropriate assignments from the "TRILL
   APPsub-TLV Types under IS-IS TLV 251 Application Identifier 1"
   Registry. No other registries are used and no new registries
   created. 

(18) List any new IANA registries that require Expert Review for
future allocations. Provide any public guidance that the IESG would
find useful in selecting the IANA Experts for these new registries.

   No IANA registries created.

(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 review required.
Back