-
Notifications
You must be signed in to change notification settings - Fork 0
Home
Robert Wilton edited this page Sep 28, 2017
·
11 revisions
- Do all top level containers in a NMDA compliant module have to be "config true" containers?
- Is an new NMDA compliant module allowed to have a top level "-state" container?
- When should a transitional "foo-state" module be generate for NMDA compliant module "foo"?
- How do I generate the transitional "foo-state" module for NMDA compliant module "foo"?
- When is it necessary to wait for updated versions of non-NMDA style published model before updating an augmenting model to conform to NMDA?
- If we have an non-NMDA draft in progress then is it OK to publish the non NMDA model followed by an NMDA version?
- Which YANG modules already specified need to be updated to be NMDA compliant?
- What happens to the old config false "-state" tree in a published YANG module when a NMDA compatible revision is produced?
- What does it mean for a server to be NMDA compliant?
- In which situations can <intended> differ from <running>?
- Does an NMDA compliant implementation have to expose the <operational> datastore?
- Can I find out whether a device has <intended> that can differ from <running>?
- Does a server have to expose <operational> to be NMDA compliant?
- Can an NMDA compliant device only support configuration and no operational state?
- Can an NMDA compliant device only support operational state and not be configurable?
- What if the device cannot provided an applied configuration value?
- Are devices allowed to modify the contents of <running>?