Subject: [netmod] Ben Campbell's No Objection on draft-ietf-netmod-yang-model-classification-07: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Mon, 05 Jun 2017 20:24:59 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-netmod-yang-model-classification-07: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Benoit Claise <[email-masked]>
Date: Wed, 7 Jun 2017 14:50:39 +0200

Hi Ben,

Thanks for your review. See in-line.
> https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-model-classification/
Actually, the security considerations related to the YANG module should 
not influence the YANG module classification.
I wrote "should" because I can't think of a single case.
To complete the Security Considerations section, here is a proposal.
OLD:

    This document doesn't have any Security Considerations.

NEW:
    The document specifying the YANG module to-be-classified already contains a Security Considerations
    section. This document doesn't add to or modify this Security Considerations section.

> types", or "discussions"? Are we talking about network topologies?
OLD:

    A number of module types have created substantial discussion during
    the development of this document including those concerned with
    topologies.

NEW:
    A number of module types have created substantial discussion during
    the development of this document: for example, those concerned with
    topologies.

> section 2. Is the reference out of place?
The reference is right. Positioning the YANG modules from a location 
point of view (equipment vendor, controller, orchestrator) helps people 
grasp the concepts of Network Element YANG Modules versus Network 
Service YANG Modules

Regards, Benoit
> .

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Jun 2017 09:11:23 -0400

Thanks for the response. Also in-line:

> On Jun 7, 2017, at 8:50 AM, Benoit Claise <[email-masked]> wrote:
> 
> Hi Ben,
> 
[...]
> Actually, the security considerations related to the YANG module should not influence the YANG module classification.

I'm fine with that, as long as people have thought about it--and this shows evidence that they have.

>    section. This document doesn't add to or modify this Security Considerations section.  
I'm okay with either version at this point.

>    the development of this document: for example, those concerned with
Would it make sense to say "... for example, modules concerned with topologies."?
> The reference is right. Positioning the YANG modules from a location point of view (equipment vendor, controller, orchestrator) helps people grasp the concepts of Network Element YANG Modules versus Network Service YANG Modules

So this was just an editorial comment, so feel free to ignore, but the bullet point containing the reference is not obviously about the concepts of element vs service modules. It does talk about relationships between models. The idea of service vs element models has not yet been explained at that point, and the figure is not sufficient by itself to explain that idea. Maybe saying "relationships between types of models" would tie the ideas together more closely. Or maybe consider changing the reference to Figure 1 to a reference to Section 2 in it's entirety.