> Having ' This data is modeled in YANG using "config true" nodes ' sort of
> suggests that the original definition holds sway and so contradicts the
> previous sentence.  And for this sentence to make sense, a reader would
> really have to understand the debates over configuration, state and how to
> model them that have been going on for so long which means that regardless
> of how true it is, it does not really belong in a definition.
> 
> There is no reference back to the previous definition, as to whether or
not
> the latest definition is meant to be the same or not.  I find this
confusing.
> 
> I think that the previous definition has to appear in this I-D, since it
has
> influenced so much work, and this I-D then needs to go on to say

It is indeed confusing to the reader if a document referring to a standard
track RFC defines and uses a term differently.
I agree that revising a term might become necessary though the revision
should be introduced properly.

> 
> 'We are revising it ..
> or
> 'We are not revising it ...
> 
> I have read the later posts but this one seemed to catch the crux of my
> discontent.
> 
> Tom Petch
> 
> > > Even worse, configuring protocol learned values is liable to break
> > > things.  To use one example, many
> protocols
> > > negotiate timers.  The value that a given systems starts with is the
> > > configured value.  The value that it learns from the protocol
> exchange is
> > > the operational value.  In fact, you better not try to configure
> that value
> > > or you are liable to break the protocol.
> >
> > Nobody proposed this, please take a look at the figure in the document
> > to understand the information flow and where the distinction is made.
> >
> > /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/>
> 
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to