Hi Roman, Here is the revision of the CFI YANG Data Model: https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-26
I attach the revision letter. Thanks. Best Regards, Paul On Tue, Feb 28, 2023 at 12:21 PM Roman Danyliw <[email protected]> wrote: > Hi > > I performed an AD review on > draft-ietf-i2nsf-consumer-facing-interface-dm-23 ( > https://mailarchive.ietf.org/arch/msg/i2nsf/VHbdIrvHo5EjvcyQf5v9fjeVy1w/). > The authors produced at -24 in response (thank you!) and I provided > additional feedback ( > https://mailarchive.ietf.org/arch/msg/i2nsf/J5w-jujcwV3dve79Ta-SyEHjf28/). > The authors have published a -25. Much appreciated! > > To make it easier to track the remaining issues, I've created this new > thread. The following is feedback on the new text introduced in -25, or > unresolved issues from -24: > > ** Section 4.3. Location-group > > [-24] Thank you for the clarifying language in this section in -24. Per > the addition of the country, region and city fields please add normative > references for ISO3166-1 and ISO3166-2: > > [-25] Thanks for cleaning up the RFC8805 references. Please also add > normative references for ISO-3166-1 and -2. > > ** Section 5/Thread Feeds and IOC > > Thanks for the changes which resulted in "thread-feed-list/ioc" in -24. > > [-24] -- STIX, MISP and OpenIOC need to be normative references > > [-24] -- For [MISP] and [OpenIOC], if the best reference possible is in > github, please at least include a branch or tag. > > [-25] Thanks for adding "(branch master)" to [MISPCORE] and [OPENIOC] > reference. History from prior IESG reviews says that this is insufficient > because the main branch can be committed to at any time and won't be > considered stable. A specific commit has been sufficient. Check my > recommendations below for accuracy, but please use URLs to specific blobs > in github: > > MISP = > https://github.com/MISP/misp-rfc/blob/051e33b6711a660faf81733d825f1015aa0d301b/misp-core-format/raw.md.txt > > OpenIOC = > https://github.com/fireeye/OpenIOC_1.1/blob/d42a8777708e171f8bdd3c2c9f8590c83488285d/schemas/ioc.xsd > > As an aside, I'm being very particular on getting these reference right > now so we can confirm consensus during IETF LC on using them as normative > references. > > ** container anti-virus > > -- Per the description in Section 3.2 > > ==[ snip ]== > This field represents the configuration for an Antivirus interruption. A > specific security profile can be added to Security Controller in order to > update the security of the Antivirus. Filenames or paths that contain the > profile can be specified by I2NSF User. The decision to either perform or > skip the Antivirus interruption depends on the action of the rule. For > example, a drop action uses the security profile for dropping either > packets or flows in the Antivirus interruption. On the other hand, a pass > action uses the security profile for allowing either packets or flows > without the Antivirus interruption. > ==[ snip ]== > > o Editorial. Can a different word that "interruption" be used? I didn't > notice this change in -24. This is the first mention of that term, but > there are no "firewall interruptions" or "url filtering interruption". Why > introduce it? > > o The concept of "profiles" is introduced here. Per "... in order to > update the security of Antivirus", would it be clearer to call this the > configuration of the antivirus? > > -- per the leaf-list profile > > ==[ snip ]== > leaf-list profile { > type string; > description > "The path or name of the file that contains a security > profile for the Antivirus interruption. The security > profile is used to scan the viruses. The absolute > paths and relative ones are to be interpreted as > globs. The decision to perform or skip the Antivirus > interruption depends on the action of the rule. A drop > action uses the security profile for dropping either > packets or flows in the Antivirus interruption. On the > other hand, a pass action uses the security profile > for allowing either packets or flows without the > Antivirus interruption."; > reference > "GLOB: Linux Programmer's Manual - GLOB"; > } > } > ==[ snip ]== > > When this leaf-list was called "exception-file" (-24 and earlier), this > data element explicitly referenced filenames/paths/globs to skip. That is, > specific files names and hashes were enumerated. In this revised > definition, the semantics are less clear. What is meant by "profiles"? Is > that a configuration file loaded into the AV? Is it's format vendor > specific? > > Per "The absolute paths and relative ones are to be interpreted as globs", > why is it "paths", plural? Where are the multiple paths coming from? The > first sentence says the "The path or name of the file", singular. > > Since [GLOB] is being cited in the YANG module and seems integral to how > read a path, please make it a normative reference. Also, the new ubuntu > URL is no more stable. Please instead use the recommendation from Paul > Wouters (thanks Paul!) to cite glob as from the Open Group/IEEE: > > NEW > [GLOB] glob. Open Group Open Group Base Specifications Issue 7, 2018 > edition/IEEE IEEE Std 1003.1-2017. > https://pubs.opengroup.org/onlinepubs/9699919799/functions/glob.html > > > ** YANG. list payload-content > > Thanks for added the additional guidance on handling multiple content > fields and the support for depth and starting point. > > [-24] Both offset and distance limit themselves to a range of "0..65535". > If dealing with packet header information only, I can see this as being > adequate. I'm imagining a hypothetical multi-MB network stream. Should > there be flexibility to search past 65K? > > [-25] Thank you for the changes that made to both offset/distance to > define them as int32. Could you please also add text which describes how > to handle negative numbers. For example, what would offset=-72 mean? > > Regards, > Roman > > _______________________________________________ > I2nsf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2nsf >
Revision-Letter-for-Consumer-Facing Interface-26-20230301.pdf
Description: Adobe PDF document
_______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
