I missed sending this to the gen-art list. ---------- Forwarded message ---------- From: Martin Thomson 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 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.