On Fri, Jan 08, 2016 at 01:46:44PM +0000, Acee Lindem (acee) wrote: > > The draft is quite succinct and I’m not sure how you and Juergen do not > agree that there are requirements beyond intended/applied state. Perhaps > you do not agree with them? Refer to requirements 3.(B & C) and 4.(B & C). > For your convenience, I’ve excerpted them below: > > > 3. Separation of the applied configuration and derived state aspects > of operational state; ability to retrieve them independently and > together > > A. Be able to retrieve only the applied configuration aspects of > operational state > > B. Be able to retrieve only the derived state aspects of > operational state
This is nothing new. See for example section 4.3.3.2 of RFC 6244. > C. Be able to retrieve both the applied configuration and > derived state aspects of operational state together Did you notice that 3.C talks about 'applied configuration'? > 4. Ability to relate configuration with its corresponding > operational state > > A. Ability to map intended config nodes to corresponding applied > config nodes > > B. Ability to map intended config nodes to associated derived > state nodes > > C. The mappings needs to be programmatically consumable I do not agree that 4.B and 4.C require to broaden the title. In fact, I wonder why 4.B is useful. If we agree that the applied config (an extended subset of the intended config) is the configration that determines what the device is doing, then we likely should have a mapping of the applied config to associated derived state. /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 netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
