Subject: Out for discussion: draft-leiba-ietf-iana-registrations

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2020 13:53:12 -0400

I've just posted the subject draft, resulting from recent discussions
with IANA and the IESG about consistency in specifying the registrant
/ change controller for IANA registrations that come from IETF-stream
drafts.  The Abstract:

> Abstract:
>    IETF documents have been inconsistent in what they specify as the
>    registrant (or contact, or change controller) in IANA registrations
>    they make.  This document provides a consistent specification
>    ("IETF") to be used, and allows for exceptions with IESG approval.

While this does come from IESG discussions, the document is an
individual submission by me and does not come from the IESG.

Comments/discussion, please.

Barry

---

From: Joe Touch <[email-masked]>
Date: Fri, 10 Apr 2020 11:04:23 -0700

> On Apr 10, 2020, at 10:53 AM, Barry Leiba <[email-masked]> wrote:
> 

I understand the intent of this claim but reject it. 

If it comes from privileged discussion, the IESG “hat” is glued on and cannot be removed by assertion. 

Joe

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 11:29:22 -0700

> / change controller for IANA registrations that come from IETF-stream

Regarding one point therein:

   When a document coming from an individual submitter makes an IANA
   request that specifies registrant information, "IETF" is to be used,
   as these registrations also come from the IETF as a whole via IETF
   last call consensus. 

Until a document is adopted by a WG, this is inappropriate and incorrect. The assignee and point of contact should never be the IETF until a doc is adopted.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Apr 2020 14:31:39 -0400

Joe, I do not follow your reasoning.
Barry is stating that he has talked to some of his fellow IESG members 
about the draft.  He probably also talked to people that are not on the 
IESG.
He is also telling us that the IESG has not agreed to this or adopted it 
in any formal fashion.  And that he is bringing it forward as a member 
of the community.

Those seem to be factual statements.

Yours,
Joel

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 11:35:35 -0700

Hi, Joel,

> On Apr 10, 2020, at 11:31 AM, Joel M. Halpern <[email-masked]> wrote:
> 
> Barry is stating that he has talked to some of his fellow IESG members about the draft.  He probably also talked to people that are not on the IESG.
> He is also telling us that the IESG has not agreed to this or adopted it in any formal fashion.  And that he is bringing it forward as a member of the community.
> 

As is the fact that I reject his claim of “hat off”.

I do not thing we should condone this sort of “under the radar” approach; if he's on the IESG, why isn’t this coming from the IESG? (The same goes for other docs similarly written by IESG members “as individuals”).

Notably, these sort of docs have been either about IETF process (like this) or even specific to the area of an IESG member (as with Mirja’s on system ports).

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Apr 2020 14:47:18 -0400

Are you claiming he is lying about his hat being off?
     That would seem to be a claim requiring evidence.

Or are you asking that we change the long standing practice of allowing 
our leadership to also participate as individuals in our work?

