On Thu, Apr 24, 2014 at 6:15 AM, t.petch <[email protected]> wrote:
> ----- Original Message ----- > From: "Susan Hares" <[email protected]> > To: "'t.petch'" <[email protected]>; "'Edward Crabbe'" > <[email protected]>; <[email protected]> > Sent: Wednesday, April 23, 2014 5:21 PM > > Tom: > > > > 100% agree with your comments. I2RS cares whether it is read-only or > > read-write. My work toward the revision found: > > > > - RBNF RBNF did not even allow you a place to r/w or r-only or > permissions > > (needed for security, but that's my next draft). > > - The yang tree I wrote was r-w for config, but did not express the > ro-only > > tree. I wanted some feedback to figure out why I had 2 write 2 trees. > > (your telling me it is a yang short-coming). > > Sue > > That is a feature of YANG. Spend half a day on the netmod WG archives > for 1H2013, particularly May and June and for interfaces-cfg, and all > will be clear. > > As Ladislav said on 2May13, > > "In the current model, the operational state data are not present unless > the corresponding entry in the "interface" list is *configured*. So, > what I have in mind is a data tree like this: ..." > > That is, 'config false' nodes under a 'config true' node do not get > instantiated in the data model unless and until the 'config true' node > is configured. So if you have the one routing table, you will be unable > to see the routes learnt via BGP - 'config false' - unless and until you > configure the table by creating a static route - 'config true'. > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > where it is written down:-( > > I am confused. How would a router that has no 'eth27' interface configured suddenly start reporting statistics for an interface named 'eth27'? I think the operational state is usually related to the configuration, wrt/ instance naming (at least). The same YANG module could have config data and operational state. NETCONF could read everything and write config, and I2RS could read everything and write operational state. Even if the objects are separated, the data types, identities, features, and instance naming can be easily shared across protocols. Using different data types and instance naming for config and operational state would mean that humans and machines would need to know both, and be able to translate from 1 to the other. This would be an operational nightmare. > Tom Petch > > Andy > > > - UML seems to be able to handle read/write variants, and I'm looking > to see > > if graphical tools will help the developer. > > > > Not shown in the reduction: > > ... And I started working on BGP, ISIS, RIP.. only to find some of > these > > issues you mention. DCHP and NTP. Any suggestions or help would be > > gratefully accepted. > > > > I will continue to try to get more details on Yang++ and ForCES to see > how > > many wheels fall off. > > > > Sue > > > > -----Original Message----- > > From: i2rs [mailto:[email protected]] On Behalf Of t.petch > > Sent: Wednesday, April 23, 2014 12:08 PM > > To: Edward Crabbe; [email protected]> > > YANG (with NETCONF) is designed for writing configuration and reading > > everything else, and does an excellent job at it. Trouble is, for me, > that > > configuration doesn't mean what I think of it as; it means, in the > YANG > > context, what you might put in through the CLI and it excludes > everything > > else, such as data learnt via a protocol. > > > > Take routing. A static route is configuration; anything learnt, via > BGP, > > IS-IS, RIP etc, is not configuration (and is read only). > > > > An interface configured automatically on a hot-plugged card is not > > configuration; adding 'ospf passive' is. > > > > And so on, for DHCP, NTP, ..... > > > > In practice, this means that the YANG model comes in twin sets, one of > > read-write configuration and one of read-only not-configuration (as > can be > > seen in the current I-Ds that the netmod WG is producing) with no > formal way > > in YANG of relating the one to the other. So if you want e.g. the > routing > > table, the host software has to know where to look and how to combine > the > > pieces to produce a coherent picture (and then you cannot edit most of > it). > > > > So if I2RS never wants to write anything to a router, YANG is fine; if > I2RS > > is only producing a Information Model (and ignoring whether or not > data is > > read-only or read-write), and not moving on to an implementation, then > YANG > > is fine. > > > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an > extension > > to YANG, a new sub-statement for all data objects, semantics not too > clear > > but designed to separate out the not-configuration, learnt via a > protocol, > > 'editable-state' (and in doing so, making it read-write - but still > 'config > > false'). > > > > Yes, YANG allows for such extensions but it seems to me that I2RS > would then > > be getting YANG++ (and NETCONF++), once the necessary work has been > done. > > > > Tom Petch > > > > > > ----- Original Message ----- > > From: "Edward Crabbe" <[email protected]> > > To: <[email protected]> > > Sent: Friday, April 11, 2014 6:50 PM > > Subject: [i2rs] consensus on I2RS protocol and model > > > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
