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.
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
when they create or replace the node, the edit will be
rejected because a mandatory node is missing.
>
> >
> > > 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
