Dear Megan, Please add one more space (as it was originally and similar to https://datatracker.ietf.org/doc/html/rfc9643#name-features).
Other than this, all perfect. Thanks you. Regards, Alex > On 15 May 2026, at 17:59, Megan Ferguson <[email protected]> > wrote: > > Alex, > > Thanks for the clarification; we have left the yang tree as was with regard > to pluralization and have updated the alignment to match the New: text in > your message (the plus lining up under the “e” of Features). You mentioned > two spaces in your message, but this was a single space update. Please let > us know if any further spacing is necessary. > > Note that this change has been added to the current version: please refresh > to view. > > The files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9984.txt > https://www.rfc-editor.org/authors/rfc9984.pdf > https://www.rfc-editor.org/authors/rfc9984.html > https://www.rfc-editor.org/authors/rfc9984.xml > > The diff files have been posted here (please refresh): > https://www.rfc-editor.org/authors/rfc9984-diff.html (comprehensive) > https://www.rfc-editor.org/authors/rfc9984-rfcdiff.html (side by side) > > https://www.rfc-editor.org/authors/rfc9984-auth48diff.html (AUTH48 changes > only) > https://www.rfc-editor.org/authors/rfc9984-auth48rfcdiff.html (side by side) > > The AUTH48 status page for this document is available here: > https://www.rfc-editor.org/auth48/rfc9984 > > Thank you. > > Megan Ferguson > RFC Production Center > >> On May 14, 2026, at 1:10 PM, Alex Huang Feng <[email protected]> >> wrote: >> >> Dear Megan, >> >> The term Features (plural) is used in text and in the yangtree of Section >> 2.1.1 to show which “features” are implemented in YANG. The term in plural >> here is correct, similar to Section 2.1.2 of RFC9643. >> This text aims at providing a diagram example for the reader. As RFC 8340 >> does not define a way to show the features in a yangtree, we use a similar >> notation. Hence the text stating that this syntax is similar but not defined >> in RFC8340. >> >> On the other hand, in the YANG module, the keyword “feature” (singular) is >> used. Singular is correct here, as it is defined in Section 7.20.1 of >> RFC7950. >> >> So, in a nutshell, please leave them as they are currently. We do feel the >> sourcecode (yangtree) from Section 2.1.1 is useful for the reader. >> >> Also, checking now, there are two spaces that have been removed in this new >> version. Please add them back: >> >> OLD: >> Features: >> +-- local-binding >> >> NEW: >> Features: >> +-- local-binding >> >> Thanks and regards, >> Alex >> >>> On 14 May 2026, at 17:27, Megan Ferguson <[email protected]> >>> wrote: >>> >>> Hi Alex, >>> >>> Thank you for your reply and guidance. >>> >>> Just one follow up as I may have bungled the question wording (based on >>> your response): >>> >>> In the yangtree sourcecode in Section 2.1.1, we see: >>> >>> Features: >>> +-- local-binding >>> >>> where Features is plural. >>> >>> However, in the YANG module we see: >>> >>> feature local-binding { >>> >>> where feature is singular. >>> >>> Please confirm whether any Section 2.1.1’s sourcecode are necessary. >>> >>> All other updates have been made to the file, the keywords you suggested >>> have been added to our database, and resolved queries have been removed >>> from the XML file. >>> >>> As you indicated your approval of the document in your last message, we >>> have updated your status to “Approved” at the AUTH48 status page (see link >>> below). However, we will necessitate a response to the above query from >>> you or one of your coauthors prior to continuing the publication process. >>> Note that we will assume your assent to any changes submitted by your >>> coauthors unless we hear otherwise at that time. >>> >>> Please review carefully as we do not make changes once the document is >>> published as an RFC. >>> >>> The files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9984.txt >>> https://www.rfc-editor.org/authors/rfc9984.pdf >>> https://www.rfc-editor.org/authors/rfc9984.html >>> https://www.rfc-editor.org/authors/rfc9984.xml >>> >>> The diff files have been posted here (please refresh): >>> https://www.rfc-editor.org/authors/rfc9984-diff.html (comprehensive) >>> https://www.rfc-editor.org/authors/rfc9984-rfcdiff.html (side by side) >>> >>> https://www.rfc-editor.org/authors/rfc9984-auth48diff.html (AUTH48 changes >>> only) >>> https://www.rfc-editor.org/authors/rfc9984-auth48rfcdiff.html (side by side) >>> >>> The AUTH48 status page for this document is available here: >>> https://www.rfc-editor.org/auth48/rfc9984 >>> >>> Thank you. >>> >>> Megan Ferguson >>> RFC Production Center >>> >>> >>>> On May 14, 2026, at 8:21 AM, Alex Huang Feng >>>> <[email protected]> wrote: >>>> >>>> Dear RFC editor, >>>> >>>> I approve this RFC for publication. >>>> >>>> Please find below the response to the different questions: >>>> >>>> 1) Following the publication of RFC 9643, I would rather keep consistency >>>> here, so, please leave the title as is: >>>> "YANG Groupings for UDP Clients and UDP Servers” >>>> >>>> 2) Keywords: UDP client, UDP server >>>> >>>> 3) Please update and use “presents” as used in cluster C463: >>>> >>>> OLD: >>>> This document defines two YANG 1.1 modules with reusable >>>> groupings for managing UDP clients and UDP servers. >>>> >>>> NEW: >>>> This document presents two YANG 1.1 modules with reusable >>>> groupings for managing UDP clients and UDP servers. >>>> >>>> 4) No updates are necessary >>>> >>>> 5) The use of Features (plural) in the title and text is correct. The use >>>> of Feature (singular) in other parts of the document is correct (including >>>> the YANG module). >>>> >>>> 6) Please apply the change as proposed: >>>> >>>> OLD: >>>> The diagram above uses syntax that is similar to but not defined in >>>> [RFC8340]. >>>> >>>> NEW: >>>> The diagram above uses syntax that is similar to the syntax used in >>>> [RFC8340]; but the syntax from the diagram is not defined in >>>> [RFC8340]. >>>> >>>> 7) I confirm the changes applied to the YANG module are correct. >>>> >>>> 8) >>>> - a) No objections to match template from >>>> https://wiki.ietf.org/group/ops/yang-security-guidelines - b) No objections >>>> >>>> Regards, >>>> Alex >>>> >>>>> On 13 May 2026, at 21:39, [email protected] wrote: >>>>> >>>>> Authors, >>>>> >>>>> While reviewing this document during AUTH48, please resolve (as >>>>> necessary) the following questions, which are also in the source file. >>>>> >>>>> 1) <!--[rfced] We note that most of the recently published RFCs >>>>> containing YANG modules format their titles as "A YANG Data Model >>>>> for...", for example: >>>>> >>>>> RFC 9094 - A YANG Data Model for Wavelength Switched Optical Networks >>>>> (WSONs) >>>>> RFC 9093 - A YANG Data Model for Layer 0 Types >>>>> RFC 9067 - A YANG Data Model for Routing Policy >>>>> >>>>> Please consider whether the title of this document should be updated. >>>>> >>>>> Current: >>>>> YANG Groupings for UDP Clients and UDP Servers >>>>> >>>>> Please also consider if the repetition of UDP is necessary: >>>>> >>>>> Perhaps: >>>>> YANG Groupings for UDP Clients and Servers >>>>> >>>>> (Note: the title appears in more places throughout the document.) >>>>> --> >>>>> >>>>> >>>>> 2) <!-- [rfced] Please insert any keywords (beyond those that appear in >>>>> the title) for use on https://www.rfc-editor.org/search. --> >>>>> >>>>> >>>>> 3) <!--[rfced] We note that this document uses "defines" where other >>>>> documents in cluster C463 use "presents". Please let us know if >>>>> you'd like to update. Note that similar text appears more than >>>>> once in the document. >>>>> >>>>> Original: >>>>> This document defines two YANG 1.1 modules with reusable >>>>> groupings for managing UDP clients and UDP servers. >>>>> >>>>> Perhaps: >>>>> This document presents two YANG 1.1 modules with reusable >>>>> groupings for managing UDP clients and UDP servers. >>>>> --> >>>>> >>>>> >>>>> 4) <!--[rfced] We note that RFC 9643 (that you mentioned in the document >>>>> intake form) and the other documents in cluster C463 all have a >>>>> section titled "Relation to Other RFCs". Please review and let >>>>> us know if any updates to this document are necessary. --> >>>>> >>>>> >>>>> 5) <!--[rfced] Please review the use of "Features" (plural) in the >>>>> feature statement in Section 2.1.1. Elsewhere in the document we >>>>> see Feature (singular). >>>>> >>>>> For example, in the module: >>>>> feature local-binding { >>>>> --> >>>>> >>>>> >>>>> 6) <!--[rfced] Please review our update to the following text to ensure >>>>> we've maintained your intended meaning: >>>>> >>>>> Original: >>>>> The diagram above uses syntax that is similar to but not defined in >>>>> [RFC8340]. >>>>> >>>>> Current: >>>>> The diagram above uses syntax that is similar to the syntax used in >>>>> [RFC8340]; but the syntax from the diagram is not defined in >>>>> [RFC8340]. >>>>> --> >>>>> >>>>> >>>>> 7) <!--[rfced] We had the following questions related to the YANG modules >>>>> in Sections 2.3 and 3.3: >>>>> >>>>> a) FYI - We see that Kent Watson is not listed as an author on the >>>>> module. We will assume this was intentional unless we hear otherwise. >>>>> >>>>> b) We have made slight updates to the format of the modules with pyang >>>>> (e.g., indentation and whitespace). Please review in the text output >>>>> and confirm. >>>>> >>>>> --> >>>>> >>>>> >>>>> 8) <!--[rfced] We had the following questions related to the Security >>>>> Considerations section: >>>>> >>>>> a) Please review the following citation mismatch. We have updated to >>>>> match the security considerations template at >>>>> https://wiki.ietf.org/group/ops/yang-security-guidelines. Please let >>>>> us know any objections. >>>>> >>>>> Template: >>>>> ...have to use a secure transport layer (e.g., SSH [RFC4252],... >>>>> >>>>> In this document: >>>>> ...have to use a secure transport layer (e.g., SSH [RFC6242],... >>>>> >>>>> b) We have updated the following for consistent pluralization. Please >>>>> let us know any objections. >>>>> >>>>> Original: >>>>> As such, there are no additional security issues related to the YANG >>>>> module that need to be considered. >>>>> >>>>> Current: >>>>> As such, there are no additional security issues related to the YANG >>>>> modules that need to be considered. >>>>> --> >>>>> >>>>> >>>>> Thank you. >>>>> >>>>> Megan Ferguson >>>>> RFC Production Center >>>>> >>>>> *****IMPORTANT***** >>>>> >>>>> Updated 2026/05/13 >>>>> >>>>> 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 >>>>> >>>>> * [email protected] (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). >>>>> >>>>> * [email protected], 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, >>>>> [email protected] 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/rfc9984.xml >>>>> https://www.rfc-editor.org/authors/rfc9984.html >>>>> https://www.rfc-editor.org/authors/rfc9984.pdf >>>>> https://www.rfc-editor.org/authors/rfc9984.txt >>>>> >>>>> Diff file of the text: >>>>> https://www.rfc-editor.org/authors/rfc9984-diff.html >>>>> https://www.rfc-editor.org/authors/rfc9984-rfcdiff.html (side by side) >>>>> >>>>> Diff of the XML: >>>>> https://www.rfc-editor.org/authors/rfc9984-xmldiff1.html >>>>> >>>>> >>>>> Tracking progress >>>>> ----------------- >>>>> >>>>> The details of the AUTH48 status of your document are here: >>>>> https://www.rfc-editor.org/auth48/rfc9984 >>>>> >>>>> Please let us know if you have any questions. >>>>> >>>>> Thank you for your cooperation, >>>>> >>>>> RFC Editor >>>>> >>>>> -------------------------------------- >>>>> RFC9984 (draft-ietf-netconf-udp-client-server-10) >>>>> >>>>> Title : YANG Groupings for UDP Clients and UDP Servers >>>>> Author(s) : A. Huang-Feng, P. Francois, K. Watsen >>>>> WG Chair(s) : Kent Watsen, Per Andersson >>>>> >>>>> Area Director(s) : Mohamed Boucadair, Mahesh Jethanandani >>>>> >>>>> >>>> >>> >>> >>> >>> >>> >> > > > > >
-- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
