zilinlin/RFC2PSM huggingface dataset:
Section 2. Acknowledgements

jointly authored by Kirk Lougheed and Yakov Rekhter.
   We would like to express our thanks to Guy Almes, Len Bosack, and
   Jeffrey C. Honig for their contributions to the earlier version
   (BGP-1) of this document.
   We would like to specially acknowledge numerous contributions by
   Dennis Ferguson to the earlier version of this document.
   We would like to explicitly thank Bob Braden for the review of the
   earlier version (BGP-2) of this document, and for his constructive
   and valuable comments.
   We would also like to thank Bob Hinden, Director for Routing of the
   Internet Engineering Steering Group, and the team of reviewers he
   assembled to review the earlier version (BGP-2) of this document.
   This team, consisting of Deborah Estrin, Milo Medin, John Moy, Radia
   Perlman, Martha Steenstrup, Mike St. Johns, and Paul Tsuchiya, acted
   with a strong combination of toughness, professionalism, and
   courtesy.
   Certain sections of the document borrowed heavily from IDRP
   [IS10747], which is the OSI counterpart of BGP.  For this, credit
   should be given to the ANSI X3S3.3 group chaired by Lyman Chapin and
   to Charles Kunzinger, who was the IDRP editor within that group.
   We would also like to thank Benjamin Abarbanel, Enke Chen, Edward
   Crabbe, Mike Craren, Vincent Gillet, Eric Gray, Jeffrey Haas, Dimitry
   Haskin, Stephen Kent, John Krawczyk, David LeRoy, Dan Massey,
   Jonathan Natale, Dan Pei, Mathew Richardson, John Scudder, John
   Stewart III, Dave Thaler, Paul Traina, Russ White, Curtis Villamizar,
   and Alex Zinin for their comments.
   We would like to specially acknowledge Andrew Lange for his help in
   preparing the final version of this document.
   Finally, we would like to thank all the members of the IDR Working
   Group for their ideas and the support they have given to this
   document.
Section 7. BGP Version Negotiation

BGP speakers MAY negotiate the version of the protocol by making
   multiple attempts at opening a BGP connection, starting with the
   highest version number each BGP speaker supports.  If an open attempt
   fails with an Error Code, OPEN Message Error, and an Error Subcode,
   Unsupported Version Number, then the BGP speaker has available the
   version number it tried, the version number its peer tried, the
   version number passed by its peer in the NOTIFICATION message, and
   the version numbers it supports.  If the two peers do support one or
   more common versions, then this will allow them to rapidly determine
   the highest common version.  In order to support BGP version
   negotiation, future versions of BGP MUST retain the format of the
   OPEN and NOTIFICATION messages.
Section 10. BGP Timers

BGP employs five timers: ConnectRetryTimer (see Section 8), HoldTimer
   (see Section 4.2), KeepaliveTimer (see Section 8),
   MinASOriginationIntervalTimer (see Section 9.2.1.2), and
   MinRouteAdvertisementIntervalTimer (see Section 9.2.1.1).
   Two optional timers MAY be supported: DelayOpenTimer, IdleHoldTimer
   by BGP (see Section 8).  Section 8 describes their use.  The full
   operation of these optional timers is outside the scope of this
   document.
   ConnectRetryTime is a mandatory FSM attribute that stores the initial
   value for the ConnectRetryTimer.  The suggested default value for the
   ConnectRetryTime is 120 seconds.
   HoldTime is a mandatory FSM attribute that stores the initial value
   for the HoldTimer.  The suggested default value for the HoldTime is
   90 seconds.
   During some portions of the state machine (see Section 8), the
   HoldTimer is set to a large value.  The suggested default for this
   large value is 4 minutes.
   The KeepaliveTime is a mandatory FSM attribute that stores the
   initial value for the KeepaliveTimer.  The suggested default value
   for the KeepaliveTime is 1/3 of the HoldTime.
   The suggested default value for the MinASOriginationIntervalTimer is
   15 seconds.
   The suggested default value for the
   MinRouteAdvertisementIntervalTimer on EBGP connections is 30 seconds.
   The suggested default value for the
   MinRouteAdvertisementIntervalTimer on IBGP connections is 5 seconds.
   An implementation of BGP MUST allow the HoldTimer to be configurable
   on a per-peer basis, and MAY allow the other timers to be
   configurable.
   To minimize the likelihood that the distribution of BGP messages by a
   given BGP speaker will contain peaks, jitter SHOULD be applied to the
   timers associated with MinASOriginationIntervalTimer, KeepaliveTimer,
   MinRouteAdvertisementIntervalTimer, and ConnectRetryTimer.  A given
   BGP speaker MAY apply the same jitter to each of these quantities,
   regardless of the destinations to which the updates are being sent;
   that is, jitter need not be configured on a per-peer basis.
   The suggested default amount of jitter SHALL be determined by
   multiplying the base value of the appropriate timer by a random
   factor, which is uniformly distributed in the range from 0.75 to 1.0.
   A new random value SHOULD be picked each time the timer is set.  The
   range of the jitter's random value MAY be configurable.
