[netmod] yang-data issues

[Martin Bjorklund <[e-mail]>]

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