Subject: RE: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model for Routing Information Protocol (RIP)) to Proposed Standard

From: Xufeng Liu <[email-masked]>
Date: Fri, 12 Jan 2018 20:18:27 +0000

Hi Tom,

Thanks for your valuable comments. We have updated the document with https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rip-08, to address these comments.

Regards,
- Xufeng

> -----Original Message-----
> From: tom p. [mailto:[email-masked]]
> Sent: Wednesday, December 20, 2017 12:13 PM
> To: tom p. <[email-masked]>; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG Data Model
> for Routing Information Protocol (RIP)) to Proposed Standard
> 
> 
> 
>  I think that this I-D falls somewhat short of the standard necessary for
> advancement.
> 
>  'reference' statements are almost wholy lacking from the YANG module and
> while it might be reasonable to expect the reader to know where to find
> information on RIP or RIPng, I do not think that that extends to other IGP or
> IPsec.  If you want to see how it SHOULD be done, look at
>         draft-ietf-netmod-rfc7277bis-01
>  One or more 'reference' statement per 'container' or'leaf' statement is  a good
> starting point.
[Xufeng] The situation is different from RFC7277, where attributes from different referenced documents are put together in a same container. In the RIP model, almost all attributes refer to the same three documents RFC2453, RFC2080, and RFC1724. If we add them to each container or leaf, we'd have to repeat these three everywhere. Therefore we put the references at the beginning to avoid the repetition. In case when some specific reference is needed, such as authentication, we add the reference to RFC8177 in that container. Is this ok?

> 
>  Talking of which,
>     [I-D.bjorklund-netmod-rfc7223bis]
>     [I-D.bjorklund-netmod-rfc7277bis]
>     [I-D.acee-netmod-rfc8022bis]
>  have all been replaced.  I am unclear whether or not this invalidates  the
> announcement, since these appeared in the announcement as downrefs.
[Xufeng] Updated in the new version.
> 
>  Common (best) practice is to then include all the references from the  YANG
> module in a separate section immediately prior to the module itself  so that the
> reader can readily find them.
>  Again
>         draft-ietf-netmod-rfc7277bis-01
>  Section 4 is an example of how to do this.
[Xufeng] We use Sec 1.3 for this purpose.
> 
>  The YANG module does reference
>            RFC 1724
>  but I think that that makes it Normative not Informative, as it  currently is.
[Xufeng] Changed it to normative as you suggested.
> 
>  The Abstract is limp.
>  "This document describes a data model for the Routing Information
>     Protocol (RIP).  "
>  So what?.  This should tell me what I can do, e.g. configure, manage,  get
> statistics or what?
>  draft-ietf-netmod-rfc7277bis-01
>  gives a better example.  At this point in time, with NMDA causing  significant
> changes, the Abstract would do well to mention where the I-D  stands with
> regard to this.
[Xufeng] Updated with more information as you suggested.
> 
>  There is now an emerging RFC on tree diagrams
>  draft-ietf-netmod-yang-tree-diagrams-03
>  The authors might consider using and referencing this.
[Xufeng] New version references the latest draft now.
> 
>  Tom Petch
> 
> > ----- Original Message -----
> > From: "The IESG" <[email-masked]>
> > Sent: Tuesday, November 28, 2017 4:29 PM
> > >
> > > The IESG has received a request from the Routing Area Working Group
> WG
> > > (rtgwg) to consider the following document: - 'A YANG Data Model for
> > Routing
> > > Information Protocol (RIP)'
> > >   <draft-ietf-rtgwg-yang-rip-06.txt> as Proposed Standard
> > >
> > > The IESG plans to make a decision in the next few weeks, and
> solicits
> > final
> > > comments on this action. Please send substantive comments to the
> > > [email-masked] mailing lists by 2017-12-12. Exceptionally, comments
> may
> > be
> > > sent to [email-masked] instead. In either case, please retain the
> > beginning of
> > > the Subject line to allow automated sorting.
> > >
> > > Abstract
> > >
> > >
> > >    This document describes a data model for the Routing Information
> > >    Protocol (RIP).  Both RIP version 2 and RIPng are covered.
> > >
> >

---

From: Yingzhen Qu <[email-masked]>
Date: Fri, 12 Jan 2018 20:54:43 +0000

Hi Xufeng,

Thanks for the update. 

Adam has comments about the description of address and Benoit has some nits comments, are you going to address those soon? 

Thanks,
Yingzhen

On 1/12/18, 12:18 PM, "Xufeng Liu" <[email-masked]> wrote:

    Hi Tom,

    Regards,
    - Xufeng

---

From: Xufeng Liu <[email-masked]>
Date: Fri, 12 Jan 2018 21:00:54 +0000

Hi Yingzhen,

Yes. Thanks for the reminder.

Regards,
- Xufeng

> From: Yingzhen Qu [mailto:[email-masked]]
> Sent: Friday, January 12, 2018 3:55 PM
> To: Xufeng Liu <[email-masked]>; tom p. <[email-masked]>;
> [email-masked]
> [email-masked]
> Adam has comments about the description of address and Benoit has some nits
> comments, are you going to address those soon?
> 
> Thanks,
> Yingzhen
> 
>     Thanks for your valuable comments. We have updated the document with
> https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rip-08, to address these
> comments.
> 
>     Regards,
>     - Xufeng
> 
>     [Xufeng] The situation is different from RFC7277, where attributes from
> different referenced documents are put together in a same container. In the RIP
> model, almost all attributes refer to the same three documents RFC2453,
> RFC2080, and RFC1724. If we add them to each container or leaf, we'd have to
> repeat these three everywhere. Therefore we put the references at the
> beginning to avoid the repetition. In case when some specific reference is
> needed, such as authentication, we add the reference to RFC8177 in that
> container. Is this ok?
> 
>     >
>     >  Talking of which,

