Subject: [I2nsf] Last Call: <draft-ietf-i2nsf-capability-data-model-08.txt> (I2NSF Capability YANG Data Model) to Proposed Standard

From: The IESG <[email-masked]>
Date: Tue, 25 Aug 2020 10:59:33 -0700

The IESG has received a request from the Interface to Network Security
Functions WG (i2nsf) to consider the following document: - 'I2NSF Capability
YANG Data Model'
  <draft-ietf-i2nsf-capability-data-model-08.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2020-09-08. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document defines a YANG data model for the capabilities of
   various Network Security Functions (NSFs) in the Interface to Network
   Security Functions (I2NSF) framework to centrally manage the
   capabilities of the various NSFs.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-capability-data-model/

The following IPR Declarations may be related to this I-D:

   https://datatracker.ietf.org/ipr/3556/
   https://datatracker.ietf.org/ipr/3606/

The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc8329: Framework for Interface to Network Security Functions (Informational - IETF stream)
    rfc8192: Interface to Network Security Functions (I2NSF): Problem Statement and Use Cases (Informational - IETF stream)
    rfc790: Assigned numbers (Historic - Legacy stream)
    rfc3444: On the Difference between Information Models and Data Models (Informational - IETF stream)
    draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF Monitoring YANG Data Model (None - IETF stream)

---

From: tom petch <[email-masked]>
Date: Mon, 31 Aug 2020 11:05:21 +0100

Paul

Picking out two points and top posting them

RFC790 was obsoleted in 1982 and the information that was in it is now
kept up-to-date as part of the IANA website so what I am saying is that
I expect that  you will be asked to change the reference to refer to
that part of the  IANA website.  Yes, it is technically possible to
include a reference to RFC790 in an I-D but that does not mean it will 
be allowed-)

On RFC8174, that is the current standard for defining the rules about
using MUST, MAY, SHALL and such like in capitals in an I-D so if you
want to use those words in capitals with the sense defined in RFC8174
then you MUST(!) reference RFC8174. Looking more closely, I see no such
usage of these words in capitals in this I-D so you could remove the
section entirely but if you are REQUIRED to include such usage at a
later date, perhaps as a result of a review such as a security review,
then you will need to include the paragraph from RFC8174 and include
references to RFC2119 and RFC8174. So what you had  in -08 was invalid
and what you have in -09 is invalid but as it stands you could remove
section 2 entirely.

HTH

Tom Petch

----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <[email-masked]>
Sent: Friday, August 28, 2020 7:19 PM

> Hi Tom,
> I have reflected your comments with the revised draft:
> https://tools.ietf.org/html/draft-ietf-i2nsf-capability-data-model-09
>
> I put my answers inline below.
>
> On Thu, Aug 27, 2020 at 6:29 PM tom petch <[email-masked]>
wrote:
>
> >> Looking at the YANG:
> >>
> >> RFC4443 is referenced and so must be in the I-D References
>
>  => This RFC4443 is included in the Normative References.
>
> >>
> >> RFC790 is referenced but this is now online under IANA - you can
see the
> >>
> => This RFC790 is included in the Normative References with its URL.
>
>
> >> IANA reference in
> >>               draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
> >> but that I-D needs to add it to the I-D references as this one will
need
> >> to; I note that this announcement flags it as a downref but think
that
> >> that is misguided -  it needs replacing.
> >>
>  => Could you clarify this question?
>       I put the reference to
draft-ietf-i2nsf-sdn-ipsec-flow-protection-08
> in the draft.
>
> >>
> >> IPsec is the correct spelling - there are some IPSec in YANG
> >> description clauses
> >>
>  => IPsec is used instead of IPSec.
>
> >>
> >> Figure 8
> >>     2.  The location of the NSF is 221.159.112.140.
> >> This address does not appear in the XML, nor is it an address
reserved
> >> for use in documentation AFAICT; in fact, I cannot see any
ipaddress
> >> anywhere in this I-D
> >>
>  => I put the following text for an actual IPv4 address for
documentation
>       in Appendix 5:
>
>      The IPv4 address of the NSF is assumed to be 192.0.2.11
[RFC5737].
>      Also, the IPv6 address of the NSF is assumed to be
2001:DB8:0:1::11
> [RFC3849].
>
>      ---
>      In addition, I added the XML examples of IPv6 as well as those of
IPv4
> in Appendix A
>      with Figure 5 and Figure 7.
>
>
> >>
> >> s.2 correctly cites RFC8174 but does not use the text prescribed
there.
> >>
>   => I removed RFC8174 from the draft.
>
> >>
> >>   ' identity system-event-capability'
> >> references system-alarm - system event would seem more apt. More
> >> generally, these references for identity could be more specific,
e.g
> >>    identity access-violation
> >> could reference 'access-violation ' rather than the more generic
'system
> >> event'
> >>
> >>   => I tried to improve the descriptions of the events and alarms
above.
>
>        Thanks for your valuable comments.
>
>        Best Regards,
>        Paul
>
>
> >> Tom Petch
> >>
> >>
> >> ----- Original Message -----
> >> From: "The IESG" <[email-masked]>
> >> To: "IETF-Announce" <[email-masked]>
> >> Cc: <[email-masked]>; <[email-masked]>;
> >> <[email-masked]>;
> >> <[email-masked]>; "Linda Dunbar" <[email-masked]>
> >> Sent: Tuesday, August 25, 2020 6:59 PM
> >>
> >>>> The IESG plans to make a decision in the next few weeks, and
solicits
> >> final
> >>>> be sent to [email-masked] instead. In either case, please retain
the
> >> beginning
> >>>>     rfc8329: Framework for Interface to Network Security
Functions
> >> (Informational - IETF stream)
> >>>>     rfc8192: Interface to Network Security Functions (I2NSF):
Problem
> >> Statement and Use Cases (Informational - IETF stream)
> >>>>     rfc3444: On the Difference between Information Models and
Data
> >> Models (Informational - IETF stream)
> >>>>     draft-ietf-i2nsf-nsf-monitoring-data-model: I2NSF NSF
Monitoring
> >> YANG Data Model (None - IETF stream)
> >>>>
>
> -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor Department of Computer Science and Engineering
Sungkyunkwan University Office: +82-31-299-4957 Email:
[email-masked], [email-masked] Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>