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

From: Joe Clarke <[email-masked]>
Date: Sat, 10 Feb 2018 13:53:55 -0800

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.

---

From: wangzitao <[email-masked]>
Date: Tue, 13 Feb 2018 03:13:15 +0000

Hi Joe,

Thanks for your comments. It make sense, and we will address your comments in next version.

Best Regards!
-Michael

-----邮件原件-----
发件人: Joe Clarke [mailto:[email-masked]] 
发送时间: 2018年2月11日 5:54
收件人: [email-masked]
抄送: [email-masked]; [email-masked]; [email-masked]
主题: Opsdir last call review of draft-ietf-lime-yang-connection-oriented-oam-model-05

Reviewer: Joe Clarke

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:

NEW:

===

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?

===

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.