Skip to main content

Last Call Review of draft-ietf-mpls-tp-mib-management-overview-
review-ietf-mpls-tp-mib-management-overview-genart-lc-thomson-2011-12-10-00

Request Review of draft-ietf-mpls-tp-mib-management-overview
Requested revision No specific revision (document currently at 08)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2011-12-12
Requested 2011-11-29
Authors Daniel King , Venkatesan Mahalingam
Draft last updated 2011-12-10
Completed reviews Genart Last Call review of -?? by Martin Thomson
Genart Telechat review of -?? by Martin Thomson
Secdir Last Call review of -?? by David McGrew
Assignment Reviewer Martin Thomson
State Completed
Review review-ietf-mpls-tp-mib-management-overview-genart-lc-thomson-2011-12-10
Completed 2011-12-10
review-ietf-mpls-tp-mib-management-overview-genart-lc-thomson-2011-12-10-00
I missed sending this to the gen-art list.


---------- Forwarded message ----------
From: Martin Thomson <martin.thomson at 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 at 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
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.