[Gen-art] Gen-art LC review of draft-ietf-mpls-tp-oam-id-mib-08

[Peter Yee <[e-mail]>]

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 <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>

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”.