YANG Data Structure Extensions
draft-ietf-netmod-yang-data-ext-05

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.

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...

This is a fine document.

Can you show and example similar to what in A.3 with 2 addressbook entries?

Please make the edit agreed from the Gen-ART review.

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.

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?