Subject: Issues list, #2: MUST/SHOULD Capitalization

From: Jeffrey Haas <[email-masked]>
Date: Mon, 6 Jan 2003 14:28:15 -0500

> Status: Consensus
> Change: Yes
> Summary: Capitalize MUST/SHOULD where appropate.
> 
> Discussion:
> 
> Jeff brought this up, and Yakov reponded asking that he point out 
> specific instances where this is needed.  Jeff said he would do so,
> given some time.
> 
> Yakov later replied that this would be fixed in the -19 version.

Attached, please find a universal diff containing my recommended changes.
Note that not all instances of our magic words are capitalized, it
is not always appropriate.  As such, I may have failed to capitalize
where it is needed and may have also done so where it is inappropriate.
These changes should go through at least one other thorough reviewer.

Note that as part of these diffs, I found two cases that looked like
a wording change was worth suggesting.  

To explicitly point it out:
    If the NEXT_HOP attribute of a BGP route depicts an address that is
    not resolvable, or it would become unresolvable if the route was
-   installed in the routing table the BGP route should be excluded from
+   installed in the routing table the BGP route MUST be excluded from
    the Phase 2 decision function.

...and...

    the NEXT_HOP attribute of the selected route (see section 5.1.3). If
    either the immediate next hop or the IGP cost to the NEXT_HOP (where
    the NEXT_HOP is resolved through an IGP route) changes, Phase 2:
-   Route Selection should be performed again.
+   Route Selection MUST be performed again.

Other than these, everything else is a capitalization 

--- html/ID.local/draft-ietf-idr-bgp4-18.txt	Mon Nov  4 15:59:08 2002
+++ draft-ietf-idr-bgp4-18.txt	Mon Jan  6 12:46:39 2003
@@ -454,7 +454,7 @@
    BGP uses TCP [RFC793] as its transport protocol. This eliminates the
    need to implement explicit update fragmentation, retransmission,
    acknowledgment, and sequencing. BGP listens on TCP port 179. Any
-   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
+   authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) MAY be
    used. The error notification mechanism used in BGP assumes that TCP
    supports a "graceful" close, i.e., that all outstanding data will be
    delivered before the connection is closed.
@@ -542,7 +542,7 @@
 RFC DRAFT                                                   October 2002

-   If a BGP speaker chooses to advertise the route, it may add to or
+   If a BGP speaker chooses to advertise the route, it MAY add to or
    modify the path attributes of the route before advertising it to a
    peer.
 
@@ -581,7 +581,7 @@
       that the BGP speaker has selected by applying its local policies
       to the routing information contained in its Adj-RIBs-In. These are
       the routes that will be used by the local BGP speaker. The next
-      hop for each of these routes must be resolvable via the local BGP
+      hop for each of these routes MUST be resolvable via the local BGP
       speaker's Routing Table.
 
       c) Adj-RIBs-Out: The Adj-RIBs-Out store the information that the
@@ -687,7 +687,7 @@
          This 2-octet unsigned integer indicates the total length of the
          message, including the header, in octets. Thus, e.g., it allows
          one to locate in the TCP stream the (Marker field of the) next
-         message. The value of the Length field must always be at least
+         message. The value of the Length field MUST always be at least
          19 and no greater than 4096, and may be further constrained,
          depending on the message type. No "padding" of extra data after
          the message is allowed, so the Length field must have the
@@ -765,7 +765,7 @@
          value of the Hold Timer by using the smaller of its configured
          Hold Time and the Hold Time received in the OPEN message. The
          Hold Time MUST be either zero or at least three seconds.  An
-         implementation may reject connections on the basis of the Hold
+         implementation MAY reject connections on the basis of the Hold
          Time.  The calculated value indicates the maximum number of
          seconds that may elapse between the receipt of successive
          KEEPALIVE, and/or UPDATE messages by the sender.
@@ -798,7 +798,7 @@
 
       Optional Parameters:
 
-         This field may contain a list of optional parameters, where
+         This field MAY contain a list of optional parameters, where
          each parameter is encoded as a <Parameter Type, Parameter
          Length, Parameter Value> triplet.
 
@@ -866,7 +866,7 @@
       Withdrawn Routes Length:
 
          This 2-octets unsigned integer indicates the total length of
-         the Withdrawn Routes field in octets.  Its value must allow the
+         the Withdrawn Routes field in octets.  Its value MUST allow the
          length of the Network Layer Reachability Information field to
          be determined as specified below.
 
@@ -919,7 +919,7 @@
       Total Path Attribute Length:
 
          This 2-octet unsigned integer indicates the total length of the
-         Path Attributes field in octets. Its value must allow the
+         Path Attributes field in octets. Its value MUST allow the
          length of the Network Layer Reachability field to be determined
          as specified below.
 
@@ -963,14 +963,14 @@

          is transitive (if set to 1) or non-transitive (if set to 0).
