Subject: [i2rs] Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT)

From: "Benoit Claise" <[email-masked]>
Date: Thu, 19 Jan 2017 03:23:48 -0800

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.

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 19 Jan 2017 14:21:55 +0100

>           router. This number uniquely identifies the router within an

For the sake of completeness, RFC 8022 has:

       leaf router-id {
         type yang:dotted-quad;
         description
           "A 32-bit number in the form of a dotted quad that is used by
            some routing protocols identifying a router.";
         reference
           "RFC 2328: OSPF Version 2.";
       }

Using yang:dotted-quad seems appropriate here.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jan 2017 09:23:26 -0500

Benoit: 

I would agree that you need a discuss regarding the security considerations
in the draft.  However, I disagree that the security considerations should
align with  
https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines, as mentioned
by others.

I believe that the security considerations should have additional fields.  I
have written the draft-hares-i2rs-yang-sec-consider-00.txt in order to start
a conversation regarding this point.  I would appreciate you holding the
DISCUSS until we reach agreement on this point. You can reference the draft
at: 

https://datatracker.ietf.org/doc/draft-hares-i2rs-yang-sec-consider/
 
Sue 

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Thursday, January 19, 2017 6:24 AM
To: The IESG
Cc: [email-masked]; [email-masked];
[email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: [i2rs] Benoit Claise's Discuss on
draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT)

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

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:

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?

      description

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.

4.

       leaf-list router-id {
           type inet:ip-address;
           description

should expedite this publication), but any good reason why this is aligned
with its definition?

- 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

   o  Parentheses enclose choice and case nodes, and case nodes are also
      marked with a colon (":").

- 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-masked]
https://www.ietf.org/mailman/listinfo/i2rs

---

From: "Carl Moberg (camoberg)" <[email-masked]>
Date: Fri, 20 Jan 2017 06:13:07 +0000

Inline below:

> On Jan 19, 2017, at 12:23 PM, Benoit Claise (bclaise) <[email-masked]> wrote:
> 

 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.

---

From: Benoit Claise <[email-masked]>
Date: Fri, 20 Jan 2017 08:19:18 +0100

>   I agree that this is a reasonable tradeoff, and am fine with leaving it as is.
Thanks Carl.
Authors, some text clarifying that all data definitions are optional 
configuration (e.g. no config false, default values or mandatory 
statements) and stressing that this is per design would be an excellent 
addition to the draft.

Regards, Benoit

---

From: "Susan Hares" <[email-masked]>
Date: Fri, 20 Jan 2017 06:58:08 -0500

Carl: 

Thank you for the re-review of this YANG Model.   My understanding is that you are fine with the trade-off the authors have made to handle this work. 

“”"

Sue 

-----Original Message-----
From: Carl Moberg (camoberg) [mailto:[email-masked]] 
Sent: Friday, January 20, 2017 1:13 AM
To: Benoit Claise (bclaise)
Cc: The IESG; [email-masked]; [email-masked]; [email-masked]; [email-masked]; Ronald P. Bonica; Martin Björklund
Subject: Re: Benoit Claise's Discuss on draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT)

 Inline below:

> 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
> an example.  They went to far in trying to mimic a real module.
> 
>  1.  change the name to example-ospf-topology  2.  change the 
> namespace to urn:example:ospf-topology  3.  remove the top-level 
> statements:
> https://www.ietf.org/mail-archive/web/yang-doctors/current/msg00031.ht
> ml I'm waiting for final blessing on v8 any time soon. Hence this late 
> DISCUSS.

“”"

“”"

> should expedite this publication), but any good reason why this is 
> aligned with its definition?
>    typedef router-id {
>       type yang:dotted-quad;
>       description
> - There are multiple slightly different definitions of the datastore 
> in the different RFCs.
> - 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"
> ospf-topology and isis-topology are examples, and defined as such in 
> this document
> 
> - section 7
> OLD: 
> The moodel defines
> NEW:
> The model defines
> 
>

---

From: "Susan Hares" <[email-masked]>
Date: Thu, 19 Jan 2017 13:20:30 -0500

Lada and Jurgen: 

The reason why is the draft-ietf-rtgwg-routing-types-00 was not firm by that
time period, and Benoit suggested we publish rather than wait.   The
publication has taken long enough to bring these drafts closer.   

Sigh, 

Sue 

-----Original Message-----
From: Ladislav Lhotka [mailto:[email-masked]] 
Sent: Thursday, January 19, 2017 8:31 AM
To: Jürgen Schönwälder
Cc: Benoit Claise; [email-masked]; Martin Björklund;
[email-masked]; [email-masked];
[email-masked]; The IESG; Carl Moberg (camoberg); [email-masked]
Subject: Re: [i2rs] Benoit Claise's Discuss on
draft-ietf-i2rs-yang-l3-topology-08: (with DISCUSS and COMMENT)

> On 19 Jan 2017, at 14:21, Juergen Schoenwaelder
<[email-masked]> wrote:
>> https://tools.ietf.org/html/draft-ietf-rtgwg-routing-types-00 (btw, 
>> we should expedite this publication), but any good reason why this is 

Right, inet:ip-address value may also contain a zone index, which is clearly
undesirable in router-id.

Lada

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 19 Jan 2017 14:31:19 +0100

> On 19 Jan 2017, at 14:21, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Right, inet:ip-address value may also contain a zone index, which is clearly undesirable in router-id.

Lada