Hi, SM, and thanks for the review. Sorry for the delay in responding.
"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.
Thanks again for the thorough review.
Barry