Re: [auth48] AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review
Lynne Bartholomew <lbartholomew@amsl.com> Mon, 08 August 2022 16:03 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 3A7E5C1594AF; Mon, 8 Aug 2022 09:03:31 -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_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 XKHGDixo_FNy; Mon, 8 Aug 2022 09:03:27 -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 1915CC14CF10; Mon, 8 Aug 2022 09:03:27 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 009D5424B446; Mon, 8 Aug 2022 09:03:27 -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 QAPfLTMXK67u; Mon, 8 Aug 2022 09:03:26 -0700 (PDT)
Received: from [IPv6:2601:646:8b00:16e0:9506:4bc1:5be0:9e00] (unknown [IPv6:2601:646:8b00:16e0:9506:4bc1:5be0:9e00]) by c8a.amsl.com (Postfix) with ESMTPSA id A6766424B432; Mon, 8 Aug 2022 09:03:26 -0700 (PDT)
From: Lynne Bartholomew <lbartholomew@amsl.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\))
Date: Mon, 08 Aug 2022 09:03:25 -0700
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>
Cc: Italo Busi <Italo.Busi@huawei.com>, "peter.park" <peter.park@kt.com>, John Scudder <jgs@juniper.net>, Jeong-dong Ryoo <ryoo@etri.re.kr>, teas-ads <teas-ads@ietf.org>, RFC System <rfc-editor@rfc-editor.org>, TEAS WG Chairs <teas-chairs@ietf.org>, Vishnu Pavan Beeram <vbeeram@juniper.net>, auth48archive <auth48archive@rfc-editor.org>
To: "Hejia (Jia)" <hejia@huawei.com>, 윤빈영 <byyun@etri.re.kr>
Message-Id: <6B6A522A-EC84-4A71-A288-682F945E0541@amsl.com>
X-Mailer: Apple Mail (2.3273)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/sno9c5BSZ1JT-7YufeO-3hwdfm0>
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: Mon, 08 Aug 2022 16:03:31 -0000
Dear Jia and Bin, We have noted your approvals on the AUTH48 status page: https://www.rfc-editor.org/auth48/rfc9270 Thank you very much! RFC Editor/lb > From: <byyun@etri.re.kr> > Subject: RE: AUTH48: RFC-to-be 9270 <draft-ietf-teas-gmpls-signaling-smp-12> for your review > Date: August 8, 2022 at 5:35:32 AM PDT > To: "'Lynne Bartholomew'" <lbartholomew@amsl.com>, <hejia@huawei.com>, <italo.busi@huawei.com>, <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> > > Dear Lynne, > > I approve the document for publication in its current form. > Thanks for your hard work. > > > Regards, > Bin > On Aug 8, 2022, at 5:31 AM, Hejia (Jia) <hejia@huawei.com> wrote: > > Hi, > > I think the document is ready for publication in its current form. Thanks a lot for your hard work. > > B.R. > Jia > 发件人:Lynne Bartholomew <lbartholomew@amsl.com> > 收件人:Hejia (Jia) <hejia@huawei.com>;Italo Busi <Italo.Busi@huawei.com>;윤빈영 <byyun@etri.re.kr>;peter.park <peter.park@kt.com> > 抄 送:John Scudder <jgs@juniper.net>;Jeong-dong Ryoo <ryoo@etri.re.kr>;teas-ads <teas-ads@ietf.org>;RFC System <rfc-editor@rfc-editor.org>;TEAS WG Chairs <teas-chairs@ietf.org>;Vishnu Pavan Beeram <vbeeram@juniper.net>;auth48archive <auth48archive@rfc-editor.org> > 时 间:2022-08-06 03:05:53 > 主 题:Re: AUTH48: RFC-to-be 9270 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-4Q9l2USxIAe6P8O4Zc > >>> > >>> * 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