[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.
- [mpls] Review of draft-ietf-mpls-lsp-ping-registr… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… tom petch
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Mach Chen
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Carlos Pignataro (cpignata)
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Loa Andersson
- Re: [mpls] Review of draft-ietf-mpls-lsp-ping-reg… Adrian Farrel