Subject: [Gen-art] IANA and AUTH48 (Was: Re: Gen-ART LC review of draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02)

From: Jari Arkko <[email-masked]>
Date: Thu, 17 Mar 2016 08:11:33 +0000

(Adding the IESG)

First, thanks for the review, Dan! I have balloted no-obj.

As for the question about IANA and AUTH48, I’m a bit conflicted there. More checking is good, but I don’t want to add more things to do in AUTH48.

But I’d like to understand where the issue really was. I guess the issue was that a discussion between the authors and IANA resulted in doing the right thing, but no body remembered to bring the update back to the I-D.

I don’t know when this happened, but it could already have happened while the document was in IESG processing.

This seems to be a more general problem, in that we often say “we’ll fix it in AUTH48”, but don’t actually edit docs or place RFC Ed notes. I’d like to suggest that whenever we plan to do something in AUTH48, at least an RFC Editor’s note about the matter (not necessarily the final edit) needs to be added to the tracker before approval. This ensures that the RFC Editor would see the issue.

Thoughts?

Jari

On 18 Jan 2016, at 11:54, Romascanu, Dan (Dan) <[email-masked]> wrote:

> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed
> by the IESG for the IETF Chair.  Please treat these comments just
> like any other last call comments.
> 
> For more information, please see the FAQ at
> 
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq
> 
> Document: draft-ietf-opsawg-hmac-sha-2-usm-snmp-new-02.txt
> Reviewer: Dan Romascanu
> Review Date: 1/18/16
> IETF LC End Date: 1/18/16
> IESG Telechat date: (if known):
> 
> Summary:
> 
> Ready.
> 
> This document is an update that fixes a problem with RFC 7360 where MODULE-IDENTITY was defined as { snmpModules 235 } rather than { mib-2 235 } as advised by the MIB Doctors and recommended by IANA. The rest of the content is identical with RFC 7360.
> 
> 
> Major issues:
> 
> There is a process issue that the IESG, IANA and the RFC Editor should check (maybe they already did it) in order to avoid such situations in the future. Is IANA involved in AUTH 48 last review of the document? If they are not, maybe they should be. In this case the MIB Doctors recommendation was implemented by IANA in the registry, but the content of the document was not fixed, and nobody at AUTH 48 discovered the problem.
> 
> Minor issues:
> 
> Nits/editorial comments:
> 
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 21 Mar 2016 15:39:23 +0000

Hi,

Obviously, an explicit RFC Editor note would solve the problem in the majority if not all the foreseeable cases. The burden is on the AD and to some extent to the IESG who should minute the decision as 'Approved. RFC Editor Note.' and maybe add 'IANA-related edit' in the minutes to make sure the issue is not forgotten (there may be multiple items in the RFC Editor notes). 

Regards,

Dan

> -----Original Message-----
> From: Jari Arkko [mailto:[email-masked]]
> Sent: Thursday, March 17, 2016 10:12 AM
> To: Romascanu, Dan (Dan); The IESG
> Cc: General Area Review Team; draft-ietf-opsawg-hmac-sha-2-usm-snmp-
> [email-masked]
> Subject: IANA and AUTH48 (Was: Re: [Gen-art] Gen-ART LC review of draft-
> ietf-opsawg-hmac-sha-2-usm-snmp-new-02)
> 
> (Adding the IESG)
> 
> As for the question about IANA and AUTH48, I'm a bit conflicted there. More
> checking is good, but I don't want to add more things to do in AUTH48.
> 
> But I'd like to understand where the issue really was. I guess the issue was
> that a discussion between the authors and IANA resulted in doing the right
> thing, but no body remembered to bring the update back to the I-D.
> 
> I don't know when this happened, but it could already have happened while
> the document was in IESG processing.
> 
> This seems to be a more general problem, in that we often say "we'll fix it in
> AUTH48", but don't actually edit docs or place RFC Ed notes. I'd like to
> suggest that whenever we plan to do something in AUTH48, at least an RFC
> Editor's note about the matter (not necessarily the final edit) needs to be
> added to the tracker before approval. This ensures that the RFC Editor would
> see the issue.
> 
> Thoughts?
> 
> Jari
> 
> > Review Team (Gen-ART) reviews all IETF documents being processed by
> > the IESG for the IETF Chair.  Please treat these comments just like
> > any other last call comments.
> >
> > This document is an update that fixes a problem with RFC 7360 where
> MODULE-IDENTITY was defined as { snmpModules 235 } rather than { mib-2
> 235 } as advised by the MIB Doctors and recommended by IANA. The rest of
> the content is identical with RFC 7360.
> >
> >
> > Major issues:
> >
> > There is a process issue that the IESG, IANA and the RFC Editor should
> check (maybe they already did it) in order to avoid such situations in the
> future. Is IANA involved in AUTH 48 last review of the document? If they are
> not, maybe they should be. In this case the MIB Doctors recommendation
> was implemented by IANA in the registry, but the content of the document
> was not fixed, and nobody at AUTH 48 discovered the problem.
> >
> > Minor issues:
> >
> > Nits/editorial comments:
> >
> >

