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