Are you saying that he should inform us of what the other IESG members 
said to him in informal conversation?  (I sure hope not, but that seems 
to be what you are asking regarding why this isn't coming from the IESG.)

Or are you asserting or requesting something else that I am unable to 
understand from your emails?

Yours,
Joel

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2020 15:11:24 -0400

> Until a document is adopted by a WG, this is inappropriate and incorrect. The assignee and point of contact
> should never be the IETF until a doc is adopted.

Are you saying that you think an individual submission that is being
sponsored by an AD in the IETF stream... is not a product of the IETF
because it didn't come from a working group?

If that's your contention, I strongly disagree.  Anything that goes
through the IETF stream is a product of the IETF and has boilerplate
in the resulting RFC that says so.  And those documents have IETF
consensus that comes from last call, which has almost always been the
case for many years, and is now guaranteed by
draft-halpern-gendispatch-consensusinformational (approved and in the
RFC Editor queue).

Documents in the Independent stream are, of course, different, and
this document doesn't apply to them.

Barry

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 12:42:43 -0700

> On Apr 10, 2020, at 12:11 PM, Barry Leiba <[email-masked]> wrote:
> 
> because it didn't come from a working group?’

No, but that’s not clear from the text.

I think it’d be fine for the text to just be more clear that this is “individual submission sponsored by an AD”.

> this document doesn't apply to them.

Understood; it’s just that the current text is vague and easy to misapply out of context.

Joe

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 12:47:35 -0700

> On Apr 10, 2020, at 11:47 AM, Joel M. Halpern <[email-masked]> wrote:
> 

No; I’m claiming that I do not recognize his hat as being removed when he speaks about IETF process.

If this were something that wouldn’t have come from the IESG, yes. But this (and the other doc, FWIW), seem like end-runs around the fact that an IESG member is speaking based on privileged IESG discussions.

> Or are you asking that we change the long standing practice of allowing our leadership to also participate as individuals in our work?

They can, but **not as individuals in matters for which they are appointed**.

> Are you saying that he should inform us of what the other IESG members said to him in informal conversation?  (I sure hope not, but that seems to be what you are asking regarding why this isn't coming from the IESG.)

No.

> Or are you asserting or requesting something else that I am unable to understand from your emails?

I think you have the idea; my point is that a “hat” is not removable by a Nomcom-appointee simply by declaration - notably in matters related to their appointment. 

They can wait until they step down or have another role. Until then, I consider them inextricably entangled with their appointment and believe others should too.

Joe

---

From: S Moonesamy <[email-masked]>
Date: Fri, 10 Apr 2020 12:55:52 -0700

Hi Joe, Joel,
At 11:47 AM 10-04-2020, Joel M. Halpern wrote:
>Or are you asking that we change the long standing practice of 
>allowing our leadership to also participate as individuals in our work?
>
>Are you saying that he should inform us of what the other IESG 
>members said to him in informal conversation?  (I sure hope not, but 
>that seems to be what you are asking regarding why this isn't coming 
>from the IESG.)
>

I read Joe's message as meaning that he views the draft posted by 
Barry as being from an IESG member.  The reason given is that a 
person cannot stop being a member of the IESG especially if the 
matter which the person is writing about is based on internal 
discussions of the IESG.

I don't see why either of you should not be allowed to express an 
opinion on this mailing list without it being turned into a 
discussion about "lying".

Regards,
S. Moonesamy

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2020 15:59:43 -0400

Ack; will fix, Joe, and thanks for letting me know that it's not clear.

Barry

---

From: "Joel M. Halpern" <[email-masked]>
Date: Fri, 10 Apr 2020 16:06:12 -0400

We have a long tradition of people in positions of leadership also 
participating as individuals.  Just because Joe thinks it doesn't work 
does not mean it is not true.  It has weaknesses.  We all know that.

Yours,
Joel

On 4/10/2020 3:55 PM, S Moonesamy wrote:
>> said to him in informal conversation?  (I sure hope not, but that 
>> seems to be what you are asking regarding why this isn't coming from 
>> the IESG.)
>>
> I read Joe's message as meaning that he views the draft posted by Barry 
> as being from an IESG member.  The reason given is that a person cannot 
> stop being a member of the IESG especially if the matter which the 
> person is writing about is based on internal discussions of the IESG.
> 
> opinion on this mailing list without it being turned into a discussion 
> about "lying".
> 
> Regards,
> S. Moonesamy

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 11 Apr 2020 08:10:57 +1200

> I think it’d be fine for the text to just be more clear that this is “individual submission sponsored by an AD”.

I think the document should open with a clear scope statement like:

This document applies only to RFCs approved in the IETF Stream [RFC7841].

And perhaps:

OLD:
IANA is asked to check compliance with this and to ask the
responsible AD in cases where this practice is not followed.

NEW:
IANA is asked to check compliance with this when reviewing IETF Stream
drafts and to query the responsible AD in cases where this practice is
not followed.

Stay well,
   Brian

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 10 Apr 2020 13:12:07 -0700

> does not mean it is not true.  It has weaknesses.  We all know that.

I think I am reading Joe's message differently than you are.  (Either, or
both, of us could be wrong, of course.)

What I am hearing is that if Barry had instead said that he was authoring
this draft on behalf of the IESG, and maybe that it had some "IESG as
author" boilerplate akin to the "IAB as author" boilerplat that some
documents have, then he would be okay with the document going out for
community review, last call, etc.  But the claim that it is somehow "a
document by just Barry as an individual" is what's problematic, with Joe
telling us that it's impossible to separate Barry-as-author from
IESG-as-author in this case.

We can debate whether or not we believe that to be true, but hopefully we
can agree on what Joe is trying to say, at least.

-Ben

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Apr 2020 16:31:22 -0400

I have Brian's changes queued up, as well as this one:

OLD
When a document coming from an individual submitter makes an IANA
request that specifies registrant information

NEW
When an AD-sponsored individual submission in the IETF stream makes an
IANA request that specifies registrant information

Barry

---

From: S Moonesamy <[email-masked]>
Date: Fri, 10 Apr 2020 14:13:08 -0700

Hi Joel,
At 01:06 PM 10-04-2020, Joel M. Halpern wrote:
>participating as individuals.  Just because Joe thinks it doesn't 
>work does not mean it is not true.  It has weaknesses.  We all know that.

I noticed that the tradition is formulated as a principle laid down 
by an authority in other venues.  I don't know whether the persons 
doing that are aware of the weaknesses.

Regards,
S. Moonesamy

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2020 22:37:13 +0100

Hiya,

On 10/04/2020 22:13, S Moonesamy wrote:
> I noticed that the tradition is formulated as a principle laid down by
> an authority in other venues.  I don't know whether the persons doing
> that are aware of the weaknesses.

FWIW, I wouldn't get too hung up on this point. A lot of
the time ADs (or recent ex-ADs) are the ones writing
drafts like these because nobody else cares really - it's
just that ADs see these issues crop up over and over and
tend to want to fix 'em;-)

S.

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 14:42:48 -0700

> On Apr 10, 2020, at 2:37 PM, Stephen Farrell <[email-masked]> wrote:
> 

Issues of note to the IESG should be offered by the IESG as a whole.

FWIW, it’s also possible that this little echo-chamber sees what it things are huge problems that the rest of us don’t need to burn cycles trying to fix, too.

Joe

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 10 Apr 2020 22:51:17 +0100

Hiya,

On 10/04/2020 22:42, Joseph Touch wrote:
>>> Hi Joel, At 01:06 PM 10-04-2020, Joel M. Halpern wrote:
>>>> We have a long tradition of people in positions of leadership
>>>> also participating as individuals.  Just because Joe thinks it
>>>> doesn't work does not mean it is not true.  It has weaknesses.
>>>> We all know that.
>>> 
>>> I noticed that the tradition is formulated as a principle laid
>>> down by an authority in other venues.  I don't know whether the
>>> persons doing that are aware of the weaknesses.
>> 
>> FWIW, I wouldn't get too hung up on this point. A lot of the time
>> ADs (or recent ex-ADs) are the ones writing drafts like these
>> because nobody else cares really - it's just that ADs see these
>> issues crop up over and over and tend to want to fix 'em;-)
>> 
>> S.
> 

I kind of agree with one of your points below:-)

