NETCONF Data Modeling Language
charter-ietf-netmod-09

[Ballot comment]
The formatting of the introductory paragraph needs to be adjusted.

I think this work is important and could help security area WGs like SACM.

[Ballot comment]
I do think that it would be helpful for this charter to discuss some of the
needed WG interactions.  In particular, where encodings of YANG are
defined elsewhere (i.e. draft-ietf-core-yang-cbor-04), there should be
coordination of the impact of changes to the YANG language. 

Another question is where do you see the discussion of device profiles
or sets of YANG modules needed to meet a particular purpose going? To
me, this doesn't read as in scope for this charter and yet I don't think that
we've thought through the right place for them.  I'm ok with continued
discussion for routing-related ones in RTGWG - but not all device profiles
(i.e. a profile of modules needed for a firewall) belong anywhere near Routing.

[Ballot comment]
I lean towards thinking this should have an external review, but I won't insist if others think it is unnecessary.  The vast majority of the text for the old charter is changed.

The milestone dates seem optimistic. Four of them are this month; is that intentional?

[Ballot comment]
This revised charter changes a lot of text, so I'm glad it's going for external review, but it seems clear to me.

I did wonder why the link to http://www.ietf.org/iesg/directorate/yang-doctors.html was removed. Was this not found to be useful in the current charter, or is there a policy about URLs in charters that I should know about?

[Ballot comment]
with respect to Peet's dicuss I expect the proposed modification to the text:

  The NETMOD WG may also develop any additional data models written in
  YANG that the WG considers core building blocks and that do not fall
  under the charters of other active IETF working groups. The NETMOD WG
  may simply add such milestones as it sees fit, with the advice and
  consent of the responsible AD.

Is in keeping with the intent.

The AD and the chairs are expected to engage in good judgement with respect to the work the WG takes on, but the working group should not have to return to the well in order to provide a place to work on  a data model which needs a home. It should not take  on work items that should be housed in other active working groups which again is a judgement call but probably a fairly straight-forward one.

[Ballot block]
This will be straightforward to clear:

  ...and developing data models written in YANG that are considered
  core building blocks and that do not fall into charters of other
  active IETF working groups (for example a data model for stateless
  packet filters).
 
By this, do you intend that this charter is open ended, that the WG can take on writing any data model document it wants without coming back for a re-charter? If so, I think you should say that explicitly in the charter, and I would delete the "(for example...)" since it's already in the milestones. If the WG needs to re-charter for new items, say that and say that the stateless packet filters is not an example, but rather the one additional deliverable. Either way, I think the above belongs in its own paragraph, either:

  The NETMOD WG may also develop any additional data models written in
  YANG that the WG considers core building blocks and that do not fall
  under the charters of other active IETF working groups. The NETMOD WG
  may simply add such milestones as it sees fit, with the advice and
  consent of the responsible AD.

or:

  The NETMOD WG will also develop an additional data model written in
  YANG for stateless packet filters. Such a data model is a core
  building block and does not fall under the charter of another active
  IETF working group.

(I'm not really a fan of open-ended charters, but I'm not going to hold up things because of that. Just so long as the charter is explicit in what it intends the WG to do.)

[Ballot comment]
One nit ...

"Oct 2014 - Submit the mapping to JSON to the IESG" may be slightly confusing to some readers, because it's easy to read it as "submit ... to JSON ..." Perhaps "Submit the JSON mapping to the IESG"?