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]
