Subject: Re: [secdir] SECDIR review of draft-leiba-cotton-iana-5226bis-08

From: Barry Leiba <[email-masked]>
Date: Wed, 5 Nov 2014 11:35:25 -0500

Hi, Donald -- I'm sorry I didn't respond to this right away.

> However, it is not clear to me that there is adequate defense against
> denial of service attacks on IANA.
...
> think Section 3.3 should clearly provide that IANA can go to the IESG
> for anything that the IANA considers abuse of registration procedures.

That seems like a reasonable addition; I will do that.

> Given the completeness of this document in other regards, it seem odd
> that it does not mention that there can be and are IANA registries
> whose root is not the IETF but some other organization.

This is about IANA Considerations sections in IETF documents.  It's
meant to tell you what to put in IANA Considerations sections, not to
cover every nuance that might exist with registry creation.  I'd
prefer not to add those kinds of edge cases that rarely happen, and
that we get through on an individual basis when they do.

> In Section 2.3, we find
>    "In particular, when a registry policy that requires involvement of
>    Working Groups, directorates, or other bodies ..."
> but in the IETF, Working Groups are transient entities. Registry
> policy involvement of a WG not allowed and I have my doubts about
> allowing "directorates". Use of a mailing list is OK because mailing
> lists can be permanent.

That text was a recent addition.  Do you have a specific suggestion
for alternative text that gets the same point across?  The point is
that even after a working group writes a restrictive policy, that very
working group (still existing at the time) sometimes refuses to handle
a registration because they think it's not work doing a
standards-track RFC "just for this".  It's not that the policy
explicitly says that the WG has to do something... it's that because
of the policy and the fact that the WG is still around, the WG (or the
directorate or whatever) gets involved.

> And, at the very end of Section 2.3, it seems to imply that
> "Specification Required" implies "significant community involvement"
> which I think is wrong. My understanding is that there needs to be an
> expert to judge that the specification cited in the assignment request
> is adequate for interoperability.

That paragraph does not say what I meant it to say.  It's possible
that the parenthesized bit at the end is stray, but I'll have to go
back to the earlier versions and see where that came from.  It needs
fixing; thanks for pointing it out.

> Section 2.3.2: Talks about using multiple policies in a registry and
> seems to imply the main reason for this would be different sources of
> applications for assignment or just the general desirability in some
> cases of having alternative policies. Completely missing here is any
> reference to the many cases where disjoint ranges of code points are
> given different registration policies but that is given in Section 4
> where there is no mention of different sources of applications. Also
> note that for registries where the assignment of a block of values
> makes sense, such as MAC addresses under the IANA OUI, it makes sense
> to have different policies for assignment of small ranges or a single
> value and more stringent policies for assignment of large ranges. This
> stuff probably shouldn't be split between Sections 2.3.2 and 4.

I don't see why it shouldn't: they're two entirely different use
cases, and they're described separately because they are separate.

> Although Section 4.7 makes it clear that any type of RFC can cause
> assignments from a registry, I believe it is the case that any type of
> RFC can, if appropriate, create an IANA Registry and it doesn't say
> that in the draft unless I missed it...

There's nothing in the document that limits what RFCs the document
applies to.  Do you really think it's necessary to say that
explicitly?

The reason 4.7 says what it says is to specifically differentiate "RFC
Required" from "IETF Review" and "Standards Action", each of which
require different types of RFCs.

> Contrary to Section 9.1 of this draft, the draft does not have an IANA
> Considerations Section.

A fair point; I will add one.  :-)

> In Section 2.3.1, under item number 6, grouping is unclear. A reader
> might not know if "significant" is supposed to modify "documentation"
> or "expert review". I suggest changing the comma after "expert review"
> to a semicolon or deleting the comma after "significant".

I will change the comma after "expert review" to the word "with".

> Since I'm sometimes a bit stubborn,

Nahhhh...

> I will make one last point on
> which, as far as I can tell, no one agrees with me. My point is the
> error is the "order of strictness" list. Expert Review and
> Specification Required both involve an expert and both involve
> documentation. While it is true that Specification Required requires
> that the documentation be public, unless there are further provisions,
> the "expert" involved in Specification Required is restricted from
> making a judgment on anything but the completeness and lack of
> ambiguity of the document.

