[mpls] Last call review of draft-ietf-mpls-tp-linear-protection-mib

"Adrian Farrel" <adrian@olddog.co.uk> Sat, 14 January 2017 17:08 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 CE28212A0C0; Sat, 14 Jan 2017 09:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 OJ--FTjbAC6N; Sat, 14 Jan 2017 09:08:07 -0800 (PST)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 96BCE12A0C4; Sat, 14 Jan 2017 09:08:01 -0800 (PST)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0EH7x2b017085; Sat, 14 Jan 2017 17:07:59 GMT
Received: from 950129200 ([176.241.250.4]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id v0EH7m4C017004 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2017 17:07:59 GMT
From: Adrian Farrel <adrian@olddog.co.uk>
To: ietf@ietf.org
Date: Sat, 14 Jan 2017 17:07:49 -0000
Message-ID: <004201d26e88$c37e07f0$4a7a17d0$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdJugVsLBP8DchTISie/ojREL//caA==
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22824.001
X-TM-AS-Result: No--13.092-10.0-31-10
X-imss-scan-details: No--13.092-10.0-31-10
X-TMASE-MatchedRID: jD4+AQXjm3zMXKkorvNQjsqXjImgj58bbv16+gil4jf2UNhppzjER7T+ vCWGCAAPk/7JXJ5e1BE8CyC5jWhXvI5S/4bo68NblVHM/F6YkvRezmeoa8MJ8xn7x7Zy0SLbmFE FjFn5VadqghzTcWeyLuj664Z1pS2O8ZTibkDR5X0ER9Ta+6BEXeAe2rni5lNAaxNXOJgeVJp/TF Ft56DIJkZyZf80rDzOUerO/uppCBwCxXFtgZVFF2lHv4vQHqYTh8Ytn75ClDNMOjKUxCZwr4qji 64B5sMVDNbgKEt9XPOe3X7K4hm1cUVcCiEXy80m3FqOVb7PDEJbdOqDH81KSkUNHQAoZf5cq2W3 sbHBcj5jP65bm9TzdOSRITh6/Ry528kC8Kr7AslsG7r4Qh7N3JnaxzJFBx6vX15NJHwjp275rwp k9127wHqqxcrRKideg2wrNlNyRDJdleeOihB1yEbKkLkJUU4fK9jw4MDFmyLqLnOUXH9QdCxfY2 8bytftQ71PeJfaR59wAmPLPyh9LvMdlDwM7h+HsyNb+yeIRApAq6/y5AEOOhTS71t+rmPI+rEc9 YP7ZaPi8zVgXoAltlwtzewu2M63Ahqkxqay+5fdB/CxWTRRu25FeHtsUoHufZGq9IXnpBc9/Lq9 66tkLeUDcK0VAKukMeVSww3VrXE+kK598Yf3Mg==
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/7k0MFBAfNBT_sovM7Xo8Ldz18dk>
Cc: mpls@ietf.org, draft-ietf-mpls-tp-linear-protection-mib@ietf.org
Subject: [mpls] Last call review of draft-ietf-mpls-tp-linear-protection-mib
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
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: Sat, 14 Jan 2017 17:08:10 -0000

> The IESG has received a request from the Multiprotocol Label Switching WG
> (mpls) to consider the following document:
> - 'MPLS Transport Profile Linear Protection MIB'
>  <draft-ietf-mpls-tp-linear-protection-mib-11.txt> as Proposed Standard
>
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action. Please send substantive comments to the
> ietf@ietf.org mailing lists by 2017-01-26. Exceptionally, comments may be
> sent to iesg@ietf.org instead. In either case, please retain the
> beginning of the Subject line to allow automated sorting.

I have reviewed the -11 version of this document. It is well written and
clear to read. I particularly welcome the explanations of the various
objects.

Here are a very few minor points and some nits.

I think the document is ready to proceed to publication.

Thanks,
Adrian

===

Section 1 concludes with

   Although the example
   described in Section 7 specify means to configure OAM identifiers for
   MPLS-TP tunnels, this should be seen as indicating how the MIB values
   would be returned in the specified circumstances having been
   configured by alternative means.

Two thoughts:

1. This text needs to be repeated in Section 7

2. This would read better as:
 
   Although the example
   described in Section 7 shows a way to configure OAM identifiers for
   MPLS-TP tunnels, this also indicates how the MIB values would be
   returned if they had been configured by alternative means.
 
---

Section 4.

The first sentence is a little hard to read...

   RFC 6378 [RFC6378] defines the protocol to provide a linear
   protection switching mechanism for MPLS-TP with protection domain as
   a point-to-point LSP.

Looking at section 1.1. of RFC 6378, I think you could write...

   RFC 6378 [RFC6378] defines the protocol to provide a linear
   protection switching mechanism for MPLS-TP for a point-to-point LSP
   within the protection domain bounded by the end points of the LSP.

---

Is Section 5.1 too terse? Maybe a two line explanation of each new TC?

---

Please have a quick check to see whether sometimes when you say "this
MIB" you mean "this MIB module" (etc., for other uses of "MIB").

For example the Description clause of mplsLpsNotificationEnable
         "Provides the ability to enable and disable notifications
          defined in this MIB.

---

It is a little odd that MplsLpsReq has a syntax of
OCTET STRING (SIZE (2)), a display hint of "1d", and you list the
potential values in binary.

I should think that the values should be listed in decimal as they
are shown in RFC6378 and RFC7271.

Then it is just a question of whether this should be a text string or
an integer, which probably doesn't matter, but if your keep it as a
octet string, you do need to say how the numbers are encoded (presumably
ASCII?).

---

For MplsLpsFpathPath why do you say...
  Bits are numbered from left to right.
...I don't see any reference to bits.

---

mplsLpsConfigSdBadSeconds and mplsLpsConfigSdGoodSeconds could use a
Units clause (although it should be pretty obvious from the name and
description!)

---

Is there a reason why you used
      SYNTAX     INTEGER {true (1), false (2)}
instead of TruthValue in
   mplsLpsStatusRevertiveMismatch
   mplsLpsStatusProtecTypeMismatch
   mplsLpsStatusCapabilitiesMismatch
   mplsLpsStatusPathConfigMismatch OBJECT-TYPE

---

   mplsLpsStatusPathConfigMismatch OBJECT-TYPE
      SYNTAX     INTEGER {true (1), falsmplsOamIdMeMpIndexNexte (2)}

Looks like a typo although it will compile :-)

===

Nits
---
Section 1
s/read- write/read-write/
s/document is consistent/document are consistent/
---
Section 4
s/alternate/alternative/
---
Section 5.3
s/failures of linear protection/failures of the linear protection/
---
mplsLpsMeStatusTable
s/liear/linear/