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 protected] > 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/> _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
