> On 15 Aug 2015, at 01:40, Andy Bierman <[email protected]> wrote:
>
>
>
> On Fri, Aug 14, 2015 at 4:32 PM, heasley <[email protected]> wrote:
> > On Thu, Aug 13, 2015 at 12:43 PM, Ladislav Lhotka <[email protected]> wrote:
> >
> > >
> > > > On 13 Aug 2015, at 21:31, Andy Bierman <[email protected]> wrote:
> > > >
> > > > Hi,
> > > >
> > > > IMO this is issue is closed.
> > > > I see no reason to re-open it.
> > > > YANG does not allow augments to add mandatory nodes.
> > >
> > > I strongly disagree with this attitude, this is a normal IETF procedure.
> > > Things can be changed even during WGLC.
> > >
> > > Virtual interims aren?t good for discussing non-trivial technical issues.
> > >
> > >
> > I am not hearing any new arguments for changing this rule for augments.
> > It's up to the co-chairs whether they want to re-open this issue.
>
> This might be ignorance of detail, but doesn't this approach essentially force
> vendors to publish [what i've been calling] enterprise yang models for models
> that they might otherwise just augment to support proprietary features?
>
> if so, what is the point of defining *any* models?
>
>
>
> The issue here is that augment cannot directly add mandatory nodes.
> They must be inside a list or a P-container.
In both examples, the augments are applied inside a list, only the list is
defined in the module that’s being augmented.
>
>
>
> augment /foo:bar {
> leaf NOT_ALLOWED {
> mandatory true;
> type string;
> }
> }
>
> augment /foo:bar {
> container THIS_IS_ALLOWED {
> presence "new feature enabled";
> leaf THIS_IS_NOW_ALLOWED {
> mandatory true;
> type string;
> }
> }
> }
>
> IMO this extra P-container is not a burden and it serves
> an important purpose, which is to allow clients that
> know the base structure to keep working. Otherwise
But it also allows clients to create invalid DNS resource records in my
example, or invalid if:interface entries in Rob’s example, because the
p-container can be omitted entirely.
> when they create or replace the node, the edit will be
> rejected because a mandatory node is missing.
The client has no good reason to create list entries with types that it doesn’t
support.
My workaround in the dns-zones module is a must statement in the “rdata” list
that requires the p-container to be always present:
must “count(*) > 2”;
This is a tricky and brittle solution though.
Lada
>
>
>
>
> >
> >
> > > Lada
> > >
>
>
> Andy
>
> >
> >
> > Andy
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
