(1) What type of RFC is being requested:
Standards Track - this document
request an assignment from the SnmpAuthProtocols registry
(http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xhtml#snmp-number-spaces-5)
which requires a Standards Track document.
(2) Technical Summary:
This memo specifies new HMAC-SHA-2 authentication protocols for USM using an
HMAC based on the SHA-2 family of hash functions. They are straightforward
adaptations of the authentication protocols HMAC-MD5-96 and HMAC-SHA-96 to the
SHA-2 based HMAC.
Working Group Summary:
During the adoption call we discovered that there was another document
(https://datatracker.ietf.org/doc/draft-hartman-snmp-sha2/) which did
something very similar. This document had been written earlier, but neither
the document authors, nor most of the OpsAWG WG was aware of it. The CfA
stalled for a long time while we asked the WG to decide which option they
proffered, and to see if there was a clean way to combine the two
documents. In the end, the authors of hartman-snmp-sha2 agreed that this
document (hmac-sha-2-usm-snmp) should progress.
Document Quality:
The document is well written and clear. David Reid (at least) has implemented
this ("We have also implemented it (using private OIDs for now).")
Personnel:
Warren Kumari will be the document shepherd. Joel Jaeggli will be the AD.
(3) The DS is also the chair of the WG. He followed the document during its
lifetime.
(4) Does the document Shepherd have any concerns about the depth or breadth of
the reviews that have been performed?
Nope. The right set of people reviewed
the document. We got sufficient review during the WGLC, but also got lots of
review during the CfA. What the document is an important maintenance activity,
not new protocol design.
(5) Do portions of the document need review from a particular or from broader
perspective:
Nope.
(6) Describe any specific concerns or issues:
None
(7) Has each author confirmed that any and all appropriate IPR disclosures
required for full conformance with the provisions of BCP 78 and BCP 79 have
already been filed.
Yes.
(8) Has an IPR disclosure been filed that references this document?
Nope.
(9) How solid is the WG consensus behind this document?
Good consensus. See Answer 4.
(10) Has anyone threatened an appeal?
Nope.
(11) Identify any ID nits the Document Shepherd has found in this
document.
None!
(12) Describe how the document meets any required formal review criteria:
The document shepherd
extracted the MIB and then ran (online) MIB tests, at maximum strictness
levels. After making some fixups (e.g: replacing 'aa' (to be assigned by IANA)
with numbers) it linted fine. Michael MacFaden also checked it and found it
clean.
(13) Have all references within this document been identified as either
normative or informative?
Yes.
(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state?
No.
(15) Are there downward normative references references (see RFC 3967)?
** YES **
Normative reference to an Informational RFC 2104 Non-RFC normative reference
'SHA' Normative reference to an Informational RFC 6234RFC 2104 and RFC 6234 are in the downregreg (which is currently throwing 500
Errors) SHA references: National Institute of Standards and Technology,
"Secure Hash Standard (SHS)", FIPS PUB 180-4, March 2012. Note that RFC2014
and RFC6234 also reference versions of this document.
(16) Will publication of this document change the status of any existing RFCs?
Nope.
(17) Describe the review of the IANA considerations section.
The IANA registry section is clear, and matches up with the requests
in the document.
(18) Any new IANA registries?
None.
(19) Describe reviews and automated checks performed by the Document
Shepherd.
Shepherd ran online MIB checker at max strictness.
Michael MacFaden and Juergen Schoenwaelder also checked.
The MIB checker threw some errors, but these were
all for things like '{ snmpAuthProtocols dd } -- dd to be assigned by
IANA'. Replacing these with numbers made things happy.