---

From: "tom p." <[email-masked]>
Date: Sat, 13 Jan 2018 13:02:54 -0000

Xufeng

Looks good

The only outstanding thought is about the tree diagram where the netmod
I-D says
"As tree diagrams are intended to provide a simplified
   view of a module, diagrams longer than a page should generally be
   avoided.   "
but, as was discussed on the netmod WG list, this can be hard to
achieve.  You currently have four pages and the only way I can see to
split this would be to separate the ipv4 and ipv6 sections with a brief
paragraph, just a sentence,  separating the three parts of the tree
diagram, albeit with one long part and two short parts.  I would
consider this worth the effort but leave it up to you.

If you look at the OSPF and BFD YANG tree diagrams you can see how
sub-dividing can work.

(My own take is that too a long tree diagram reflects a too flat module
structure and that the module structure should be changed, but this view
has yet to gain traction!)

I take your point about the description clauses.

Tom Petch

----- Original Message -----
From: "Xufeng Liu" <[email-masked]>
Sent: Friday, January 12, 2018 8:18 PM

> Thanks for your valuable comments. We have updated the document with
https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rip-08, to address
these comments.
> [Xufeng] The situation is different from RFC7277, where attributes
from different referenced documents are put together in a same
container. In the RIP model, almost all attributes refer to the same
three documents RFC2453, RFC2080, and RFC1724. If we add them to each
container or leaf, we'd have to repeat these three everywhere. Therefore
we put the references at the beginning to avoid the repetition. In case
when some specific reference is needed, such as authentication, we add
the reference to RFC8177 in that container. Is this ok?

---

From: Xufeng Liu <[email-masked]>
Date: Tue, 23 Jan 2018 22:18:18 +0000

Hi Tom,

Thanks for the thought. Section 3 includes the complete tree diagram for the model. We have received different suggestions and opinions on this topic. I have read your comments on the NETMOD mailing list. Your opinion is appreciated. However, we have also received comments to request the complete, un-altered tree diagram for easy referencing. Some implementers mentioned that the tree diagram is the first section they look at, and the one that needs to be referenced often. 

I'd hope a consensus on this. For now, we'd keep it as is.

Thanks,

- Xufeng

> Sent: Saturday, January 13, 2018 8:03 AM
> To: Xufeng Liu <[email-masked]>; ietf <[email-masked]>
> [email-masked]; Alia Atlas <[email-masked]>
> The only outstanding thought is about the tree diagram where the netmod I-D
> says "As tree diagrams are intended to provide a simplified
> but, as was discussed on the netmod WG list, this can be hard to achieve.  You
> currently have four pages and the only way I can see to split this would be to
> separate the ipv4 and ipv6 sections with a brief paragraph, just a sentence,
> separating the three parts of the tree diagram, albeit with one long part and two
> short parts.  I would consider this worth the effort but leave it up to you.
> 
> If you look at the OSPF and BFD YANG tree diagrams you can see how sub-
> dividing can work.
> 
> (My own take is that too a long tree diagram reflects a too flat module structure
> and that the module structure should be changed, but this view has yet to gain
> traction!)
> 
> > >         draft-ietf-netmod-rfc7277bis-01  One or more 'reference'
> > > statement per 'container' or'leaf'
> statement is  a good
> > > starting point.
> from different referenced documents are put together in a same container. In
> the RIP model, almost all attributes refer to the same three documents RFC2453,
> > >         draft-ietf-netmod-rfc7277bis-01  Section 4 is an example of
> > > how to do this.

---

From: "tom p." <[email-masked]>
Date: Wed, 24 Jan 2018 16:12:27 -0000

----- Original Message -----
From: "Xufeng Liu" <[email-masked]>
Sent: Tuesday, January 23, 2018 10:18 PM

> Hi Tom,
>
> Thanks for the thought. Section 3 includes the complete tree diagram
for the model. We have received different suggestions and opinions on
this topic. I have read your comments on the NETMOD mailing list. Your
opinion is appreciated. However, we have also received comments to
request the complete, un-altered tree diagram for easy referencing. Some
implementers mentioned that the tree diagram is the first section they
look at, and the one that needs to be referenced often.
> I'd hope a consensus on this. For now, we'd keep it as is.

OK.  I can live with it.

Tom Petch

> > but, as was discussed on the netmod WG list, this can be hard to
achieve.  You
> > If you look at the OSPF and BFD YANG tree diagrams you can see how
sub-
> > https://tools.ietf.org/html/draft-ietf-rtgwg-yang-rip-08, to address
these
> > > > while it might be reasonable to expect the reader to know where
to
> > find
container. In
> > > >  Common (best) practice is to then include all the references
from
> > the  YANG
> > > > module in a separate section immediately prior to the module
itself
> > so that the
> > > >  gives a better example.  At this point in time, with NMDA
causing
> > significant
> > > > changes, the Abstract would do well to mention where the I-D
stands
> > with
> > > > > > The IESG has received a request from the Routing Area
Working
> > Group
> > > > WG
> > > > > > (rtgwg) to consider the following document: - 'A YANG Data
Model
> > for