Subject: [mpls] IESG Last Call Comments: draft-ietf-mpls-tp-mib-management-overview

From: "Daniel King" <[email-masked]>
Date: Tue, 31 Jan 2012 10:59:49 -0000

Hi All, 

As you may have just noticed we uploaded a new version (06) of
draft-ietf-mpls-tp-mib-management-overview. This version addresses a few
minor issues and comments received during IESG Last Call. There is no
material change to the document. 

The specific comments and how they were addressed in the 06 version are
summarised below:

Martin Thomson (MT)

Stewart Bryant (SB)

Daniel King (DK)

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. 

SB - Comment 1: Pseudowire does not support forwarding other  than the
nexthop IP address.". This seems to be a general comment on PWs and not a
MIB comment.

DK: Yes, the text has been removed. 

SB - Comment 2: Pseudowire 129 FEC type-2 can be used in non-IP and IP
environments with the required changes.". Again, this seems to be a general
comment on PWs and not a MIB comment.

DK: Again yes, the text has been removed. 

SB - Comment 3: There are lots of cases where you say "a new MIB module
will" Does the text of that module exist or do you mean "a new MIB module
needs to be written that"?

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.

Br, Dan.