Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Tue, 09 August 2022 21:55 UTC
Return-Path: <lbartholomew@amsl.com>
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 9220BC159493; Tue, 9 Aug 2022 14:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.207
X-Spam-Level:
X-Spam-Status: No, score=-4.207 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 ElsI86v1M-E9; Tue, 9 Aug 2022 14:55:18 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 110FEC14F74D; Tue, 9 Aug 2022 14:55:18 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E5D95424B44B; Tue, 9 Aug 2022 14:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fx-prHj3UoaJ; Tue, 9 Aug 2022 14:55:17 -0700 (PDT)
Received: from [IPv6:2601:646:8b00:26c0:bcc9:b242:4194:62b9] (unknown [IPv6:2601:646:8b00:26c0:bcc9:b242:4194:62b9]) by c8a.amsl.com (Postfix) with ESMTPSA id 9BE8E424B440; Tue, 9 Aug 2022 14:55:17 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <SLXP216MB1180DC97EDB71004FDAF6B69FA639@SLXP216MB1180.KORP216.PROD.OUTLOOK.COM>
Date: Tue, 09 Aug 2022 14:55:16 -0700
Cc: John Scudder <jgs@juniper.net>, Jeong-dong Ryoo <ryoo@etri.re.kr>, "teas-ads@ietf.org" <teas-ads@ietf.org>, RFC System <rfc-editor@rfc-editor.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, "byyun@etri.re.kr" <byyun@etri.re.kr>, Vishnu Pavan Beeram <vbeeram@juniper.net>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org>, "hejia@huawei.com" <hejia@huawei.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <97BDD9A7-A3FE-4B2C-8BAE-F45FA7B21705@amsl.com>
References: <20220712223705.331A84C0A2@rfcpa.amsl.com> <p7j5epje3kfn.p7j5epjb4u0z.g1@dooray.com> <D87ABDE2-3EB0-4C59-AD06-7768C2278ED3@amsl.com> <609C56BC-F2D8-4A9C-83F5-0520D77242E0@juniper.net> <3583F1BB-28B6-43B6-A2AB-289511134C8B@amsl.com> <181B717A-95AF-4973-8DFE-8C62CCDE7775@amsl.com> <002501d8ab23$5a357ed0$0ea07c70$@etri.re.kr> <SLXP216MB1180DC97EDB71004FDAF6B69FA639@SLXP216MB1180.KORP216.PROD.OUTLOOK.COM>
To: "\"박춘걸(AI Managed Service Projec)\"" <peter.park@kt.com>, "italo.busi@huawei.com" <italo.busi@huawei.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/o0UivoQGEGX1P7JSMEwvpR0Xdek>
Subject: Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
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: Tue, 09 Aug 2022 21:55:22 -0000
Dear Peter and Italo, We have noted your approvals on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9270 As we now have all approvals, we will prepare this document for publication shortly. Thank you! RFC Editor/lb > From: Italo Busi <Italo.Busi@huawei.com> > Subject: RE: AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review > Date: August 9, 2022 at 12:19:04 AM PDT > To: Lynne Bartholomew <lbartholomew@amsl.com>, "Hejia (Jia)" <hejia@huawei.com>, 윤빈영 <byyun@etri.re.kr>, "peter.park@kt.com" <peter.park@kt.com> > Cc: John Scudder <jgs@juniper.net>, Jeong-dong Ryoo <ryoo@etri.re.kr>, "teas-ads@ietf.org" <teas-ads@ietf.org>, RFC System <rfc-editor@rfc-editor.org>, "teas-chairs@ietf.org" <teas-chairs@ietf.org>, Vishnu Pavan Beeram <vbeeram@juniper.net>, "auth48archive@rfc-editor.org" <auth48archive@rfc-editor.org> > > Hi Lynne > > I approve the document for publication in its current form. > > Thanks, Italo > On Aug 8, 2022, at 4:17 PM, 박춘걸(AI Managed Service Projec) <peter.park@kt.com> wrote: > > Dear Lynne, > > Thank you for all the contributions on this document. > I have a confirmation on this document ready for publication. > > Best regards, > Peter. > > -----Original Message----- > From: byyun@etri.re.kr <byyun@etri.re.kr> > Sent: Monday, August 8, 2022 9:36 PM > To: 'Lynne Bartholomew' <lbartholomew@amsl.com>; hejia@huawei.com; italo.busi@huawei.com; 박춘걸(AI Managed Service Projec) <peter.park@kt.com> > Cc: 'John Scudder' <jgs@juniper.net>; 'Jeong-dong Ryoo' <ryoo@etri.re.kr>; teas-ads@ietf.org; 'RFC System' <rfc-editor@rfc-editor.org>; teas-chairs@ietf.org; 'Vishnu Pavan Beeram' <vbeeram@juniper.net>; auth48archive@rfc-editor.org > Subject: RE: AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review > > Dear Lynne, > > I approve the document for publication in its current form. > Thanks for your hard work. > > > Regards, > Bin > > -----Original Message----- > From: Lynne Bartholomew <> > Sent: Saturday, August 6, 2022 4:05 AM > To: hejia@huawei.com; italo.busi@huawei.com; 윤빈영 <byyun@etri.re.kr>; peter.park@kt.com > Cc: John Scudder <jgs@juniper.net>; Jeong-dong Ryoo <ryoo@etri.re.kr>; teas-ads@ietf.org; RFC System <rfc-editor@rfc-editor.org>; teas-chairs@ietf.org; Vishnu Pavan Beeram <vbeeram@juniper.net>; auth48archive@rfc-editor.org > Subject: Re: AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review > > Dear Jia, Italo, Bin, and Peter, > > We do not believe that we have heard from you regarding this document's readiness for publication. > > Please review the updated files, and let us know whether further changes are needed or you approve the document for publication in its current form. > > The latest files are posted here: > > https://www.rfc-editor.org/authors/rfc9270.txt > https://www.rfc-editor.org/authors/rfc9270.pdf > https://www.rfc-editor.org/authors/rfc9270.html > https://www.rfc-editor.org/authors/rfc9270.xml > https://www.rfc-editor.org/authors/rfc9270-diff.html > https://www.rfc-editor.org/authors/rfc9270-alt-diff.html > https://www.rfc-editor.org/authors/rfc9270-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9270-auth48diff.html > > https://www.rfc-editor.org/authors/rfc9270-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9270-xmldiff2.html > > The AUTH48 status page is here: > > https://www.rfc-editor.org/auth48/rfc9270 > > Thank you! > > RFC Editor/lb > >> On Jul 22, 2022, at 2:17 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >> >> Hi, John. We have noted your approval: >> >> https://www.rfc-editor.org/auth48/rfc9270 >> >> Thank you! >> >> RFC Editor/lb >> >>> On Jul 21, 2022, at 8:29 AM, John Scudder <jgs@juniper.net> wrote: >>> >>> Hi Lynne, >>> >>>> On Jul 15, 2022, at 8:13 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>> >>>> Dear Jeong-dong and *AD (John), >>>> >>>> * John, per our process, we will need your approval for the removal of "MUST" in Section 4, Paragraph 2 (just after Figure 1). >>> >>> Yes, this change is fine, thanks for checking. >>> >>> —John >> > >> From: Lynne Bartholomew <lbartholomew@amsl.com> >> Subject: Re: *[AD] Re: AUTH48: RFC-to-be 9270 >> <draft-ietf-teas-gmpls-signaling-smp-12> for your review >> Date: July 19, 2022 at 12:55:55 PM PDT >> To: Jeong-dong Ryoo <ryoo@etri.re.kr> >> Cc: teas-ads@ietf.org, John Scudder <jgs@juniper.net>, >> hejia@huawei.com, italo.busi@huawei.com, 윤빈영 <byyun@etri.re.kr>, >> peter.park@kt.com, RFC System <rfc-editor@rfc-editor.org>, >> teas-chairs@ietf.org, Vishnu Pavan Beeram <vbeeram@juniper.net>, >> auth48archive@rfc-editor.org >> >> Dear Jeong-dong, >> >> We have noted your approval on the AUTH48 status page: >> >> https://www.rfc-editor.org/auth48/rfc9270 >> >> Thank you very much! >> >> RFC Editor/lb >> >>> On Jul 18, 2022, at 6:09 PM, Jeong-dong Ryoo <ryoo@etri.re.kr> wrote: >>> >>> Dear Lynne, >>> >>> Thank you for the updates. They are all good to me. I hope the outstanding issue related to the removal of "MUST" will be finalized according to the response from our AD, John. >>> >>> Thanks again. >>> >>> Best regards, >>> >>> Jeong-dong >>> >>> >>> >>> >>> -----Original Message----- >>> From: "Lynne Bartholomew" <lbartholomew@amsl.com> >>> To: "Jeong-dong Ryoo" <ryoo@etri.re.kr>; <teas-ads@ietf.org>; "John Scudder" <jgs@juniper.net>; >>> Cc: <hejia@huawei.com>; <italo.busi@huawei.com>; "윤빈영" <byyun@etri.re.kr>; <peter.park@kt.com>; "RFC System" <rfc-editor@rfc-editor.org>; <teas-chairs@ietf.org>; "Vishnu Pavan Beeram" <vbeeram@juniper.net>; <auth48archive@rfc-editor.org>; >>> Sent: 2022-07-16 (토) 09:14:14 (UTC+09:00) >>> Subject: *[AD] Re: AUTH48: RFC-to-be 9270 >>> <draft-ietf-teas-gmpls-signaling-smp-12> for your review >>> >>> Dear Jeong-dong and *AD (John), >>> >>> * John, per our process, we will need your approval for the removal of "MUST" in Section 4, Paragraph 2 (just after Figure 1). >>> >>> Jeong-dong, thank you for your prompt reply! We have updated this document per your notes below. >>> >>> The latest files are posted here: >>> >>> https://www.rfc-editor.org/authors/rfc9270.txt >>> https://www.rfc-editor.org/authors/rfc9270.pdf >>> https://www.rfc-editor.org/authors/rfc9270.html >>> https://www.rfc-editor.org/authors/rfc9270.xml >>> https://www.rfc-editor.org/authors/rfc9270-diff.html >>> https://www.rfc-editor.org/authors/rfc9270-rfcdiff.html >>> https://www.rfc-editor.org/authors/rfc9270-auth48diff.html >>> >>> https://www.rfc-editor.org/authors/rfc9270-alt-diff.html >>> https://www.rfc-editor.org/authors/rfc9270-xmldiff1.html >>> https://www.rfc-editor.org/authors/rfc9270-xmldiff2.html >>> >>> Thanks again for your quick reply and help! >>> >>> RFC Editor/lb >>> >>>> On Jul 14, 2022, at 7:00 PM, Jeong-dong Ryoo <ryoo@etri.re.kr> wrote: >>>> >>>> Dear RFC Editor, >>>> >>>> >>>> Thank you for your email. >>>> >>>> Please, see my answers to your questions as follows: >>>> >>>> 1) Thank you for the improvements you've done. I am ok with the changes. >>>> >>>> 2) As you pointed out, I couldn't find the "MUST" as related to RFC 3209, either. I suggest the following change (removing MUST): >>>> >>>> OLD: >>>> Per RFC >>>> 3209 [RFC3209], in order to achieve resource sharing during the >>>> signaling of these protecting LSPs, they MUST have the same Tunnel >>>> Endpoint Address (as part of their SESSION object). >>>> >>>> NEW: >>>> Per RFC >>>> 3209 [RFC3209], in order to achieve resource sharing during the >>>> signaling of these protecting LSPs, they have the same Tunnel >>>> Endpoint Address (as part of their SESSION object). >>>> >>>> 3) According to the definition and usage of the <aside> element, it looks like there will be no problem putting the "Note:" in the <aside> element. But, I don't know what the resulting text looks like if the <aside> element is used. Nevertheless, I should be ok as long as the text is there. >>>> >>>> 4) Thank you for taking a close look at those reference documents as well. Both expressions are understood to be the same. I would like to keep object names consistent in this document by making them all uppercase. >>>> >>>> 5) Yes, it means "preemption status". I am fine with your suggestion. >>>> >>>> 6) "SMP" in the "SMP protecting LSP" is not really necessary. Since we use "protecting LSP" throughout this document except Section 5.6, please, replace "SMP protecting LSP" with "protecting LSP" in Section 5.6. >>>> >>>> 7) Sorry for the confusion. Suggestion #1 is correct. >>>> >>>> 8) Your change is good. >>>> >>>> 9) I am aware of the terms related to the "inclusive language" and tried not to use them. I don't think any changes are needed. >>>> >>>> 10) No objection. Thank you for the consistency check. >>>> >>>> Thank you. >>>> >>>> >>>> Best regards, >>>> >>>> Jeong-dong >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: "" <rfc-editor@rfc-editor.org> >>>> To: <hejia@huawei.com>; <italo.busi@huawei.com>; <ryoo@etri.re.kr>; <byyun@etri.re.kr>; <peter.park@kt.com>; >>>> Cc: <rfc-editor@rfc-editor.org>; <teas-ads@ietf.org>; <teas-chairs@ietf.org>; <vbeeram@juniper.net>; <auth48archive@rfc-editor.org>; >>>> Sent: 2022-07-13 (수) 07:37:12 (UTC+09:00) >>>> Subject: Re: AUTH48: RFC-to-be 9270 >>>> <draft-ietf-teas-gmpls-signaling-smp-12> for your review >>>> >>>> Authors, >>>> >>>> While reviewing this document during AUTH48, please resolve (as >>>> necessary) the following questions, which are also in the XML file. >>>> >>>> 1) <!-- [rfced] Abbreviated (running) title (.pdf output) and body >>>> of >>>> document: Because this document and RFC 4872 state that they define >>>> extensions (i.e., more than one extension) for GMPLS signaling, we >>>> changed "extension" to "extensions" as noted below. Please review, >>>> and let us know any concerns. >>>> >>>> Original: >>>> GMPLS Extension for SMP >>>> ... >>>> 4. Operation of SMP with GMPLS Signaling Extension . . . . . . . 5 >>>> 5. GMPLS Signaling Extension for SMP . . . . . . . . . . . . . . 6 >>>> ... >>>> RFC 4872 [RFC4872] defines extension of Resource Reservation >>>> Protocol >>>> - Traffic Engineering (RSVP-TE) to support Shared Mesh Restoration >>>> (SMR) mechanisms. >>>> >>>> Currently: >>>> GMPLS Extensions for SMP >>>> ... >>>> 4. Operation of SMP with GMPLS Signaling Extensions 5. GMPLS >>>> Signaling Extensions for SMP ... >>>> RFC 4872 [RFC4872] defines extensions for Resource Reservation >>>> Protocol - Traffic Engineering (RSVP-TE) to support Shared Mesh >>>> Restoration (SMR) mechanisms. --> >>>> >>>> >>>> 2) <!-- [rfced] Section 4: We could not verify the "MUST" as >>>> related to RFC 3209. Please verify that this text is correct and >>>> will be clear to readers. >>>> >>>> Original: >>>> Per RFC >>>> 3209 [RFC3209], in order to achieve resource sharing during the >>>> signaling of these protecting LSPs, they MUST have the same Tunnel >>>> Endpoint Address (as part of their SESSION object). --> >>>> >>>> >>>> 3) <!-- [rfced] Section 5.2: Please review whether this "Note:" >>>> item should be in the <aside> element. <aside> is defined as "a >>>> container for content that is semantically less important or >>>> tangential to the content that surrounds it" >>>> (https://xml2rfc.tools.ietf.org/xml2rfc-doc.html#name-aside-2). >>>> >>>> Original: >>>> Note: N bit is set to indicate that the protection switching >>>> signaling is done via data plane. --> >>>> >>>> >>>> 4) <!-- [rfced] Section 5.3: We see that RFC 3473 uses "Admin_Status" >>>> instead of "ADMIN_STATUS", while RFCs 4872 and 4873 use >>>> "ADMIN_STATUS". However, RFC 4873 also uses "Admin_Status". Will >>>> these distinctions be clear to readers? >>>> >>>> Original: >>>> The formerly working LSP MAY be signaled with the A bit set in the >>>> ADMIN_STATUS object (see [RFC3473]). --> >>>> >>>> >>>> 5) <!-- [rfced] Section 5.4: Does "preempted situation" mean >>>> "preemption status" or something else? If the suggested text is not >>>> correct, please clarify. >>>> >>>> Original: >>>> Once the working LSP and the >>>> protecting LSP are configured or pre-configured, the end node MUST >>>> keep refreshing both working and protecting LSPs regardless of >>>> failure or preempted situation. >>>> >>>> Suggested: >>>> Once the working LSP and the >>>> protecting LSP are configured or preconfigured, the end node MUST >>>> keep refreshing both working and protecting LSPs, regardless of >>>> failure or preemption status. --> >>>> >>>> >>>> 6) <!-- [rfced] Section 5.6: Do these four instances of "SMP >>>> protecting LSP" mean "SMP's protecting LSP", "protecting LSP for >>>> SMP", or something else? >>>> >>>> Original: >>>> SMP relies on APS protocol messages being exchanged between the >>>> nodes along the path to activate an SMP protecting LSP. >>>> >>>> In order to allow the exchange of APS protocol messages, an APS >>>> channel has to be configured between adjacent nodes along the path >>>> of the SMP protecting LSP. This is done by other means than GMPLS >>>> signaling, before any SMP protecting LSP has been set up. >>>> Therefore, there are likely additional requirements for APS >>>> configuration which are outside the scope of this document. >>>> >>>> Depending on the APS protocol message format, the APS protocol may >>>> use different identifiers than GMPLS signaling to identify the SMP >>>> protecting LSP. --> >>>> >>>> >>>> 7) <!-- [rfced] Section 6.2: We had trouble determining what is >>>> "only applicable" in this sentence, because of the comma after "1". >>>> If neither suggestion below is correct, please clarify. >>>> >>>> Original: >>>> The O bit is only >>>> applicable when the P bit is set to 1, and the LSP Protection Type >>>> Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 (1+1 >>>> Unidirectional Protection), 0x10 (1+1 Bidirectional Protection), or >>>> 0x20 (Shared Mesh Protection). >>>> >>>> Suggestion #1 (only applicable when (1) and (2) are applied): >>>> The O bit is only >>>> applicable when (1) the P bit is set to 1 and (2) the LSP Protection >>>> Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), 0x08 >>>> (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional >>>> Protection), or 0x20 (Shared Mesh Protection). >>>> >>>> Suggestion #2 (only applicable when the P bit is set to 1): >>>> The O bit is only >>>> applicable when the P bit is set to 1. Also, the LSP Protection >>>> Type Flag is set to 0x04 (1:N Protection with Extra-Traffic), >>>> 0x08 (1+1 Unidirectional Protection), 0x10 (1+1 Bidirectional >>>> Protection), or 0x20 (Shared Mesh Protection). --> >>>> >>>> >>>> 8) <!-- [rfced] Section 6.3: This paragraph was difficult to >>>> follow; for example, "several fields from that field" reads oddly. >>>> Also, the fourth sentence appeared to conflict with Section 1, >>>> Paragraph 1, last sentence of this document, as well as Section 9.2 of RFC 4873. >>>> We updated the text as follows. Please review carefully, and let us >>>> know if anything is incorrect. >>>> >>>> Original: >>>> [RFC4872] reserved a 32-bit field in the PROTECTION object header. >>>> Subsequently, [RFC4873] allocated several fields from that field, >>>> and left the remainder of the bits reserved. This specification >>>> further allocates the preemption priority field from those >>>> formerly-reserved bits. The 32-bit field in the PROTECTION object >>>> defined in [RFC4873] are updated as follows: >>>> >>>> Currently (the subject-verb disagreement in the fourth sentence has >>>> been corrected): >>>> [RFC4872] reserved a 32-bit field in the PROTECTION object header. >>>> Subsequently, [RFC4873] allocated several bits from that field and >>>> left the remainder of the bits reserved. This specification further >>>> allocates the Preemption Priority field from the remaining formerly >>>> reserved bits. The 32-bit field in the PROTECTION object as defined >>>> in [RFC4872] and modified by [RFC4873] is updated by this document >>>> as >>>> follows: --> >>>> >>>> >>>> 9) <!-- [rfced] Please review the "Inclusive Language" portion of >>>> the online Style Guide at >>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, >>>> and let us know if any changes are needed. Note that our script did >>>> not flag any words or phrases. --> >>>> >>>> >>>> 10) <!-- [rfced] The following terms were used inconsistently in >>>> this document. We chose to use the latter forms. Please let us >>>> know any objections. >>>> >>>> LSP protection type / LSP Protection Type (per RFC 4872) >>>> >>>> Protection Object / PROTECTION object (in text) (per RFC 4872, with >>>> one exception, which appears to be an oversight) --> >>>> >>>> >>>> Thank you. >>>> >>>> RFC Editor >>>> >>>> >>>> On Jul 12, 2022, at 3:32 PM, rfc-editor@rfc-editor.org wrote: >>>> >>>> *****IMPORTANT***** >>>> >>>> Updated 2022/07/12 >>>> >>>> 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://www.rfc-editor.org/faq/). >>>> >>>> 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://trustee.ietf.org/license-info/). >>>> >>>> * 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://authors.ietf.org/rfcxml-vocabulary>. >>>> >>>> * 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://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2US >>>> xIAe6P8O4Zc >>>> >>>> * The archive itself: >>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>> >>>> * 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://www.rfc-editor.org/authors/rfc9270.xml >>>> https://www.rfc-editor.org/authors/rfc9270.html >>>> https://www.rfc-editor.org/authors/rfc9270.pdf >>>> https://www.rfc-editor.org/authors/rfc9270.txt >>>> >>>> Diff file of the text: >>>> https://www.rfc-editor.org/authors/rfc9270-diff.html >>>> https://www.rfc-editor.org/authors/rfc9270-rfcdiff.html (side by >>>> side) >>>> >>>> For your convenience, we have also created an alt-diff file that >>>> will allow you to more easily view changes where text has been >>>> deleted or >>>> moved: >>>> https://www.rfc-editor.org/authors/rfc9270-alt-diff.html >>>> >>>> Diff of the XML: >>>> https://www.rfc-editor.org/authors/rfc9270-xmldiff1.html >>>> >>>> The following files are provided to facilitate creation of your own >>>> diff files of the XML. >>>> >>>> Initial XMLv3 created using XMLv2 as input: >>>> https://www.rfc-editor.org/authors/rfc9270.original.v2v3.xml >>>> >>>> XMLv3 file that is a best effort to capture v3-related format >>>> updates >>>> only: >>>> https://www.rfc-editor.org/authors/rfc9270.form.xml >>>> >>>> >>>> Tracking progress >>>> ----------------- >>>> >>>> The details of the AUTH48 status of your document are here: >>>> https://www.rfc-editor.org/auth48/rfc9270 >>>> >>>> Please let us know if you have any questions. >>>> >>>> Thank you for your cooperation, >>>> >>>> RFC Editor >>>> >>>> -------------------------------------- >>>> RFC9270 (draft-ietf-teas-gmpls-signaling-smp-12) >>>> >>>> Title : GMPLS Signaling Extensions for Shared Mesh Protection >>>> Author(s) : J. He, I. Busi, J. Ryoo, B. Yoon, P. Park >>>> WG Chair(s) : Vishnu Pavan Beeram, Lou Berger >>>> >>>> Area Director(s) : Alvaro Retana, John Scudder, Andrew Alston >>>> >>>> > > > > >
- [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-teas-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Jeong-dong Ryoo
- [auth48] *[AD] Re: AUTH48: RFC-to-be 9270 <draft-… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9270 <dr… Jeong-dong Ryoo
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9270 <dr… Lynne Bartholomew
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9270 <dr… John Scudder
- Re: [auth48] *[AD] Re: AUTH48: RFC-to-be 9270 <dr… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Hejia (Jia)
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… byyun
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… 박춘걸(AI Managed Service Projec)
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Italo Busi
- Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-t… Lynne Bartholomew