Subject: [Netconf] standard YANG RFC publication (was 5539bis comments)

From: Andy Bierman <[email-masked]>
Date: Sat, 6 Jul 2013 09:26:41 -0700

Hi,

Martin cited this text from the 5539bis-03 draft:

   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.

And had this comment:

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

This publication procedure is at best under-specified and at worst,
completely unworkable.

IMO there MUST be at most 1 RFC containing the current revision
of the ietf-netconf-config module.  This proposal seems to obsolete
the previous ietf-netconf-config module, but not the sub-modules
that were published in each RFC.

So let's walk through an example of how this publication procedure
works from an RFC Editor POV.

   Time-0)  first module
      - RFC 5539bis is published with revision 2013-xx-xx of
ietf-netconf-config.
      - Obsoletes: RFC 5539

    Time-1) add new submodule to configure some other feature
           (e.g. multiple candidates) as RFC XXXX.
      - the main module must maintain the most current normative reference
        for each submodule that is included.
      - the new main module revision is 2014-xx-xx.  At this point the
main module
        in RFC 5539bis is obsolete, but not the submodules. RFC XXXX
has a normative
        reference to RFC5539bis.
      - Updates: RFC 5539bis  (cannot be Obsoletes because of the submodules)

Each time any change in any submodule is needed, the new RFC becomes
the latest ietf-netconf-config home, with the latest revision.  Every normative
reference from every include-stmt in the main module is a normative reference
for each newest RFC.  IMO, this is a really bad idea.  The goal of
modular data modeling is to prevent a spaghetti bowl of dependencies.

Every time 1 submodule is changed, the entire module revision is updated.
There are no submodule revisions advertised in the NETCONF <hello> message,
and the 'schema' list from ietf-netconf-monitoring is optional to implement.
Therefore there is no reliable mechanism for an NMS developer to use to
identify submodule revisions.  This kitchen-sink approach is bad for
modular version
management.

I want to understand how well this RFC publication process is going to work for
the next 10 years.  The purpose of using submodules is to avoid "the high cost
of using an XML namespace".  IMO the RFC publication issues are far worse than
the message overhead incurred by using an additional namespace.  The solution
is worse than the original problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Jul 2013 20:43:12 +0200

> modular data modeling is to prevent a spaghetti bowl of dependencies.

Lets say MvX is a module at revision X and S1, S2, ... are submodules
and lets assume the worst case (each submodule is published as a
separate RFC). This leads to:

| RFC   | Content   | Comment       |
|-------+-----------+---------------|
| RFC_1 | (Mv1, S1) |               |
| RFC_2 | (Mv2, S2) | updates RFC_1 |
| RFC_3 | (Mv3, S3) | updates RFC_2 |
| ...   | ...       | ...           |

> Every time 1 submodule is changed, the entire module revision is updated.

Yes.

> modular version management.

The module uses include by revision. In fact, I think for an NMS
developer, this is essentially the same as if there would have been
only a flat module with stuff added at each revision.

> I want to understand how well this RFC publication process is going
> to work for the next 10 years.  The purpose of using submodules is
> to avoid "the high cost of using an XML namespace".  IMO the RFC
> publication issues are far worse than the message overhead incurred
> by using an additional namespace.  The solution is worse than the
> original problem.

Like with many things in life there are trade-offs and judgements may
differ as well.

/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: Sat, 6 Jul 2013 13:09:36 -0700

...
> | RFC   | Content   | Comment       |

Each RFC_n contains Mv[n], which includes S[1] .. S[n-1],
so there are normative references for RFC_1 .. RFC_n-1.

I think the use of submodules in ietf-netconf-snmp is fine because there is
strong cohesion between the submodules. In this case ietf-netconf-config
exhibits weak cohesion (anything config=true related to the NETCONF protocol).

Using one giant module and "if-feature submodule-A' seems complicated.
YANG modules naturally provide that level of granularity for independent
software features.

If we had started out this way, then that would be different.
Since we didn't, most NETCONF config will not be under /netconf.

How does this scale to the rest of the IETF?
If the IETF standardizes 8 or 10 different routing related YANG modules,
where will these modules be rooted?  Under /routing from ietf-routing.yang?
Under the WG name? (e.g., /i2rs/???). Whatever top-level node they want?

Let's say it is ietf-routing.
Do these WGs need to republish the ietf-routing RFC and add their
submodule include (so their RFC becomes the new home of /ietf-routing)?

IMO it is much more stable and clean to just augment /ietf-routing
from a different RFC because it does not require any republication
of the augmented module.  I think the same approach works best
for the /netconf container as well.  I suspect future RFCs will just
augment this container and not bother with more sub-modules.

>...

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 6 Jul 2013 22:22:26 +0200

> so there are normative references for RFC_1 .. RFC_n-1.

Yep.

