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

[Roman Danyliw <[e-mail]>]

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