YANG Data Structure Extensions
draft-ietf-netmod-yang-data-ext-05
Yes
(Ignas Bagdonas)
No Objection
Éric Vyncke
(Adam Roach)
(Alvaro Retana)
(Deborah Brungard)
(Magnus Westerlund)
(Martin Vigoureux)
(Mirja Kühlewind)
(Suresh Krishnan)
Note: This ballot was opened for revision 04 and is now closed.
Roman Danyliw
No Objection
Comment
(2019-12-03 for -04)
Sent
Section 6. Recommend staying consistent with the standard YANG security considerations (https://trac.ietf.org/trac/ops/wiki/yang-security-guidelines) and at least include this following subset (or something like it) of the boiler plate language: The YANG module in this document defines an extension in the YANG data modeling language that will be imported and used by other modules. When imported and used, the resultant schema will have data nodes that can be writable, or readable. The access to such data nodes may be considered sensitive or vulnerable in some network environments. Write operations (e.g., edit-config) to these data nodes without proper protection can have a negative effect on network operations. Section 7.3. What purpose will this section serve when published? Is seems like it could be removed. The only use of the [1] reference is Appendix C which is supposed to be removed before publication.
Warren Kumari
No Objection
Comment
(2019-12-03 for -04)
Not sent
I don't have much to add, other than to agree with Alexey's comments on 2 addressbook entry examples, and Benjamin's "This does not mean a YANG data structure has to be used as a top- level protocol message or other top-level data structure." comment -- I too was confused by this...
Éric Vyncke
No Objection
Ignas Bagdonas Former IESG member
Yes
Yes
(for -04)
Unknown
Adam Roach Former IESG member
No Objection
No Objection
(for -04)
Not sent
Alexey Melnikov Former IESG member
No Objection
No Objection
(2019-10-19 for -04)
Sent
This is a fine document. Can you show and example similar to what in A.3 with 2 addressbook entries?
Alissa Cooper Former IESG member
No Objection
No Objection
(2019-12-04 for -04)
Sent
Please make the edit agreed from the Gen-ART review.
Alvaro Retana Former IESG member
No Objection
No Objection
(for -04)
Not sent
Barry Leiba Former IESG member
No Objection
No Objection
(2019-10-17 for -04)
Sent
A fine extension. Just three editorial nits: -- Section 1 — There is no assumption that a YANG data structure can only be used as a top-level abstraction, instead of nested within some other data structure. It’s a little odd to use “instead of” after “there is no assumption”; I can’t explain it fully, but it feels odd to this native English speaker. I suggest this: NEW There is no assumption that a YANG data structure can only be used as a top-level abstraction, and it may also be nested within some other data structure. END similar to the existing YANG "augment" statement. Make it “similarly”. — Section 1.1.1 — The following terms are defined in the Network Management Datastore Architecture (NMDA) [RFC8342]. and are not redefined here: The period after the citation should be a comma.
Benjamin Kaduk Former IESG member
No Objection
No Objection
(2019-12-03 for -04)
Sent
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?
Deborah Brungard Former IESG member
No Objection
No Objection
(for -04)
Not sent
Magnus Westerlund Former IESG member
No Objection
No Objection
(for -04)
Not sent
Martin Vigoureux Former IESG member
No Objection
No Objection
(for -04)
Not sent
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -04)
Not sent
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -04)
Not sent