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
On Sat, Mar 18, 2023 at 12:54 AM tom petch <daedu...@btconnect.com> 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-c...@ietf.org mailing lists by 2023-03-16. Exceptionally,
> >> comments may
> >> be sent to i...@ietf.org 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-annou...@ietf.org
> >> https://www.ietf.org/mailman/listinfo/ietf-announce
> >> .
> >>
>
> _______________________________________________
> I2nsf mailing list
> I2nsf@ietf.org
> https://www.ietf.org/mailman/listinfo/i2nsf
>
Revision-Letter-for-Consumer-Facing Interface-27-20230326.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