Yes, you and I have significant disagreement here.  Expert Review does
not necessary involve documentation (apart from the information
required for the registration request).  And Specification Required
can have the designated expert consider whatever it wants to have the
expert consider, according to the instructions given to the expert.

In my view, Expert Review has the expert review the registration
request, and Specification Required has the expert review the
registration request *and* the specification.

And this sort of disagreement is exactly why this document increases
the emphasis on instructions to the expert, so each use of these
policies makes it clear what they expect the expert to consider (and
what not to consider).

> I went to the www.iana.org/protocols page and was unable to find the
> Fruit Parameters Registry or the Fruit Access Flags... Maybe the IANA
> Considerations Section that should be in this draft shouldn't be empty
> but should create that Registry for documentation purposes...

He-he-he........

Thanks again for the thorough and thoughtful review.

Barry

---

From: Barry Leiba <[email-masked]>
Date: Wed, 5 Nov 2014 13:31:45 -0500

> That seems like a reasonable addition; I will do that.

Here's what I added to the end of the section:

NEW
   IANA always has the discretion to ask the IESG for advice or
   intervention when they feel it is needed, such as in cases where
   policies or procedures are unclear to them, where they encounter
   issues or questions they are unable to resolve, or where registration
   requests or patterns of requests appear to be unusual or abusive.

> for alternative text that gets the same point across?

I thought about it a bit more.  How about this?:

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

NEW
   In particular, working groups will sometimes write in policies such
   as Standards Action when they develop documents.  Later, someone
   will come to the working group (or to the relevant community, if the
   working group has since closed) with a simple request to register a
   new item, and will be met with a feeling that it's not worth doing a
   Standards-Track RFC for something so trivial.  In such cases, it was
   a mistake for the working group to have set the bar that high.

> fixing; thanks for pointing it out.

There was a missing word, but I re-worded the stuff in parentheses a
little more):

OLD
   Therefore, Working Groups and other document developers should use
   care in selecting appropriate registration policies when their
   documents create registries.  They should select the least strict
   policy that suits a registry's needs, and look for specific
   justification for policies that require significant community
   involvement (Specification Required, in terms of the well-known
   policies).

NEW
   Therefore, working groups and other document developers should use
   care in selecting appropriate registration policies when their
   documents create registries.  They should select the least strict
   policy that suits a registry's needs, and look for specific
   justification for policies that require significant community
   involvement (those stricter than Specification Required, in terms of
   the well-known policies).

Barry

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 10 Nov 2014 16:32:36 -0500

Hi,

Sorry for delay in response

> that we get through on an individual basis when they do.

OK

> require different types of RFCs.

It is a common false impression, despite plenty of counter examples,
that only standards track (and maybe experiemental standard) RFCs can
create registries and get code point assignments. I think it would be
good to dispell that.

> A fair point; I will add one.  :-)

OK.

> I will change the comma after "expert review" to the word "with".

OK.

> required for the registration request).

Sure.

> And Specification Required can have the designated expert consider
> whatever it wants to have the expert consider, according to the
> instructions given to the expert.

Specification Required implies an expert review of the documentation
to determine if it is sufficient for interoperability. Once you start
giving any additional instructions to the expert, it isn't
Specification Required anymore, it is now something else that I think
would be "Expert Review with Public Documentation Required" but I
suppose you could call "Sepcification Required and Expert Review" or
something.

In any case, the strictness ordering of the IANA Considerations
categories should be the correct ordering for their unadorned meaning,
not their meaning as modified by arbitrary additional provisions
making them stricter or less strict. The fact that you have to add
special additional instructions to "Specification Required" to bring
up it's difficulty to be equal to default "Expert Review" and the fact
that you could add instructions to "Expert Review" directing the
expert to only check if the docmentation is adequate for
interoperatibility, thus brining its difficutly down below the level
of Specification Required (since the docuentation would not have to be
public) makes it pretty clear that just plain "Specification Required"
is less strict than just plain "Expert Review".

