Hi Alex, > (Resending, apologies in case of duplicates)
Resending? This is the first time I'm seeing these. Did you send them when the Last Call was open before? The Last Call closed a couple weeks ago ;) I don't want to reopen rfc6087bis for anything less than Errata at this point (or promoting it to a BCP, but that's a different thing altogether). It seems that some of your suggestions could go into the new "guidelines-next" issue tracker [1]. We may also consider adding information to the FAQ [2]. Regarding Security Considerations, I think that a "node" can be the root of a subtree, and the rubbery- ness is likely from [3] and can be addressed separately. [1] https://github.com/netmod-wg/guidelines-next/issues [2] https://github.com/netmod-wg/FAQ/wiki [3] http://trac.tools.ietf.org/area/ops/trac/wiki/yang-security-guidelines What do you think? Kent // shepherd I have reviewed some parts of the draft and have just a few comments as well: - One area where guidelines are missing, but where guidance would be needed, concerns how to model return values from RPCs, as well as how to model the handling of RPC error conditions. This is an area where I think YANG itself could need some improvement, and in its absence good guidelines would be even more important. - It would be also useful to provide guidelines regarding how to augment/extend groupings. This is a common scenario and what to do is not necessarily intuitive, so I am sure many users would appreciate guidelines here. - Section 3.4: It would be good to provide a guideline regarding lines that exceed 70 columns (from the pyang tree output), at least mention that authors need to manually address this issue - Section 3.7: Personally, I think the security considerations as currently stated, while well-intended, introduce a bit too much red tape. Specifically, this concerns having to list nodes individually - this can lead to defining many "trees" while missing the "forest". The guidelines are a bit "rubbery" here, by the way, stating that data nodes MUST be individually listed and discussed, at the same time only if they "could be especially disruptive" - what does that mean - so maybe the requirement should simply be a "SHOULD" here? - Observation: there is no mention/guideline canonical order of YANG statements. Thanks --- Alex -----Original Message----- From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Kent Watsen Sent: Tuesday, September 12, 2017 11:22 AM To: netmod@ietf.org Cc: netmod-cha...@ietf.org; draft-ietf-netmod-rfc6087...@ietf.org Subject: [netmod] WG Last Call: draft-ietf-netmod-rfc6087bis-14 This starts a two-week working group last call on: Guidelines for Authors and Reviewers of YANG Data Model Documents https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetmod-2Drfc6087bis-2D14&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iR7m1fbjxuH4HW0Ws7SS-jWBlHsFIVCZEbG2vxMtmno&s=mQRtxCYVsN0ttmets8w-8a-VBh3vh9rJj_NJVhtGa4k&e= Please send email to the list indicating your support or concerns. We are particularly interested in statements of the form: * I have reviewed this draft and found no issues. * I have reviewed this draft and found the following issues: ... Thank you, NETMOD WG Chairs _______________________________________________ netmod mailing list netmod@ietf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netmod&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=iR7m1fbjxuH4HW0Ws7SS-jWBlHsFIVCZEbG2vxMtmno&s=NeFF02cR18ZWLxBX0kSsjAolx0QUWN4ChF3_GJc9WMc&e= _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
