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

From: Alex Zinin <[email-masked]>
Date: Thu, 12 Feb 2004 22:38:02 -0800

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/

---

From: Tony Przygienda <[email-masked]>
Date: Fri, 13 Feb 2004 22:37:18 +0100

Alex Zinin wrote:

>This is a forwarded message
>From: Alex Zinin <[email-masked]>
>To: [email-masked]
>Cc: [email-masked]
>Date: Thursday, February 12, 2004, 10:38:02 PM
>Subject: Comments solicited: draft-kompella-zinin-early-allocation-00.txt
>
>===8<==============Original message text===============
>Folks-
>
from my reading necessary and sufficent. Point c) makes me a tad 
concerned. It ain't clear
cut to decide that often but I struggle to come up with a better idea. 
Actually, I have one but
it's not very practical, we could require that such an early allocation 
must have as structure

    Code Point followed by Version number

but it's tad unwieldy. On the other hand, changing codepoints when a 
serious flaw preventing
interop is detected will run havoc since we'll call 2 codepoints by same 
name for all practical
purposes. Differentiam specificam between earlier and newer versions of 
draft are pretty
opaque to the average feature user but the fact that feature X based on 
draft Y and feature X
based on draft Y+1 will be called the same and not work together, is 
not. On the other hand,
we have sometimes the situation today already so the policy here won't 
make matter worse
I think

    2c

    -- tony

---

From: [email-masked]
Date: Sat, 14 Feb 2004 18:52:51 +0100

hi alex, kireeti, all,

would it be possible to detail the difference in procedure
between a refresh, a renewal and a re-allocation

"3.3. Expiry

    If early allocations expire before the document progresses to the
    point where IANA normally makes allocations, the authors and WG
    chairs may follow an abbreviated version of the process in section
    x.2 to request renewal of the code points.  At most one renewal
    request may be made; thus, authors should choose carefully when the
    original request is to be made."

the reason being that you're proposing "at most one renew"
and i'd like to know if this means i can refresh at most
once ? or that i may ask only once for a different code-
point value - definition(s) may help here

thanks for the clarification(s)
- dimitri.

-- 
Papadimitriou Dimitri
E-mail : [email-masked]
E-mail : [email-masked]
Webpage: http://psg.com/~dpapadimitriou/
Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium
Phone  : +32 3 240-8491

---

From: Eric Rosen <[email-masked]>
Date: Thu, 26 Feb 2004 13:40:41 -0500

The problem  that this doc is trying  to solve appears to  be the following:

- some codepoint spaces are small, not extensible, or otherwise not amenable
  to a FCFS style of allocation

- early implementations  that need codepoint values from  these spaces can't
  rely on IANA, and have to make their own choices

- if these implementations become  widespread, the codepoint values they use
  become the defacto standard. 

I just don't  see how the complicated rigamarole  that the document proposes
will solve this  problem.  If a particular use of  a codepoint value becomes
widespread, it  will still become the  defacto standard, no  matter how what
the IETF says about expirations, refreshes, renewals, etc., etc.

If the  implementation does  not catch on,  perhaps the  proposed procedures
would at  least allow the codepoint  value to be  reclaimed.  Well, probably
not.  The  WG will have disbanded,  or there will  be a new WG  chairman who
doesn't  know anything  about  the codepoint  and  has no  idea  that he  is
supposed to talk to IANA about it. 

The procedures  do provide  a way to  get an "official"  codepoint allocated
from  a "standards action"  space without  having to  wait for  a "standards
action", but it doesn't really seem to get to the root of the problem, which
is that the codepoint space is too small. 

As  for  two years  being  long  enough, that's  a  joke.   Two years  after
widespread  deployment  is   usually  about  the  time  that   the  IESG  is
insisting on the need for the Requirements and Framework documents.

---

From: John Leslie <[email-masked]>
Date: Thu, 26 Feb 2004 15:19:54 -0500

>   become the defacto standard. 

   At first blush, Eric seems to have stated the problem correctly (albeit
not politically correctly ;)

   He does, of course, gloss over the IESG action to declare a particular
namespace appropriate for this early-allocation process. I assume that no
codespace in imminent danger of exhaustion would be so designated...

   We need to clarify whether codespaces in danger of exhaustion MAY be so
designated -- and possibly suggest conditions under which the designation
would be withdrawn.

> the IETF says about expirations, refreshes, renewals, etc., etc.

   As I think about this, we perhaps need the equivalent of the RFC1918
free-for-all zones: particular codes which may be used for interoperability
testing, but are subject to other incompatible uses.

> supposed to talk to IANA about it. 

   What does "reclaimed" mean?

   It's easy enough to remove it from IANA databases; but that doesn't stop
its use by deployed equipment.

   Thus, I'd suggest we redefine "reclaimed" to mean RFC1918-style free-for-all.

--
John Leslie <[email-masked]>

---

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

Eric,

>   to a FCFS style of allocation

Change this to:

  - for whatever reason a decision has been made to make the allocation policy
    for a codepoint space the Standards Action, whether this space is large or
    small

>   rely on IANA, and have to make their own choices

Change this to:

  - early implementations required by the process (or because it's a hot
    technology) can't get the codepoint from IANA because a Standards Action
    is required, yet implementations are needed to approve the standard, so
    they simply grab the next number available hoping it'll do.

>   become the defacto standard.

Change this to:

  - if these implementations get deployed in the same network at some point--
    they collide

> is that the codepoint space is too small. 

I think you're missing the problem. It is not the size of the space. It is
the circular dependency between IANA allocation and STD action.

Alex

---

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

John,

> testing, but are subject to other incompatible uses.

Experimental allocation policy should cover this. See RFC 3692.

Alex

---

From: Kireeti Kompella <[email-masked]>
Date: Sun, 29 Feb 2004 17:18:58 -0800 (PST)

> the circular dependency between IANA allocation and STD action.

Exactly.

Kireeti.
-------

---

From: Eric Rosen <[email-masked]>
Date: Mon, 01 Mar 2004 10:07:42 -0500

> the circular dependency between IANA allocation and STD action. 

I think  there is only a  practical problem if  the space is small.   If the
space  is large,  the  problem  is easily  solved  by making  a  part of  it
available for  FCFS assignment.  In fact,  it seems evident  that it doesn't
make any sense to  put a large space in the "STD  action" category, as there
is no means to enforce it.

---

From: Alex Zinin <[email-masked]>
Date: Tue, 2 Mar 2004 09:35:53 +0900

Eric,

> is no means to enforce it.

I see your point now. Note that "STD action" and a space being small are not
directly related--it is feasible to use "STD action" even if the space is big
enough (e.g. for change control), and on the other hand, it is possible to
use other policies for scarce resources (Expert Review, IESG Approval, IETF
Consensus). Also note, that there several existing registries with "STD action"
as the policy and that need this issue solved.

Alex