Hi Roman, Thanks for your review. Patrick and I will revise this CFI draft according to your 2nd review comments.
Thanks. Best Regards, Paul 2023년 1월 9일 (월) 오전 11:16, Roman Danyliw <r...@cert.org>님이 작성: > 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! > > 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 -24. > > ** Section 4.3. Location-group > > 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: > > [-23] Geo-ip-ipv4 and Geo-ip-ipv6 are citing RFC8805. My understanding > of that specification is that it provides a way to bind a geographic name > to an IP address. I don't see anything in the Location object that ties a > human readable geographic label to an IP address. Is the related geography > in the Name field? > > [-24] The YANG definition of "location-group" still cites RFC8805. With > the addition of the country, region and city fields, in what way is RFC8805 > still used? It seems like with the current fields there is a complete > mechanism to map human readable names to IP addresses (and then I don't see > a reliance on RFC8805); or all of these fields could be dropped in favor of > a single uri field that points to a RFC8805 file. Perhaps a hybrid would > be possible too. > > ** Section 5/Thread Feeds and IOC > > Thanks for the changes which resulted in "thread-feed-list/ioc" in -24. > > -- STIX, MISP and OpenIOC need to be normative references > > -- For [MISP] and [OpenIOC], if the best reference possible is in github, > please at least include a branch or tag. > > -- Conflict of interest as I am one of the document's co-author's: > _consider_ if you also want to include RFC8727 (JSON binding of IODEF). > > ** YANG. Per the fields under "rules": > > The revised text says: > > leaf name { > type string; > description > "This represents the name for a rule. The name must be > unique to represent different rules."; > } > > -- Should the "unique" constraint per Section 7.8.3 of RFC7950 be applied > here? > > -- Editorial. Is it that the "name must be unique to represent different > rules" or that "each rule name must be unique"? > > ** YANG. container anti-virus. > > [feedback for -24] > leaf-list exception-files { > type string; > description > "The type or name of the files to be excluded by the > antivirus. This can be used to keep the known > harmless files. Absolute paths are filenames/paths > to be excluded and relative ones are interpreted as > globs. Note that the file names can be hash names > to specify malicious files to block."; > reference > "GLOB: Linux Programmer's Manual - GLOB"; > > The above text is new in -24 to address feedback in -23. This new text > > -- The semantics of the "hash name" idea would benefit from further > specification. How does one know if one has a hash name as opposed to a > file name? How does one know which hash algorithm was used? Why are the > block values (i.e., the hash files) in the same leaf-list as those being > explicitly allowed (i.e., block values are being shared in an > "exception-file" list) > > -- [GLOB] needs to be a normative reference. Please also find a more > stable reference than https://man7.org/linux/man-pages/man7/glob.7.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? > > > ** Section 7.1 (was: Section 8.1). Per Figure 20: > > Thanks for the changes in -24 to address prior feedback on Figure 19 and > 20. > > [-24] The following text was added to Figure 20: > > <voice-group> > <name>malicious-id-v6</name> > <sip-id>sip:david@[2001:db8:2ef0::32b7]</sip-id> > </voice-group> > > > Use of the brackets around the IP address ("sip:david@[2001:db8:2ef0::32b7]") > is not a valid address. It should be "sip:david@2001:db8:2ef0::32b7". > > ** Section 7.4 (was: Section 8.4) > > [Per -24] > Thanks for explaining how the rates are computed. It appears that in this > section the following text was added: > > Note that tcpdump can be used to capture packets per host as source > [tcpdump]. tcpdump can limit capture to only packets related to a > specific host (e.g., source) by using the host filter. > > No disagreement on the capabilities of tcpdump. However, I'm having > trouble understanding the role it plays in the example. Is tcpdump being > invoked If so, how is that evident from the example? > > Thanks, > Roman > > _______________________________________________ > I2nsf mailing list > I2nsf@ietf.org > https://www.ietf.org/mailman/listinfo/i2nsf > -- =========================== Mr. Jaehoon (Paul) Jeong, Ph.D. Associate Professor Department of Computer Science and Engineering Sungkyunkwan University Office: +82-31-299-4957 Email: paulje...@skku.edu, jaehoon.p...@gmail.com Personal Homepage: http://iotlab.skku.edu/people-jaehoon-jeong.php <http://cpslab.skku.edu/people-jaehoon-jeong.php>
_______________________________________________ I2nsf mailing list I2nsf@ietf.org https://www.ietf.org/mailman/listinfo/i2nsf