Section Appendix A. Comparison with RFC 1771

There are numerous editorial changes in comparison to [RFC1771] (too
   many to list here).
   The following list the technical changes:
      Changes to reflect the usage of features such as TCP MD5
      [RFC2385], BGP Route Reflectors [RFC2796], BGP Confederations
      [RFC3065], and BGP Route Refresh [RFC2918].
      Clarification of the use of the BGP Identifier in the AGGREGATOR
      attribute.
      Procedures for imposing an upper bound on the number of prefixes
      that a BGP speaker would accept from a peer.
      The ability of a BGP speaker to include more than one instance of
      its own AS in the AS_PATH attribute for the purpose of inter-AS
      traffic engineering.
      Clarification of the various types of NEXT_HOPs.
      Clarification of the use of the ATOMIC_AGGREGATE attribute.
      The relationship between the immediate next hop, and the next hop
      as specified in the NEXT_HOP path attribute.
      Clarification of the tie-breaking procedures.
      Clarification of the frequency of route advertisements.
      Optional Parameter Type 1 (Authentication Information) has been
      deprecated.
      UPDATE Message Error subcode 7 (AS Routing Loop) has been
      deprecated.
      OPEN Message Error subcode 5 (Authentication Failure) has been
      deprecated.
      Use of the Marker field for authentication has been deprecated.
      Implementations MUST support TCP MD5 [RFC2385] for authentication.
      Clarification of BGP FSM.
Section Appendix B. Comparison with RFC 1267

All the changes listed in Appendix A, plus the following.
   BGP-4 is capable of operating in an environment where a set of
   reachable destinations may be expressed via a single IP prefix.  The
   concept of network classes, or subnetting, is foreign to BGP-4.  To
   accommodate these capabilities, BGP-4 changes the semantics and
   encoding associated with the AS_PATH attribute.  New text has been
   added to define semantics associated with IP prefixes.  These
   abilities allow BGP-4 to support the proposed supernetting scheme
   [RFC1518, RFC1519].
   To simplify configuration, this version introduces a new attribute,
   LOCAL_PREF, that facilitates route selection procedures.
   The INTER_AS_METRIC attribute has been renamed MULTI_EXIT_DISC.
   A new attribute, ATOMIC_AGGREGATE, has been introduced to insure that
   certain aggregates are not de-aggregated.  Another new attribute,
   AGGREGATOR, can be added to aggregate routes to advertise which AS
   and which BGP speaker within that AS caused the aggregation.
   To ensure that Hold Timers are symmetric, the Hold Timer is now
   negotiated on a per-connection basis.  Hold Timers of zero are now
   supported.
Section Appendix C. Comparison with RFC 1163

All of the changes listed in Appendices A and B, plus the following.
   To detect and recover from BGP connection collision, a new field (BGP
   Identifier) has been added to the OPEN message.  New text (Section
   6.8) has been added to specify the procedure for detecting and
   recovering from collision.
   The new document no longer restricts the router that is passed in the
   NEXT_HOP path attribute to be part of the same Autonomous System as
   the BGP Speaker.
   The new document optimizes and simplifies the exchange of information
   about previously reachable routes.
Section Appendix D. Comparison with RFC 1105

All of the changes listed in Appendices A, B, and C, plus the
   following.
   Minor changes to the [RFC1105] Finite State Machine were necessary to
   accommodate the TCP user interface provided by BSD version 4.3.
   The notion of Up/Down/Horizontal relations presented in RFC 1105 has
   been removed from the protocol.
   The changes in the message format from RFC 1105 are as follows:
      1. The Hold Time field has been removed from the BGP header and
         added to the OPEN message.
      2. The version field has been removed from the BGP header and
         added to the OPEN message.
      3. The Link Type field has been removed from the OPEN message.
      4. The OPEN CONFIRM message has been eliminated and replaced with
         implicit confirmation, provided by the KEEPALIVE message.
      5. The format of the UPDATE message has been changed
         significantly.  New fields were added to the UPDATE message to
         support multiple path attributes.
      6. The Marker field has been expanded and its role broadened to
         support authentication.
   Note that quite often BGP, as specified in RFC 1105, is referred to
   specified in this document is referred to as BGP-4.
Section Appendix E. TCP Options that May Be Used with BGP

If a local system TCP user interface supports the TCP PUSH function,
   then each BGP message SHOULD be transmitted with PUSH flag set.
   Setting PUSH flag forces BGP messages to be transmitted to the
   receiver promptly.
   If a local system TCP user interface supports setting the DSCP field
   [RFC2474] for TCP connections, then the TCP connection used by BGP
   SHOULD be opened with bits 0-2 of the DSCP field set to 110 (binary).
   An implementation MUST support the TCP MD5 option [RFC2385].