On Thu, Nov 14, 2024 at 5:49 AM Robert Peschi (Nokia) <robert.peschi=
[email protected]> wrote:

> Hi all,
>
>
>
> > template expansion in the running DS ?
>
> Whether one could interpret that the running DS may or may not contain
> expanded data (and I think personally that it should not, in view of how
> NMDA defines the intended DS), the very idea of templates is to reduce the
> size of the running DS that is passed from the Client to the Server. My
> understanding is that the running DS contents is the same in the client and
> in the server. So when the device expands the templates it should put it
> elsewhere than in the running DS:
>
>    - In NMDA: the device would locate the expanded data in the intended DS
>    - In non-NMDA: the device would locate the expanded data its
>    application SW and reflect it in a dedicated R/O YANG tree for the client
>    to read what the device has actually expanded
>
>
>
> In other words, it looks to me that expanding the data in the running DS
> would ruin the purpose of a template mechanism.
>
>
>


IMO requiring the client to provide data already provided by a template or
else <running> will  fail validation tests
defeats the purpose of templates.



> Best regards,
>
> Robert
>

Andy


>
>
> *From:* Deepak Rajaram (Nokia) <[email protected]>
>
> *Sent:* Thursday, November 14, 2024 12:13 PM
> *To:* Shiya Ashraf (Nokia) <[email protected]>;
> maqiufang (A) <[email protected]>; Kent Watsen <[email protected]>
> *Cc:* [email protected]
> *Subject:* [netmod] Re: Mandatory/default statements and templates (was:
> Yang Template Proposals)
>
>
>
> 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]>
> *Sent:* Thursday, November 14, 2024 9:03 AM
> *To:* Shiya Ashraf (Nokia) <[email protected]>; Kent Watsen <
> [email protected]>
> *Cc:* [email protected]
> *Subject:* RE: [netmod] Re: Mandatory/default statements and templates
> (was: Yang Template Proposals)
>
>
>
> You don't often get email from [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]
> <[email protected]>]
> *Sent:* Thursday, November 14, 2024 9:02 AM
> *To:* Kent Watsen <[email protected]>
> *Cc:* [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]>
> *Sent:* Thursday, November 14, 2024 1:05 AM
> *To:* Shiya Ashraf (Nokia) <[email protected]>
> *Cc:* [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]
>
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to