Hi,
Benoit Claise <bcla...@cisco.com> wrote:
> 2. The requirements.
> If there are still clarifications needed around the requirements in
> draft-openconfig-netmod-opstate-01 section 4
4.1. Applied configuration as part of operational state
Already in the title, this requirement mandates the solution.
I think the requirement is that if the device is "asynchronous", the
operator should (1) be able to learn this fact and (2) be able to
retrieve both intended and applied configuration.
4.2. Support for both transactional, synchronous management systems as
well as distributed, asynchronous management systems
If people say that they have systems that work like this, then ok.
4.3. Separation of configuration and operational state data; ability to
retrieve them independently
Ok, but retrieval is going to be a protocol issue, not a language issue.
4.4. Ability to retrieve operational state corresponding only to
derived values, statistics, etc.
Ok, but retrieval is going to be a protocol issue, not a language issue.
4.5. Consistent schema locations for configuration and corresponding
operational state data
This requirement also mandates the solution in the title. I think
Juergen formulated this requirement better when he wrote that it
should be 'easy' to locate state related to config for humans and
machines, in a 'robust' way.
Also, in the introduction, the document says:
These proposals are based on the assertion that YANG models should
be usable via a number of protocols (not solely IETF-defined
protocols such as NETCONF and RESTCONF)
I agree with this statement in priniciple, but only if the protocol is
suitable for YANG. I do not agree that YANG should be changed
everytime someone says that they want to use YANG with protocol X
(especially when protocol X is unknown). In fact, I believe it is not
possible to design a *data* modelling language (see RFC 3444) that can
be used for an arbitrary protocol (see
draft-schoenw-sming-lessons-01).
As an example, I know that some implementations are using YANG with
SNMP. Does this imply that *all* models MUST have some statement to
assign an oid with every node?
> , or around the
> requirement that the YANG models need some sort of hierarchy
> (draft-openconfig-netmod-model-structure)
I don't think the requirements for this problem are described
anywhere?
/martin
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
