> The IESG has received a request from the Multiprotocol Label Switching WG > (mpls) to consider the following document: > - 'MPLS Transport Profile Linear Protection MIB' > as Proposed Standard > > The IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to the > ietf at ietf.org mailing lists by 2017-01-26. Exceptionally, comments may be > sent to iesg at ietf.org instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. I have reviewed the -11 version of this document. It is well written and clear to read. I particularly welcome the explanations of the various objects. Here are a very few minor points and some nits. I think the document is ready to proceed to publication. Thanks, Adrian === Section 1 concludes with Although the example described in Section 7 specify means to configure OAM identifiers for MPLS-TP tunnels, this should be seen as indicating how the MIB values would be returned in the specified circumstances having been configured by alternative means. Two thoughts: 1. This text needs to be repeated in Section 7 2. This would read better as: Although the example described in Section 7 shows a way to configure OAM identifiers for MPLS-TP tunnels, this also indicates how the MIB values would be returned if they had been configured by alternative means. --- Section 4. The first sentence is a little hard to read... RFC 6378 [RFC6378] defines the protocol to provide a linear protection switching mechanism for MPLS-TP with protection domain as a point-to-point LSP. Looking at section 1.1. of RFC 6378, I think you could write... RFC 6378 [RFC6378] defines the protocol to provide a linear protection switching mechanism for MPLS-TP for a point-to-point LSP within the protection domain bounded by the end points of the LSP. --- Is Section 5.1 too terse? Maybe a two line explanation of each new TC? --- Please have a quick check to see whether sometimes when you say "this MIB" you mean "this MIB module" (etc., for other uses of "MIB"). For example the Description clause of mplsLpsNotificationEnable "Provides the ability to enable and disable notifications defined in this MIB. --- It is a little odd that MplsLpsReq has a syntax of OCTET STRING (SIZE (2)), a display hint of "1d", and you list the potential values in binary. I should think that the values should be listed in decimal as they are shown in RFC6378 and RFC7271. Then it is just a question of whether this should be a text string or an integer, which probably doesn't matter, but if your keep it as a octet string, you do need to say how the numbers are encoded (presumably ASCII?). --- For MplsLpsFpathPath why do you say... Bits are numbered from left to right. ...I don't see any reference to bits. --- mplsLpsConfigSdBadSeconds and mplsLpsConfigSdGoodSeconds could use a Units clause (although it should be pretty obvious from the name and description!) --- Is there a reason why you used SYNTAX INTEGER {true (1), false (2)} instead of TruthValue in mplsLpsStatusRevertiveMismatch mplsLpsStatusProtecTypeMismatch mplsLpsStatusCapabilitiesMismatch mplsLpsStatusPathConfigMismatch OBJECT-TYPE --- mplsLpsStatusPathConfigMismatch OBJECT-TYPE SYNTAX INTEGER {true (1), falsmplsOamIdMeMpIndexNexte (2)} Looks like a typo although it will compile :-) === Nits --- Section 1 s/read- write/read-write/ s/document is consistent/document are consistent/ --- Section 4 s/alternate/alternative/ --- Section 5.3 s/failures of linear protection/failures of the linear protection/ --- mplsLpsMeStatusTable s/liear/linear/