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

[Martin Thomson <[e-mail]>]

Hi Dan,

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

--Martin

On 30 January 2012 13:37, Daniel King <[e-mail]> 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.