> Issues of note to the IESG should be offered by the IESG as a whole.

It wasn't the one above. I don't know what you even mean.
Asking that the IESG reach consensus on everything they
do before they run something by the community seems to me
like a pretty bad plan.

> 
> FWIW, itâ€™s also possible that this little echo-chamber sees what it
> things are huge problems that the rest of us donâ€™t need to burn
> cycles trying to fix, too.

That's a fair point yes. (Well, the "echo-chamber" part is
egregious, but otherwise it's fair.) That doesn't mean that
the proposals are always wrong though. (In this case, I
don't really care enough about the specifics so would be
neither for nor against the draft itself.)

Cheers,
S.

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 15:11:22 -0700

FWIW...

> On Apr 10, 2020, at 2:51 PM, Stephen Farrell <[email-masked]> wrote:
> 
> ...

Why couldn’t that be said of every doc in any WG then?

What we’d have are people flinging docs to the IETF list and spinning up the whole community before the pockets of interest and expertise weighed in. That’s inefficient and why we try to home things in a WG and work *up* the hierarchy, not down.

In this case, yes - I think the IESG should have reached a rough consensus on this first. Again, we’re not talking about an arbitrary issue; we’re talking about an IETF-wide process change, which is absolutely the purview of the IESG anyway.

Joe

---

From: John C Klensin <[email-masked]>
Date: Fri, 10 Apr 2020 20:56:56 -0400

Joel, Joe,

Personally, I don't see a way to separate this draft, and at
least my interpretation of Joe's comments, from a broader
situation.

The last few months have seen two situations in which the IESG
has claimed extraordinary authority, developed a proposal
internally, and then presented it to the community.  Both -- the
decision to take IETF 107 virtual and the ongoing discussions
about NomCom eligibility -- were necessitated by very unusual
situations and tight deadlines.  Whether I agree with the
outcomes or not, I think they did what was necessary and, for
the Nomcom case, which was less of an emergency than whether to
hold IETF 107 f2f, I think the community should feel better
about things in general because the IESG (and Barry
specifically) listened to input from the community and shifted
from a "do this by IESG Statement" plan to one of using a more
or less normal process for a BCP.

