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

[Barry Leiba <[e-mail]>]

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