Apologies for the delay - Scott and I were planning on meeting in Singapore to discuss a bunch of OpsAWG stuff, but the scheduling didn't work out (we were there for different meetings and he arrived just before I left...)
Anyway, yup, Standards Track (which you've already done, this just closes the loop...) On Fri, Jan 30, 2015 at 5:22 AM, t.petch <[email protected]> wrote: > 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 > -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
