Inline below:
> On Jan 19, 2017, at 12:23 PM, Benoit Claise (bclaise) <[email protected]>
> wrote:
>
> Benoit Claise has entered the following ballot position for
> draft-ietf-i2rs-yang-l3-topology-08: Discuss
>
> 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-l3-topology/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 1. The examples.
> In the AUTH48 for the RESTCONF RFC, the example YANG module discussion
> came up (again). And the examples in draft-ietf-i2rs-yang-l3-topology
> were also discussed. Here is the feedback from one YANG doctor, from a
> couple of days ago.
>
> Look at this:
>
> module example-ietf-ospf-topology {
> ...
> namespace
> "urn:ietf:params:xml:ns:yang:example-ietf-ospf-topology";
> ...
> description
> "This module defines a model for OSPF network topologies.
> Copyright (c) 2017 IETF Trust and the persons identified as
> authors of the code.
>
>
> They are using the IANA-controlled namespace w/o registering it.
>
> This module *really* looks like a proper normative module, rather than
> an
> example. They went to far in trying to mimic a real module.
>
> It is clear that we need more guidelines in 6087 for how to write
> example modules.
>
> I was going to ask if this module passed YANG doctor review - then I
> checked and saw that version -02 was reviewed, which didn't include
> this example. How should we (the YANG doctors) handle such a case?
>
> In this case they should:
>
> 1. change the name to example-ospf-topology
> 2. change the namespace to urn:example:ospf-topology
> 3. remove the top-level statements:
> organization, contact, revision
>
> 4. change the top-level description to what the text in the draft
> says:
>
> description
> "This module is intended as an example for how the
> Layer 3 Unicast topology model can be extended to cover
> OSFP topologies.";
>
> (same for the other example module)
>
>
> As I mentioned to the authors, respective chairs and AD already, we
> should follow the decision in this NETMOD email thread
> https://www.ietf.org/mail-archive/web/netmod/current/msg17428.html
> This will hopefully resolve fast. Once settled, the examples should be
> updated.
>
> 2. The security considerations should be better aligned with
> https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as
> mentioned by others.
>
> 3. Carl Moberg, as YANG doctor, reviewed v1 of the draft.
> https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.html
> I'm waiting for final blessing on v8 any time soon. Hence this late
> DISCUSS.
I have re-reviewed the current (-08) draft to follow up on my remarks from
-01. The only remark that has not been addressed in the draft is the following:
“”"
1. All data definitions are optional configuration (e.g. no config false,
default values or mandatory statements). This seems to open up for many odd
combinations of e.g. existing and non-existing leafs in node, link, and
termination-points. This is also true for the notifications. Is this by design
or something that needs additional work?
“””
The response from the authors (through Alex Clemm) during the first review was
that:
“”"
This is actually by design, as there is always the issue for leaving
flexibility for implementations (I know, this flexibility can be at odds with
ease-of-use) but we shall review this.
“””
I agree that this is a reasonable tradeoff, and am fine with leaving it as is.
> 4.
>
> leaf-list router-id {
> type inet:ip-address;
> description
> "Router-id for the node";
> }
>
> We don't want to wait for
> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, we
> should expedite this publication), but any good reason why
> this is aligned with its definition?
> typedef router-id {
> type yang:dotted-quad;
> description
> "A 32-bit number in the dotted quad format assigned to each
> router. This number uniquely identifies the router within an
> Autonomous System.";
> }
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - 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]
>
> - 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.
>
> - Instead of:
>
> Brackets
> enclose list keys, "rw" means configuration, "ro" operational state
> data, "?" designates optional nodes, "*" designates nodes that can
> have multiple instances. Parantheses enclose choice and case nodes.
>
> Use the 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.
>
> Btw, no need to repeat this convention in section 6.1.1 and 6.2.1
>
> - I agree with Suresh: "OSPF and IS-IS are used later in the document as
> examples but this section (especially Figure 1) seems to treat them as
> more than examples"
> Either modify figure 1, or even better, stress in section 3 that
> ospf-topology and isis-topology are examples, and defined as such in this
> document
>
> - section 7
> OLD:
> The moodel defines
> NEW:
> The model defines
>
>
_______________________________________________
i2rs mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/i2rs