-         For well-known attributes, the Transitive bit must be set to 1.
+         For well-known attributes, the Transitive bit MUST be set to 1.
          (See Section 5 for a discussion of transitive attributes.)
 
          The third high-order bit (bit 2) of the Attribute Flags octet
          is the Partial bit. It defines whether the information con-
          tained in the optional transitive attribute is partial (if set
          to 1) or complete (if set to 0). For well-known attributes and
-         for optional non-transitive attributes the Partial bit must be
+         for optional non-transitive attributes the Partial bit MUST be
          set to 0.
 
          The fourth high-order bit (bit 3) of the Attribute Flags octet
@@ -978,7 +978,7 @@
          Length is one octet (if set to 0) or two octets (if set to 1).
 
          The lower-order four bits of the Attribute Flags octet are
-         unused. They must be zero when sent and must be ignored when
+         unused. They MUST be zero when sent and MUST be ignored when
          received.
 
          The Attribute Type Code octet contains the Attribute Type Code.
@@ -1069,7 +1069,7 @@
          d) MULTI_EXIT_DISC (Type Code 4):
 
             This is an optional non-transitive attribute that is a four
-            octet non-negative integer. The value of this attribute may
+            octet non-negative integer. The value of this attribute MAY

@@ -1110,7 +1110,7 @@
             The attribute contains the last AS number that formed the
             aggregate route (encoded as 2 octets), followed by the IP
             address of the BGP speaker that formed the aggregate route
-            (encoded as 4 octets).  This should be the same address as
+            (encoded as 4 octets).  This SHOULD be the same address as
             the one used for the BGP Identifier of the speaker.
 
             Usage of this attribute is defined in 5.1.7.
@@ -1205,10 +1205,10 @@
    feasible route, in which case the WITHDRAWN ROUTES field need not be
    present.
 
-   An UPDATE message should not include the same address prefix in the
+   An UPDATE message SHOULD NOT include the same address prefix in the
    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
    however a BGP speaker MUST be able to process UPDATE messages in this
-   form. A BGP speaker should treat an UPDATE message of this form as if
+   form. A BGP speaker SHOULD treat an UPDATE message of this form as if
    the WITHDRAWN ROUTES doesn't contain the address prefix.

@@ -1356,12 +1356,12 @@
                3. Optional transitive.
                4. Optional non-transitive.
 
-   Well-known attributes must be recognized by all BGP implementations.
-   Some of these attributes are mandatory and must be included in every
+   Well-known attributes MUST be recognized by all BGP implementations.
+   Some of these attributes are mandatory and MUST be included in every
    UPDATE message that contains NLRI. Others are discretionary and may
    or may not be sent in a particular UPDATE message.
 
-   All well-known attributes must be passed along (after proper updat-
+   All well-known attributes MUST be passed along (after proper updat-
    ing, if necessary) to other BGP peers.
 
    In addition to well-known attributes, each path may contain one or
@@ -1369,7 +1369,7 @@
    implementations support all optional attributes. The handling of an
    unrecognized optional attribute is determined by the setting of the
    Transitive bit in the attribute flags octet. Paths with unrecognized
-   transitive optional attributes should be accepted. If a path with
+   transitive optional attributes SHOULD be accepted. If a path with

@@ -1384,16 +1384,16 @@
 
    unrecognized transitive optional attribute is accepted and passed
    along to other BGP peers, then the unrecognized transitive optional
-   attribute of that path must be passed along with the path to other
+   attribute of that path MUST be passed along with the path to other
    BGP peers with the Partial bit in the Attribute Flags octet set to 1.
    If a path with recognized transitive optional attribute is accepted
    and passed along to other BGP peers and the Partial bit in the
    Attribute Flags octet is set to 1 by some previous AS, it is not set
    back to 0 by the current AS. Unrecognized non-transitive optional
-   attributes must be quietly ignored and not passed along to other BGP
+   attributes MUST be quietly ignored and not passed along to other BGP
    peers.
 
-   New transitive optional attributes may be attached to the path by the
+   New transitive optional attributes MAY be attached to the path by the
    originator or by any other BGP speaker in the path. If they are not
    attached by the originator, the Partial bit in the Attribute Flags
    octet is set to 1. The rules for attaching new non-transitive
@@ -1401,12 +1401,12 @@
    attribute. The documentation of each new non-transitive optional
    attribute will be expected to include such rules. (The description of
    the MULTI_EXIT_DISC attribute gives an example.) All optional
-   attributes (both transitive and non-transitive) may be updated (if
+   attributes (both transitive and non-transitive) MAY be updated (if
    appropriate) by BGP speakers in the path.
 
-   The sender of an UPDATE message should order path attributes within
+   The sender of an UPDATE message SHOULD order path attributes within
    the UPDATE message in ascending order of attribute type. The receiver
-   of an UPDATE message must be prepared to handle path attributes
+   of an UPDATE message MUST be prepared to handle path attributes
    within the UPDATE message that are out of order.
 
    The same attribute can not appear more than once within the Path
@@ -1454,7 +1454,7 @@

    ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
-   shall be generated by the speaker that originates the associated
+   SHALL be generated by the speaker that originates the associated
    routing information. Its value SHOULD NOT be changed by any other
    speaker.
 
@@ -1468,20 +1468,20 @@
    AS_SETs or AS_SEQUENCEs.
 
    When a BGP speaker propagates a route which it has learned from
-   another BGP speaker's UPDATE message, it shall modify the route's
+   another BGP speaker's UPDATE message, it SHALL modify the route's
    AS_PATH attribute based on the location of the BGP speaker to which
    the route will be sent:
 
       a) When a given BGP speaker advertises the route to an internal
-      peer, the advertising speaker shall not modify the AS_PATH
+      peer, the advertising speaker SHALL NOT modify the AS_PATH
       attribute associated with the route.
 
       b) When a given BGP speaker advertises the route to an external
