Subject: [netmod] Alissa Cooper's Discuss on draft-ietf-netmod-module-tags-07: (with DISCUSS and COMMENT)

From: Alissa Cooper via Datatracker <[email-masked]>
Date: Thu, 11 Apr 2019 05:38:17 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-netmod-module-tags-07: 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 https://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:
https://datatracker.ietf.org/doc/draft-ietf-netmod-module-tags/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This is a minor thing, but people get really confused about it so I'd like to
discuss it. This document allows for minting new "IETF Standard" tags by
publishing documents that are not standards of any kind. That is, because the
registry specified in 7.2 has its allocation policy as IETF Review, that means
that informational documents can be used to register new "IETF Standard" tags.
This seems ripe for creating further confusion about what is and is not an IETF
"standard." Could these tags simply be called "IETF tags"?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I strongly encourage you to follow the advice of the Gen-ART reviewer and
include a contact or change controller field in the registry defined in 7.1.
For a registry where you expect other SDOs to be making registrations, this
field can be critical if the registry entries need to be updated years after
they are created. See RFC 8126 Section 9.5.

Adam noted that RFC 8199 is now a downref, based on changes made in the -07,
after IETF last call. I think this is fine and does not require another last
call.