Yes, both the NETCONF <get> operation and the RESTCONF GET on the unified view of the underlying datastores have limitations and a solution in situations where these limitations hurt is to move towards NMDA.
/js On Fri, Jun 28, 2019 at 08:38:38AM +0000, Rob Wilton (rwilton) wrote: > Hi Frank, > > Pre NMDA: > > * You have a the <running> datastore, along with some others like > <candidate> and <startup> that you can ignore for the purposes of this > discussion. > * The <running> datastore can only contains data for schema nodes that > are marked as “config true” in YANG (i.e. “rw” in your tree output below). > * The system may also have some operational state data that is marked as > “config false” in YANG (i.e. “ro” in your tree output below). > > The NETCONF <get-config> operation returns the contents of the <running> > datastore. > The NETCONF <get> operation returns the contents of the <running> datastore > combined with all the operational state as well. Filters can be applied to > return a subset of the data. > > Regarding your question about user created configuration vs system created > configuration, it depends on whether the devices instantiates the > configuration in <running> or not. If it does, then it would be returned in > <get> and <get-config> operations. If it doesn’t then it would not. > Different vendors/devices will likely implement this in different ways. > > Generally, I think that <running> should only contain the configuration > explicitly configured by the operator’s systems. But this means that there > isn’t a clean way to represent system created configuration or applied > configuration, unless you make a config false copy of every config true node > in YANG. This is approach that was taken by the original IETF YANG models > (e.g. RFC 7223) before they were superseded by NMDA, and also the OpenConfig > YANG models (but using a different structure – which also struggles to > cleanly represent system created configuration data). > > The NMDA architecture was written to solve this problem in a clean way > without requiring duplication in the YANG data models. > > Hopefully this helps clarify. > > Thanks, > Rob > > > From: netmod <[email protected]> On Behalf Of Fengchong (frank) > Sent: 28 June 2019 04:29 > To: [email protected]; [email protected] > Cc: Zhangwei (SS) <[email protected]> > Subject: [netmod] 答复: pls clarify get operation > > Hi all, > > Pls clarify this question. I have been confused for a long time. > > ________________________________ > 华为技术有限公司 Huawei Technologies Co., Ltd. > [Company_logo] > 个人签名：冯冲 > 手 机：13776612983 > 电子邮件：[email protected]<mailto:[email protected]> > 公司网址：www.huawei.com<http://www.huawei.com> > ________________________________ > 本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁 > 止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中 > 的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ > This e-mail and its attachments contain confidential information from HUAWEI, > which > is intended only for the person or entity whose address is listed above. Any > use of the > information contained herein in any way (including, but not limited to, total > or partial > disclosure, reproduction, or dissemination) by persons other than the intended > recipient(s) is prohibited. If you receive this e-mail in error, please > notify the sender by > phone or email immediately and delete it! > > 发件人: Fengchong (frank) > 发送时间: 2019年6月27日 9:59 > 收件人: '[email protected]' <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > 抄送: Yangshouchuan > <[email protected]<mailto:[email protected]>>; Zhangwei (SS) > <[email protected]<mailto:[email protected]>> > 主题: pls clarify get operation > > Hi all, > In RFC6241, get operation is defined as: > 7.7<https://tools.ietf.org/html/rfc6241#section-7.7>. <get> > > Description: Retrieve running configuration and device state > > information. > This description is too simply, so I think it should be clarified. > > The case is: a data node modelled by one yang can be configured by user, but > also can be created/modified by system or other protocols. If client issues > get operation to retrieve this node, > The data is created/modified by system or other protocols SHOULD be > returned? > For example: > Rib can be configured by user and also can be created by routing > protocols. In RFC 8349, the rib list is defined as: > > > > +--rw ribs > > +--rw rib* [name] > > +--rw name string > > +--rw address-family? identityref > > +--ro default-rib? boolean {multiple-ribs}? > > +--ro routes > > | +--ro route* > > | ... > > +---x active-route > > | +---w input > > | | +---w v4ur:destination-address? inet:ipv4-address > > | | +---w v6ur:destination-address? inet:ipv6-address > > | +--ro output > > | ... > > +--rw description? string > > > > If client issued get operation to retrieve ribs from non-NMDA device, > rib instance created by routing protocols should be returned? > > Another associated question: If client issued get-config operation > from non-NMDA device, only user-controlled rib instance should be returned? > > _______________________________________________ > netmod mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 <https://www.jacobs-university.de/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
