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 protected]] > 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 protected] > 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) > > 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 protected]> > 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 protected] > > https://www.ietf.org/mailman/listinfo/gen-art _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
