Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-yang-model-classification-04

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 2 Dec 2016 09:35:37 +0100

Hi,

I have read this document and I think it is in good shape and useful,
hence I support the publication. Some comments below, but nothing that
I consider a showstopper.

- I think the RFC editor does not like citation in an abstract. But
  this is actually not my point, I am more wondering why the abstract
  says YANG is defined in RFC 6020 given that we have YANG 1.1 defined
  in RFC 7950.

  The easiest fix is to remove the citation from the abstract (might
  make the RFC editor happy anyway).

- Sometimes you use 'data modeling language' sometimes just 'modeling
  language'. I am not sure whether we have to be consistent or even
  whether there is a reason why the document uses different terms.

- The relationship of the terms '(YANG) data model' and '(YANG)
  module' is not necessarily clear. My understanding has been there
  might be a 1:1 relationship between a data model and a YANG module
  but a data model may also be expressed using a collection of YANG
  modules (and submodules). (Perhaps we should have clarified these
  terms better in the terminology section of RFC 7950.)

  One option to resolve this issue could be to simply not talk about
  models at all; the title says this is a classification of YANG
  modules.

- I am not sure what 'ready to be used by operators' means since you
  put this into the context of Network Service YANG modules. I believe
  Network Element YANG modules are also to be used by operators, no?

- Is it 'they propose in their products' or is it 'they support in
  their products'?

- The module definition in the terminology section is not the
  definition contained in RFC 7950. It is the old definition from RFC
  6020 but you refer rightly to RFC 7950, so this needs to be updated.

- s/perform the intent of the service/realize the service/

  (trying to avoid intent as people may read too much into this)

- Should there be a short discussion in the security considerations?
  Are there different aspects to consider for service modules? Network
  element modules essentially put network elements at risk and the
  network (if network elements misbehave). Service modules put
  complete services at risk, i.e., a security flaws in a service
  module or an implementation of a service module may have much higher
  impact (orchestrated failures or misbehavior of network elements).

/js

On Wed, Nov 30, 2016 at 12:35:44PM -0500, Lou Berger wrote:
> All,
> This starts a two-week working group last call on
> draft-ietf-netmod-yang-model-classification-04.
> 
> The working group last call ends on December 14. Please send your
> comments to the netmod mailing list.
> 
> Positive comments, e.g., "I've reviewed this document and
> believe it is ready for publication", are welcome!
> This is useful and important, even from authors.
> 
> Thank you,
> Netmod Chairs
> 
> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Lou Berger <[email-masked]>
Date: Fri, 16 Dec 2016 13:31:18 -0500

[resend]
All,

This WG LC is closed.

Authors,

Please update your document per any (on & off list) comments received as
well as ensure it passes ID nits, preferably without any warnings.  If
there are issues to be discussed based on comment, please do so on the
list. Once the document is updated to address all comments, please let
us (all) know by sending a  message to the list summarizing resolution
of issues raised and changes.  Publication will be requested at that point.

Thank you!
Lou