----- Original Message -----
From: "Warren Kumari" <[email protected]>
To: "Johannes Merkle" <[email protected]>
Cc: <[email protected]>; "Scott Bradner" <[email protected]>; "t.petch"
<[email protected]>
Sent: Tuesday, February 17, 2015 9:48 PM
> And I *think* that this addresses the open questions (see Joel's
> response on the "adding an entry to a registry" question) - please
> feel free to poke me is I missed any...
>
> While having another look before starting the WGLC I found a few more
> minor nits.
>
> 1:
> Values of constants M (the length of the secret key) and N (the length
> of the MAC output) used below, are:
> usmHMAC128SHA224AuthProtocol: M=28, N=16;
> ..."
> it might be nice to say that M and N lengths are octets. This should
> be blindingly obvious from the text in Section 4.1, but doesn't hurt.
>
> 2:
> Your instructions to the RFC Ed contain an off-by-one type error:
> " ::= { snmpAuthProtocols bb } -- bb to be assigned by IANA
> -- RFC Ed.: replace cc with actual number assigned by IANA &
> remove this line"
It's not one off.
There is a similar mismatch for 'cc' and 'dd' and 'dd' and 'ff'
Tom Petch
> 3:
> -02 still has a reference to RFC4231, which isn't used in the doc.
>
> Other:
> There are still some downward references to Informational documents,
> which is a process issue I've not had to deal with recently, and so
> have forgotten the procedure...
> I poked around and there are ~80 Standards Track documents that have
> Normative downrefs to RFC2104, and 3 that reference RFC6234.
> RFC3967 (Clarifying when Standards Track Documents may Refer
> Normatively to Documents at a Lower Level) says that the normal last
> call happens, and we note that there are downward refs. If the AD
> believes that this is a well known case, they may waive this bit.
> Entertainingly enough, it also uses RFC2104 as an example of this
> ("For example, the use of MD5 [RFC1321] and HMAC [RFC2104] is well
> known among cryptographers.").
> So, I think we can go ahead with this and I'll make a note when we
> send it over to our AD and he can deal with it.
>
> While we *could* note these in the WGLC call, I think it would be
> cleaner if you could post a new version, and then I think we can kick
> off the WGLC.
>
> W
>
>
> On Tue, Feb 17, 2015 at 3:15 PM, Warren Kumari <[email protected]>
wrote:
> > 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
>
>
>
> --
> 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
