Hi Eric Thanks for you Review. We have posted an updated draft 07 to address your comments. Note I Revalidated the MIB with the changes, but I realized I didn’t update the tree in the draft. So, I have one pending change, but I will wait and see if we satisfied your points.
See [Don] Below. Thanks Don -----Original Message----- From: Éric Vyncke via Datatracker <nore...@ietf.org> Éric Vyncke has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: Discuss 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-ipsecme-mib-iptfs/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ipsecme-mib-iptfs-06 CC @evyncke Thank you for the work put into this document (even if I am balloting a DISCUSS); Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education). Special thanks to Tero Kivinen for the shepherd's detailed write-up including the WG consensus *but* it lacks the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Inconsistent intended status & use of experimental code point This document is standard track, but the OID used in section 4.1 is 'experimental' and in section 4.2 `experimental 500` per https://www.iana.org/assignments/smi-numbers/smi-numbers.xhtml. Please request IANA to assign an OID from the 1.3.6.1.2.1 tree. [Don] This was a holdover from the initial draft. We have updated to be consistent with the IANA requests and your comment. BTW Thank you for helping us clarify where this should be placed. ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Section 1 ``` Note an IETF MIB model for IPsec was never standardized however the structures here could be adapted to existing MIB implementations. ``` [Don] we updated to: adapted to existing proprietary MIB implementations where SNMP is used to manage networks. Perhaps clarify "existing MIB implementations" ? I guess this is about proprietary IPsec MIBs, but clarification will be welcome. ### Section 4.2 Should the construct with `<CODE BEGINS>` be used to allow for easy file extraction ? [Don] OK Roman had requested this comment and I looked for MIB examples and found none. But as I updated the YANG, I found the sourcecode tag and used that for a mib and nothing seem to complain. We may be the only MIB that ever used this though. `mailto:ekinzie.labn.net` is probably wrong ;-) [Don] Fixed. `l2FixedRate`and `l3FixedRate` have 'counter64' type, RFC 2578 section 7.1.10 defines this type as monotically increasing. I understand that there are no interger64 in RFC 2578 but why not using a different unit than 'bps' for those two items ? [Don] We updated this CounterBasedGauge64 - Does this satisfy your point? SNMP has a richer set of types. ### Section 5 The IANA section should probably follow more closely RFC 8126, notably specifying the right registry (e.g., "SMI Network Management MGMT Codes Internet-standard MIB") [Don] Thanks we updated this an noted. ### Section 8.1 Unsure whether I-D.ietf-ipsecme-yang-iptfs (and perhaps I-D.ietf-ipsecme-iptfs) is a normative reference (i.e., I can implement this I-D MIB without accessing the YANG module). [Don] We moved the YANG to informative. We left the IP-TFS core draft as normative since it is the source for the attributes. ## NITS ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec