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

[Barry Leiba <[e-mail]>]

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.


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


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

Barry