-      peer, then the advertising speaker shall update the AS_PATH
+      peer, then the advertising speaker SHALL update the AS_PATH
       attribute as follows:
 
          1) if the first path segment of the AS_PATH is of type
-         AS_SEQUENCE, the local system shall prepend its own AS number
+         AS_SEQUENCE, the local system SHALL prepend its own AS number
          as the last element of the sequence (put it in the leftmost
          position). If the act of prepending will cause an overflow in
          the AS_PATH segment, i.e. more than 255 ASs, it shall be legal
@@ -1489,7 +1489,7 @@
          own AS number to this new segment.
 
          2) if the first path segment of the AS_PATH is of type AS_SET,
-         the local system shall prepend a new path segment of type
+         the local system SHALL prepend a new path segment of type

@@ -1507,21 +1507,21 @@
 
    When a BGP speaker originates a route then:
 
-      a) the originating speaker shall include its own AS number in a
+      a) the originating speaker SHALL include its own AS number in a
       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
       UPDATE messages sent to an external peer. (In this case, the AS
       number of the originating speaker's autonomous system will be the
       only entry the path segment, and this path segment will be the
       only segment in the AS_PATH attribute).
 
-      b) the originating speaker shall include an empty AS_PATH
+      b) the originating speaker SHALL include an empty AS_PATH
       attribute in all UPDATE messages sent to internal peers.  (An
       empty AS_PATH attribute is one whose length field contains the
       value zero).
 
    Whenever the modification of the AS_PATH attribute calls for includ-
    ing or prepending the AS number of the local system, the local system
-   may include/prepend more than one instance of its own AS number in
+   MAY include/prepend more than one instance of its own AS number in
    the AS_PATH attribute. This is controlled via local configuration.

@@ -1534,16 +1534,16 @@
    is calculated as follows.
 
       1) When sending a message to an internal peer, if the route is not
-      locally originated the BGP speaker should not modify the NEXT_HOP
+      locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP
       attribute, unless it has been explicitly configured to announce
       its own IP address as the NEXT_HOP. When announcing a locally
-      originated route to an internal peer, the BGP speaker should use
+      originated route to an internal peer, the BGP speaker SHOULD use
       as the NEXT_HOP the interface address of the router through which
       the announced network is reachable for the speaker; if the route
       is directly connected to the speaker, or the interface address of
       the router through which the announced network is reachable for
       the speaker is the internal peer's address, then the BGP speaker
-      should use for the NEXT_HOP attribute its own IP address (the
+      SHOULD use for the NEXT_HOP attribute its own IP address (the
       address of the interface that is used to reach the peer).
 
       2) When sending a message to an external peer X, and the peer is
@@ -1579,12 +1579,12 @@
 
          - Otherwise, if the external peer to which the route is being
          advertised shares a common subnet with one of the announcing
-         router's own interfaces, the router may use the IP address
+         router's own interfaces, the router MAY use the IP address
          associated with such an interface in the NEXT_HOP attribute.
          This is known as a "first party" NEXT_HOP attribute.
 
          - By default (if none of the above conditions apply), the BGP
-         speaker should use in the NEXT_HOP attribute the IP address of
+         speaker SHOULD use in the NEXT_HOP attribute the IP address of
          the interface that the speaker uses to establish the BGP con-
          nection to peer X.
 
@@ -1598,18 +1598,18 @@
          attribute of the learned route (the speaker just doesn't modify
          the NEXT_HOP attribute).
 
-         - By default, the BGP speaker should use in the NEXT_HOP
+         - By default, the BGP speaker SHOULD use in the NEXT_HOP
          attribute the IP address of the interface that the speaker uses
          to establish the BGP connection to peer X.
 
    Normally the NEXT_HOP attribute is chosen such that the shortest
-   available path will be taken. A BGP speaker must be able to support
+   available path will be taken. A BGP speaker MUST be able to support
    disabling advertisement of third party NEXT_HOP attributes to handle
    imperfectly bridged media.
 
-   A BGP speaker must never advertise an address of a peer to that peer
+   A BGP speaker MUST NEVER advertise an address of a peer to that peer
    as a NEXT_HOP, for a route that the speaker is originating. A BGP
-   speaker must never install a route with itself as the next hop.
+   speaker MUST NEVER install a route with itself as the next hop.

