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

Luca Martini <lmartini@monoski.com> Wed, 22 February 2017 18:05 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 477FB129A83; Wed, 22 Feb 2017 10:05:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] 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 iXtXhKVuwOiy; Wed, 22 Feb 2017 10:05:19 -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 9E345129A92; Wed, 22 Feb 2017 10:04:48 -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 v1MI4evm021217 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 22 Feb 2017 11:04:40 -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>
From: Luca Martini <lmartini@monoski.com>
Organization: Monoski
Message-ID: <58ADD2B3.8040101@monoski.com>
Date: Wed, 22 Feb 2017 11:04:35 -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: <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/kmF_--JyRIyAdWT0PTHQP_ivu9w>
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, 22 Feb 2017 18:05:20 -0000

Adrian,

I addressed all your comments and produced v03.

At the same time I also followed Debra's suggestions in her reply e-mail.
There is only one minor point on the FCFS vendor ranges that if it does
not work I will need to remove the FCFS ranges.
See comments below.
Thanks.
Luca


On 02/13/17 11:59, Adrian Farrel wrote:
> Hi Luca,
>
> Love monoski.com!
>
> You've done a fine job with this. Thanks.
>
> Just cutting down to a few minor points that are so trivial I'm ashamed to type...
>
>>>     > Section 4
>>>     > You have not described all of the fields in the figure.
>>>
>> What did I miss ?
> -  MPLS LSP (tunnel) Label Stack Entry 
> -  GAL
> - 0 0 0 1
> - Version
> - Reserved   
>
> But these probably only need a group entry pointing at another doc.
>
Haa i see what you meant. I did not explain these fields exactly for
that reason. They are not part of the specification in this document.
I will add a reference to the GAL rfc for the GAL and the following
fields. I agree that it would make the document easier to read.
The MPLS LSP can be explained by rfc 3031.
I'll add the quotes as normative.

>>>     >
>>>     > Section 4
>>>     > You have...
>>>     > Channel type 0xZZ pending IANA allocation.
>>>     > ...but no mention in the IANA section
>>>     > The figure shows "0xZZ PW OAM Message", but surely this is
>>>     > "PW Status Reduction Message"
>>>     >
>>>
>> Sure , but it has not been allocated yet. This is for the RFC editor to
>> replace the text once the allocation is dune.
> Yeah, but if you don't have 0xZZ or "PW OAM Message" in the IANA Considerations section (section 8) it seems unlikely that IANA will do anything and so the RFC Editor will not be able to replace ZZ with anything.
ok, you are right the IANA section is missing directions.
I will add it.
>>>     > Section 4
>>>     > Do you want IANA to track the flags field?
>> no.
>> I think this needs to be allocated by a new RFC. Is that not the default ?
>> Making flags easy to allocate when there are only 6 bits is not wise and
>> will lead to misuse.
> You would still need an RFC to allocate the flags.
> The difference is that, without the registry, several RFCs may become "confused" about which flags they have allocated.
> The IANA registry provides a way of preventing clashes.
OK - This sounds reasonable. I will add a registry, with policy of IETF
Review.

>>>     > Section 5
>>>     > In 8.3 you list a number of notification codes. A little can be
>>>     deduced
>>>     > from their names, but you do not describe anywhere when or why
>>>     most of
>>>     > them are used (5.0.2.3 and 6 are the exceptions). You should, and
>>>     > section 5 or 6 is probably the place.
>>>
>> These are really obvious. I do not see the point of adding obvious text.
>> Go look at all the BGP specs , most of them are extremely unreadable,
>> this is much more clear then any of those.
>> like if i receive an ack message sequence number that is after the last
>> message i sent , clearly is have a "Unacknowledged control message" error...
> Ah, and there was I thinking that this would be a "Control message acknowledgement" error, while "Unacknowledged control message" would be used when a control message went unacknowledged. :-)
>
> I don't think "other documents are worse" is the best argument you've ever used, but I'm not going to fight this. It's up to the AD and shepherd.
Yes after looking at this more closely , i will add the missing guidance
where appropriate.
I explained code 0x0, code 0x1 (renamed to PW configuration  mismatch ,
which is more appropriate English)
code 0x3 and code 0x4.

>>>     > Section 8.1
>>>     > You have a range assigned by Expert Review. It is a requirement that
>>>     > you give guidance to the experts about how they should review
>>>     > requests.
>> we did not do that in the past.  I assume that the Expert is an Expert
>> in this field , and has good judgment.
>> maybe i should add "at sole discretion of the expert" ?
> Times may have changed.
> Let's leave this for the AD to worry about.
ok, I will add an expert guidance section. The purpose of this range was
to make things easy to allocate and avoid duplication.
>>>     > 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.


>>>     > The sub-section numbering in Section 5 is broken. You can have,
>>>     > for example, "5.0.1".
>>>     >
>>>
>> fixed
>>>     > In a number of places you have "sub-TLVs" and in other places
>>>     "TLVs".
>>>     > I think they are all "TLVs".
>>>
>> yes, i mean sub-tlv because it's within another tlv.
>>
>>
>>>     > In 5.0.2.1 "the address of the MPLS-TP tunnel ID" is confused. It is
>>>     > "the identifier of the MPLS tunnel". Indeed, where did MPLS-TP
>>>     suddenly
>>>     > come from since you want this to work for all LSPs (see also 8.2).
>>>     >
>>>
>> no, this is what this is . If you want an MPLS tunnel ID , it would be
>> different.
> Shrug.
> I don't think it's an address. I think its and ID.
ok I think I understand now. i will replace Tunnel ID address , with
simply "Tunnel ID"

>>>     > 2.1.1, 2.1.3, and 5.0.2.3
>>>     > "unprovisioned"
>>>     > I think the word is "deprovisioned"
>  >
>> unprovisioned means it is not provisioned. deprovisioned , i take to
>> mean that it was once provisioned, now it is not ....
>> I like the more generic "unprovisioned"
> Hmmm. The phrase would be "not provisioned". 
> "unprovisioned" apparently gives rise to confusion :-)
>
>
>
ok, but the problem is that there is a difference between "not
provisioned" and something that was once provisioned , and is now not
provisioned.
I will go with deprovisioned as you suggested, if it makes things
clearer. I'll let the RFC editor figure out if it is correct English.

Luca