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

From: Benoit Claise <[email-masked]>
Date: Tue, 12 Dec 2017 16:31:15 +0100

Dear draft-ietf-i2rs-yang-l3-topology,

Checking v13 now, as the document is on the telechat in 2 days, it seems 
that none of my feedback below was into account or even discussed.
The feedback below was on v11, sent on Sept 27th.

Regards, Benoit
> Benoit Claise has entered the following ballot position for
> draft-ietf-i2rs-yang-l3-topology-11: 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:
> ----------------------------------------------------------------------
>
> Preliminary note: I hope I'm doing the right thing by updating this DISCUSS
> point as  I understand that the document is back to the WG. However, since I
> reviewed the version 11, since some of my ballot points have been addressed
> (thank you), and since I wanted to share my feedback publicly, here is my
> feedback.
>
> 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.
>
> 4.
>
>         leaf-list router-id {
>             type inet:ip-address;
>             description
>               "Router-id for the node";
>           }
>
> My initial DISCUSS was: 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.";
>       }
>
> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, it makes
> sense to import its router-id
>
>
> ----------------------------------------------------------------------
> 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.
>
> - section 7
> OLD:
> The moodel defines
> NEW:
> The model defines
>
>
> .
>

---

From: "Alexander Clemm" <[email-masked]>
Date: Wed, 13 Dec 2017 22:10:05 -0800

Hello Benoit,

I have incorporated your comments into -14 that I will post shortly.  Please
see replies inline for individual items. 

Thanks
--- Alex

-----Original Message-----
From: i2rs [mailto:[email-masked]] On Behalf Of Benoit Claise
Sent: Tuesday, December 12, 2017 7:31 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; Ladislav
Lhotka <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [i2rs] Benoit Claise's Discuss on
draft-ietf-i2rs-yang-l3-topology-11: (with DISCUSS and COMMENT)

Regards, Benoit
> 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
> Preliminary note: I hope I'm doing the right thing by updating this 
> DISCUSS point as  I understand that the document is back to the WG. 
> However, since I reviewed the version 11, since some of my ballot 
> points have been addressed (thank you), and since I wanted to share my 
> feedback publicly, here is my feedback.
>
> 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.
> This module *really* looks like a proper normative module, rather than 
> an example.  They went to far in trying to mimic a real module.
>

<ALEX> done.  We only have one example module now.  </ALEX>

>
> 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.
> 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
> My NEW DISCUSS: since is in IETF LC and on the telechat on Oct 12th, 
> it makes sense to import its router-id

<ALEX> This is only used in the example.  The point of the example is to
show how the model can be extended, not to define something normative, hence
I don't think there is a need to introduce a dependency here which would
only be distracting.
</ALEX>

<ALEX> done </ALEX>

> - There are multiple slightly different definitions of the datastore 
> in the different RFCs.
<ALEX> done (already in -13) </ALEX>
> The model defines

<ALEX> done </ALEX>

_______________________________________________
i2rs mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i2rs