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

Thanks Luca,

Let's kick it up stairs.

Adrian

> -----Original Message-----
> From: Luca Martini [mailto:lmartini@monoski.com]
> Sent: 08 March 2017 15:20
> To: adrian@olddog.co.uk; 'Andrew G. Malis'; 'George Swallow'; 'Elisa Bellagamba'
> Cc: draft-ietf-pals-status-reduction@ietf.org; pals-chairs@ietf.org; 'BRUNGARD,
> DEBORAH A'; pals@ietf.org
> Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt
> 
> HI! Adrian,
> I followed your initial suggestion and put al lthese ranges in the
> Expert review range , and created an expert guideline section.
> 
> With this version -04 we should be good to go!
> Thanks.
> Luca
> 
> 
> On 02/27/17 10:33, Adrian Farrel wrote:
> > 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
> >
> >
> >
> >
> > _______________________________________________
> > Pals mailing list
> > Pals@ietf.org
> > https://www.ietf.org/mailman/listinfo/pals
> >