Hi Tom,
I have addressed your comments on I2NSF Consumer-Facing Interface:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-27
I attach a revision letter to explain how I have addressed your comments on the revision.
Thanks.
Best Regards,
Paul
I have addressed your comments on I2NSF Consumer-Facing Interface:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-27
I attach a revision letter to explain how I have addressed your comments on the revision.
Thanks.
Best Regards,
Paul
On Sat, Mar 18, 2023 at 12:54 AM tom petch <daedulus@xxxxxxxxxxxxx> wrote:
On 15/03/2023 11:32, tom petch wrote:
> On 02/03/2023 14:16, The IESG wrote:
>>
>> The IESG has received a request from the Interface to Network Security
>> Functions WG (i2nsf) to consider the following document: - 'I2NSF
>> Consumer-Facing Interface YANG Data Model'
>> <draft-ietf-i2nsf-consumer-facing-interface-dm-26.txt> as Proposed
>> Standard
Belatedly I notice another area of divergence which makes the set of
documents incoherent and that is with threats.
This I-D uses 'ioc' as a basis' from which is derived
identity stix {
identity misp {
identity openioc {
identity iodef {
Earlier versions used threaat feed with
identity signature-yara {
identity signature-snort {
identity signature-suricata {
and the capability I-D, with the RFC Editor, has
identity content-security-control {
from which are derived
identity ips {
identity anti-virus {
which give rise to
identity signature-set {
identity exception-signature {
and
identity detect {
identity exception-files {
I am unclear how the capabilities which can be configured in this I-D
are specified with the YANG identity of the capability I-D. A sentence
or two in this I-D explaining the relationship might clarify.
Tom Petch
> This is one of a set of seven or so documents, one of which (framework)
> made RFC8329 six years ago, the others are waiting on MISSREF and then
> there is this one. It would be good to get these out as RFC.
>
> A problem I have seen with them is ideas changing with them, evolving,
> so that the I-D are out of step. As this is the last, this might be the
> place to address this.
>
> I have not had time, in the tsunami of I-D prior to IETF submission
> cut-off, to review this thoroughly but do see a divergence in the
> treatment of location. This used to be geo-ip, RFC8179, as is mentioned
> in RFC8329 and that is still referenced in e.g. nsf-facing. This I-D
> now uses country/region/city which is fine except for documents like
> 'capability' in the RFC-Editor Q which references RFC8179. The
> technically correct solution might be to update 'capability' etc but I
> think that the time for that is past. I put in some effort a few years
> ago to get them in line but no sooner had I done so than they diverged
> again after comments by other reviewers so I think that keeping them in
> line is a never ending task.
>
> What this I-D perhaps could do is to mention this divergence in
> treatment. I will look some more to see where else they have diverged
> but not before the end of thie Last Call.
>
> In passing, I note that the SIP example uses what might be genuine
> addresses.
>
> Tom Petch
>
>> 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 2023-03-16. 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 describes an information model and the corresponding
>> YANG data model for the Consumer-Facing Interface of the Security
>> Controller in an Interface to Network Security Functions (I2NSF)
>> system in a Network Functions Virtualization (NFV) environment. The
>> information model defines various types of managed objects and the
>> relationship among them needed to build the flow policies from users'
>> perspective. This information model is based on the "Event-
>> Condition-Action" (ECA) policy model defined by a capability
>> information model for I2NSF, and the YANG data model is defined for
>> enabling different users of a given I2NSF system to define, manage,
>> and monitor flow policies within an administrative domain (e.g., user
>> group).
>>
>>
>>
>>
>> The file can be obtained via
>> https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/
>>
>>
>>
>> The following IPR Declarations may be related to this I-D:
>>
>> https://datatracker.ietf.org/ipr/3554/
>> https://datatracker.ietf.org/ipr/3604/
>> https://datatracker.ietf.org/ipr/5749/
>> https://datatracker.ietf.org/ipr/5694/
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> IETF-Announce mailing list
>> IETF-Announce@xxxxxxxx
>> https://www.ietf.org/mailman/listinfo/ietf-announce
>> .
>>
_______________________________________________
I2nsf mailing list
I2nsf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/i2nsf
Attachment:
Revision-Letter-for-Consumer-Facing Interface-27-20230326.pdf
Description: Adobe PDF document
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
