Hi, Anees Shaikh <[email protected]> wrote: > hi -- some additional comments inline. I think that the revisit on some of > the operator requirements is primarily due to some proposed solution's > inability to address them. > > On Thu, Sep 10, 2015 at 12:41 AM, Martin Bjorklund <[email protected]> wrote: > > > Hi, > > > > Benoit Claise <[email protected]> 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. > > > > No, the title does not mandate a solution -- it just asserts that > configuration should be treated as part of the state, or, in other words, > what a device is running at any given moment is part of its state
Ok, as long as "part of operational state" does not mean "must be modelled as config false in YANG". > -- I do > agree that it's a different perspective from the thinking that led to the > limited way in which YANG supports operational state modeling today. > > > 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. > > > > Retrieval is not only about the protocol -- the model's structure (in this > case the ability to indicate state data clearly in the model ) also is > important. Limiting this to a protocol issue also presupposes a solution. Let me rephrase. I agree that we need to be able to separate configuration data from operational state data, and this is a language issue. However, the protocol needs to support retrieval of them independently. > > 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. > > > > Again, no -- not only a protocol issue -- same as above (this time you're > dictating a solution :-) ). Certainly the model plays a part in > designating different data items as operational state that reflects applied > configuration vs. operational state that reflects device-generated data. Agreed. See above. > > 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. > > > > This alternate formulation is not better -- it's just a much vaguer version > of the requirement that is harder to define How about "ability to relate configuration with its corresponding operational state"? And not use terms like "easy", "robust" etc. > -- I think we've already seen > there are very different experiences and ideas about what makes a solution > easy or robust. And prioritizing YANG modeling for consumption by humans > rather than NMSes, automation systems, programmatic interfaces, etc. risks > defeating the whole purpose of using it IMO. > > > > > > > > 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? > > > > > No. Great, then we agree! > Please note that our proposed solutions have so far required *no* > changes to YANG other than use of a single extension (which is a supported > language feature). Not a single line of pyang was changed to successfully > compile models that follow the proposed structure. Let's not confuse > proposing changes to YANG *models* and introducing conventions with > requiring changes to the YANG language. Sure, but the implications of these conventions are such that unless my YANG module follow these conventions, it cannot be used (other than in a closed proprietary environment). > This is not to say that some > language changes would not make things a bit more sensible -- we have > worked around those limitations, and most of the changes have been > identified as needed in other contexts as well (see observations from the > ODL project, for example). I expect proposals to be forthcoming. > > > > > > > > , 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? > > > > Well, you could re-read the thread that you actively participated in > (Motivations for Structuring Models) :-) If the goal of this meeting is to agree on requirements, wouldn't it help if we had them summarized in one place? > My read of that discussion (and > the discussion at the June interim meeting on this topic) was that there > was no real disagreement on the need for a structure to help organize > related functionality across the growing set of models (the ietf-routing > model is trying to do exactly this for a subset of functionality). Agreed, and this is a good way to handle this problem. I.e., define structure for one function at the time. /martin _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
