[Gen-art] Fwd: GenART review of draft-ietf-mpls-tp-mib-management-overview-05

Martin Thomson <martin.thomson@gmail.com> Sat, 10 December 2011 02:52 UTC

Return-Path: <martin.thomson@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id AAA8021F85F1 for <gen-art@ietfa.amsl.com>; Fri, 9 Dec 2011 18:52:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.666
X-Spam-Status: No, score=-4.666 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id VGOmMtMYzAGc for <gen-art@ietfa.amsl.com>; Fri, 9 Dec 2011 18:52:30 -0800 (PST)
Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id D4FE521F85BB for <gen-art@ietf.org>; Fri, 9 Dec 2011 18:52:29 -0800 (PST)
Received: by bkbzs8 with SMTP id zs8so4112787bkb.31 for <gen-art@ietf.org>; Fri, 09 Dec 2011 18:52:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=bh9DSBiHexYdifar12jpI5d0+K6Q5w30743BrMvPuAI=; b=DPxVJMrnMnhV0WBzxzEVaFNQ0TWyKj/4DB2/P9BHgeQv+c2NgE20jobuK9RvdAREfT ObtzDbZLzvoX2EDzniB1bfp0PpYHGO/BdwWIiXbrOwQAxeKVQFDO2/tPolhIBg4IezQH EzsdwCy1yy5XCVTSsVMa1nEZNXM37+C20rdrs=
MIME-Version: 1.0
Received: by with SMTP id b2mr5433164bka.52.1323485548927; Fri, 09 Dec 2011 18:52:28 -0800 (PST)
Received: by with HTTP; Fri, 9 Dec 2011 18:52:28 -0800 (PST)
In-Reply-To: <CABkgnnV5Acsmi=UXh9qwu4zH77xMcQsDsrF02z_x7URxG9nFiQ@mail.gmail.com>
References: <CABkgnnV5Acsmi=UXh9qwu4zH77xMcQsDsrF02z_x7URxG9nFiQ@mail.gmail.com>
Date: Sat, 10 Dec 2011 13:52:28 +1100
Message-ID: <CABkgnnU67g+DD=1R+xU6QK-FiY6LXqKov+EO1f9-oCH=LXbKTA@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: gen-art@ietf.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: [Gen-art] Fwd: GenART review of draft-ietf-mpls-tp-mib-management-overview-05
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/gen-art>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 10 Dec 2011 02:52:30 -0000

I missed sending this to the gen-art list.

---------- Forwarded message ----------
From: Martin Thomson <martin.thomson@gmail.com>
Date: 7 December 2011 11:46
Subject: GenART review of draft-ietf-mpls-tp-mib-management-overview-05
To: draft-ietf-mpls-tp-mib-management-overview.all@tools.ietf.org

Document: draft-ietf-mpls-tp-mib-management-overview-05
Reviewer: Martin Thomson
Review Date: 2011-12-07
IETF LC End Date: ...
IESG Telechat date: ...

Summary: The document is mostly ready for publication as an
informational RFC, but there are some minor issues that need to be

Major issues: none

Minor issues:

 - It's probably OK for an audience of MPLS & network management
experts, but this document relies heavily on assumed knowledge.  I
found this draft to be nigh on indecipherable.  I have no technical
comments for that reason.

 - Reading through the introduction and gap analysis, it seemed like
the intent of the draft is to outline requirements for MPLS-TP MIBs,
not to describe the additions.  It was a little surprising to see
Section 6 launch straight into a definition of new branches, almost as
if they already exist.

 If this is simply an initial outline, or a plan, or agreed
requirements, then that could be made clearer.  As it is, it reads as
though it were a done deal.  Later parts are clearer about this ("a
new MIB module will be...").  Making this more consistently stated as
requirements, promises or plans there is less confusion about
existence, and fewer problems if the plan changes.

 - If the first paragraph of the security considerations is true, then
this would be great.  And that paragraph is then all that is
necessary.  The later paragraphs don't really add any value.  Truisms
(new MIBs will include security considerations), appeal for SNMPv3,
and a description of access control best practice are not really
needed.  Do these new objects change the dynamics in a way that
requires new operational practices?  I suspect not.

Nits/editorial comments:

 - This document has a very high density of acronyms, as well as other
symbols.  Providing expansions of acronyms on first use (e.g. FEC) and
providing some context for less frequently used symbols would help
casual readers.  With such a high density, it might even be easier to
use expansions by default for less commonly used labels.

 - Section 4.2.6 contains a number of strange, one-bullet lists.  Try
<list style="none"> if the intent is to indent these notes.  If the
intent is that these items are part of a larger list, then try

 - The diagram in Section 4.2.10 didn't help me understand the
relationships at all.  The text was much easier to follow.

 - Some references (RFC6370) need to be updated.