@@ -1633,9 +1633,9 @@
    entry which resolves the IP address in the NEXT_HOP attribute will
    always specify the outbound interface. If the entry specifies an
    attached subnet, but does not specify a next-hop address, then the
-   address in the NEXT_HOP attribute should be used as the immediate
+   address in the NEXT_HOP attribute SHOULD be used as the immediate
    next-hop address.  If the entry also specifies the next-hop address,
-   this address should be used as the immediate next-hop address for
+   this address SHOULD be used as the immediate next-hop address for
    packet forwarding.

@@ -1687,7 +1687,7 @@
    each external route based on the locally configured policy, and
    include the degree of preference when advertising a route to its
    internal peers. The higher degree of preference MUST be preferred.  A
-   BGP speaker shall use the degree of preference learned via LOCAL_PREF
+   BGP speaker SHALL use the degree of preference learned via LOCAL_PREF
    in its decision process (see section 9.1.1).
 
    A BGP speaker MUST NOT include this attribute in UPDATE messages that
@@ -1745,11 +1745,11 @@
 5.1.7 AGGREGATOR

-   AGGREGATOR is an optional transitive attribute which may be included
+   AGGREGATOR is an optional transitive attribute which MAY be included
    in updates which are formed by aggregation (see Section 9.2.2.2). A
-   BGP speaker which performs route aggregation may add the AGGREGATOR
+   BGP speaker which performs route aggregation MAY add the AGGREGATOR
    attribute which shall contain its own AS number and IP address. The
-   IP address should be the same as the BGP Identifier of the speaker.
+   IP address SHOULD be the same as the BGP Identifier of the speaker.

 6. BGP Error Handling.
@@ -1763,7 +1763,7 @@
    fields is sent, and the BGP connection is closed, unless it is
    explicitly stated that no NOTIFICATION message is to be sent and the
    BGP connection is not to be closed. If no Error Subcode is specified,
-   then a zero must be used.
+   then a zero MUST be used.
 
    The phrase "the BGP connection is closed" means that the TCP connec-
    tion has been closed, the associated Adj-RIB-In has been cleared, and
@@ -1928,17 +1928,17 @@
    The IP address in the NEXT_HOP must meet the following criteria to be
    considered semantically correct:
 
-      a) It must not be the IP address of the receiving speaker
+      a) It MUST NOT be the IP address of the receiving speaker
 
       b) In the case of an EBGP where the sender and receiver are one IP
       hop away from each other, either the IP address in the NEXT_HOP
-      must be the sender's IP address (that is used to establish the BGP
+      MUST be the sender's IP address (that is used to establish the BGP
       connection), or the interface associated with the NEXT_HOP IP
-      address must share a common subnet with the receiving BGP speaker.
+      address MUST share a common subnet with the receiving BGP speaker.
 
-   If the NEXT_HOP attribute is semantically incorrect, the error should
-   be logged, and the route should be ignored. In this case, no NOTIFI-
-   CATION message should be sent, and connection should not be closed.
+   If the NEXT_HOP attribute is semantically incorrect, the error SHOULD
+   be logged, and the route SHOULD be ignored. In this case, no NOTIFI-
+   CATION message should be sent, and connection SHOULD NOT be closed.
 
    The AS_PATH attribute is checked for syntactic correctness. If the
    path is syntactically incorrect, then the Error Subcode is set to
@@ -1963,11 +1963,11 @@
    is set to Invalid Network Field.
 
    If a prefix in the NLRI field is semantically incorrect (e.g., an
-   unexpected multicast IP address), an error should be logged locally,
-   and the prefix should be ignored.
+   unexpected multicast IP address), an error SHOULD be logged locally,
+   and the prefix SHOULD be ignored.
 
    An UPDATE message that contains correct path attributes, but no NLRI,
-   shall be treated as a valid UPDATE message.
+   SHALL be treated as a valid UPDATE message.

@@ -2000,7 +2000,7 @@
    If a system does not receive successive KEEPALIVE and/or UPDATE
    and/or NOTIFICATION messages within the period specified in the Hold
    Time field of the OPEN message, then the NOTIFICATION message with
-   Hold Timer Expired Error Code must be sent and the BGP connection
+   Hold Timer Expired Error Code MUST be sent and the BGP connection
    closed.

@@ -2016,15 +2016,15 @@

    In absence of any fatal errors (that are indicated in this section),
-   a BGP peer may choose at any given time to close its BGP connection
+   a BGP peer MAY choose at any given time to close its BGP connection
    by sending the NOTIFICATION message with Error Code Cease. However,
-   the Cease NOTIFICATION message must not be used when a fatal error
+   the Cease NOTIFICATION message MUST NOT be used when a fatal error
    indicated by this section does exist.
 
