Re: [netmod] yang-data issues

[Kent Watsen <[e-mail]>]

Folks,

Can we get some quick replies to this email?

Kent // all hats




-----Original Message-----
From: netmod <[e-mail]> on behalf of Martin Bjorklund <[e-mail]>
Date: Tuesday, September 11, 2018 at 4:45 AM
To: "[e-mail]" <[e-mail]>
Subject: [netmod] yang-data issues

Hi,

The authors of draft-ietf-netmod-yang-data-ext have been discussing
the two remaining issues on this draft; the issue of whether a
yang-data structure must have unique top-level node names or not, and
the issue of the syntax for augment-yang-data.  We haven't been able
to find agreement with the current proposal, so I have a suggestion
for a slightly modified yang-data statement (which may have been
discussed before):

The idea is to encode a yang-data extension the same way as anydata,
i.e., as a container.  For example:

  yd:yang-data modify-subscription-datastore-error-info {
      description
        "This yang-data MAY be provided as part of a subscription's RPC
        error response when there is a failure of a
        'modify-subscription' RPC which has been made against a
        datastore.  This yang-data MUST be used if hints are to be
        provides back to the subscriber.";
      leaf reason {
        type identityref {
          base sn:modify-subscription-error;
        }
        description
          "Indicates the reason why the subscription has failed to
          be modified.";
      }
      uses hints;
    }

This would be encoded as:

  <modify-subscription-datastore-error-info>
    <reason>foo</reason>
    <period-hint>42</period-hint>
    ...
  </modify-subscription-datastore-error-info>


Since the structure is always encoded as a container, it follows that
it can have any data definition statement as substatement, with no
restriction on naming and type of statement.  An instance of this can
trivially be a complete instance document in XML w/o additional
context, works well with JSON, and can appear in an error-info
structure.

Such a structure can be augemented as:

  yd:augment-yang-data /sn:modify-subscription-datastore-error-info {
    leaf foo { ... }
  }

The drawback is that it forces the use of an extra container in the
encoding.  OTOH, most usages of current rc:yang-data follows this
pattern:

  rc:yang-data modify-subscription-datastore-error-info {
    container modify-subscription-datastore-error-info {
      ...
    }
  }
  



/martin

_______________________________________________
netmod mailing list
[e-mail]
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=7nlVu5dJaa8XsD0LRd0VTH301caVRUXGsa6L-UgXVRE&s=1o7vXH-j8Ha6xbJFTG1jjNzy9JQw7k-UWIqpeCr8qrk&e=