I think the last few years have also seen an increase in
technical specifications that are developed by one IESG member
(with a "no hat" or "as an individual" declaration), sponsored
by a second, and approved by the IESG after very little comment
during Last Call (possibly because no one else really cared).
In an even smaller number of cases, the only parties who may
care about the spec are the companies supporting the IETF work
or one of more ADs.  All perfectly legitimate under our current
rules.  And, especially for procedural matters for which (as
Stephen points out) current and recent ADs may be the only ones
who have been exposed closely enough to the problems to care.

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.

Those of us who have been through multiple rounds of "circuit vs
packet" wars, OSI wars, and variations of them, know that, many
times, when the technical proposals and arguments fail, what
follows are institutional attacks.  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.   Maybe we should be thinking
about short-term WGs whose purpose is to smooth the rough edges
off documents (like the changes that Barry has already queued)
and to present the community with clear pro and con arguments
before we start trying to debug on the IETF list (which, sadly,
many of those in the community who might be affected don't
follow).  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.

best,
  john

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Apr 2020 22:57:18 -0500

> >    ("IETF") to be used, and allows for exceptions with IESG approval.

|   When a document coming from an individual submitter makes an IANA
|   request that specifies registrant information, "IETF" is to be used,
|   as these registrations also come from the IETF as a whole via IETF
|   last call consensus.  If contact information is specified and there
|   are relevant mailing lists as outlined above, one of those lists
|   would normally be used, with the assent of the working group chairs
|   or list owners.  If there is no relevant working group, a relevant
|   directorate or area-wide mailing list is the next choice, with the
|   assent of the Area Directors.  In cases where neither of those
|   options applies, the document authors or the IESG itself can be used
|   as contact information.

Not all IANA registries require RFC publication to trigger registration.
The above seems to imply otherwise.  FCS, Expert Review type registries
don't need an RFC or I-D, though you can have an I-D, and you can never
progress it to publication as an RFC, and still get your registration.

The idea that all registrations come from the IETF strikes me as very,
very wrong.  IANA doesn't only serve the IETF.  And not all registrants
speak for the IETF -- often not even remotely.

If anything your I-D seems to impliedly raise the bar on many
registries, and by the back door.  If that's not the intent then at the
very least you need to clarify that.

> individual submission by me and does not come from the IESG.

OK, what were these IESG discussions about?  What prompted them?  What
is the problem that you're trying to solve?  The abstract certainly
doesn't say.  The intro doesn't say either.

Inconsistency isn't necessarily a problem.  To see inconsistency as a
problem we should see some examples where the inconsistency does cause
knock-on problems.

That famous Ralph Waldo Emerson quote comes to mind.  Why is the IESG
adoring consistency here?

|3.  IANA Considerations
|
|   IANA is asked to check compliance with this and to ask the
|   responsible AD in cases where this practice is not followed.

Asking for a WG list or directorate list as a something of a fallback
contact point seems reasonable.  Asking for that as the only contact
seems wrong when the registrant isn't really the IETF.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Fri, 10 Apr 2020 23:09:21 -0500

> 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
> clear if the IESG later adopts it.   [...]
>   [...].  That goes beyond specific types of proposals: for

Trust, but not really.

Nico
--

---

From: Joseph Touch <[email-masked]>
Date: Fri, 10 Apr 2020 21:09:38 -0700

> On Apr 10, 2020, at 5:56 PM, John C Klensin <[email-masked]> wrote:
> 
> Joel, Joe,
> 
> internally, and then presented it to the community.

Agreed. My own concern is when some members have claimed extraordinary insight, developed a proposal, then either failed to propose it from their office (in this case) or tried to push it through IETF last call before even considering a first call to the AD’s own area WG (where the doc very clearly should have been homed anyway),

Most reputable conferences are wise enough to prohibit their own chairs from submitting. Even when there are co-chairs who could arguably handle the case, the *perception* of a potential abuse of authority is usually enough to get most reasonable chairs to comply.

Not so here in the IETF. Somehow, the idea persists that the mere removal of a virtual “hat” of such office is sufficient to absolve the appointee of their office, regardless of the relation of the “individual” contribution to that office.

> … I think the community should feel better

That’s like feeling better that the conference chair submitted a paper with their student as first author.

If the idea behind the RFC isn’t controversial, then going outside the expected process isn’t “normal”. It’s an end-run.

...
> don't trust our leadership,

We shouldn’t HAVE to. COI and other such policies exist to remove that need.

Joe

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Apr 2020 00:37:38 -0400

Nico, thank you for focusing on the draft content.  I will look again in 
the light of the issues you raise.

Yours,
Joel

---

From: Keith Moore <[email-masked]>
Date: Sat, 11 Apr 2020 00:52:24 -0400

