On 22/11/2021 17:55, Kyle Rose via Datatracker 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.
The overall ecosystem has major latent problems IMHO but it is the IETF ecosystem that has them. It is very hard to get one WG to collaborate with another (and sometimes they wilfully trample on another's toes:-(
Yes, there a lots of e.g. transport-related items that could be in a transport module are imported by the other WG that need them. I tried to get the TCPM WG interested in draft-ietf-opsawg-l3sm-l3nm which e.g. redefined the flags in the TCP header, and mostly failed. Likewise I sought to get the LSR WG interesed in a redefinition of OSPF but failed. The IETF does not work that way.
Even the NETMOD WG, which might have claim to primacy with YANG, has failed to progress a common module, 6991bis, which has several generally useful constructs over and above RFC6991; the author recently asked on the NETMOD list if it was time to give up - I have not seen a reply. Over the years, I have seen I-D import 6991bis and have suggested they duplicate the definitions as there is no guarantee the 6991bis will ever become an RFC.
Equally the NETCONF WG has spent many years, performed many summersaults, and has yet to produce common modules for the netconf protocol, especially with security aspects thereof.
Closer to home, I first reviewed the i2nsf sdn module which is now an RFC. I failed to realise that there were another five or more overlapping I2NSF modules which cried out for a common module but which instead did not agree on naming, strucure and so on. By then, these I-D had been long in the making and my sense was and is that the WG does not have the energy to undertake such a major rethink in the approach so I focussed instead on getting the I-D more in line, using the same identifiers and structure, as the WG list will show.
So, when it comes to the common good, the IETF structure militates against it. I think that the early work on YANG succeeded because it was building on SMI, which had had decades to get it right (or not), and on the existing DDL of a major manufacturer. OPSAWG recently produced a common module for VPN, doing so after two of the four potential importers were RFC, and having it last called with the third. Now the fourth is in last call, suggestions have been made how the common should be improved - too late! Do it early, do it late, either way the IETF is not organised for it.
Tom Petch
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 .
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
