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

Martin Thomson <> Tue, 31 January 2012 01:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D2E5B21F861D for <>; Mon, 30 Jan 2012 17:00:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.474
X-Spam-Status: No, score=-4.474 tagged_above=-999 required=5 tests=[AWL=-0.875, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mXi+98mcZ-pm for <>; Mon, 30 Jan 2012 17:00:48 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 94EF521F85E5 for <>; Mon, 30 Jan 2012 17:00:47 -0800 (PST)
Received: by bkbzt4 with SMTP id zt4so4088767bkb.31 for <>; Mon, 30 Jan 2012 17:00:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=JfDOmBh+4fku0eskmdQLMLUBAF5SQ6vG6NCIxY6TW64=; b=kqZJQm9oAnON2n27e2y0kY/THsvErnKQW1J2J7N8ne84LPb3fn4xDH8CHNsKlMHU/q XOxKDRBVR7dZlLKRAMtBKUTyuJyD1ezBovr6MHX7JnIWIKAc/x0xxhLWMGRlh+n43Jwu v8mI77kyshl1UYk3EblrV9EACoL9tFNvx8kJk=
MIME-Version: 1.0
Received: by with SMTP id h24mr9905557bkw.15.1327971646490; Mon, 30 Jan 2012 17:00:46 -0800 (PST)
Received: by with HTTP; Mon, 30 Jan 2012 17:00:46 -0800 (PST)
In-Reply-To: <019d01ccdf97$65fc6fc0$31f54f40$>
References: <019d01ccdf97$65fc6fc0$31f54f40$>
Date: Mon, 30 Jan 2012 17:00:46 -0800
Message-ID: <>
From: Martin Thomson <>
To: Daniel King <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc:,,,, "Ryoo, Jeong-dong" <>,,,
Subject: Re: [Gen-art] GenART Review of draft-ietf-mpls-tp-mib-management-overview-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 31 Jan 2012 01:00:49 -0000

Hi Dan,

Looks good to me.  -06 is good to go from my perspective.


On 30 January 2012 13:37, Daniel King <> wrote:
> Dear Martin,
> Thank you for your review of draft-ietf-mpls-tp-mib-management-overview-05. We have endeavoured to address your comments in our new version (06 attached). The comments that had specific actions or required updates are summarised below. If you can email me (us) back to let us know you are happy or unhappy with our updates it would be appreciated.
> MT – Comment 1: 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.
> DK: Ok.
> MT –  Comment 2: 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.
> DK: This OID structure is proposed in draft-ietf-mpls-tp-te-mib-01. We have clarified the text for Section 6 to include “The MPLS-TP MIB OID tree as proposed in [MPLS-TP-TE-MIB] has the following structure:”
> MT – Comment 3:  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.
> DK: Absolutely, where relevant the text now reads “where additional MIB modules are necessary” and/or “A new MIB module is required to”, or equivalent.
> MT – Comment 4: 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.
> DK: We kept the SNMP boilerplate security code for best practice. We felt the existing Security text did not further edits.
> MT – Comment 5: 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.
> DK: Agreed, we expanded on some of the lesser known acronyms (FEC, OID, et al.), but still avoiding expanding the well-known candidates (MPLS, etc.)
> MT – Comment 6: Bullet 5 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 sub-sections.
> DK: Fixed.
> MT – Comment 7: The diagram in Section 4.2.10 didn't help me understand the relationships at all.  The text was much easier to follow.
> DK: Ah, we like it and had positive comments from others so we kept the figure. It is busy but adds value by showing the directional interrelations, the text does enhance. Hopefully once you read the text the figure becomes more useful.
> MT – Comment 8: Some references (RFC6370) need to be updated.
> DK: Fixed.
> Again, thanks for your time and review. Once you send me an echo-response to confirm you are happy with these updates to address the relevant comments, we will format, check against submission tool and then upload the new version.
> Br, Dan.