> speak for the IETF -- often not even remotely.

I also have this concern.   There are some individual submissions for 
non-IETF consensus specifications (sometimes vendor specifications) that 
have IANA registries, and at least on some occasions this situation is 
desirable.    If the document is an IETF consensus document, then IETF 
is probably the right choice, but I can imagine scenarios in which it's not.

(I really wish, in hindsight, for instance, that we had delegated URN 
namespace assignment to another organization with more core competence 
in this area.  IETF, IMO, has really botched it.   But that's just one 
example.)

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Apr 2020 00:16:14 -0500

On Sat, Apr 11, 2020 at 12:52:24AM -0400, Keith Moore wrote:
> desirable.    If the document is an IETF consensus document, then IETF is
> probably the right choice, but I can imagine scenarios in which it's not.

The absolutely minimal change to Barry's I-D needed is to not impose
this "IETF is the registrant" requirement when IETF consensus is not
required by the registry, and, if the registration request comes from an
I-D, it's not one requiring IETF consensus (e.g., it targets publication
as Experimental or Informational via the ISE).

That and the addition of a stronger justification.

Nico
--

---

From: Barry Leiba <[email-masked]>
Date: Sat, 11 Apr 2020 01:30:08 -0400

I think the draft is clear that it applies to registrations that come from
the IETF.  It doesn’t say anything about others, and would not want to.  Do
you have specific suggestions for text that would clarify that further?

Some of the problems include a lot of contact information for individuals
who are no longer reachable and/or no longer have any connection to the
registrations they are contacts for, along with the idea that the IETF, not
an arbitrary individual, should be the change controller for items
registered by the IETF.

Barry

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Apr 2020 00:39:39 -0500

> you have specific suggestions for text that would clarify that further?

It was not clear to me.  I'll post suggested changes tomorrow.

> an arbitrary individual, should be the change controller for items

In these cases there's an RFC, and the RFC has datatracker history,
which means anyone who wants to know who to contact can find the WG (if
any) and mailing list there.  If there's no WG, well, presumably one
would think to ask IANA or a directorate.

Even WG mailing lists die.  Once a WG has been concluded for many years,
the mailing list for it may well no longer serve to contact anyone
involved in the WG.

What might be worth doing is asking IANA to list in all registrations
the registrant's contact information, the WG's if there was one, and the
applicable directorate either way.

Nico
--

---

From: "Joel M. Halpern" <[email-masked]>
Date: Sat, 11 Apr 2020 13:33:29 -0400

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

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Apr 2020 13:50:10 -0500

On Sat, Apr 11, 2020 at 01:33:29PM -0400, Joel M. Halpern wrote:
> 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.

Perhaps I mistook "IETF documents" for "RFCs".  A simple fix to that is
to clarify "IETF documents".

OLD:
Abstract

NEW:
Abstract

   IETF documents have been inconsistent in what they specify as the
   registrant (or contact, or change controller) in IANA registrations
   they make.  This document provides a consistent specification
   ("IETF") to be used as the registrant when the registration arises
   from publication of a Request For Comment (RFC) that has received
   IETF Review.  Exceptions are allowed with IESG approval.

When/why would the IESG approve exceptions, and who might ask for them?
Is an exception mechanism just a safety switch in case of unforeseen
circumstances?

> 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.

Note that you can do both, publish an I-D targeting publication on the
Standards Tack, and within it direct IANA to make registrations in
Expert Review of FCFS registries.  Because the authors could have
requested registration independently (and possibly did), what is the
best registrant in that case?  The registration might have been accepted
and effected before publication -- should it be updated upon
publication?

Note too that by the time an RFC is published, the original registrants
of any related FCFS registrations might no longer be authors.  Losing
this information from the IANA registration record would be bad.  One
way to prevent this would be to _add_ "IETF" as a registrant rather than
have it be the only registrant.

Perhaps the IESG exception is about this?

> 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".

Another inconsistency.  But again, the registration record should record
all relevant information.  Whether we supplant "IETF" for the authors of
the RFC makes little actual difference to me.

> 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.

For a registration that has been made, the contact information of future
use can be all of: the registrants', the Expert Reviewers' (if
applicable), the WG list (if applicable), a directorate (if applicable).

