IETF Logo Mail Archive

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

Roman Danyliw <rdd@cert.org> Wed, 19 June 2019 08:40 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 8E59B120455; Wed, 19 Jun 2019 01:40:53 -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 j2Dcww9kHU1X; Wed, 19 Jun 2019 01:40:51 -0700 (PDT)
Received: from veto.sei.cmu.edu (veto.sei.cmu.edu [147.72.252.17]) (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 E288A120462; Wed, 19 Jun 2019 01:40:50 -0700 (PDT)
Received: from korb.sei.cmu.edu (korb.sei.cmu.edu [10.64.21.30]) by veto.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5J8emmU033536; Wed, 19 Jun 2019 04:40:48 -0400
DKIM-Filter: OpenDKIM Filter v2.11.0 veto.sei.cmu.edu x5J8emmU033536
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1560933648; bh=gqUZGhpKpEhjN3nGwG10ArYOPTm8EIOaEArchGTSmAY=; h=From:To:CC:Subject:Date:References:In-Reply-To:From; b=rw+l4NX8kwsLy/W3CjTqdZ8z3kQwmTbgGjI3Ouaw4EFMgBbZdBhyK7lrB+8SKgTm2 Q9UKS3iawtQcZznttz7z+RYuLFtPeEf5YsfMc6Hjl/5CuRolzjcIHYGEuaVKgl4lFo DtX411CQrsli+BbjYO0uddJsVEHI4rgcHDV+JXMI=
Received: from CASCADE.ad.sei.cmu.edu (cascade.ad.sei.cmu.edu [10.64.28.248]) by korb.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id x5J8elBN008200; Wed, 19 Jun 2019 04:40:47 -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; Wed, 19 Jun 2019 04:40:47 -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///82b+ABWNaAIABxYLQ
Date: Wed, 19 Jun 2019 08:40:46 +0000
Message-ID: <359EC4B99E040048A7131E0F4E113AFC01B339B573@marathon>
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>
In-Reply-To: <CAEz6PPReEkiAjhKxU-Rx1bwXGkQoCfOWy_pZf_hTFAHYEai5kw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.22.6]
Content-Type: multipart/alternative; boundary="_000_359EC4B99E040048A7131E0F4E113AFC01B339B573marathon_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/teas/1uX2Ni8GBZkGA-iYMx6fT5OkzFQ>
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: Wed, 19 Jun 2019 08:40:54 -0000

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>; 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>
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

v2.23.0 | Report a Bug | By Email