Subject: Request for comments : IANA Policy for the Independent Stream

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 04:42:59 -0700

Hello IETF Community,

Several people have recently asked me what the policy is for creating or
modifying IANA registries using documents in the Independent Submissions
Stream, and from time to time a document in the stream requests allocation
of a code point from an existing registry.

This document is an attempt to describe how I will act (as Independent
Submissions Editor) when I am asked to publish such documents.

I would very much appreciate comments and thoughts.

Best,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

-----Original Message-----
From: I-D-Announce <[email-masked]> On Behalf Of
[email-masked]
Sent: 13 August 2019 12:24
To: [email-masked]
Subject: I-D Action: draft-ise-iana-policy-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

Title       : How Requests for IANA Action Will be Handled on
              the Independent Stream
Author      : Adrian Farrel
Filename    : draft-ise-iana-policy-00.txt
Pages       : 5
Date        : 2019-08-13

Abstract:
   The Internet Assigned Numbers Authority (IANA) maintains registries
   to track codepoints used by protocols defined by the IETF and
   documented in RFCs developed on the IETF Stream.

   The Independent Submissions Stream is another source of documents
   that can be published as RFCs.  This stream is under the care of the
   Independent Submissions Editor (ISE).

   This document updates RFC 4846 by describing how the current ISE will
   handle documents in the Independent Submissions Stream that request
   actions from the IANA.  Nothing in this document changes existing
   IANA registries and their allocation policies.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ise-iana-policy/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ise-iana-policy-00
https://datatracker.ietf.org/doc/html/draft-ise-iana-policy-00

---

From: Job Snijders <[email-masked]>
Date: Tue, 13 Aug 2019 13:50:36 +0200

Beste Arien,

Helder, we gaan overleggen en puzzelen of we hier ruimte voor kunnen
maken.

Zou je je slides met ons willen delen?

Met vriendelijke groeten,

Job

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 13 Aug 2019 08:37:53 -0400

Adrian,

The document certainly looks reasonable. Should you add a section
discussing how it changes RFC 4846, so people don't have to refer back and
compare?

Also, the last paragraph on page 1 is missing the word "and" following
"[RFC4846]".

Cheers,
Andy

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 06:04:23 -0700

Thanks Andy,

> discussing how it changes RFC 4846, so people don't have to refer back >
and compare?

Not sure a section is warranted, but the text in the Abstract and
Introduction will change to say...

This document updates [RFC4846] by adding a description of how the current
ISE will handle documents in the Independent Stream that request actions
from the IANA.

Cheers,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 13 Aug 2019 09:19:32 -0400

Adrian,

Sounds good. Also, you seem to setting a policy just for yourself rather
than the ISE role going forward by the use of the word "current". Is there
any reason why? If you removed the word "current", and a future ISE wants
to change the policy, they could certainly write another RFC, but this
policy seems to terminate at the conclusion of your holding the role, which
would require the next ISE to reissue or amend the policy. My suggestion
would be to remove the word "current", so that future ISEs can take
advantage of this policy without having to reissue the RFC.

Cheers,
Andy

---

From: Samuel Weiler <[email-masked]>
Date: Tue, 13 Aug 2019 09:22:40 -0400 (EDT)

As someone who has published a doc through the Independent Steam which 
requested a codepoint in a Specification Required registry, this doc 
looks quite reasonable.

-- Sam

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Aug 2019 11:39:35 -0400

> I would very much appreciate comments and thoughts.

Thank you very much for writing this. I do have a question...

