Hi Kyle and Tom,
Here is the revision of I2NSF NSF-Facing Interface YANG Data Model Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-17
I attach a revision letter to explain how Patrick and I have addressed your comments.
Thanks.
Best Regards,
Paul
Here is the revision of I2NSF NSF-Facing Interface YANG Data Model Draft:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-nsf-facing-interface-dm-17
I attach a revision letter to explain how Patrick and I have addressed your comments.
Thanks.
Best Regards,
Paul
On Tue, Nov 23, 2021 at 2:57 AM Kyle Rose via Datatracker <noreply@xxxxxxxx> wrote:
Reviewer: Kyle Rose
Review result: Has Issues
I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area directors.
Document editors and WG chairs should treat these comments just like any other
last call comments.
This document Has Issues.
I don't actually have a lot to say about this document from a security
perspective: its purpose is to describe, using YANG, a data model intended as
the basis for configuration schemas developed for implementations of the
Interface to Network Security Functions (I2NSF) framework. Security
considerations for the most part should be addressed in documents describing
system architecture or normatively detailing how implementations are to make
use of the data model described here. I'm not going to relitigate any such
issues here.
The main issues I found in this document are ones that I, as someone not
terribly familiar with YANG, found troubling from a general engineering
perspective. These are best illustrated by example:
* Why are `ipvX-prefix`, `-range`, and (the misleadingly-named) `-address`
defined here? These concepts are generic enough that they should be in modules
of their own to minimize variation among data models and the errors that will
inevitably result from capturing the same concept in slightly different ways
that are not obvious to the user. * Overall, I have to imagine that much of
the `nsfintf` data model is generic enough that it should be captured
externally. For instance, `tcp-flags`, `port-range`, `flow-label`, `dscp`,
etc. are generally useful elements of an abstract transport data model that
they shouldn't be defined here, but rather incorporated from an external data
model that is maintained by those in (for example) the transport area.
Am I just commenting on the YANG ecosystem in general? If these are standard
practices, then the overall ecosystem has major latent problems. Ideally, a
particular YANG module seems like it should describe only those elements
defined at a particular layer, in this case rules and actions, and use
reference external modules for elements that are defined at lower layers.
Also some nits:
* `ipvX-address` describes a subspace of the global IPvX address space, not a
single address. The name is going to cause problems. * The descriptions given
are often (usually?) just restatements of the entity name. Example is
`identity priority-by-order` described as "Identity for priority by order".
The description should provide some value for the user beyond simply restating
the name. * The headings in section 5 should be clearly labeled with the word
"example", such as "Example Security Requirement 1". * IPv6 addresses in text
MUST be represented in lowercase, according to RFC 5952 section 4.3.
_______________________________________________
I2nsf mailing list
I2nsf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/i2nsf
Attachment:
Revision-Letter-for-draft-ietf-i2nsf-nsf-facing-interface-dm-17-2022-01-22.pdf
Description: Adobe PDF document
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
