[auth48] [IANA #1288304] [IANA] Re: [E] AUTH48: RFC-to-be 9516 <draft-ietf-sfc-multi-layer-oam-28> for your review
David Dong via RT <iana-matrix@iana.org> Thu, 16 November 2023 00:20 UTC
Return-Path: <iana-shared@icann.org>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F02B0C1516F8; Wed, 15 Nov 2023 16:20:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.658
X-Spam-Level:
X-Spam-Status: No, score=-1.658 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YDaOgN10HqwE; Wed, 15 Nov 2023 16:20:32 -0800 (PST)
Received: from smtp.lax.icann.org (smtp.lax.icann.org [IPv6:2620:0:2d0:201::1:81]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7995CC151095; Wed, 15 Nov 2023 16:20:32 -0800 (PST)
Received: from request6.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp.lax.icann.org (Postfix) with ESMTP id 502A1E2333; Thu, 16 Nov 2023 00:20:32 +0000 (UTC)
Received: by request6.lax.icann.org (Postfix, from userid 48) id 4D30952F35; Thu, 16 Nov 2023 00:20:32 +0000 (UTC)
RT-Owner: david.dong
From: David Dong via RT <iana-matrix@iana.org>
Reply-To: iana-matrix@iana.org
In-Reply-To: <CB58490C-96AE-4550-8849-197A0DA3A4FF@amsl.com>
References: <RT-Ticket-1288304@icann.org> <20231030225651.59525E7C06@rfcpa.amsl.com> <22CB735B-402E-47A0-A117-B8EAE8E77DB2@amsl.com> <CANtnpwjW-WzR6ZXuDDiM9Pgqb5H7H2JM5Zkf_C7iiL+uJWzEBg@mail.gmail.com> <12DE609C-ACF7-4C25-A9AE-7BB20FCD232A@amsl.com> <CAJhXr9-JzOwKOTEt-oi+tvYBpqi28nv0boqsWmwJrYGS4UD8Ew@mail.gmail.com> <389E0EC4-4453-4234-91C9-D7F36F60DD35@amsl.com> <442EC8FD-0926-40A8-A387-5EAC4A6B5DD2@amsl.com> <CB58490C-96AE-4550-8849-197A0DA3A4FF@amsl.com>
Message-ID: <rt-5.0.3-842023-1700094032-952.1288304-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1288304
X-Managed-BY: RT 5.0.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: david.dong@iana.org
To: apaloma@amsl.com
CC: vumip1@gmail.com, sfc-chairs@ietf.org, sfc-ads@ietf.org, rfc-editor@rfc-editor.org, meng.wei2@zte.com.cn, mail4kentl@gmail.com, iana@iana.org, gyan.s.mishra@verizon.com, gregimirsky@gmail.com, donald.eastlake@futurewei.com, auth48archive@rfc-editor.org, andrew-ietf@liquid.tech, 18555817@qq.com
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Thu, 16 Nov 2023 00:20:32 +0000
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/cOiQJM7GMZkOSn_1fy_u1kN9FFQ>
Subject: [auth48] [IANA #1288304] [IANA] Re: [E] AUTH48: RFC-to-be 9516 <draft-ietf-sfc-multi-layer-oam-28> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Thu, 16 Nov 2023 00:20:37 -0000
Hi Alanna, This change is complete. Please see: https://www.iana.org/assignments/sfc-active-oam/ Best regards, David Dong IANA Services Sr. Specialist On Tue Nov 14 19:18:08 2023, apaloma@amsl.com wrote: > IANA, > > Please update your registries as follows to match the edited document > at https://www.rfc-editor.org/authors/rfc9516-diff.html. > > 1) Please update the Description column for Value 1 in the “SFC Active > OAM Message Type” registry <https://www.iana.org/assignments/sfc- > active-oam/sfc-active-oam.xhtml#sfc-active-oam> to remove the second > “Echo". > > Old: > SFC Echo Request/Echo Reply > > New: > SFC Echo Request/Reply > > 2) Please update the titles of the "SFC Active OAM Message Type” > registry <https://www.iana.org/assignments/sfc-active-oam/sfc-active- > oam.xhtml#sfc-active-oam> and the "SFC Active OAM TLV Type” registry > <https://www.iana.org/assignments/sfc-active-oam/sfc-active- > oam.xhtml#sfc-active-tlv> to make “Type” plural in both. > > Old: > SFC Active OAM Message Type > SFC Active OAM TLV Type > > New: > SFC Active OAM Message Types > SFC Active OAM TLV Types > > Best regards, > RFC Editor/ap > > > On Nov 14, 2023, at 11:12 AM, Alanna Paloma <apaloma@amsl.com> wrote: > > > > Authors, > > > > Approvals from each author have been noted on the AUTH48 status page: > > https://www.rfc-editor.org/auth48/rfc9516 > > > > We will now ask IANA to update their registry accordingly. After the > > IANA updates are complete, we will move forward with the publication > > process. > > > > Thank you, > > RFC Editor/ap > > > >> On Nov 14, 2023, at 8:43 AM, Alanna Paloma <apaloma@amsl.com> wrote: > >> > >> Hi Gyan, > >> > >> We have noted your approval on the AUTH48 status page: > >> https://www.rfc-editor.org/auth48/rfc9516 > >> > >> Thank you, > >> RFC Editor/ap > >> > >>> On Nov 13, 2023, at 11:35 AM, Mishra, Gyan S > >>> <gyan.s.mishra@verizon.com> wrote: > >>> > >>> > >>> Thank you Alanna. > >>> > >>> I agree with all the updates and changes. > >>> > >>> Kind Regards > >>> > >>> Gyan > >>> > >>> On Mon, Nov 13, 2023 at 11:40 AM Alanna Paloma <apaloma@amsl.com> > >>> wrote: > >>> Hi Bhumip, > >>> > >>> Your approval has been noted on the AUTH48 status page: > >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>> 2Deditor.org_auth48_rfc9516&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=d1PVySlxRqgwlM4XX4RardCecD_rXvNJNh5woXgeX9k&e= > >>> > >>> We will await approvals from Ting and Gyan. > >>> > >>> Thank you, > >>> RFC Editor/ap > >>> > >>>> On Nov 11, 2023, at 12:19 PM, B. Khasnabish <vumip1@gmail.com> > >>>> wrote: > >>>> > >>>> > >>>> > >>>> Thank you Alanna. Yes, agree with the updates/changes. > >>>> > >>>> Once again, many Thanks in advance. > >>>> > >>>> Best Regards, > >>>> > >>>> Bhumip > >>>> ----------------------------------------------------------------------------------------- > >>>> > >>>> Bhumip Khasnabish | +1-781-752-8003 (m) > >>>> vumip1@gmail.com > >>>> > >>>> :: > >>>> > >>>> On Mon, Nov 6, 2023 at 4:49 PM Alanna Paloma <apaloma@amsl.com> > >>>> wrote: > >>>> Greetings, > >>>> > >>>> We do not believe we have heard from you regarding this document's > >>>> readiness for publication. Please review our previous messages > >>>> describing the AUTH48 process and containing any document-specific > >>>> questions we may have had. > >>>> > >>>> We will wait to hear from you before continuing with the > >>>> publication process. > >>>> > >>>> The AUTH48 status page for this document is located here: > >>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>> 2Deditor.org_auth48_rfc9516&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=d1PVySlxRqgwlM4XX4RardCecD_rXvNJNh5woXgeX9k&e= > >>>> > >>>> Thank you, > >>>> RFC Editor/ap > >>>> > >>>> > >>>>> On Oct 30, 2023, at 3:56 PM, rfc-editor@rfc-editor.org wrote: > >>>>> > >>>>> Authors, > >>>>> > >>>>> While reviewing this document during AUTH48, please resolve (as > >>>>> necessary) the following questions, which are also in the XML > >>>>> file. > >>>>> > >>>>> 1) <!--[rfced] Please note the title of the document has been > >>>>> updated as > >>>>> follows. Abbreviations have been expanded per Section 3.6 of RFC > >>>>> 7322 > >>>>> ("RFC Style Guide"). Please review. > >>>>> > >>>>> Original: > >>>>> Active OAM for Service Function Chaining (SFC) > >>>>> > >>>>> Current: > >>>>> Active Operations, Administration, and Maintenance (OAM) for > >>>>> Service > >>>>> Function Chaining (SFC) > >>>>> --> > >>>>> > >>>>> > >>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that > >>>>> appear in the > >>>>> title) for use on > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_search&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=MrZDy9pnR_eo2r- > >>>>> EZc4L_6cvsCbAiB_hrwt29m6aFCU&e= . --> > >>>>> > >>>>> > >>>>> 3) <!--[rfced] We do not see "Performance Monitoring OAM" > >>>>> mentioned in RFC > >>>>> 8924. Please let us know if/how this citation should be updated. > >>>>> > >>>>> Additionally, "as a requirement" is unclear. May we update the > >>>>> sentence as > >>>>> follows? > >>>>> > >>>>> Original: > >>>>> Note that > >>>>> Performance Monitoring OAM, as mentioned in [RFC8924], as a > >>>>> requirement, is not satisfied by this document and is out of > >>>>> scope. > >>>>> > >>>>> Perhaps: > >>>>> Note that > >>>>> Performance Monitoring OAM, as required by [RFC8924], > >>>>> is not satisfied by this document and is out of scope. > >>>>> --> > >>>>> > >>>>> > >>>>> 4) <!--[rfced] Should the terms in Section 2.2 be listed in > >>>>> alphabetical > >>>>> order? --> > >>>>> > >>>>> > >>>>> 5) <!-- [rfced] Please confirm that references to Section 6.5.4 > >>>>> for SFF > >>>>> traceroute are correct, as we don't see mention of SFF or Service > >>>>> Function > >>>>> Forwarders in that section. Perhaps "SFF traceroute" should be > >>>>> "SFP > >>>>> tracing"? Please let us know if any updates are neeeded. > >>>>> > >>>>> Original: > >>>>> * REQ#2: Continuity monitoring via the SFF traceroute defined in > >>>>> Section 6.5.4 ("Tracing an SFP "). > >>>>> > >>>>> * REQ#4: Connectivity verification via the SFF traceroute > >>>>> (Section 6.5.4). > >>>>> --> > >>>>> > >>>>> > >>>>> 6) <!-- [rfced] We have updated the following 2 instances of > >>>>> "Active SFC > >>>>> OAM" to "SFC Active OAM" to match the description in the IANA > >>>>> registry. > >>>>> Please let us know if any updates are needed. > >>>>> > >>>>> Original: > >>>>> To identify the active SFC > >>>>> OAM message, the "Next Protocol" field MUST be set to Active SFC > >>>>> OAM > >>>>> (TBA1) (Section 10.1). ... A case when the O bit is clear and the > >>>>> "Next Protocol" field value is set to Active SFC OAM (TBA1) is > >>>>> considered an erroneous combination. > >>>>> > >>>>> We note that Figure 2 includes a "SFC Active OAM Control Packet" > >>>>> field, but > >>>>> the section title is "Active SFC OAM Header" - should the section > >>>>> title be > >>>>> SFC Active OAM Header? > >>>>> > >>>>> Original: > >>>>> 5. Active SFC OAM Header > >>>>> > >>>>> Perhaps: > >>>>> 5. SFC Active OAM Header > >>>>> > >>>>> > >>>>> In addition, the term appears inconsistently throughout the > >>>>> document. > >>>>> Please review and let us know how/if these may be updated for > >>>>> consistency. > >>>>> > >>>>> active SFC OAM vs Active SFC OAM (capitalization) > >>>>> SFC active OAM vs SFC Active OAM (capitalization) > >>>>> active SFC OAM vs SFC active OAM (location of "active") > >>>>> --> > >>>>> > >>>>> > >>>>> 7) <!--[rfced] We see a number of author-inserted comments in the > >>>>> .xml file > >>>>> for this document. We are unsure if these have been resolved. > >>>>> Please review > >>>>> and let us know if these can be deleted or if they need to be > >>>>> addressed. > >>>>> --> > >>>>> > >>>>> > >>>>> 8) <!--[rfced] In Section 6.4.1, should "Errored TLVs Type" be > >>>>> "Errored > >>>>> TLVs" to match the field in Figure 6? > >>>>> > >>>>> Original: > >>>>> The Errored TLVs Type <bcp14>MUST</bcp14> be set to 2 (Section > >>>>> 10.4). > >>>>> > >>>>> Perhaps: > >>>>> Errored TLVs - <bcp14>MUST</bcp14> be set to 2 (Section 10.4). > >>>>> --> > >>>>> > >>>>> > >>>>> 9) <!--[rfced] We are having some trouble parsing "information on > >>>>> the > >>>>> actual path the CVReq packet has traveled". Is this meant to > >>>>> described the > >>>>> information that is collected? > >>>>> > >>>>> Original: > >>>>> As a result, the ingress SFF collects information about all > >>>>> traversed > >>>>> SFFs and SFs, information on the actual path the CVReq packet has > >>>>> traveled. > >>>>> > >>>>> Perhaps: > >>>>> As a result, the ingress SFF collects information about all > >>>>> traversed > >>>>> SFFs and SFs, i.e., information on the actual path the CVReq > >>>>> packet has > >>>>> traveled. > >>>>> --> > >>>>> > >>>>> > >>>>> 10) <!--[rfced] There are no definitions for the "Length" and "SF > >>>>> Information Sub-TLV" fields in Figure 9. Should ones be added? If > >>>>> so, > >>>>> please provide text. > >>>>> --> > >>>>> > >>>>> > >>>>> 11) <!--[rfced] In Section 6.6.2, should "SF sub-TLV Type" be "SF > >>>>> Sub-TLV" > >>>>> to match the field in Figure 10? > >>>>> > >>>>> Original: > >>>>> SF sub-TLV Type: one-octet long field. The value is (5) > >>>>> (Section 10.4). > >>>>> > >>>>> Perhaps: > >>>>> SF Sub-TLV : one-octet field. The value is (5) (Section 10.4). > >>>>> --> > >>>>> > >>>>> > >>>>> 12) <!--[rfced] To clarify, does "their" refer to the "SF ID > >>>>> Type"? If so, > >>>>> may we update "their" to "its"? > >>>>> > >>>>> Original: > >>>>> 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 10). > >>>>> > >>>>> Perhaps: > >>>>> For this case, the SF ID Type, > >>>>> which must be the same for all of these SFs, appears once but all > >>>>> of > >>>>> its SF Identifiers will appear concatenated in the SF Identifier > >>>>> area of the sub-TLV (see Figure 10). > >>>>> --> > >>>>> > >>>>> > >>>>> 13) <!-- [rfced] Should the section title and registry title be > >>>>> plural > >>>>> (i.e., s/Type/Types)? > >>>>> > >>>>> Perhaps: > >>>>> SFC Active OAM Message Types > >>>>> --> > >>>>> > >>>>> > >>>>> 14) <!-- [rfced] The IETF Review range has been updated to > >>>>> specify 0-31, to > >>>>> match what appears in the IANA registry. See > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive-2Doam_sfc-2Dactive- > >>>>> 2Doam.xhtml-23sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=RyG6sFnf- > >>>>> gTI3NHNlba6gI8mMkn25eU-LxlC2UNilwA&e= . > >>>>> > >>>>> Original: > >>>>> 2-31 IETF Review > >>>>> --> > >>>>> > >>>>> > >>>>> 15) <!-- [rfced] May we update instances of "Echo Request/Echo > >>>>> Reply" to be > >>>>> "Echo Request/Reply" throughout the document, including the IANA- > >>>>> related > >>>>> text, to align with text in Section 2? > >>>>> > >>>>> From Section 2: > >>>>> In this document, "Echo Request/Reply" and > >>>>> "SFC Echo > >>>>> Request/Reply" are used interchangeably. > >>>>> > >>>>> For example, this is the current IANA-related text from Table 2: > >>>>> | 1 | SFC Echo Request/Echo Reply | RFC 9516 | > >>>>> > >>>>> Perhaps: > >>>>> | 1 | SFC Echo Request/Reply | RFC 9516 | > >>>>> --> > >>>>> > >>>>> > >>>>> 16) <!-- [rfced] Note that these two rows have been combined to > >>>>> match what > >>>>> appears in the IANA registry: > >>>>> > >>>>> Original: > >>>>> | 2 - 31 | Unassigned | This document | > >>>>> | 32-62 | Unassigned | This document | > >>>>> > >>>>> Current: > >>>>> | 2 - 62 | Unassigned | | > >>>>> --> > >>>>> > >>>>> > >>>>> 17) <!-- [rfced] We do not see an "SFC Echo Request/Echo Reply > >>>>> Parameters" > >>>>> registry within the "Service Function Chaining (SFC) Active > >>>>> Operations, > >>>>> Administration, and Maintenance (OAM)" registry. Based on the > >>>>> IANA > >>>>> actions, we believe the intent is for registries defined in > >>>>> sections 10.3.1 > >>>>> - 10.3.4, 10.4, and 10.5 (in the I-D) to be created within the > >>>>> "Service > >>>>> Function Chaining (SFC) Active Operations, Administration, and > >>>>> Maintenance > >>>>> (OAM)" registry - we have updated the text accordingly (including > >>>>> removing > >>>>> Section 10.3). Please review the updates carefully and let us > >>>>> know any > >>>>> objections. > >>>>> > >>>>> From IANA: > >>>>> We've created the following registries and placed them in the > >>>>> "Service > >>>>> Function Chaining (SFC) Active Operations, Administration, and > >>>>> Maintenance > >>>>> (OAM)" registry group: > >>>>> > >>>>> SFC Active OAM Message Type > >>>>> SFC Echo Request Flags > >>>>> SFC Echo Types > >>>>> SFC Echo Reply Modes > >>>>> SFC Echo Return Codes > >>>>> SFC Active OAM TLV Type > >>>>> SF Identifier Types > >>>>> > >>>>> Please see https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= for the list of > >>>>> registrations and procedures. > >>>>> --> > >>>>> > >>>>> > >>>>> 18) <!-- [rfced] Section 9.2.3. SFC Echo Types > >>>>> > >>>>> Note that the IETF Review range has been updated to reflect what > >>>>> appears in > >>>>> the IANA registry. > >>>>> > >>>>> The following ranges were commented out in the XML, but they > >>>>> appear in the > >>>>> IANA registry. > >>>>> > >>>>> 240-251 Experimental Use > >>>>> 252-254 Private Use > >>>>> > >>>>> We have re-added the ranges to the Assignment Policy, as the > >>>>> ranges appear > >>>>> in the IANA registry and the table below. Please review and let > >>>>> us know > >>>>> whether these ranges are valid or if they should be removed from > >>>>> the IANA > >>>>> registry. > >>>>> See <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= >. > >>>>> > >>>>> Note that these rows have been combined to match what appears in > >>>>> the IANA > >>>>> registry. > >>>>> > >>>>> | 5 - 175 | Unassigned | | > >>>>> | 176 - 239 | Unassigned | | > >>>>> > >>>>> Current: > >>>>> | 5 - 239 | Unassigned | | > >>>>> --> > >>>>> > >>>>> > >>>>> 19) <!-- [rfced] Section 9.2.4. SFC Echo Reply Modes > >>>>> > >>>>> Similar to what was done for Section 9.2.3, the IETF Review range > >>>>> has been > >>>>> updated to reflect what appears in the IANA registry. > >>>>> > >>>>> The following ranges were commented out in the XML, but they > >>>>> appear in the > >>>>> IANA registry. > >>>>> > >>>>> 240 - 251 Experimental > >>>>> 252 - 254 Private Use > >>>>> > >>>>> We have re-added the ranges to the Assignment Policy, as the > >>>>> ranges appear > >>>>> in the IANA registry and the table below. Please review and let > >>>>> us know > >>>>> whether these ranges are valid or if they should be removed from > >>>>> the IANA > >>>>> registry. > >>>>> See <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= >. > >>>>> > >>>>> Note that these rows have been combined to match what appears in > >>>>> the IANA > >>>>> registry. > >>>>> > >>>>> | 8 - | Unassigned | | > >>>>> | 175 | > >>>>> | | > >>>>> | 176 - | Unassigned > >>>>> | | > >>>>> | 239 | > >>>>> | | > >>>>> > >>>>> --> > >>>>> > >>>>> > >>>>> 20) <!-- [rfced] Section 9.2.5. SFC Echo Return Codes > >>>>> > >>>>> Similar to above, the IETF Review range has been updated to > >>>>> reflect what > >>>>> appears in the IANA registry. > >>>>> > >>>>> The following range was commented out in the XML, but it appears > >>>>> in the > >>>>> IANA registry. > >>>>> > >>>>> 252 - 254 Private Use > >>>>> > >>>>> We have re-added the range to the Assignment Policy, as the range > >>>>> appears > >>>>> in the IANA registry and the table below. Please review and let > >>>>> us know > >>>>> whether the range is valid or if it should be removed from the > >>>>> IANA > >>>>> registry. > >>>>> See <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= >. > >>>>> > >>>>> > >>>>> Note that these rows have been combined to match what appears in > >>>>> the IANA > >>>>> registry. > >>>>> > >>>>> | 9 -191 | Unassigned | > >>>>> | > >>>>> | 192-251 | Unassigned | > >>>>> | > >>>>> --> > >>>>> > >>>>> > >>>>> 21) <!-- [rfced] 9.2.6. SFC Active OAM TLV Type > >>>>> > >>>>> Should the registry and section title be plural (i.e., > >>>>> s/Type/Types)? > >>>>> > >>>>> Note that the IETF Review range has been updated to reflect what > >>>>> appears in > >>>>> the IANA registry. > >>>>> > >>>>> The following ranges were commented out in the XML, but they > >>>>> appear in the > >>>>> IANA registry. > >>>>> 240 - 251 Experimental > >>>>> 252 - 254 Private Use > >>>>> > >>>>> We have re-added the ranges to the Assignment Policy, as the > >>>>> ranges appear > >>>>> in the IANA registry and the table below. Please review and let > >>>>> us know > >>>>> whether these ranges are valid or if they should be removed from > >>>>> the IANA > >>>>> registry. > >>>>> See <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= >. > >>>>> > >>>>> Note that these rows have been combined to match what appears in > >>>>> the IANA > >>>>> registry. > >>>>> > >>>>> | 6 - 175 | Unassigned | | > >>>>> | 176 - 239 | Unassigned | | > >>>>> --> > >>>>> > >>>>> > >>>>> 22) <!--[rfced] 9.2.7. SF Identifier Types > >>>>> > >>>>> FYI, as no SF Types registry is mentioned in RFC 9263, we have > >>>>> removed the citation from the sentence below. > >>>>> > >>>>> Original: > >>>>> IANA is requested to create in the SF Types registry [RFC9263] > >>>>> the > >>>>> sub-registry as follows: > >>>>> > >>>>> > >>>>> Similar to above, the IETF Review range has been updated to > >>>>> reflect what > >>>>> appears in the IANA registry. > >>>>> > >>>>> The following range was commented out in the XML, but it appears > >>>>> in the > >>>>> IANA registry. > >>>>> > >>>>> 252 - 254 Private Use > >>>>> > >>>>> We have re-added the range to the Assignment Policy, as the range > >>>>> appears > >>>>> in the IANA registry and the table below. Please review and let > >>>>> us know > >>>>> whether the range is valid or if it should be removed from the > >>>>> IANA > >>>>> registry. > >>>>> See <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__www.iana.org_assignments_sfc-2Dactive- > >>>>> 2Doam&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=eDzoSXrU7nyC- > >>>>> sdHVKSu6INdKgCzJV_g_tZu2HJ4-BY&e= >. > >>>>> > >>>>> > >>>>> Note that these rows have been combined to match what appears in > >>>>> the IANA > >>>>> registry. > >>>>> > >>>>> | 4 -191 | Unassigned | | > >>>>> | 192-251 | Unassigned | | > >>>>> --> > >>>>> > >>>>> > >>>>> 23) <!-- [rfced] Throughout the text, the following terminology > >>>>> appears to > >>>>> be used inconsistently. May we update to use the latter ? > >>>>> > >>>>> performance monitoring vs. Performance Monitoring > >>>>> Echo Request/Echo Reply vs. Echo Request/Reply > >>>>> > >>>>> --> > >>>>> > >>>>> > >>>>> 24) <!-- [rfced] Acronyms > >>>>> > >>>>> a) "SFC" has been expanded as both "Service Function Chain" and > >>>>> "Service > >>>>> Function Chaining" in this document. We have updated to use the > >>>>> latter to > >>>>> parallel the use in the other documents from Cluster C479 (RFCs > >>>>> 9451 and > >>>>> 9452). Note that instances of "service function chain" > >>>>> (lowercased) have > >>>>> been left as is. Please let us know of any objections. > >>>>> > >>>>> b) FYI - We have expanded the following abbreviation > >>>>> per Section 3.6 of RFC 7322 ("RFC Style Guide"). Please review > >>>>> each > >>>>> expansion in the document carefully to ensure correctness. > >>>>> > >>>>> Label Switched Path (LSP) > >>>>> --> > >>>>> > >>>>> > >>>>> 25) <!-- [rfced] Please review the "Inclusive Language" portion > >>>>> of the > >>>>> online Style Guide > >>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_styleguide_part2_-23inclusive- > >>>>> 5Flanguage&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=sOKdAnlc1- > >>>>> cS-S21kq0BfKhEuWPtH5F-Jtm-6BEwBL8&e= > > >>>>> and let us know if any changes are needed. > >>>>> > >>>>> For example, please consider whether "sanity" should be updated. > >>>>> --> > >>>>> > >>>>> > >>>>> Thank you. > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> On Oct 30, 2023, at 1:52 PM, rfc-editor@rfc-editor.org wrote: > >>>>> > >>>>> *****IMPORTANT***** > >>>>> > >>>>> Updated 2023/10/30 > >>>>> > >>>>> RFC Author(s): > >>>>> -------------- > >>>>> > >>>>> Instructions for Completing AUTH48 > >>>>> > >>>>> Your document has now entered AUTH48. Once it has been reviewed > >>>>> and > >>>>> approved by you and all coauthors, it will be published as an > >>>>> RFC. > >>>>> If an author is no longer available, there are several remedies > >>>>> available as listed in the FAQ > >>>>> (https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_faq_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=8v7Qy1AZMoPG0P3WfkOXz4cDC8amHutrv61vQPUw- > >>>>> x4&e= ). > >>>>> > >>>>> You and you coauthors are responsible for engaging other parties > >>>>> (e.g., Contributors or Working Group) as necessary before > >>>>> providing > >>>>> your approval. > >>>>> > >>>>> Planning your review > >>>>> --------------------- > >>>>> > >>>>> Please review the following aspects of your document: > >>>>> > >>>>> * RFC Editor questions > >>>>> > >>>>> Please review and resolve any questions raised by the RFC Editor > >>>>> that have been included in the XML file as comments marked as > >>>>> follows: > >>>>> > >>>>> <!-- [rfced] ... --> > >>>>> > >>>>> These questions will also be sent in a subsequent email. > >>>>> > >>>>> * Changes submitted by coauthors > >>>>> > >>>>> Please ensure that you review any changes submitted by your > >>>>> coauthors. We assume that if you do not speak up that you > >>>>> agree to changes submitted by your coauthors. > >>>>> > >>>>> * Content > >>>>> > >>>>> Please review the full content of the document, as this cannot > >>>>> change once the RFC is published. Please pay particular > >>>>> attention to: > >>>>> - IANA considerations updates (if applicable) > >>>>> - contact information > >>>>> - references > >>>>> > >>>>> * Copyright notices and legends > >>>>> > >>>>> Please review the copyright notice and legends as defined in > >>>>> RFC 5378 and the Trust Legal Provisions > >>>>> (TLP – https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__trustee.ietf.org_license- > >>>>> 2Dinfo_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=- > >>>>> IsSl7vbTAlQn0KKIYTQQMAKRu2gfENRsI_d4fOD5RM&e= ). > >>>>> > >>>>> * Semantic markup > >>>>> > >>>>> Please review the markup in the XML file to ensure that elements > >>>>> of > >>>>> content are correctly tagged. For example, ensure that > >>>>> <sourcecode> > >>>>> and <artwork> are set correctly. See details at > >>>>> <https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__authors.ietf.org_rfcxml- > >>>>> 2Dvocabulary&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=8giPwx48JpY7nx83B3gEke0Ds_ch51r2RcGtrb8DSLU&e= > >>>>> >. > >>>>> > >>>>> * Formatted output > >>>>> > >>>>> Please review the PDF, HTML, and TXT files to ensure that the > >>>>> formatted output, as generated from the markup in the XML file, > >>>>> is > >>>>> reasonable. Please note that the TXT will have formatting > >>>>> limitations compared to the PDF and HTML. > >>>>> > >>>>> > >>>>> Submitting changes > >>>>> ------------------ > >>>>> > >>>>> To submit changes, please reply to this email using ‘REPLY ALL’ > >>>>> as all > >>>>> the parties CCed on this message need to see your changes. The > >>>>> parties > >>>>> include: > >>>>> > >>>>> * your coauthors > >>>>> > >>>>> * rfc-editor@rfc-editor.org (the RPC team) > >>>>> > >>>>> * other document participants, depending on the stream (e.g., > >>>>> IETF Stream participants are your working group chairs, the > >>>>> responsible ADs, and the document shepherd). > >>>>> > >>>>> * auth48archive@rfc-editor.org, which is a new archival mailing > >>>>> list > >>>>> to preserve AUTH48 conversations; it is not an active > >>>>> discussion > >>>>> list: > >>>>> > >>>>> * More info: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__mailarchive.ietf.org_arch_msg_ietf-2Dannounce_yb6lpIGh- > >>>>> 2D4Q9l2USxIAe6P8O4Zc&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=Xpv_RGqQvhqtNJZYsAZdjRqqqMLITUhSheAlBOS0QcM&e= > >>>>> > >>>>> * The archive itself: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https- > >>>>> 3A__mailarchive.ietf.org_arch_browse_auth48archive_&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=ZZF5J6GNV98YvflVxho- > >>>>> ehYkE4XVuSgzPxUv7BMXRuo&e= > >>>>> > >>>>> * Note: If only absolutely necessary, you may temporarily opt > >>>>> out > >>>>> of the archiving of messages (e.g., to discuss a sensitive > >>>>> matter). > >>>>> If needed, please add a note at the top of the message that > >>>>> you > >>>>> have dropped the address. When the discussion is concluded, > >>>>> auth48archive@rfc-editor.org will be re-added to the CC list > >>>>> and > >>>>> its addition will be noted at the top of the message. > >>>>> > >>>>> You may submit your changes in one of two ways: > >>>>> > >>>>> An update to the provided XML file > >>>>> — OR — > >>>>> An explicit list of changes in this format > >>>>> > >>>>> Section # (or indicate Global) > >>>>> > >>>>> OLD: > >>>>> old text > >>>>> > >>>>> NEW: > >>>>> new text > >>>>> > >>>>> You do not need to reply with both an updated XML file and an > >>>>> explicit > >>>>> list of changes, as either form is sufficient. > >>>>> > >>>>> We will ask a stream manager to review and approve any changes > >>>>> that seem > >>>>> beyond editorial in nature, e.g., addition of new text, deletion > >>>>> of text, > >>>>> and technical changes. Information about stream managers can be > >>>>> found in > >>>>> the FAQ. Editorial changes do not require approval from a stream > >>>>> manager. > >>>>> > >>>>> > >>>>> Approving for publication > >>>>> -------------------------- > >>>>> > >>>>> To approve your RFC for publication, please reply to this email > >>>>> stating > >>>>> that you approve this RFC for publication. Please use ‘REPLY > >>>>> ALL’, > >>>>> as all the parties CCed on this message need to see your > >>>>> approval. > >>>>> > >>>>> > >>>>> Files > >>>>> ----- > >>>>> > >>>>> The files are available here: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=SxAnToF1bD17Ylf0ISe7m- > >>>>> ZEuYAvsaaRRIqom0YC-tg&e= > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=ws6XasfHZmTCyStHTHQJvo8drKIMBKIeSdF5X94ndLY&e= > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.pdf&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=P5Qm6- > >>>>> WcRWIQgsfhP_9_7pApSvXGfi351eSpK3WGCW4&e= > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.txt&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=dPqAG6AEpPOfCnnBZfJp5Nxh59pfzDkdTFh5Eo6VeOM&e= > >>>>> > >>>>> Diff file of the text: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516- > >>>>> 2Ddiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=1BJbDOHJQPxTf1aoNF5jypj_7ORWrXKn7lwOdWnsAJ0&e= > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516- > >>>>> 2Drfcdiff.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=qc- > >>>>> DM9p0gK0B36AxMShc-W8LEI5bWduwvcS0kROi0xM&e= (side by side) > >>>>> > >>>>> Diff of the XML: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516- > >>>>> 2Dxmldiff1.html&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=Mk51dKFss9G2tyOhB7TSM_SqyamMui_- > >>>>> F3Kz0MTRmvM&e= > >>>>> > >>>>> The following files are provided to facilitate creation of your > >>>>> own > >>>>> diff files of the XML. > >>>>> > >>>>> Initial XMLv3 created using XMLv2 as input: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.original.v2v3.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=M78Dni2xKbQmdBK8TbwvmxGrHdV9VEe2IjzWoiygWsI&e= > >>>>> > >>>>> XMLv3 file that is a best effort to capture v3-related format > >>>>> updates > >>>>> only: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_authors_rfc9516.form.xml&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=3IBljze4OS1Ub5Heycrz- > >>>>> KepqD2lHgtOzdCTfFAn8vs&e= > >>>>> > >>>>> > >>>>> Tracking progress > >>>>> ----------------- > >>>>> > >>>>> The details of the AUTH48 status of your document are here: > >>>>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > >>>>> 2Deditor.org_auth48_rfc9516&d=DwIFaQ&c=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ&r=DnUkF34wu4mqq0UY8nn2rxBBO7qOW_D- > >>>>> RfNVLML28ZU&m=U2_vqYBzvuJlI3TN9fsfhQDi6cUqv25tSimkIo_syfgEIAjC_E7_VIG00sc7ewDJ&s=d1PVySlxRqgwlM4XX4RardCecD_rXvNJNh5woXgeX9k&e= > >>>>> > >>>>> Please let us know if you have any questions. > >>>>> > >>>>> Thank you for your cooperation, > >>>>> > >>>>> RFC Editor > >>>>> > >>>>> -------------------------------------- > >>>>> RFC9516 (draft-ietf-sfc-multi-layer-oam-28) > >>>>> > >>>>> Title : Active OAM for Service Function Chaining (SFC) > >>>>> Author(s) : G. Mirsky, W. Meng, T. Ao, B. Khasnabish, K. > >>>>> Leung, G. Mishra > >>>>> WG Chair(s) : Joel M. Halpern, Jim Guichard > >>>>> > >>>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston > >>>> > >>> > >>> -- > >>> > >>> > >>> Gyan Mishra > >>> IT Technologist & Innovations Specialist > >>> Associate Fellow-Network Design > >>> Network Solutions Architect, > >>> R&S, SP SME & Protocol Design Expert > >>> Global Technology Services > >>> O 240 970-6287 > >>> M 301 502-1347 > >>> > >>> > >> > >
- [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-sfc-m… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Greg Mirsky
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Greg Mirsky
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… meng.wei2
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Alanna Paloma
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… B. Khasnabish
- Re: [auth48] AUTH48: RFC-to-be 9516 <draft-ietf-s… Alanna Paloma
- Re: [auth48] [E] Re: AUTH48: RFC-to-be 9516 <draf… Mishra, Gyan S
- Re: [auth48] [E] AUTH48: RFC-to-be 9516 <draft-ie… Alanna Paloma
- Re: [auth48] [E] AUTH48: RFC-to-be 9516 <draft-ie… Alanna Paloma
- [auth48] [IANA] Re: [E] AUTH48: RFC-to-be 9516 <d… Alanna Paloma
- [auth48] [IANA #1288304] [IANA] Re: [E] AUTH48: R… David Dong via RT
- Re: [auth48] [IANA #1288304] [IANA] Re: [E] AUTH4… Alanna Paloma
- Re: [auth48] [IANA #1288304] [IANA] Re: [E] AUTH4… Greg Mirsky
- Re: [auth48] [E] AUTH48: RFC-to-be 9516 <draft-ie… Alanna Paloma