Hi Eric,
"Eric Voit (evoit)" <[email protected]> wrote: > Hi Martin, > > Several comments on the YANG model within rfc7223bis. > > list interface { > key "name"; > description > "The list of interfaces on the device. The status of an interface > is available in this list in the > operational state... > > A few questions on this. > (a) The description of the list defines behaviors of various list > nodes which might or might not exist in different NMDA datastores. It > also suggests when certain elements should be populated in various > datastores. Is the precedence being set that datastore specific > behaviors may be placed into descriptions? I don't know; I guess it depends on what people think about this style. I think that when the mapping between config and operational state is not 1-1 and obvious, it needs to be somehow explained in the description - just like the old descriptions did, except that where the old descriptions refered to different *nodes*, we now refer to different *intantiations* of the same node. > Is this type of > documentation guidance something which explored in > draft-dsdt-nmda-guidelines? I don't think so. > (b) Does status mean 'admin-status', 'oper-status' or both? (I think > 'oper-status'.) No, it is intended to mean the status of the interface in general. > (c) should quotes be used around status? No, since it's not the name of a specific node. > leaf name {, leaf type { .... > There are NETCONF specific behaviors in the definition of these two > leaves. It would be great to have this transport agnostic. One thing to note is that this also should apply to a RESTCONF server. But adding that doesn't really address your point :) However, I don't know what the correct way of handling this would be. We could be less specific and just write that the server MUST return an "invalid-value" error, but less specific might also be more confusing. > I realize > that such a transport segmentation dissociates transport error > handling from the nodes being handled. > > leaf admin-status {... > incorrectly marked as config false; See the reply from Vladimir; this is corrcect. /martin > > Thanks, > Eric > > > > > -----邮件原件----- > > > 发件人: netmod [mailto:[email protected]] 代表 Kent Watsen > > > 发送时间: 2017年11月29日 3:29 > > > 收件人: [email protected] > > > 抄送: [email protected] > > > 主题: [netmod] WG Last Call: draft-ietf-netmod-rfc7223bis-00 > > > > > > All, > > > > > > This starts a two-week working group last call on draft-ietf-netmod- > > rfc7223bis-00. > > > > > > Please recall that this update's intention is to modify the YANG > > > module to > > be in line with the NMDA guidelines [1]. Reviewing the diff between > > the > > two drafts [2] should reveal just this. > > > > > > The working group last call ends on December 12. > > > Please send your comments to the netmod mailing list. > > > > > > Positive comments, e.g., "I've reviewed this document and believe it > > > is > > ready for publication", are welcome! > > > This is useful and important, even from authors. > > > > > > [1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01 > > > [2] > > > https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7223bis-00.tx > > > t > > > > > > Thank you, > > > Netmod Chairs > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > > _______________________________________________ > > > netmod mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > > netmod mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
