Hi Tom, That would be very much appreciated. Text or word with embedded comments or suggestions is good. If you prefer other way, that is fine as well.
cheers -sam > On Dec 11, 2014, at 7:11 PM, Tom Taylor <[email protected]> wrote: > > I suppose I could have a look at the grammar. What format would I use to > convey suggested changes? > > Tom Taylor > > On 11/12/2014 3:41 PM, Sam K. Aldrin wrote: >> Hi Elwyn, >> >> Thanks for the review and comments. >> Please find the responses inline. >>> On Dec 11, 2014, at 10:36 AM, Elwyn Davies <[email protected]> wrote: >>> >>> I am the assigned Gen-ART reviewer for this draft. For background on >>> Gen-ART, please see the FAQ at >>> >>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >>> >>> Please resolve these comments along with any other Last Call comments >>> you may receive. >>> >>> Document: draft-ietf-mpls-tp-te-mib-09.txt >>> Reviewer: Elwyn Davies >>> Review Date: 10 December 2014 >>> IETF LC End Date: 8 December 2014 >>> IESG Telechat date: (if known) - >>> >>> >>> Summary: >>> Not ready. I am not a MIB expert nor an MPLS(-TP) configuration expert, >>> so I have >>> assumed that the details of the MIB specification have been addressed by >>> Joan's MIB Doctor review and the configuration examples have been checked >>> by an >>> MPLS-TP expert. However, the introductory text needs significant work to >>> make it >>> easier for people who are not MPLS-TP experts to come to grips with the >>> document. >> This MIB is intended to be used for MPLS-TP tunnels and is done by the way >> of extending existing MPLS-TE MIB. The assumption is that reader is already >> aware of MPLS-TP. Hence we didn’t provide a primer for MPLS-TP in this MIB >> and I am not sure if it is the right place either. >>> >>> The major issue with this document is that it appears to go against the >>> current IETF view >>> that SNMP is not a satisfactory solution for configuring networks. The >>> document has >>> effectively reiterated the RFC 3812 situation from 10 years ago when the >>> IETF held its nose >>> and said that SNMP was the only game in town even if security sucked. As >>> I mention below, this was extensively discussed a year ago but I couldn't >>> determine whether this draft was given >>> a special dispensation even though consensus seemed to be that writeable >>> MIBs were >>> considered inappropriate. If this is the case, it will be sufficient to >>> adapt the end of s1. >> We have deliberated over this topic for more than two years and after >> multiple discussions along with Routing AD and OPS AD, we decided to go >> forward with the writable objects for this MIB. Additionally we added a >> small paragraph at the end of s1, as recommended, the reason for doing so. >>> >>> AFAICS this draft has not had the 'grammar review' recommended by its AD >>> about a year >>> ago and there are a number of areas in the object descriptions where >>> language >>> improvements would be desirable in addition to notes given here. That is it >>> still needs >>> the grammar review. >> We could take help of English reviewers and request WG chairs to help us out >> in this regard. >>> >>> There are some more minor issues, particularly as regards the description >>> of the types >>> of tunnel in s1, the discussion of the contents of the MIBs in s6 and >>> possibly in regard to >>> the interaction with the standard interface table. >>> >>> >>> Major issues: >>> >>> Support for configuration: >>> The issue of SNMPset (write) support was discussed at length in the context >>> of >>> the MIB doctors' review of v-05 of this draft. The consensus at that time >>> appeared >>> to be that provision of write support in new MIBs should be strongly >>> discouraged. >>> I am unclear what the outcome of that discussion in the context of this >>> draft was, >>> but it is clear that the draft is very much written from the point of using >>> the MIB >>> as a configuration tool, especially in s9 (examples of usage). Whilst this >>> technique >>> reflects the equivalent section is RFC 3813, that document was written over >>> 10 years >>> ago and considerable effort has been devoted to providing alternative and >>> more secure >>> ways of configuring networks in the intervening time. The body of the >>> document has not >>> been altered to reflect the discussion that occurred. >> Whether SNMP write should exist or not discussion is not within the scope of >> this document. Whether this MIB should support writable MIB objects was >> discussed and the conclusion was yes. The text at end of s1 was added as >> recommended by AD’s. On the contrary, if this MIB were to change the way >> RFC3813 is to implemented/interpreted along with the MIB i.e. from writable >> for TE but read-only for non MPLS-TE tunnels, then it should be documented. >> >>> "Lip service" is paid to the discouragement of the use of SNMPset by the >>> addition of >>> para 3 of s1: >>>> It is understood that SNMP SET is not used for MPLS configuration these >>>> days, however the read-write and read-create option is still specified >>>> for some objects as a way to provide the information model. >>> It is not clear to me why providing read-write or read-create options >>> enhance the >>> MIB or are "a way to provide the information model". >>> >>> I note that despite the extensive discussion of this topic by WG members >>> and MIB specialists >>> back in December 2013, this issue was not flagged up in the Shepherd's >>> write up. >>> >>> If it has now been agreed that the configuration "flavour" is to be >>> accepted as WG consensus >>> in spite of being contrary to current practice, it appears to me that the >>> word "configuration" >>> should be removed from the last sentence of para 2 of s1 and the last para >>> of s1 rewritten to >>> explain why write capabilities are used in a more convincing manner. >> As noted above, the write option was retained after discussing at length, >> both at the WG sessions and over emails. The statement in last part of s1 >> was added as per the advice we received to move forward with the writable >> objects [ref: email from OPS AD dated Mar 11 on MPLS mailing list]. The main >> reason for writable objects, is because the MPLS-TE had writable objects and >> MPLS-TP extensions leverage this existing MIB and also few vendors have >> implemented them. >> >> Having said that, we are open to any suggested text, in addition to the one, >> which you already did below, in regards to ‘writable’ objects. >>> >>> Minor issues: >>> Abstract/s1: Needs to be clear in both places that is is intended for >>> MPLS-TP, this: >>> -- Abstract and s1: s/transport networks./MPLS networks conforming to the >>> MPLS Transport Profile (MPLS-TP)./ >>> >>> s1: What is a Non-MPLS-TP (transport) network? >> MPLS-TE and other MPLS networks which is not constrained by transport >> requirements. Assuming some new tunnel type comes up into the future like >> bi-directional TE. :D >>> >>> s1: The explanation of what the MIB extensions in this document actually do >>> is not clear to the >>> general reader. I suggest replacing para 2 completely: >>> >>> OLD: >>> The existing MPLS Traffic Engineering (TE) Management Information Base >>> (MIB) [RFC3812] and Generalized Multiprotocol Label Switching (GMPLS) >>> Traffic Engineering Management Information Base [RFC4802] do not support >>> the management of transport network requirements of Tunnel end points >>> with non-IP based identifiers and static bidirectional tunnels. This >>> document focuses on static bidirectional MIB modules that should be used >>> in conjunction with [RFC3812] and companion document [RFC3813] for MPLS >>> Transport Profile (MPLS-TP) path configuration and management. >>> >>> NEW: >>> As described in the MPLS Traffic Engineering (TE) Management Information >>> Base (MIB) definition [RFC3812], MPLS traffic engineering is concerned with >>> the >>> creation and management of MPLS tunnels. This term is a shorthand for a >>> combination of one or one or explicitly routed LSPs (ERLSPs) linking an >>> ingress >>> and an egress LSR. Several types of point-to-point MPLS tunnels may be >>> constructed >>> between a pair of LSRs A and B: >>> >>> - Unidirectional with a single LSP (say) from A to B. >>> >>> - Associated bidirectional consisting of two separately routed ERLSPs, one >>> linking >>> A to B and the other linking B to A. Together the pair provide a single >>> logical >>> bidirectional transport path. >>> >>> - Corouted bidirectional consisting of an associated bidirectional tunnel >>> but with >>> the second ERLSP from B to A following the reverse of the path of the ERLSP >>> from A to B, in terms of both nodes and links. >>> >>> Tunnels may be either statically configured by management action or >>> dynamically created using >>> a LSP management protocol. >> what is ‘LSP management protocol’? >>> >>> The existing MPLS TE MIB [RFC3812] and the Generalized Multiprotocol Label >>> Switching (GMPLS) Traffic Engineering Management Information Base [RFC4802] >>> address only a subset of the >>> combinations of statically and dynamically configured tunnel types, >>> catering for statically >>> configured unidirectional tunnels together with dynamically configured >>> unidirectional and >>> corouted bidirectional tunnels. They are alsorestricted to to end point >>> LSRs identified >>> by IP addresses. >>> >>> The MPLS-TP TE MIB defined in this document extends the MIB defined in >>> [RFC3812] to cover >>> all six combinations (that is adding support for statically configured >>> associated and >>> corouted bidirectional plus dynamically configured associated bidirectional >>> tunnels). It also >>> extends support to end points that are identified other than with IP >>> addresses. >>> >>> This support is provided by a suite of four MIB modules that are to be used >>> in conjunction >>> with the MIBS defined in [RFC3812] and the companion document [RFC3813] for >>> MPLS >>> Transport Profile (MPLS-TP) TE path [configuration and]* management. >>> >>> END NEW >> Thank you. Will go through the text again and replace as suggested. >>> >>> * Note: Using the term 'configuration' is inconsistent with the discussion >>> in para 3. >>> See Major Issues above >>> >>> s5, bullet 1: s8 in RFC 3812 discusses the use of the Interface Table with >>> MPLS. It should be >>> made clear here: >>> 1. Whether, if the MPLS-TP Tunnel is treated as an interface, there is any >>> difference in the usage >>> of the ifTable fields as compared with standard MPLS. In particular if a >>> different interface type >>> should be applicable. >>> 2. Are there any issues if all or (more especially) a subset of the tunnels >>> are not treated as >>> interfaces >> Haven’t come across any different types as such. Do you see any specific >> type which is of contrary to RFC 3812, that MPLS-TP defines? Will ask my >> co-authors as well. >>> >>> Row pointer usage: s9 of RFC 3812 considers Row Pointer usage - are there >>> any differences or >>> additional considerations for these MIBs? >> None that we are aware off. >>> >>> s6: Sections 6.1 to 6.4 are not MIBs (as indicated by the title and >>> prologue) but MIB objects in >>> the MPLS-TE-EXT-STD-MIB MIB. Please reorganize s6 accordingly. Looking back >>> at RFC3812, the >>> structure of the document in sections 5 and 6 appears to be more helpful to >>> the new reader with a >>> summary of the four MIB modules in one section (expanded from ss6.5 - 6.7) >>> followed by notes on >>> the key MIB objects in each MIB as necessary. It would also be helpful to >>> clarify where objects in >>> this MIB are expected to parallel those in the basic (RFC 3812) and note >>> that they are indexed >>> equivalently (notably in the case of mplsTunnelTable and >>> mplsTunnelExtTable). >>> Nits/editorial comments: >> Nod. >>> General: Consistent use of bi-directional or bidirectional: Please choose >>> one and use it throughout. >> Nod. >>> >>> General: The qualifier "sparse" is used incorrectly in several places >>> (e.g., sparsely extended). >>> Presumably the intention is that the extensions are "slight" or "limited" . >>> In most cases the term >>> can be deleted: The degree of extension will ultimately be in the eyes of >>> the implementer! >>> (s5 - 2 cases, s6.4, s7 - 2 cases, s8, s9.1.6, s9.2.9, s9.3.6, s12 - 3 >>> cases) >>> General: The figures need number and captions. The numbers should be used >>> to refer to the figures. >> Will review and edit as suggested. >>> >>> s4, para 1: s/unidirectional tunnel/unidirectional tunnels/ >> Nod. >>> >>> s4, para 1, last sentence: s/re-use/re-use and extend/ >> Nod. >>> >>> s4, para 2: >>> OLD: >>> retained in the same document, instead of a separate document. >>> NEW: >>> all defined in this document, rather than split over several documents. >>> >>> s5, para 1: s/This document identifies/The MIBs in this document satisfy/ >>> >>> s5, para 2: s/The MIB module supports/The MIB modules, taken together, >>> support/ >>> >>> s5, para 2: s/static and signaled/statically configured and dynamically >>> signaled/ >>> >>> s5, bullet 4: s/sparsely extended/extended/ >>> >>> s9.1.6, s9.2.9, s9.3.6: s/a sparse augmentation/a limited augmentation/ >> Nod for all the above. >>> >>> s5, bullet 5: It would be helpful to explain how node identification >>> differs from >>> standard MPLS to understand why this mapping is needed. There appears to be >>> text in s6.1 that might help >>> but it is too late to make it easy to understand this section. >> Will add reference to s6.1. >>> >>> ss10-13: It is conventional to give the RFCs used as references in the >>> docuement s/RFC 3812/[RFC3812]/ etc. >> Nod. >>> >>> s14: This is a near duplicate of the security considerations in RFC 3812. >>> It might be easier to reference >>> that section and add a note that extra tables may provide further sensitive >>> information. >> Nod. >>> >>> A brief discussion of whether the non-IP case makes any difference would be >>> useful. >> I do not think there is a difference as such. We have provided example for >> non-ip case anyway. >>> >>> s16: At the very least RFC 3811, RFC 3812 and RFC 3813 are normative. RFC >>> 6923 probably is. >>> RFC 6370 and RFC 4802 may also be. >> Nod. >> >> thanks again >> -sam >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art >> _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
