[mpls] Shepherd's pre-adoption-poll review of draft-andersson-lsp-ping-registries-update

"Adrian Farrel" <adrian@olddog.co.uk> Mon, 05 August 2019 13:33 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9471201EA; Mon, 5 Aug 2019 06:33:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_NONE=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 X4XDADpgBuyG; Mon, 5 Aug 2019 06:33:12 -0700 (PDT)
Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75B561201E5; Mon, 5 Aug 2019 06:33:12 -0700 (PDT)
Received: from vs2.iomartmail.com (vs2.iomartmail.com [10.12.10.123]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id x75DXAT1018523; Mon, 5 Aug 2019 14:33:10 +0100
Received: from vs2.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 69C8822044; Mon, 5 Aug 2019 14:33:10 +0100 (BST)
Received: from asmtp1.iomartmail.com (unknown [10.12.10.248]) by vs2.iomartmail.com (Postfix) with ESMTPS id 5E9B422048; Mon, 5 Aug 2019 14:33:10 +0100 (BST)
Received: from LAPTOPK7AS653V ([87.112.55.143]) (authenticated bits=0) by asmtp1.iomartmail.com (8.14.4/8.14.4) with ESMTP id x75DX7j3000955 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 5 Aug 2019 14:33:09 +0100
Reply-To: <adrian@olddog.co.uk>
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <draft-andersson-lsp-ping-registries-update@ietf.org>
Cc: <mpls@ietf.org>
Date: Mon, 5 Aug 2019 14:33:06 +0100
Organization: Old Dog Consulting
Message-ID: <043801d54b92$51f903c0$f5eb0b40$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AdVLjjGivUPFuwjGRwuUfKfdJIKVuQ==
Content-Language: en-gb
X-Originating-IP: 87.112.55.143
X-Thinkmail-Auth: adrian@olddog.co.uk
X-TM-AS-GCONF: 00
X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-24822.007
X-TM-AS-Result: No--13.420-10.0-31-10
X-imss-scan-details: No--13.420-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-24822.007
X-TMASE-Result: 10--13.419900-10.000000
X-TMASE-MatchedRID: FXGKkZg/B/H5uyvfNjfPT3FPUrVDm6jtS/ceBQrgS1FQKAQSutQYXG0L QpmjB9pj21BHKSeoeV4Qnem4O36k5DZxjkmratY+4h8r8l3l4eYiJN3aXuV/obiBTLMkgNsWIN/ MbXxx+S10Q3kLI5lkfACeNsrtHscC3uvoBt9Zrdy20BbG4zmyXpeDTKy+kyH7S411xkMup5Qo+d 2hAeagywXhqtaGWOL/rtM5xoxNNOO433sKec1LAfRUId35VCIe6/ovm5YGTGm8NrbzjPvzJ7mhV mie+sctIjXKhrGfOKcOjHEoV3dzamgRF+KXsXmMUL+lPXRaPqn9EfbuxTfAPYe/yi1B5QhCaoL2 VZYlMZxG+fINELXoh6ORQRr7tR1qYXy1htRbB/CL6q5RsNhv5MtEPnVvPlFkDJinLlDjjHMuhqj QrfAzpVQSf2wR7z3QSasvmwdPPMHtCUBQ/BGX6wm6mWzI013HbhfjcETuo7RXPwnnY5XL5Hd7bc i/LVuNUjwC4PXX8BpicArG/2fGpU1+zyfzlN7y/sToY2qzpx4rN8z0HohG3voLR4+zsDTt+Tf0t cxKuLpa5u2NVJuap3gCu90kT31zLBJRhqwmC1sa66hcTnOLvA==
X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/G6swIYsEqJwpGLySUnbygtXT0v8>
Subject: [mpls] Shepherd's pre-adoption-poll review of draft-andersson-lsp-ping-registries-update
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Aug 2019 13:33:14 -0000

Hi authors,

I'm the designated driver for your draft.

I know this is not last call, but there are a couple of things I think you
should sort out before we go for adoption.

---

This document needs to be Standards Track: it updates two existing Standards
Track documents.

---

Idnits points out...

> -- The draft header indicates that this document updates RFC8029, but the
>     abstract doesn't seem to mention this, which it should.
>
> -- The draft header indicates that this document updates RFC8611, but the
>     abstract doesn't seem to mention this, which it should.

Easy fix such as...

OLD
   This document updates some registries in the LSP Ping IANA name
   space.  The updates are mostly for clarification and to align this
   registry with recent developments.
NEW
   This document updates RFC 8029 and RFC 8611 that define IANA
   registries for MPLS LSP Ping.  The updates are mostly for clarification
   and to align this registry with recent developments.
END

---

Section 1 doesn't mention 8611, and it should. It should also make the
"updates 8029" statement.

OLD
   When RFC 8029 [RFC8029] where published it contained among other
   things updates to the "Multiprotocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" IANA name space
   [IANA-LSP-PING].

   The LSP Ping IANA registries were partly updated to match RFC 8029,
   but the there were some ambiguity in the RFC, that were reflected in
   the registries.

   This document updates two groups of registries.
NEW
   When RFC 8029 [RFC8029] where published it contained among other
   things updates to the "Multiprotocol Label Switching (MPLS) Label
   Switched Paths (LSPs) Ping Parameters" IANA name space
   [IANA-LSP-PING].

   RFC 8126 [RFC8126] updated the LSP Ping IANA registries to match 
   RFC 8029, but there were still some ambiguities, that were
   reflected in the registries.

   This document updates [RFC8029] and [RFC8126] by updating two
   groups of registries.
END

---

Section 3.
Not sure of the value of describing how the registry is now. Anyone who
cares (while reviewing the document) can look at the registries themselves.
And once this becomes an RFC, all you care about is the description of how
the registry is rebuilt.
(You don't have to make this change now).

---

3.1 has

   IETF does not prescribe how the Experimental Use and Private Use sub-
   TLVs are handled; however, if a packet containing a sub-TLV from the
   Experimental Use or Private Use ranges is received by an LSR that
   does not recognize the sub-TLV, an error message MAY be returned if
   the sub-TLV is from the range 31744-32767, and the packet SHOULD be
   silently dropped if it is from the range 64512-65535.

Is this a new normative definition of implementation behaviour? If so, this
document is doing more than updating the registries. That would be OK, but
you'd need to say so up front.

If this is simply a restatement of established fact, then perhaps you don't
need to say it here, but could use a reference. And then you wouldn't need
section 1.1.

---

Some text in Section 4 will be needed, but you can leave that for later if
you like.

---

I think the appendix text should be moved into Section 5. Appendices are
usually non-normative.

---

Thanks,
Adrian