Re: [I2nsf] AD review follow-up on draft-ietf-i2nsf-consumer-facing-interface-dm-24

["Mr. Jaehoon Paul Jeong" <[e-mail]>]

Hi Roman,
The revision for Consumer-Facing Interface is done by Patrick and me:
https://datatracker.ietf.org/doc/html/draft-ietf-i2nsf-consumer-facing-interface-dm-25

I attach the revision letter.

If you are satisfied with this revision, please move it forward.

Thanks.

Best Regards,
Paul

On Tue, Jan 10, 2023 at 1:16 AM Roman Danyliw <[e-mail]> 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!
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/i2nsf
>