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...
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
