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

[Martin Thomson <[e-mail]>]

I missed sending this to the gen-art list.


---------- Forwarded message ----------
From: Martin Thomson <[e-mail]>
Date: 7 December 2011 11:46
Subject: GenART review of draft-ietf-mpls-tp-mib-management-overview-05
To: [e-mail]


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
addressed.

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
sub-sections.

 - 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.