"For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA) [RFC2860]."
Given that there seems to be a service mark for "Internet Assigned Numbers Authority", shouldn't there be an IPR disclosure?
Not that I can tell. We use "IANA" and its expansion regularly, and I see no reason to change anything about that here (this also goes to your other comments about changing how we refer to IANA).
"IANA services are currently provided by the International Corporation
for Assigned Names and Numbers (ICANN)."
According to www.icann.org there is an "Internet Corporation For Assigned Names and Numbers".
Yes, I mis-expanded it (or 5226 did; I'm not bothering to check). Corrected in my working version.
'For this document, "the specification" as used by RFC 2119 refers to
the processing of protocol documents within the IETF standards
process.'
There was a thread about registration policies (see http://www.ietf.org/mail-archive/web/ietf/current/msg88598.html ). My reading of the quoted text is that the key words do not apply to documents in the IRTF and Independent Streams.
This document is about the IETF stream. It's up to the other streams to specify that this document applies to them as well, and I believe that they do. There's a lot of stuff that is defined to apply to "the IETF standards process" that other streams also use.
"In particular, when a registry policy that requires involvement of
Working Groups, directorates, or other bodies to be actively involved
and to support the effort, requests frequently run into concerns that
"it's not worth doing a Standards-Track RFC for something this
trivial," when, in fact, that requirement was created by the Working
Group in the first place, by placing the bar that high."
Are directorates involved in registry policy?
They certainly could be. I don't see a reason not to mention them.
I suggest changing "Standards-Track RFC" to RFC as even an RFC is a high bar and it is a non-trivial requirement.
It's an example of an argument I've actually heard, and I'm inclined to leave it.
In Section 3.3:
"In order to allow assignments in such cases, the IESG is granted
authority to override registration procedures and approve assignments
on a case-by-case basis."
In other words the registry policy used is "IESG Approval". There is already a good description of that in Section 4.10. I do not see the need to emphasize that the IESG has the authority to do so.
It seems that Section 3.3 is trying to address a different problem than what is in RFC 7120, i.e. the registration procedure does not adequately cover the reality of registry operation. For example, there was an RFC published because an email address had to be updated. It is onerous to go through such an effort for an email address change. If that happens a few times it is a sign that the registration procedure should be updated.
Indeed, and that's exactly what section 3.3 says: that it's a sign that an update is needed. I think this section is valuable, and don't think it should be removed or changed. It's important to talk about the IESG being able to override things where necessary.
Barry