Typo: - this is a duplicate of # 3-a + this is a duplicate of # 4-a
Kent On 9/10/15, 10:46 AM, "Kent Watsen" <kwat...@juniper.net> wrote: >[As co-chair] > >To facilitate the meeting, following is a straw man list of requirements >based on what I've read. Let's focus on refining this list during the >meeting. > > >1. Ability to interact with both intended and applied configuration > > a. The ability to ask the operational components of a system > (e.g., line cards) for the configuration that they are currently > using. This is the "applied configuration". > > b. applied configuration is read-only > > c. The data model for the applied configuration is the same as > the data model for the intended configuration (same leaves) > > d. For asynchronous systems, when fully synchronized, the data > in the applied configuration is the same as the data for the > intended configuration. > > >2. Applied configuration as part of operational state > > a. the ability to retrieve the applied configuration and > derived state nodes in a single protocol operation. > > >3. Support for both transactional, synchronous management > systems as well as distributed, asynchronous management > systems > > a. For asynchronous systems, the ability to request a protocol > operation to not return (i.e. block) until the intended > configuration has been fully synchronized. > > b. The protocol operation's response would indicate the result > of the operation (success, failure, partial, etc.) > > >4. Separation of configuration and operational state data; ability > to retrieve them independently > > a. be able to retrieve only the derived aspects of operational state > > b. be able to retrieve only the non-derived aspects of operational >state > > >5. Ability to retrieve operational state corresponding only to > derived values, statistics, etc. > > // this is a duplicate of # 3-a > > >6. 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 > > >7. Ability for distinct modules to leverage a common model-structure > > a. Scope is limited to IETF-defiend modules > b. multiple domain-specific trees are okay > c. multiple namespaces are okay > > > > >Thanks, >Kent > > > >_______________________________________________ >netmod mailing list >netmod@ietf.org >https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
