Re: [core] [Ext] Early allocation expiry/renewal (Re: Lars Eggert's Discuss on draft-ietf-core-sid-22: (with DISCUSS and COMMENT))

[Amanda Baber <[e-mail]>]

We’ve been looking at producing a 7120bis, which we’re going to bring up at the IESG meeting on Sunday. We can speak to processing issues that affect us, but issues like the appropriate length of an allocation term require feedback from chairs and ADs, followed by (/concurrent with) guidance from the IESG. 

The section of the document that says “At most, one renewal request should be made [...] under rare circumstances, more than one allocation renewal may be justified” dates back to RFC 4020. It doesn’t reflect current practice.  

In fact, most early allocations are renewed at least once, and of the ~30 sets of early allocations currently present in the registries, roughly half have required two or more renewals. (The first requires AD approval only, but subsequent renewals require approval from the IESG.)

We've only started to reach out, but it's already been suggested that a two-year term might be preferable.

Amanda 

On 10/27/23, 2:41 PM, "iesg on behalf of Carsten Bormann" <[e-mail] on behalf of [e-mail]> wrote:

    On 2023-10-26, at 15:18, Lars Eggert via Datatracker <[e-mail]> wrote:
    > 
    > 
    > ### Section 6.5.3, paragraph 9
    > ```
    >     Early Allocations are made with a one-year period, after which they
    >     need to be renewed or will expire.
    > ```
    > In practice, that one year is too short

    +1

    At most one renewal also is too short.

    > and is already creating
    > frequent IESG management items for extension approvals. Given the
    > many more early allocations, this process will require, this will be
    > disruptive for the IESG.

    Right, how do we get this fixed?

    (The sentence is just a restatement of how BCP100 deals with the timing.)

    Grüße, Carsten