While reflecting on the discussions, i am asking myself these questions and i
think it will be better if we could capture our thoughts together, as i see
different interpretations.
1> Template definition:
* Is this client data? meaning explicitly configured by the client? Yes,
in my view
* Where does it reside(Datastore view): As it is explicitly configured,
in the running. of course, there are arguments that a explicit set is not a
requirement for it to be in running, but in this case, as the template is
defined explicitly , i am assuming it to be in running.
2> Template validation: in case it is treated as client data, should this not
be validated during definition itself? Of course, if it is under anydata, this
is not possible
3> Template expansion:
Where does it reside? In NMDA, we say it is in intended DS, but
what about non-nmda servers? in running?
Regards,
Deepak
From: Shiya Ashraf (Nokia) <[email protected]>
Sent: Thursday, November 14, 2024 3:41 PM
To: maqiufang (A) <[email protected]>; Kent Watsen <[email protected]>
Cc: [email protected]
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang
Template Proposals)
Hi Qiufang,
Thanks and see inline some response with tag [Shiya].
- Shiya
From: maqiufang (A) <[email protected]<mailto:[email protected]>>
Sent: Thursday, November 14, 2024 9:03 AM
To: Shiya Ashraf (Nokia)
<[email protected]<mailto:[email protected]>>; Kent Watsen
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: RE: [netmod] Re: Mandatory/default statements and templates (was: Yang
Template Proposals)
You don't often get email from
[email protected]<mailto:[email protected]>. Learn why this is
important<https://aka.ms/LearnAboutSenderIdentification>
Hi, Shiya,
Please see my reply inline.
From: Shiya Ashraf (Nokia) [mailto:[email protected]]
Sent: Thursday, November 14, 2024 9:02 AM
To: Kent Watsen <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: [netmod] Re: Mandatory/default statements and templates (was: Yang
Template Proposals)
Thanks Kent, Andy for your responses and the interesting discussion.
Its getting very late here, so I will have to stop with this email for today. đ
RFC 8342 says in section 5.1.3 for running DS
â It MAY include configuration that requires further transformation before it
can be applied, e.g., inactive configuration, or template-mechanism-
oriented configuration that needs further expansion. â
And in section 5.1.4 for intended DS
âIt represents the configuration after all
configuration transformations to <running> are performed (e.g.,
template expansion, removal of inactive configuration) and is the
configuration that the system attempts to apply.
â
<Shiya> For me, these two explicit statements about templates gave me an
understanding that <running> stores the unexpanded data while <intended> stores
the expanded.
[Qiufang] Yes, thatâs my understanding as well. And I believe thatâs also the
intention of authors after extensively discussion on the list.
[Shiya] Glad that we are inline.
And if the RFC is open on storing either the unexpanded or expanded one in
<running>, there must have been a capability defined to expose how the server
actually stores these data (transformed or not) isnât it? Otherwise, how will
the client know what response he get for a get-config response, isnât this
important? Also if some one need to fetch the un expanded data from the device,
shouldnât there already be a way defined for this as well?
[Qiufang] I donât think the RFC is open on storing either the unexpanded or
expanded one in <running>, RFC 8342 is clear on this point. Maybe you are
referring to non-NMDA? I guess that is because config template has never been
standardized in IETF. If we are going to work on this, I think this is
something we need to make it clear.
[Shiya] I was not referring to anything. I was just taking as assumption, some
of the interpretations that I got in this mail chain saying that <running> can
hold expanded data. I agree that we should provide more clarity on what this
means in both NMDA/non-NMDA env.
Also, as I noted earlier, memory gain is a major motivation for using templates
(especially in Fiber network devices).
[Qiufang] Maybe, but it always needs to be expanded in the datastore (e.g.,
<intended>). I also think other motiviations like configuration reuse and
consistency assurance to reduce errors and misconfigurations.
I hope this expansion of templates in running DS doesnât mean we loose such
gains.
[Qiufang] If it is expanded in <running> (which I hope not), I assume <running>
needs the same memory space as not using the template. But still, use of
templates simplifies the configuration delivery.
[Shiya] This is indeed my worry as well.
Thanks,
Shiya
Best Regards,
Qiufang
From: Kent Watsen <[email protected]<mailto:[email protected]>>
Sent: Thursday, November 14, 2024 1:05 AM
To: Shiya Ashraf (Nokia) <[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [netmod] Mandatory/default statements and templates (was: Yang
Template Proposals)
CAUTION: This is an external email. Please be very careful when clicking links
or opening attachments. See the URL nok.it/ext for additional information.
Hi Shiya,
Where does it say <running> contains only data provided by the client in
<edit-config> operations?
(Nowhere)
To put a finer point on this, it is a long-standing desire that changes to
<running> happen only with the clientâs knowledge. That said, <running> could
contain config that was *generated* due to a client-instruction. For instance,
the âresolve-systemâ flag that was recently removed from the âsystem-configâ
draft or, in Yumaâs case, an instruction that causes a template-expansion to
occur at time of the <edit-config>.
Kent // contributor
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
