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]
