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, 19 July 2019 02:12 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 3264612002E; Thu, 18 Jul 2019 19:12:31 -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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 tlCdnZgciupu; Thu, 18 Jul 2019 19:12:29 -0700 (PDT)
Received: from mail-io1-xd30.google.com (mail-io1-xd30.google.com [IPv6:2607:f8b0:4864:20::d30]) (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 5F21812004E; Thu, 18 Jul 2019 19:12:29 -0700 (PDT)
Received: by mail-io1-xd30.google.com with SMTP id h6so55220330iom.7; Thu, 18 Jul 2019 19:12:29 -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=ET4xiY0pviLjtYIxJ1YXvRvOHLdCDAb1JpoGzgEwc+M=; b=Jjd00b9tz05iFAw5cRRZR0DFfxEv56D6TGTj5EIhGeAroyYwpgyjKVTKG2xc6iSpAG MFGm6qgQh+Gg0kJTQRdAGqIzm1a1AzdW73fEbqYaSJStymlgfn6Zu9abMpy92ri1UEfO uuCw4a7BOQlhOxl5kp8PCQlJrvZSTedz7zPz8akBTWobPzDarM8VWQ2Y2fabMb0TXRke r7gpA0bUER/vhZ9LmgTw0Vr+2gXi7Aq+SUFvO+fvNOlSINiWTTwEMQod/sWsncXMf9vO iHhemR1JwUuBnGyDmNdLHdx/O2kUNo3Bhbrx6Gw2Hn/mfHJuZ3b1FHZYDKSON0nL0jxx Hg5A==
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=ET4xiY0pviLjtYIxJ1YXvRvOHLdCDAb1JpoGzgEwc+M=; b=CdoLarntk+7z0FvG2Ef2NgPtjapQbMjW7kieoo6kBKt0B+P1ELt8ZUMZPS7qK+TPKq vsRCb/hZF9TvfYA4GPMTBa0YVIfEf5DsXg+hZS7oYZZYFVBqUIYbCvQm86tUJRVjCqBp QoAkCMdrTLOL8QccNHymwAJOKO0DCVbE1cth9I1SJIHeEz+NgGZy2ksaw2DxYdSEQgDq lla1PmqjlOzd314qjWaKayWCyAHdZDApWBJHXT6vE/ZqRWom/+08blUKevXGs1DnvfrP fz51SX7CAnOvVKIq+oxy3qvZG2kTyBlfc90r/0Tu3+x08mxlOyh/21hdicDHxvi02KGO pc/w==
X-Gm-Message-State: APjAAAX2o96iezp/l8vVOLtcZvpu3cAtQpjYOeaaTxrZh7zMsn9z9eUw t13IfUxEQCiirCUYytf4yBl1qvBQ55Ba+8pWqjc=
X-Google-Smtp-Source: APXvYqwJih4M5pE730/2TKigb1XkFqaZF0kd+aMwH426ZYfJ6p60QjXseqiL8oBqEyiwjl3v28KjxXGi2inVdEII1TE=
X-Received: by 2002:a5d:8347:: with SMTP id q7mr43611036ior.277.1563502348657; Thu, 18 Jul 2019 19:12:28 -0700 (PDT)
MIME-Version: 1.0
References: <156030332758.5903.11787427451647585397.idtracker@ietfa.amsl.com> <CAEz6PPRa=XUZyU5pq+f69Av+RZoWHDC497RVGqGw8+wA+fp8-w@mail.gmail.com> <5DEC3699-21C3-4DF2-AFC7-98FDEFB4562F@cert.org> <CAEz6PPReEkiAjhKxU-Rx1bwXGkQoCfOWy_pZf_hTFAHYEai5kw@mail.gmail.com> <359EC4B99E040048A7131E0F4E113AFC01B339B573@marathon>
In-Reply-To: <359EC4B99E040048A7131E0F4E113AFC01B339B573@marathon>
From: Xufeng Liu <xufeng.liu.ietf@gmail.com>
Date: Thu, 18 Jul 2019 22:12:17 -0400
Message-ID: <CAEz6PPQoNSPC-iLs-s03WBe5Ri6vwKdL2DdetD8VNm8hXxEGRg@mail.gmail.com>
To: Roman Danyliw <rdd@cert.org>
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>
Content-Type: multipart/alternative; boundary="00000000000018e8d6058dff4236"
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/56YUWpczqXb-tIOLARhcq7_Cg8k>
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, 19 Jul 2019 02:12:31 -0000

H Roman,

The new revision https://tools.ietf.org/html/draft-ietf-teas-yang-te-topo-22
has been posted to contain the changes.
Thanks,
- Xufeng

On Wed, Jun 19, 2019 at 4:40 AM Roman Danyliw <rdd@cert.org> wrote:

> Hi!
>
>
>
> *From:* Xufeng Liu [mailto:xufeng.liu.ietf@gmail.com]
> *Sent:* Monday, June 17, 2019 9:37 PM
> *To:* Roman Danyliw <rdd@cert.org>
> *Cc:* The IESG <iesg@ietf.org>rg>; draft-ietf-teas-yang-te-topo@ietf.org;
> Lou Berger <lberger@labn.net>et>; TEAS WG Chairs <teas-chairs@ietf.org>rg>;
> TEAS WG <teas@ietf.org>
> *Subject:* Re: Roman Danyliw's No Objection on
> draft-ietf-teas-yang-te-topo-21: (with COMMENT)
>
>
>
> Hi Roman,
>
>
>
> (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.
>
>
>
> [Xufeng]: Agree that a bit more description would be better. Would it be
> OK to add the following to the end of this section:
>
> Even though this data model allows to access TE topology information
> across clients, implementations MAY restrict access for particular clients
> to particular data fields. The Network Configuration Access Control Model
> (NACM) [RFC8341] provides such a mechanism.
>
> [Roman] Adding this clarifying language makes sense to me.  Thanks.
>
> Roman
>
>
>
>
>
> Thanks,
>
> - Xufeng
>
>
>