-----邮件原件----- 发件人: netmod [mailto:[email protected]] 代表 Kent Watsen 发送时间: 2018年10月20日 20:49 收件人: [email protected] 主题: Re: [netmod] yang-data issues
Folks, Can we get some quick replies to this email? [Qin]: I believe restconf collection work might benefit from this work as well. It follows traditional usages of rc:yang-data, However I am not sure the benefit to remove container defined within yang-data extension, the restrict ion I see this, In traditional usage of yang-data, we can add more than one containers, then augment-yang-data can augment from any of these containers defined within yang-data extension. But with below proposal, we lose such flexibility, in my opinion. Kent // all hats -----Original Message----- From: netmod <[email protected]> on behalf of Martin Bjorklund <[email protected]> Date: Tuesday, September 11, 2018 at 4:45 AM To: "[email protected]" <[email protected]> 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 [email protected] 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= _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