"RFC8126 - IANA Considerations Section in RFCs"
(https://tools.ietf.org/html/rfc8126) lists "IESG Approval" as one of
the possibilities for a registry.
Snippet:
"New assignments may be approved by the IESG.  Although there is no
requirement that the request be documented in an RFC, the IESG has the
discretion to request documents or other supporting materials on a
case-by-case basis.
IESG Approval is not intended to be used often or as a "common case";
indeed, it has seldom been used in practice." -- this then lists a few
cases, including RFC6275 and RFC5771.
RFC8126 goes on to say: "..., it is intended to be available in
conjunction with other policies as a fall-back mechanism in the case
where one of the other allowable approval mechanisms cannot be
employed in a timely fashion or for some other compelling reason."

Your draft specifically says that "a registry whose policy is "IETF
Review" or "Standards Action" [RFC8126] is not available to
Independent Stream documents.", but doesn't mention what happens with
"IESG Approval" registries. I would assume that these are also not
available to IS documents, but in my view it would be entirely
appropriate for the ISE to be able to *request* that the IESG approve
allocation. In my *personal* view, a request from the ISE for
allocation under the IESG Approval procedure should be given extra
weight.

Whatever the case, I think that the document should cover the other
cases as well.

I'd also like to echo Andy's suggestion that you remove 'current'
(unless there is a good reason that simply hasn't occurred to us :-))
W

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf

---

From: [email-masked]
Date: Tue, 13 Aug 2019 09:01:28 -0700 (PDT)

> available to IS documents,

That's not the case currently. One counterexample is standards tree media types
in independent stream documents. RFC 6828 section 3.1 on standards tree
registrations states:

   Registrations published in non-IETF RFC streams are also allowed and
   require IESG approval.  A registration can be either in a stand-alone
   "registration only" RFC or incorporated into a more general
   specification of some sort.

That said, I don't see anything in the document at hand that prevents
this.

> but in my view it would be entirely

> Whatever the case, I think that the document should cover the other

Seems reasonable.

				Ned

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Aug 2019 13:11:04 -0400

>    specification of some sort.

Yup, I fully agree that it doesn't need to be an IETF stream, but that
still says "require IESG approval" - this means that the ISE cannot
just approve assignment.
I guess I worded the above poorly -- it's not that "these are also not
available to IS documents", but rather that that the ISE would have to
work with the IESG / request that the IESG approve the registration
(the ISE cannot "guarantee" the assignment).
An interesting question for the IANA would be if they'd recognise
"IESG and / or ISE Approval" as type -- I cannot see why not...

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 10:17:12 -0700

Hi Warren and Ned on the same email response.

>> requirement that the request be documented in an RFC, the IESG has
>> the discretion to request documents or other supporting materials on
>> a case-by-case basis.
>> indeed, it has seldom been used in practice." -- this then lists a
>> few cases, including RFC6275 and RFC5771.
> That's not the case currently. One counterexample is standards tree
> media types in independent stream documents. RFC 6828 section 3.1 on
> standards tree registrations states:
>
>    Registrations published in non-IETF RFC streams are also allowed
>    and require IESG approval.  A registration can be either in a
>    stand-alone "registration only" RFC or incorporated into a more
>    general specification of some sort.
>

I am particularly enthusiastic to avoid two things:
1. Precedent influencing my policy. Mistakes of the past shall not
determine what we do tomorrow.
2. Imposing anything on IETF policies.

I believe that the text that Warren quotes is clear about the cases under
which "IESG Approval" may be used. Furthermore, I think that this document
is clear that "Documents proceeding from the Independent Stream will
always follow the assignment policies defined for the registries from
which they request allocations."

To me that says that IS documents *can* request code points from "IESG
Approval" registries, but (of course) such requests would be subject to
IESG review. You might like to think that IS documents would be given
extra weight in such considerations, but I could not comment. It would
certainly not be for me to write down how I think the IESG will behave!

I think section 2 lists all registry types that are not available (so the
others, including "IESG Approval," are, by default). I think section 3
lists the only allocation policies that could be used for new registries
(in the rare case that they are created) and "IESG Approval" is not listed
(because, of course, the ISE cannot tell the IESG what to do).

So, I'm not convinced anything extra needs to be written.

Cheers,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Warren Kumari <[email-masked]>
Date: Tue, 13 Aug 2019 14:34:49 -0400

> Hi Warren and Ned on the same email response.
[SNIP]
> So, I'm not convinced anything extra needs to be written.

Ok, fair 'nuff.
W

---

From: Benjamin Kaduk <[email-masked]>
Date: Tue, 13 Aug 2019 13:57:08 -0500

Hi Adrian,

> I would very much appreciate comments and thoughts.

Thanks for writing this up -- it seems pretty well thought-out (and
already got some good comments, too).

I do wonder, though -- isn't RFC 4846 from the IAB stream?  I'm not sure
whether the "Updates:" relationship is quite right, absent the standard IAB
review process being run.

-Ben

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 12:16:00 -0700

Hi Ben,

You're very right.

It all depends on whether draft-kuehlewind-update-tag makes progress in
time since the "update" in this case is very much "see also."

But if draft-kuehlewind-update-tag doesn't make enough progress, I agree
that this mention of "update" should be removed, and the text should read
"This document complements..."

Thanks,
Adrian

Benjamin Kaduk wrote:

> I do wonder, though -- isn't RFC 4846 from the IAB stream?  I'm not
> sure whether the "Updates:" relationship is quite right, absent the
> standard IAB review process being run.

-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Ted Hardie <[email-masked]>
Date: Tue, 13 Aug 2019 12:55:36 -0700

Hi Adrian,

It looks like section 4 has one or more examples in mind--can you give
example registries where this sort of allocation has been or might be
required via this stream?

thanks,

Ted

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 13 Aug 2019 16:09:06 -0400

Adrian,

You haven't yet addressed the point that Warren and I both made that you
should remove the word "current" from the draft.

Cheers,
Andy

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 13:24:31 -0700

Hi Ted,

> required via this stream?

Sure.

Random example...

Consider the "LMP Object Class name space and Class type (C-Type)"
registry at
https://www.iana.org/assignments/lmp-parameters/lmp-parameters.xhtml#lmp-parameters-4

New assignments of Class Names can be made by Standards Action (0-127) or
Expert Review (128-247).

Suppose an Independent Submission asks for a code point in the 128-247
range, and suppose that the DE thinks this is OK. A value is assigned, and
everyone is happy.

But you'll also notice on the registry page that each Class Name code
point has an associated sub-registry to track the Class Types for the
Class Name.

Thus, the new code point would also need a new sub-registry.

I must admit that I find this corner case (and, by the way, there are
plenty of examples of similar cases) to be a bit squirrelly. I would
prefer if it didn't need to happen, but I think there may turn out to be
cases where it does have to happen, and we have to describe it.

Now, it *could* be that these cases don't actually need the creation of a
new sub-registry. It could be that the code points for these cases could
be contained in the RFC and that would be that. However, this would, IMHO,
create a discrepancy in the registries that could cause confusion.

Does that help?

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Tue, 13 Aug 2019 13:31:38 -0700

Hi again, Andy.

> You haven't yet addressed the point that Warren and I both made that
> you should remove the word "current" from the draft.

Right.

I'm cogitating.

- I believe is is helpful to document what my procedures will be.

- I agree that it could be a burden/disruption for a future ISE to
  have to individually update this and any other similar RFCs to
  explain that they also apply (although, they might do that in a
  simple way).

- I agree that a future ISE could change any policy by writing a
  new RFC.

My concern is that I don't want to set policies for the Independent Stream
(and in this Ben is right that I don't want to formally update 4846).
Rather, I want to document how I am operating.

Thanks,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 13 Aug 2019 20:25:52 -0400

> I would very much appreciate comments and thoughts.

It seems entirely reasonable.
(So I had to read it again to be sure)

If a registry is created, or an entry is created in a registry, by an ISE,
can an IETF Standards Action document later change the rules on that
registry (or adopt that entry?)

Perhaps the correct question is, "How can an IETF stream document adopt an
ISE created entry"

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: "RFC ISE (Adrian Farrel)" <[email-masked]>
Date: Wed, 14 Aug 2019 01:48:05 -0700

Hi Michael,

> If a registry is created, or an entry is created in a registry, by
> an ISE, can an IETF Standards Action document later change the rules
> on that registry (or adopt that entry?)
>
> Perhaps the correct question is, "How can an IETF stream document
> adopt an ISE created entry"

I think I can write text describing how the ISE will behave: that is,
describing the publication process in the Independent Submission Stream.

I don't think I can write text (except aspirationally, and aiming for
wider consensus) that describes how other streams will behave.

The corner case you describe does nominally exist, but is second-order in
its rarity. 1. Very few IS documents create registries. 2. Very few IS
documents are obsoleted (or taken over) by IETF documents.

A short while ago I started a thread with the other stream managers about
"crossing the streams" for exactly the case where an IETF document seeks
to obsolete an IS document. Hopefully we'll have an opinion to share with
the community in the fullness of time - but it is not a worrying or
pressing problem, and we have always handled such cases gracefully in the
past.

Curiously, a case in point (which is in no way a problem) is in hand at
the moment as the new generation of Babel documents seek to replace the
previous Experimental IS documents.

Having Independent Stream work adopted into the IETF and developed there
with consensus is a Good Thing. Nothing we do should get in the way of
that.

So, I think you are right that I should write some warm words about
transferring registry "ownership" to the IETF.

I do not foresee ever transferring ownership out of the IETF.

Best,
Adrian
-- 
Adrian Farrel (ISE),
[email-masked]

---

From: Leif Johansson <[email-masked]>
Date: Thu, 22 Aug 2019 09:02:50 +0200

> requested a codepoint in a Specification Required registry, this doc

As someone who has setup an IANA registry via AD-sponsored ISE I agree
that it looks entirely reasonable.

	Cheers Leif