> exhibits weak cohesion (anything config=true related to the NETCONF protocol).

ietf-netmod-snmp    anything config=true related to the SNMP protocol
ietf-netconf-config anything config=true related to the NETCONF protocol
 
> YANG modules naturally provide that level of granularity for independent

Not sure what is easier: Only having to deal with features or having
to deal with a combination of modules and features.

> Since we didn't, most NETCONF config will not be under /netconf.

Except nacm, there is no standardized NETCONF config.

> submodule include (so their RFC becomes the new home of /ietf-routing)?

I assume routing will have routing technology specific data models,
e.g. a config model for BGP, OSPF, ... These might consist of
submodules.

> augment this container and not bother with more sub-modules.

I think you are comparing apples with oranges (but you will not
subscribe to that view). The generic routing infrastructure has been
designed to be augmented since the generic model provides the glue
between different technology specific routing config models.

/js

---

From: Andy Bierman <[email-masked]>
Date: Sat, 6 Jul 2013 13:44:16 -0700

Hi,

I don't mind the /netconf container.
The disagreement is really over sub-modules vs. augment.
IMO, augment is cleaner because the extended RFC does
not have to be re-published, and the <hello> has the revision date.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 08 Jul 2013 09:09:49 +0200

> not have to be re-published, and the <hello> has the revision date.

+1.

Lada

> _______________________________________________
> Netconf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 8 Jul 2013 14:01:04 +0200

> not have to be re-published, and the <hello> has the revision date.

Let me at least clarify that

* submodules do augment - see the examples

* there is no need to republish an extended RFC, you republish the
  main module; a WG can of course at their discretion choose to
  republish everything

* the updated module of course has a new revision date which is
  carried in the <hello> (and it uses import by revision)

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 16 Jul 2013 09:13:15 -0700

> * submodules do augment - see the examples

I meant external module augment.  I understand the draft
uses an augment-stmt to add all its contents to a container
node in another submodule.

An external module augment does not require that
an include-stmt be added to the main module.

>   main module; a WG can of course at their discretion choose to

this is the most acceptable approach.

>   carried in the <hello> (and it uses import by revision)

What if a WG using this approach needs to update more than
1 submodule at a time, or it takes so long another new submodule
starts before the other "new main module" is published?
Are all drafts combined into 1 RFC or are 2 main modules
in progress at the same time?

Keeping all submodules in 1 RFC makes the most sense.
In this case, using submodules is purely for style.
So I am changing my objection -- if all new NETCONF config
objects are kept in the same RFC (Obsoletes, not Updates),
then using submodules is not a problem.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 16 Jul 2013 20:18:45 +0200

> in progress at the same time?

The idea is that WGs have the flexibility to do whatever makes most
sense. Even in the extreme cases when there are multiple concurrent
I-Ds sitting in the RFC editor queue and they get processed together,
I assume the RFC editor with the help of the authors and chairs will
figure out how to serialize things properly.

/js

---

From: Balazs Lengyel <[email-masked]>
Date: Wed, 17 Jul 2013 13:14:50 +0200

Hello,
Having the same module published in many RFCs is a recipe for mistakes. 
People will keep using the module from the incorrect RFC. Also why 
bother people with keeping track of the correct version if it does not 
need to be done.

AFAIK one of the main reasons for having the augment statement was that 
ONLY the augmenting module needs to be touched. If we thought that was 
an important idea, why are we not following it now. (I don't really see 
any advantages of the submodule approach.)

So I would like a separate /netconf module that is not republished.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Jul 2013 22:58:52 +0200 (CEST)

> Like with many things in life there are trade-offs and judgements may

I am with Juergen on this one.  It is a somewhat subjective matter,
but I think the submodule design with a single namespace and
include-by-revision leads to a simpler solution.  Yes, the RFCs will
have multiple normative references, but I do not think this is a
problem.  Since include-by-revison is used, it is clear which
submodules are actually used.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 23 Jul 2013 23:03:25 +0200 (CEST)

Hi,

Balazs Lengyel <[email-masked]> wrote:
> Hello,
> Having the same module published in many RFCs is a recipe for
> mistakes. People will keep using the module from the incorrect
> RFC.

I don't know what the incorrect RFC would be.  Since
include-by-revision is used, you cannot mix an old module with a newer
submodule.

> Also why bother people with keeping track of the correct version
> if it does not need to be done.
> 
> AFAIK one of the main reasons for having the augment statement was
> that ONLY the augmenting module needs to be touched. If we thought
> that was an important idea, why are we not following it now. (I don't
> really see any advantages of the submodule approach.)

With this logic, you would also never update a published module;
always use augment to add new stuff instead.  submodules should be
viewed as a way to split one module / namespace into smaller pieces.

External augment has its places (as was mentioned, the routing module
is designed for use with external augmentation), and submodule
augmentation has its places.

/martin