Subject: IANA document allocation

From: Luca Martini <[email-masked]>
Date: Mon, 13 Dec 2004 15:19:45 -0700

WG,

Thomas Narten, our sponsoring AD, has asked me to change the IANA 
allocation document to reflect only two kind of allocations:
IETF consensus , and Expert review.

This means that I would remove the first come first served ranges, and 
the vendor specific ranges that are currently defined in the documents.

My personal opinion is that this is a good change as , "the expert" , 
can probably still respond quickly ( as opposed to an IETF consensus 
process ), yet can make sure that there is a good clear description and 
application for the allocated values.

I would like to hear from the WG if there are any strong opinions about 
this change to the IANA allocation documents.

Thanks.
Luca

---

From: "Shah, Himanshu" <[email-masked]>
Date: Thu, 16 Dec 2004 11:44:47 -0500

I also oppose to these changes strongly,
for about the same reasons.

/himanshu

> -----Original Message-----
> From: Eric Rosen [mailto:[email-masked]]
> Sent: Thursday, December 16, 2004 10:57 AM
> To: Luca Martini
> Cc: 'W. Mark Townsley'; PWE3 WG (E-mail)
> Subject: Re: [PWE3] IANA document allocation 
> 
> 
> 
> I strongly oppose this change. 
> 
> The FCFS range is there for a valid reason.  Eliminating it 
> merely increases
> the  political power  of the  IESG to  suppress innovation,  
> and  that would
> certainly be a move in the wrong direction. 
> 
> I also agree with Andy's arguments that the change is not practical. 
> 
> _______________________________________________
> pwe3 mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/pwe3
>

---

From: "Thomas D. Nadeau" <[email-masked]>
Date: Fri, 17 Dec 2004 15:27:06 -0500

On Dec 17, 2004, at 3:03 PM, Thomas Narten wrote:

>> Indeed, one of the things that might be good to have words about in
>> the IANA document (if Expert Review is chosen) is what type of
>> requests are expected to be approved, and what sort of review is
>> needed prior to granting a request.
>
> To followup, e.g., it wouldn't be unreasonable for the expert to ask
> the WG and for the WG to have to agree to an assignment (if that is
> what the WG wants).

	What happens if no working group exists at that time?

	--Tom

> For another perspective,  look at RFC 3575 "IANA Considerations for
> RADIUS", section 2.1, which says:
>
> 2.1.  Recommended Registration Policies
>
>    For registration requests where a Designated Expert should be
>    consulted, the responsible IESG area director should appoint the
>    Designated Expert.  The intention is that any allocation will be
>    accompanied by a published RFC.  However, the Designated Expert can
>    approve allocations once it seems clear that an RFC will be
>    published, allowing for the allocation of values prior to the
>    document being approved for publication as an RFC.  The Designated
>    Expert will post a request to the AAA WG mailing list (or a 
> successor
>    designated by the Area Director) for comment and review, including 
> an
>    Internet-Draft.  Before a period of 30 days has passed, the
>    Designated Expert will either approve or deny the registration
>    request, publish a notice of the decision to the AAA WG mailing list
>    or its successor, and inform IANA of its decision.  A denial notice
>    must be justified by an explanation and, in the cases where it is
>    possible, concrete suggestions on how the request can be modified so
>    as to become acceptable.
>
> The point is, it would be good to provide some general guidelines for
> what is an acceptable request and what is not, so both the requestor
> and the expert are on the same page. But it is also best not to get
> too explicit, since flexibility is needed to handle each request on a
> case-by-case basis and to deal with things that come up that might not
> have been thought through at the time the document was written. That
> is, give the expert general guidelines, but then give him/her the
> authority to do the right thing.
>
> Thomas
>

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Dec 2004 15:32:12 -0500

> 	What happens if no working group exists at that time?

The expert then decides is one answer. But in practice, the mailing
list may be around, in which case asking the list would presumably
still be reasonable.

Having an expert allows for flexibility to handle cases like the WG
going away.

The bottom line is that the expert is supposed to be responsive to the
community and deal with requests in a timely fashion. If that isn't
working (for whatever reason), one can raise the issue with the IESG
so that corrective steps can be taken (e.g., find a new expert).

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 17 Dec 2004 14:49:18 -0500

"Andrew G. Malis" <[email-masked]> writes:

> Yes, I do have a strong feeling about this.  As a prior "victim" of the 
> IANA expert review process, it needs to work much better in practice than 
> it has in the past in order for this to be practical.  How are the 
> following issues to be addressed:

I'll agree that the review process has not always worked as it should
in the past. But I think things are better now.

> - Naming the expert or experts

IESG names them (per RFC 2434). In practice, we ask the WG chairs and
after some discussion, someone gets picked, typically by mutual
agreement.

> - Replacing the experts following retirement, death, boredom, WG
    shutdown, etc.

IESG can replace at anytime (per 2434). Bottom line: if the expert
isn't being responsive, someone needs to raise the issue (i.e., to
make us aware) and then appropriate followup is needed.

> - Assuring timely response from the experts, who after all are volunteers 
> and presumably have revenue responsibilities

Same as above. Unresponsive experts should get replaced.

> I would also like to hear more about the supposed evils of FCFS registry 
> ranges.  There are many existing IANA registries with FCFS ranges.  Are 
> there problems associated with these registries?

It really depends on the registry. For some, FCFS is really fine. For
others, you really want some  review, to pushback on requests that
aren't appropriate. There are lots of reasons (bad idea, damaging to
the protocol or internet, duplicates existing work, etc.)

Some of this is discussed in RFC 2434 (actually,
draft-narten-iana-considerations-rfc2434bis-01.txt would be a better
starting point).

Also, there is much discussion on the problem of "unreviewed
extensions" (which can be a problem with FCFS registries) discussed in
draft-iesg-vendor-extensions-02.txt.

Comments/discussion on either draft would of course be most welcome.

Thomas

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 17 Dec 2004 21:46:37 +0000

The text that we put in the latest version of CW

http://www.ietf.org/internet-drafts/draft-ietf-pwe3-cw-01.txt

was

 >5.   IANA considerations
 >
 >   IANA needs to set up a registry of "PW Associated Channel Type".
 >   These are 16-bit values. IANA requests for the allocation of values
 >   from the PW Associated Channel Type REQUIRE expert review.
 >
 >   Initial PW Associated Channel Type value allocations are specified
 >   in "IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3)"
 >   [IANA], and should be incorporated by IANA into the registry.

The draft will be updated, if necessary, to reflect the
consensus at the end of this discussion.

- Stewart

---

From: Thomas Narten <[email-masked]>
Date: Mon, 20 Dec 2004 10:53:23 -0500

> 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