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

[Donald Eastlake <[e-mail]>]

Hi,

Sorry for delay in response

On Wed, Nov 5, 2014 at 11:35 AM, Barry Leiba <[e-mail]> wrote:
> Hi, Donald -- I'm sorry I didn't respond to this right away.
>
>...
>
>> 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.

OK

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

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.

>> Contrary to Section 9.1 of this draft, the draft does not have an IANA
>> Considerations Section.
>
> A fair point; I will add one.  :-)

OK.

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

OK.

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

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

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

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.

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

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.

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

You're welcome and see further below.

> Barry

On Wed, Nov 5, 2014 at 1:31 PM, Barry Leiba <[e-mail]> wrote:
> Following up on a thing or two:
>
>>> 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.
>
> 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.

That looks great.

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

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

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

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

> Barry

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   [phone] (cell)
 155 Beaver Street, Milford, MA 01757 USA
 [e-mail]