Re: [Teas] Roman Danyliw's No Objection on draft-ietf-teas-yang-te-topo-21: (with COMMENT)

Roman Danyliw <rdd@cert.org> Fri, 14 June 2019 19:19 UTC

Return-Path: <rdd@cert.org>
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 4BC05120154; Fri, 14 Jun 2019 12:19:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 OtIjl7PWDVbA; Fri, 14 Jun 2019 12:19:46 -0700 (PDT)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 E645112011C; Fri, 14 Jun 2019 12:19:45 -0700 (PDT)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5EJJfV0005513; Fri, 14 Jun 2019 15:19:41 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu x5EJJfV0005513
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1560539981; bh=zpKXHmo83l6d1juJxwXNHfu4g7DlecWnLvaauWky5qM=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=s5XfAbuift6WMsd0VL35G3TN5L9JhzcrBogeX+wJO7rZoRO9jAK5p1Llg7CRv+D3/ xtGVlORkhk2wvJkD7kM6WshN9lc0H2hHAgbqp1pPgjrfoWgPsHB1tVfgf5jjOwbXoM Oc3czH28CM+hsyWxasrE2qJTFYLEyU+wxPDAEnJM=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5EJJbQw007981; Fri, 14 Jun 2019 15:19:37 -0400
Received: from MARATHON.ad.sei.cmu.edu ([10.64.28.250]) by CASCADE.ad.sei.cmu.edu ([10.64.28.248]) with mapi id 14.03.0439.000; Fri, 14 Jun 2019 15:19:37 -0400
From: Roman Danyliw <rdd@cert.org>
To: Xufeng Liu <xufeng.liu.ietf@gmail.com>
CC: The IESG <iesg@ietf.org>, "draft-ietf-teas-yang-te-topo@ietf.org" <draft-ietf-teas-yang-te-topo@ietf.org>, Lou Berger <lberger@labn.net>, "TEAS WG Chairs" <teas-chairs@ietf.org>, TEAS WG <teas@ietf.org>
Thread-Topic: Roman Danyliw's No Objection on draft-ietf-teas-yang-te-topo-21: (with COMMENT)
Thread-Index: AQHVIL8kWQfejoBb5EGsJNHNwuSRFKabjd4A///82b8=
Date: Fri, 14 Jun 2019 19:19:36 +0000
Message-ID: <5DEC3699-21C3-4DF2-AFC7-98FDEFB4562F@cert.org>
References: <156030332758.5903.11787427451647585397.idtracker@ietfa.amsl.com>, <CAEz6PPRa=XUZyU5pq+f69Av+RZoWHDC497RVGqGw8+wA+fp8-w@mail.gmail.com>
In-Reply-To: <CAEz6PPRa=XUZyU5pq+f69Av+RZoWHDC497RVGqGw8+wA+fp8-w@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: multipart/alternative; boundary="_000_5DEC369921C34DF2AFC798FDEFB4562Fcertorg_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/oQpInp05AVpzIDypbqIo1mvwdCs>
Subject: Re: [Teas] Roman Danyliw's No Objection on draft-ietf-teas-yang-te-topo-21: (with COMMENT)
X-BeenThere: teas@ietf.org
X-Mailman-Version: 2.1.29
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: Fri, 14 Jun 2019 19:19:49 -0000

Hi Xufeng!

On Jun 14, 2019, at 11:31 AM, Xufeng Liu <xufeng.liu.ietf@gmail.com<mailto:xufeng.liu.ietf@gmail.com>> wrote:

Hi Roman,

Thanks for the review and comments. Please see some reponses and explanations in-line below.
Regards,
- Xufeng


On Tue, Jun 11, 2019 at 9:35 PM Roman Danyliw via Datatracker <noreply@ietf.org<mailto:noreply@ietf.org>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-teas-yang-te-topo-21: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(1) Section 4.2.  Per “The data model proposed in this document can be used to
retrieve/represent/manipulate the customized TE Topology depicted in Figure 8b”
this statement struck me as odd because aren’t all of the topologies depicted
here supported with the modeling language?

Xufeng]: This sentence is here because that the title of Section 4.2. is “Customized TE Topologies”, which is the focus of this section. It is correct that many other types of topologies are supported by this model. For example, Section 4.1. focuses on “Native TE Topologies”, and Section 4.3 focuses on “merged topologies”.


Got it. Thanks for the clarification.

(2) Section 4.2.  Per “Although an authorized client MAY receive a TE topology
with the client ID field   matching some other client”, why would this happen?
Couldn’t this potentially leak customized TE information across clients?

[Xufeng]: Right. This does leak the information across clients. Whether to allow this or not is an implementation policy, which can be supported by other IETF documents and models, such as RFC8341 Network Configuration Access Control Model. Section 8. contains the following:

The Network Configuration Access Control Model (NACM) [RFC8341]

provides the means to restrict access for particular NETCONF or
RESTCONF users to a preconfigured subset of all available NETCONF or
RESTCONF protocol operations and content.

Understood. As non-blocking feedback, I’d recommend adding sentence to explain this nuance.



(3) Section 5.9.  Per “When two or more templates specify values for the same
configuration field, the value from the template with the highest priority is
used”, is the highest priority 0 or 65535 (since priority is a uint16)?  The
text doesn’t indicate whether the highest priority is a largest or smallest
number.

[Xufeng]: Thanks for pointing this out. We will clarify the text, by adding the following after the quoted sentence:

“The range of the priority is from 0 to 65535, with a lower number indicating a higher priority.”

Also, in the description statement in the model, a sentence will be added:

Page 87:
[OLD]:
       leaf priority {
         type uint16;
         description
           "The preference value to resolve conflicts between different
            templates. When two or more templates specify values for
            one configuration attribute, the value from the template
            with the highest priority is used.";
       }
[NEW]:
       leaf priority {
         type uint16;
         description
           "The preference value to resolve conflicts between different
            templates. When two or more templates specify values for
            one configuration attribute, the value from the template
            with the highest priority is used.
            A lower number indicates a higher priority. The highest priority is 0. ";
       }
[END]


(4) Editorial Nits
-- Section 3.4.  Missing word.  s/3.3/Section 3.3/

-- Section 4.2.  Typo.  s/-connectivit-/-connectivity-/

-- Section 4.2.  Editorial.  Why does “single-abstract-node-with-connectivit
–matrix topology” use hyphens and
“border_nodes_connected_via_mesh_of_abstract_links topology” use an underscore?

[Xufeng]: Will change the underscores to hyphens.

-- Section 4.2.  Typo.  s/Although a/Although an/

-- Section 5.6.  Typo.  s/cooresponding/corresponding/

[Xufeng]: Thanks for these catches. Will fix them as suggested.

Thanks for making these other changes and for the document.

Roman