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

From: [email-masked]
Date: Wed, 25 Feb 2004 16:08:13 -0600

Alex,

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

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

Regards
Mukesh

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of ext Alex Zinin
> Sent: Thursday, February 12, 2004 10:38 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Comments solicited:
> draft-kompella-zinin-early-allocation-00.txt
> 
> 
> Folks-
> 
>  Please review draft-kompella-zinin-early-allocation-00.txt and
>  provide your comments. We're going to discuss it at the Routing
>  Area meeting in Seoul. Below is the abstract from the document:
> 
>    This memo discusses earlier allocation of code points by IANA as a
>    remedy to the problem created by the "Standards Action" IANA policy
>    for protocols where, by the IETF process, implementation and
>    deployment experience is desired or required prior to publication.
>  
>  The document is available at:
>  
>  
> http://www.ietf.org/internet-drafts/draft-kompella-zinin-early
> -allocation-00.txt
>   
>  Send your comments to [email-masked], please.
>  
> -- 
> Alex
> http://www.psg.com/~zinin/
> 
> 
> _______________________________________________
> routing-discussion mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/routing-discussion
>

---

From: Kireeti Kompella <[email-masked]>
Date: Thu, 26 Feb 2004 08:24:31 -0800 (PST)

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

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

---

From: Alex Zinin <[email-masked]>
Date: Thu, 26 Feb 2004 09:48:31 -0800

Kireeti, Mukesh-

> it gives two years.  Perhaps two renewals is okay, but no more (imho).

Maybe we could say that further renewals require IESG approval,
so it is possible, but painful enough to make it less attractive
than finishing the spec and advancing it to STD tracks.

> workload is a 'nice-to-have' :-)

Exactly. Unfortunately, automatic means a periodic human check for
IANA--they don't have the infrastructure to automatically expire
allocations. This may change in future, but at this point asking
IANA to do so essentially means nobody will.

Alex

---

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

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

---

From: Pedro Roque Marques <[email-masked]>
Date: Mon, 1 Mar 2004 11:25:18 -0800 (PST)

Lou Berger writes:

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

Just make sure you don't try to reuse the same assigned number for
something else in less than 10 years, if it ever gets into software...

That is about the lifetime for 'deprecated' behaviour.

While the ietf may be able to assume that an assigment "dies"... the
decision may not be so simple in the real world. I would at least like
to have a good idea of everyone that claims to have implemented said
code point...

Ask your self the question: How many networks are running TDP, which
is a protocol that "died" in the ietf ? And would you like to reuse
its code point ?

I'm sure that people can come up w/ many other examples.

  Pedro.