-   A BGP speaker may support the ability to impose an (locally config-
+   A BGP speaker MAY support the ability to impose an (locally config-
    ured) upper bound on the number of address prefixes the speaker is
    willing to accept from a neighbor. When the upper bound is reached,
-   the speaker (under control of local configuration) may either (a)
+   the speaker (under control of local configuration) MAY either (a)
    discard new address prefixes from the neighbor (while maintaining BGP
    connection with the neighbor), or (b) terminate the BGP connection
    with the neighbor. If the BGP speaker decides to terminate its BGP
@@ -2042,7 +2042,7 @@
 RFC DRAFT                                                   October 2002

-   bound, then the speaker must send to the neighbor a NOTIFICATION mes-
+   bound, then the speaker MUST send to the neighbor a NOTIFICATION mes-
    sage with the Error Code Cease.

@@ -2065,8 +2065,8 @@
    the peers involved in the collision and to retain only the connection
    initiated by the BGP speaker with the higher-valued BGP Identifier.
 
-   Upon receipt of an OPEN message, the local system must examine all of
-   its connections that are in the OpenConfirm state. A BGP speaker may
+   Upon receipt of an OPEN message, the local system MUST examine all of
+   its connections that are in the OpenConfirm state. A BGP speaker MAY
    also examine connections in an OpenSent state if it knows the BGP
    Identifier of the peer by means outside of the protocol. If among
    these connections there is a connection to a remote BGP speaker whose
@@ -2127,7 +2127,7 @@
    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.
+   of BGP MUST retain the format of the OPEN and NOTIFICATION messages.

 8. BGP Finite State machine
@@ -2171,7 +2171,7 @@
 
    Please note that only Event 1 (manual start) and Event 2 (manual
    stop) are mandatory administrative events. All other administrative
-   events are optional.
+   events are OPTIONAL.
 
        Event1: Manual start
 
@@ -2592,7 +2592,7 @@
 
    There is one FSM per BGP connection.  Prior to determining what peer
    a connection is associated with there may be two connections for a
-   given peer.  There should be no more than one connection per peer.
+   given peer.  There SHOULD be no more than one connection per peer.
    The collision detection identifies the case where there is more than
    one connection per peer and provides guidance for which connection to
    get rid of.  When this occurs, the corresponding FSM for the connec-
@@ -3363,7 +3363,7 @@

        In response to a TCP connection succeeds [Event 15
-       or Event 16], the 2nd connection shall be tracked until
+       or Event 16], the 2nd connection SHALL be tracked until
        it sends an OPEN message.
 
        If a valid Open message [Event 18] is received, it will be
@@ -3433,28 +3433,28 @@
    loops. AS loop detection is done by scanning the full AS path (as
    specified in the AS_PATH attribute), and checking that the autonomous
    system number of the local system does not appear in the AS path.  If
-   the autonomous system number appears in the AS path the route may be
+   the autonomous system number appears in the AS path the route MAY be
    stored in the Adj-RIB-In, but unless the router is configured to
    accept routes with its own autonomous system in the AS path, the
-   route shall not be passed to the BGP Decision Process. Operations of
+   route SHALL NOT be passed to the BGP Decision Process. Operations of
    a router that is configured to accept routes with its own autonomous
    system number in the AS path are outside the scope of this document.
 
    If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
    the previously advertised routes whose destinations (expressed as IP
-   prefixes) contained in this field shall be removed from the Adj-RIB-
-   In.  This BGP speaker shall run its Decision Process since the previ-
+   prefixes) contained in this field SHALL be removed from the Adj-RIB-
+   In.  This BGP speaker SHALL run its Decision Process since the previ-
    ously advertised route is no longer available for use.
 
    If the UPDATE message contains a feasible route, the Adj-RIB-In will
    be updated with this route as follows: if the NLRI of the new route
    is identical to the one of the route currently stored in the Adj-RIB-
-   In, then the new route shall replace the older route in the Adj-RIB-
+   In, then the new route SHALL replace the older route in the Adj-RIB-
    In, thus implicitly withdrawing the older route from service. Other-
    wise, if the Adj-RIB-In has no route with NLRI identical to the new
-   route, the new route shall be placed in the Adj-RIB-In.
+   route, the new route SHALL be placed in the Adj-RIB-In.
 
-   Once the BGP speaker updates the Adj-RIB-In, the speaker shall run
+   Once the BGP speaker updates the Adj-RIB-In, the speaker SHALL run
    its Decision Process.

@@ -3487,7 +3487,7 @@
    selection.
 
    The function that calculates the degree of preference for a given
-   route shall not use as its inputs any of the following: the existence
+   route SHALL NOT use as its inputs any of the following: the existence
    of other routes, the non-existence of other routes, or the path
    attributes of other routes. Route selection then consists of individ-
    ual application of the degree of preference function to each feasible
@@ -3524,7 +3524,7 @@
 9.1.1 Phase 1: Calculation of Degree of Preference

-   The Phase 1 decision function shall be invoked whenever the local BGP
+   The Phase 1 decision function SHALL be invoked whenever the local BGP
    speaker receives from a peer an UPDATE message that advertises a new
    route, a replacement route, or withdrawn routes.
 
@@ -3542,16 +3542,16 @@
 RFC DRAFT                                                   October 2002

-   The Phase 1 decision function shall lock an Adj-RIB-In prior to oper-
-   ating on any route contained within it, and shall unlock it after
+   The Phase 1 decision function SHALL lock an Adj-RIB-In prior to oper-
+   ating on any route contained within it, and SHALL unlock it after
    operating on all new or unfeasible routes contained within it.
 
    For each newly received or replacement feasible route, the local BGP
