----- 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"
> 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...
Warren
You go to the website and see if they have already been approved.
http://trac.tools.ietf.org/group/iesg/trac/wiki/DownrefRegistry#
(2104 6234 have and the latter has a Normative Reference to FIPS 180-3
which should serve although a strict reading of the web page says not;
but then a strict reading of the web page says that Russ Housley should
have caused the FIPS document to have been added to the web page which
it wasn't).
Then it is up to the AD to see if they warrant a mention in IETF Last
Call using the information that the Document Shepherd has put in section
15.
Tom Petch
> 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
