Subject: [Netconf] comments on draft-ietf-netconf-rfc5539bis-03

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Jun 2013 09:40:48 -0700

Hi,

The YANG module in this draft has been split into 3 YANG files:

   1) module (ietf-netconf-config)
   2) submodule ietf-netconf-common
   3) submodule ietf-netconf-tls

The main module has nothing but boilerplate and include-stmts
for the 2 sub-modules.  The first sub-module has 1 container (/netconf)
and the 2nd sub-module has some TLS objects.

Besides the triple boilerplate, it seems strange that we will have
to update the NETCONF over TLS transport mapping RFC every time
we want to add another sub-module to the ietf-netconf-config module.

I like YANG modules much better than sub-modules because new functionality
can be published in just 1 RFC instead of 2 RFCs.

I don't think putting all new NETCONF config objects under 1 /netconf element
(same local name as /netconf in RFC 5277) is that important, but if the WG wants
to do that, then I strongly suggest creating a place-holder RFC with just
the /netconf container in it.  Other RFCs  can augment from their own
YANG module instead of a submodule.

This way, new config modules will have a normative reference to the 100% stable
/netconf container RFC instead of a normative reference to the
potentially unstable
NETCONF over TLS RFC.  The reference is more clear to readers as well, since
no NETCONF config RFC will ever be related to TLS except 5539bis.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Sat, 29 Jun 2013 20:40:01 +0200 (CEST)

Hi,

> we want to add another sub-module to the ietf-netconf-config module.

That is not what the document says.  It says:

   If new definitions need to be added to the NETCONF configuration
   data model, either an existing YANG submodule can be updated or a
   new YANG submodule can be written.  In both cases, the new document
   will carry an updated version of the "ietf-netconf-config" module
   importing the submodules.

So, if you add a new submodule, you would update the
ietf-netconf-config module, but not NETCONF over TLS.

> YANG module instead of a submodule.

This adds namespaces.  I prefer the current submodule design.

> NETCONF over TLS RFC.

But a new config submodule would NOT have a reference to NETCONF over
TLS.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Sat, 29 Jun 2013 13:07:39 -0700

> ietf-netconf-config module, but not NETCONF over TLS.

I like this even worse -- so the ietf-netconf-config module would
end up being defined in lots of RFCs.  I prefer a YANG module
to stay in RFCnnnn, then RFCnnnn-bis obsoletes RFCnnnn
and it is clear which is the newest version.

I don't see any point to having a /netconf container that
is this much trouble to maintain.  It doesn't really matter
if there are 4 top-level NETCONF nodes or 8 or 20.
The server advertises all the modules it implements (but not submodules).
The client knows where the data lives from parsing the YANG module.
Each module has its own revision date and RFC history.
This is easy to maintain.

Andy

> This adds namespaces.  I prefer the current submodule design.

So what -- what does a namespace cost?
A server doesn't advertise submodules and the
schemas list in ietf-netconf-monitoring is optional to implement.

> But a new config submodule would NOT have a reference to NETCONF over

Worse -- ietf-netconf-config is spread over multiple RFCs.

Andy