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

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Tue, 11 Jun 2019 18:35:27 -0700

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?

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

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

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

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

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

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 14 Jun 2019 11:30:54 -0400

Hi Roman,

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

> https://datatracker.ietf.org/doc/draft-ietf-teas-yang-te-topo/
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”.

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

> text doesn’t indicate whether the highest priority is a largest or smallest
[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]

> “border_nodes_connected_via_mesh_of_abstract_links topology” use an
[Xufeng]: Will change the underscores to hyphens.

> -- Section 5.6.  Typo.  s/cooresponding/corresponding/
[Xufeng]: Thanks for these catches. Will fix them as suggested.

---

From: Roman Danyliw <[email-masked]>
Date: Fri, 14 Jun 2019 19:19:36 +0000

Hi Xufeng!

On Jun 14, 2019, at 11:31 AM, Xufeng Liu <[email-masked]<mailto:[email-masked]>> 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 <[email-masked]<mailto:[email-masked]>> wrote:
Roman Danyliw has entered the following ballot position for
draft-ietf-teas-yang-te-topo-21: No Objection

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.

[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:

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

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

Page 87:
[OLD]:
       leaf priority {
         type uint16;
         description
            A lower number indicates a higher priority. The highest priority is 0. ";
       }
[END]

(4) Editorial Nits

Thanks for making these other changes and for the document.

Roman

---

From: Xufeng Liu <[email-masked]>
Date: Mon, 17 Jun 2019 21:36:30 -0400

Hi Roman,

(2) Section 4.2.  Per “Although an authorized client MAY receive a TE
topology

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

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

Thanks,

- Xufeng

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 19 Jun 2019 08:40:46 +0000

Hi!

From: Xufeng Liu [mailto:[email-masked]]
Sent: Monday, June 17, 2019 9:37 PM
To: Roman Danyliw <[email-masked]>
Cc: The IESG <[email-masked]>; [email-masked]; Lou Berger <[email-masked]>; TEAS WG Chairs <[email-masked]>; TEAS WG <[email-masked]>
Subject: Re: Roman Danyliw's No Objection on draft-ietf-teas-yang-te-topo-21: (with COMMENT)

Hi Roman,

[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