> ....
> >
> > I do not understand the need for a yang-data structure that represents
> data
> > that can be instantiated anywhere and everywhere.
>
> AFAIK noone is proposing that.
>
> > I do not want to break
> > existing tools that expect sibling data nodes in the same module
> namespace
> > to
> > be unique local-names.
> >
> > I would rather stick with the yang-data in RFC 8040 than introduce a new
> > extension
> > with no restrictions. Standard YANG extensions should be interoperable
> and
> > have
> > a clear purpose.
>
> Of course.
>
> > If we do not need to define what a YANG extension does in
> > a way that can be observed somehow, then it does not need to be a
> standard.
>
> Agreed.
>
> Not sure how any of this helps with the original issue though.
>
>
You proposed that duplicate nodes were OK:
module X {
prefix x;
x:yang-data A {
list foo { ... }
}
x:yang-data B {
container foo { ... }
}
}
I do not want to allow any duplicates.
There are no encoding and parsing rules for instance data
that support this sort of duplicate.
yang-data definitions define conceptual data nodes (e.g, /x:foo)
Only one data-def-stmt (in yang-data or otherwise) can define a data node
/x:foo.
The descriptive names for the yang-data (A or B) do not define namespaces.
> /martin
>
>
Andy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
