Re: [Xml-sg-cmt] Errata for <bcp14> tags?

[John R Levine <[e-mail]>]

> Do you have thoughts on whether this should be verified?  We have been adding the tagging, so I’m not sure it’s really considered “optional”.
>
> We tag keywords early on in the process and have a tool that checks for correct <bcp14> tagging just prior to pub, but these slipped through.

If we're retroactively making the tags mandatory, we're creating a whole 
lot of existing wrongness.  Here's over 300 lines with untagged keywords 
in what we've published so far.

I'm inclined to add this to the "tag these yourself if they are importatnt to you" list.

Regards,
John Levine, [e-mail], Taughannock Networks, Trumansburg NY
Please consider the environment before reading this e-mail. https://jl.ly

rfc/rfc8652.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8652.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8652.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8652.xml:         1 and 64; a device MAY further restrict the length of this
rfc/rfc8652.xml:         1 and 64; a device MAY further restrict the length of this
rfc/rfc8684.xml:          <t pn="section-3.3.1-14">The mapping provided by a Data Sequence Mapping MUST apply to
rfc/rfc8686.xml:              <th align="left" colspan="1" rowspan="1">3: MUST do 1st lookup</th>
rfc/rfc8686.xml:              <th align="left" colspan="1" rowspan="1">4: SHOULD do further lookups in that order</th>
rfc/rfc8686.xml:      ALTO Cross-Domain Server Discovery Procedure SHOULD inform its caller
rfc/rfc8696.xml:     ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
rfc/rfc8696.xml:  ukm [1] EXPLICIT UserKeyingMaterial OPTIONAL,
rfc/rfc8702.xml:   -- field MUST contain NULL.
rfc/rfc8702.xml:   -- parameters field MUST be absent.  The message digest algorithm
rfc/rfc8702.xml:   -- used in RSASSA-PSS MUST be SHAKE128 or SHAKE256 with a 32- or
rfc/rfc8702.xml:   -- function MUST be SHAKE128 or SHAKE256 with an output length
rfc/rfc8702.xml:   -- The RSASSA-PSS saltLength MUST be 32 or 64 bytes, respectively. 
rfc/rfc8702.xml:   -- The trailerField MUST be 1, which represents the trailer 
rfc/rfc8702.xml:   -- public key MUST be encoded using the RSAPublicKey type.
rfc/rfc8702.xml:   -- MUST be absent and the signature algorithm should be 
rfc/rfc8702.xml:   -- deterministic ECDSA [RFC6979].  The message digest MUST
rfc/rfc8702.xml:   -- MUST be encoded using the id-ecPublicKey type.
rfc/rfc8723.xml:    |                    RTP extension (OPTIONAL) ...               |
rfc/rfc8723.xml:|                    RTP extension (OPTIONAL) ...               | | O
rfc/rfc8724.xml:        <t pn="section-10.10-1">The parser MUST NOT label this field unless the UDP Length value
rfc/rfc8762.xml:              <t>This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.</t>
rfc/rfc8774.xml:	"It is RECOMMENDED that this simplified throughput equation be used 
rfc/rfc8774.xml:              <t>This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc8776.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8776.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8776.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8776.xml:       This attribute MAY be mapped to the Router Address TLV
rfc/rfc8776.xml:       The reachability of such a TE node MAY be achieved by a
rfc/rfc8776.xml:       undergoing establishment.  This MAY also be used to
rfc/rfc8776.xml:       establishment.  This MAY also be used to specify
rfc/rfc8776.xml:       undergoing establishment.  This MAY also be used to specify
rfc/rfc8776.xml:      "Indicates that the LSP MUST be provisioned in the
rfc/rfc8791.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8791.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8791.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8791.xml:       specification using this extension MUST specify the message
rfc/rfc8791.xml:       The substatements of this extension MUST follow the ABNF
rfc/rfc8791.xml:       The substatements of this extension MUST follow the ABNF
rfc/rfc8792.xml:          <t pn="section-7.1.2-3">Exceptionally long lines MAY be folded multiple times.</t>
rfc/rfc8792.xml:          <t pn="section-8.1.2-3">Exceptionally long lines MAY be folded multiple times.</t>
rfc/rfc8794.xml:    Currency MUST be set (minOccurs=1) if the associated Item stores
rfc/rfc8794.xml:    a Cost, else Currency MAY be unset (minOccurs=0).
rfc/rfc8800.xml:	<xref target="I-D.dhody-pce-stateful-pce-optional" format="default" sectionFormat="of" derivedContent="PCE-OPTIONAL"/>
rfc/rfc8800.xml:    <displayreference target="I-D.dhody-pce-stateful-pce-optional" to="PCE-OPTIONAL"/>
rfc/rfc8800.xml:        <reference anchor="I-D.dhody-pce-stateful-pce-optional" quoteTitle="true" target="https://tools.ietf.org/html/draft-dhody-pce-stateful-pce-optional-06" derivedAnchor="PCE-OPTIONAL">
rfc/rfc8819.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8819.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8819.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8819.xml:       carriage return, newline, or tab characters.  It SHOULD begin
rfc/rfc8819.xml:       prefix SHOULD NOT be treated as invalid.";
rfc/rfc8819.xml:       is used by module authors to indicate the tags that SHOULD be
rfc/rfc8824.xml:            <t indent="0">This specification introduces a CoAP option called 'No-Response'. Using this option, the client can explicitly express to the server its disinterest in all responses against the particular request. This option also provides granular control to enable expression of disinterest to a particular response class or a combination of response classes.  The server MAY decide to suppress the response by not transmitting it back to the client according to the value of the No-Response option in the request.  This option may be effective for both unicast and multicast requests.  This document also discusses a few examples of applications that benefit from this option.</t>
rfc/rfc8839.xml:If the candidate is a host candidate, &lt;rel-addr&gt; and &lt;rel-port&gt; MUST be omitted.
rfc/rfc8845.xml:   A Provider OPTIONALLY can include the Simultaneous Transmission
rfc/rfc8849.xml:   cipher suites.  Encrypted SRTP Header extensions <xref target="RFC6904" format="default" sectionFormat="of" derivedContent="RFC6904"/> MUST be supported.
rfc/rfc8855.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc8859.xml:              <t indent="0">This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL.  The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed.  This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.  [STANDARDS-TRACK]</t>
rfc/rfc8866.xml:payload formats MAY be used in the session, and these payload 
rfc/rfc8873.xml:              <t indent="0">This document defines a Message Session Relay Protocol (MSRP) extension, Connection Establishment for Media Anchoring (CEMA). Support of this extension is OPTIONAL.  The extension allows middleboxes to anchor the MSRP connection, without the need for middleboxes to modify the MSRP messages; thus, it also enables secure end-to-end MSRP communication in networks where such middleboxes are deployed.  This document also defines a Session Description Protocol (SDP) attribute, 'msrp-cema', that MSRP endpoints use to indicate support of the CEMA extension.  [STANDARDS-TRACK]</t>
rfc/rfc8877.xml:              <t indent="0">This document describes an OPTIONAL feature for active performance measurement protocols that allows use of the Precision Time Protocol timestamp format defined in IEEE 1588v2, as an alternative to the Network Time Protocol that is currently used.</t>
rfc/rfc8881.xml:                <t pn="section-toc.1-1.5.2.1.1"><xref derivedContent="5.1" format="counter" sectionFormat="of" target="section-5.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-required-attributes">REQUIRED Attributes</xref></t>
rfc/rfc8881.xml:                <t pn="section-toc.1-1.5.2.2.1"><xref derivedContent="5.2" format="counter" sectionFormat="of" target="section-5.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recommended-attributes">RECOMMENDED Attributes</xref></t>
rfc/rfc8881.xml:                <t pn="section-toc.1-1.5.2.6.1"><xref derivedContent="5.6" format="counter" sectionFormat="of" target="section-5.6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-required-attributes-list-an">REQUIRED Attributes - List and Definition References</xref></t>
rfc/rfc8881.xml:                <t pn="section-toc.1-1.5.2.7.1"><xref derivedContent="5.7" format="counter" sectionFormat="of" target="section-5.7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-recommended-attributes-list">RECOMMENDED Attributes - List and Definition References</xref></t>
rfc/rfc8881.xml:            <t pn="section-toc.1-1.17.1"><xref derivedContent="17" format="counter" sectionFormat="of" target="section-17"/>. <xref derivedContent="" format="title" sectionFormat="of" target="name-operations-required-recomme">Operations: REQUIRED, RECOMMENDED, or OPTIONAL</xref></t>
rfc/rfc8881.xml:	  OPEN4_RESULT_MAY_NOTIFY_LOCK reply flag in <xref target="OP_OPEN" format="default" sectionFormat="of" derivedContent="Section 18.16"/> and see <xref target="OP_CB_NOTIFY_LOCK" format="default" sectionFormat="of" derivedContent="Section 20.11"/>).
rfc/rfc8881.xml:   5 == NFSv4.1 clients MUST support
rfc/rfc8881.xml:   6 == NFSv4.1 servers MUST support
rfc/rfc8881.xml:         * GUARDED4 MUST be used.  Otherwise, use
rfc/rfc8887.xml:        the client to the server, and MUST be in the form of a single JMAP
rfc/rfc8904.xml:   MUST NOT be taken to mean no security information is available for
rfc/rfc8913.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8913.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8913.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8913.xml:         MUST be a power of 2 and at least 1024.  It is configured
rfc/rfc8913.xml:        "This parameter limits the maximum Count value, which MUST
rfc/rfc8913.xml:         keys.  Therefore, TWAMP-compliant systems SHOULD have a
rfc/rfc8913.xml:         The default maximum Count value SHOULD be 32768.'
rfc/rfc8913.xml:         value SHOULD be 15, which corresponds to a maximum value of
rfc/rfc8913.xml:           Control-Client MUST choose the highest-priority
rfc/rfc8913.xml:             device SHALL choose its own source IP address.";
rfc/rfc8913.xml:             'Client-IV merely needs to be unique (i.e., it MUST
rfc/rfc8913.xml:               If not configured, the device SHALL choose its own
rfc/rfc8913.xml:               By default, the Control-Client SHALL auto-allocate a
rfc/rfc8913.xml:               message.  The well-known port (862) MAY be used.";
rfc/rfc8913.xml:               MUST NOT be repeated.
rfc/rfc8913.xml:               then the test session SHALL be repeated using the
rfc/rfc8913.xml:               session SHALL be repeated *forever* using the
rfc/rfc8913.xml:               SHALL NOT decrement the value.";
rfc/rfc8913.xml:                 negotiation of a new test session SHALL begin
rfc/rfc8913.xml:               All members of the pm-reg-list MUST have the same
rfc/rfc8913.xml:           'The Server MAY discontinue any established control
rfc/rfc8913.xml:           SHOULD use the DSCP value from the Control-Client's
rfc/rfc8913.xml:          "The Session-Reflector MAY discontinue any session that
rfc/rfc8913.xml:              <t indent="0">The IETF has completed its work on the core specification of TWAMP -- the Two-Way Active Measurement Protocol.  This memo describes an OPTIONAL feature for TWAMP, that gives the controlling host the ability to start and stop one or more individual test sessions using Session Identifiers.  The base capability of the TWAMP protocol requires all test sessions that were previously requested and accepted to start and stop at the same time.  [STANDARDS-TRACK]</t>
rfc/rfc8916.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8916.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8916.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8916.xml:               connection SHOULD be configured to the same
rfc/rfc8923.xml:                                Implementation: via SET_CHECKSUM_REQUIRED.UDP.</t>
rfc/rfc8931.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc8941.xml:        <t indent="0" pn="section-2-13.3">Foo-Example is an Item Structured Header [RFC8941]. Its value MUST be
rfc/rfc8941.xml:        <t indent="0" pn="section-2-13.5">Its value indicates the amount of Foo in the message, and it MUST
rfc/rfc8941.xml:be between 0 and 10, inclusive; other values MUST cause
rfc/rfc8941.xml:MUST be ignored. If its value is a relative reference (Section 4.2
rfc/rfc8941.xml:of [RFC3986]), it MUST be resolved (Section 5 of [RFC3986]) before
rfc/rfc8957.xml:   A Querier MUST wait a configured time (suggested wait of 60 seconds)
rfc/rfc8957.xml:   requests SHOULD be made.  These restricctions are to prevent
rfc/rfc8961.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc8962.xml:      <t indent="0" pn="section-2-1">For possibly the first time in IETF history, words like "SHALL" and "MAY" are used in this document in their real
rfc/rfc8962.xml:             transgressed, any information the investigation produces MAY be used against you in future proceedings.</t>
rfc/rfc8962.xml:             For a period specified in an official notification, all other networks SHALL drop all network packets originating
rfc/rfc8962.xml:      <t indent="0" pn="section-appendix.a-1">Members of the Protocol Police MUST salute and ACK all network traffic from <contact fullname="Daniel Kahn Gillmor"/>, <contact fullname="Mallory Knodel"/>, and <contact fullname="Adrian Farrel"/>.</t>
rfc/rfc8963.xml:            <t indent="0">In Transparent Interconnection of Lots of Links (TRILL) active-active access, a Reverse Path Forwarding (RPF) check failure issue may occur when using the pseudo-nickname mechanism specified in RFC 7781.  This document describes a solution to resolve this RPF check failure issue through centralized replication.  All ingress Routing Bridges (RBridges) send Broadcast, Unknown Unicast, and Multicast (BUM) traffic to a centralized node with unicast TRILL encapsulation.  When the centralized node receives the BUM traffic, it decapsulates the packets and forwards them to their destination RBridges using a distribution tree established per the TRILL base protocol (RFC 6325). To avoid RPF check failure on an RBridge sitting between the ingress RBridge and the centralized replication node, some change in the RPF calculation algorithm is required.  RPF checks on each RBridge MUST be calculated as if the centralized node was the ingress RBridge, instead
  of being calculated using the actual ingress RBridge.  This document updates RFC 6325.</t>