---

From: joel jaeggli <[email-masked]>
Date: Mon, 21 Mar 2016 08:59:52 -0700

On 3/21/16 8:39 AM, Romascanu, Dan (Dan) wrote:
> Hi,
> 
> Obviously, an explicit RFC Editor note would solve the problem in the
> majority if not all the foreseeable cases. The burden is on the AD
> and to some extent to the IESG who should minute the decision as
> 'Approved. RFC Editor Note.' and maybe add 'IANA-related edit' in the
> minutes to make sure the issue is not forgotten (there may be
> multiple items in the RFC Editor notes).

To be clear though In general I'd vastly prefer to send a document to
the rfc editor that is correct. so holding for edits seems like the most
appropriate first order step.

> Regards,
> 
> Dan
> 
> 
>> -----Original Message----- From: Jari Arkko
>> [mailto:[email-masked]] Sent: Thursday, March 17, 2016 10:12
>> AM To: Romascanu, Dan (Dan); The IESG Cc: General Area Review Team;
>> draft-ietf-opsawg-hmac-sha-2-usm-snmp- [email-masked] 
>> Subject: IANA and AUTH48 (Was: Re: [Gen-art] Gen-ART LC review of
>> draft- ietf-opsawg-hmac-sha-2-usm-snmp-new-02)
>> 
>> (Adding the IESG)
>> 
>> As for the question about IANA and AUTH48, I'm a bit conflicted
>> there. More checking is good, but I don't want to add more things
>> to do in AUTH48.
>> 
>> But I'd like to understand where the issue really was. I guess the
>> issue was that a discussion between the authors and IANA resulted
>> in doing the right thing, but no body remembered to bring the
>> update back to the I-D.
>> 
>> I don't know when this happened, but it could already have happened
>> while the document was in IESG processing.
>> 
>> This seems to be a more general problem, in that we often say
>> "we'll fix it in AUTH48", but don't actually edit docs or place RFC
>> Ed notes. I'd like to suggest that whenever we plan to do something
>> in AUTH48, at least an RFC Editor's note about the matter (not
>> necessarily the final edit) needs to be added to the tracker before
>> approval. This ensures that the RFC Editor would see the issue.
>> 
>> Thoughts?
>> 
>> Jari
>> 
>>> I am the assigned Gen-ART reviewer for this draft. The General
>>> Area Review Team (Gen-ART) reviews all IETF documents being
>>> processed by the IESG for the IETF Chair.  Please treat these
>>> comments just like any other last call comments.
>>> 
>>> Reviewer: Dan Romascanu Review Date: 1/18/16 IETF LC End Date:
>>> 1/18/16 IESG Telechat date: (if known):
>>> 
>>> Summary:
>>> 
>>> Ready.
>>> 
>> MODULE-IDENTITY was defined as { snmpModules 235 } rather than {
>> mib-2 235 } as advised by the MIB Doctors and recommended by IANA.
>> The rest of the content is identical with RFC 7360.
>>> 
>>> 
>>> Major issues:
>>> 
>> check (maybe they already did it) in order to avoid such situations
>> in the future. Is IANA involved in AUTH 48 last review of the
>> document? If they are not, maybe they should be. In this case the
>> MIB Doctors recommendation was implemented by IANA in the registry,
>> but the content of the document was not fixed, and nobody at AUTH
>> 48 discovered the problem.
>>> 
>>> Minor issues:
>>> 
>>> Nits/editorial comments:
>>> 
>>> 
>>> _______________________________________________ Gen-art mailing
>>> list [email-masked]

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Mon, 21 Mar 2016 16:04:30 +0000

Of course. It's just that sometimes ADs (maybe not nowadays, but I may have sinned once or more when I was an AD) leave 'simple' edits to the RFC Editor. Which should be fine unless you forget to mention these in the RFC Editor notes :-) 

Regards,

Dan

> From: joel jaeggli [mailto:[email-masked]]
> Sent: Monday, March 21, 2016 6:00 PM
> To: Romascanu, Dan (Dan); Jari Arkko; The IESG

> To be clear though In general I'd vastly prefer to send a document to the rfc
> editor that is correct. so holding for edits seems like the most appropriate
> first order step.
>