[bcc to i2rs and netmod]; I propose to discuss the netconf aspects of this on the netconf mailing list. However, for i2rs "consensus" on the specific netconf requirements, I think it MUSR be dealth with on i2rs list.
Thanks Jeff, this is good for netconf participants to be aware of. And to discuss/comment on. Bert On 22/09/14 23:05, Jeffrey Haas wrote:
[BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff _______________________________________________ Netconf mailing list [email protected] https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