> registration request *and* the specification.

What about the "registration" does the expert review for Specification
Required? What you say above isn't what the draft says.

In any case, I think the biggest problem with the standard categories
of IANA Consideration is the immense gap between First Come First
Server and the next stricter rung. If you are going to destroy
Specification Required by making it mean "Expert Review and
Specifcation Required", you are making that huge gap even bigger and I
request the addition of a new IANA Consideration category "Really Just
Specification Required" to cut that gap back down again.

If you go back to the history, it was quite clear: Expert Review was
patterned after Jon Postel. You know, an expert who reviews things and
uses their judgement. Specification Required was really much, much
easier - no judgement involved, doesn't matter if you are grabbing the
last code point, doesn't matter if your intended use is junk, ... as
long as you publicly describe the use, you get the code point. That's
it. The ordering was quite clear and, while you can argue that it is
really a lattice with no strict ordering between Expert Review and
Specification Required, in practice Expert Review was considered much
stricter than the mere requirement to public a spec.

Then people decided you needed an expert to see if the spec was really
a spec. That's fine. But now you have decided that because there is an
expert, instead of just deciding if the spec is a spec, suddently, out
of thin air, the "Specification" expert gets to apply arbitrary
judgement. I just don't see where that comes from, consider it a
radical change to "Specifciation Required", and believe it makes the
term "Specification Required" inaccurate and misleading.

> policies makes it clear what they expect the expert to consider (and

If there are any special instructions to an expert, then it is
basically Expert Review, not Specification Required.

And I'm not sure that lots of specufuc rules for an expert is always
such a good idea. Something to convey the general desires for
assignment policy is good but the expert should have the freedom to
take into account the numbe of code points remaining, for example,
which is rarely mentioned in instructions to experts that I have seen,
or unanticipated contingencies that come up.

> Thanks again for the thorough and thoughtful review.

You're welcome and see further below.

>    requests or patterns of requests appear to be unusual or abusive.

That looks great.

>    a mistake for the working group to have set the bar that high.

I agree that errors in the direction of overly stringent requirements
are much more common than errors in the other direction. But this
isn't an exact science, conditions can change, etc. Anyway I agree
with Brian Carpenter that not all Standards Action IANA Considerations
are a "mistake"...

>    the well-known policies).

OK, that sounds good except, of course, it should say "stricter than
Expert Review".

> Barry

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [email-masked]

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 16:57:58 -1000

> Sorry for delay in response

's OK.  Delays Я Us.

I think the only thing we're still stuck on is the Specification
Required vs Expert Review thing.  I've had a chat with Thomas and
Harald.  I have this to propose, so let me know, ASAP, what you think:

-- Section 2.3 --

OLD
   Therefore, working groups and other document developers should use
   care in selecting appropriate registration policies when their
   documents create registries.  They should select the least strict
   policy that suits a registry's needs, and look for specific
   justification for policies that require significant community
   involvement (those stricter than Specification Required, in terms of
   the well-known policies).
NEW
   Therefore, working groups and other document developers should use
   care in selecting appropriate registration policies when their
   documents create registries.  They should select the least strict
   policy that suits a registry's needs, and look for specific
   justification for policies that require significant community
   involvement (those stricter than Expert Review or Specification
   Required, in terms of the well-known policies).
END

-- Section 2.3.1 --

OLD
   The well-known policies from "First Come First Served" to "Standards
   Action" specify a range of policies in increasing order of strictness
   (using the numbering from the full list in Section 4):

   4.   First Come First Served
        No review, minimal documentation.

   5.   Expert Review
        Expert review with sufficient documentation for review.

   6.   Specification Required
        Expert review with significant, stable public documentation.
NEW
   The well-known policies from "First Come First Served" to "Standards
   Action" specify a range of policies in increasing order of strictness
   (using the numbering from the full list in Section 4):

   4.   First Come First Served
        No review, minimal documentation.

   5/6. Expert Review / Specification Required
        Expert review with sufficient documentation for review. /
        Expert review with significant, stable public documentation.
END

