Hi Randy, thanks for the comments and proposed edits. Please see inline.
Randy Presuhn <randy_pres...@mindspring.com> writes: > 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. Would "doesn't exist or cannot be determined at module design time" be better? > >> 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 OK. > >> 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 "of a regular", probably - you know, we Slavonic people are really hopeless when it comes to articles. :-) > > 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). You are right. So it is left to the "other means" to make sure the data model is observed if necessary. > > 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: > -? Are there any general limitations? Perhaps the section on XML encoding could describe in more detail the subset of XML 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 module > > "as" -> "at" Actually, this typo was copied-and-pasted from 6020bis. Thanks, Lada > >> design time. > ... > > > Randy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
