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
