I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written primarily for the benefit of the security area directors.  Document editors and WG chairs should treat these comments just like any other last call comments.


This document defines a data structure and defines a data transfer syntax for retrieving and sometimes setting routing configuration information from network intermediaries and possibly network endpoints.


This document is pretty much unreadable unless one is immersed in the arcane world of OAM YANG models. I remember having the same reaction to MIB RFCs. That's not a criticism... just acknowledging my lack of qualification to do this review. That said, I have some observations/feedback.

Documents not intended to be readable by outsiders should include in the introduction a reference to documents that the reader is expected to have read before reading this one. I made it through most of the document before realizing I had (probably) misparsed the title (I'm still not sure). I assumed this specified something related to "Connectionless Operations, Administration, and Maintenance Protocols" since those are the last words of the title. The fact that the Introduction used Ping and Traceroute as protocols that this protocol wanted to generalize reinforced that view. Such protocols have severe security issues because there is effectively no way to add encryption, authentication, and authorization to them. But the Security Considerations section specifies that these protocols are intended to be layered over NETCONF or RESTCONF (both connection-oriented protocols that can be run over secure transports). So I now believe this document is about accessing configuration information that concerns connectionless protocols, but that it is not intended to run over connectionless protocols. But the data types defined appear to be of interest to both connectionless and connection oriented data transfer. If I have this wrong, then there are serious problems with security. If not, then it is probably fine.


Formatting Glitches / Typos:


Throughout the document, there seems to be a problem with  spaces erroneously inserted and removed near single quotes and the sequence: "e.g..". A particularly dramatic example is at the top of page 5:

   'grouping is chosen based on 'tp-location-type' leaf which when
   chosen, leads to a container that includes a list of 'test-point-
   locations' keyed by technology specific keys(e.g.,
   'ipv4-location'leaf).  Each test point location under 'test-point-
   locations 'grouping includes a 'test-point-location-info' grouping.


I believe Section 3.6 has a wording error exacerbated by the space problem. In any case, I could not parse the following:

   Path discovery includes data to be
   retrieved on a 'per- hop' basis via a list of 'path-trace-info-
   list'list which includes information like 'timestamp'grouping, '
   ingress-intf-name ', ' egress-intf-name ' and 'app-meta-data'.


Starting on page 21, there appear to be many lines that exceed the maximum length for an RFC. This causes the PDF rendering to switch to a smaller font for the pages that contain the long lines.


Awkward English in section 5.2.1.2:

   To support lsp-ping, the "ietf-connectionless-oam" model can be
   extended and add lsp-ping specific parameters can be defined and
   under "test-point-location" list.

   User can reuse the attributes or groupings which are defined in
   [I-D.zheng-mpls-lsp-ping-yang-cfg] as follows:

   The snippet below depicts an example of augmenting the "test-point-
   locations" list with lsp ping attributes: