Date: Fri, 28 Jun 2019 10:50:14 +0200
From: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
To: "Rob Wilton (rwilton)" <rwilton@cisco.com>
CC: "Fengchong (frank)" <frank.fengchong@huawei.com>, "netconf@ietf.org"
 <netconf@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, "Zhangwei (SS)"
 <zhangwei70@huawei.com>
Message-ID: <20190628085014.ljxh73fcmiu6iqx7@anna.jacobs.jacobs-university.de>
Reply-To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
Mail-Followup-To: "Rob Wilton (rwilton)" <rwilton@cisco.com>,
 "Fengchong (frank)" <frank.fengchong@huawei.com>,
 "netconf@ietf.org" <netconf@ietf.org>,
 "netmod@ietf.org" <netmod@ietf.org>,
 "Zhangwei (SS)" <zhangwei70@huawei.com>
References: <5756FB984666AD4BB8E1D63E2E3AA3D001ED5E20@dggemm513-mbx.china.huawei.com>
 <BYAPR11MB2631D3A01E398ADDBB294588B5FC0@BYAPR11MB2631.namprd11.prod.outlook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
In-Reply-To: <BYAPR11MB2631D3A01E398ADDBB294588B5FC0@BYAPR11MB2631.namprd11.prod.outlook.com>
User-Agent: NeoMutt/20180716
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/rI1AV1LzZUqwQOS_WJHkR_NOfik>
Subject: Re: [netmod] pls clarify get  operation
Precedence: list

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,
>=20
> Pre NMDA:
>=20
>   *   You have a the <running> datastore, along with some others like <=
candidate> and <startup> that you can ignore for the purposes of this dis=
cussion.
>   *   The <running> datastore can only contains data for schema nodes t=
hat are marked as =E2=80=9Cconfig true=E2=80=9D in YANG (i.e. =E2=80=9Crw=
=E2=80=9D in your tree output below).
>   *   The system may also have some operational state data that is mark=
ed as =E2=80=9Cconfig false=E2=80=9D in YANG (i.e. =E2=80=9Cro=E2=80=9D i=
n your tree output below).
>=20
> The NETCONF <get-config> operation returns the contents of the <running=
> datastore.
> The NETCONF <get> operation returns the contents of the <running> datas=
tore combined with all the operational state as well.  Filters can be app=
lied to return a subset of the data.
>=20
> Regarding your question about user created configuration vs system crea=
ted configuration, it depends on whether the devices instantiates the con=
figuration in <running> or not.  If it does, then it would be returned in=
 <get> and <get-config> operations.  If it doesn=E2=80=99t then it would =
not.  Different vendors/devices will likely implement this in different w=
ays.
>=20
> Generally, I think that <running> should only contain the configuration=
 explicitly configured by the operator=E2=80=99s systems.  But this means=
 that there isn=E2=80=99t a clean way to represent system created configu=
ration or applied configuration, unless you make a config false copy of e=
very config true node in YANG.  This is approach that was taken by the or=
iginal IETF YANG models (e.g. RFC 7223) before they were superseded by NM=
DA, and also the OpenConfig YANG models (but using a different structure =
=E2=80=93 which also struggles to cleanly represent system created config=
uration data).
>=20
> The NMDA architecture was written to solve this problem in a clean way =
without requiring duplication in the YANG data models.
>=20
> Hopefully this helps clarify.
>=20
> Thanks,
> Rob
>=20
>=20
> From: netmod <netmod-bounces@ietf.org> On Behalf Of Fengchong (frank)
> Sent: 28 June 2019 04:29
> To: netconf@ietf.org; netmod@ietf.org
> Cc: Zhangwei (SS) <zhangwei70@huawei.com>
> Subject: [netmod] =E7=AD=94=E5=A4=8D: pls clarify get operation
>=20
> Hi all,
>=20
>      Pls clarify this question. I have been confused for a long time.
>=20
> ________________________________
> =E5=8D=8E=E4=B8=BA=E6=8A=80=E6=9C=AF=E6=9C=89=E9=99=90=E5=85=AC=E5=8F=B8=
 Huawei Technologies Co., Ltd.
> [Company_logo]
> =E4=B8=AA=E4=BA=BA=E7=AD=BE=E5=90=8D=EF=BC=9A=E5=86=AF=E5=86=B2
> =E6=89=8B=E3=80=80=E3=80=80=E6=9C=BA=EF=BC=9A13776612983
> =E7=94=B5=E5=AD=90=E9=82=AE=E4=BB=B6=EF=BC=9Afrank.fengchong@huawei.com=
<mailto:frank.fengchong@huawei.com>
> =E5=85=AC=E5=8F=B8=E7=BD=91=E5=9D=80=EF=BC=9Awww.huawei.com<http://www.=
huawei.com>
> ________________________________
> =EF=BB=BF =E6=9C=AC=E9=82=AE=E4=BB=B6=E5=8F=8A=E5=85=B6=E9=99=84=E4=BB=B6=
=E5=90=AB=E6=9C=89=E5=8D=8E=E4=B8=BA=E5=85=AC=E5=8F=B8=E7=9A=84=E4=BF=9D=E5=
=AF=86=E4=BF=A1=E6=81=AF=EF=BC=8C=E4=BB=85=E9=99=90=E4=BA=8E=E5=8F=91=E9=80=
=81=E7=BB=99=E4=B8=8A=E9=9D=A2=E5=9C=B0=E5=9D=80=E4=B8=AD=E5=88=97=E5=87=BA=
=E7=9A=84=E4=B8=AA=E4=BA=BA=E6=88=96=E7=BE=A4=E7=BB=84=E3=80=82=E7=A6=81
> =E6=AD=A2=E4=BB=BB=E4=BD=95=E5=85=B6=E4=BB=96=E4=BA=BA=E4=BB=A5=E4=BB=BB=
=E4=BD=95=E5=BD=A2=E5=BC=8F=E4=BD=BF=E7=94=A8=EF=BC=88=E5=8C=85=E6=8B=AC=E4=
=BD=86=E4=B8=8D=E9=99=90=E4=BA=8E=E5=85=A8=E9=83=A8=E6=88=96=E9=83=A8=E5=88=
=86=E5=9C=B0=E6=B3=84=E9=9C=B2=E3=80=81=E5=A4=8D=E5=88=B6=E3=80=81=E6=88=96=
=E6=95=A3=E5=8F=91=EF=BC=89=E6=9C=AC=E9=82=AE=E4=BB=B6=E4=B8=AD
> =E7=9A=84=E4=BF=A1=E6=81=AF=E3=80=82=E5=A6=82=E6=9E=9C=E6=82=A8=E9=94=99=
=E6=94=B6=E4=BA=86=E6=9C=AC=E9=82=AE=E4=BB=B6=EF=BC=8C=E8=AF=B7=E6=82=A8=E7=
=AB=8B=E5=8D=B3=E7=94=B5=E8=AF=9D=E6=88=96=E9=82=AE=E4=BB=B6=E9=80=9A=E7=9F=
=A5=E5=8F=91=E4=BB=B6=E4=BA=BA=E5=B9=B6=E5=88=A0=E9=99=A4=E6=9C=AC=E9=82=AE=
=E4=BB=B6=EF=BC=81
> This e-mail and its attachments contain confidential information from H=
UAWEI, 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 i=
ntended
> recipient(s) is prohibited. If you receive this e-mail in error, please=
 notify the sender by
> phone or email immediately and delete it!
>=20
> =E5=8F=91=E4=BB=B6=E4=BA=BA: Fengchong (frank)
> =E5=8F=91=E9=80=81=E6=97=B6=E9=97=B4: 2019=E5=B9=B46=E6=9C=8827=E6=97=A5=
 9:59
> =E6=94=B6=E4=BB=B6=E4=BA=BA: 'netconf@ietf.org' <netconf@ietf.org<mailt=
o:netconf@ietf.org>>; netmod@ietf.org<mailto:netmod@ietf.org>
> =E6=8A=84=E9=80=81: Yangshouchuan <yangshouchuan@huawei.com<mailto:yang=
shouchuan@huawei.com>>; Zhangwei (SS) <zhangwei70@huawei.com<mailto:zhang=
wei70@huawei.com>>
> =E4=B8=BB=E9=A2=98: pls clarify get operation
>=20
> Hi all,
> In RFC6241, get operation is defined as:
> 7.7<https://tools.ietf.org/html/rfc6241#section-7.7>.  <get>
>=20
>    Description:  Retrieve running configuration and device state
>=20
>       information.
> This description is too simply, so I think it should be clarified.
>=20
> 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 clien=
t issues get operation to retrieve this node,
>           The data is created/modified by system or other protocols SHO=
ULD be returned?
>           For example:
>           Rib can be configured by user and also can be created by rout=
ing protocols. In RFC 8349, the rib list is defined as:
>=20
>=20
>=20
>       +--rw ribs
>=20
>          +--rw rib* [name]
>=20
>             +--rw name              string
>=20
>             +--rw address-family?   identityref
>=20
>             +--ro default-rib?      boolean {multiple-ribs}?
>=20
>             +--ro routes
>=20
>             |  +--ro route*
>=20
>             |        ...
>=20
>             +---x active-route
>=20
>             |  +---w input
>=20
>             |  |  +---w v4ur:destination-address?   inet:ipv4-address
>=20
>             |  |  +---w v6ur:destination-address?   inet:ipv6-address
>=20
>             |  +--ro output
>=20
>             |        ...
>=20
>             +--rw description?      string
>=20
>=20
>=20
>        If client issued get operation to retrieve ribs from non-NMDA de=
vice, rib instance created by routing protocols should be returned?
>=20
>        Another associated question: If client issued get-config operati=
on from non-NMDA device, only user-controlled rib instance should be retu=
rned?
>=20



> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--=20
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/>