OLD
   The description in Section 4.10 of "IESG Approval" suggests that the
   IESG "can (and should) reject a request if another path for
   registration is available that is more appropriate and there is no
   compelling reason not to use that path."  The IESG should give
   similar consideration to any registration policy more stringent than
   Specification Required, asking for justification and ensuring that
   more relaxed policies have been considered, and the strict policy is
   the right one.
NEW
   The description in Section 4.10 of "IESG Approval" suggests that the
   IESG "can (and should) reject a request if another path for
   registration is available that is more appropriate and there is no
   compelling reason not to use that path."  The IESG should give
   similar consideration to any registration policy more stringent than
   Expert Review or Specification Required, asking for justification
   and ensuring that more relaxed policies have been considered, and
   the strict policy is the right one.
END

That makes the two policies of equal or unspecified strictness order.

WFY?

Barry

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 10 Nov 2014 23:19:09 -0500

Hi Barry,
>    Required, in terms of the well-known policies).

That's fine.

> That makes the two policies of equal or unspecified strictness order.

I'm OK with an unspecified strictness order. But I think "Expert
review with significant, stable public documentation." is highly
misleading. In the absence of express additional criterion,
Specification Required constrains the expert to only judging whether
or not the documentation is sufficient. It should say "Significant
stable public documentation sufficient for interoperability." or
something like that. For the Specification Required case, the expert
has a very limited remit and should be invisible to applicants. They
either get back a code point or a statement that their specification
was insufficient and needs more detail (or, I suppose, a statement
that the code points are exhausted).

I've also thought some more about this, trying to figure out why we
are at such complete disagreement. Don't know that I came to any
conclusion.
     Have you ever been in the position of seeking a code point
assignment when you believed the relevant expert was both
unconstrained by any specific guidelines and actively hostile to your
effort? I have and I can tell you I would have loved for the criterion
to be a simple Specification Required. So this may color my thinking.
    One possibility is that IESG members have the significant burden
of having to appoint experts and somehow that makes all experts
vaguely equivalent in the eyes of the IESG. So somehow you don't think
that an expert authorized to use any reasonable judgement (by an
unqualified "Expert Review" IANA Considerations, for example) is much
different from an expert that is only authorized to determine if
documentation is sufficient for interoperation (i.e., Specification
Required) and think of them as about the same, even though I think it
is like night and day.
     Another possibility is that these days most Specification
Required IANA Considerations have additional instructions requiring
experts to make judgements on matters other than whether the
documentation is sufficient for interoperability. (In my opinion,
since I think the ability of the Expert to apply reasonable judgement
is the most important characteristic, that makes them really Expert
Review.)

Really, there are lots of unqualified Expert Review IANA
Considerations. For example, look at
www.iana.org/assignments/isis-tlv-codepoints/isis-tlv-codepoints.xhtml
almost all the registries on that page are Expert Review with no
additional guidance of which I am aware.

Thanks,
Donald

---

From: Barry Leiba <[email-masked]>
Date: Mon, 10 Nov 2014 18:28:44 -1000

> something like that.

I can live with that.  Shall I make the changes, with that modification?

> to be a simple Specification Required. So this may color my thinking.

And that's why this version of BCP 26 is much stronger than the RFC
5226 version with respect to guidance for the designated expert.  And
I know that several of us on the IESG now are pushing that, strongly
asking for DE guidance (often to the puzzlement of the document
authors, who aren't sure what we're looking for).  I think the reason
guidance is often lacking is exactly because it's obvious to the
people writing the document what the DE should be considering, and the
problems happen much later.

All that said, the current IESG is not the future IESG, and there may
come a time when we again have an IESG that doesn't push on this point
at all.  Which is why it's good to have the strong push for DE
guidance baked into BCP 26.

Barry

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 10 Nov 2014 23:56:06 -0500

Hi Barry,

> I can live with that.  Shall I make the changes, with that modification?

OK. with that I'm satisfied.

> problems happen much later.

I'm not so sure it's obvious. While there might be people they would
trust, it is really a significant amount of work to try to come up
with reasonably complete guidance - there is really no limit to the
contingencies that could be covered.

Thanks,
Donald