-   speaker shall determine a degree of preference as follows:
+   speaker SHALL determine a degree of preference as follows:
 
       If the route is learned from an internal peer, either the value of
-      the LOCAL_PREF attribute shall be taken as the degree of prefer-
-      ence, or the local system may compute the degree of preference of
+      the LOCAL_PREF attribute SHALL be taken as the degree of prefer-
+      ence, or the local system MAY compute the degree of preference of
       the route based on preconfigured policy information. Note that the
       latter (computing the degree of preference based on preconfigured
       policy information) may result in formation of persistent routing
@@ -3560,7 +3560,7 @@
       If the route is learned from an external peer, then the local BGP
       speaker computes the degree of preference based on preconfigured
       policy information. If the return value indicates that the route
-      is ineligible, the route may not serve as an input to the next
+      is ineligible, the route MAY NOT serve as an input to the next
       phase of route selection; otherwise the return value is used as
       the LOCAL_PREF value in any IBGP readvertisement.
 
@@ -3571,19 +3571,19 @@
 9.1.2 Phase 2: Route Selection

-   The Phase 2 decision function shall be invoked on completion of Phase
+   The Phase 2 decision function SHALL be invoked on completion of Phase
    1. The Phase 2 function is a separate process which completes when it
-   has no further work to do. The Phase 2 process shall consider all
+   has no further work to do. The Phase 2 process SHALL consider all
    routes that are eligible in the Adj-RIBs-In.
 
-   The Phase 2 decision function shall be blocked from running while the
-   Phase 3 decision function is in process. The Phase 2 function shall
-   lock all Adj-RIBs-In prior to commencing its function, and shall
+   The Phase 2 decision function SHALL be blocked from running while the
+   Phase 3 decision function is in process. The Phase 2 function SHALL
+   lock all Adj-RIBs-In prior to commencing its function, and SHALL
    unlock them on completion.
 
    If the NEXT_HOP attribute of a BGP route depicts an address that is
    not resolvable, or it would become unresolvable if the route was
-   installed in the routing table the BGP route should be excluded from
+   installed in the routing table the BGP route MUST be excluded from
    the Phase 2 decision function.
 
    It is critical that routers within an AS do not make conflicting
@@ -3603,7 +3603,7 @@

    For each set of destinations for which a feasible route exists in the
-   Adj-RIBs-In, the local BGP speaker shall identify the route that has:
+   Adj-RIBs-In, the local BGP speaker SHALL identify the route that has:
 
       a) the highest degree of preference of any route to the same set
       of destinations, or
@@ -3626,7 +3626,7 @@
    the NEXT_HOP attribute of the selected route (see section 5.1.3). If
    either the immediate next hop or the IGP cost to the NEXT_HOP (where
    the NEXT_HOP is resolved through an IGP route) changes, Phase 2:
-   Route Selection should be performed again.
+   Route Selection MUST be performed again.
 
    Notice that even though BGP routes do not have to be installed in the
    Routing Table with the immediate next hop(s), implementations must
@@ -3643,7 +3643,7 @@
 9.1.2.1 Route Resolvability Condition

-   As indicated in Section 9.1.2, BGP routers should exclude unresolv-
+   As indicated in Section 9.1.2, BGP routers MUST exclude unresolv-
    able routes from the Phase 2 decision. This ensures that only valid
    routes are installed in Loc-RIB and the Routing Table.
 
@@ -3696,14 +3696,14 @@
    the network.
 
    Whenever a BGP speaker identifies a route that fails the resolvabil-
-   ity check because of mutual recursion, an error message should be
+   ity check because of mutual recursion, an error message SHOULD be
    logged.

 9.1.2.2 Breaking Ties (Phase 2)

-   In its Adj-RIBs-In a BGP speaker may have several routes to the same
+   In its Adj-RIBs-In a BGP speaker MAY have several routes to the same
    destination that have the same degree of preference. The local
    speaker can select only one of these routes for inclusion in the
    associated Loc-RIB. The local speaker considers all routes with the
@@ -3731,7 +3731,7 @@
    The tie-breaking algorithm begins by considering all equally prefer-
    able routes to the same destination, and then selects routes to be
    removed from consideration. The algorithm terminates as soon as only
-   one route remains in consideration.  The criteria must be applied in
+   one route remains in consideration.  The criteria MUST be applied in
    the order specified.
 
    Several of the criteria are described using pseudo-code. Note that
@@ -3828,7 +3828,7 @@
 9.1.3 Phase 3: Route Dissemination

-   The Phase 3 decision function shall be invoked on completion of Phase
+   The Phase 3 decision function SHALL be invoked on completion of Phase
    2, or when any of the following events occur:

@@ -3852,35 +3852,35 @@
 
    The Phase 3 function is a separate process which completes when it
    has no further work to do. The Phase 3 Routing Decision function
