Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

Gregory Mirsky <gregory.mirsky@ericsson.com> Tue, 17 November 2015 15:00 UTC

Return-Path: <gregory.mirsky@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46F591A8BB5; Tue, 17 Nov 2015 07:00:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.201
X-Spam-Level:
X-Spam-Status: No, score=-104.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
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 7k_Aja1VdCkd; Tue, 17 Nov 2015 07:00:22 -0800 (PST)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 369F31A8AFB; Tue, 17 Nov 2015 07:00:22 -0800 (PST)
X-AuditID: c6180641-f792c6d00000686a-3e-564ad2e90aff
Received: from EUSAAHC005.ericsson.se (Unknown_Domain [147.117.188.87]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id C1.93.26730.9E2DA465; Tue, 17 Nov 2015 08:10:33 +0100 (CET)
Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC005.ericsson.se ([147.117.188.87]) with mapi id 14.03.0248.002; Tue, 17 Nov 2015 10:00:20 -0500
From: Gregory Mirsky <gregory.mirsky@ericsson.com>
To: Ben Campbell <ben@nostrum.com>, The IESG <iesg@ietf.org>
Thread-Topic: Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)
Thread-Index: AQHRIOUWp3deIamSYEiyj0Ywbq7xyp6gSaqg
Date: Tue, 17 Nov 2015 15:00:19 +0000
Message-ID: <7347100B5761DC41A166AC17F22DF1122193D907@eusaamb103.ericsson.se>
References: <20151117030721.22342.71025.idtracker@ietfa.amsl.com>
In-Reply-To: <20151117030721.22342.71025.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.11]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGIsWRmVeSWpSXmKPExsUyuXRPuO7LS15hBt9WWVvM7zzNbnH8aqHF tdUHWCxm/JnIbLHu8ik2i1tLV7Ja/F1xhcWB3WPJkp9MHtebrrJ7zNr5hCWAOYrLJiU1J7Ms tUjfLoEr486rv8wFi9QqOk56NTAuUe1i5OSQEDCRaDuxhB3CFpO4cG89WxcjF4eQwBFGifVr jzNDOMsZJbZNuccGUsUmYCTxYmMPWIeIgI3E8oMvwTqYBZ4zSeybtJoFJCEskCWxq3cVE0RR tsT7Xc+BGjiAbCOJRfsTQcIsAqoS+89PApvJK+ArMX/ZNrCZQgKOEgsvHGIFsTkFnCTevjzM CGIzAl33/dQasJHMAuISt57MZ4K4WkBiyZ7zzBC2qMTLx/9YIWwliY+/54OtZRbQlFi/Sx+i VVFiSvdDdoi1ghInZz5hmcAoNgvJ1FkIHbOQdMxC0rGAkWUVI0dpcWpZbrqR4SZGYGwdk2Bz 3MG44JPlIUYBDkYlHt4P8V5hQqyJZcWVuYcYJTiYlUR4Oa28w4R4UxIrq1KL8uOLSnNSiw8x SnOwKInzzptxP1RIID2xJDU7NbUgtQgmy8TBKdXAWHry1NsJehvZxXdkvj7xpFh8n9IxhmMH t9rwWFY4aO0Rm3muRdHu5dQ/cpk1jddNKlds/yfovCzl28Pq5w/FN/ZMeGq0l3VPU9GPJukj DRP9dGYo+79ulXniwuYS1zSNX4fFK8pp+cK6oIKjArvZdwn8ETL02KgsV7m3uezDqvbIre+c 9i02UWIpzkg01GIuKk4EAL0I4eapAgAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/O0nL7MRibfKGJ-5mbN2mbw2xLC4>
Cc: "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf.all@ietf.org" <draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf.all@ietf.org>, "draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@ietf.org" <draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@ietf.org>, "rcallon@juniper.net" <rcallon@juniper.net>, "mpls-chairs@ietf.org" <mpls-chairs@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 17 Nov 2015 15:00:24 -0000

Hi Ben,
thank you for your thorough review and thoughtful comments. Please find my responses and proposed changes in-line and tagged GIM.

	Regards,
		Greg

-----Original Message-----
From: Ben Campbell [mailto:ben@nostrum.com] 
Sent: Monday, November 16, 2015 7:07 PM
To: The IESG
Cc: draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@ietf.org; draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf.all@ietf.org; mpls-chairs@ietf.org; rcallon@juniper.net; mpls@ietf.org
Subject: Ben Campbell's No Objection on draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: (with COMMENT)

Ben Campbell has entered the following ballot position for
draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf-15: No Objection

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I have one minor (almost trivial) comment/question, and several nits:

Comment:
=========
- 4.1, paragraph 3:
Is it reasonable for a TLV in this standards-action registry to be have sub-tlvs with reduced registration requirements?  (And if so, is there a reason to exclude specifications that are not RFCs?)
GIM>> Yes. This is how it is done for all standard track registry TLVs for the entire LSP ping.
And yes we want RFCs to define the sub-TLVs (if the come out of the Specification need range) just because they go into a standard track specified TLV.

Nits:
====
-1, paragraph 1:
Missing "the" before "MPLS Transport Profile "
GIM>> Thank you, added.

- 1.0, last paragraph, last two sentences:
Who are “we” in these sentences? Does it make sense to talk about what “we” are or are not “configuring”?
GIM>> Indeed, re-worded as:
   It should be noted that this document does not specify how to configure on-
   demand throughput estimates based on saturating the connection as
   defined in [RFC6371].  Rather, only how to enable the estimation of
   the current throughput based on loss measurements.

2.1.1, first bullet in first list:
consider s/"both sides should be"/"both sides are"
GIM>> Agree, accepted.

-4.1, 2nd paragraph, first sentence:
Missing words? (What is IANA requested to do with the TLV? I assume register it. Also, what is the name of the new TLV?
Consider a cross-reference to table to for "this sub-registry"
GIM>> I think that missing are "to allocate" and the name of the TLV " MPLS OAM Functions":
   IANA is requested to allocate a new MPLS OAM Functions TLV from the
   standards action range (0-16383) and sub-TLVs as follows from sub-
   registry presented in Table 1, called "Sub-TLVs for TLV [TBA1]".

-4.2: "Assignments of bit positions 0 through 31"
If I read correctly, that's all the bits. Is this the same as saying the registry itself requires standards-action?
GIM>> Yes, the whole range is under standard-action allocation policy.

-5:
It's mildly odd to find the acknowledgements section between two substantive sections.
GIM>> Thank you, moved it.

-6, first paragraph:
Should "liveliness" be "liveness"?
GIM>> Yes, we're not checking its vitality.