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

Xufeng Liu <xufeng.liu.ietf@gmail.com> Fri, 14 June 2019 15:31 UTC

Return-Path: <xufeng.liu.ietf@gmail.com>
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 048AE1203A6; Fri, 14 Jun 2019 08:31:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 (2048-bit key) header.d=gmail.com
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 be85KVgYT3nv; Fri, 14 Jun 2019 08:31:06 -0700 (PDT)
Received: from mail-io1-xd31.google.com (mail-io1-xd31.google.com [IPv6:2607:f8b0:4864:20::d31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0F881203AA; Fri, 14 Jun 2019 08:31:05 -0700 (PDT)
Received: by mail-io1-xd31.google.com with SMTP id s7so6564065iob.11; Fri, 14 Jun 2019 08:31:05 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Rf6i2Zj4Akdxf8rr1fq1HvfOzQn4QOzYc/19Wtrmp9U=; b=uEAbyhZ6X6SuCn6jcBwQEJVbZkJousSm++jyc+NlDS7+rJN2to045OFBQVsZycZaPi GpZ1dhsZWLIv9imQwtJJffw0s2ZgmRWWoCf5tsOR4Tvpt4zHetV0a2HjpE7uOs7TMMy6 YKKM15AkmgPht87r4Trg1C+O98JJg+/tlR0SfOvOxCJlO6qeZrjZE/bBcwhNOB2ilRcB Fr0JYWztmbLyQ7p/OfO4QBNWg5bvmt/lO4KG6l4Ni9ljbwwXCgjFlliIqVKEg8diqJgW +YEejD/L3gCAuq3yz+xkjMOmFSfV6mfbgkMBxt727B4NwN34gVPMVLusuk6nVlgH4RbC EeMg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Rf6i2Zj4Akdxf8rr1fq1HvfOzQn4QOzYc/19Wtrmp9U=; b=aBTgf1k6zpytC+E8LWWsjGqbSJSmF391+ef390pR98Q4nEn8Ci0/Dy81t4aVmDxgDo wusZKmKlbaHpO2SXYc4XY5EGVxExdTC1Go9Q8TtEa2wj4Xr5HBBjL4W362nP/hwiMTUY W6COUdlBk5oy+6Q6v4JKs/IzAIMYZ2UqEnYTkCRMcUH9bOby9/pwvVz/eDdrW+41wW2k cXEkYNh+RspHot2wvdZwkCtXHQiIajigPe+NJVQMemkxvfHYWmLhXOG3ocDFdJk/W8HO JVSJQdOEMd+HFklIX1ZfjWEcuU1YVq+oqNDV+J2TVfVEhg/5yRusQAXlRUfnhDhhveD3 ie0g==
X-Gm-Message-State: APjAAAWu8dIKtRQRV0wYSbrFY5vPpyD9394Uj8zGMmfXNtfe57Mb8ftZ ZmdhbvLyE/syMG5aSGnk+sVoU/qeg65VP8kOH1M=
X-Google-Smtp-Source: APXvYqxqKNLTh1X64aVJJX7AdmQ/ApDULuYhlqa4esE5ZYdun7ritTCqkNzCfSKaatKMbkIbLU51deaJk/9Y6ES8AOY=
X-Received: by 2002:a6b:bf01:: with SMTP id p1mr17208296iof.181.1560526265099; Fri, 14 Jun 2019 08:31:05 -0700 (PDT)
MIME-Version: 1.0
References: <156030332758.5903.11787427451647585397.idtracker@ietfa.amsl.com>
In-Reply-To: <156030332758.5903.11787427451647585397.idtracker@ietfa.amsl.com>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Fri, 14 Jun 2019 11:30:54 -0400
Message-ID: <CAEz6PPRa=XUZyU5pq+f69Av+RZoWHDC497RVGqGw8+wA+fp8-w@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
Cc: The IESG <iesg@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>
Content-Type: multipart/alternative; boundary="000000000000b1ad11058b4a55a3"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/nJ6AHezK-lfY6Jd43tE3qEOZ3MI>
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 15:31:09 -0000

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

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

>
> (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 indicat
ing 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.