[Teas] some shepherd comments on draft-ietf-teas-yang-te-topo

Lou Berger <lberger@labn.net> Mon, 09 October 2017 22:40 UTC

Return-Path: <lberger@labn.net>
X-Original-To: teas@ietfa.amsl.com
Delivered-To: teas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9ECA1331DD for <teas@ietfa.amsl.com>; Mon, 9 Oct 2017 15:40:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-2.8, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KboXMzj7XktZ for <teas@ietfa.amsl.com>; Mon, 9 Oct 2017 15:40:58 -0700 (PDT)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8390132D22 for <teas@ietf.org>; Mon, 9 Oct 2017 15:40:57 -0700 (PDT)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id A7894215E0F for <teas@ietf.org>; Mon, 9 Oct 2017 16:40:52 -0600 (MDT)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with id Kago1w00o2SSUrH01agrEX; Mon, 09 Oct 2017 16:40:52 -0600
X-Authority-Analysis: v=2.2 cv=dZfw5Tfe c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=02M-m0pO-4AA:10 a=ETbLuy7_Rha8vKNLc3EA:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:Subject:From:To:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=9V+rPRqVL9FJ+LQCVU2j5gbf7a4dvkZs0gGiFIsPFYc=; b=CXNrQUAtAGaX3NaRKSuunTwIsx vambdQmSM1Kw8T4fzg6HglL5WkBWAB5MHyQ7bNZNCxy50d/9JUbNp7MEoprO+b2PhAesS4rZD+GZD y8xss5AXTKiGRO3ULnhSGZ8eG;
Received: from pool-100-15-84-20.washdc.fios.verizon.net ([100.15.84.20]:51128 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <lberger@labn.net>) id 1e1gjA-003peE-HJ; Mon, 09 Oct 2017 16:40:48 -0600
To: draft-ietf-teas-yang-te-topo@ietf.org
From: Lou Berger <lberger@labn.net>
Cc: TEAS WG <teas@ietf.org>
Message-ID: <06bb3c46-0bcb-7748-86e3-8743028fe579@labn.net>
Date: Mon, 09 Oct 2017 18:40:44 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.84.20
X-Exim-ID: 1e1gjA-003peE-HJ
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: pool-100-15-84-20.washdc.fios.verizon.net ([IPv6:::1]) [100.15.84.20]:51128
X-Source-Auth: lberger@labn.net
X-Email-Count: 2
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/UENP71HVlXTLRGpiD1AI8YflVk4>
Subject: [Teas] some shepherd comments on draft-ietf-teas-yang-te-topo
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Traffic Engineering Architecture and Signaling working group discussion list <teas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/teas>, <mailto:teas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/teas/>
List-Post: <mailto:teas@ietf.org>
List-Help: <mailto:teas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/teas>, <mailto:teas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Oct 2017 22:40:59 -0000

Authors,

Great (and important) work! I think the early sections are very
informative and readable. 

My one substantive comment is that I think it would be helpful to future
model developers to provide an overview of how you see this work will be
extended to support technology specific extensions, e.g., new control
technologies, new/tech link config parameters/statistics, technology
specific (or not) switching constraints, etc.    I don' want this to
delay the work, but I also don't want to find out in 6 months that the
model isn't sufficiently extendable. What do you think?

** Editorial comments:

- TE should be spelled out in the title and first use in the abstract
and introduction

- This should be moved to section 1.1:

  Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC-2119 [RFC2119].

- reverences to 6020 should be replaced 7950

- Section 1.1
  It's unclear to me how you selected this particular terms and I
suspect we're going to see many comments on the need to expand this
list.  Perhaps just state that reader is assumed to be familiar with the
terminology and concepts in TE rfcs, e.g., perhaps just add something like:

   The reader is assumed to be familiar with general body of work
captured in
    currently available TE related RFCs.  RFC7926 serves as a good
starting point
    for those who may be less familiar with Traffic Engineering related
RFCs.

- It would be good to add references the first time you refer to a
well-known concept, e.g.,
Multi-layer TE [RFC5512], SRLGs, ODUk, etc..

- Section 1.2 should be replaced by a reference to
draft-ietf-netmod-yang-tree-diagrams

- s/decorate/annotate and s/decorating/annotating

- I'm not sure how useful the 30 odd pages of tree diagrams in section 6
are in this document.  Perhaps move to an appendix?  I'm really not sure...

- Please replace the reference to   draft-clemm-netconf-yang-push with
draft-ietf-netconf-yang-push

- please make [YANG-SCHEDULE] and informative reference

That's it,
Lou