Subject: Re: [OPSAWG] Start of WGLC for draft-ietf-opsawg-hmac-sha-2-usm-snmp - *please* review.

From: Johannes Merkle <[email-masked]>
Date: Mon, 2 Mar 2015 12:31:51 +0100

Warren Kumari schrieb am 20.02.2015 um 15:47:
> Dear OpsAWG WG,
> 
> The authors of draft-ietf-opsawg-hmac-sha-2-usm-snmp-03 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-hmac-sha-2-usm-snmp-03/
> 

In case you get a 404 error, the correct link is
https://datatracker.ietf.org/doc/draft-ietf-opsawg-hmac-sha-2-usm-snmp/

Johannes

---

From: t.petch <[email-masked]>
Date: Fri, 6 Mar 2015 10:07:23 +0000

Subject to resolving Juergen's comments satisfactorily, yes, I am ok
with it.

Tom Petch

----- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]>
To: "Warren Kumari" <[email-masked]>
Sent: Friday, February 20, 2015 4:49 PM
>
> I have reviewed this document and I support it moving forward. There
> are a couple of nits that should be fixed before submitting the
> document to the IESG.
>
> Section 7.1:
>
>  - replace "MIB" with "MIB module"
>
> Section 7.2:
>
>  - replace "The SNMP Management Architecture
>    MIB (SNMP-FRAMEWORK-MIB)" with "SNMP-FRAMEWORK-MIB"
>
>  - remove "Therefore, the use of the HMAC-SHA2 authentication
>    protocols requires the usage of the objects defined in the
>    SNMP-FRAMEWORK-MIB." since this sentence is not needed
>
> Section 7.3:
>
>   - replace "IMPORTS objects" with "IMPORTS definitions"
>
> Section 8:
>
>  - The comment behind LAST-UPDATED is wrong (this happens once
>    there is redundant information)
>
>  - The DESCRIPTION clause of the MODULE-IDENTITY macro says that there
>    is supplementary information at IANA. I am not sure what this
means.
>    Perhaps this last paragraph needs to be changed to what other
recent
>    MIB modules include, namely a short version of the copyright
>    statement. See for example RFC 7331.
>
>  - This may be wrong: usmHMAC384SHA12AuthProtocol (a 5 missing)
>
>  - The MIB modules compiles using smilint after fixing the RFC Ed.
>    comments below the definition of usmHMAC256SHA384AuthProtocol and
>    usmHMAC384SHA12AuthProtocol.
>
> Section 9.1:
>
>  - I think this sentence should be changed to this:
>
>    The security considerations of [RFC3414] also apply to the
>    HMAC-SHA-2 authentication protocols defined in this document.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>
>

---

From: Warren Kumari <[email-masked]>
Date: Fri, 6 Mar 2015 11:47:41 -0500

On Fri, Feb 20, 2015 at 9:47 AM, Warren Kumari <[email-masked]> wrote:
> 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 document has already received significant review during adoption,
> etc. and so reviewing it should not be a large hardship. We'd like at
> **least** 5 regular WG participants to chime in saying that they
> support the document.
>
>
> This WGLC ends Fri 06-Mar-2015.

Dear everyone,

Thanks for participating -- we see consensus for publication.
I will write up the shepherd report shortly.
W

>
>
> 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-hmac-sha-2-usm-snmp-03?  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)
>
> --
> 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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Mar 2015 18:17:35 +0100

Dear chairs,

I think I raised some points during WG last call that should be
addressed and I think others supported this. So I would assume that a
revised I-D is needed first before this goes to the IESG.

What about producing the writeup of the VMM-MIB in the meantime, which
has passed WG last call as announced on Feb 18th.

/js

On Fri, Mar 06, 2015 at 11:47:41AM -0500, Warren Kumari wrote:
> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

---

From: Warren Kumari <[email-masked]>
Date: Fri, 6 Mar 2015 12:45:37 -0500

> revised I-D is needed first before this goes to the IESG.

Yup. Status in the datatracker is marked as: Revised I-D Needed -
Issue raised by WGLC

I can still write up the shepherd report (it's not likely to change
much), but we'll not submit till the draft has been revised.

> has passed WG last call as announced on Feb 18th.

Yup, Scott is handling that one.
W

> Fax:   +49 421 200 3103

---

From: Johannes Merkle <[email-masked]>
Date: Mon, 9 Mar 2015 15:58:46 +0100

I am not sure, how to resolve this comment. Please give advice.

>    there is redundant information)

Shouldn't the dates specified in LAST-UPDATED and REVISION be the publication date of the RFC? In this case, I would
need to add place holders with comments for the RFC Ed to replace them with the publication date. Or should these dates
be set to the  date when the MIB was finally prepared (neglecting editorial changes by the RFC Ed?

-- 
Johannes

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 9 Mar 2015 16:20:21 +0100

> be set to the  date when the MIB was finally prepared (neglecting editorial changes by the RFC Ed?

Ideally it is the publication date (or more precisely the date when
the final edits were made by the RFC Editor). They usually understand
this for MIB modules but it never hurts to be explicit (and the check
during AUTH48 as well).

/js

---

From: Johannes Merkle <[email-masked]>
Date: Wed, 11 Mar 2015 15:25:43 +0100

> much), but we'll not submit till the draft has been revised.

I have already updated my internal draft, but, due to the IETF 92, submission is not possible until March 22nd.

-- 
Johannes

---

From: Warren Kumari <[email-masked]>
Date: Tue, 24 Mar 2015 14:48:14 -0500

A new version has been posted with all the comments addressed, and so
I'm requesting publication.

W