Shepherd writeup
draft-ietf-babel-source-specific-05

draft-ietf-babel-source-specific-05

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

Proposed Standard as indicated on the title page. This document
extends the Babel routing protocol so that the routing of a packet can
depend on the source address as well as the destination address.

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

Source-specific routing (also known as Source-Address Dependent
Routing, SADR) is an extension to traditional next-hop routing where
packets are forwarded according to both their destination and their
source address.  This document describes an extension for source-
specific routing to the Babel routing protocol.

  Working Group Summary:

Discussion of the draft during WG Last Call extended to one aspect of
the rfc6126bis draft but WG consensus supported both this draft and
not changing rfc6126bis.

  Document Quality:

The quality of the document is good. There are two known
implementations: babeld in the currently unreleased 1.9 branch and
Toke Høiland-Jørgensen's code in BIRD.

  Personnel:
     Document Shepherd: Donald Eastlake
     Responsible Area Director: Martin Vigoureux

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

Shepherd review is here
https://mailarchive.ietf.org/arch/msg/babel/S4QVnhDZ38bsph2qOvw06qzEfoU
Discussion on the list of the review comments lead to the -05 version.

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

No review concerns. In addition to the Shepherd review and general
review by the Working Group there was an early Routing Directorate
review as shown here:
https://mailarchive.ietf.org/arch/msg/babel/-V3XN6IHqAEVjIyCpztO9PsoCvA

 (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? If so, describe the
     review that took place.

No. There was an early Routing Directorate review (see 4 above).

 (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. If not, explain why?

Yes, see
https://mailarchive.ietf.org/arch/msg/babel/ne-KW9H84FgApfcbWegSNA5v94I
https://mailarchive.ietf.org/arch/msg/babel/vd9Tht3TaVH5DC_D4IwpmZWGi8g

 (8) Has an IPR disclosure been filed that references this document?

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 a reasonable consensus for this document. All commenters
during Last Call supported the document except for one who objected to
the provision in draft-ietf-babel-rfc6126bis that left the version
number at 2 and possible interaction of this with the source specific
draft. This issues was discussed during the Last Call of source
specific and a consensus favored leaving the source-specific and
rfc6126bis drafts as is.

(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). Boilerplate checks are not enough;
     this check needs to be thorough.

Two of the references to drafts reference a version number one less
than the current version number.

(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 criteria apply to this document.

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

There is a normative reference to draft-ietf-babel-rfc-6126bis
publication of which as an RFC has been requested and which is
currently in the AD Review state.

(15) Are there downward normative references references (see RFC
     3967)? If so, list these downward references to support the Area
     Director in the Last Call procedure.

There are no downward references. (There is a reference to a BCP.)

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

This document does not affect 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 only required IANA action is the allocation of a Babel sub-TLV
type number. This action has already occurred and is documented in
this draft.

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

This document does not create any 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 formal language appears in this document.
Back