Subject: RE: Comments solicited: draft-kompella-zinin-early-allocation-00.txt

From: Lou Berger <[email-masked]>
Date: Thu, 26 Feb 2004 20:51:35 -0500

[resend]

How about linking assignment expiration to expiration of the draft, 3 
months after?  If the draft makes it to RFC, no issue, if the draft takes a 
long time through the editors queue (which can take ~1.5 years!), no issue, 
if the draft keeps changing, no issue.  If the draft dies, so does the 
assignment.

Lou

At 11:24 AM 2/26/2004, Kireeti Kompella wrote:
>On Wed, 25 Feb 2004 [email-masked] wrote:
>
> > I finally got a chance to read the draft. The idea is good. I just
> > have a couple of questions/concerns about the expiry of the early
> > allocations..
> >
> > - Do you think that "at most one renewal" would work in practice ?
> >   There might be instances where there is a genuine need to keep
> >   the early allocations for more than a year (Consider VRRPv3).
> >   How do we deal with that situation ? If it is not possible to
> >   renew the allocations more than once, do we need to ask for
> >   early allocations with new numbers (which ofcourse will make
> >   the situation worse) or we should just ask/let IANA to delete
> >   and reassign those numbers (which would create problems as well).
>
>We mulled a bit over how many times the allocations should be renewed.
>The idea is that early allocation should NOT be requested as sson as
>an ID is written :-)  One renewal may be a bit too aggressive, but
>it gives two years.  Perhaps two renewals is okay, but no more (imho).
>
> > - The draft seems to put the responsibility of changing the status
> >   of the early allocations on the WG chairs ? I know that our chairs
> >   are very very responsible but I think, it will be a good idea to
> >   have an alternate mechanism in place such that the early allocations
> >   are marked deprecated/deleted automatically after a timeout.
>
>Automatic expiry was actually in the first version, but not everyone
>felt comfortable with that.  We can (and should) review this, and
>perhaps make clearer what expiry means.
>
>Note that NOT adding to either IANA's or the IESG's workload is an
>explicit goal.  Whatever we can do to avoid adding to WG chairs'
>workload is a 'nice-to-have' :-)
>
>Kireeti.
>-------
>
>_______________________________________________
>routing-discussion mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/routing-discussion

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Alex Zinin <[email-masked]>
Date: Sun, 29 Feb 2004 14:21:16 +0900

Lou,

  This would tie expiration to the author's ability to resubmit the draft,
  rather than to how the doc progresses. We could instead say that once the doc
  is submitted to the IESG, the codepoint is "frozen".

-- 
Alex
http://www.psg.com/~zinin/

---

From: Alex Zinin <[email-masked]>
Date: Sun, 29 Feb 2004 14:21:16 +0900

Lou,