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

Luca Martini <lmartini@monoski.com> Wed, 08 March 2017 15:20 UTC

Return-Path: <lmartini@monoski.com>
X-Original-To: pals@ietfa.amsl.com
Delivered-To: pals@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661E31296D5; Wed, 8 Mar 2017 07:20:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.891
X-Spam-Level:
X-Spam-Status: No, score=-1.891 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, T_FILL_THIS_FORM_SHORT=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nxgyy9pF884y; Wed, 8 Mar 2017 07:20:00 -0800 (PST)
Received: from napoleon.monoski.com (napoleon.monoski.com [70.90.113.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78611296D6; Wed, 8 Mar 2017 07:19:59 -0800 (PST)
Received: from confusion.monoski.com (confusion.monoski.com [209.245.27.2]) (authenticated bits=0) by napoleon.monoski.com (8.14.7/8.14.7) with ESMTP id v28FJpkY005568 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 8 Mar 2017 08:19:51 -0700 (MST)
To: adrian@olddog.co.uk, "'Andrew G. Malis'" <agmalis@gmail.com>, 'George Swallow' <swallow.ietf@gmail.com>, 'Elisa Bellagamba' <Elisa.bellagamba@gmail.com>
References: <058601d21988$e15b2820$a4117860$@olddog.co.uk> <F64C10EAA68C8044B33656FA214632C85DDC31DC@MISOUT7MSGUSRDE.ITServices.sbc.com> <CAA=duU2gRSmXvHU4Pt-Xq58eM0t_FjMK0W3UpZrE2yN+gq1COw@mail.gmail.com> <58A0F649.7090301@monoski.com> <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk> <58ADD2B3.8040101@monoski.com> <01f301d2911f$a6354b90$f29fe2b0$@olddog.co.uk>
From: Luca Martini <lmartini@monoski.com>
Organization: Monoski
Message-ID: <58C02112.90403@monoski.com>
Date: Wed, 08 Mar 2017 08:19:46 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <01f301d2911f$a6354b90$f29fe2b0$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/YvCzgBk53pV_EgaQBi5LWD2WW64>
Cc: draft-ietf-pals-status-reduction@ietf.org, pals-chairs@ietf.org, "'BRUNGARD, DEBORAH A'" <db3546@att.com>, pals@ietf.org
Subject: Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt
X-BeenThere: pals@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Pseudowire And LDP-enabled Services dicussion list." <pals.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pals>, <mailto:pals-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/pals/>
List-Post: <mailto:pals@ietf.org>
List-Help: <mailto:pals-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pals>, <mailto:pals-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 08 Mar 2017 15:20:06 -0000

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
>