Re: IANA document allocation

Thomas Narten <narten@us.ibm.com> Mon, 20 December 2004 15:53 UTC

From: Thomas Narten <narten@us.ibm.com>
Subject: Re: IANA document allocation
Date: Mon, 20 Dec 2004 10:53:23 -0500
Lines: 48
References: <200412172038.iBHKcBHS017601@rtp-core-1.cisco.com>
Cc: "'W. Mark Townsley'" <townsley@cisco.com>, "PWE3 WG (E-mail)" <pwe3@ietf.org>, Luca Martini <lmartini@cisco.com>
X-From: pwe3-bounces@ietf.org Mon Dec 20 17:03:52 2004
Return-path: <pwe3-bounces@ietf.org>
To: erosen@cisco.com
In-Reply-To: Message from erosen@cisco.com of "Fri, 17 Dec 2004 15:38:11 EST." <200412172038.iBHKcBHS017601@rtp-core-1.cisco.com>
X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081
X-BeenThere: pwe3@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Pseudo Wires Edge to Edge <pwe3.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:pwe3@ietf.org>
List-Help: <mailto:pwe3-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pwe3>, <mailto:pwe3-request@ietf.org?subject=subscribe>
Sender: pwe3-bounces@ietf.org
Errors-To: pwe3-bounces@ietf.org
X-Message-ID:
Message-ID: <20140418091811.2560.65108.ARCHIVE@ietfa.amsl.com>

> I think  most documents refer to  this as "private use",  i.e., it basically
> means "not  to be  assigned by IANA".

"Private use" is a defined term in 2434. If that is what is meant, it
is better to use standard terminology.

> In general, this only gets used if there is no FCFS space.  However,
> values in this space may also end up becoming de facto standards.
> Private use values could also be used if someone wanted to deploy a
> proprietary and non-interoperable extension, though I'm sure that no
> one would ever want to do that.

"private use" is also not really for deploying proprietary stuff, at
least not for a _vendor_ to do so. It is intended that an end-user can
do this (within an environment they do control, so they can assure
that numbers won't conflict). (If a vendor needs to deploy something,
we need to make sure that they use unique numbers so that the numbers
don't conflict with those used by some other vendor/purpose.)

> One thing that might be rational would be to make the FCFS space
> bigger, but to also leave a reserved space.  If at some point we
> actually look to be in danger of running out of FCFS space, we can
> then decide whether to extend the FCFS space.

I think one really needs to look at each name space individually and
consider such things as:

 - is the space large enough to accomodate likely usage?

Separately, one needs to consider how much review is necessary. For
some name spaces, I agree that little or no review is needed. But for
others, it is. Again, please have a look at
draft-iesg-vendor-extensions-02.txt, as there is much experience with
problems caused by unreviewed extensions.

> I do not at all like the idea of "expert review", as it creates a
> process which is all too easily subverted by cronyism and political
> agendas, or which might just fail to deliver results.

Well, if you are not willing to have _any_ review, there is a risk
that bogus extensions will get defined and deployed that negatively
impact other deployments, the overall pwe3 architecture, etc. IMO,
expert review provides the reasonable balance between no review (which
has caused significant problems with some protocols) vs. an even
higher bar, such as requiring an RFC publication, (or even higher,
requiring a standards track document).

Thomas