Subject: Re: New Version Notification for draft-leiba-cotton-iana-5226bis-20.txt

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Feb 2017 09:59:45 -0800

As a result of the discussion on the -19 version of the draft (where
"IANA" was replaced with "IANA Services" throughout, and related
changes were made), the IETF Trust agreed on the alternative of
putting a paragraph at the beginning (the second paragraph in the
Introduction in version -20), and then reverting most of the other
changes in -19.

Version -20 now only has the paragraph that explains that we call
<this stuff> "IANA" in this document, plus a few minor changes that
came out in IESG Evaluation.

We believe the document is now ready to publish, having been through
Last Call and IESG Evaluation, and ask Terry, as responsible AD, to
send this version off.

Thanks, everyone, for the comments!

Barry, document editor

On Thu, Feb 9, 2017 at 9:52 AM,  <[email-masked]> wrote:
>
> A new version of I-D, draft-leiba-cotton-iana-5226bis-20.txt
> has been successfully submitted by Barry Leiba and posted to the
> IETF repository.
>
> Name:           draft-leiba-cotton-iana-5226bis
> Revision:       20
> Title:          Guidelines for Writing an IANA Considerations Section in RFCs
> Document date:  2017-02-08
> Group:          Individual Submission
> Pages:          41
> URL:            https://www.ietf.org/internet-drafts/draft-leiba-cotton-iana-5226bis-20.txt
> Status:         https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/
> Htmlized:       https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-20
> Diff:           https://www.ietf.org/rfcdiff?url2=draft-leiba-cotton-iana-5226bis-20
>
> Abstract:
>    Many protocols make use of points of extensibility that use constants
>    to identify various protocol parameters.  To ensure that the values
>    used in these fields do not have conflicting uses, and to promote
>    interoperability, their allocation is often coordinated by a central
>    record keeper.  For IETF protocols, that role is filled by the
>    Internet Assigned Numbers Authority (IANA).
>
>    To make assignments in a given registry prudently, guidance is needed
>    for describing the conditions under which new values should be
>    assigned, as well as when and how modifications to existing values
>    can be made.  This document defines a framework for the documentation
>    of these guidelines by specification authors, in order to assure that
>    the provided guidance for the IANA Considerations is clear and
>    addresses the various issues that are likely in the operation of a
>    registry.
>
>    This is the third edition of this document; it obsoletes RFC 5226.
>
>
>
>
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

---

From: Bob Hinden <[email-masked]>
Date: Thu, 9 Feb 2017 14:50:56 -0800

Barry,

Thanks, changes look good to me.

Bob

> On Feb 9, 2017, at 9:59 AM, Barry Leiba <[email-masked]> wrote:
>

---

From: Loa Andersson <[email-masked]>
Date: Fri, 10 Feb 2017 12:08:41 +0800

Barry and Michelle,

The current document says about designated experts:

    The designated expert is responsible for coordinating the appropriate
    review of an assignment request.  The review may be wide or narrow,
    depending on the situation and the judgment of the designated expert.
    This may involve consultation with a set of technology experts,
    discussion on a public mailing list, consultation with a working
    group (or its mailing list if the working group has disbanded), etc.
    Ideally, the designated expert follows specific review criteria as
    documented with the protocol that creates or uses the namespace.  See
    the IANA Considerations sections of [RFC3748] and [RFC3575] for
    specific examples.

And we talk about combinations of allocation policies:

    Such combinations will commonly use one of {Standards Action, IETF
    Review, RFC Required} in combination with one of {Specification
    Required, Expert Review}.  Guidance should be provided about when
    each policy is appropriate, as in the example above.

All this is good, and I support it.

There is one aspect of the work of the designated experts that I have
not seen documented anywhere, maybe not even considered:

We are creating large registries, with quite a bit of inter-
dependencies, in my part of the world the LSP PING registries comes
into mind:
http://www.iana.org/assignments/mpls-lsp-ping-parameters/mpls-lsp-ping-parameters.xhtml

That registry have 24 sub-registries, some of the have a "Specification
Required" allocation policy and we have experts appointed.

However, the expert reviews a single allocation at the time, in doing
so I assume that the obvious dependencies are checked. Working groups
allocate code points through Standards Action, there are no explicit
cross review among registries, even though I know that it happens,
individual members of the working sometimes spot issues and propose
improvements. But this is not consistently done across all assignments.

IANA are good at asking when something is not obvious.

As a fail-safe mechanism, and based on what you say above would it be
possible to appoint experts for the ENTIRE registry, no matter what the
allocation policies are. The role of the experts would be extended to
consider the full range of related registries, rather than one registry
at the time.

If this is possible - What would it take?

If it is not possible, can we add text to 5226bis to make it possible?

/Loa

-- 

Loa Andersson                        email: [email-masked]
Senior MPLS Expert                          [email-masked]
Huawei Technologies (consultant)     phone: +46 739 81 21 64

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Feb 2017 21:02:44 -0800

Hi, Loa.
I think what you're asking about is already done, and doesn't require
anything specific to be said in BCP 26.  We have quite a few sets of
related registries where the same set of experts is appointed for the
set, and the experts consider what they need to (ideally, what they're
instructed to) with respect to the set of registries.  It's all just a
matter of spelling it out when the registries are created.

We can't put every possible combination of situations and all nuances
in BCP 26.  I think what's there gives enough guidance to allow people
to write policies and guidance for the registries that they need to
create.

Barry

On Thu, Feb 9, 2017 at 8:08 PM, Loa Andersson <[email-masked]> wrote:
>>> URL:
>>> https://www.ietf.org/internet-drafts/draft-leiba-cotton-iana-5226bis-20.txt
>>> Status:
>>> https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/
>>> Htmlized:
>>> https://tools.ietf.org/html/draft-leiba-cotton-iana-5226bis-20
>>> Diff:
>>> https://www.ietf.org/rfcdiff?url2=draft-leiba-cotton-iana-5226bis-20
>>>
>>> Abstract:

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 10 Feb 2017 10:29:23 +0000

Both this document and the early allocation document remain silent
on the reinstatement of expired (dead) early allocations on publication.

If a protocol has taken longer to publish than expected, and the constant
renewal via the IESG has not happened, I think that technically the
result should be a new assignment, when the right thing is often
to support the deployed user base by resurrecting the value and
assigning it to the RFC.

- Stewart

---

From: tom p. <[email-masked]>
Date: Fri, 10 Feb 2017 10:57:26 +0000

Barry

I note that Pete Resnick still  holds a DISCUSS (since 2014) on this
document, according to the datatracker.

What is going to happen to that?

Tom Petch

----- Original Message -----
From: "Barry Leiba" <[email-masked]>
To: "IETF discussion list" <[email-masked]>
Cc: <[email-masked]>
Sent: Thursday, February 09, 2017 5:59 PM

> > Group:          Individual Submission
https://www.ietf.org/internet-drafts/draft-leiba-cotton-iana-5226bis-20.
txt

---

From: "Pete Resnick" <[email-masked]>
Date: Fri, 10 Feb 2017 14:47:09 -0600

[Apologies for sending this earlier from the wrong address. Resending.]

My old DISCUSS has no formal effect since I'm no longer on the IESG.

Hopefully someone will check to see that my DISCUSS points are 
addressed. If I get some cycles, I will do so myself.

pr

-- 
Pete Resnick <http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Feb 2017 12:50:08 -0800

> Hopefully someone will check to see that my DISCUSS points are addressed. If
> I get some cycles, I will do so myself.

You already did, some while ago.  We chatted about one point at
length, and came up with text.

Barry