发件人: Kent Watsen [mailto:[email protected]]
发送时间: 2019年7月10日 2:31
收件人: Qin Wu <[email protected]>
抄送: [email protected]; [email protected]
主题: Re: [netconf] [netmod] RE: pls clarify get operation

[Just back from a 4th of July thing]

Hi Qin,
It provides guideline how to create temporary non-NMDA module from NMDA module, 
but temporary non-NMDA module is not standard module. So everybody will create 
the same temporary non-NMDA module?
I also feel this second paragraph is not very clear, especially the last 
sentence,  is nested config false data nodes part of NMDA module or temporary 
non-NMDA
Module? Looks like  nested config false data node part of NMDA module?
True, but as I wrote Frank on the 28th:

"Some drafts already publish a "state" module in their Appendix and, when they 
do, there is a completely standard non-NMDA IETF solution.  I don't know if 
this strategy is being followed universally but, if not, then I don't believe 
the IETF would object at all to the publication of drafts for missing state 
models in drafts that only assumed NMDA."

Are you facing this situation currently?   If so, with which modules?  Have you 
considered submitting an I-D to define the missing state tree module?

[Qin]: Yes, we are looking for completely standard non-NMDA IETF solution in 
this NMDA transition time period, since we assume many NETCONF clients in the 
existing deployment don’t support NMDA. We are not sure state module in the 
appendix is standard non-NMDA model or not? How many operators and implementer 
will use them as standard model.
Yeah, for some of other model may not define such state module in the appendix.
Can non-NMDA client consume NMDA module?

Sort of.  The config-true nodes will appear in the <running> as usual, and the 
config-false nodes can be accessed via the standard operations.  But there will 
be issues as, for instance, the config-false nodes will only appear for 
configured items and the operational value for config-true nodes will be 
missing, the latter of which may be important as an NMDA-optimized data model 
is unlikely to define config-false nodes for any config-true nodes, and hence 
the config-false that are defined may be far and few between, leading to an 
unacceptably incomplete upstate view.

[Qin]:That is exactly the issue we are facing. How do we as Non-NMDA client use 
NDMA module to get system generated configuration. I assume config false nodes 
for config-true nodes are referred to system generated configuration. These 
system generated configuration can not be obtained through get operation.


_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to