A YANG Data Model for Retrieval Methods for the Management of Operations, Administration, and Maintenance (OAM) Protocols That Use Connectionless Communications
draft-ietf-lime-yang-connectionless-oam-methods-13

id-nits reports: 

  ** There are 5 instances of too long lines in the document, the longest one
     being 3 characters in excess of 72.

The document uses "id", "Id", and "ID" interchangeably for "identifier." I suggest changing these to "ID" everywhere.

The indenting and spacing in the YANG module appears to be inconsistent. You may want to consider a formatting pass to make it easier to read.

After a useful conversation with Benoit, I better understand how the status-code and sub-status-code
are intended to be used.  While I do still have some concerns about the clarity and ease of using this,
I do not think it is Discuss-worthy, so I have moved these to be Comments.

a)  It would be helpful to clarify that and how additional OAM YANG modules
are expected to use the status-code identityref and sub-status-code identityref
so that there is a clear indication of how OAM modules are expected to interact
and be build to interact. 

b) To handle the cases where OAM mechanisms might be triggered by the RPCs but that
OAM mechanism may not have an associated YANG module, it would be useful to be able
to send back the numeric codes (whether status-code or sub-status-code).  Maybe that's a
generic module of status codes - but this could help with dependencies.

These two points get to what I was concerned/confused by in (1) below.

1) on p. 19: "        leaf status-code {
          type identityref{
            base status-code;
          }
          mandatory true;
          description
           "Error code for continuity-check message, that is
            relevant to the protocol under use for CC.
            For example if ICMP is the protocol under use, the
            error codes are as defined in [RFC4443].";
        }"
I am quite unclear on how this could technically be used??  RFC4443 defines integer error codes or types and
sub-codes that are also integers.
Is the expectation that an ICMPv6-specific YANG module will define those codes as identityrefs???
Clarification in at least the description is needed, since I don't see how it could be used as currently defined.

=======================================

1) On p.6 : "leaf protocol-id-meta-data {
             type uint64;
             description
               "An optional meta-data related to the protocol ID.
                For e.g., this could be the Internet Protocol number
                for standard Internet Protocols for help in protocol
                processing.";
           }"
Seems very useful - but how and where would a tool be able to learn the expected contents and parsing of the
protocol-id-meta-data?  I do not see any indication in the module on p.16 where the protocol-ids are defined -
not even in the descriptions much less programmatically.

2) The complete data hierarchy in Sec 3.2 is confusing in a couple ways.  First, it isn't clear what is going to be
defined in this document and what is from draft-ietf-lime-yang-connectionless-oam-14.   Second, the groupings
are all expanded - which makes it very hard to see the logical structure & requires sanity-checking that the same
information appears.

There is an outstanding issue stemming from the Gen-ART review concerning whether two-way delay is supported and whether it would be signaled by specifying TWAMP as the protocol-id. This should be resolved before the document gets published.

I noted a few nits:

Line 729
    description
      "Propreitary protocol (eg.,IP SLA).";
  }
Typo: proprietary


Line 766
  identity invalid-cc{
   base status-code;
Nit: " {"

Thanks for your work on this draft.  In the security considerations, could you please add a clause on network reconnaissance into the text since that could lead to other attack types (compromise, etc.).

OLD:

These are the
   operations and their sensitivity/vulnerability:

   o  continuity-check: Generates continuity check.

   o  path-discovery: Generates path discovery.

   which may lead to Denial-of-Service attack on both the local device
   and the network or unauthorized source access to some sensitive
   information.

NEW:
These are the
   operations and their sensitivity/vulnerability:

   o  continuity-check: Generates continuity check.

   o  path-discovery: Generates path discovery.

   which may be used for network reconnaissance or lead to Denial-of-Service attack on both the local device
   and the network or unauthorized source access to some sensitive
   information.