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-KW9H84FgApfcbWegSNA5v94Ihttps://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.