Warren One of the points I raise below calls for input from the WG Chairs.
The registry that is being updated http://www.iana.org/assignments/snmp-number-spaces/snmp-number-spaces.xh tml#snmp-number-spaces-5 requires Standards Track for updating. The current I-D is Informational. This will hit a brick wall when it reaches IANA (I-d Advancement Not Admissible). Johannes wisely said that that he would look for the agreement of the chairs for this change. Do you agree? 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
