All, Happy New Year!
Just a status update that this document set awaits author action. Please let us know if we can be of assistance as you address our list of queries (see our initial message). Thank you. Megan Ferguson RFC Production Center > On Dec 1, 2025, at 7:47 AM, Megan Ferguson <[email protected]> > wrote: > > Hi Paul and Bob, > > No worries from our side and thanks for the updates! > > Megan Ferguson > RFC Production Center > > >> On Nov 25, 2025, at 5:08 PM, Mr. Jaehoon Paul Jeong <[email protected]> >> wrote: >> >> Hi Robert and Megan, >> I have been busy with my university teaching since the IETF 124. >> I will be able to work on this cluster of I2NSF drafts from next week. >> >> I am sorry for this delay. >> >> Thanks. >> >> Best Regards, >> Paul >> =========================== >> Mr. Jaehoon (Paul) Jeong >> Professor >> Department of Computer Science and Engineering >> Sungkyunkwan University >> Mobile: +82-10-4758-1765 >> Phone: +82-31-299-4957 >> Email: [email protected], [email protected] >> URI: http://iotlab.skku.edu/people-jaehoon-jeong.php >> >> >> 2025년 11월 26일 (수) 오전 7:08, Robert Moskowitz <[email protected]>님이 작성: >> I just found this thread in a supposedly inactive folder! >> >> I will attempt to figure it out... >> >> Bob >> >> >> On 11/3/25 12:27 PM, Mr. Jaehoon Paul Jeong wrote: >>> Megan, >>> Thanks for your understanding and support.:-) >>> >>> If I have questions about my work on this cluster, I will contact RFC >>> editors in Montreal. >>> >>> Thanks. >>> >>> Best Regards, >>> Paul >>> >>> On Mon, Nov 3, 2025 at 12:23 PM Megan Ferguson >>> <[email protected]> wrote: >>> Hi Paul, >>> >>> No problem from our end; please take the time you need. >>> >>> I am not in Montreal, but there are several editors from the RPC there with >>> office hours at the RFC Editor table. Please feel free to either stop by >>> and see them or email me directly if you have anything you’d like to ask as >>> you work through your revisions. >>> >>> Enjoy IETF 124! >>> >>> Megan Ferguson >>> RFC Production Center >>> >>>> On Nov 1, 2025, at 1:23 AM, Mr. Jaehoon Paul Jeong >>>> <[email protected]> wrote: >>>> >>>> Hi Megan, >>>> I need more time on this cluster of the I2NSF drafts because I was busy >>>> with my teaching and research last month. >>>> I am in Montreal for the IETF 124 Meeting, so I will focus on the revision >>>> of those drafts according to your comments. >>>> >>>> Thanks for your waiting and patience. >>>> >>>> Best Regards, >>>> Paul >>>> >>>> >>>> On Fri, Oct 10, 2025 at 1:37 AM Megan Ferguson >>>> <[email protected]> wrote: >>>> Paul, >>>> >>>> Perfect timing as I will be out of office next week. >>>> >>>> Note that if you do encounter any blocking issue that requires assistance >>>> in my absence, you can still reach out to [email protected] >>>> (otherwise, your response will be handled upon my return). >>>> >>>> Thank you. >>>> >>>> Megan Ferguson >>>> RFC Production Center >>>> >>>>> On Oct 9, 2025, at 8:21 AM, Mr. Jaehoon Paul Jeong >>>>> <[email protected]> wrote: >>>>> >>>>> Megan, >>>>> That's great! >>>>> >>>>> I will work on your questions from tomorrow for a week and will come back >>>>> to you >>>>> when I have them resolved in the five revised xml files. >>>>> >>>>> Thanks. >>>>> >>>>> Best Regards, >>>>> Paul >>>>> >>>>> On Thu, Oct 9, 2025 at 11:02 PM Megan Ferguson >>>>> <[email protected]> wrote: >>>>> Hi Paul, >>>>> >>>>> Thank you for sending along the ordering information; we have noted your >>>>> response and will use this information in our editing and RFC number >>>>> assignment. >>>>> >>>>> Note that these documents will remain in AUTH state until we hear back >>>>> with the updated files addressing Questions 1-10. >>>>> >>>>> Thank you for your attention to this document set! >>>>> >>>>> Megan Ferguson >>>>> RFC Production Center >>>>> >>>>> >>>>>> On Oct 9, 2025, at 4:41 AM, Mr. Jaehoon Paul Jeong >>>>>> <[email protected]> wrote: >>>>>> >>>>>> Hi Megan, >>>>>> Here are my answers as the editor of all these six drafts inline below. >>>>>> >>>>>> On Thu, Oct 2, 2025 at 10:58 PM Megan Ferguson >>>>>> <[email protected]> wrote: >>>>>> All, >>>>>> >>>>>> A further question: do you have guidance on reading order for these >>>>>> drafts? >>>>>> => Yes, we have guidance on reading order for them. >>>>>> >>>>>> >>>>>> If so, please let us know using an RFC NNNN, RFC NNNN+1, RFC NNNN+2 >>>>>> format. >>>>>> >>>>>> draft-ietf-i2nsf-nsf-facing-interface-dm-29 => RFC NNNN + 3 >>>>>> draft-ietf-i2nsf-nsf-monitoring-data-model-20 => RFC NNNN + 4 >>>>>> draft-ietf-i2nsf-applicability-18 => RFC NNNN + 5 >>>>>> draft-ietf-i2nsf-capability-data-model-32 => RFC NNNN >>>>>> draft-ietf-i2nsf-registration-interface-dm-26 => RFC NNNN + 1 >>>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-31 => RFC NNNN + 2 >>>>>> >>>>>> Thanks. >>>>>> >>>>>> Best Regards, >>>>>> Paul >>>>>> >>>>>> >>>>>> Thank you. >>>>>> >>>>>> Megan Ferguson >>>>>> RFC Production Center >>>>>> >>>>>>> On Oct 1, 2025, at 8:47 AM, Mr. Jaehoon Paul Jeong >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> Hi Megan, >>>>>>> Sure, we can work on those documents together. >>>>>>> If I need your help, I will let you know. >>>>>>> >>>>>>> Thanks. >>>>>>> >>>>>>> Best Regards, >>>>>>> Paul >>>>>>> =========================== >>>>>>> Mr. Jaehoon (Paul) Jeong >>>>>>> Professor >>>>>>> Department of Computer Science and Engineering >>>>>>> Sungkyunkwan University >>>>>>> Phone: +82-31-299-4957 >>>>>>> Email: [email protected], [email protected] >>>>>>> URI: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>> >>>>>>> >>>>>>> 2025년 10월 1일 (수) 오전 12:09, Megan Ferguson >>>>>>> <[email protected]>님이 작성: >>>>>>> Hi Paul, >>>>>>> >>>>>>> Thank you for your reply. We look forward to working with you to get >>>>>>> these documents moving through the publication process! >>>>>>> >>>>>>> I’ve made sure to update the CC field to include the AUTH48 archive and >>>>>>> Roman as AD (and removed Deb Cooley per her separate reply). >>>>>>> >>>>>>> Please feel free to reach out with any questions/concerns as necessary. >>>>>>> >>>>>>> Thank you. >>>>>>> >>>>>>> Megan Ferguson >>>>>>> RFC Production Center >>>>>>> >>>>>>> >>>>>>>> On Sep 30, 2025, at 3:09 AM, Mr. Jaehoon Paul Jeong >>>>>>>> <[email protected]> wrote: >>>>>>>> >>>>>>>> Hi Megan, >>>>>>>> Thanks for your excellent work on this cluster of I2NSF YANG Data >>>>>>>> Model drafts. >>>>>>>> >>>>>>>> I will work on your comments and questions this and next weeks as the >>>>>>>> editor of all these five drafts >>>>>>>> and come back to you later. >>>>>>>> >>>>>>>> Best Regards, >>>>>>>> Paul >>>>>>>> -- >>>>>>>> =========================== >>>>>>>> Mr. Jaehoon (Paul) Jeong >>>>>>>> Professor >>>>>>>> Department of Computer Science and Engineering >>>>>>>> Sungkyunkwan University >>>>>>>> Phone: +82-31-299-4957 >>>>>>>> Email: [email protected], [email protected] >>>>>>>> URI: http://iotlab.skku.edu/people-jaehoon-jeong.php >>>>>>>> LinkedIn: https://www.linkedin.com/in/jaehoonjeong/ >>>>>>>> >>>>>>>> >>>>>>>> On Tue, Sep 30, 2025 at 1:44 PM Megan Ferguson >>>>>>>> <[email protected]> wrote: >>>>>>>> Authors, Editors, *ADs, >>>>>>>> >>>>>>>> We have a number of questions related to the following documents from >>>>>>>> Cluster 405 (C405): >>>>>>>> >>>>>>>> draft-ietf-i2nsf-nsf-monitoring-data-model-20 >>>>>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-31 >>>>>>>> draft-ietf-i2nsf-capability-data-model-32 >>>>>>>> draft-ietf-i2nsf-registration-interface-dm-26 >>>>>>>> draft-ietf-i2nsf-nsf-facing-interface-dm-29 >>>>>>>> >>>>>>>> We note that resolving these questions may require significant author >>>>>>>> input or updates. As such, we would like to raise these issues now, >>>>>>>> rather than during AUTH48. Please review the questions/comments >>>>>>>> below, discuss amongst yourselves, update the attached XML files with >>>>>>>> any necessary changes, and resubmit the xml files to the RPC via email >>>>>>>> at your earliest convenience. >>>>>>>> >>>>>>>> As this is outside our normal process, note that the files are in >>>>>>>> various states of editorial completion and have not yet benefitted >>>>>>>> from a final review within the RPC. Therefore, we ask that you ignore >>>>>>>> any edits or queries in the XML files not directly related to the list >>>>>>>> below (i.e., please refrain from making any further changes at this >>>>>>>> time). All other queries/issues will be handled once the documents >>>>>>>> reach AUTH48. >>>>>>>> >>>>>>>> Please reach out with any questions and let us know if we can be of >>>>>>>> further assistance as you complete this process. >>>>>>>> >>>>>>>> Note: Each of the above documents has been moved to “AUTH” state (see >>>>>>>> https://www.rfc-editor.org/about/queue/) as they are awaiting author >>>>>>>> action prior to moving forward in the publication process. >>>>>>>> >>>>>>>> The related cluster information page is viewable at: >>>>>>>> >>>>>>>> https://www.rfc-editor.org/cluster_info.php?cid=C405 >>>>>>>> >>>>>>>> Thank you. >>>>>>>> >>>>>>>> Megan Ferguson >>>>>>>> RFC Production Center >>>>>>>> >>>>>>>> >>>>>>>> 1) The text in the Security Considerations sections of the following >>>>>>>> documents does not match the boilerplate at >>>>>>>> https://wiki.ietf.org/group/ops/yang-security-guidelines. >>>>>>>> >>>>>>>> We also note that RFC 4252 has not been cited in the references >>>>>>>> sections. >>>>>>>> >>>>>>>> Please consider what, if any, updates need to be made. Note that >>>>>>>> these updates will likely require *AD approval. >>>>>>>> >>>>>>>> draft-ietf-i2nsf-nsf-monitoring-data-model-20 >>>>>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-31 >>>>>>>> draft-ietf-i2nsf-capability-data-model-32 >>>>>>>> draft-ietf-i2nsf-registration-interface-dm-26 >>>>>>>> >>>>>>>> For draft-ietf-i2nsf-nsf-facing-interface-dm-29: >>>>>>>> >>>>>>>> As we do not see any mention of RPC operations in this document, >>>>>>>> please confirm that the "Some of the RPC operations" paragraph as >>>>>>>> listed on <https://wiki.ietf.org/group/ops/yang-security-guidelines> >>>>>>>> is not applicable to this document. >>>>>>>> >>>>>>>> 2) *AD - please review and approve the changes that the authors made >>>>>>>> between version -18 and version -20 of >>>>>>>> draft-ietf-i2nsf-nsf-monitoring-data-model at: >>>>>>>> >>>>>>>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-nsf-monitoring-data-model/history/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 3) For each document in the list at the top of this mail, please >>>>>>>> review the following related to titles: >>>>>>>> >>>>>>>> We note that most of the 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 >>>>>>>> >>>>>>>> We also note the guidance from RFC 7322 (RFC Style Guide) to expand >>>>>>>> abbreviations in document titles. >>>>>>>> >>>>>>>> Please consider whether the titles of these documents should be >>>>>>>> updated to something like the following example: >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> A YANG Data Model for Interface to Network Security Functions (I2NSF) >>>>>>>> Monitoring >>>>>>>> >>>>>>>> Note: If changes are made, please also consider if changes to the >>>>>>>> abbreviated title should be made as well. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 4) The following questions relate to the Terminology sections: >>>>>>>> >>>>>>>> a) We note that these documents: >>>>>>>> >>>>>>>> draft-ietf-i2nsf-nsf-monitoring-data-model-20 >>>>>>>> draft-ietf-i2nsf-consumer-facing-interface-dm-31 >>>>>>>> draft-ietf-i2nsf-capability-data-model-32 >>>>>>>> draft-ietf-i2nsf-nsf-facing-interface-dm-29 >>>>>>>> >>>>>>>> include the following text in the Terminology section: >>>>>>>> >>>>>>>> This document uses the terminology described in [RFC8329]. >>>>>>>> >>>>>>>> However, when looking at the Terminology section of RFC 8329 (included >>>>>>>> below for your convenience), we see that no definitions are listed: >>>>>>>> there is simply a list of terms and a pointer to >>>>>>>> draft-ietf-i2nsf-terminology-08 >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-i2nsf-terminology/), >>>>>>>> which is now expired: >>>>>>>> >>>>>>>> 2.2. Definitions >>>>>>>> >>>>>>>> The following terms, which are used in this document, are defined in >>>>>>>> the I2NSF terminology document [I2NSF-TERMS]: >>>>>>>> >>>>>>>> Capability >>>>>>>> Controller >>>>>>>> Firewall >>>>>>>> I2NSF Consumer >>>>>>>> I2NSF NSF-Facing Interface >>>>>>>> I2NSF Policy Rule >>>>>>>> I2NSF Producer >>>>>>>> I2NSF Registration Interface >>>>>>>> I2NSF Registry >>>>>>>> Interface >>>>>>>> Interface Group >>>>>>>> Intrusion Detection System >>>>>>>> Intrusion Protection System >>>>>>>> Network Security Function >>>>>>>> Role >>>>>>>> >>>>>>>> We further note that not all terms listed in RFC 8329 are used in this >>>>>>>> document set and that some terms from draft-ietf-i2nsf-terminology-08 >>>>>>>> are used but not listed in RFC 8329 (e.g., I2NSF Consumer-Facing >>>>>>>> Interface). >>>>>>>> >>>>>>>> We recommend including the definitions used in this set of documents >>>>>>>> in the documents themselves instead of pointing to an expired draft >>>>>>>> from 2018. >>>>>>>> >>>>>>>> Note: If more than one document in this cluster uses a term, we >>>>>>>> suggest including the definition in one document and including a >>>>>>>> citation to that document in the other documents in the cluster. >>>>>>>> >>>>>>>> b) Related to the above, draft-ietf-i2nsf-registration-interface-dm-26 >>>>>>>> uses: >>>>>>>> >>>>>>>> This document uses the following terms defined in [RFC3444], >>>>>>>> [RFC8329] and [I-D.ietf-i2nsf-capability-data-model]. >>>>>>>> >>>>>>>> However, the definitions listed and those in RFC 8329 (and thus >>>>>>>> draft-ietf-i2nsf-terminology-08) are not the same. For example: >>>>>>>> >>>>>>>> draft-ietf-i2nsf-registration-interface-dm-26: >>>>>>>> Network Security Function (NSF): A function that is responsible for >>>>>>>> a specific treatment of received packets. A Network Security >>>>>>>> Function can act at various layers of a protocol stack (e.g., at >>>>>>>> the network layer or other OSI layers). Sample Network Security >>>>>>>> Service Functions are as follows: Firewall, Intrusion Prevention/ >>>>>>>> Detection System (IPS/IDS), Deep Packet Inspection (DPI), >>>>>>>> Application Visibility and Control (AVC), network virus and >>>>>>>> malware scanning, sandbox, Data Loss Prevention (DLP), Distributed >>>>>>>> Denial of Service (DDoS) mitigation and TLS proxy. >>>>>>>> >>>>>>>> draft-ietf-i2nsf-terminology-08: >>>>>>>> Network Security Function (NSF): Software that provides a set of >>>>>>>> security-related services. Examples include detecting unwanted >>>>>>>> activity and blocking or mitigating the effect of such unwanted >>>>>>>> activity in order to fulfil service requirements. The NSF can >>>>>>>> also help in supporting communication stream integrity and >>>>>>>> confidentiality. >>>>>>>> >>>>>>>> Please review the above text and consider if/how to update either the >>>>>>>> citation or the definition. >>>>>>>> >>>>>>>> c) Related to a), we see RFC 8329 and draft-ietf-i2nsf-terminology-08 >>>>>>>> use the term "Intrusion Protection System (IPS)” while this set of >>>>>>>> documents uses Intrusion Prevention System (however, in >>>>>>>> draft-ietf-i2nsf-capability-data-model-32, we do see "intrusion >>>>>>>> detection and/or protection" as well as "Intrusion Prevention System >>>>>>>> (IPS)"). Please review and update accordingly. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 5) The following questions relate to the reference clauses in the YANG >>>>>>>> modules: >>>>>>>> >>>>>>>> a) We see mixed styles in reference clauses with regard to use of a >>>>>>>> section number, a concept name, a section name/title, and an RFC >>>>>>>> title. >>>>>>>> >>>>>>>> We suggest making the reference clauses in the YANG modules uniform >>>>>>>> following the pattern below to match the guidance in >>>>>>>> draft-ietf-netmod-rfc8407bis-28 >>>>>>>> (https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc8407bis/) where >>>>>>>> a section number (instead of a concept) is pointed to. >>>>>>>> >>>>>>>> Original: >>>>>>>> reference >>>>>>>> "RFC 9110: HTTP Semantics >>>>>>>> - Request Method PUT"; >>>>>>>> Perhaps: >>>>>>>> reference >>>>>>>> "RFC 9110: HTTP Semantics, Section 9.3.4"; >>>>>>>> >>>>>>>> b) For draft-ietf-i2nsf-monitoring-data-model-20: >>>>>>>> >>>>>>>> [IEEE-802.1AB]'s title is "IEEE Standard for Local and metropolitan >>>>>>>> area networks - Station and Media Access Control Connectivity >>>>>>>> Discovery" rather than "IEEE Standard for Local and metropolitan area >>>>>>>> networks - Station and Media Access Control Connectivity Discovery - >>>>>>>> Link Layer Discovery Protocol (LLDP)”. Should this be updated as >>>>>>>> follows in the YANG reference clauses? >>>>>>>> >>>>>>>> Current: >>>>>>>> reference >>>>>>>> "IEEE-802.1AB: IEEE Standard for Local and metropolitan >>>>>>>> area networks - Station and Media Access Control >>>>>>>> Connectivity Discovery - Link Layer Discovery Protocol >>>>>>>> (LLDP)" >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> reference >>>>>>>> "IEEE-802.1AB: IEEE Standard for Local and metropolitan >>>>>>>> area networks - Station and Media Access Control >>>>>>>> Connectivity Discovery" >>>>>>>> >>>>>>>> c) For draft-ietf-i2nsf-monitoring-data-model-20: >>>>>>>> >>>>>>>> [RFC4861] does not contain a section titled "Neighbor Discovery >>>>>>>> Protocol (ND)" and because the entire document is about Neighbor >>>>>>>> Discovery, please review whether a section pointer is necessary when >>>>>>>> completing the updates suggested in (a) above. >>>>>>>> >>>>>>>> Current: >>>>>>>> >>>>>>>> RFC 4861: Neighbor Discovery for IP version 6 (IPv6) - >>>>>>>> Neighbor Discovery Protocol (ND)”; >>>>>>>> >>>>>>>> d) See a further possible update to YANG reference clauses in question >>>>>>>> 6e below. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 6) The following questions relate to citations/references of these >>>>>>>> documents: >>>>>>>> >>>>>>>> a) The "YANG Module Names" registry is defined in RFC 6020 and not in >>>>>>>> RFC 7950. Please see Section 14 of RFC 6020 >>>>>>>> (https://www.rfc-editor.org/info/rfc6020) and >>>>>>>> https://www.iana.org/assignments/yang-parameters/. >>>>>>>> >>>>>>>> We have changed "7950" to "6020" accordingly (and added an informative >>>>>>>> reference entry to RFC 6020). Please let us know any concerns with >>>>>>>> these updates. >>>>>>>> >>>>>>>> Original: >>>>>>>> This document requests IANA to register the following YANG module in >>>>>>>> the "YANG Module Names" registry [RFC7950][RFC8525]: >>>>>>>> >>>>>>>> Currently: >>>>>>>> IANA has registered the following YANG module in the "YANG Module >>>>>>>> Names" registry [RFC6020] [RFC8525]: >>>>>>>> >>>>>>>> b) We note that some of these documents contain snippets of XML. Per >>>>>>>> <https://www.ietf.org/about/groups/iesg/statements/formal-languages-use/>, >>>>>>>> we believe the documents should cite [W3C.REC-xml-20081126] >>>>>>>> ("Extensible Markup Language (XML) 1.0 (Fifth Edition)") somewhere in >>>>>>>> the body of the document and list it as a Normative Reference, per RFC >>>>>>>> 8349. Please add an appropriate citation and reference entry where >>>>>>>> necessary. >>>>>>>> >>>>>>>> c) For draft-ietf-i2nsf-consumer-facing-interface-dm-31: >>>>>>>> >>>>>>>> We see several RFCs mentioned in the lead-in text to the YANG module >>>>>>>> that are not included in the YANG module itself. Please review and >>>>>>>> consider if these citations (and possibly their corresponding >>>>>>>> reference entries) should be removed. >>>>>>>> >>>>>>>> The list has been included below for your convenience: >>>>>>>> >>>>>>>> [RFC0768] >>>>>>>> [RFC0854] >>>>>>>> [RFC0959] >>>>>>>> [RFC1939] >>>>>>>> [RFC2595] >>>>>>>> [RFC3022] >>>>>>>> [RFC4250] >>>>>>>> [RFC4340] >>>>>>>> [RFC4443] >>>>>>>> [RFC5321] >>>>>>>> [RFC9051] >>>>>>>> [RFC9110] >>>>>>>> [RFC9112] >>>>>>>> [RFC9113] >>>>>>>> [RFC9260] >>>>>>>> [RFC9293] >>>>>>>> >>>>>>>> d) For draft-ietf-i2nsf-consumer-facing-interface-dm-31: >>>>>>>> >>>>>>>> The reference below appears to be pointing to the POSIX.1 standard. >>>>>>>> However, the provided URL points to a specific page in the POSIX.1 >>>>>>>> specification for "glob". >>>>>>>> >>>>>>>> We recommend having this reference's URL point to the specification in >>>>>>>> general, rather than this specific page. >>>>>>>> >>>>>>>> Additionally, please note that there is a more up-to-date version of >>>>>>>> POSIX.1: >>>>>>>> https://pubs.opengroup.org/onlinepubs/9799919799/ >>>>>>>> (The updated URL for "glob” is >>>>>>>> https://pubs.opengroup.org/onlinepubs/9799919799/functions/glob.html) >>>>>>>> >>>>>>>> Would you like to update this reference to the most current version? >>>>>>>> (FYI - We have inserted a comment in the XML with this updated >>>>>>>> information). >>>>>>>> >>>>>>>> For your convenience, we have included the suggested updated reference >>>>>>>> for you to review (combining points a and b above) in text form below: >>>>>>>> >>>>>>>> Original: >>>>>>>> [GLOB] IEEE, "The Open Group Base Specifications Issue 7, 2018 >>>>>>>> Edition", IEEE Std 1003.1-2017, >>>>>>>> <https://pubs.opengroup.org/onlinepubs/9699919799/ >>>>>>>> functions/glob.html>. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> [GLOB] IEEE/The Open Group, "The Open Group Base Specifications >>>>>>>> Issue 8", POSIX.1-2024, IEEE Std 1003.1-2024, 2024, >>>>>>>> <https://pubs.opengroup.org/onlinepubs/9799919799/>. >>>>>>>> >>>>>>>> e) For draft-ietf-i2nsf-consumer-facing-interface-dm-31 and >>>>>>>> draft-ietf-i2nsf-nsf-facing-interface-dm-29: >>>>>>>> >>>>>>>> Regarding the [ISO-3166-1alpha2], [ISO-3166-2], and [ISO-3166] >>>>>>>> references: >>>>>>>> >>>>>>>> The URL for [ISO-3166-1alpha2] goes to a page titled "ISO 3166 Country >>>>>>>> Codes" (Note: this is the same URL that [ISO-3166-2] redirects to). >>>>>>>> >>>>>>>> It appears the decoding table of ISO 3166-1 alpha-2 codes is now >>>>>>>> available here: https://www.iso.org/obp/ui/#iso:pub:PUB500001:en. >>>>>>>> >>>>>>>> We found the following URL for the most up-to-date version of ISO >>>>>>>> 3166-2 (ISO 3166-2:2020): https://www.iso.org/standard/72483.html. >>>>>>>> >>>>>>>> Would you like to update to point to the most up-to-date version of >>>>>>>> ISO 3166 (see example reference updates below)? (FYI - We have >>>>>>>> inserted a comment in the XML with this updated information). >>>>>>>> >>>>>>>> Note that further updates to these references are recommended with >>>>>>>> regard to title, etc. Please review and confirm or let us know if any >>>>>>>> further changes are necessary: >>>>>>>> >>>>>>>> Original: >>>>>>>> [ISO-3166-2] >>>>>>>> ISO, "ISO 3166-2:2007", >>>>>>>> <https://www.iso.org/iso/home/standards/ >>>>>>>> country_codes.htm#2012_iso3166-2>. >>>>>>>> >>>>>>>> Suggested: >>>>>>>> [ISO-3166-2] >>>>>>>> >>>>>>>> ISO, "Codes for the representation of names of countries >>>>>>>> and their subdivisions - Part 2: Country subdivision >>>>>>>> code", ISO 3166-2:2020, August 2020, >>>>>>>> <https://www.iso.org/standard/72483.html>. >>>>>>>> >>>>>>>> Original: >>>>>>>> [ISO-3166-1alpha2] >>>>>>>> ISO, "ISO 3166-1 decoding table", >>>>>>>> <https://www.iso.org/iso/home/standards/country_codes/iso- >>>>>>>> 3166-1_decoding_table.htm>. >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> [ISO-3166-1alpha2] >>>>>>>> ISO, "Decoding table of ISO 3166-1 alpha-2 codes", >>>>>>>> <https://www.iso.org/obp/ui/#iso:pub:PUB500001:en>. >>>>>>>> >>>>>>>> In light of the suggested updates to the titles (above) and to match >>>>>>>> the citation tags used, we further suggest updating the titles in the >>>>>>>> YANG reference clauses to match (note that these updates would occur >>>>>>>> in multiple places). >>>>>>>> >>>>>>>> Original: >>>>>>>> "ISO 3166-2: 3166-2 subdivision code”; >>>>>>>> >>>>>>>> "ISO 3166-1: Decoding table alpha-2 country code”; >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> "ISO 3166-2: Codes for the representation of names of countries >>>>>>>> and their subdivisions - Part 2: Country subdivision >>>>>>>> code"; >>>>>>>> >>>>>>>> "ISO 3166-1alpha2: Decoding table of ISO 3166-1 alpha-2 codes”; >>>>>>>> >>>>>>>> NOTE: Throughout the the rest of the document, and in the YANG module, >>>>>>>> we see the following mixed use when discussing these specs. >>>>>>>> >>>>>>>> ISO 3166-2 >>>>>>>> ISO3166-1 alpha-2 vs. ISO3166-1 alpha 2 >>>>>>>> >>>>>>>> We have updated these for consistency within the document as well as >>>>>>>> within the RFC Series. Please let us know any objections. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> f) For draft-ietf-i2nsf-capability-data-model-32 and >>>>>>>> draft-ietf-i2nsf-nsf-facing-interface-dm-29: >>>>>>>> >>>>>>>> Please review the references [IEEE802.3-2018] and [IEEE-802.3]. This >>>>>>>> IEEE Standard was superseded by a new version in 2022 >>>>>>>> (https://ieeexplore.ieee.org/document/9844436). Would you like to >>>>>>>> update this reference to use the most current version? (FYI - We have >>>>>>>> inserted a comment in the XML files with this updated information). >>>>>>>> >>>>>>>> Original: >>>>>>>> [IEEE802.3-2018] >>>>>>>> Committee, I. S., "IEEE 802.3-2018 - IEEE Standard for >>>>>>>> Ethernet", August 2018, >>>>>>>> <https://ieeexplore.ieee.org/document/8457469>. >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> Original: >>>>>>>> [IEEE-802.3] >>>>>>>> Institute of Electrical and Electronics Engineers, "IEEE >>>>>>>> Standard for Ethernet", 2018, >>>>>>>> <https://ieeexplore.ieee.org/document/8457469/>. >>>>>>>> >>>>>>>> >>>>>>>> Perhaps: >>>>>>>> [IEEE802.3-2022] >>>>>>>> IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, >>>>>>>> DOI 10.1109/IEEESTD.2022.9844436, July 2022, >>>>>>>> <https://ieeexplore.ieee.org/document/9844436>. >>>>>>>> >>>>>>>> and >>>>>>>> >>>>>>>> [IEEE-802.3] >>>>>>>> IEEE, "IEEE Standard for Ethernet", IEEE Std 802.3-2022, >>>>>>>> DOI 10.1109/IEEESTD.2022.9844436, July 2022, >>>>>>>> <https://ieeexplore.ieee.org/document/9844436>. >>>>>>>> >>>>>>>> >>>>>>>> g) For draft-ietf-i2nsf-registration-interface-dm-26: >>>>>>>> >>>>>>>> Please review the reference [nfv-framework]: >>>>>>>> >>>>>>>> We found a more recent version of this ETSI Group Specification at the >>>>>>>> following URL: >>>>>>>> https://www.etsi.org/deliver/etsi_gs/nfv/001_099/002/01.02.01_60/gs_nfv002v010201p.pdf. >>>>>>>> >>>>>>>> Note that this appears to be Version 1.2.1 published in December 2014, >>>>>>>> while the current reference points to Version 1.1.1 published in >>>>>>>> October 2013. (Note: we were unable to find a URL for Version 1.1.1). >>>>>>>> >>>>>>>> Should this reference be updated to use the more recent version from >>>>>>>> December 2014? (FYI - We have inserted a comment in the XML with this >>>>>>>> updated information if you’d like to adopt it). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 7) The following questions are about contact information: >>>>>>>> >>>>>>>> a) Jinyong, Jaehoon, and Liang: >>>>>>>> >>>>>>>> We see a mix of the following forms throughout this cluster: >>>>>>>> >>>>>>>> Jinyong Tim Kim vs. Jinyong (Tim) Kim >>>>>>>> Jaehoon Paul Jeong vs. Jaehoon (Paul) Jeong (past RFCs do not use >>>>>>>> parentheses) >>>>>>>> Liang Frank Xia vs. Liang Xia >>>>>>>> >>>>>>>> We have updated to use the following consistently: >>>>>>>> >>>>>>>> Jinyong Tim Kim >>>>>>>> Jaehoon Paul Jeong >>>>>>>> Liang Frank Xia >>>>>>>> >>>>>>>> And we have used only single first initial for each author in the >>>>>>>> header. Please review and update as desired. >>>>>>>> >>>>>>>> b) We note several authors/contributors have similar affiliations at >>>>>>>> the same university. >>>>>>>> Please review if updates are needed for consistency. >>>>>>>> >>>>>>>> Department of Electrical and Computer Engineering >>>>>>>> Department of Electronic, Electrical and Computer Engineering >>>>>>>> Department of Computer Science and Engineering >>>>>>>> >>>>>>>> c) Liang: >>>>>>>> >>>>>>>> We see slightly different addresses in different documents (e.g., the >>>>>>>> district being listed vs. not and the code being listed vs. not). We >>>>>>>> suggest updating to match the address published in RFC 9684 (please >>>>>>>> also keep question 7a in mind). >>>>>>>> >>>>>>>> As published in RFC 9684: >>>>>>>> >>>>>>>> Liang Xia (Frank) >>>>>>>> Huawei Technologies >>>>>>>> Yuhuatai District >>>>>>>> 101 Software Avenue >>>>>>>> Nanjing >>>>>>>> Jiangsu, 210012 >>>>>>>> China >>>>>>>> Email: [email protected] >>>>>>>> >>>>>>>> d) Diego: >>>>>>>> >>>>>>>> We see different addresses in these two documents. Please review >>>>>>>> these and update for consistency as necessary. >>>>>>>> >>>>>>>> draft-ietf-i2nsf-capability-data-model-32: >>>>>>>> >>>>>>>> Diego R. Lopez - Telefonica I+D, Zurbaran, 12, Madrid, 28010, Spain, >>>>>>>> Email: [email protected] >>>>>>>> >>>>>>>> draft-ietf-i2nsf-registration-interface-dm-26: >>>>>>>> >>>>>>>> Diego R. Lopez - Telefonica I+D, Jose Manuel Lara, 9, Seville, >>>>>>>> 41013, Spain. EMail: [email protected] >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 8) Please review whether any of the notes in the documents should be >>>>>>>> in the <aside> element. It is defined as "a container for content that >>>>>>>> is semantically less important or tangential to the >>>>>>>> content that surrounds it" >>>>>>>> (https://authors.ietf.org/en/rfcxml-vocabulary#aside). If no updates >>>>>>>> are necessary, please confirm that the text should remain as is. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 9) Some author comments are present in the XML files. Please confirm >>>>>>>> that no updates related to these comments are outstanding and delete >>>>>>>> the resolved comments. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 10) Please review the line lengths of yang trees and other figures to >>>>>>>> ensure they fit within the 69-character limit and make any updates >>>>>>>> necessary. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>> >>>> >>> >> > -- auth48archive mailing list -- [email protected] To unsubscribe send an email to [email protected]
