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" <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>
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
