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
On Fri, Apr 10, 2020 at 11:57 PM Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote:
On Fri, Apr 10, 2020 at 01:53:12PM -0400, Barry Leiba wrote:
> 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.
| 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.
> While this does come from IESG discussions, the document is an
> 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
--
