Hi Cheng, Thank you for your reply. We have updated the document and will continue with publication shortly.
RFC Editor/sg > On Apr 14, 2025, at 3:44 AM, Cheng Li <c.l=40huawei....@dmarc.ietf.org> wrote: > > After discussing with Dhruv, "Optional processing of PCEP object " is > preferred. > > Thanks, > Cheng > > > > > > > 李呈 Li Cheng > Mobile: +86-15116983550(中国电话)/+33-625833229(法国电话) > Mail: c...@huawei.com > > 发件人：Cheng Li <c...@huawei.com> > 收件人：Sandy Ginoza <sgin...@staff.rfc-editor.org>;slitkows.ietf > <slitkows.i...@gmail.com> > 抄 送：Zhenghaomian <zhenghaom...@huawei.com>;Dhruv Dhody > <d...@dhruvdhody.com>;RFC Editor <rfc-edi...@rfc-editor.org>;pce-ads > <pce-...@ietf.org>;pce-chairs <pce-cha...@ietf.org>;Roman Danyliw > <r...@cert.org>;auth48archive <auth48archive@rfc-editor.org> > 时 间：2025-04-14 11:38:44 > 主 题：RE: question: Re: AUTH48: RFC-to-be 9753 for your review > > I think it should be " Optional Processing in Stateful PCEP". > > It is not Stateful PCE for Optional PCEP Objects. > > Thanks, > Cheng > > > -----Original Message----- > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > Sent: Friday, April 11, 2025 8:29 PM > To: slitkows.i...@gmail.com > Cc: Zhenghaomian <zhenghaom...@huawei.com>; Dhruv Dhody > <d...@dhruvdhody.com>; Cheng Li <c...@huawei.com>; RFC Editor > <rfc-edi...@rfc-editor.org>; pce-...@ietf.org; pce-cha...@ietf.org; Roman > Danyliw <r...@cert.org>; auth48archive@rfc-editor.org > Subject: question: Re: AUTH48: RFC-to-be 9753 > <draft-ietf-pce-stateful-pce-optional-13> for your review > > Hi Stephane, Authors, > > Thank you for your review. We have noted your approval on the AUTH48 page > <https://www.rfc-editor.org/auth48/rfc9753>. > > Authors, please note that we have updated the abbreviated title that appears > in the center header of the PDF as shown below. Originally, it shows > "STATEFUL-OPT”, which is not a term used in the document. > > Original: > STATEFUL-OPT > > Current: > Stateful PCE for Optional PCEP Objects > > We would appreciate an acknowledgement that the update is acceptable from at > least one author at this point in the process. If it is unacceptable, please > provide the update. > > Please see <https://www.rfc-editor.org/authors/rfc9753.pdf>. (Note that the > change is not visible in the other file formats or the diffs because the > center header does not appear in the other files.) > > All of the files are available here: > https://www.rfc-editor.org/authors/rfc9753.xml > https://www.rfc-editor.org/authors/rfc9753.txt > https://www.rfc-editor.org/authors/rfc9753.pdf > https://www.rfc-editor.org/authors/rfc9753.html > > Thank you, > RFC Editor/sg > > > On Apr 11, 2025, at 7:10 AM, <slitkows.i...@gmail.com> > > <slitkows.i...@gmail.com> wrote: > > > > Hi, > > > > I have reviewed and I approve. > > > > > > -----Original Message----- > > From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > > Sent: Monday, April 7, 2025 5:35 PM > > To: Zhenghaomian <zhenghaom...@huawei.com> > > Cc: slitkows.i...@gmail.com; Dhruv Dhody <d...@dhruvdhody.com>; Cheng Li > > <c...@huawei.com>; RFC Editor <rfc-edi...@rfc-editor.org>; > > pce-...@ietf.org; pce-cha...@ietf.org; Roman Danyliw <r...@cert.org>; > > auth48archive@rfc-editor.org > > Subject: Re: AUTH48: RFC-to-be 9753 > > <draft-ietf-pce-stateful-pce-optional-13> for your review > > > > Hi Haomian, > > > > Thank you for your review. We have noted your approval on the AUTH48 page > > <https://www.rfc-editor.org/auth48/rfc9753>. > > > > Thank you, > > RFC Editor/sg > > > >> On Apr 7, 2025, at 1:28 AM, Zhenghaomian <zhenghaom...@huawei.com> wrote: > >> > >> Hi Sandy, all, > >> > >> I am writing to approve the changes, thank you for the work. > >> > >> Best wishes, > >> Haomian > >> > >> -----邮件原件----- > >> 发件人: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >> 发送时间: 2025年4月7日 9:19 > >> 收件人: Zhenghaomian <zhenghaom...@huawei.com>; slitkows.i...@gmail.com; > >> Dhruv Dhody <d...@dhruvdhody.com> > >> 抄送: Cheng Li <c...@huawei.com>; RFC Editor > >> <rfc-edi...@rfc-editor.org>; slitkows.i...@gmail.com; > >> pce-...@ietf.org; pce-cha...@ietf.org; Roman Danyliw <r...@cert.org>; > >> auth48archive@rfc-editor.org > >> 主题: Re: AUTH48: RFC-to-be 9753 > >> <draft-ietf-pce-stateful-pce-optional-13> for your review > >> > >> Greetings Haomian and Stephane, > >> > >> This is a friendly reminder that we await your review and approval before > >> continuing with the publication process. Please review the document at > >> the URLs listed below and let us know if updates are needed. > >> > >> Thank you, > >> RFC Editor/sg > >> > >> > >> > >>> On Apr 2, 2025, at 9:23 AM, Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>> wrote: > >>> > >>> Hi Dhruv, > >>> > >>> Thanks for your review. We have updated the text and posted the revised > >>> files here: > >>> https://www.rfc-editor.org/authors/rfc9753.xml > >>> https://www.rfc-editor.org/authors/rfc9753.txt > >>> https://www.rfc-editor.org/authors/rfc9753.pdf > >>> https://www.rfc-editor.org/authors/rfc9753.html > >>> > >>> Diffs highlighting the more recent updates: > >>> https://www.rfc-editor.org/authors/rfc9753-lastdiff.html > >>> https://www.rfc-editor.org/authors/rfc9753-lastrfcdiff.html (side by > >>> side) > >>> > >>> AUTH48 diffs: > >>> https://www.rfc-editor.org/authors/rfc9753-auth48diff.html > >>> https://www.rfc-editor.org/authors/rfc9753-auth48rfcdiff.html (side > >>> by side) > >>> > >>> Comprehensive diffs: > >>> https://www.rfc-editor.org/authors/rfc9753-diff.html > >>> https://www.rfc-editor.org/authors/rfc9753-rfcdiff.html (side by > >>> side) > >>> > >>> Thanks, > >>> RFC Editor/sg > >>> > >>> > >>>> On Apr 2, 2025, at 8:58 AM, Dhruv Dhody <d...@dhruvdhody.com> wrote: > >>>> > >>>> Hi Sandy, > >>>> > >>>> One tiny nit, We have one instance of "PCinit message" and one > >>>> instance of "PCinitiate message"; please change both to PCInitiate > >>>> message (as per RFC 8281) > >>>> > >>>> Thanks! > >>>> Dhruv > >>>> > >>>> On Wed, Apr 2, 2025 at 9:11 PM Sandy Ginoza > >>>> <sgin...@staff.rfc-editor.org> wrote: > >>>> Hi Cheng, > >>>> > >>>> Thank you for reply. We have updated the text and posted the revised > >>>> files. We believe you approve the RFC for publication, so we have noted > >>>> your approval on the AUTH48 page > >>>> <https://www.rfc-editor.org/auth48/rfc9753>. We will wait to hear from > >>>> your coauthors before continuing with publication. > >>>> > >>>> Current files: > >>>> https://www.rfc-editor.org/authors/rfc9753.xml > >>>> https://www.rfc-editor.org/authors/rfc9753.txt > >>>> https://www.rfc-editor.org/authors/rfc9753.pdf > >>>> https://www.rfc-editor.org/authors/rfc9753.html > >>>> > >>>> Diffs of the most recent update: > >>>> https://www.rfc-editor.org/authors/rfc9753-lastdiff.html > >>>> https://www.rfc-editor.org/authors/rfc9753-lastrfcdiff.html (side > >>>> by side) > >>>> > >>>> AUTH48 diffs: > >>>> https://www.rfc-editor.org/authors/rfc9753-auth48diff.html > >>>> https://www.rfc-editor.org/authors/rfc9753-auth48rfcdiff.html (side > >>>> by side) > >>>> > >>>> Comprehensive diffs: > >>>> https://www.rfc-editor.org/authors/rfc9753-diff.html > >>>> https://www.rfc-editor.org/authors/rfc9753-rfcdiff.html (side by > >>>> side) > >>>> > >>>> Thank you, > >>>> RFC Editor/sg > >>>> > >>>> > >>>> > >>>>> On Apr 2, 2025, at 2:02 AM, Cheng Li <c...@huawei.com> wrote: > >>>>> > >>>>> Hi Sandy, > >>>>> > >>>>> Just to be clear. I confirm that we can publish the RFC. > >>>>> > >>>>> Thanks, > >>>>> Cheng > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Cheng Li > >>>>> Sent: Friday, March 28, 2025 11:20 AM > >>>>> To: 'Sandy Ginoza' <sgin...@staff.rfc-editor.org> > >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Zhenghaomian > >>>>> <zhenghaom...@huawei.com>; slitkows.i...@gmail.com; > >>>>> pce-...@ietf.org; pce-cha...@ietf.org; d...@dhruvdhody.com; Roman > >>>>> Danyliw <r...@cert.org>; auth48archive@rfc-editor.org > >>>>> Subject: RE: AUTH48: RFC-to-be 9753 > >>>>> <draft-ietf-pce-stateful-pce-optional-13> for your review > >>>>> > >>>>> Hi Sandy, > >>>>> > >>>>> Sorry for my delay. > >>>>> I think the current text is good to me. > >>>>> > >>>>> Regarding the new text you suggested below, I think I can understand it > >>>>> without problem. And the current text in the link is also ok to me. > >>>>> Therefore, you can choose the better one from your point of view. > >>>>> > >>>>> Based the NEW text, we suggest this update: > >>>>> > >>>>>> The scope of how P and I flags are applied is defined in > >>>>>> [RFC5440] and is unchanged by this document. Therefore, these flags > >>>>>> can only be applied to an entire PCEP object; they cannot be applied > >>>>>> at the granularity of optional TLVs encoded in the PCEP Object. > >>>>> > >>>>> For the notes in the XML file(which are not shown in the text/website), > >>>>> I think they can be removed. > >>>>> > >>>>> Thanks, > >>>>> Cheng > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> -----Original Message----- > >>>>> From: Sandy Ginoza <sgin...@staff.rfc-editor.org> > >>>>> Sent: Tuesday, March 18, 2025 11:42 AM > >>>>> To: Cheng Li <c...@huawei.com> > >>>>> Cc: RFC Editor <rfc-edi...@rfc-editor.org>; Zhenghaomian > >>>>> <zhenghaom...@huawei.com>; slitkows.i...@gmail.com; > >>>>> pce-...@ietf.org; pce-cha...@ietf.org; d...@dhruvdhody.com; Roman > >>>>> Danyliw <r...@cert.org>; auth48archive@rfc-editor.org > >>>>> Subject: Re: AUTH48: RFC-to-be 9753 > >>>>> <draft-ietf-pce-stateful-pce-optional-13> for your review > >>>>> > >>>>> Hi Cheng, > >>>>> > >>>>> We have updated the document as described below except for the item > >>>>> you’ve asked the authors to review. The updated files are available > >>>>> here: > >>>>> https://www.rfc-editor.org/authors/rfc9753.xml > >>>>> https://www.rfc-editor.org/authors/rfc9753.txt > >>>>> https://www.rfc-editor.org/authors/rfc9753.pdf > >>>>> https://www.rfc-editor.org/authors/rfc9753.html > >>>>> > >>>>> AUTH48 diffs: > >>>>> https://www.rfc-editor.org/authors/rfc9753-auth48diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9753-auth48rfcdiff.html > >>>>> (side by side) > >>>>> > >>>>> Comprehensive files: > >>>>> https://www.rfc-editor.org/authors/rfc9753-diff.html > >>>>> https://www.rfc-editor.org/authors/rfc9753-rfcdiff.html (side by > >>>>> side) > >>>>> > >>>>> > >>>>> Please review our suggested update for the new text below and let us > >>>>> know if you approve. > >>>>> > >>>>>> OLD: > >>>>>> Further, it should be noted that similar to handling of P and I > >>>>>> flags in [RFC5440], the flag applies to full PCEP Object and > >>>>>> could not be applied to the granularity of an optional TLVs > >>>>>> encoded in the PCEP Object. > >>>>>> > >>>>>> > >>>>>> NEW: > >>>>>> > >>>>>> This document does not modify the scope that P and I flags can be > >>>>>> applied to, as defined in [RFC5440]. Therefore, these flags will only > >>>>>> be applied to an entire PCEP object, and cannot be applied to the > >>>>>> granularity of an optional TLVs encoded in the PCEP Object. > >>>>> > >>>>> > >>>>> Based the NEW text, we suggest this update: > >>>>> > >>>>>> The scope of how P and I flags are applied is defined in > >>>>>> [RFC5440] and is unchanged by this document. Therefore, these flags > >>>>>> can only be applied to an entire PCEP object; they cannot be applied > >>>>>> at the granularity of optional TLVs encoded in the PCEP Object. > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Also, we see this text commented out in the XML file. Please consider > >>>>> whether any action is needed; otherwise the notes will be removed. > >>>>> > >>>>> <!--Similarly in the case of an association group > >>>>> <xref target="RFC8697"/> such as Disjoint Association <xref > >>>>> > >>>>> target="RFC8800"/>, the PCE may need to completely relax the > >>>>> > >>>>> disjointness constraint in order to provide a path to all the LSPs > >>>>> > >>>>> that are part of the association.—> > >>>>> > >>>>> <!--By default, the PCE SHOULD set the P > >>>>> flag, unless a > >>>>> > >>>>> local configuration or local policy indicates that some > >>>>> constraints > >>>>> (corresponding PCEP objects) can be marked as optional and could > >>>>> be > >>>>> ignored by the PCC.--> > >>>>> > >>>>> Thank you, > >>>>> RFC Editor/sg > >>>>> > >>>>> > >>>>> > >>>>> > >>>>>> On Mar 12, 2025, at 2:07 AM, Cheng Li > >>>>>> <c.l=40huawei....@dmarc.ietf.org> wrote: > >>>>>> > >>>>>> Hi RFC Editors, > >>>>>> > >>>>>> Please see my reply inline. Thanks for your work! > >>>>>> > >>>>>> Specially, authors, please review this modification proposal. > >>>>>> > >>>>>> > >>>>>> OLD: > >>>>>> Further, it should be noted that similar to handling of P and I > >>>>>> flags in [RFC5440], the flag applies to full PCEP Object and > >>>>>> could not be applied to the granularity of an optional TLVs > >>>>>> encoded in the PCEP Object. > >>>>>> > >>>>>> > >>>>>> NEW: > >>>>>> > >>>>>> This document does not modify the scope that P and I flags can be > >>>>>> applied to, as defined in [RFC5440]. Therefore, these flags will only > >>>>>> be applied to an entire PCEP object, and cannot be applied to the > >>>>>> granularity of an optional TLVs encoded in the PCEP Object. > >>>>>> > >>>>>> Authors, please review this change. > >>>>>> > >>>>>> > >>>>>> Thanks, > >>>>>> Cheng > >>>>>> > >>>>>> -----Original Message----- > >>>>>> From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > >>>>>> Sent: Monday, March 10, 2025 7:24 AM > >>>>>> To: Cheng Li <c...@huawei.com>; Zhenghaomian > >>>>>> <zhenghaom...@huawei.com>; slitkows.i...@gmail.com > >>>>>> Cc: rfc-edi...@rfc-editor.org; pce-...@ietf.org; > >>>>>> pce-cha...@ietf.org; d...@dhruvdhody.com; r...@cert.org; > >>>>>> auth48archive@rfc-editor.org > >>>>>> Subject: Re: AUTH48: RFC-to-be 9753 > >>>>>> <draft-ietf-pce-stateful-pce-optional-13> 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] Please insert any keywords (beyond those that > >>>>>> appear in the title) for use on https://www.rfc-editor.org/search. > >>>>>> --> [Cheng] PCEP, Stateful, optional processing > >>>>>> > >>>>>> 2) <!-- [rfced] We are having trouble parsing this sentence. Please > >>>>>> consider whether the suggested text conveys the intended meaning. > >>>>>> > >>>>>> Original: > >>>>>> [RFC5440] describes the handling of unknown objects as per the > >>>>>> setting of the P flag for the PCReq message. > >>>>>> > >>>>>> Perhaps: > >>>>>> Setting the P flag in the PCReq message to handle unknown objects > >>>>>> is as described in Section 7.2 of [RFC5440]. > >>>>>> --> > >>>>>> [Cheng]OK > >>>>>> > >>>>>> > >>>>>> 3) <!-- [rfced] Does marking something as optional allow the PCEP peer > >>>>>> to ignore the object? If yes, may we update the text as follows? > >>>>>> > >>>>>> Original: > >>>>>> In these cases, it would be useful to mark the objects as > >>>>>> 'optional' and they could be ignored by the PCEP peer. > >>>>>> > >>>>>> Perhaps: > >>>>>> In these cases, it would be useful to mark the objects as > >>>>>> 'optional' so they could be ignored by the PCEP peer. > >>>>>> --> > >>>>>> [Cheng]OK > >>>>>> > >>>>>> 4) <!-- [rfced] We are having trouble parsing this text. It refers to > >>>>>> the P and I flags, but then switches to "the flag". Does "the flag" > >>>>>> refer to the R flag, which has not yet been introduced? Please review > >>>>>> and let us know how the text may be clarified. > >>>>>> > >>>>>> Original (prior sentence included for context): > >>>>>> Thus, this document specifies how the already existing P and I > >>>>>> flags in the PCEP common object header could be used during the > >>>>>> stateful PCEP message exchange. Further, it should be noted that > >>>>>> similar to handling of P and I flags in [RFC5440], the flag > >>>>>> applies to full PCEP Object and could not be applied to the > >>>>>> granularity of an optional TLVs encoded in the PCEP Object. > >>>>>> > >>>>>> Perhaps: > >>>>>> Further, it should be noted that, similar to handling of P and I > >>>>>> flags in [RFC5440], the flag indicating that the constraint has > >>>>>> been relaxed applies to the full PCEP object and cannot be > >>>>>> applied at the granularity of an optional TLV encoded in the PCEP > >>>>>> object. > >>>>>> --> > >>>>>> [Cheng]I do not think 'the flag' is correct here. It should not be the > >>>>>> R flag, but the 'P and I flags'. After discussing with Dhruv, we > >>>>>> confirm that we should use the flags(P and I flags). Please see the > >>>>>> new text below. > >>>>>> > >>>>>> OLD: > >>>>>> Further, it should be noted that similar to handling of P and I > >>>>>> flags in [RFC5440], the flag applies to full PCEP Object and > >>>>>> could not be applied to the granularity of an optional TLVs > >>>>>> encoded in the PCEP Object. > >>>>>> > >>>>>> > >>>>>> NEW: > >>>>>> > >>>>>> This document does not modify the scope that P and I flags can be > >>>>>> applied to, as defined in [RFC5440]. Therefore, these flags will only > >>>>>> be applied to an entire PCEP object, and cannot be applied to the > >>>>>> granularity of an optional TLVs encoded in the PCEP Object. > >>>>>> > >>>>>> Authors, please review this change. > >>>>>> > >>>>>> > >>>>>> > >>>>>> 5) <!-- [rfced] PCUpd seems to be exapnded slightly differently in two > >>>>>> places. Based on what we see in RFC 8231 (see below), we don't > >>>>>> believe the terms are interchangeable. Please review and let us know > >>>>>> how/if these should be made consistent? Perhaps Section 3.3.2 can > >>>>>> just refer to PCUpd and PCInitiate since those terms are introduced > >>>>>> earlier in the document? > >>>>>> > >>>>>> Section 1: Path Computation Update Request (PCUpd) > >>>>>> This document defines a new flag, the R > >>>>>> (RELAX) flag in STATEFUL-PCE-CAPABILITY TLV in the PCEP common > >>>>>> object header to indicate a PCE speaker supporting P and I flags > >>>>>> processing, and also specifies how the P and I flags could be > >>>>>> used in the stateful PCE model to identify optional objects in > >>>>>> the Path Computation State Report (PCRpt) [RFC8231], the Path > >>>>>> Computation Update Request (PCUpd) [RFC8231], and the LSP > >>>>>> Initiate Request > >>>>>> (PCInitiate) [RFC8281] message. > >>>>>> > >>>>>> Section 3.3.2: LSP Update Request (PCUpd) The I flag in the PCRpt > >>>>>> message [RFC8231] allows a PCC to indicate to a PCE whether or > >>>>>> not an optional object was processed in response to an LSP Update > >>>>>> Request (PCUpd) or LSP Initiate Request (PCInitiate). > >>>>>> > >>>>>> > >>>>>> From RFC 8231: > >>>>>> Path Computation Update Request (PCUpd) > >>>>>> > >>>>>> Section 6.2 of RFC 8231: > >>>>>> A PCUpd message can carry more than one LSP Update Request. > >>>>>> --> > >>>>>> [Cheng]It takes few minutes to understand the problem. Ha, we can > >>>>>> change LSP update request to PCUpd message, and LSP Initiate request > >>>>>> to PCinit message. The purpose is not to emphasize the LSP, but the > >>>>>> message. > >>>>>> > >>>>>> > >>>>>> 6) <!-- [rfced] We are having trouble parsing this sentence. Please > >>>>>> consider whether the suggested text is more clear. Otherwise, please > >>>>>> clarify. > >>>>>> > >>>>>> Original: > >>>>>> This document updates the handling of unknown objects in the > >>>>>> stateful PCEP messages as per the setting of the P flag in the > >>>>>> common object header in a similar way as [RFC5440], i.e. if a > >>>>>> PCEP speaker does not understand an object with the P flag set or > >>>>>> understands the object but decides to ignore the object, the > >>>>>> entire stateful PCEP message MUST be rejected and the PCE MUST > >>>>>> send a PCErr message with Error- Type="Unknown Object" or "Not > >>>>>> supported Object" [RFC5440]. > >>>>>> > >>>>>> Perahps: > >>>>>> This document updates the handling of unknown objects in the > >>>>>> stateful PCEP messages by setting the P flag in the common object > >>>>>> header in a similar way as described in [RFC5440]. That is, if a > >>>>>> PCEP speaker does not understand an object with the P flag set, > >>>>>> or if the PCEP speaker understands the object but decides to > >>>>>> ignore the object, the entire stateful PCEP message MUST be > >>>>>> rejected, and the PCE MUST send a PCErr message with Error- > >>>>>> Type="Unknown Object" > >>>>>> or "Not supported object" [RFC5440]. > >>>>>> --> > >>>>>> > >>>>>> [Cheng]ok, thanks! Will avoid to use 'as per' next time, and try > >>>>>> to make the subject of a sentence clear 😊 > >>>>>> > >>>>>> > >>>>>> 7) <!-- [rfced] Note that we have lowercased "object" when it appears > >>>>>> as "PCEP object" to align with use in the referenced RFCs (e.g., 9753, > >>>>>> 5440). > >>>>>> Please let us know if any updates are needed. > >>>>>> --> > >>>>>> [Cheng]please follow the best practice, I am ok with lowercase or > >>>>>> uppercase. Thanks. > >>>>>> > >>>>>> > >>>>>> 8) <!-- [rfced] Please review the "Inclusive Language" portion of > >>>>>> the online Style Guide > >>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language> > >>>>>> and let us know if any changes are needed. Updates of this > >>>>>> nature typically result in more precise language, which is helpful for > >>>>>> readers. > >>>>>> > >>>>>> Note that our script did not flag any words in particular, but > >>>>>> this should still be reviewed as a best practice. > >>>>>> --> > >>>>>> [Cheng]no change needed, thanks! > >>>>>> > >>>>>> I have review the diff file, the modification is ok to me. > >>>>>> > >>>>>> > >>>>>> Thank you. > >>>>>> > >>>>>> RFC Editor > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Mar 9, 2025, at 11:16 PM, rfc-edi...@rfc-editor.org wrote: > >>>>>> > >>>>>> *****IMPORTANT***** > >>>>>> > >>>>>> Updated 2025/03/09 > >>>>>> > >>>>>> 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-edi...@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-4Q9l > >>>>>> 2 > >>>>>> U > >>>>>> SxI > >>>>>> Ae6P8O4Zc > >>>>>> > >>>>>> * 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/rfc9753.xml > >>>>>> https://www.rfc-editor.org/authors/rfc9753.html > >>>>>> https://www.rfc-editor.org/authors/rfc9753.pdf > >>>>>> https://www.rfc-editor.org/authors/rfc9753.txt > >>>>>> > >>>>>> Diff file of the text: > >>>>>> https://www.rfc-editor.org/authors/rfc9753-diff.html > >>>>>> https://www.rfc-editor.org/authors/rfc9753-rfcdiff.html (side by > >>>>>> side) > >>>>>> > >>>>>> Diff of the XML: > >>>>>> https://www.rfc-editor.org/authors/rfc9753-xmldiff1.html > >>>>>> > >>>>>> > >>>>>> Tracking progress > >>>>>> ----------------- > >>>>>> > >>>>>> The details of the AUTH48 status of your document are here: > >>>>>> https://www.rfc-editor.org/auth48/rfc9753 > >>>>>> > >>>>>> Please let us know if you have any questions. > >>>>>> > >>>>>> Thank you for your cooperation, > >>>>>> > >>>>>> RFC Editor > >>>>>> > >>>>>> -------------------------------------- > >>>>>> RFC 9753 (draft-ietf-pce-stateful-pce-optional-13) > >>>>>> > >>>>>> Title : Extension for Stateful PCE to allow Optional > >>>>>> Processing of PCE Communication Protocol (PCEP) Objects > >>>>>> Author(s) : C. Li, H. Zheng, S. Litkowski > >>>>>> WG Chair(s) : Julien Meuric, Dhruv Dhody > >>>>>> > >>>>>> Area Director(s) : Jim Guichard, John Scudder, Gunter Van de > >>>>>> Velde > >>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >> > > > > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
