Re: [sfc] Shepherd's review of draft-ietf-sfc-multi-layer-oam-21

[Donald Eastlake <[e-mail]>]

Hi Greg:

I'm OK with the candidate version -22 you sent out except for the
following trivial glitches. Suggest you fix these and upload next week
when auto-submissions are re-enabled.

"fieldand" -> "field and"

Delete period in line below:
  TTL expired (as per [RFC8300]) may be sending the Echo Reply. is

"Figure 11Figure 10" -> "Figure 10"

"ofSFC" -> "of SFC"

Thanks,
Donald
===============================
 Donald E. Eastlake 3rd   [phone] (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 [e-mail]

On Sun, Jul 17, 2022 at 3:07 PM Greg Mirsky <[e-mail]> wrote:
>
> Hi Donald,
> thank you for your thorough and extremely helpful feedback. We accepted all the updates you've suggested. Attached, please find the diff highlighting the applied changes and the copy of the working version. I hope that I captured all proposed changes and applied updates correctly.
>
> Regards,
> Greg
>
> On Sat, Jul 16, 2022 at 1:11 PM Donald Eastlake <[e-mail]> wrote:
>>
>> Hi,
>>
>> See below:
>>
>>       This document defines how active Operation, Administration and
>>       Maintenance (OAM), per [RFC7799] definition of active OAM, is
>>       identified when Network Service Header (NSH) is used as the SFC
>>
>> (NSH) -> (NSH [RFC8300])
>>
>>       encapsulation.  Following the analysis of SFC OAM in [RFC8924], this
>>       document applies and, when necessary, extends requirements listed in
>>       Section 4 of [RFC8924] for the use of active OAM in an SFP supporting
>>       fault management and performance monitoring.  Active OAM tools,
>>
>>
>>       conformant to the requirements listed in Section 3, improve, for
>>       example, troubleshooting efficiency and defect localization in SFP
>>       because they specifically address the architectural principles of
>>       NSH.  For that purpose, SFC Echo Request and Echo Reply are specified
>>       in Section 6.  This mechanism enables on-demand Continuity Check,
>>
>> "Check," -> "Check and"
>>
>>       Connectivity Verification, among other operations over SFC in
>>
>> "Verification," -> "Verification"
>>
>>       networks, addresses functionalities discussed in Sections 4.1, 4.2,
>>
>> ", addresses" -> " and addresses"
>>
>>       and 4.3 of [RFC8924].  SFC Echo Request and Echo Reply, defined in
>>       this document, can be used with encapsulations other than NSH, for
>>       example, using MPLS encapsulation, as described in [RFC8595].  The
>>       applicability of the SFC Echo Request/Reply mechanism in SFC
>>       encapsulations other than NSH is outside the scope of this document.
>>
>>
>>          REQ#8: SFC OAM MUST be able to trigger on-demand FM with responses
>>          being directed towards the initiator of such proxy request.
>>
>> Why is this a "proxy" request? Why not just "such a request."?
>>
>>
>>    6.  Echo Request/Echo Reply for SFC
>>
>>       Echo Request/Reply is a well-known active OAM mechanism extensively
>>       used to verify a path's continuity, detect inconsistencies between a
>>       state in control and the data planes, and localize defects in the
>>       data plane.  ICMP ([RFC0792] for IPv4 and [RFC4443] for IPv6
>>       networks, respectively) and [RFC8029] are examples of broadly
>>       used
>>
>> Delete ", respectively".
>>
>>
>>          The Echo Request Flags is a two-octet bit vector field.  Note that
>>          a flag defined in the Flags field of the SFC Active OAM header in
>>          Figure 2 has no implication of those defined in the Echo Request
>>          Flags field of an Echo Request/Reply message.
>>
>>  Editorial: suggest replacement paragraph:
>>
>>          The Echo Request Flags is a two-octet bit vector field.  A
>>          flag defined in the Flags field of the SFC Active OAM header
>>          in Figure 2 has no implication for those defined in the Echo
>>          Request Flags field of an Echo Request/Reply message.
>>
>>
>>
>>          Return Codes and Subcodes are one-octet fields each.  These can be
>>          used to inform the sender about the result of processing its
>>          request.  Initial Return Code values are provided in Table 1.
>>          For
>>
>> Delete "Initial".
>>
>>          all Return Code values defined in this document, the value of the
>>          Return Subcode field MUST be set to zero.
>>
>>          The Sender's Handle is a four-octet field.  It MUST be filled in
>>          by the sender of the Echo Request and returned unchanged by the
>>          Echo Reply sender (if a reply mandated).  The sender of the Echo
>>
>> "reply mandated" -> "replay is mandated"
>>
>>          Request SHOULD use a pseudo-random number generator to set the
>>          value of the Sender's Handle field.
>>
>> "generator to" -> "generator [RFC4086] to"
>>
>>
>>          The Sequence Number is a four-octet field, and it is assigned by
>>          the sender and can be, for example, used to detect missed replies.
>>          Initial Sequence Number MUST be randomly generated and then SHOULD
>>
>> Replace beginning of above line with
>>          The initial Sequence Number MUST be pseudo-randomly generated [RFC4086]
>>
>>          be monotonically increasing in the course of the test session.
>>
>>
>>       TLV is a variable-length construct.  Multiple TLVs MAY be placed in
>>       an SFC Echo Request/Reply packet.  None, one or more sub-TLVs may be
>>       enclosed in a TLV, subject to the semantics of the (outer) TLV.
>>
>> "in a TLV" -> "in the value part of a TLV"
>>
>>       Figure 4 presents the format of an SFC Echo Request/Reply TLV, where
>>       fields are defined as follows:
>>
>>
>>          Type - a one-octet field that characterizes the interpretation of
>>          the Value field.  The value of the Type field determines its
>>          interpretation and encoding.  Type values allocated according to
>>          Section 10.4.
>>
>> In the above paragraph, the 2nd sentence seems redundant and could be
>> deleted. Also "values allocated" -> "values are allocated"
>>
>>
>>          Length - a two-octet field equal to the Value field's length in
>>          octets.
>>
>> Suggest "octets." -> "octets as an unsigned integer."
>>
>>
>>    6.1.  Return Codes
>>
>>       The value of the Return Code field is set to zero by the sender of an
>>
>> How about"is set" -> "MUST be set"
>>
>>       Echo Request.  The receiver of said Echo Request can set it to one of
>>       the values listed in Table 1 in the corresponding Echo Reply that it
>>       generates (in cases when the reply is requested).
>>
>>
>>    6.2.  Authentication in Echo Request/Reply
>>
>>       Authentication can be used to protect the integrity of the
>>       information in SFC Echo Request and/or Echo Reply.  In the [RFC9145]
>>       a variable-length Context Header has been defined to protect the
>>       integrity of the NSH and the payload.  The header can also be used
>>       for the optional encryption of sensitive metadata.  MAC#1 (Message
>>       Authentication Code) Context Header is more suitable for the
>>       integrity protection of active SFC OAM, particularly of the defined
>>       in this document SFC Echo Request and Echo Reply.  On the other hand,
>>
>> I think the lines above read better if "defined in this document" is
>> moved to the end of the sentence.
>>
>>       using MAC#2 Context Header allows the detection of mishandling of the
>>       O-bit by a transient SFC element.
>>
>>
>>       Value of the Reply Mode field MAY be set to:
>>
>> -> "Value of the Reply Mode field MUST be set to one of the following:"
>>
>>       *  Do Not Reply (1) if one-way monitoring is desired.  If the Echo
>>          Request is used to measure synthetic packet loss, the receiver may
>>          report loss measurement results to a remote node.  Note that ways
>>
>> "Note that ways" -> "Ways"
>>
>>          of learning the identity of that node are outside the scope of
>>          this specification.
>>
>>       *  Reply via an IPv4/IPv6 UDP Packet (2) value likely will be the
>>          most used.
>>
>> -> "Reply via an IPv4/IPv6 UDP packet (2). This will likely be the
>> most common value."
>>
>>       *  Reply via Application-Level Control Channel (3) value if the SFP
>>          may have bi-directional paths.
>>
>> -> "Reply via Application-Level Control Channel (3). Useful if the SFP
>> has bi-directional paths."
>>
>>       *  Reply via Specified Path (4) value to enforce the use of the
>>
>> "(4) value to enforce the" -> "(4). This value requests the"
>>
>>          particular return path specified in the included TLV to verify bi-
>>          directional continuity and also increase the robustness of
>>          the
>>
>> "and also" -> "and may also"
>>
>>          monitoring by selecting a more stable path.  Section 6.5.1
>>          provides an example of communicating an explicit path for the Echo
>>          Reply.
>>
>>       *  Reply via an IPv4/IPv6 UDP Packet with the data integrity
>>          protection (5) value to enforce use of the MAC Context Header
>>
>> "(5) value to enforce use" -> "(5). This value requests the use"
>>
>>          [RFC9145].
>>
>>       *  Reply via Application-Level Control Channel with the data
>>          integrity protection (6) value to enforce use of the MAC Context
>>
>> "(6) value to enforce use" -> "(6). This value requests the use"
>>
>>          Header [RFC9145].
>>
>>       *  Reply via Specified Path with the the data integrity protection
>>          (7) value to enforce use of the MAC Context Header [RFC9145].
>>
>> "(7) value to enforce use" -> "(7). This value requests the use"
>>
>>    6.3.1.  Source TLV
>>
>>       Responder to the SFC Echo Request encapsulates the SFC Echo Reply
>>
>> "Responder" -> "The responder"
>>
>>       message in IP/UDP packet if the Reply mode is "Reply via an IPv4/IPv6
>>       UDP Packet".  Because the NSH does not identify the ingress node that
>>       generated the Echo Request, the source ID MUST be included in the
>>       message and used as the IP destination address and destination UDP
>>       port number of the SFC Echo Reply.  The sender of the SFC Echo
>>       Request MUST include an SFC Source TLV (Figure 5).
>>
>>
>>       A single Source ID TLV for each address family, i.e., IPv4 and IPv6,
>>       MAY be present in an SFC Echo Request message.  If the Source TLVs
>>       for both address families are present in an SFC Echo Request message,
>>       the SFF MUST NOT replicate an SFC Echo Reply but choose the
>>       destination IP address for the SFC Echo Reply based on the local
>>
>> "the SFC Echo Reply based" -> "the one SFC Echo Reply it sends based"
>>
>>       policy.  If more than one Source ID TLV per the address family is
>>       present, the receiver MUST use the first TLV and ignore the rest.
>>
>>
>>    6.4.  SFC Echo Request Reception
>>
>>       Punting received SFC Echo Request to the control plane is triggered
>>
>> "Punting received" -> "Punting a received"
>>
>>       by one of the following packet processing exceptions: NSH TTL
>>       expiration, NSH Service Index (SI) expiration, or the receiver is the
>>       terminal SFF for an SFP.
>>
>>       Firstly, if the SFC Echo Request is integrity-protected, the
>>       receiving SFF first MUST verify the authentication.  Then the
>>       receiver SFF MUST validate the Source TLV, as defined in
>>       Section 6.3.1.  Suppose the authentication validation has failed and
>>       the Source TLV is considered properly formatted.  In that case, the
>>       SFF MUST send to the system identified in the Source TLV (see
>>       Section 6.5), according to a rate-limit control mechanism, an SFC
>>       Echo Reply with the Return Code set to "Authentication failed" and
>>       the Subcode set to zero.  If the Source TLV is determined malformed,
>>       the received SFC Echo Request processing is stopped, the message is
>>       dropped, and the event SHOULD be logged, according to a rate-limiting
>>       control for logging.  Then, the SFF that has received an SFC Echo
>>       Request verifies the rest of the received packet's general sanity.
>>       If the packet is not well-formed, the receiver SFF SHOULD send an SFC
>>       Echo Reply with the Return Code set to "Malformed Echo Request
>>       received" and the Subcode set to zero under the control of the rate-
>>       limiting mechanism to the system identified in the Source TLV (see
>>       Section 6.5).  If there are any TLVs that the SFF does not
>>       understand, the SFF MUST send an SFC Echo Reply with the Return Code
>>       set to 2 ("One or more TLVs was not understood") and set the Subcode
>>       to zero.  In the latter case, the SFF MAY include an Errored TLVs TLV
>>       (Section 6.4.1) that, as sub-TLVs, contains only the misunderstood
>>       TLVs.  Sender's Handle and Sequence Number fields are not examined
>>       but are included in the SFC Echo Reply message.  If the sanity check
>>       of the received Echo Request succeeded, then the SFF at the end of
>>       the SFP MUST set the Return Code value to 5 ("End of the SFP") and
>>       the Subcode set to zero.  If the SFF is not at the end of the SFP and
>>       the TTL value is 1, the value of the Return Code MUST be set to 4
>>       ("TTL Exceeded") and the Subcode set to zero.  In all other cases,
>>       SFF MUST set the Return Code value to 0 ("No Return Code") and the
>>       Subcode set to zero.
>>
>> The above paragraph is very long and, I think, would be better
>> reformatted as a numbered list or the like.
>>
>>
>>          The Sub-TLV's Type the copy of the first octet of the not
>>          understood or failed to be parced TLV.
>>
>> "Type the copy" -> "Type - a copy"
>> "parced" -> "parsed"
>>
>>
>>          The Sub-TLV Value field contains data that follow the Legth field
>>          in the errored TLV.
>>
>> "Legth" -> "Length"
>>
>>    6.5.  SFC Echo Reply Transmission
>>
>>       The "Reply Mode" field directs whether and how the Echo Reply message
>>       should be sent.  The Echo Request sender MAY use TLVs to request that
>>       the corresponding Echo Reply be transmitted over the specified path.
>>       Section 6.5.1 provides an example of a TLV that specifies the return
>>       path of the Echo Reply.  Value 1 is the "Do not reply" mode and
>>       suppresses the Echo Reply packet transmission.  The default value (2)
>>       for the Reply mode field requests the responder to send the Echo
>>       Reply packet out-of-band as IPv4 or IPv6 UDP packet.
>>
>> "requests the responder to send the" -> "requests sending the"
>> "as IPv4" -> "as an IPv4"
>>
>>
>>       The SFC Reply Path TLV carries the information that sufficiently
>>       identifies the return SFP that the SFC Echo Reply message is expected
>>       to follow.  The format of SFC Reply Path TLV is shown in Figure 8.
>>
>> Above and in this document below, there are many occurrences of
>> "SFC Reply Path TLV" that I think should be globally changed to
>> "Reply Service Function Path TLV".
>>
>>
>>       *  SFC Reply Path Type: is a one-octet field, indicates the TLV that
>>          contains information about the SFC Reply path.  IANA is requested
>>          to assign value 3,
>>
>> Replacement point for the above:
>>
>>       *  Reply Service Function Path Type (3): This is is a one-octet
>>          fieldand indicates the TLV that contains information about
>>          the SFC Reply path.
>>
>>       *  Reserved - one-octet field.  The field MUST be zeroed on
>>          transmission and ignored on receipt.
>>
>> " -" -> ": "
>>
>>       *  Length: is a two-octet field, MUST be equal to 4
>>
>>       *  Reply Service Function Path is used to describe the return path
>>          that an SFC Echo Reply is requested to follow.
>>
>>       The format of the Reply Service Function Path field displayed in
>>       Figure 9.
>>
>>
>>            0                   1                   2                   3
>>            0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>>           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>           |    Reply Service Function Path Identifier     | Service Index |
>>           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>>
>>              Figure 9: Reply Service Function Path Field Format
>>
>> I don't see any reason for Figure 9 to be separate from Figure 8. They
>> could be integrated.
>>
>>
>>       The destination SFF of the SFP being tested or the SFF at which SFC
>>       TTL expired (as per [RFC8300]) may be sending the Echo Reply.  The
>>       processing described below equally applies to both cases and is
>>       referred to as responding SFF.
>>
>> I think things got slightly scrambled above. How about:
>>
>>       The destination SFF of the SFP being tested or the SFF at which
>>       SFC TTL expired (as per [RFC8300]) may be sending the Echo Reply
>>       is referred to as responding SFF.  The processing described
>>       below equally applies to both cases.
>>
>>
>>       *  if the matching to the Echo Request found, the value of the
>>
>> Replace above line with:
>>
>>       *  the matching SFC Echo Request is found, that is, the value of the
>>
>>          Sender's Handle in the Echo Request sent is equal to the value of
>>          Sender's Handle in the Echo Reply received;
>>
>>       *  if all checks passed, the SFF checks if the Sequence Number
>>          in the
>>
>> Replace above with:
>>
>>       *  all other checks and and the Sequence Number
>>
>>          Echo Request sent matches to the Sequence Number in the Echo Reply
>>          received.
>>
>>
>>       Suppose a specialized information element (e.g., IPv6 Flow Label
>>       [RFC6437] or Flow ID [I-D.ietf-sfc-nsh-tlv]) is used for distributing
>>       the load across Equal Cost Multi-Path or Link Aggregation Group
>>       paths.  In that case, such an element MAY also be used for the SFC
>>
>> How about "MAY" -> "SHOULD"?
>>
>>       OAM traffic.  Doing so is meant to induce the SFC Echo Request to
>>       follow the same RSP as the monitored flow.
>>
>>    6.6.  Verification of the SFP Consistency
>>
>>       The consistency of an SFP can be verified by comparing the view of
>>       the SFP from the control or management plane with information
>>       collected from traversed by an SFC NSH Echo Request message.  Every
>>
>> "traversed" -> "traversing"
>>
>>       SFF that receives the Consistency Verification Request (CVReq)
>>
>> "the Consistency" -> "a Consistency"
>>
>>       (specified in Section 6.6.1) MUST perform the following actions:
>>
>>       *  Collect information of the traversed by the CVReq packet SFs and
>>
>> Replace above line with:
>>
>>       *  Collect information about the SFs traversed by the CVReq packet and
>>
>>          send it to the ingress SFF as CVRep packet over IP network;
>>
>>       *  Forward the CVReq to the next downstream SFF if the one exists.
>>
>>       As a result, the ingress SFF collects information about all traversed
>>       SFFs and SFs, information on the actual path the CVReq packet has
>>       traveled.  That information is used to verify the SFC's path
>>
>> "is used" -> "can be used"
>>
>>       consistency.  The mechanism for the SFP consistency verification is
>>       outside the scope of this document.
>>
>>
>>    6.6.1.  SFP Consistency Verification packet
>>
>>       For the verification of an SFP consistency, two new types of messages
>>       to the SFC Echo Request/Reply operation defined in Section 6 with the
>>       following values detailed in Section 10.3.2:
>>
>> Replace above paragraph with the following:
>>
>>       For the verification of an SFP consistency, two types of SFC Active OAM
>>       messages are defined in addition to the SFC Echo Request/Reply messages.
>>       Their SFC Echo Request/Echo Response Message Types are as follows:
>>
>>       *  3 - SFP Consistency Verification Request
>>
>>       *  4 - SFP Consistency Verification Reply
>>
>>
>>    6.6.2.  SFF Information Record TLV
>>
>>       For the received CVReq, an SFF is expected to include in the CVRep
>>       message the information about SFs that are mapped to that SFF.  The
>>
>> "mapped to" -> "available from"?
>>
>>       SFF MUST include SFF Information Record TLV (Figure 10) in CVRep
>>       message.  Every SFF sends back a single CVRep message, including
>>       information on all the SFs attached to the SFF on the SFP, as
>>
>> "the SFF" -> "that SFF"
>>
>>       requested in the received CVReq message using the SF Information sub-
>>       TLV (Section 6.6.3).
>>
>>
>>       The SFF Information Record TLV is a variable-length TLV that includes
>>       the information of all SFs mapped to the particular SFF instance for
>>
>> "mapped to" -> "available from"
>>
>>       the specified SFP.  Figure 10 presents the format of an SFF
>>       Information Record TLV, where fields are defined as the following:
>>
>>
>>       If the NSH of the received SFC Echo Reply includes the MAC Context
>>       Header [RFC9145], the authentication of the packet MUST be verified
>>       before using any data.  If the verification fails, the receiver MUST
>>       stop processing the SFF Information Record TLV and notify an
>>       operator.  The notification mechanism SHOULD include control of rate-
>>       limiting messages.  Specification of the notification mechanism is
>>
>> "limiting messages" -> "limited messages"
>>
>>       outside the scope of this document.
>>
>>    6.6.3.  SF Information Sub-TLV
>>
>>       Every SFF receiving CVReq packet MUST include the SF characteristic
>>
>> "receiving CVReq" -> "receiving a CVReq"
>>
>>       data into the CVRep packet.  The format of an SF Information sub-TLV,
>>       included in a CVRep packet, is shown in Figure 11.
>>
>>
>>          SF sub-TLV Type: Two-octets long field.  The value is (5)
>>
>> "Two" -> "one"
>> since the first word after the colon is not capitalized in any of the cases
>> below it should not be capitalized here or they should all be capitalized.
>>
>>          (Section 10.4).
>>
>>
>>    6.6.4.1.  Multiple SFs as Hops of an SFP
>>
>>       Multiple SFs attached to the same SFF can be the hops of the SFP.
>>       The service indexes of these SFs on thatSFP will be different.
>>       Service function types of these SFs could be different or be the
>>       same.  Information about all SFs MAY be included in the CVRep
>>       message.  Information about each SF MUST be listed as separate SF
>>       Information sub-TLVs in the CVRep message.
>>
>> Suggest adding to the end of the above paragraph: "The same SF can even
>> appear more than once in an SFP with a different service index."
>>
>>
>>    6.6.4.2.  Multiple SFs for load balance
>>
>>       Multiple SFs may be attached to the same SFF to spread the load; in
>>       other words, that means that the particular traffic flow will
>>       traverse only one of these SFs.  These SFs have the same Service
>>       Function Type and Service Index.  For this case, the SF identifiers
>>       and SF ID Type of all these SFs will be listed in the SF Identifiers
>>       field and SF ID Type in a single SF information sub-TLV of the CVRep
>>       message.  The number of these SFs can be calculated using the SF ID
>>       Type and the value of the Length field of the sub-TLV.
>>
>> I found the second half of the above paragraph somewhat confusing.
>> Sounds like the SF ID Type would be included for each of the SFs but
>> their ID Types will all be the same. I suggest replacing the 2nd part
>> of this paragraph after the first two sentences with something like
>> the following:
>>
>>       For this case, the SF ID Type, which must be the same for all of
>>       these SFs, appears once but all of their SF Identifiers will
>>       appear concatenated in the SF Identifier area of the Sub-TLV
>>       (see Figure 11). The number of these SFs can be calculated from
>>       the SF ID Type and the value of the Length field of the sub-TLV.
>>
>>
>>       It is RECOMMENDED that implementations throttle the SFC ping traffic
>>       going to the control plane to mitigate potential Denial-of-Service
>>       attacks.
>>
>> I found the occurrence of "ping" here to be startling. There are two
>> other occurrences of "ping" in this document, both earlier in this
>> Security Considerations section, but in a different context.
>> Otherwise, ping does not occur anywhere else. My guess is that you
>> means SFC Echo Request/Echo Reply. I suggest you use that here instead
>> of "ping". Alternatively, you could make the major change of carefully
>> and prominently defining ping and using it throughout the document.
>>
>>
>>       SFC NSH Echo Request/Reply provides essential OAM functions for
>>       network operators.  SFC NSH Echo Request/Reply is intended to detect
>>       and localize defects in an SFC.  For example, by comparing results of
>>       the trace function in operational and failed states, an operator can
>>       locate the defect, e.g., the connection between SFF1 and SFF2
>>       (Figure 1).  Note that a more specific failure location can be
>>
>> "Note that" -> "After narrowing down a failure to an overlay link,"
>>
>>       determined using OAM tools in the underlay network.  The mechanism
>>       defined in this document can be used on-demand or for periodic
>>       validation of an SFP or RSP.  Because the protocol uses information
>>       in the SFC control plane, an operator must have the ability to
>>       control the frequency of transmitted Echo Request and Reply messages.
>>
>> Assuming I understand the above sentence, how about replacing it with
>> the following:
>>
>>       Because the protocol makes use of the control plane which may
>>       have limited capacity, an operator must be able to rate limit
>>       Echo Request and Echo Reply messages.
>>
>>
>>    10.  IANA Considerations
>>
>> Suggest inserting here:
>>
>>       "The terms used in the IANA Considerations below are intended to
>>       be consistent with [RFC8126]."
>>
>>
>>       [RFC Editor, please update all occurrences of TBA1 with the value
>>       assigned by IANA Action.]
>>
>> The above RFC Editor note is unnecessary and could be deleted.
>>
>>
>>    10.2.  SFC Active OAM
>>
>>       IANA is requested to create a new SFC Active OAM registry.
>>
>> If you are asking IANA to "create" something, the word "new" is
>> redundant. If it wasn't "new", then you would be asking IANA to
>> "change" something, not "create" it. Suggest the following replacement
>> for the above sentence:
>>
>>       IANA is requested to create an SFC Active OAM registry
>>       containing the sub-registries listed below.
>>
>> Do you actually mean "web page" rather than registry? There doesn't
>> seem to be anything in this "registry" other than "sub-registries". Of
>> course, the RFC/IANA terminology for all this is highly inconsistent...
>>
>>
>>    10.2.1.  SFC Active OAM Message Type
>>
>>       IANA is requested to create in the SFC Active OAM registry a new sub-
>>       registry as follows:
>>
>> "new" -> ""
>>
>> So, the problem with the sub-registry below is that the SFC Active OAM
>> Message Type file looks to me like it has only six bits, not 16 bits,
>> so there are only 64 values. Given that, I suggest making it all "IETF
>> Review". You could do something like changing the 2nd half from "First
>> Come First Served" to "Specification Required" but that would require
>> the appointment of experts. I generally favor liberal IANA assignment
>> criterion but, as I say, in this case I think IETF Review might be
>> best.
>>
>>
>>          Sub-registry Name: SFC Active OAM Message Type.
>>
>>          Assignment Policy:
>>
>>          2-32767 IETF Review
>>
>> "23767" -> "31"
>>
>>          32768-65530 First Come First Served
>>
>> -> "32-62"
>>
>> Similar changes in table below with final Reserved value being 63.
>>
>>          Reference: [this document]
>>
>>          +===============+=============================+===============+
>>          | Value         |         Description         | Reference     |
>>          +===============+=============================+===============+
>>          | 0             |           Reserved          | This document |
>>          +---------------+-----------------------------+---------------+
>>          | 1             | SFC Echo Request/Echo Reply | This document |
>>          +---------------+-----------------------------+---------------+
>>          | 2 - 32767     |          Unassigned         | This document |
>>          +---------------+-----------------------------+---------------+
>>          | 32768 - 65530 |          Unassigned         | This document |
>>          +---------------+-----------------------------+---------------+
>>          | 65531 - 65534 |          Unassigned         | This document |
>>          +---------------+-----------------------------+---------------+
>>          | 65535         |           Reserved          | This document |
>>          +---------------+-----------------------------+---------------+
>>
>>                        Table 3: SFC Active OAM Message Type
>>
>>
>>    10.2.2.  SFC Active OAM Header Flags
>>
>>       IANA is requested to create in the SFC Active OAM registry the new
>>
>> "registry the new" -> "Registry the"
>>
>>       sub-registry SFC Active OAM Flags.
>>
>>
>>    10.3.  SFC Echo Request/Echo Reply Parameters
>>
>>       IANA is requested to create a new SFC Echo Request/Echo Reply
>>       Parameters registry.
>>
>> I would put this 10.3 stuff and the 10.4 stuff under the SFC Action
>> OAM registry rather than trying to nest deeper. Depending on how IANA
>> interprets this, it may result in multiple short IANA web pages, which
>> is kind of a pain in my mind. Better to have fewer web pages with more
>> registries per page.
>>
>>
>>    10.3.1.  SFC Echo Request Flags
>>
>>       IANA is requested to create in the SFC Echo Request/Echo Reply
>>       Parameters registry the new sub-registry SFC Echo Request Flags.
>>
>> "new" -> ""
>>
>> I'm not sure what will happen or what you think will happen with IANA
>> web pages / Registries / Sub-Registries"...
>>
>>       This sub-registry tracks the assignment of 16 flags in the SFC Echo
>>       Request Flags field of the SFC Echo Request message.  The flags are
>>       numbered from 0 (most significant bit, transmitted first) to 15.
>>
>>       New entries are assigned by Standards Action.
>>
>>                   +============+=============+===============+
>>                   | Bit Number | Description | Reference     |
>>                   +============+=============+===============+
>>                   | 15-0       |  Unassigned | This document |
>>                   +------------+-------------+---------------+
>>
>>                         Table 5: SFC Echo Request Flags
>>
>>    10.3.2.  SFC Echo Request/Echo Reply Message Types
>>
>>       IANA is requested to create in the SFC Echo Request/Echo Reply
>>       Parameters registry the new sub-registry as follows:
>>
>> "new" -> ""
>>
>>          Sub-registry Name: Message Types
>>
>>          Assignment Policy:
>>
>>          5 - 175 IETF Review
>>
>>          176 - 239 First Come First Served
>>
>>          240 - 251 Experimental
>>
>>          252 - 254 Private Use
>>
>> Delete above two lines.
>>
>> I think "Assignment Policy" normally only lists those ranges for which
>> assignment is possible so doesn't list Private Use or Reserved or
>> Experimental.
>>
>>          Reference: [this document]
>>
>>       +===========+======================================+===============+
>>       | Value     |             Description              | Reference     |
>>       +===========+======================================+===============+
>>       | 0         |               Reserved               | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 1         |           SFC Echo Request           | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 2         |            SFC Echo Reply            | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 3         | SFP Consistency Verification Request | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 4         |  SFP Consistency Verification Reply  | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 5 - 175   |              Unassigned              | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 176 - 239 |              Unassigned              | This document |
>>       +-----------+--------------------------------------+---------------+
>>       | 240 - 251 |              Unassigned              | This document |
>>
>> "Unassigned" - "Experimental"
>>
>>       +-----------+--------------------------------------+---------------+
>>       | 252 - 254 |              Unassigned              | This document |
>>
>> "Unassigned" -> "Private Use"
>>
>>       +-----------+--------------------------------------+---------------+
>>       | 255       |               Reserved               | This document |
>>       +-----------+--------------------------------------+---------------+
>>
>>                Table 6: SFC Echo Request/Echo Reply Message Types
>>
>>    10.3.3.  SFC Echo Reply Modes
>>
>>       IANA is requested to create in the SFC Echo Request/Echo Reply
>>       Parameters registry the new sub-registry as follows:
>>
>>          Sub-registry Name: Reply Mode
>>
>>          Assignment Policy:
>>
>>
>>
>>    Mirsky, et al.           Expires 10 January 2023               [Page 28]
>>
>>    Internet-Draft             Active OAM for SFC                  July 2022
>>
>>
>>          8 - 175 IETF Review
>>
>>          176 - 239 First Come First Served
>>
>>          240 - 251 Experimental
>>
>>          252 - 254 Private Use
>>
>> Delete above two lines.
>>
>> I think "Assignment Policy" normally only lists those ranges for which
>> assignment is possible so doesn't list Private Use or Reserved or
>> Experimental.
>>
>>          Reference: [this document]
>>
>>
>>          +=======+====================================+===============+
>>          | Value |            Description             | Reference     |
>>          +=======+====================================+===============+
>>          | 0     |              Reserved              | This document |
>>          +-------+------------------------------------+---------------+
>>          | 1     |            Do Not Reply            | This document |
>>          +-------+------------------------------------+---------------+
>>          | 2     | Reply via an IPv4/IPv6 UDP Packet  | This document |
>>          +-------+------------------------------------+---------------+
>>          | 3     |    Reply via Application-Level     | This document |
>>          |       |          Control Channel           |               |
>>          +-------+------------------------------------+---------------+
>>          | 4     |      Reply via Specified Path      | This document |
>>          +-------+------------------------------------+---------------+
>>          | 5     | Reply via an IPv4/IPv6 UDP Packet  | This document |
>>          |       | with the data integrity protection |               |
>>          +-------+------------------------------------+---------------+
>>          | 6     |    Reply via Application-Level     | This document |
>>          |       |   Control Channel with the data    |               |
>>          |       |        integrity protection        |               |
>>          +-------+------------------------------------+---------------+
>>          | 7     | Reply via Specified Path with the  | This document |
>>          |       |     data integrity protection      |               |
>>          +-------+------------------------------------+---------------+
>>          | 8 -   |             Unassigned             | IETF Review   |
>>
>> "IETF Review" -> "This document"
>>
>>          | 175   |                                    |               |
>>          +-------+------------------------------------+---------------+
>>          | 176 - |             Unassigned             | First Come    |
>>          | 239   |                                    | First Served  |
>>
>> "First Come First Served" -> "This document"
>>
>>          +-------+------------------------------------+---------------+
>>
>> In both entries below, "Description" column should have value
>> currently in the "Reference" column and the "Reference" column should
>> say "This document".
>>
>>          | 240 - |             Unassigned             | Experimental  |
>>          | 251   |                                    |               |
>>          +-------+------------------------------------+---------------+
>>          | 252 - |             Unassigned             | Private Use   |
>>          | 254   |                                    |               |
>>          +-------+------------------------------------+---------------+
>>          | 255   |              Reserved              | This document |
>>          +-------+------------------------------------+---------------+
>>
>>                           Table 7: SFC Echo Reply Mode
>>
>>    10.3.4.  SFC Echo Return Codes
>>
>>       IANA is requested to create in the SFC Echo Request/Echo Reply
>>       Parameters registry the new sub-registry as follows:
>>
>> "new" -> ""
>>
>>          Sub-registry Name: Return Codes
>>
>>          Assignment Policy:
>>
>>          9 - 191 IETF Review
>>
>>          192 - 251 First Come First Served
>>
>>          252 - 254 Private Use
>>
>> Delete above line.
>>
>> I think "Assignment Policy" normally only lists those ranges for which
>> assignment is possible so doesn't list Private Use or Reserved or
>> Experimental.
>>
>>          Reference: [this document]
>>
>>           +=========+=================================+===============+
>>           | Value   |           Description           | Reference     |
>>           +=========+=================================+===============+
>>           | 0       |          No Return Code         | This document |
>>           +---------+---------------------------------+---------------+
>>           | 1       | Malformed Echo Request received | This document |
>>           +---------+---------------------------------+---------------+
>>           | 2       | One or more of the TLVs was not | This document |
>>           |         |            understood           |               |
>>           +---------+---------------------------------+---------------+
>>           | 3       |      Authentication failed      | This document |
>>           +---------+---------------------------------+---------------+
>>           | 4       |           TTL Exceeded          | This document |
>>           +---------+---------------------------------+---------------+
>>           | 5       |          End of the SFP         | This document |
>>           +---------+---------------------------------+---------------+
>>           | 6       | Reply Path TLV is missing       | This document |
>>           +---------+---------------------------------+---------------+
>>           | 7       | Reply SFP was not found         | This document |
>>           +---------+---------------------------------+---------------+
>>           | 8       | Unverifiable Reply Path         | This document |
>>           +---------+---------------------------------+---------------+
>>           | 9 -191  |            Unassigned           | This document |
>>           +---------+---------------------------------+---------------+
>>           | 192-251 |            Unassigned           | This document |
>>           +---------+---------------------------------+---------------+
>>           | 252-254 |            Unassigned           | This document |
>>
>> "Unassigned" -> "Private Use"
>>
>>           +---------+---------------------------------+---------------+
>>           | 255     |             Reserved            | This document |
>>           +---------+---------------------------------+---------------+
>>
>>                           Table 8: SFC Echo Return Codes
>>
>>    10.4.  SFC Active OAM TLV Type
>>
>>       IANA is requested to create the new registry as follows:
>>
>>          Registry Name: SFC Active OAM TLV Type
>>          Assignment Policy:
>>
>>          6 -175 IETF Review
>>
>>          176 - 239 First Come First Served
>>
>>          240 - 251 Experimental
>>
>>          252 - 254 Private Use
>>
>> Delete above two lines.
>>
>> I think "Assignment Policy" normally only lists those ranges for which
>> assignment is possible so doesn't list Private Use or Reserved or
>> Experimental.
>>
>>          Reference: [this document]
>>
>>            +===========+=============================+===============+
>>            | Value     |         Description         | Reference     |
>>            +===========+=============================+===============+
>>            | 0         |           Reserved          | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 1         |        Source ID TLV        | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 2         |         Errored TLVs        | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 3         | SFC Reply Path Type         | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 4         | SFF Information Record Type | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 5         |        SF Information       | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 6 - 175   |          Unassigned         | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 176 - 239 |          Unassigned         | This document |
>>            +-----------+-----------------------------+---------------+
>>            | 240 - 251 |          Unassigned         | This document |
>>
>> "Unassigned" -> "Experimental"
>>
>>            +-----------+-----------------------------+---------------+
>>            | 252 - 254 |          Unassigned         | This document |
>>
>> "Unassigned" -> "Private Use"
>>
>>            +-----------+-----------------------------+---------------+
>>            | 255       |           Reserved          | This document |
>>            +-----------+-----------------------------+---------------+
>>
>>                     Table 9: SFC Active OAM TLV Type Registry
>>
>>    10.5.  SF Identifier Types
>>
>>       IANA is requested to create in the SF Types registry the new sub-
>>       registry as follows:
>>
>> "new" -> ""
>>
>>          Registry Name: SF Identifier Types
>>
>>          Assignment Policy:
>>
>>
>>
>>    Mirsky, et al.           Expires 10 January 2023               [Page 32]
>>
>>    Internet-Draft             Active OAM for SFC                  July 2022
>>
>>
>>          4 -191 IETF Review
>>
>>          192 - 251 First Come First Served
>>
>>          252 - 254 Private Use
>>
>> delete above line.
>>
>> I think "Assignment Policy" nomrally only lists those ranges for which
>> assignment is possible so doesn't list Private Use or Reserved or
>> Experimenal.
>>
>>          Reference: [this document]
>>
>>                     +=========+=============+===============+
>>                     | Value   | Description | Reference     |
>>                     +=========+=============+===============+
>>                     | 0       |   Reserved  | This document |
>>                     +---------+-------------+---------------+
>>                     | 1       |     IPv4    | This document |
>>                     +---------+-------------+---------------+
>>                     | 2       |     IPv6    | This document |
>>                     +---------+-------------+---------------+
>>                     | 3       |     MAC     | This document |
>>                     +---------+-------------+---------------+
>>                     | 4 -191  |  Unassigned | This document |
>>                     +---------+-------------+---------------+
>>                     | 192-251 |  Unassigned | This document |
>>                     +---------+-------------+---------------+
>>                     | 252-254 |  Unassigned | This document |
>>
>> "Unassigned" -> "Private Use"
>>
>>                     +---------+-------------+---------------+
>>                     | 255     |   Reserved  | This document |
>>                     +---------+-------------+---------------+
>>
>>                            Table 10: SF Identifier Type
>>
>>
>>    11.2.  Informative References
>>
>>  Add Informative References [RFC4086] and [RFC8126].
>>
>> Thanks,
>> Donald
>> ===============================
>>  Donald E. Eastlake 3rd   [phone] (cell)
>>  2386 Panoramic Circle, Apopka, FL 32703 USA
>>  [e-mail]