Hi Dan, Looks good to me. -06 is good to go from my perspective.
--Martin On 30 January 2012 13:37, Daniel King <[email protected]> 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. _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
