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
