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]
