(1)What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)?
Why? It modifies a proposed standard RFC2439.
Is it proper? RFC2439 specifies an algorithm implemented in BGP for timing of error messages and retransmissions.
Is this type of RFC indicated in the title page header? Yes.
(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:
BGP Route Flap damping seeks to reduce the BGP churn in routers.
First described in operators forms (RIPE, [ripe178]) and RFC2430 it was harsh penalizing sites for being well-connected because topology riches amplified the number of updates. Therefore, many operators turned it off [ripe378]. However, now because new measurements f[plesser2011] indicates a different suppression hold (6000) BGP update rate can be reduced by 19%. Ripe, a European Operator forum, has endorse these new settings [ripe580]. The Japanese operators have reported their use of the new RFD and their desires for implementation [shishio-grow-isp-rfd-implement-survey].
Working Group Summary:
WG Group had consensus over the last call. During the last call, a suggestion for addition features was made. The chairs/WG suggested this would be a follow-on draft rather than an addition to the current draft.
Existing implementation of RFD exist in Juniper and Cisco. Protocol deployments [shishio-grow-isp-rfd-implement-survey] found bugs which have been fixed. The Japanese operator and RIPE operator community have reviewed these documents, and the Japanese operator community given the response in [shishio-grow-isp-rfd-implement-survey].
Since these are changes to existing features with existing configurations, some of the features were tunable via configuration and some not (see table 1 in document).
Since BGP configuration via MIB is not widely deployed, a specific MIB review or information model for this specific draft is not warranted. However, this draft will be added by the chairs to drafts to be examined by NM/OPS groups for BGP configuration.
Personnel: Shepherd: Susan Hares (WG chair), AD: Stewart Bryant
(3) Briefly describe the review of this document that was performed by the Document Shepherd. If this version of the document is not ready for publication, please explain why the document is being forwarded to the IESG.
Reviewed of technical input: Read Draft, Grow draft, referenced documents
(4)Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed?
No. The Shepherd has read all referenced document.
(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.
Yes. It was looked at by 3 major BGP Communities: US, Japan, and Europe.
(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?
This document may be followed up with a configuration drafts regarding this topic, but this is a good thing.
(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?
IPR is unlikely, but authors have been
(8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures.
No IPR disclosure has been filed.
(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? Has anyone threatened an appeal or otherwise indicated extreme discomfort?
The operator community seems to be active although silent on the list. Therefore, the document shepherd suggests the community is agreeable but silent.
No indication of an appeal.
(10) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
This nits have found something. However, it appears the ID-NITS are wrong. Boilerplate checks are not enough; this check needs to be thorough.
(11)Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews.
No MIB, no media talk, URI type reviews.
(12) Have all references within this document been identified as either normative or informative?
Yes – all references are normative or informative.
(13) Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? No.
(14)Are there downward normative references (see RFC 3967)? If so, list these downward references to support the Area Director in the Last Call procedure.
(15) Will publication of this document change the status of any existing RFCs?
yes, it will limits suggested by RFC2439 (Modification)
a. No considerations – The specification only changes implementation knobs.
b. No new registries
(17) No XML or BNF or MB
(18) 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. - not applicable
[Note: Japan/US Time is why draft is 8/22 and write-up is 8/21.]