: # Document Shepherd Write-Up for Group Documents
:
: ## Document History
:
: 1. Does the working group (WG) consensus represent the strong concurrence of a
: few individuals, with others being silent, or did it reach a broad
agreement?
This draft received significant commentary over its lifetime from original
submission to Working Group last call.
Since this draft is of significant interest to the Internet operator community,
it received significant scrutiny and support from participants that do not
traditionally comment on IDR drafts. This commentary was not exclusively to
register support for the adoption or last call of the draft, but also had
several participants who do not regularly do work in IDR offer technical
commentary and review.
Participation by list membership that is more generally active was also quite
reasonable.
Adoption thread, February 2023:
https://mailarchive.ietf.org/arch/msg/idr/4yZZF5DN-iTnJ-3XEIJ8TnBDsfQ/
- Supportive: Gert Doering, Job Snijders (author), Mikael Abrahamsson, Ben Cox
(author), Ben Maddison, Jared Mauch, Claudio Jeker, Jeff Tantsura, Gyan Mishra,
- Concerns: Tom Petch, Randy Bush (?) - Not supportive: Robert Raszuk
The draft had several presentations including IETF 116, Interim April 2023,
Interim 1/29/2024.
Working Group last call was requested in December 2023.
Working Group last call started March 22, 2024
https://mailarchive.ietf.org/arch/msg/idr/ikZPV6Jg-DdhDsDaD6BqwTqZ1kA/
extended:
https://mailarchive.ietf.org/arch/msg/idr/0cTJUYZpwAIdWJpBnEkyMPYgmsU/
Support for Working Group last call on version -03:
Support: Claudio Jeker, Mikael Abrahamsson, Maria Matejka, Donatas Abraitis,
Tom Strickx, Acee Lindem, Gert Doering, Marco Marzetti, William McCall,
Ben Maddison, Joel Jaeggli, Rob Shakir, Gyan Mishra, Heasley, Martin Pels,
Paolo Lucente,
Does not support: Robert Raszuk,
Concerns: Tom Petch on FSM. Text was added, but doesn't match existing rfc
4271 styling.
: 2. Was there controversy about particular points, or were there decisions
where : the consensus was particularly rough?
During Working Group adoption, concerns were raised whether this draft
sufficiently addressed the issue at hand. A separate proposal,
draft-chen-idr-tcp-user-timeout, was raised to address the problem space. That
draft was eventually polled separately for adoption and did not have sufficient
support to adopt. At a later point, the authors of tcp-user-timeout asked
whether their work could be merged into the sendholdtimer work, but the
consensus was that it would not be merged.
A number of discussion points were raised and reached rough consensus:
- The draft makes changes vs. the BGP finite state machine. The complexity of
its potential impact was raised early on by Tom Petch (March 2023) and again
during Working Group last call. While some text had been added to address the
FSM issues, the form of the text diverges from the style in RFC 4271, Section
8. The consensus was that while this was indeed a style variance, the text
addressed the concerns about the FSM functionality for the feature.
- A smaller FSM issue was that the feature was originally specified as status:
mandatory in the FSM text. The discussion among the IDR chairs is that BGP
extension RFCs should not make new FSM variables or events "mandatory". A key
criterion for mandatory or not is whether the protocol change would have
non-backward compatible impacts on an otherwise compliant implementation.
This discussion point will likely come up again as IDR considers moving RFC
4271 to Full Standard.
The authors agreed to make the status optional, although with some hesitance
as they see this as fixing a defect in the original BGP FSM.
- A specific sub-thread discussed whether this feature should not be used when
the negotiated BGP HoldTime is zero. The consensus was that it was not in the
spirit of zero HoldTime for this feature to be used.
- A final point is when is the sendholdtimer reset. As sepcified, it's when a
BGP message is sent. However, implementors have responded that this is not
necessarily on a BGP message boundary, but on success of a send() operation in
the TCP stack. Consensus was that since the termination of the BGP session
using this feature is, effecitvely, a local matter, implementations have some
freedom as to when to count a message as sent or not.
https://mailarchive.ietf.org/arch/msg/idr/d4FD9mEgBRYHLaYng7Rxeot1GdM/
- Some late discussion regarding whether the feature can operate in "warning
only" mode rather than resetting the BGP connect didn't elicit
enough support to make this change. It is the shepherd's opinion that
such a deviation from the normative behaviors is an implementation choice
that can be supported by configuration, but doesn't have the support
of the Working Group to make a normative operational consideration.
- Discussions about maintenance procedures for the BGP FSM have started
several background activities discussing how this should be done.
For purposes of this draft, the Chairs have concluded that the appended
action for resetting the new SendHoldTimer on transitions out of the
Established state are adequately covered by the existing "release all
BGP resources" action in the state machine.
: 3. Has anyone threatened an appeal or otherwise indicated extreme discontent?
If : so, please summarize the areas of conflict in separate email messages
to the : responsible Area Director. (It should be in a separate email
because this : questionnaire is publicly available.)
No.
: 4. For protocol documents, are there existing implementations of the contents
of : the document? Have a significant number of potential implementers
indicated : plans to implement? Are any existing implementations reported
somewhere, : either in the document itself (as [RFC 7942][3] recommends) or
elsewhere : (where)?
Implementation report:
https://wiki.ietf.org/en/group/idr/implementations/draft-ietf-idr-sendholdtimer
: 5. Do the contents of this document closely interact with technologies in
other : IETF working groups or external organizations, and would it
therefore benefit : from their review? Have those reviews occurred? If yes,
describe which : reviews took place.
No.
: 6. Describe how the document meets any required formal expert review criteria,
: such as the MIB Doctor, YANG Doctor, media type, and URI type reviews.
N/A
: 7. If the document contains a YANG module, has the final version of the module
: been checked with any of the [recommended validation tools][4] for syntax
and : formatting validation? If there are any resulting errors or warnings,
what is : the justification for not fixing them at this time? Does the YANG
module : comply with the Network Management Datastore Architecture (NMDA) as
specified : in [RFC 8342][5]?
This feature, along with many recent smaller IDR features, does not yet have
presence in the IETF BGP YANG model. That model has yet to reach RFC status.
Two possibilities for addition seem reasonable:
- Add the necessary configuration and operational state to the IETF BGP YANG
model prior to publication.
- Publish an augmentation model to add that state to the base model at a later
date.
It is this chair's opinion that requiring the model to be added to the existing
draft is problematic since it'd create a dependency that would block
publication.
: 8. Describe reviews and automated checks performed to validate sections of the
: final version of the document written in a formal language, such as XML
code, : BNF rules, MIB definitions, CBOR's CDDL, etc.
N/A
: 9. Based on the shepherd's review of the document, is it their opinion that
this : document is needed, clearly written, complete, correctly designed,
and ready : to be handed off to the responsible Area Director?
It is.
: 10. Several IETF Areas have assembled [lists of common issues that their
: reviewers encounter][6]. For which areas have such issues been identified
: and addressed? For which does this still need to happen in subsequent
: reviews?
It is the shepherd's opinion that no additional directorate review is required.
The issue being addressed by the document is a well understood issue that would
normally be studied by the Transport area as a TCP issue. Since this draft does
not recommend use of additional TCP mechanisms and, instead, relies on user-land
TCP behaviors covered by POSIX, additional review has not been requested.
: 11. What type of RFC publication is being requested on the IETF stream ([Best
: Current Practice][12], [Proposed Standard, Internet Standard][13],
: [Informational, Experimental or Historic][14])? Why is this the proper
type : of RFC? Do all Datatracker state attributes correctly reflect this
intent?
Proposed Standard.
: 12. Have reasonable efforts been made to remind all authors of the
intellectual : property rights (IPR) disclosure obligations described in
[BCP 79][7]? To : the best of your knowledge, have all required disclosures
been filed? If : not, explain why. If yes, summarize any relevant
discussion, including links : to publicly-available messages when
applicable.
Job Snijders:
https://mailarchive.ietf.org/arch/msg/idr/5ABCU1s_kuagV0N-pTSWWZMjomg/https://mailarchive.ietf.org/arch/msg/idr/yYJGU1qgbGXdlSxtCWIF0nw5aLs/
Ben Cox
https://mailarchive.ietf.org/arch/msg/idr/BYLhYrNWgnJVoNaTycV0-B324C4/https://mailarchive.ietf.org/arch/msg/idr/64PqB92HkMOM4N7P5o6gFby2Xas/
Yingzhen Qu:
https://mailarchive.ietf.org/arch/msg/idr/FDcyZos3rG9MJEehCpOcRQoioDE/
: 13. Has each author, editor, and contributor shown their willingness to be
: listed as such? If the total number of authors and editors on the front
page : is greater than five, please provide a justification.
They are willing to be listed as an author.
: 14. Document any remaining I-D nits in this document. Simply running the
[idnits : tool][8] is not enough; please review the ["Content Guidelines"
on : authors.ietf.org][15]. (Also note that the current idnits tool
generates : some incorrect warnings; a rewrite is underway.)
No relevant nits.
: 15. Should any informative references be normative or vice-versa? See the
[IESG : Statement on Normative and Informative References][16].
The informative references supporting the appendix A internet-draft
implementation section should be removed before publication.
: 16. List any normative references that are not freely available to anyone. Did
: the community have sufficient access to review any such normative
: references?
N/A
: 17. Are there any normative downward references (see [RFC 3967][9] and [BCP
: 97][10]) that are not already listed in the [DOWNREF registry][17]? If so,
: list them.
N/A
: 18. Are there normative references to documents that are not ready to be
: submitted to the IESG for publication or are otherwise in an unclear
state? : If so, what is the plan for their completion?
N/A
: 19. Will publication of this document change the status of any existing RFCs?
If : so, does the Datatracker metadata correctly reflect this and are those
RFCs : listed on the title page, in the abstract, and discussed in the :
introduction? If not, explain why and point to the part of the document :
where the relationship of this document to these other RFCs is discussed.
N/A
: 20. 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 aspects of the document requiring IANA
assignments are : associated with the appropriate reservations in IANA
registries. Confirm : that any referenced IANA registries have been clearly
identified. Confirm : that each newly created IANA registry specifies its
initial contents, : allocations procedures, and a reasonable name (see [RFC
8126][11]).
The definition of the new error code has been completed. As noted in
RFC 4271, section 6.5, an error subcode of unspecific (0) is appropriate
when there are no more specific subcodes. This feature has symmetry to
the holdtimer feature which doesn't require anything more specific.
IDR currently doesn't have a setup a process for maintaining the
enumerated FSM code points. draft-hhp-idr-bgp-fsm-iana has been
proposed to create a registry for this coordination.
It is the intent of the IDR Chairs to assign FSM elements from that
draft until the creation of its IANA registry.
: 21. List any new IANA registries that require Designated Expert Review for
: future allocations. Are the instructions to the Designated Expert clear?
: Please include suggestions of designated experts, if appropriate.
N/A