Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review
Italo Busi <Italo.Busi@huawei.com> Tue, 09 August 2022 07:19 UTC
Return-Path: <Italo.Busi@huawei.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 E4E26C15C51B; Tue, 9 Aug 2022 00:19:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=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=ham 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 eQsRqW89z-Ej; Tue, 9 Aug 2022 00:19:08 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 13911C157B54; Tue, 9 Aug 2022 00:19:08 -0700 (PDT)
Received: from fraeml709-chm.china.huawei.com (unknown [172.18.147.201]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4M249z3zRFz687Wr; Tue, 9 Aug 2022 15:16:23 +0800 (CST)
Received: from fraeml715-chm.china.huawei.com (10.206.15.34) by fraeml709-chm.china.huawei.com (10.206.15.37) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.24; Tue, 9 Aug 2022 09:19:04 +0200
Received: from fraeml715-chm.china.huawei.com ([10.206.15.34]) by fraeml715-chm.china.huawei.com ([10.206.15.34]) with mapi id 15.01.2375.024; Tue, 9 Aug 2022 09:19:04 +0200
From: Italo Busi <Italo.Busi@huawei.com>
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>
Thread-Topic: AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review
Thread-Index: AQHYqP5jpWybdtFvvkSJEK/n+VkQm62mLmgA
Date: Tue, 09 Aug 2022 07:19:04 +0000
Message-ID: <f11015fecb2a4e999412a370ad726f89@huawei.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>
In-Reply-To: <181B717A-95AF-4973-8DFE-8C62CCDE7775@amsl.com>
Accept-Language: it-IT, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.81.208.127]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/rilrJkzZsZOsXpsJe166Y7CxZlQ>
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 07:19:13 -0000
Hi Lynne I approve the document for publication in its current form. Thanks, Italo > -----Original Message----- > From: Lynne Bartholomew <lbartholomew@amsl.com> > Sent: venerdì 5 agosto 2022 21:05 > To: Hejia (Jia) <hejia@huawei.com>; Italo Busi <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