Éric Vyncke has entered the following ballot position for draft-ietf-i2nsf-capability-data-model-25: 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/blog/handling-iesg-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-capability-data-model/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. As I reviewed the -12 and as I am running out of time, I have focused my ballot on the changes between -12 and -25. Thanks to the authors for including the information model (but see my review :( ...), the document should now have a logical flow from information to data model (this was part of my previous DISCUSS but Susan Hares and Diego Lopez had replied to me on this topic). Thanks as well for handling SCTP now. 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 write-up including the section about the WG consensus and the IPR declarations, minor regrets: nothing is said about the 2nd IESG evaluation. I hope that this helps to improve the document, Regards, -éric ## Section 3.1 This comment is probably for purists, but I wonder whether the automation & scalability (important operational requirements) should be requirements for an information model (as opposed to a data model). And, the whole 'information model' section is not an information model :-( ... Please rename it as 'requirements' or something like that. ## Section 6 (YANG model) 'identity next-header': the text "Identity for the capability of matching IPv4 Protocol Field or equivalent to IPv6 Next Header.;" does not sound like a proper English sentence to me (I can obviously be wrong as I am not a native English speaker) in the same identity, please use the right wording for the IANA registry (it does not include IPv4 in its name/title) <https://www.iana.org/assignments/protocol-numbers/protocol-numbers.xml> Should "identity identification" be renamed into "identity fragment-identification" ? And also applied to IPv6 as the IPv6 fragmentation extension header has this field ? identity identity fragment-offset: there is a fragment offset field in the IPv6 fragmentation extension header... Does this identity also apply to IPv6 ? should 'identity type' be renamed in icmp-type ? Same applies for 'code' Suggest to s/traffic flow capability/traffic flow export capability/ For consistency, s/identity hop-by-hop/identity hop-by-hop-header/ and s/destination-options/destination-options-header/ I am puzzled by the limited list of application-protocols, i.e., DNS, NTP, ... are not included. Is there a need to have such a non-exhaustive list ? _______________________________________________ I2nsf mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2nsf
