Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt

["Adrian Farrel" <[e-mail]>]

Hi Luca,

> >>> > Section 8.1
> >>> > The values 128 through 254 are assigned using FCFS. You cannot then
> >>> > attempt to further constrain how the values are used (e.g., "for
> >>> > vendor proprietary extensions"), and you should avoid the word
> >>> >  "reserved" since it has special meaning for IANA.
> >>
> >> ??? i want the vendor proprietary extensions to be FCFS, does this not
> >> say that ?
> >> the point is that if something is not a proprietary extension it should
> >> not use this.
> >> for example it prevents people like me from using FEC type 128 for a
> >> standard protocol ...;-)
> >
> > Afraid it doesn't
> > FCFS means "open season". Anyone can get a FCFS code point for any use.
> > Again, the AD can help sort this out.
|> Yes , FCFS is open , and this range is also designated for vendor
|> proprietary extensions. The intention is that something in this range
|> would never become IETF standard.
>
> Can IANA follow the FCFS process while this document designates this
> range as vendor proprietary ?
> if someone violates that rule, then other implementations have no duty
> to support these extensions as they are not standard.
> 
> If you think that this will not work , I can change it to just IETF review.

No. The only rules are the rules in the registry. That is, you tell IANA how to assign values, and they do that. Someone coming along later is bound only by the IANA rules and not by additional words in your RFC.

So you can choose from 5226, but sounds to me that you want:
- a registry to be kept of values used by vendors (i.e., not just an
  unregulated space for them to play in)
- to stop people grabbing from the vendor space when they should
   be writing RFCs
I suggest you use "Expert Review" [RFC5226] and describe in your document (as you would be required to) the rules that the Designated Expert must apply. These could be:
- Not used for protocol extensions that should be standardised
- Only use for vendor-specific uses
- Must have a clear indication of the vendor
- Should have a contact email address that is not an individual

(Otherwise, IETF review)

A