Last Call Review of draft-ietf-lime-yang-connection-oriented-oam-model-05
review-ietf-lime-yang-connection-oriented-oam-model-05-opsdir-lc-clarke-2018-02-10-00

Request Review of draft-ietf-lime-yang-connection-oriented-oam-model
Requested rev. no specific revision (document currently at 07)
Type Last Call Review
Team Ops Directorate (opsdir)
Deadline 2018-02-19
Requested 2018-02-05
Other Reviews Yangdoctors Early review of -03 by Carl Moberg (diff)
Genart Last Call review of -05 by Paul Kyzivat (diff)
Secdir Last Call review of -05 by Sandra Murphy (diff)
Review State Completed
Reviewer Joe Clarke
Review review-ietf-lime-yang-connection-oriented-oam-model-05-opsdir-lc-clarke-2018-02-10
Posted at https://mailarchive.ietf.org/arch/msg/ops-dir/yAAKTS-bpm9Jla6phleIpINRr1M
Reviewed rev. 05 (document currently at 07)
Review result Has Issues
Draft last updated 2018-02-10
Review completed: 2018-02-10

Review
review-ietf-lime-yang-connection-oriented-oam-model-05-opsdir-lc-clarke-2018-02-10

I have been asked to review  draft-ietf-lime-yang-connection-oriented-oam-model  on behalf of the Ops Directorate.  This document defines a generic YANG data model for connection-oriented OAM that is designed to be extended for other protocols' uses of OAM.  Insofar as that is concerned, I do think the document does a good job.  Where I think there are issues is with section 7.  I feel the specifics discussed concerning TRILL and MPLS-TP go beyond example usage and cover areas of extension that would be better left for specific documents concerning TRILL and MPLS-TP.  For example, when technology type extensions are covered, it prescribes the specific wording of the YANG identity augmentations.  But what happens if those subsequent documents deviate from this? 

Beyond the issue of scope conflation, I found a few minor issues/nits in the text.  One overall comment is the inconsistent use of capitalization.  For example, sometimes "verification" is capitalized (e.g., Connectivity Verification) and sometimes it is not (e.g., Fault verification).  A sweep should be made to make sure any capitalized noun has some specific meaning (else make them lowercase).

Section 1:

OLD:

Monitor networks connections (Connectivity Verification,

NEW:

Monitor network connections (Connectivity Verification,

===

Section 1:

You refer to RFC7276 for an overview of OAM.  Good.  It is.  But then in this same section you say, "but control information is required to identify the destination (e.g., [G.800] and [RFC7276])."  You refer again to RFC7276 when you speak about additional control information.  But you do not reference _where_ in this document to find that information.  The whole document itself is not about this control information.

===

Section 1:

You use abbreviations LBM and LTM before defining them.  And I didn't see LTM listed in your terminology list.

===

Section 5:

In the typedef for time-interval, you specify what 0 means, but what does a negative number mean?  Perhaps you should add a range qualifier to make sure this value cannot be negative?

===

Section 5 (coupled with Section 6):

You specify that the base mode includes certain defaults, one of which being that the MEP address is the IP address of the interface on which the MEP is located.  But in the YANG model, ip-address is not the default for mep-address (there is no default).  Should it be?

===

Section 5:

In the rpc for traceroute, you use "it's" twice in the description.  Both uses should be "its" without the apostrophe.

===

Section 8:

While I'm not the security directory rep, the wording "These data nodes may be considered sensitive or vulnerable in some network environments" seemed odd to me.  Sensitive I get.  But vulnerable I see as these data nodes are somehow weaker than others.  Unless the security directorate feels otherwise, I would drop the word vulnerable.  I think sensitive covers it as you go on to say that they can adversely affect network operations if misused.