YANG Module Classification
RFC 8199

Note: This ballot was opened for revision 07 and is now closed.

(Alia Atlas) Yes

Comment (2017-06-06 for -07)
No email
send info
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.

Deborah Brungard Yes

Comment (2017-06-08 for -07)
No email
send info
[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).

Warren Kumari Yes

Alvaro Retana Yes

(Ben Campbell) No Objection

Comment (2017-06-05 for -07)
No email
send info

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


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

Alissa Cooper No Objection

(Suresh Krishnan) No Objection

(Mirja Kühlewind) No Objection

(Terry Manderson) No Objection

(Alexey Melnikov) No Objection

(Kathleen Moriarty) No Objection

(Eric Rescorla) No Objection

Comment (2017-06-06 for -07)
No email
send info
I wonder if we can find a better word than "module types" because really both axes are types. Perhaps "module scope" or "module maturity"?

(Adam Roach) No Objection

Comment (2017-06-06 for -07)
No email
send info
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.

(Benoît Claise) Recuse