Skip to main content

Telechat Review of draft-ietf-lime-yang-connectionless-oam-11

Request Review of draft-ietf-lime-yang-connectionless-oam
Requested revision No specific revision (document currently at 18)
Type Telechat Review
Team Security Area Directorate (secdir)
Deadline 2017-10-24
Requested 2017-10-11
Authors Deepak Kumar , Zitao Wang , Qin Wu , Reshad Rahman , Srihari Raghavan
I-D last updated 2017-10-19
Completed reviews Secdir Telechat review of -11 by Charlie Kaufman (diff)
Yangdoctors Early review of -05 by Carl Moberg (diff)
Genart Telechat review of -13 by Elwyn B. Davies (diff)
Assignment Reviewer Charlie Kaufman
State Completed Snapshot
Review review-ietf-lime-yang-connectionless-oam-11-secdir-telechat-kaufman-2017-10-19
Reviewed revision 11 (document currently at 18)
Result Has Nits
Completed 2017-10-19
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

   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: