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

"Carlos Pignataro (cpignata)" <cpignata@cisco.com> Wed, 01 April 2020 17:57 UTC

Return-Path: <cpignata@cisco.com>
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 83C5C3A14AD; Wed, 1 Apr 2020 10:57:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.6
X-Spam-Level:
X-Spam-Status: No, score=-9.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=NSjJs70W; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=srA0ZhmV
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 dfYRjT8schHF; Wed, 1 Apr 2020 10:57:33 -0700 (PDT)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F5B83A14AE; Wed, 1 Apr 2020 10:57:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=14234; q=dns/txt; s=iport; t=1585763853; x=1586973453; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=NSjJs70Wf/thcopc0aWwrE61IxnTTjZBu8TQ9ODG17WfxSgTTqNnG2Ni jzloc8A9T9keWTBmkuxUDcTsFrwU9vRtozv09HYI+KzccqdF0ABgAvIiW szdMNsDTUKCKzgd4xDeNwjmiSUpRyBApH3c9XnJP9mCMXMDvCaIDyDFRd 4=;
IronPort-PHdr: 9a23:zyAcyRcg/cJxmNhVX80pq9eulGMj4e+mNxMJ6pchl7NFe7ii+JKnJkHE+PFxlwGQD57D5adCjOzb++D7VGoM7IzJkUhKcYcEFnpnwd4TgxRmBceEDUPhK/u/ZDQ7E8JLSFZN9HCgOk8TE8H7NBXf
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CYBQCX1YRe/49dJa1gBhwBAQEBAQcBAREBBAQBAYF7gVRQBYFEIAQLKgqEEINFA4pvgjolmB2CUgNUCgEBAQwBAS0CBAEBhEQCF4IhJDgTAgMBAQsBAQUBAQECAQUEbYVWDIVxAQEBAgESEREMAQE3AQQLAgEGAhoCJgICAjAVEAEBBA4FIoMEgkwDDiABkyqQZwKBOYhidYEygn8BAQWFKRiCDAmBDiqJZYJMGoFBP4EQAScMFIFPfj6EPg8YgnsygiyOBzWCSIYiigqPVAqCPY1EiVwdgkyNDIwakHmXB4M1AgQCBAUCDgEBBYFpIoFYcBU7KgGCQT4SGA2OHYNzilV0gSmMfAGBDwEB
X-IronPort-AV: E=Sophos;i="5.72,332,1580774400"; d="scan'208";a="456578777"
Received: from rcdn-core-7.cisco.com ([173.37.93.143]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 01 Apr 2020 17:57:32 +0000
Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-7.cisco.com (8.15.2/8.15.2) with ESMTPS id 031HvWbi023434 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 1 Apr 2020 17:57:32 GMT
Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 12:57:32 -0500
Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Wed, 1 Apr 2020 13:57:31 -0400
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Wed, 1 Apr 2020 12:57:30 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Hjc811mn+pLdrZrgzYnGKA7QYZQYrVmbrVmIe9+hVgdkMUO7VF7A9MHakBdZf5JcW/DSaLl0qkaeMdBf3kGyiBy+eBBmsvmtCfRiEPQ262jpafwogA2sZdcwiMycV8eQ09ZAmp2hUuITBMFzp11K9ajP/M8WaD2PQTDdIFCKG91s/pH7IHn/ZFs299jtTkXnXcni01YBAPxDElYKMYPPLmC/sRft0xhLwOU1dVnw1P4TTL6iQOvkDi26VHf8P0/JKceCt2eKQUxXgM+NHeLaSu4Bgeokzga4W5iJoATjRlZLnCKTv2qnAagYAayoljfFCTsAWuefIBTqlKmS+TWLBg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=jO5/cXSWCJ53zFXcX88ffgAiUXRGAhmRInZVg01TxJbDsBp613SOAHj2We8eJdah6wUQhXt+Mgyg1bdtqqLEzQVb0HStXnuRmtIRkCcm/2Gcz4i+jwbtNBXfNDCTCRNbo+TY9XqmwWXoFZsxPwQNECQTEmYkW7EALHNPgTNfdC0MpekMisqR3KmiUPnEyzkmrWW+68L01lSw/ABgSE6n6Hx1tJds7X8OzhhgJ7VZ3ZnTUtnNjGbobmvs/Av4HG9IJ7RcEtu24TtMxVNQW3pM9dg8Cjvob6/izDcSuw1Xjax1/yo975CeauwYrAxGpCEtvbyiOclxf9386AJKemzfYw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=T+EQ90kuZbDxzfn6e4DNGrEDfaVkp0FPj31g2CdL5dE=; b=srA0ZhmViNdHoa2psQCgie5OmNug6SIeuSqyqWVwAIFYnDku5Q/3KUV6S2zzrVGH0e9iqi2aSM0i5ufVhuiMM8fQ6P6ESpmSnP4tef+xVTYSxTevEwzKIRZUKFNAnZDhUQqipTy3hEcK47Zzsq2FvWVSGRiuls74TYX7MziMGnY=
Received: from BN8PR11MB3635.namprd11.prod.outlook.com (2603:10b6:408:86::20) by BN8PR11MB3843.namprd11.prod.outlook.com (2603:10b6:408:88::29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2856.19; Wed, 1 Apr 2020 17:57:30 +0000
Received: from BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74]) by BN8PR11MB3635.namprd11.prod.outlook.com ([fe80::2c08:cdcf:fc41:fe74%7]) with mapi id 15.20.2856.019; Wed, 1 Apr 2020 17:57:30 +0000
From: "Carlos Pignataro (cpignata)" <cpignata@cisco.com>
To: Adrian Farrel <adrian@olddog.co.uk>
CC: "draft-ietf-mpls-lsp-ping-registries-update@ietf.org" <draft-ietf-mpls-lsp-ping-registries-update@ietf.org>, mpls <mpls@ietf.org>
Thread-Topic: Review of draft-ietf-mpls-lsp-ping-registries-update-01
Thread-Index: AdYIR9J7mClFBWOaQoqHGGT02ONvpAABy9UA
Date: Wed, 01 Apr 2020 17:57:30 +0000
Message-ID: <C56BE1EF-230A-4430-BAEF-6453F99D22BA@cisco.com>
References: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
In-Reply-To: <0f5701d60847$ed2a2230$c77e6690$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-mailer: Apple Mail (2.3608.80.23.2.2)
authentication-results: spf=none (sender IP is ) smtp.mailfrom=cpignata@cisco.com;
x-originating-ip: [108.203.7.63]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 0468f2db-54c4-4cd7-0246-08d7d6662591
x-ms-traffictypediagnostic: BN8PR11MB3843:
x-microsoft-antispam-prvs: <BN8PR11MB3843C65022A29D021BE636DDC7C90@BN8PR11MB3843.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 03607C04F0
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN8PR11MB3635.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(10009020)(4636009)(376002)(346002)(396003)(39860400002)(366004)(136003)(6916009)(26005)(81156014)(2616005)(5660300002)(91956017)(2906002)(186003)(8676002)(81166006)(8936002)(76116006)(36756003)(66946007)(66476007)(86362001)(6486002)(6506007)(15650500001)(33656002)(478600001)(71200400001)(66446008)(4326008)(64756008)(66556008)(316002)(54906003)(6512007); DIR:OUT; SFP:1101;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: EsH317/S5qz8S0lvhZpL2I99YH7DyIiw7XmEHTAlI6X27iHSXusB1gdsupO8EtnqtnY/mpEuSfLIM/oMbXg5YjENQtbYsfPWdRJ4FfSgTRAaCyHHzhW49/7EPCf278hJRJakKH9FL2vyN1GuP0XnOp6uoCoDVbOmFcvwFGgnoQsffmpanN2Fy07SU39meVSu4ni919vzebyXDfYGTc/oGUfIxSA1sEUDx3FsmRFxayd5b0LZwlssqTjCoXHVSZBxFBls17GTVFdGmr1rz2AuwoaF8wn1ihF8lxxciqgn6dhEjBYSwLUJ43HvWWDJUlsDRl5p1pUO3BqE4FT3Js2VVHgyC2U5JRnuvexkemflMUGo8GBnpOB3idTJsoYHt7Uy7pMAIQa6T5ejHdx+GhVup7r1d704QX8qEDJa5xSzHHhwAYVYw5Gxb1P5xjR41wnt
x-ms-exchange-antispam-messagedata: 2WN9Oqmytuah2X/Wt0XEr8OHqltWoKMl89pA6TvTUSdWENcdRdCJcSTNCXXM7SUcTTd+9QDhkAsyyFV1RXEW1O6ap2808q90j1u/RAP6fBf2gS1HU5zjmXlopGJU1UwZMoAXqus7I8c7Ke4iPb6xUQ==
x-ms-exchange-transport-forked: True
Content-Type: text/plain; charset="utf-8"
Content-ID: <C77DFD421DCE724C94ECE7A6D38FC909@namprd11.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 0468f2db-54c4-4cd7-0246-08d7d6662591
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Apr 2020 17:57:30.0573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: ZXYX7Ux6XulkJeJAFeIbLDSifGVn9KQwuB3Xfzup/uZEnNOR9qitqVW2S+8Cto0ce3HEaW6wgWeAMKstWrbJWQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3843
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com
X-Outbound-Node: rcdn-core-7.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/6Hf_YOPUGwvhgpklgZsyra2_uMU>
Subject: Re: [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:57:37 -0000

Thanks Adrian for the thorough review and great comments!

On your broader-scope question, I see the difference in definition of private-use versus experimental-use, but I tend to agree with you that for this use case they are overlapping in intent or need.

My view would be to keep only Experimental Use.

Thanks,

Carlos.

> 2020/04/01 午後1:06、Adrian Farrel <adrian@olddog.co.uk>のメール:
> 
> 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.
>