forwarded to opsawg -------- Forwarded Message -------- Subject: Re: AD help needed by opsawg Date: Fri, 30 Jan 2015 23:57:36 -0800 From: joel jaeggli <[email protected]> To: Bradner, Scott <[email protected]>, [email protected] <[email protected]> CC: Warren Kumari <[email protected]>
On 1/30/15 2:59 AM, Bradner, Scott wrote: > Joel can you help here The registration procedure for the snmp number spaces is by-in-large standards track modula transport which is spec-required. Requesting a new auth protocol is therefore question of the draft creating one, not of altering 3411. if you are changing the registry policy or altering the interpretation of 3411 that would entail updating the draft. in the meantime we can allocate points within the number space without changing our interpretation of how the registry works. Lets roll some hmac-sha2 thanks joel > Scott > > >> Begin forwarded message: >> >> From: t.petch <[email protected]> >> To: <[email protected]> >> Date: January 30, 2015 at 5:21:37 AM EST >> Cc: <[email protected]>, Scott Bradner <[email protected]> >> Subject: Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt >> >> Joel >> >> One of the issues that I raise below on this I-D would benefit from AD >> guidance. >> >> The I-D adds entries to a registry established by RFC3411. Should the >> I-D then say that is updates RFC3411 or not? My experience is that some >> ADs say that this is NOT an update, while other ADs have said, at least >> in the past, that it IS an update. I would prefer that the I-D is in >> line with your thinking before it advances. >> >> Guidance please. >> >> The nearest parallel in the SNMP world is RFC3826 which added an >> snmpPrivProtocol to the registry also established by RFC3411, in June >> 2004, and which is not listed as updating any RFC. >> >> Tom Petch >> >> ----- Original Message ----- >> From: "Johannes Merkle" <[email protected]> >> To: "t.petch" <[email protected]>; "Warren Kumari" <[email protected]> >> Cc: <[email protected]>; "Scott Bradner" <[email protected]> >> Sent: Thursday, January 29, 2015 8:03 AM >> >>> Tom, >>> >>> thanks for the thorough review. This really helps improving the >> document. >>> >>>> s4.2.1 step 2 uses RFC6234 in a way that I think must make it a >>>> Normative reference. RFC6234 is not Standards Track but that is ok, >> it >>>> is already in the list of IESG permitted downrefs (does that need >>>> calling out at IETF Last Call?) >>> >>> You are right, but the question is whether I should rather use >> references [RFC2104] and [SHA] here. >>> >>>> >>>> s9.1 >>>> /apply the use /apply to the use / >>> >>> Right. >>> >>>> >>>> s9.2 >>>> is it the length of the key that gives it strength or its entropy? >> Is >>>> abcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcdabcd0004 >>>> really stronger than >>>> !qaurk/99SS~ ? >>> >>> Strictly speaking, you are right, but it is common sense that >> cryptographic keys should have maximum entropy, i.e., they >>> should be selected uniformly at random from bit string of that length. >> Consequently, virtually all cryptographic papers >>> and text books use key the key length synonymous to its entropy. Thus, >> I consider this distinction as unnecessary. >>> >>>> >>>> s9.4 refers to OBJECTS, but there aren't any, only IDENTITY so I >> think >>>> that s9.4 should reflect that (lest it confuses, or am I confused >> having >>>> missed an OBJECT somewhere?) >>> >>> Here I definitely need help, as I have no knowledge about MIBs. >> Actually, I copied that section from RFC 3411. Please >>> give advise what to write here or if this section is needed at all. >>> >>> >>>> The names used for the four protocols are not consistent within the >>>> document. Following RFC3414, I think that including Auth is >> correct. >>>> >>> oops, this escaped my attention. >>> >>>> Updates to this registry requires a Standards Track document which >> this >>>> is not. >>> >>> Wright. If the chairs agree, I'll change the track. >>> >>>> >>>> MIB Module copyright is 2004 >>> >>> opps again. Copy and paste error. >>> >>>> >>>> Does this document update RFC3414? It adds to the registry that >> that >>>> RFC created which some ADs say is NOT an update, some ADs say it IS >> an >>>> update; I think that we need guidance here (the update by RFC5590 of >>>> RFC3414 is a whole different ball game). >>> >>> I will wait for the guidance here. >>> >>> -- >>> Johannes >> >> _______________________________________________ >> OPSAWG mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/opsawg > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
