[I2nsf] Éric Vyncke's No Objection on draft-ietf-i2nsf-consumer-facing-interface-dm-27: (with COMMENT)

[Éric Vyncke via Datatracker <[e-mail]>]

Éric Vyncke has entered the following ballot position for
draft-ietf-i2nsf-consumer-facing-interface-dm-27: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thank you for the work put into this document.

Please find below some non-blocking COMMENT points (but replies would be
appreciated even if only for my own education).

Special thanks to Linda Dunbar for the shepherd's detailed write-up including
the WG consensus *but* it lacks a proper the justification of the intended
status. The write-up mentions 2 IPR while there are 4 of them.

Please note that Dirk Von Hugo is the Internet directorate reviewer (at my
request) and you may want to consider this int-dir review as well when it will
be available (no need to wait for it though):
https://datatracker.ietf.org/doc/draft-ietf-i2nsf-consumer-facing-interface-dm/reviewrequest/17250/

I hope that this review helps to improve the document,

Regards,

-éric

# COMMENTS (non blocking)

## Threat feed

While threat feeds are important, do they have a place in this model ?

## Section 3

Including a YANG tree in a section about an information model is really
surprising. It seems that the whole section is more about the YANG data model
than about an information model. Suggest to rename the section.

Having a leaf about language that is optional also means that the complete
instance will be mono-lingual (i.e., not possible to have an instance with
descriptions both in English and in Korean)

## Section 3.2

What about filtering ARP ? or IPv6 extension headers ?

`For more information about the mapping between ICMPv4 and ICMPv6 messages,
refer to [IANA-ICMP-Parameters] and [IANA-ICMPv6-Parameters]` but there is no
mapping described in the IANA tables. Also, this text is partially redundant
with the text in 'case(firewall)'.

## Sections 4.1 & 4.2

What is impact of randomised MAC addresses and RFC 8981 IPv6 temporary
addresses on this model ? Is it still worth doing ?

Is a start-end practical in a sparse addressing space as IPv6 ? Should this
rather be a prefix notation ?

## Section 4.3

Is the 'city' in the language as indicated by a top leaf or is it English?
Please, specify.

Did the author try to find another representation than basically
copying/duplicating addresses in 'user/device/location' trees ? Why not having
a list of all addresses (assuming that this is useful) and then having a leaf
for user / device / location grouping ? This could be faster to identify a rule
relevant to a MAC address (even if performance is not really the key point of
an information model).

## Section 5

Should the work done in DOTS WG be listed in this section ?

## Section 6.1

I am not a YANG expert but isn't there an easier way to refer to
draft-ietf-i2nsf-nsf-monitoring-data-model rather than redefining all
identities here ?