rfc/rfc8984.xml:              <t indent="0" pn="section-4.4.6-5.32.1">This is a list of status codes, returned from the processing of the most recent scheduling message sent to this participant. The status codes MUST be valid <tt>statcode</tt> values as defined in the ABNF in <xref target="RFC5545" sectionFormat="of" section="3.8.8.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc5545#section-3.8.8.3" derivedContent="RFC5545"/>.</t>
rfc/rfc8985.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc8995.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc8995.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc8995.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc8995.xml:           voucher-request, and any occurrence MUST be ignored.";
rfc/rfc8995.xml:           voucher-request, and any occurrence MUST be ignored.";
rfc/rfc8995.xml:           voucher-request, and any occurrence MUST be ignored.";
rfc/rfc8995.xml:           SHOULD be ignored by the MASA.";
rfc/rfc8995.xml:             protocol path, then the previously signed voucher SHOULD
rfc/rfc8995.xml:             The registrar and MASA MAY examine the prior-signed
rfc/rfc8995.xml:             assertions.  The MASA SHOULD remove all
rfc/rfc8995.xml:             to the pledge.  This MUST be populated in a pledge's
rfc/rfc9006.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc9020.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc9020.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc9020.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc9020.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc9020.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc9020.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc9020.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc9020.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc9020.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc9024.xml:		Note: Network fragmentation for DetNet is not supported and MUST be avoided. The reason for this is that network fragmentation is not  consistent with the packet delivery times needed for DetNet. Therefore, when IP is used as the sub-network, IPv6 fragmentation MUST NOT be used, and IPv4 packets MUST be sent with the DF bit set. This means that the network operator MUST ensure that all the DetNet encapsulation overhead plus the maximum TSN App-flow frame size does not exceed the DetNet network's MTU.
rfc/rfc9034.xml:	originating node MUST further ensure that
rfc/rfc9034.xml:	MUST use the same value for the SAFETY_FACTOR.  The SAFETY_FACTOR
rfc/rfc9040.xml:              <t indent="0">This document defines the standard algorithm that Transmission Control Protocol (TCP) senders are required to use to compute and manage their retransmission timer.  It expands on the discussion in Section 4.2.3.1 of RFC 1122 and upgrades the requirement of supporting the algorithm from a SHOULD to a MUST.  This document obsoletes RFC 2988.   [STANDARDS-TRACK]</t>
rfc/rfc9051.xml:        <iref item="MUST (specification requirement term)" subitem="" primary="false" pn="iref-must-specification-requirem"/>
rfc/rfc9051.xml:        <iref item="MUST NOT (specification requirement term)" subitem="" primary="false" pn="iref-must-not-specification-requ"/>
rfc/rfc9051.xml:        <iref item="OPTIONAL (specification requirement term)" subitem="" primary="false" pn="iref-optional-specification-requ"/>
rfc/rfc9051.xml:        <iref item="REQUIRED (specification requirement term)" subitem="" primary="false" pn="iref-required-specification-requ"/>
rfc/rfc9051.xml:        <iref item="SHOULD (specification requirement term)" subitem="" primary="false" pn="iref-should-specification-requir"/>
rfc/rfc9051.xml:        <iref item="SHOULD NOT (specification requirement term)" subitem="" primary="false" pn="iref-should-not-specification-re"/>
rfc/rfc9051.xml:        <iref item="RECOMMENDED (specification requirement term)" subitem="" primary="false" pn="iref-recommended-specification-r"/>
rfc/rfc9051.xml:        <iref item="NOT RECOMMENDED (specification requirement term)" subitem="" primary="false" pn="iref-not-recommended-specificati"/>
rfc/rfc9051.xml:        <iref item="MAY (specification requirement term)" subitem="" primary="false" pn="iref-may-specification-requireme"/>
rfc/rfc9051.xml:        <iref item="OPTIONAL (specification requirement term)" subitem="" primary="false" pn="iref-optional-specification-requi"/>
rfc/rfc9051.xml:   format. This size SHOULD match the result
rfc/rfc9051.xml:                    ; MUST accept body-extension fields.  Server
rfc/rfc9051.xml:                    ; implementations MUST NOT generate
rfc/rfc9051.xml:                    ; MUST NOT be returned on non-extensible
rfc/rfc9051.xml:                    ; MUST NOT be returned on non-extensible
rfc/rfc9051.xml:                    ; MESSAGE subtype MUST NOT be "RFC822" or
rfc/rfc9051.xml:                    ; New capabilities SHOULD be
rfc/rfc9051.xml:                    ; Servers that offer RFC 1730 compatibility MUST
rfc/rfc9051.xml:                    ; Servers that offer RFC 3501 compatibility MUST
rfc/rfc9051.xml:                    ; MUST accept flag-extension flags.  Server
rfc/rfc9051.xml:                    ; implementations MUST NOT generate
rfc/rfc9051.xml:                    ; of INBOX (e.g., "iNbOx") MUST be interpreted as
rfc/rfc9051.xml:               ; The content MUST conform to either
rfc/rfc9051.xml:                    ; MAY change for a message
rfc/rfc9051.xml:                    ; MUST NOT change for a message
rfc/rfc9051.xml:                    ; MUST NOT contain ".", "/", "%", or "*"
rfc/rfc9051.xml:                    ; CHARSET argument to SEARCH MUST be
rfc/rfc9051.xml:                    ; Servers MAY coalesce overlaps and/or execute
rfc/rfc9051.xml:                    ; equivalent to 10,9,8,7,6,5,4,5,6,7 and MAY
rfc/rfc9051.xml:                    ; MUST be registered with IANA
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.15.2.1.1.9">MAY (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.15.2.1.1.33">MUST (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.15.2.1.1.37">MUST NOT (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.16.2.1.1.29">NOT RECOMMENDED (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.17.2.1.1.9">OPTIONAL (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.18.2.1.1.13">PRIVACYREQUIRED (response code)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.19.2.1.1.9">RECOMMENDED (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.19.2.1.1.17">REQUIRED (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.20.2.1.1.33">SHOULD (specification requirement term)</dt>
rfc/rfc9051.xml:                <dt pn="section-appendix.h-2.20.2.1.1.37">SHOULD NOT (specification requirement term)</dt>
rfc/rfc9061.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
rfc/rfc9061.xml:     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
rfc/rfc9061.xml:     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
rfc/rfc9061.xml:       values MUST follow the requirement levels for
rfc/rfc9061.xml:       The acceptable values MUST follow the requirement
rfc/rfc9061.xml:         SHOULD be rekeyed.  The value 0 implies
rfc/rfc9061.xml:         SHOULD be rekeyed.  The value 0 implies
rfc/rfc9061.xml:         SHOULD be removed.  The value 0 implies
rfc/rfc9061.xml:          "The end port number MUST be equal or greater
rfc/rfc9061.xml:         the inner IP header.  This MUST be ignored or
rfc/rfc9061.xml:             this flag MUST be false.  Setting this
rfc/rfc9061.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
rfc/rfc9061.xml:     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
rfc/rfc9061.xml:     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
rfc/rfc9061.xml:         but also for the local NSF.  The local NSF MAY use the
rfc/rfc9061.xml:                 example.com.  The string MUST
rfc/rfc9061.xml:                 MUST NOT contain any
rfc/rfc9061.xml:                 reasons.  This value MUST be
rfc/rfc9061.xml:                 MUST contain information.  For
rfc/rfc9061.xml:             peer is stored.  It MUST match a
rfc/rfc9061.xml:             remote peer is stored.  It MUST match a
rfc/rfc9061.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL',
rfc/rfc9061.xml:     'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED',
rfc/rfc9061.xml:     'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this
rfc/rfc9061.xml:               this flag MUST BE false. Setting this
rfc/rfc9061.xml:         SA that MUST be generated.";
rfc/rfc9064.xml:            <td align="center" colspan="1" rowspan="1">MAYBE</td>
rfc/rfc9067.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc9067.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc9067.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc9067.xml:         prefix-set MUST be of the same address family as the
rfc/rfc9067.xml:        "Mask length range lower bound.  It MUST NOT be less than
rfc/rfc9067.xml:        error-message "The upper bound MUST NOT be less "
rfc/rfc9067.xml:        "Mask length range upper bound.  It MUST NOT be less than
rfc/rfc9067.xml:               The mode provides a hint; all prefixes MUST be of
rfc/rfc9067.xml:               the indicated type.  The device MUST validate
rfc/rfc9067.xml:                   called policy SHOULD contain an explicit or a
rfc/rfc9067.xml:                   ambiguous. The call-policy MUST NOT have been
rfc/rfc9073.xml:                   ; The following is REQUIRED
rfc/rfc9073.xml:                   ; but MUST NOT occur more than once.
rfc/rfc9073.xml:                   ; The following are OPTIONAL
rfc/rfc9073.xml:                   ; but MUST NOT occur more than once.
rfc/rfc9073.xml:                   ; The following is OPTIONAL
rfc/rfc9073.xml:                   ; and MAY occur more than once.
rfc/rfc9073.xml:;Value MUST match value type
rfc/rfc9073.xml:                 ; The following is OPTIONAL for a URI value,
rfc/rfc9073.xml:                 ; REQUIRED for a TEXT or BINARY value,
rfc/rfc9073.xml:                 ; and MUST NOT occur more than once.
rfc/rfc9073.xml:                 ; The following is OPTIONAL
rfc/rfc9073.xml:                 ; and MAY occur more than once.
rfc/rfc9073.xml:               ; The following are REQUIRED
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; and MAY occur more than once.
rfc/rfc9073.xml:               ; The following are REQUIRED
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; and MAY occur more than once.
rfc/rfc9073.xml:               ; The following are REQUIRED
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; but MUST NOT occur more than once.
rfc/rfc9073.xml:               ; The following are OPTIONAL
rfc/rfc9073.xml:               ; and MAY occur more than once.
rfc/rfc9074.xml:             ; the following are REQUIRED
rfc/rfc9074.xml:             ; but MUST NOT occur more than once
rfc/rfc9074.xml:             ; one set of action properties MUST be
rfc/rfc9074.xml:             ; present and MUST match the action specified
rfc/rfc9074.xml:             ; the following are OPTIONAL
rfc/rfc9074.xml:             ; and MAY occur more than once
rfc/rfc9074.xml:                ; 'duration' and 'repeat' are both OPTIONAL
rfc/rfc9074.xml:                ; and MUST NOT occur more than once each,
rfc/rfc9074.xml:                ; but if one occurs, so MUST the other
rfc/rfc9074.xml:                ; the following is OPTIONAL
rfc/rfc9074.xml:                ; but MUST NOT occur more than once
rfc/rfc9074.xml:              ; the following are REQUIRED
rfc/rfc9074.xml:              ; but MUST NOT occur more than once
rfc/rfc9074.xml:              ; 'duration' and 'repeat' are both OPTIONAL
rfc/rfc9074.xml:              ; and MUST NOT occur more than once each,
rfc/rfc9074.xml:              ; but if one occurs, so MUST the other
rfc/rfc9074.xml:               ; the following are all REQUIRED
rfc/rfc9074.xml:               ; but MUST NOT occur more than once
rfc/rfc9074.xml:               ; the following is REQUIRED
rfc/rfc9074.xml:               ; and MAY occur more than once
rfc/rfc9074.xml:               ; 'duration' and 'repeat' are both OPTIONAL
rfc/rfc9074.xml:               ; and MUST NOT occur more than once each,
rfc/rfc9074.xml:               ; but if one occurs, so MUST the other
rfc/rfc9074.xml:               ; the following is OPTIONAL
rfc/rfc9074.xml:               ; and MAY occur more than once
rfc/rfc9074.xml:                ; the following are OPTIONAL
rfc/rfc9074.xml:                ; and MAY occur more than once
rfc/rfc9074.xml:              ; the following is OPTIONAL
rfc/rfc9074.xml:              ; but MUST NOT occur more than once
rfc/rfc9074.xml:              ; the following is OPTIONAL
rfc/rfc9074.xml:              ; and MAY occur more than once
rfc/rfc9074.xml:                   ; the following is OPTIONAL
rfc/rfc9074.xml:                   ; but MUST NOT occur more than once
rfc/rfc9074.xml:                     ; the following is OPTIONAL
rfc/rfc9074.xml:                     ; and MAY occur more than once
rfc/rfc9074.xml:                   ; the following is OPTIONAL
rfc/rfc9074.xml:                   ; but MUST NOT occur more than once
rfc/rfc9074.xml:                   ; the following is OPTIONAL
rfc/rfc9074.xml:                   ; and MAY occur more than once but only
rfc/rfc9074.xml:                  ; the following is OPTIONAL
rfc/rfc9074.xml:                  ; and MAY occur more than once
rfc/rfc9105.xml:     The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL
rfc/rfc9105.xml:     NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'NOT RECOMMENDED',
rfc/rfc9105.xml:     'MAY', and 'OPTIONAL' in this document are to be interpreted as
rfc/rfc9105.xml:                 administrators SHOULD configure a shared secret with
rfc/rfc9118.xml:      mustInclude [0] JWTClaimNames OPTIONAL,
rfc/rfc9118.xml:        -- The listed claim names MUST appear in the PASSporT
rfc/rfc9118.xml:        -- and dest MUST appear in the PASSporT.
rfc/rfc9118.xml:      permittedValues [1] JWTClaimValuesList OPTIONAL,
rfc/rfc9118.xml:        -- If the claim name is present, the claim MUST contain one
rfc/rfc9118.xml:      mustExclude [2] JWTClaimNames OPTIONAL }
rfc/rfc9118.xml:        -- The listed claim names MUST NOT appear in the PASSporT.
rfc/rfc9118.xml:  mustInclude [0] JWTClaimNames OPTIONAL,
rfc/rfc9118.xml:    -- The listed claim names MUST appear in the PASSporT
rfc/rfc9118.xml:    -- and dest MUST appear in the PASSporT.
rfc/rfc9118.xml:  permittedValues [1] JWTClaimValuesList OPTIONAL,
rfc/rfc9118.xml:    -- If the claim name is present, the claim MUST contain one
rfc/rfc9118.xml:  mustExclude [2] JWTClaimNames OPTIONAL }
rfc/rfc9118.xml:    -- The listed claim names MUST NOT appear in the PASSporT.