The first of those (the registrant's) is redundantly available as the
RFCs' authors in the case of a registration arising from RFC
publication, so replacing it with "IETF" makes some sense, but it
neither adds nor subtracts information.  The IANA already links to
relevant documents (such as RFCs) in registrations.

The fact that this proposal neither adds nor removes information makes
me thinkg it's at best just a matter of style.  Couldn't the IANA
implement this change entirely of their own volition?  Why hasn't it?

Couldn't the IESG simply request that editors apply this change to all
RFCs it reviews?  Does the IESG require IETF approval to do that?
(Ironic, I know, because doing something like that might be perceived as
a power grab, but to me this is purely a matter style.)

Nico
--

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Apr 2020 10:06:26 +1200

Nico,

On one point only:

On 12-Apr-20 06:50, Nico Williams wrote:
...
> implement this change entirely of their own volition?  Why hasn't it?

IANA operates RFC-based registries under the rules of RFC2860 clause 4.1,
which seems worth quoting here:

>    4.1. The IANA will assign and register Internet protocol parameters
>    only as directed by the criteria and procedures specified in RFCs,
>    including Proposed, Draft and full Internet Standards and Best
>    Current Practice documents, and any other RFC that calls for IANA
>    assignment. If they are not so specified, or in case of ambiguity,
>    IANA will continue to assign and register Internet protocol
>    parameters that have traditionally been registered by IANA, following
>    past and current practice for such assignments, unless otherwise
>    directed by the IESG.
> 
>    If in doubt or in case of a technical dispute, IANA will seek and
>    follow technical guidance exclusively from the IESG. Where
>    appropriate the IESG will appoint an expert to advise IANA.
> 
>    The IANA will work with the IETF to develop any missing criteria and
>    procedures over time, which the IANA will adopt when so instructed by
>    the IESG.

We seem to be in the first line of the last paragraph, and therefore
IMHO Barry was correct to bring the discussion here. I hope that
IANA is watching this discussion and will contribute.

Stay well,
    Brian

---

From: Nico Williams <[email-masked]>
Date: Sat, 11 Apr 2020 17:58:34 -0500

> IANA is watching this discussion and will contribute.

No one will deny that the IESG can do what the above quote says.  If
there's a question of "missing criteria" then do we even need Barry's
I-D to resolve it, or can the IESG simply direct IANA as to how to
resolve the issue?

I do question the utility of the change, I proposed a clarification, and
I would like to see the justification enhanced (e.g., can we have some
examples of inconsistency?).  I don't oppose the proposed change as
such.

Nico
--

---

From: Larry Masinter <[email-masked]>
Date: Sat, 11 Apr 2020 16:29:18 -0700

I'm not sure the suggested process would work for problematic cases, e.g.
those where there's an intermediate state for registrations pending.
It seems like in all of these cases the relationship of events and roles of
IANA, document shepherd, IESG, RFC editor, author, AD, WG chair isn't
simple, and needs some flexibility and judgement

1 https://tools.ietf.org/html/draft-nottingham-thanks-larry-00 The 418
error code in a registry (from April 1 RFC2324) 
    (but no  coffee: in scheme registry)
Some RFCs not dated April 1 can have the same issues.

2 The change in ownership of application/pdf (RFC 8118)  was it necessary?
How else can the owner organization change?

3  The change in registration of text/html from RFC 2854 without obsoleting
RFC
In this case, how to populate other bits of metadata were of some concern

4  The 'duri' and 'tdb' URI schemes
(https://tools.ietf.org/html/draft-masinter-dated-uri-10) 
   can a registration from an I-D be accepted if there's no intention to
produce an RFC ever?
 
5
https://mailarchive.ietf.org/arch/msg/uri-review/Imkhlr8KwsdRmiWeWopEGPa_UDc
/  
     Can a registration be based on an archived email containing the
specification?

--
https://LarryMasinter.net
https://Going-Remote.info

---

From: Barry Leiba <[email-masked]>
Date: Sat, 11 Apr 2020 19:41:47 -0400

Hi, Larry, and thanks for the comments.

(1) This document only deals with registrations coming from IETF documents
— working group products and AD-sponsored individual submissions — and it
says that (I guess not clearly enough, and Nico is going to suggest text to
improve it).  These are being published as RFCs in the IETF stream.

Registrations done by other means are not subject to this at all.  That
includes any FCFS registrations or Expert Review registrations or
Specification Required registrations that are not in IETF RFCs.  Not
covered here.  Also not covered here are registrations coming from RFCs in
the Independent stream (which includes April 1st RFCs).

(2) This does not cover how to change ownership.  It’s only specifying what
to do for new registrations.  We hope that by setting change control for
IETF registrations with the IETF, it will be less often necessary to change
it.

(3) The document acknowledges that there will be reasons to do other than
what is specified here, and provides for ADs to allow differences when it
makes sense to do so.

I think that covers all your examples.  If you think any of this is unclear
in the document, I’d appreciate suggested text to improve it.

Barry

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 12 Apr 2020 18:19:56 +1000

Just wondering (especially after reading comments) - would GENDISPATCH have been a more appropriate place to send this?

Cheers,

> On 11 Apr 2020, at 3:53 am, Barry Leiba <[email-masked]> wrote:
> 

--
Mark Nottingham   https://www.mnot.net/

---

From: Carsten Bormann <[email-masked]>
Date: Sun, 12 Apr 2020 10:27:54 +0200

> Just wondering (especially after reading comments) - would GENDISPATCH have been a more appropriate place to send this?

+1.

Grüße, Carsten

---

From: John C Klensin <[email-masked]>
Date: Sun, 12 Apr 2020 14:37:29 -0400

Barry,

Deliberately not replying to any one specific message...

First, it seems to me that trying to rationalize the situation
with registrants, change controllers, etc., is a good idea.  At
the same time, given that we have managed to muddle along with
problems of not having clarity about responsible parties,
changing contact information, and so on for 40-odd years, it is
not clear to me why the problems are urgent enough to justify
taking up IETF time and apparently putting it on a fast track
right now.  I note, for example, the immediate and future NomCom
eligibility efforts as being far more important.  Those
considerations lead me to some sympathy with those who are
suggesting this should have gone to GENDISPATCH (too late now,
but maybe something from which we can learn for whatever the
"next time" turns out to be) and with procedural concerns.
Ordinary individual submissions usually remain in "I-D Exists"
state even after there has been discussion on the IETF list and
the IESG (or a relevant AD) has decided to push the discussion
off to another list.  For them, the information changes to
identify a sponsoring AD only when the document is close to Last
Call.  I noticed today that this one is already in "AD is
watching" state, with a sponsoring AD assigned, in the
datatracker.  Not a serious problem, IMO, but something that
further confuses the question of whether this is your individual
effort or one you are moving forward on behalf of some or all of
the IESG.

Putting that aside and looking at the substance of the document
(including the various changes that you have queued), I'm still
not sure I fully understand what problem you are trying to
solve.  As an example, consider one of your examples:

   IETF <[email-masked]>

Now, clearly, that puts the IETF's mark on things but so, to
some degree, does "ietf.org" in the address.  As far as I know,
while the recommendation has gotten ever-stronger over the
years, we still don't require WGs to use mailing lists based at
ietf.org and, at least equally important, we sometimes
consolidate mailing lists associated with concluded WGs.  If one
is worried about stable contact information, we could take two
examples from our distant past.   Had either produced IANA
registries, one would not want to list the mailing list for YAM
as the best contact point (in spite of that list still
receiving, archiving, and distributing mail), nor would it be
wise to list 822ext as either
   IETF <[email-masked]>
or 
   IETF ietf.cnri.reston.va.us:~/ietf-mail-archive/822ext/

I understand that you are talking only about new registries
going forward, but the reality is that these things do change.
I note particularly the suggestion about use of a "directorate
or area-wide mailing list" in combination with our tendency to
periodically consolidate or drop areas and invent new names in
the process.  Expanding the number of things that we need to
keep stable for as long as IANA registries exist (and the IETF
does) is probably not a good idea for just those reasons.  The
document actually makes that point in requiring that contact
information not be published in RFCs [1].

Assuming the goal of this document is to clarify what is going
on rather than  simply to create consistency for its own sake
and/or to create more procedural hoops for WGs, document
authors, and shepherds to jump through for anything this draft
considers unusual -- thereby creating more delays in document
evaluation and processing -- let me suggest a simpler and less
ambiguous strategy going forward:

(i) For "registrant" or "contact" no change and no need to
mention either in this document other than to specify that
"IESG" (which is inherently transient except insofar as the
changing membership makes decisions reflecting IETF consensus or
on behalf of the IETF) MUST NOT appear.  Even that may be a
problem that does not need solving at the BCP level.

(ii) For registries and registrations that really are the
responsibility of the IETF for either additions or changes,
require that the Change Controller field appear and that it be
listed as "IETF".  Not "IETF" and some mailing list, but "IETF".
WGs are by definition transient so, while they might be
registrants and perhaps even (for a while) contacts, they should
never be listed as change controllers.   Using the Applications
Area and the Real Time one as very handy examples, Areas are
transient too and the same considerations apply. 

(iii) If a WG document that specifies a registry or registration
specifies, e.g., a WG Chair as registrant, it is entirely
appropriate for that to be questioned by the WG, during IETF
Last Call, or by the document shepherd or IESG review, but it
does not seem to me we need a BCP-level document to say that.

I don't think anything else is going to reduce confusion or
improve contact information more than that suggestion would.  It
appears to me that what the proposal in the I-D would likely do
is to increase the workload on both IANA and the IESG (or
designees of the latter) every time we reorganize Areas, close a
WG and/or decide that concluded WG mailing lists should be
consolidated or moved to another location, and increase the
pressure on IANA to do outreach to keep addresses up-to-date
that they now correct only on an as-needed basis when things are
brought to their attention.

That requirement for a "Change controller" entry in registries
or registrations created under IEZTF respoonsibility probably
would benefit from an update to BCP 26/ RFC 8126, but I see no
reason why that would be problematic.

thanks,
   john

[1] Section 2, paragraph 3 starting with "In any case...".
And, btw, that statement sounds a lot like a RFC 2119-style MUST
NOT unless you intend that the IESG be able to make exceptions
to that too, in which case a SHOULD NOT might be appropriate.
We also put "mutable email addresses into immutable RFCs" all
the time: email addresses are the only contact information other
than personal names that we still require in I-Ds and RFCs.

---

From: Barry Leiba <[email-masked]>
Date: Sun, 12 Apr 2020 16:07:14 -0400

Hi, John, and thanks for the thoughtful note.  You're certainly right
that things such as NomCom eligibility are far more important than
stuff such as this.

Just on one small point, for now:

> I noticed today that this one is already in "AD is

Just put that down to a new and eager co-AD, and read nothing further
into it.  :-)

Barry

---

From: John C Klensin <[email-masked]>
Date: Sun, 12 Apr 2020 16:18:50 -0400

--On Sunday, April 12, 2020 16:07 -0400 Barry Leiba
<[email-masked]> wrote:

> Hi, John, and thanks for the thoughtful note.  You're
> certainly right that things such as NomCom eligibility are far
> more important than stuff such as this.
> 
>> further confuses the question of whether this is your
>> individual effort or one you are moving forward on behalf of
>> some or all of the IESG.
> 
> Just put that down to a new and eager co-AD, and read nothing
> further into it.  :-)

