Re: [Pals] RtgDir review of draft-ietf-pals-status-reduction-01.txt
"Adrian Farrel" <adrian@olddog.co.uk> Mon, 13 February 2017 18:59 UTC
Return-Path: <adrian@olddog.co.uk>
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 97EE51297CE; Mon, 13 Feb 2017 10:59:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-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 WzLY5-jIy4nR; Mon, 13 Feb 2017 10:59:35 -0800 (PST)
Received: from asmtp1.iomartmail.com (asmtp1.iomartmail.com [62.128.201.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EE291297B8; Mon, 13 Feb 2017 10:59:35 -0800 (PST)
Received: from asmtp1.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DIxUNL025350; Mon, 13 Feb 2017 18:59:30 GMT
Received: from 950129200 ([176.241.251.4]) (authenticated bits=0) by asmtp1.iomartmail.com (8.13.8/8.13.8) with ESMTP id v1DIxQZC025329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 13 Feb 2017 18:59:28 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: 'Luca Martini' <lmartini@monoski.com>, "'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>
In-Reply-To: <58A0F649.7090301@monoski.com>
Date: Mon, 13 Feb 2017 18:59:24 -0000
Message-ID: <01b901d2862b$4e449980$eacdcc80$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQM4vo8J6wBQZFbSvY6b5rTwOAF7nwH7KBPWAn2FA1kCSZrYWJ5kvt4w
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.1.0.1062-22884.001
X-TM-AS-Result: No--20.801-10.0-31-10
X-imss-scan-details: No--20.801-10.0-31-10
X-TMASE-MatchedRID: EMyCvCfVN1Fm2M+WdBiaRLdQIb8hCnY+EtdrY/Wb3fOp0TM4Pvf0QVdW JfEqbx6MtnL5EJYaKJT89WDKQGB2Ljxz5tDhhD0GnhHKNOYbLL49Z8UKMHjz4ZgWnaLDiGghIE9 v7dw1ta66dfDybokxRLVN0yuAcuwfWNPIxk1QrbR2IsPC9Z62GJE+3DCX3uibCVuEXtlNqcs9CU on0NTGec4WZ2e8JNtqmea15mW1PaXypyieQZBHiH/pBSMMVbhlpfVcx39Kq+7+9hPYcyW1ZI/x1 Ofbpz/fjXsFLEEP2Yq6oOKV8cM+m63gEYRSDbsNT7RVRbrn8wsZYA38gj3BxM2mvbig5LjGrX2B 4yCTgci5F0lgaETIUiuPV88ja/tdeaJohvG878aRfvUfL+585u4dka7Cjort9YBezwhBfW4b4fB 6yXNvBizSHqTnTaYvvTyMtG3v9FQIaofrtSGke3pwT5vp/xalLAnNohUyMa0ujyxRHwe+HMbK+p u0ZYwRtObqKvOLcVCw/gB9oTBycVUOzv+ERMvrJmbrB1j4XwpUXmZR3qwgxpsoi2XrUn/Jsuf7R WbvUtyrusVRy4an8bxAi7jPoeEQftwZ3X11IV0=
Archived-At: <https://mailarchive.ietf.org/arch/msg/pals/A3r608xUAXIkBpP5ruB5KqTi_No>
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
Reply-To: adrian@olddog.co.uk
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: Mon, 13 Feb 2017 18:59:37 -0000
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. > > > > > > 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. > > > 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. > > > 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. > > > 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. > > > 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. > > > 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. > > > 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 :-)
- [Pals] RtgDir review of draft-ietf-pals-status-re… Adrian Farrel
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Luca Martini
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Andrew G. Malis
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Adrian Farrel
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… BRUNGARD, DEBORAH A
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Luca Martini
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Adrian Farrel
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Luca Martini
- Re: [Pals] RtgDir review of draft-ietf-pals-statu… Adrian Farrel