Hi Joe, Thanks for your comments. It make sense, and we will address your comments in next version. Best Regards! -Michael -----邮件原件----- 发件人: Joe Clarke [mailto:jclarke@xxxxxxxxx] 发送时间: 2018年2月11日 5:54 收件人: ops-dir@xxxxxxxx 抄送: draft-ietf-lime-yang-connection-oriented-oam-model.all@xxxxxxxx; lime@xxxxxxxx; ietf@xxxxxxxx 主题: Opsdir last call review of draft-ietf-lime-yang-connection-oriented-oam-model-05 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.