[mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01

Adrian Farrel <adrian@olddog.co.uk> Wed, 01 April 2020 17:06 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 E60AF3A13AC; Wed, 1 Apr 2020 10:06:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.895
X-Spam-Level:
X-Spam-Status: No, score=-1.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MAY_BE_FORGED=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, 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 xboknTZ_1-g8; Wed, 1 Apr 2020 10:06:49 -0700 (PDT)
Received: from mta6.iomartmail.com (mta6.iomartmail.com [62.128.193.156]) (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 383F53A13A7; Wed, 1 Apr 2020 10:06:48 -0700 (PDT)
Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta6.iomartmail.com (8.14.4/8.14.4) with ESMTP id 031H6kfc006581; Wed, 1 Apr 2020 18:06:46 +0100
Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id C336D2203C; Wed, 1 Apr 2020 18:06:46 +0100 (BST)
Received: from asmtp3.iomartmail.com (unknown [10.12.10.224]) by vs3.iomartmail.com (Postfix) with ESMTPS id ADC332203D; Wed, 1 Apr 2020 18:06:46 +0100 (BST)
Received: from LAPTOPK7AS653V (81-174-206-152.bbplus.pte-ag2.dyn.plus.net [81.174.206.152] (may be forged)) (authenticated bits=0) by asmtp3.iomartmail.com (8.14.4/8.14.4) with ESMTP id 031H6j3N015844 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 1 Apr 2020 18:06:46 +0100
Reply-To: adrian@olddog.co.uk
From: Adrian Farrel <adrian@olddog.co.uk>
To: draft-ietf-mpls-lsp-ping-registries-update@ietf.org
Cc: mpls@ietf.org
Date: Wed, 01 Apr 2020 18:06:45 +0100
Organization: Old Dog Consulting
Message-ID: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Content-Language: en-gb
Thread-Index: AdYIR9J7mClFBWOaQoqHGGT02ONvpA==
X-Originating-IP: 81.174.206.152
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-25328.001
X-TM-AS-Result: No--14.755-10.0-31-10
X-imss-scan-details: No--14.755-10.0-31-10
X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-25328.001
X-TMASE-Result: 10--14.755000-10.000000
X-TMASE-MatchedRID: 7JAi/59+m5r5uyvfNjfPT3FPUrVDm6jt4NNiN6MhlPBKDy5+nmfdPi1M HnltY21Ox2BzlZpGzx63ZrLmSuAyDgGdFZ6mVeZBTvKpZzlxUs8vVDkwJq9QCAbYcy9YQl6efj+ TWTS/RbDQGJiqsMGMHrQc5DCOw3yNYeOFZSwS7nTJ/bVh4iw9hg9Mm+1DE1vOy5JfHvVu9Ism8v N2YrewSsYL0svrRnOUqcwVjSNTEBvtSLKqBxR9ZXMRkHzmR6yHcDE+oNxhOFD+7KZICEbEsvI8k vclw7r9BKruPSAvtRKQMp5P10RFe2JZXQNDzktSCmEn+y8Sa8Zlu8AJBkPNME+86maMM3aStApi 5PiRGDo4Y1TGtqUm9CMc2ott4KOcopj+MJJi6hSvJmjb249RXjH+T3YvtHy2mHjEz2gByy0EYFi zlg3DwzKqjQMJSwhd/StNdQuGxIfuxoIYPSP14Lrbxxduc6FPcgUuM/TfAYxz1vqdMzrPw1Whvk HN/Hkcs0ybruRrgHUOjHEoV3dzapN/i/+M0xRDbBMSu4v05tNpv5k9epk1AgytGucsJkSa2wREP 4ORcRgLPSx0FMCTDVcR/Zh004Z27a5dyb9gTlsBnSWdyp4eob/I3arxTrviGFuT8Dlyd8tOzKQY s+5RjtAbTu4Y+b2NMrJENq9fGfO+jtOFdba6ScmR5yDJkPg4zPMyzZ3J7JVemWwoCXDj9XoKkRt lWKdw3+flGq44CU3YfjaXLOolwlsxOQwlwyavcI7vRACwF0LLRD51bz5RZDEPpsUuRPfIjQb0Zi jHcXBNt11UYtfapNzGhFBWo8SYW2me7a7nTFOeAiCmPx4NwLTrdaH1ZWqCii7lXaIcF/Ww7M6dy uYKg46HM5rqDwqtFtlUsmpqM5PJTT0V//9UyFaVQohs6nttw1eUHkrmJfBSMpOBoKvSlg==
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/MqF_0Br59BHaCRn2J-0qesnBXYs>
Subject: [mpls] Review of draft-ietf-mpls-lsp-ping-registries-update-01
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: Wed, 01 Apr 2020 17:06:52 -0000

Hi all,

As document shepherd I have done another review of this document to see
whether it is ready for working group last call as the authors have 
asked to progress the draft.

Sadly, I don't think this document is ready. The ideas have crystallised
fine, but the write-up here is lacking.

I have a number of small editorials and some larger questions and issues
set out below. I also have one question that has broader scope:

For [IANA-MT] and [IANA-Sub-6] you now have both 'Private Use' and
'Experimental Use'. I struggle to see how this makes sense. The uses
decribed in RFC 8126 are sufficiently similar that it is unusual to
have both categories defined for a single registry. I don't see anything
in the descriptive text in this document that makes clear why you need
both categories and how an implementation would decide which range to
select a code point from.

If we can clean up all these points, the document may be ready.

Best,
Adrian

==

Abstract

s/.././

--

Abstract

"The updates are mostly..."
Text like this always makes me ask, "What about the rest?"

--

All section heading should use capitalisation

--

1.

d/among other things/

--

1.

   RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
   8029, but the registrations can be further clarified and their
   definitions more precise.

Maybe...

   RFC 8611 [RFC8611] updated the LSP Ping IANA registries to match RFC
   8029.  This document further clarifies the entries in those
   registries and makes the definitions more precise.

--

1.

   This document updates RFC 8029 [[RFC8029] and RFC 8611 [RFC8611] by
   updating two groups of registries.

Maybe...

   This document updates RFC 8029 [RFC8029] and RFC 8611 [RFC8611] by
   updating two groups of registries as follows:

--

1.

   First the registries for Message Types [IANA-MT], Reply Modes
   [IANA-RM] and Return Codes [IANA-RC].  The changes to these
   registries are minor.

NEW

   First, the registries for Message Types [IANA-MT], Reply Modes
   [IANA-RM], and Return Codes [IANA-RC] are updated.  The changes to
   these registries are minor.

--

2.

OLD

   o  a small set of code points (4 code points) for experimental use is
      added, actually they are take from the range for "Private Use".

NOTE
The code points are not taken from the range for "Private Use". Rather,
the "Private Use" range is reduced. So...

NEW

   o  a small set of code points (4 code points) for Experimental Use is
      added by reducing the range for "Private Use".

--

2.

   o  In the listing of assignments the term "Vendor Private Use" is
      changed to "Private Use"

I'd move this to the top of the list so that the term "Private Use" has
context when it is used in other bullets.

--

3.

I'm not sure that the text in the base section (i.e., before 3.1) adds
to the document.

--

3.1 first two bullets

s/requires/require/
s/the/they/

However, how I don't see how these bullets belong in this document. What 
do the processing rules have to do with the IANA registries? The
paragraph immediately after the bullets would seem to be enough.

But then I got to Section 4 and discovered that you are also changing 
the use of terminology around mandatory/optional. This goes further 
than the name of the document, the first sentence of the Abstract, and
the whole of the Introduction. So, I think you need to work out what
the document is intended to do (fix the registries, or fix the 
registries *and* fix the descriptions of how parameters are used) and
then clarify the document accordingly.

--

3.1

   Each of the blocks have code point spaces with the following
s/have/has/

--

   The range of each TLV and sub-TLV registry is divided into to blocks,
   one with a range from 0 to 49161 for TLVs and sub-TLVs that require a
   response if not recognized.  Another block in the range from 49161 to
   65535, this block is for TLVs and sub-TLVs that may be silently
   dropped if not recognized.

Are you sure that 49161 shouldn't read 32767 and 32768 in the two cases
here?

s/into to/into two/

--

3.1.1

s/Expereimetal USe/Experimental Use/
s/Privagte/Private/

--

3.1.1

   Unrecognized TLVs and sub-TLVs for Expereimetal USe and Privagte Use
   are handled as any other unrecognised TLV or sub-TLV.

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (37144-37147) or from the Private Use range (31748-32767) a
      the Return Code of 2 ("One or more of the TLVs was not
      understood") will be sent in the echo response.

   o  If the unrecognized TLV or sub-TLV is from the Experimental Use
      range (64512-64515) or from the Private Use range (64515-65535)
      the TLVs SHOULD be silently ignored.

   IETF does not prescribe how recognized or unrecognized Experimental
   Use and Private Use TLVs and sub-TLVs are handled in experimental or
   private networks, that is up to the agency running the experiment or
   the private network.  The statement above relates to how standard
   compliant implementations will treat the unrecognized TLVs and sub-
   TLVs from these ranges.

Firstly, just like the issue with section 3.1, I think you should just
focus on the IANA considerations.

Secondly, this final paragraph seems to say something that may go 
beyond what is in the base RFCs and is an update beyond simply a change
to the IANA section.

But, you could boil this down to a simplified statement of: there are
two sets of ranges, one for "send error if not recognised" and one for
"silently ignore if not recognised". If you do that, then the contents
of 3.1.1 would collapse into 3.1.

--

3.2

OLD
   This section lists the changes to each MPLS LSP Ping Registry, in
   Section 6.1, Section 6.2 and Section 6.3 the changes are detailed and
   it is shown what the IANA registry version of the registration
   procedures and assignments would look like.
NEW
   This section lists the changes to each MPLS LSP Ping Registry.  
   Section 6.1, Section 6.2 and Section 6.3 set out how the new 
   versions of the IANA registries should look, together with the
   registration procedures.

--

3.2.1 

Many of the same issues as shown for Section 2

--

4.

s/ths/that/

--

4.1

s/is nows/is now/

--

4.1

This was presumably a problem in 8029, but perhaps we can fix it here.
You propose...

      TLV and sub-TLV Types greater than or equal to 32768 (i.e., with
      the high-order bit equal to 1) are TLVs and sub-TLVs that SHOULD
      be ignored if the implementation does not understand or support
      them.

You should say under what conditions and how they SHOULD may be varied.
This is probably...

     , but such implementations MAY choose to send an error as it 
     would have done if the high-order bit had been clear.

--

4.1.1 

s/Comments to this changes/Comments to these changes/

s/change in two/changed in two/

--

I stumbled over section 4.1.1. It claims to provide comments on the 
changes and provides three numbered bullet points:
1. This doesn't describe a change
2. This describes two changes
3. Does describe a change, but the text is not clear that it describes
   a change.

--

There is load of duplication in this document because you have:
- some repetition of text from existing RFCs
- duplication between sections describing how the text should look and
  section 6 that instructs IANA

I think you could have trimmed this substantially by:
- simply pointing at the relevant section of the updated RFC
- explaining what you want to change
- pointing at the relevant piece of section 6 for the new text

Result:
- shorter draft
- less scope for errors

--

The whole of section 4.2 (including 4.2.1) says "changes aligned with
the rest of this document" but doesn't actually say what the changes
are.

--

4.2.1

s/tu return am/to return an/
s/ir only/only/

However, that whole paragraph seems to be missing meaning.

--

5.

   This document only updates IANA registries, not how the code-points
   in the registries are used.  This should not create any new threats.

The first sentence seems to be false. That is, you are also updating the
terminology to clarify the rules about when a TLV or sub-TLV can be
ignored if it is not understood.

However, this is a good thing for security because it makes it more 
likely that implementations will be consistent and harder to attack.

--

6. It would be really nice if the whole of section 6 could refer to
registries using precise names (probably in quotes). You want IANA to
be easily able to find the right registries.

--

6.

   IANA is requested to update the LSP Ping name space as described in
   this document and documented in the Appendixies.

What Appendixies?

--

6.1

The captions for the tables are at best confusing, but probably wrong.

--

6.2

Consistent with the comment for section 6, this whole section is very
confusing! Are you actually asking IANA to do anything in this section?

--

In section 6.3, I can't parse what you asking IANA to do.