-   shall be blocked from running while the Phase 2 decision function is
+   SHALL be blocked from running while the Phase 2 decision function is
    in process.
 
-   All routes in the Loc-RIB shall be processed into Adj-RIBs-Out
-   according to configured policy. This policy may exclude a route in
+   All routes in the Loc-RIB SHALL be processed into Adj-RIBs-Out
+   according to configured policy. This policy MAY exclude a route in
    the Loc-RIB from being installed in a particular Adj-RIB-Out.  A
-   route shall not be installed in the Adj-Rib-Out unless the destina-
+   route SHALL NOT be installed in the Adj-Rib-Out unless the destina-
    tion and NEXT_HOP described by this route may be forwarded appropri-
    ately by the Routing Table. If a route in Loc-RIB is excluded from a
    particular Adj-RIB-Out the previously advertised route in that Adj-
-   RIB-Out must be withdrawn from service by means of an UPDATE message
+   RIB-Out MUST be withdrawn from service by means of an UPDATE message
    (see 9.2).
 
    Route aggregation and information reduction techniques (see 9.2.2.1)
-   may optionally be applied.
+   MAY optionally be applied.
 
    Any local policy which results in routes being added to an Adj-RIB-
    Out without also being added to the local BGP speaker's forwarding
    table, is outside the scope of this document.
 
    When the updating of the Adj-RIBs-Out and the Routing Table is com-
-   plete, the local BGP speaker shall run the Update-Send process of
+   plete, the local BGP speaker SHALL run the Update-Send process of
    9.2.

 9.1.4 Overlapping Routes

-   A BGP speaker may transmit routes with overlapping Network Layer
+   A BGP speaker MAY transmit routes with overlapping Network Layer
    Reachability Information (NLRI) to another BGP speaker. NLRI overlap
    occurs when a set of destinations are identified in non-matching mul-
    tiple routes. Since BGP encodes NLRI using IP prefixes, overlap will
@@ -3913,7 +3913,7 @@

    When overlapping routes are present in the same Adj-RIB-In, the more
-   specific route shall take precedence, in order from more specific to
+   specific route SHALL take precedence, in order from more specific to
    least specific.
 
    The set of destinations described by the overlap represents a portion
@@ -3965,22 +3965,22 @@
    either the same autonomous system or a neighboring autonomous system.
 
    When a BGP speaker receives an UPDATE message from an internal peer,
-   the receiving BGP speaker shall not re-distribute the routing infor-
+   the receiving BGP speaker SHALL NOT re-distribute the routing infor-
    mation contained in that UPDATE message to other internal peers,
    unless the speaker acts as a BGP Route Reflector [RFC2796].
 
    As part of Phase 3 of the route selection process, the BGP speaker
    has updated its Adj-RIBs-Out. All newly installed routes and all
-   newly unfeasible routes for which there is no replacement route shall
+   newly unfeasible routes for which there is no replacement route SHALL
    be advertised to its peers by means of an UPDATE message.
 
-   A BGP speaker should not advertise a given feasible BGP route from
+   A BGP speaker SHOULD NOT advertise a given feasible BGP route from
    its Adj-RIB-Out if it would produce an UPDATE message containing the
    same BGP route as was previously advertised.
 
-   Any routes in the Loc-RIB marked as unfeasible shall be removed.
+   Any routes in the Loc-RIB marked as unfeasible SHALL be removed.
    Changes to the reachable destinations within its own autonomous sys-
-   tem shall also be advertised in an UPDATE message.
+   tem SHALL also be advertised in an UPDATE message.
 
    If due to the limits on the maximum size of an UPDATE message (see
    Section 4) a single route doesn't fit into the message, the BGP
@@ -4082,7 +4082,7 @@
 RFC DRAFT                                                   October 2002

-   The Decision Process may optionally reduce the amount of information
+   The Decision Process MAY optionally reduce the amount of information
    that it will place in the Adj-RIBs-Out by any of the following meth-
    ods:
 
@@ -4145,7 +4145,7 @@
    aggregated.
 
    Path attributes that have different type codes can not be aggregated
-   together. Path attributes of the same type code may be aggregated,
+   together. Path attributes of the same type code MAY be aggregated,
    according to the following rules:
 
       NEXT_HOP:
@@ -4155,10 +4155,10 @@
 
       ORIGIN attribute:
          If at least one route among routes that are aggregated has ORI-
-         GIN with the value INCOMPLETE, then the aggregated route must
+         GIN with the value INCOMPLETE, then the aggregated route MUST
          have the ORIGIN attribute with the value INCOMPLETE.  Other-
          wise, if at least one route among routes that are aggregated
-         has ORIGIN with the value EGP, then the aggregated route must
+         has ORIGIN with the value EGP, then the aggregated route MUSt
          have the origin attribute with the value EGP. In all other case
          the value of the ORIGIN attribute of the aggregated route is
          IGP.
@@ -4173,14 +4173,14 @@
          "type" identifies a type of the path segment the AS belongs to
          (e.g.  AS_SEQUENCE, AS_SET), and "value" is the AS number. If
          the routes to be aggregated have different AS_PATH attributes,