Barry,
   More than happy to do that.  I noticed it only because of the
earlier subthread about whether this was your individual
document or an IESG proposal.

Murray,
  Few of us managed to get through our first month as ADs
without some small gaffe that turns out to be educational.
Congratulations on yours being this minor.

best,
  john

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 12 Apr 2020 18:04:50 -0500

> Congratulations on yours being this minor.

For the new ADs, the classic boner in recent years has been accidentally
sending a draft out for IETF Last Call for a second time because *I* was
thinking of another draft from the same working group that I had just
finished AD Evaluation for.

No need to repeat my mistakes, when you can make new and exciting mistakes
of your own!

Best,

Spencer

---

From: Michelle Cotton <[email-masked]>
Date: Mon, 13 Apr 2020 14:56:30 +0000

Hi Brian, all, 

We are watching...  I was involved in some of the conversations that led to this draft.  
There is inconsistency when IETF stream documents list change controllers for registrations and that is what we are trying to fix.

I have to get through all the mail for looking at other points being discussed.

--Michelle

Michelle Cotton
IANA Services

On 4/11/20, 3:06 PM, "ietf on behalf of Brian E Carpenter" <[email-masked] on behalf of [email-masked]> wrote:

    Nico,
    
    On one point only:
    
    ....

    
    
    Stay well,
        Brian

---

From: John C Klensin <[email-masked]>
Date: Mon, 13 Apr 2020 12:26:01 -0400

--On Monday, April 13, 2020 14:56 +0000 Michelle Cotton
<[email-masked]> wrote:

> Hi Brian, all, 
> 
> We are watching...  I was involved in some of the
> conversations that led to this draft.   There is inconsistency
> when IETF stream documents list change controllers for
> registrations and that is what we are trying to fix.

Then, if the problem is the listing of change controllers,
shouldn't we be fixing that problem rather than taking an
excursion into other types of contact and registration
information?

> I have to get through all the mail for looking at other points

As you do, I look forward to your comments on the note I posted
yesterday at 14:37 -0400.  Part of it focuses specifically on
the change controller issue and suggests one way to approach it
(and it only).

stay safe and well,
   john

---

From: Nico Williams <[email-masked]>
Date: Mon, 13 Apr 2020 11:31:05 -0500

> > registrations and that is what we are trying to fix.

Thanks for explaining.

+1.