Re: [secdir] secdir review of draft-ietf-lime-yang-connectionless-oam-11

Qin Wu <> Mon, 16 October 2017 10:40 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 64393132F69; Mon, 16 Oct 2017 03:40:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.219
X-Spam-Status: No, score=-4.219 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yN_WFnPldZAV; Mon, 16 Oct 2017 03:40:14 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 536A31270AB; Mon, 16 Oct 2017 03:40:13 -0700 (PDT)
Received: from (EHLO ([]) by (MOS 4.3.7-GA FastPath queued) with ESMTP id DQS66491; Mon, 16 Oct 2017 10:40:11 +0000 (GMT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 16 Oct 2017 11:40:09 +0100
Received: from ([]) by ([]) with mapi id 14.03.0235.001; Mon, 16 Oct 2017 18:40:05 +0800
From: Qin Wu <>
To: Charlie Kaufman <>, "" <>, "" <>, "" <>
Thread-Topic: secdir review of draft-ietf-lime-yang-connectionless-oam-11
Thread-Index: AQHTRWlfh4+GQ0heREaViILKKGb1NaLmQMcQ
Date: Mon, 16 Oct 2017 10:40:04 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_B8F9A780D330094D99AF023C5877DABA9ABE5A76nkgeml513mbxchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090206.59E48C8B.0080, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: e137d978251286e2d4c07c6966d1c4d4
Archived-At: <>
Subject: Re: [secdir] secdir review of draft-ietf-lime-yang-connectionless-oam-11
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 16 Oct 2017 10:40:17 -0000

Thank for valuable review to this document, please see my reply inline below marked with [Qin]
发件人: Charlie Kaufman []
发送时间: 2017年10月15日 11:58
主题: secdir review of draft-ietf-lime-yang-connectionless-oam-11

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.

[Qin]: Please read RFC6087 which provide Guidelines for Authors and Reviewers of YANG Data Model Documents and RFC7950 and RFC6022 which defines the YANG data modeling language before reading this one.

We can add a statement to say

“The reader is expected to know the YANG data modeling language [RFC7950] and Guidelines for Authors and Reviewers of YANG Data Model Documents [RFC6087]before using this document.”

If you think necessary. But note that this is not tradition or convention to add this statement for YANG data modeling standards.

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).

[Qin]: what we define in this draft is data model not new protocol, the protocol we are using to carry modeled data is netconf or restconf, netconf or restconf runs on top of secure transport such as SSH.

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.

[Qin]: Correct, connectionless protocols is east west protocol used to generate data or troubleshooting results,  and NETCONF+ the model defined in this draft can be used to configure the parameters that are needed for connectionless protocols and also export data or troubleshooting results back from test device to the management system.

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.

[Qin]: Correct, please see

we follows this YANG security guidelines to write this security consideration section.

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.

[Qin]:Good catching and have got this fixed.

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'.

[Qin]: In all information included in ‘path-trace-info-list’ , only ‘timestamp’ is defined as grouping, ‘ingress-intf-name’,’egress-intf-name’,’app-meta-data’ are defined as leaf.

yes, space will been removed

The proposed change is as follows:


   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', '
   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:

[Qin]: Copy and past error. The proposed change is to fixe the first sentence and remove the second sentence as follows:


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

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