I have read draft-ietf-netmod-rfc8407bis-27.txt. My first comment is that maybe this document should be delayed/modified depending upon whether or not we will continue to use RFCs to publish YANG modules.
section: 3.5.0: I don't know about the "+" feature. I guess I should learn. Is YIN really still a thing? Is there some consideration when it should be used? I hardly know it. I went into this document because of the YANG Security Considerations requirement, which when doing yang-data work, we've always had to explain away. I think that there should be sample/template text for that case added. RFC8366: https://www.rfc-editor.org/rfc/rfc8366.html#section-7.4 Section 3.9: consider recommending that I-Ds contain a section, maybe called "YANG Module references", which is simply a list of all the references that are contained in the **YANG MODULE** itself that would not otherwise appear in the document. This should be an RFC-editor-please-remove section. The point is to keep unreferenced warnings to a minimum, such that no YANG module references are incorrectly removed when cleaning up. yanglint does not understand many "modern" YANG constructs, and I found it unuseable. In particular, it can't be used to validate JSON encoded examples. I was unaware of yangson. Could we have pointers to tutorials? Could we put this on the IETF wiki? Maybe all of section 3.10/3.11 should be there. Please reference rfc9637 in 3.12, as well as 3849. I don't have much to say about section 4, which in some sense is really the meat of this document. Or is it... It's more guidelines for YANG with RESTCONF, and it's not really specific to IETF RFCs. I wonder if the mechanical parts of this document (about I-Ds and RFCs) should be in the same document. or maybe it belongs in no document, just the wiki. It is written that this is not a tutorial, yet, it is significant advice that people have to learn. So it's not an *introductory* tutorial. It's an tutorial to help you move from beginning to advanced. section 4.30, about IANA maintained tutorial should perhaps receive more emphasis. Maybe an entire section! I think it points to a fundamental oops in YANG design, but that's water under the bridge. I don't know how to use identityref. 4.11.1 might be enough to clue me in. Other examples I've seen were too complicated. Maybe it could be extended to explain how foo-type is extendable. {ps: I still have significant difficulty guessing if a document ought to be in netmod or netconf. I think that part of this is that I continue to see documents in netconf which I think are infrastructure/transport agnostic, such as netconf-yang-library-augmentedby } -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] [email protected] http://www.sandelman.ca/ | ruby on rails [ -- Michael Richardson <[email protected]> . o O ( IPv6 IøT consulting ) Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
_______________________________________________ netmod mailing list -- [email protected] To unsubscribe send an email to [email protected]
