Looking at the draft, at a sample IANA registry (I picked one I knew),
and Nico's comment, I think I see a potential for confusion in the
current text.
The text is clear that it is talking about IETF drafts. That part is
fine in my view. But it is unclear within that what registries the
"change control" marker is to be applied to. On the one hand, there is
no point in a Change Control designation for an IETF review
registration, as the definition for change control is the IETF. On the
other hand, for expert review, first-come / first -served, or
experimental use, change control does not reside with the IETF or the
working group.
For some registries, the "IETF review" really does mean the working
group. (Routing Protocol code points go through the relevant working
group.) For others, there can be and often is overlapping
responsibility, which is why the policy is "IETF review" not "Working
Group Review".
And contact information, as is discussed in the draft, depends upon
contact for what purpose. For background on a registry, the working
group is the contact. But for expert review, IANA is the contact, who
then goes to the experts.
I think this draft needs a more nuanced presentation. It might also
help if we spelled out what we understand the purpose of these fields to
be. If the "change control" field is understood to be the authority who
can change the rules for the registry, then for IETF created registries
that does seem to be the IETF. But if "change control" is entry
creation, then it depends upon the registry type.
Yours,
Joel
On 4/11/2020 12:09 AM, Nico Williams wrote:
On Fri, Apr 10, 2020 at 08:56:56PM -0400, John C Klensin wrote:
However, there is a broader issue that I think we should all be
keeping in mind, especially when things like ongoing discussion
about the proposals associated with ETSI and ITU-T or a question
asked at the plenary should remind us. The IETF didn't invent
packet switching or even TCP/IP. Even if "we" had, we produce
voluntary standards, standards whose adoption depends on
perceptions of their technical quality and of the openness,
balance, and fairness of the processes that produce them and not
because the IETF has any claim to ownership of any particular
set of standards and protocols that anyone else is required to
take seriously. "We" also don't get to determine what gets
layered on top of our core protocols: Not only does
"permissionless innovation" (a song many of us have sung for
years) not mean "don't need permission of anyone other than the
IETF", but, had consultation with the IETF been a requirement
before its early development, we might not have the web, at
least a web running as part of the Internet.
Indeed. And the main problem with Barry's I-D is that it feels like an
understated change to IANA registries. At best it confuses how those
IANA registries that don't require Protocol Action would work. At worst
it's a power grab.
The given justification (something to do with consistency) is utterly
underwhelming. Any change of this magnitude should require stronger
justification.
Anyways, the idea that registration requests by individuals should be
ascribed to the IETF seems _really_ wrong -- a complete misunderstanding
of the IANA. That or I completely misunderstood the I-D. If the
latter, please clue me in.
[...]. So, if a process change
proposal, especially one that appears to give the IESG more
power and authority, shows up after an IESG internal discussion,
it is important to be extra-sure that the community consensus is
clear if the IESG later adopts it. [...]
[...]. That goes beyond specific types of proposals: for
example, maybe we need to think about recall procedures less in
terms of "do we trust the IESG and IAB" and "maybe any problems
can wait for the next NomCom" but in terms of it being obvious
that we have clear and workable models by which the community
can insure fairness and protect itself against cabals within the
leadership and other abuses.
Again, those things (and probably others we might benefit from
having clearer rules and procedures about) are not because we
don't trust our leadership, but that, especially in troubled
times, the appearance of a fair and open process with good
safeguards against abuse or dominance by particular people in
the leadership, or particular companies or clusters of
interests, may be as or more important that our internal
confidence that such things are not occurring.
Trust, but not really.
Nico
