Benoit Claise has entered the following ballot position for draft-ietf-i2rs-yang-network-topo-10: 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-i2rs-yang-network-topo/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Reading this document one more time, some more editorial comment - OLD: At the same time, where data specific to a network type does comes into play NEW: At the same time, where data specific to a network type does come into play - The figure shows two Service Functions - X1 and X2 - mapping onto a single L3 network element; this could happen, for example, if two service functions reside in the same VM (or server) and share the same set of network interfaces. You meant X1 and X3, mapping to the same Y2 L3 network element, right? - please expand ROADM - There are multiple slightly different definitions of the datastore in the different RFCs. Let's not add to the confusion. Pick one (RFC6241 should be the latest one) and mention the reference. - YANG definition "YANG: A data definition language for NETCONF" I would use: YANG is a data modeling language used to model configuration data, state data, Remote Procedure Calls, and notifications for network management protocols [RFC7950] - OLD: The abstract (base) network model is defined in the network.yang module. Its structure is shown in the following figure. Brackets enclose list keys, "rw" means configuration data, "ro" means operational state data, and "?" designates optional nodes. A "+" indicates a line break. NEW (cut/paste from RFC8022 and https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-09] o Brackets "[" and "]" enclose list keys. o Curly braces "{" and "}" contain names of optional features that make the corresponding node conditional. o Abbreviations before data node names: "rw" means configuration (read-write), "ro" state data (read-only), "-x" RPC operations or actions, and "-n" notifications. o Symbols after data node names: "?" means an optional node, "!" a container with presence, and "*" denotes a "list" or "leaf-list". o Parentheses enclose choice and case nodes, and case nodes are also marked with a colon (":"). o Ellipsis ("...") stands for contents of subtrees that are not shown. Note that you have two instances of this. - Final comment: the security considerations should be better aligned with https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as replied to Kathleen's DISCUSS. _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
