Subject: FW: IANA alloacation document text sample.

From: "Gray, Eric" <[email-masked]>
Date: Fri, 25 Mar 2005 14:41:20 -0500

-----Original Message-----
From: Gray, Eric 
Sent: Friday, March 25, 2005 2:41 PM
To: 'Luca Martini'
Cc: Eric Rosen (erosen); [email-masked]
Subject: RE: IANA alloacation document text sample.

Luca,

	This approach is half-way between "First Come First Serve"
and "Specification Required" as defined in RFC 2434.  As Thomas
Narten (a co-author of RFC 2434) brought up in the meeting, that
RFC is a guide-line.  I agree that this seems to represent the
consensus result of discussion in and around the PWE3 meeting in 
Mpls.

	I just re-read the minutes, and note that the way it is 
left in the minutes is as follows:

	o	the question should be debated on the list
	o	there was no hard conclusion with respect to 
		eliminating the vendor specific assignments
		entirely

The "consensus" represented by your suggested IANA text is the
result - IMHO - of my withdrawing my objection to allowing the
ID to be allowed to expire rather than becoming at last an 
Informational RFC. That discussion was after the meeting and is 
not reflected in the minutes.  That is OK with me if it is OK
with every one else.

	Assuming that you are posting this recommended text as a
potential beginning point for debate, I will follow it up by
saying that I am in full agreement with the sense of the text
you propose.  With the choice between a small number of "IETF
Consensus", and a much larger number of "FCFS" code points, I
feel certain that having a separate vendor specific set would
be redundant and unnecessary.

	I do not know if it is necessary to suggest to IANA that
they should capture the salient points from the relevant ID at
the time that they assign the number, given that the ID may be
difficult to obtain at a later date.  However, as we discussed,
it is nearly always possible to find a copy of an expired ID
somewhere.

--
Eric

-----Original Message-----
From: Luca Martini [mailto:[email-masked]]
Sent: Friday, March 25, 2005 2:05 PM
To: Eric Rosen (erosen); Gray, Eric
Cc: [email-masked]
Subject: IANA alloacation document text sample.

Eric & Eric & WG,

Below is a sample text of what I am thinking about writing in the IANA 
document. As far as I can remember this reflects the consensus we 
reached in the PWE3 meeting in Minneapolis.
Please let me know if the grammar need improvement , or we need to 
change the allocation policy...
In general I will allocate a small portion of the space to IETF 
consensus , and the rest to first come first served space.
The only exception would be the status messaging type where I think to 
reverse this, because there is very little space , so maybe only 4 bits 
should be first come first served. is that ok ?

Thanks.
Luca

"Pseudowire Type"

IANA needs to set up a registry of "Pseudowire Type".  These are 15-bit
values.  PW Type values 1 through 127 are to be assigned by IANA using the
"IETF Consensus" policy defined in RFC2434. PW Type values 128 through 32767
are to be assigned by IANA, using the "First Come First Served" policy
defined in RFC2434. In addition to the "First Come First Served" policy, an
Internet draft describing the intended use for the code point to be
allocated, MUST exists at the time of allocation. This Internet draft MAY
be targeted to become an informational RFC, but in any case the allocation
will not depend in any way on the status of the Internet draft.
A Pseudowire Type description of up to 65 characters is required for any
assignment from this registry. The registry MUST contain the name of the
Internet draft at the time of code point allocation.

---

From: "Gray, Eric" <[email-masked]>
Date: Mon, 28 Mar 2005 11:14:38 -0500

Eric,

	I believe this objection presupposes that most people will not
even attempt to be clear about the way in which they will use a code
point.  Do you not believe that most people are at least slightly more
conscientious than that?

	If we use FCFS without expecting people to even make the attempt
to specify how they will use it, then it effectively turns the entire
set of FCFS code points into vendor specific/experimental numbers.  On
the other hand, if people specify how they expect to use it, then many
of the uses that may become obvious at some point may use the same code 
points.

	If it is your position that we should either not ask for a draft,
or ask for one that will become permanent, then I would push for using
the IANA code-point assignment policy "Specification Required" rather
than either "Expert Review" or "First Come First Serve".  In most cases,
an Informational RFC can be published fairly quickly - reducing the DoS
potential that some people see with "Expert Review" - and people will be
able to find it easily enough.

--
Eric Gray

-----Original Message-----
From: Eric Rosen [mailto:[email-masked]]
Sent: Monday, March 28, 2005 11:00 AM
To: Luca Martini
Cc: Gray, Eric; [email-masked]
Subject: Re: IANA alloacation document text sample. 

I  really don't  see  the point  of  requiring an  internet-draft  to get  a
codepoint, if  there is no  quality control on  the draft, and the  draft is
going to be allowed to expire once the codepoint is granted.  Once we decide
to assign the codepoints FCFS, with  no expert review, we might as well face
up to  the fact that  we won't necessarily  know how the codepoint  is being
used.

---

From: Luca Martini <[email-masked]>
Date: Mon, 28 Mar 2005 09:21:45 -0700

Eric,

Let's face it , there is no way to enforce the use of a particular code 
point.
However the proposed methodology, makes a good assumption that people 
will cooperate with the system , and document what is used.
I believe that the IANA process serves to document, and coordinate 
codepoint allocation, not enforce usage. Requiring an ID will force 
documentation of what is proposed, and possibly feedback from the IETF 
community.
Two allocation methods are proposed:

IETF consensus: gives full documentation, and control to the IETF community.
FCFS : Gives minimum documentation, and no control .

I think implementers can always choose to ignore anything not in the 
IETF consensus range.

Luca

Eric Rosen wrote:

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