-         then the aggregated AS_PATH attribute shall satisfy all of the
+         then the aggregated AS_PATH attribute SHALL satisfy all of the
          following conditions:
 
             - all tuples of type AS_SEQUENCE in the aggregated AS_PATH
-            shall appear in all of the AS_PATH in the initial set of
+            SHALL appear in all of the AS_PATH in the initial set of
             routes to be aggregated.
 
-            - all tuples of type AS_SET in the aggregated AS_PATH shall
+            - all tuples of type AS_SET in the aggregated AS_PATH SHALL
             appear in at least one of the AS_PATH in the initial set
             (they may appear as either AS_SET or AS_SEQUENCE types).
 
@@ -4239,12 +4239,12 @@
       ATOMIC_AGGREGATE:
          If at least one of the routes to be aggregated has
          ATOMIC_AGGREGATE path attribute, then the aggregated route
-         shall have this attribute as well.
+         SHALL have this attribute as well.
 
       AGGREGATOR:
-         All AGGREGATOR attributes of all routes to be aggregated should
+         All AGGREGATOR attributes of all routes to be aggregated SHOULD
          be ignored. The BGP speaker performing the route aggregation
-         may attach a new AGGREGATOR attribute (see Section 5.1.7).
+         MAY attach a new AGGREGATOR attribute (see Section 5.1.7).

@@ -4288,15 +4288,15 @@
 
 9.4 Originating BGP routes
 
-   A BGP speaker may originate BGP routes by injecting routing informa-
+   A BGP speaker MAY originate BGP routes by injecting routing informa-
    tion acquired by some other means (e.g. via an IGP) into BGP. A BGP
-   speaker that originates BGP routes shall assign the degree of prefer-
+   speaker that originates BGP routes SHALL assign the degree of prefer-
    ence to these routes by passing them through the Decision Process
-   (see Section 9.1). These routes may also be distributed to other BGP
+   (see Section 9.1). These routes MAY also be distributed to other BGP
    speakers within the local AS as part of the update process (see Sec-
    tion 9.2). The decision whether to distribute non-BGP acquired routes
    within an AS via BGP or not depends on the environment within the AS
-   (e.g. type of IGP) and should be controlled via configuration.
+   (e.g. type of IGP) and SHOULD be controlled via configuration.

 10 BGP Timers
@@ -4338,9 +4338,9 @@
    figurable.
 
    To minimize the likelihood that the distribution of BGP messages by a
-   given BGP speaker will contain peaks, jitter should be applied to the
+   given BGP speaker will contain peaks, jitter SHOULD be applied to the
    timers associated with MinASOriginationInterval, KeepAlive, Min-
-   RouteAdvertisementInterval, and ConnectRetry. A given BGP speaker may
+   RouteAdvertisementInterval, and ConnectRetry. 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.
@@ -4348,7 +4348,7 @@
    The suggested default amount of jitter shall be determined by multi-
    plying 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
+   random value SHOULD be picked each time the timer is set. The range
    of the jitter random value MAY be configurable.

@@ -4514,16 +4514,16 @@

    If a local system TCP user interface supports TCP PUSH function, then
-   each BGP message should be transmitted with PUSH flag set.  Setting
+   each BGP message SHOULD be transmitted with PUSH flag set.  Setting
    PUSH flag forces BGP messages to be transmitted promptly to the
    receiver.
 
    If a local system TCP user interface supports setting precedence for
-   TCP connection, then TCP connection used by BGP should be opened with
+   TCP connection, then TCP connection used by BGP SHOULD be opened with
    precedence set to Internetwork Control (110) value (see also
    [RFC791]).
 
-   A local system may protect its BGP connections by using the TCP MD5
+   A local system MAY protect its BGP connections by using the TCP MD5
    Signature Option [RFC2385].

@@ -4602,7 +4602,7 @@
    This permits them to quickly identify sets of attributes from differ-
    ent update messages which are semantically identical.  To facilitate
    this, it is a useful optimization to order the path attributes
-   according to type code.  This optimization is entirely optional.
+   according to type code.  This optimization is entirely OPTIONAL.

 Appendix F.4 AS_SET sorting
@@ -4622,7 +4622,7 @@
 RFC DRAFT                                                   October 2002

-   is entirely optional.
+   is entirely OPTIONAL.

 Appendix F.5 Control over version negotiation
@@ -4638,7 +4638,7 @@

    An implementation which chooses to provide a path aggregation algo-
-   rithm which retains significant amounts of path information may wish
+   rithm which retains significant amounts of path information MAY wish
    to use the following procedure:
 
       For the purpose of aggregating AS_PATH attributes of two routes,
@@ -4692,7 +4692,7 @@
 
       If as a result of the above procedure a given AS number appears
       more than once within the aggregated AS_PATH attribute, all, but
-      the last instance (rightmost occurrence) of that AS number should
+      the last instance (rightmost occurrence) of that AS number SHOULD
       be removed from the aggregated AS_PATH attribute.

-- 
Jeff Haas 
NextHop Technologies