[Lime] Opsdir last call review of draft-ietf-lime-yang-connection-oriented-oam-model-05

[Joe Clarke <[e-mail]>]

Reviewer: Joe Clarke
Review result: Has Issues

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.