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

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 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)
> >>>>
>
> -- =========================== 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>