Benjamin Kaduk has entered the following ballot position for draft-ietf-netmod-yang-data-ext-04: No Objection
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 The "yang-data" extension from [RFC8040] has been copied here, renamed to "structure", and updated to be more flexible. There is no The Gen-Art reviewer had a good comment on this that should be acted upon. Section 2 This does not mean a YANG data structure has to be used as a top- level protocol message or other top-level data structure. I was confused by this until I got through Section 4, which (I think!) clarified that I need a top-level extension directive to "declare the named structure", but this is saying that once the structure is declared, it can be placed anywhere in the tree as a "node of structure type". Perhaps we could add a few words here to clarify, e.g., "YANG data structure, once defined," or "A YANG data structure can be used as any other data type, in the rest of the module"? Section 3 Do we need to say anything about how the child <node>s under structure/augment-structure get printed? (I assume they get the same handling as for the datastore tree, but could be wrong.) The new sections, including spaces conventions is: structure <structure-name>: (I see four spaces between the column the paragraph starts in and the column the "structure" keyword starts in, not two.) [augment-structure] [...] The sub-statements of this extension MUST follow the ABNF rules below, where the rules are defined in RFC 7950: [status-stmt] [description-stmt] [reference-stmt] 1*(data-def-stmt / case-stmt) Comparing to RFC 7950's augment-stmt, we see that when-stmt and if-feature-stmt are not present; would those be used externally to the augment-structure declaration if needed? Section 6 I might consider adding a note that the data being modelled might have its own security considerations, but there's a pretty good case that this is already covered in RFC 7950 and thus would be redundant here. Appendix A.1 Using last+first as the only naming options (and the list keys) is perhaps a bit unfortunate, given, e.g., https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ (which has been popularized several times on varous social-media sites over the years). I suppose it still suffices for the purposes of this example, though. Appendix A.3, A.4 As Alexey notes, maybe have two address entries in the example so that the reader sees the encoding of the list structure? _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod