Hi Siva, Thank you for your reply. We have noted your approval on the AUTH48 page <https://www.rfc-editor.org/auth48/rfc9752>. We have received all of the needed approvals and will continue with publication shortly.
Thank you, RFC Editor/sg > On Apr 2, 2025, at 7:25 AM, Siva Sivabalan <msiva...@gmail.com> wrote: > > Looks good. > > Thanks, > Siva > > On Tue, Mar 11, 2025 at 6:18 PM Cheng Li <c...@huawei.com> wrote: > Hi RFC editor, > > Thanks for your work! The diff looks good to me. > > For the questions, please see my reply inline. > > Thanks, > Cheng > > > > -----Original Message----- > From: rfc-edi...@rfc-editor.org <rfc-edi...@rfc-editor.org> > Sent: Monday, March 10, 2025 7:23 AM > To: Cheng Li <c...@huawei.com>; Zhenghaomian <zhenghaom...@huawei.com>; > msiva...@gmail.com; ssi...@cisco.com; z...@cisco.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 9752 <draft-ietf-pce-stateful-pce-vendor-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]PCE, Vendor specific, vendor-specific > > 2) <!-- [rfced] "to revise the refrence to the IANA registry" is unclear > without further context. Please consider whether the suggested text > clarifies the intent. > > Original: > This document updates RFC 7470 to revise the reference to the IANA > registry for managing Enterprise Numbers. > > Perhaps: > This document updates RFC 7470 to specify that Enterprise numbers > are managed through the "Private Enterprise Numbers (PENs)" registry. > --> > [Cheng]OK > > 3) <!-- [rfced] For clarity, may we update the text as follows? > > Original: > The format of the PCUpd message (with Section 6.2 of [RFC8231] as the > base) is updated as follows: > > ... > > The format of the PCInitiate message (with Section 5.1 of [RFC8281] > as the base) is updated as follows: > > Perhaps: > The format of the PCUpd message (using the format described in > Section 6.2 of [RFC8231] as the base) is updated as follows: > > ... > > The format of the PCInitiate message (using the format > described in Section 5.1 of [RFC8281] as the base) > is updated as follows: > --> > [Cheng]OK > > > 4) <!-- [rfced] The use of "as per" twice in this sentence is confusing. > As it seems the second instance refers to best practices for implementing > TLS, please consider the update below. > > Original: > As per [RFC8231] it is RECOMMENDED that these PCEP extensions only be > activated on authenticated and encrypted sessions across PCEs and > PCCs using Transport Layer Security (TLS) [RFC8253], as per the > recommendations and best current practices in RFC 9325 [BCP195]. > > Perhaps: > Per [RFC8231], it is RECOMMENDED that these PCEP extensions only be > activated on authenticated and encrypted sessions across PCEs and > PCCs using Transport Layer Security (TLS) [RFC8253]. See the > recommendations and best current practices for using TLS in > RFC 9325 [BCP195]. > --> > [Cheng]OK > > 5) <!-- [rfced] We updated artwork to sourcecode in Section 2, with type set > to "rbnf". Please review and let us know if any updates are needed. > > The current list of preferred values for "type" is available at > <https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types>. > If the current list does not contain an applicable type, feel free to suggest > additions for consideration. Note that it is also acceptable to leave the > "type" attribute not set. > --> > [Cheng]I do not have opinion here, so OK with that. > > > 6) <!-- [rfced] Throughout the text, the following terminology appears to be > used inconsistently. > > - Vendor Information Object vs Vendor Information object (per RFC 7470) > > We have updated this as "Vendor Information object". Please let us know any > objections. > [Cheng]ok with me. > > - Please review the capitalization of stateful in the following and let us > know if/how they should be made consistent. > > stateful PCE operations > Stateful PCE > Stateful PCE deployment > Stateful PCE model > Stateful PCE extensions > Stateful PCEP extensions > Stateful PCEP messages > stateful PCEP message > stateful PCEP objects > --> > > [Cheng]well, thanks! I did not notice this. > I checked RFC8231, it use uppercase and lowercase ones as well. But in most > cases, the lowercase one is used. Therefore, I may prefer to use lowercase > 'stateful' > > > > 7) <!-- [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]OK to me, no change is needed. > > Thank you. > > RFC Editor > > > > On Mar 9, 2025, at 11:14 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-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/rfc9752.xml > https://www.rfc-editor.org/authors/rfc9752.html > https://www.rfc-editor.org/authors/rfc9752.pdf > https://www.rfc-editor.org/authors/rfc9752.txt > > Diff file of the text: > https://www.rfc-editor.org/authors/rfc9752-diff.html > https://www.rfc-editor.org/authors/rfc9752-rfcdiff.html (side by side) > > Diff of the XML: > https://www.rfc-editor.org/authors/rfc9752-xmldiff1.html > > > Tracking progress > ----------------- > > The details of the AUTH48 status of your document are here: > https://www.rfc-editor.org/auth48/rfc9752 > > Please let us know if you have any questions. > > Thank you for your cooperation, > > RFC Editor > > -------------------------------------- > RFC 9752 (draft-ietf-pce-stateful-pce-vendor-13) > > Title : Conveying Vendor-Specific Information in the Path > Computation Element (PCE) Communication Protocol (PCEP) extensions for > Stateful PCE. > Author(s) : C. Li, H. Zheng, S. Sivabalan, S. Sidor, Z. Ali > 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
