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.
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> >
>
