I think the value ‘intended’ should be namespace qualified to ensure uniqueness.
Section 5.2.1 in RFC 7952:
“The value of a metadata annotation SHALL be encoded in exactly the
same way as the value of a YANG leaf node having the same type as the
annotation”
{
"example:interface" : [
Hi,
By my understanding both annotations should be included in one JSON object,
like this.
{
"example:interface" : [
{
"name" : "eth1",
"mtu" : 1500,
"@mtu" : {
"ietf-netconf-with-defaults:default" : true,
"ietf-ori
Hi Robert, Ladislav,
Thanks for the clarification. I think it would be helpful if an example of
encoding multiple annotations in JSON metadata encoding is mentioned in any
of the related drafts.
Thanks,
Amar
On Thu 14 Feb, 2019, 5:10 PM Ladislav Lhotka On Thu, 2019-02-14 at 11:26 +, Robert
On Thu, 2019-02-14 at 11:26 +, Robert Wilton wrote:
> Hi Amar,
> Based on RFC 7952 section 5.2.1, I think that it would look like this:
> {
> "example:interface" : [
>{
>"name" : "eth1",
>"mtu" : 1500,
>"@mtu" : {
> "ietf-netcon
Hi Amar,
Based on RFC 7952 section 5.2.1, I think that it would look like this:
{
"example:interface" : [
{
"name" : "eth1",
"mtu" : 1500,
"@mtu" : {
"ietf-netconf-with-defaults:default" : true,
"ietf-origin:origin" : intended
Hi Balazs,
I think that every instance data document logically has a YANG schema
associated with it (i.e. a set of YANG modules, deviations, and enabled
features).
YANG library defines this schema on a per datastore basis, along with
other information.
My YANG packages is another attempt t
On 2019. 02. 07. 13:10, Robert Wilton
wrote:
Hi Balazs,
Regarding identifying the instance data using a YANG package.
If the YANG packages work is liked by the WG and progresses,
then it seems plausible that a YANG package could