Hi Tom,
I have reflected your comments on the revision below:
Please see my answers inline.
On Mon, Aug 31, 2020 at 7:05 PM tom petch <daedulus@xxxxxxxxxxxxx> wrote:
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-)
=> I replaced RRFC790 with the following IANA Website for Protocol Numbers:
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.
=> I removed Section 2 entirely.
Thanks.
Best Regards,
Paul
HTH
Tom Petch
----- Original Message -----
From: "Mr. Jaehoon Paul Jeong" <jaehoon.paul@xxxxxxxxx>
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 <daedulus@xxxxxxxxxxxxx>
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" <iesg-secretary@xxxxxxxx>
> >> To: "IETF-Announce" <ietf-announce@xxxxxxxx>
> >> Cc: <rdd@xxxxxxxx>; <i2nsf@xxxxxxxx>;
> >> <draft-ietf-i2nsf-capability-data-model@xxxxxxxx>;
> >> <i2nsf-chairs@xxxxxxxx>; "Linda Dunbar" <dunbar.ll@xxxxxxxxx>
> >> 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
> >>>> last-call@xxxxxxxx mailing lists by 2020-09-08. Exceptionally,
> >> comments may
> >>>> be sent to iesg@xxxxxxxx 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:
jaehoon.paul@xxxxxxxxx, pauljeong@xxxxxxxx Personal Homepage:
http://iotlab.skku.edu/people-jaehoon-jeong.php
<http://cpslab.skku.edu/people-jaehoon-jeong.php>
>
>
===========================
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@xxxxxxxxx, pauljeong@xxxxxxxx
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
Mr. Jaehoon (Paul) Jeong, Ph.D.
Associate Professor
Department of Computer Science and Engineering
Sungkyunkwan University
Office: +82-31-299-4957
Email: jaehoon.paul@xxxxxxxxx, pauljeong@xxxxxxxx
Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
