Hi Kent,
Sorry but I miss the point you made with the below statement:
"As a contributor, I feel that the concern is unwarranted. My belief/hope is
that templates are not themselves validated when defined, but rather only the
fully expanded/flattened results of templates are validated."
Shiya>> For mandatories, the problem that was highlighted was more about
following the DRY approach for templates.
For instance, in the below example copied from #3, slide 6, assume if the 'mtu'
was defined as a mandatory data node with in a non-presence container, you will
be forced to add it anyway for each interface in the below example and thus
loosing the advantage of templating for these special data nodes. Isn't it?
<interfaces>
<interface yt:apply-templates="set_physical_mtu">
<name>GigabitEthernet0/0/0/0</name>
</interface>
<interface>
<name>GigabitEthernet0/0/0/1</name>
</interface>
</interfaces>
Thanks,
Shiya
From: Kent Watsen <[email protected]>
Sent: Wednesday, November 13, 2024 3:08 PM
To: Don Fedyk <[email protected]>
Cc: [email protected]; [email protected]
Subject: [netmod] Re: 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.
[just now home from Ireland, hence the delayed response]
> It would help if the WG agreed upon some functional requirements for
> templates. Any plan for that?
+1 I found myself wondering what requirements each solution satisfied.
I agree that the WG should define requirements first. I will kickoff a thread
on that shortly!
I would like to thank the group for the fruitful discussion on various
proposals on templates. When reading the drafts further, i have few questions
on the draft draft-ma-netmod-yang-config-template-00 - YANG
Templates<https://datatracker.ietf.org/doc/draft-ma-netmod-yang-config-template/>
. Since, it is marked as standards track, I would like to understand if the
intention is to standardise the 'ietf-template' model mentioned in section 8.1
or to standardise the metadata object stmt-extend/operation-tag or both. In my
view, the stmt-extend/operation-tag is something which could as well be
achieved with existing RFC 7952?
I have similar queries on
slides-121-netmod-sessb-16-yang-templates-01<https://datatracker.ietf.org/meeting/121/materials/slides-121-netmod-sessb-16-yang-templates-01>,
are we proposing to standardise the module 'yang-template' in slide 3 or the
metadata object apply-templates/exclude-templates or both?
Please do not read anything into the Intended Status field of any of the
current draft proposals. All ideas expressed in current I-Ds and/or slides are
effectively "Informative" at this point.
The show of hands performed at the end of that session clearly expressed that
the WG would like to define a *standard* templating mechanism.
At some point the WG will adopt an I-D that has the Intended Status "Standards
Track", but that won't occur until after the requirements are settled and a
group of authors formed to put together such an I-D.
In both the proposals, were the point on mandatories and defaults(which was
touched upon in the meeting) considered? I believe, this needs to be considered
when applying a template.
I recall that presentation. I raised my hand to say the following (but lowered
it when noticing that we were running low on time and wanting to giver others a
chance to speak):
As a contributor, I feel that the concern is unwarranted. My belief/hope is
that templates are not themselves validated when defined, but rather only the
fully expanded/flattened results of templates are validated.
IMO a solution using anydata + a deterministic method of identifying the object
for the root of template is required.
I'm trying to avoid discussing solutions too much now, but I tend to agree.
Implicit in this statement, and I think different from any of the proposals, is
that the data model (e.g., YANG) for the template may not be the same as the
data model of the datastore the template resides in, but rather any node within
that datastore. The reasons for why this seems good to me (as a contributor)
include: 1) better focus and 2) templates can be referenced anywhere a grouping
is used.
Kent
_______________________________________________
netmod mailing list -- [email protected]
To unsubscribe send an email to [email protected]
