WK>Please review this draft to see if you think it is ready for WK> publication and send comments to the list, clearly stating your view.
Regarding https://tools.ietf.org/id/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt I also support adoption of the draft. Putting on the mib doctor hat, I ran smilint over the mib module as well using faux oids, smilint reports clean. $ smilint -l9 ./SNMP-USM-HMAC-SHA2-MIB $smidump -f tree SNMP-USM-HMAC-SHA2-MIB registration tree (generated by smidump 0.4.8) --snmpModules(1.3.6.1.6.3) | +--snmpFrameworkMIB(10) | | | +--snmpFrameworkAdmin(1) | | | +--snmpAuthProtocols(1) | | | +--usmHMAC192SHA256AuthProtocol(888) | | | +—usmHMAC384SHA12AuthProtocol(999) | | | +—usmHMAC128SHA224AuthProtocol(777) | | | +—usmHMAC256SHA384AuthProtocol(666) | +—snmpUsmHmacSha2MIB(666) In the Security Considerations section I had these comments: 1) To be clear, I interpret section 9.2 which states: At the time of this writing, to mean the date when the document is published. 2) Per http://trac.tools.ietf.org/area/ops/trac/wiki/mib-security the boiler plate text to add here would be the clause starting with the sentence “There are no management objects.” but would change “textual conventions” to “oid value assignments" 3) There exist rfc normative references listed in the above url boilerplate not included in the draft typically used in rfcs containing mib modules. Mike MacFaden
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
