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

["tom p." <[e-mail]>]

----- Original Message -----
From: "Xufeng Liu" <[e-mail]>
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

> Thanks,
>
> - Xufeng
>
> > -----Original Message-----
> > From: tom p. [mailto:[e-mail]]
> > Sent: Saturday, January 13, 2018 8:03 AM
> > To: Xufeng Liu <[e-mail]>; ietf <[e-mail]>
> > Cc: [e-mail]; [e-mail];
> > [e-mail]; Alia Atlas <[e-mail]>
> > Subject: Re: Last Call: <draft-ietf-rtgwg-yang-rip-06.txt> (A YANG
Data Model
> > for Routing Information Protocol (RIP)) to Proposed Standard
> >
> > 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" <[e-mail]>
> > Sent: Friday, January 12, 2018 8:18 PM
> >
> >
> > > 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:[e-mail]]
> > > > Sent: Wednesday, December 20, 2017 12:13 PM
> > > >
> > > >  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" <[e-mail]>
> > > > > 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
> > > > > > [e-mail] mailing lists by 2017-12-12. Exceptionally,
> > comments
> > > > may
> > > > > be
> > > > > > sent to [e-mail] 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.
> > > > > >
> > > > >
> > >
> > >
>
>