Subject: [netmod] review of draft-openconfig-netmod-opstate-01

From: Kent Watsen <[email-masked]>
Date: Tue, 25 Aug 2015 02:14:13 +0000

[As a contributor]

Section 2 defines the term "applied configuration".   It's clear that applied configuration has the same data model as the intended configuration, but in how many ways might it not be the same?  So far, I understand differences including 1) the intended configuration is still being processed (not yet applied) and 2) some configuration knobs taking on protocol negotiated values (e.g., MTU and duplex).  What else is there?

Also in Section 2, the end of the 6th paragraph states "To this end, operational state information can be considered to be 'unknown' to the network manager." - what does this mean?   - isn't it just a matter of the NMS polling on this YANG-modeled data?

Still in Section 2, paragraph 7 does provide more definition to "applied configuration" (merge with above?), but I'm unclear about the line card dependency part.   I would've thought that configuration destined to a missing line card would be present, albeit inactive.   Assuming an <applied> datastore, would a <get-config> source==applied have the linecard's configurations missing?    If so, then what about  unconfigured interfaces, would they show up as "applied" configuration with their default/system-provided configurations?  [update: this is related to Section 7, #3)

And yet again in Section 2, Figure 1 and text just below it don't square up.  The applied config is shown as having the same leaves as the intended config, and is listed below the line marked config: false.  Also, the text says "Only derived state is marked as operational data" and while I also see "operational:true" in Figure 1, this is a forward reference to Section 9.1, which is confusing.  Attached is a picture illustrating my view on this.

In Section 4,1, the last sentence says "This is not considered in [RFC6244]".   Indeed, and there may be a need to do a 6244bis now...to address a number of new items including the intended and ephemeral datastores as well.

Section 4.2 discusses synchronous versus asynchronous.  The point of this section seems to impress the  reader about the need for asynchronous.  That said, all we have today is asynchronous, albeit without the defined applied data stores.   But I'm now more interested in the synchronous requirement - is such a thing actually needed?  Is it something that the NMS should handle instead?

Section 6 says "Below we show an example model structure that meets the requirements described above for all three types of data we are considering".  This Section seems disconnected to the rest of the draft, which has little to do with model structure, with exception to Section 5.2.   It seems that this entire section should be removed from the draft (use model-structure draft for this instead).

Thanks,
Kent