[secdir] Secdir telechat review of draft-ietf-netmod-yang-tree-diagrams-05

Phillip Hallam-Baker <hallam@gmail.com> Thu, 25 January 2018 20:35 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: secdir@ietf.org
Delivered-To: secdir@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C2E2F12EAAA; Thu, 25 Jan 2018 12:35:55 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Phillip Hallam-Baker <hallam@gmail.com>
To: secdir@ietf.org
Cc: draft-ietf-netmod-yang-tree-diagrams.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.70.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151691255573.8494.16260998328717962330@ietfa.amsl.com>
Date: Thu, 25 Jan 2018 12:35:55 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/dK7HwNOWkHMu4H8vpLMHmzYlzos>
Subject: [secdir] Secdir telechat review of draft-ietf-netmod-yang-tree-diagrams-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Jan 2018 20:35:56 -0000

Reviewer: Phillip Hallam-Baker
Review result: Has Nits

I have reviewed the document and it is generally free of security
considerations as claimed. There are some areas of concern however, the
significance of which may become more apparent as such tools find future use.

As described in the document, the tree diagram format is intended to serve as
an output generated by a tool to aid human interpretation. Thus, a potential
ambiguity can arise if the tool used to generate the format is buggy or if the
document contains schema and presentation data compiled from different versions
of the source.

Specifications using this representation need to make clear which
representation is canonical. Otherwise we end up in a situation in which a
document that has an ambiguity being unfixable by means of issuing an errata
because there is no agreement as to whether the change is breaking or not.

Another issue that is of concern is that even though the format is not intended
to be an input format, there can be no guarantee it will not be used as such.
Indeed it could be argued that a spec that makes use of this format should
encourage this approach so as to detect possible ambiguities.