Hi -
>From: Ladislav Lhotka <lho...@nic.cz>
>Sent: Sep 29, 2015 7:07 AM
>To: netmod@ietf.org
>Subject: [netmod] 6020bis - anydata
>
>Hi,
>
>I propose to expand the text in Sec. 7.10 as follows:
>
>OLD
>
> The "anydata" statement is used to represent an unknown set of nodes
> that can be modelled with YANG. An example of where this can be
> useful is a list of received notifications, where the exact
> notifications are not known as design time.
>
>NEW
>
> The "anydata" statement is used to represent an unknown set of nodes
> that can be modelled with YANG but for which the data model doesn't
> exist at module design time.
"doesn't exist" would not be appropriate for the example you provide
below. It would be incorrect if some of the notifications in your
example had already been defined, even though "anydata" would still
be necessary to handle others not yet defined.
> At run time, the data model for
> "anydata" content MAY be known through protocol signalling or other
This use of "MAY" seems outside the RFC 2119 sense. Suggested
replacement:
It is possible for the data model for "anydata" content to become
known through protocol signalling or other
> means that are outside the scope of this document, it is however not
> required. If the data model is known, implementations MUST treat
> "anydata" content exactly as if it was a part of regular data tree.
"of regular" -> "of a regular" -or- "of the regular", depending
on which it is that you mean
This use of "MUST" seems at odds with section 6 of RFC 2119.
For example, dynamic lookup of data models could be affected by
connectivity. The "MUST" would mean that the observable protocol
behaviour on the Netconf wire could change, depending on whether
a schema server happened to be reachable at the moment (or not).
Suggested replacement:
When the data model is known (by whatever means) it is possible
for implementations to treat "anydata" as a part of the regular
data tree.
When the data model is not known, the following limitations
potentially apply:
-?
> An example of where this can be useful is a list of received
> notifications, where the exact notifications are not known as module
"as" -> "at"
> design time.
...
Randy
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
