Robert Wilton has entered the following ballot position for draft-ietf-ipsecme-mib-iptfs-06: 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-ipsecme-mib-iptfs/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Hi, Thanks for this document. Please can you add an RFC editor's note to ensure that the MIB Module and MIB tree are suitably updated once IANA has assigned a code point for the iptfsMIB. I support Eric's comment that Guage32 (or possibly even CountedBasedGauge64 defined in RFC 2856) may be a better choice than Counter64 for the l2FixedRate and l3FixedRate. However, I also appreciate that there is probably also a strong desire to keep the MIB entirely consistent with the YANG. I noted that the IANA considerations section is requesting an OID code point for both the iptfs and ipsec MIBs, but it wasn't clear to me why ipsec was being registered here, since the isn't any ipsec MIB being defined in this document. Is this registration left over from an earlier draft, or does it serve some other purpose? Regards, Rob _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
