YANG Module Classification
draft-ietf-netmod-yang-model-classification-08
Yes
Warren Kumari
(Alvaro Retana)
No Objection
(Alexey Melnikov)
(Alissa Cooper)
(Kathleen Moriarty)
(Mirja Kühlewind)
(Suresh Krishnan)
(Terry Manderson)
Recuse
(Benoît Claise)
Note: This ballot was opened for revision 07 and is now closed.
Warren Kumari
Yes
Alia Atlas Former IESG member
Yes
Yes
(2017-06-06 for -07)
Unknown
If there is a desire to change from "module types", which I agree is likely to be overused, an alternate term might be "module pedigree". Thank you for an excellent, clear, and useful document; I remember the confusion that generated this.
Alvaro Retana Former IESG member
Yes
Yes
(for -07)
Unknown
Deborah Brungard Former IESG member
Yes
Yes
(2017-06-08 for -07)
Unknown
[Added comment on definition of SDO] My 2cents on the "type" discussion: The sentence in Section 1 Introduction does cause confusion "A number of module types have created substantial discussion" as it's describing the possible name duplication of a module in two different "layers", not types. Will read better if remove "types". I'm very surprised that Adrian on his reading did not question the use of "layers" to distinguish between services and network element modules. To me, with my layer hat on, this is very confusing. My suggestion would be to use the generic word "types" for "layers" and use "class" to distinguish modules which are standard, vendor, user. Vendor/user modules may/may not overlap with standard modules functionality-wise, they also may be modules with no interest to be standardized, so they are not necessarily associated with maturity/finer aging:-) I find the definition of SDO and vendor confusing. In the draft, it defines an SDO as published by a standards development organization. It provides the example of IETF, IEEE, MEF. It defines a vendor-specific module as "..industry consortia and opensource projects".."openly published". This is blurring the lines of SDO and industry consortia, e.g. MEF is a forum (industry consortia) whereas IETF and IEEE (and ITU) are SDOs. It's based on organizational criteria, and it's in the organization's description of their product e.g. standards, specifications. Some users don't care, others do. To prevent IETF from being pulled into the hornet's nest, suggest SDO be defined as only IETF, and separate labels for vendor and industry consortia (includes opensource/openly published).
Adam Roach Former IESG member
No Objection
No Objection
(2017-06-06 for -07)
Unknown
I'm not going to pick out a bike shed color, but I do support the assertions that "module type" is a bit too ambiguous. When I got to section 3, I had to go back to see what section 2 called its things, because "type" is so generic. There are some places where the unexpanded acronyms lost me (VRF, MEF, UNI) -- consider expanding these on first use.
Alexey Melnikov Former IESG member
No Objection
No Objection
(for -07)
Unknown
Alissa Cooper Former IESG member
No Objection
No Objection
(for -07)
Unknown
Ben Campbell Former IESG member
No Objection
No Objection
(2017-06-05 for -07)
Unknown
Substantive: -4: That seems almost a challenge :-) But seriously, I dont know if it makes sense to discuss this sort of thing in this document-- but it seems like sensitivity of content might be a consideration when "typing" models. For example, models that include security credentials or keys. (An answer of "that's not what we are talking about" would be perfectly sensible.) Editorial: -1, " A number of module types have created substantial discussion during the development of this document including those concerned with topologies." I'm not sure I understand that sentence. Is the antecedent of "those" "module types", or "discussions"? Are we talking about network topologies? The section ends with "See figure 1". But that figure seems more related to section 2. Is the reference out of place?
Eric Rescorla Former IESG member
No Objection
No Objection
(2017-06-06 for -07)
Unknown
I wonder if we can find a better word than "module types" because really both axes are types. Perhaps "module scope" or "module maturity"?
Kathleen Moriarty Former IESG member
No Objection
No Objection
(for -07)
Unknown
Mirja Kühlewind Former IESG member
No Objection
No Objection
(for -07)
Unknown
Suresh Krishnan Former IESG member
No Objection
No Objection
(for -07)
Unknown
Terry Manderson Former IESG member
No Objection
No Objection
(for -07)
Unknown
Benoît Claise Former IESG member
Recuse
Recuse
(for -07)
Unknown