Subject: [netmod] comments on draft-ietf-netmod-snmp-cfg--05

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jun 2014 14:49:27 -0700

Hi,

It's probably past WG Last Call, but I still do not understand
the value of splitting the ietf-snmp configuration module into
12 files (1 main + 11 sub-modules) instead of just 1 file.

IMO it makes it harder to read, not easier, and wrt/ YANG library
management,
there are 12 files to update and keep in sync, instead of 1.

Is there some expectation that individual sub-modules for SNMP
configuration will be updated regularly in new RFCs?

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2014 08:26:05 +0200

> configuration will be updated regularly in new RFCs?

The organization essentially reflects the modular structure of the
SNMPv3 MIB modules. The SNMPv3 MIB modules are roughly the same
number.

If updates will ever will be necessary, we might benefit from the
modular structure. If updates will never be needed, there is not much
work with synchronizing the sub-modules either. Whether modularity is
a good thing of not can likely be discussed endlessly. In this case,
we followed the modular structure of the SNMPv3 MIB modules.

/js

-- 
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: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2014 04:18:02 -0700

> we followed the modular structure of the SNMPv3 MIB modules.
Seems like SNMP WG had a good reason to have 12 modules
(not all developed at once like the YANG modules). Half the
YANG text is boilerplate. (Copied 12 times to make sure it gets read!)

I am glad this module is an anomaly. Not one other YANG module
in the IETF uses submodules, let alone 11 of them.

/js

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 13 Jun 2014 12:01:37 -0700

> we followed the modular structure of the SNMPv3 MIB modules.

Actually, you did not really follow the SMIv2 structure, or you would have
used
modules instead of submodules. The main module (ietf-snmp) is just a list
of include-by-revision statements.  All submodules have to be present
or the tool will exit with a fatal error.  I suppose the main module could
be altered by vendors (e.g., comment out the include-stmts they don't want
to support), but that would be non-compliant for standard modules.

/js

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 13 Jun 2014 23:03:47 +0200

On Fri, Jun 13, 2014 at 12:01:37PM -0700, Andy Bierman wrote:
> Actually, you did not really follow the SMIv2 structure, or you
> would have used modules instead of submodules.

I wrote "reflects the modular structure of the SNMPv3 MIB modules". I
think my statement was precise.

> The main module (ietf-snmp) is just a list of include-by-revision
> statements.

Correct.

> All submodules have to be present or the tool will exit with a fatal
> error.

Correct.

> I suppose the main module could be altered by vendors (e.g., comment
> out the include-stmts they don't want to support), but that would be
> non-compliant for standard modules.

Yes, it is possible to implement a standard incorrectly.

It does not matter whether a vendor comments out an include statement
or comments out complete containers. The result is equally broken.

/js