(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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art

Reply via email to