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

[Roman Danyliw <[e-mail]>]

Hi Xufeng!

On Jun 14, 2019, at 11:31 AM, Xufeng Liu <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> 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