Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-vmm-mib
[ Top post ]
Scott and I discussed this document again today, and, in light of the
comments we got after the WGLC ended, have decided that there is now
enough evidence of support to proceed.
Thank you to everyone who commented, and apologies to the authors for
the runaround.
One of us will write up the shepherd document shortly.
W
On Wed, Jan 28, 2015 at 6:40 PM, Warren Kumari wrote:
> On Fri, Jan 9, 2015 at 12:15 PM, Warren Kumari wrote:
>> Dear OpsAWG WG,
>>
>> The authors of draft-ietf-opsawg-vmm-mib have indicated that they
>> believe that the document is ready, and have asked for Working Group
>> Last Call.
>>
>> The draft is available here:
>> https://datatracker.ietf.org/doc/draft-ietf-opsawg-vmm-mib/
>>
>> Please review this draft to see if you think it is ready for
>> publication and send comments to the list, clearly stating your view.
>>
>> This WGLC ends Fri 23-Jan-2015.
>>
>> In addition, to satisfy RFC 6702 ("Promoting Compliance with
>> Intellectual Property Rights (IPR)"):
>> Are you personally aware of any IPR that applies to
>> draft-ietf-opsawg-vmm-mib? If so, has this IPR been disclosed in
>> compliance with IETF IPR rules? (See RFCs 3979, 4879, 3669, and 5378
>> for more details.)
>>
>> Thanks,
>> Warren Kumari
>> (as OpsAWG WG co-chair)
>
> The WGLC has concluded with no feedback or comments, and so we have to
> conclude that the WG is no longer interested in this work.
>
> Apologies to the authors,
> W
>
>>
>> --
>> 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
--
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
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] Alissa Cooper's Discuss on draft-ietf-opsawg-coman-probstate-reqs-04: (with DISCUSS)
Alissa Cooper has entered the following ballot position for draft-ietf-opsawg-coman-probstate-reqs-04: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: http://datatracker.ietf.org/doc/draft-ietf-opsawg-coman-probstate-reqs/ -- DISCUSS: -- I'm putting this in as a DISCUSS in the event that the authors/WG want to discuss it or that I'm just missing some context, but I will happily move to ABSTAIN if there is no appetite for such discussion -- I see no need to block the document from advancing on the basis of my comments. It's really hard to tell how the "requirements" listed in this document are intended to be used. In fact, it seems incorrect to call them "requirements" at all -- in the sense of somehow being "required" -- given the following: This document provides a problem statement and lists potential requirements for the management of a network with constrained devices. ... Depending on the concrete circumstances, an implementer may decide to address a certain relevant subset of the requirements. ... This document in general does not recommend the realization of any subset of the described requirements. As such this document avoids selecting any of the requirements as mandatory to implement. A device might be able to provide only a particular selected set of requirements and might not be capable to provide all requirements in this document. On the other hand a device vendor might select a specific relevant subset of the requirements to implement. It's hard to see how the approach described above will contribute towards useful standardization. The "requirements" seem more like a laundry list of all the properties that a management architecture, management protocols, networks of constrained devices, and/or individual implementations might find desirable. This also makes me wonder how the WG intends for these "requirements" to be used. What is the next step as far as standardization goes? To design the "management architecture" that is mentioned? Or the "management protocols" that are mentioned -- one or more, working together or separately? Or to consider how existing management protocols can be repurposed for constrained networks (which is sort of hinted at in section 2, but not stated explicitly), to meet some undefined subset of the listed "requirements"? I think publishing a laundry list of desirable properties is ok if people find value in it, but I'm having trouble seeing how this document specifies either a problem statement or requirements that will somehow contribute to standardization efforts in the future. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] ID Tracker State Update Notice:
IANA action state changed to RFC-Ed-Ack ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] ID Tracker State Update Notice:
IANA action state changed to Waiting on RFC Editor ID Tracker URL: http://datatracker.ietf.org/doc/draft-ietf-opsawg-capwap-hybridmac/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt
On Wed, Feb 18, 2015 at 5:46 AM, t.petch wrote:
> - Original Message -
> From: "Warren Kumari"
> To: "Johannes Merkle"
> Cc: ; "Scott Bradner" ; "t.petch"
>
> 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.
>
Oh, excellent. Thank you, my search foo failed me...
W
> 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
> 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
> 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"
>> >> To: "t.petch" ; "Warren Kumari"
>
>> >> Cc: ; "Scott Bradner"
>> >> 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~ ?
>> >>>
>> >>> St
[OPSAWG] I-D Action: draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt
A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF. Title : HMAC-SHA-2 Authentication Protocols in USM for SNMP Authors : Johannes Merkle Manfred Lochter Filename: draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt Pages : 13 Date: 2015-02-18 Abstract: This memo specifies new HMAC-SHA-2 authentication protocols for the User-based Security Model (USM) for SNMPv3 defined in RFC 3414. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
[OPSAWG] New Version Notification - draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt
A new version (-03) has been submitted for draft-ietf-opsawg-hmac-sha-2-usm-snmp: http://www.ietf.org/internet-drafts/draft-ietf-opsawg-hmac-sha-2-usm-snmp-03.txt The IETF datatracker page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/ Diff from previous version: http://www.ietf.org/rfcdiff?url2=draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. IETF Secretariat. ___ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt
- Original Message -
From: "Warren Kumari"
To: "Johannes Merkle"
Cc: ; "Scott Bradner" ; "t.petch"
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
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
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"
> >> To: "t.petch" ; "Warren Kumari"
> >> Cc: ; "Scott Bradner"
> >> 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
Re: [OPSAWG] I-D Action:draft-ietf-opsawg-hmac-sha-2-usm-snmp-00.txt
- Original Message -
From: "Warren Kumari"
To: "Johannes Merkle"
Cc: ; "Scott Bradner" ; "t.petch"
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
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
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"
> >> To: "t.petch" ; "Warren Kumari"
> >> Cc: ; "Scott Bradner"
> >> 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
