I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For background on Gen-ART, please see the FAQ at Document: draft-ietf-mpls-tp-oam-id-mib-08 Reviewer: Peter Yee Review Date: Aug-27-2015 IETF LC End Date: Aug-27-2015 IESG Telechat date: TBD Summary: This draft is on the right track but has open issues, described in the review. [Ready with nits.] The draft specifies an OAM MIB for the MPLS Transport Profile. Major issues: None Minor issues: None Nits: General: There are a lot of the definite and indefinite articles missing in the draft. Mostly this occurs in description text in the MIB. These do help readability, so consider using them going forward. There are a few specific cases where I wasn’t certain whether a definite or indefinite article would have been more appropriate; removing this ambiguity would be a good thing. General: fix the footer so that only one space occurs after “Aldrin,”. Page 1, Abstract: change “MPLS based” to “MPLS-based”. Page 3, section 1, 1st paragraph, 2nd sentence: append a hyphen after “Switching”. Page 3, section 1, 2nd paragraph: consider adding “Tunnel, ” before “LSP” as the body of the draft also describes tunnel support. Append a space after “LSP”. Append a comma after “Pseudowires”. Page 3, section 2, 2nd paragraph, 3rd sentence: change “compliant to” to “compliant with”. For the STD/RFC list, rewrite as: “STD 58 (RFC 2578, RFC 2579, RFC 2580)”. Page 3, section 3.1: change “RFC-2119” to “RFC 2119”. Page 4, section 4: append a comma after “associated bidirectional LSPs”. Page 4, section 5: change “IP compatible” to “IP-compatible”. Change “ICC based” to “ICC-based”. Make those changes globally in the document. Append a comma after “LSPs”. Page 5, 2nd paragraph: append a comma after LSPs. Consider your usage of “Pseudowire” vs. “pseudowire”; there’s some inconsistency in capitalization. While the capitalized form makes sense in titles and in other locations where it derives from a source document that uses it that way, the remaining uses in the document should aim for consistency. If nothing else, it will keep ignorant readers (like me) from guessing if there’s a hidden meaning to the capitalization. Page 5, section 6, 2nd paragraph: Remove the “a” before “MEG”. Page 5, section 6, 3rd paragraph, 1st sentence: change “a MPLS” to “an MPLS”. Page 5, section 6, 3rd paragraph, 2nd sentence: change “IP based” to “IP-based”. Make that change globally. Insert “an” before “MPLS”. Page 7, Contact Info for Sam Aldrin: append “ 94043” after “CA”. We denizens of 94043 should be proud of our rare zip code. ;-) Page 8: Are two “DESCRIPTION” sections allowed? I am in no way a MIB doctor, so I ask simply from a consistency standpoint. If only one is allowed, then combine the IETF boilerplate/brief overview and the longer text that more fully describes what this module does into one DESCRIPTION block. In either case, append a comma after “Pseudowires”. Page 9, for the descriptive text for "associated bidirectional LSP” and “PW”, a space is found in front of Z9. While this is obviously just text, it appears inconsistent with other usage, so consider removing the spaces. Page 11, mplsOamIdMegName DESCRIPTION: insert “a” before “unique”. Page 11/12: mplsOamIdMegIdCc, mplsOamIdMegIdIcc, and mplsOamIdMegIdUmc definition: the text starting "This object MUST contain a non-null ICC value” appears in each DESCRIPTION. I believe this text should use “CC”, “ICC”, and “UMC” respectively, twice in each DESCRIPTION. I’m also not sure what “octet size 0” means in those DESCRIPTIONs. Furthermore, the DESCRIPTIONs note that the ICC is concatentated with the CC to ensure global uniqueness, but that the UMC is appended to the ICC to form the MEGID. It’s ambiguous as to whether that implies the MEGID is ICC+CC+UMC or ICC+UMC+CC. Page 12, mplsOamIdMegIdUmc DESCRIPTION: append a comma after “Provider”. Change “and” to “which”. Page 13, REFERENCEs: there appear to be at least two different style of textual references used in the MIB. Pick one? Page 14, last partial sentence: insert a space before “(1)”. up is not a function. ;-) Do the same thing for “(2)” at the top of the following page (15) along with (1) near the bottom of the page. Page 20, mplsOamIdMeSinkMepIndex DESCRIPTION: insert “to” before “zero”. Append a space after “Identifiers”. Page 20, mplsOamIdMeMpType DESCRIPTION, 2nd paragraph: delete an extraneous space after "mep (1),”. Page 20, mplsOamIdMeMpType DESCRIPTION, 3rd paragraph: “end nodes” are mentioned in this paragraph. Are these the same as the “Egress nodes” in the previous paragraph. If so, considering using consistent terminology, at least between the two paragraphs. Page 21, mplsOamIdMeServicePointer DESCRIPTION, 2nd paragraph: delete the first two commas. Insert “the” before “ME” and “MEG”. Page 21, mplsOamIdMeRowStatus DESCRIPTION: insert a space before “(1)”. Page 27, section 8, 1st paragraph, 1st sentence: change “is” to “are”. Change “has” to “have”. Yes, really. Page 28, 2nd full paragraph, 1st sentence: do you mean “Further” as in “Also”? Or should you omit the comma to indicate that continued deployment of older versions of SNMP is deprecated? If you mean the latter, delete the comma after “Further”. Page 30, section 11: append a comma after “Cheng”.