Subject: Re: [netmod] [Netconf] netconf yang module namespaces

From: Andy Bierman <[email-masked]>
Date: Sun, 20 Nov 2011 13:12:13 -0800

On 10/24/2011 04:39 PM, Kent Watsen wrote:
....
> Concrete example, we originally defined modules like this:
>
>
>      module hardware {
>          namespace "http://xml.juniper.net/dmi";<--- same namespace
>          prefix "dmi";
>          revision "2008-11-05" {
>              ...
>          }
>          ...
>      }
>      module software {
>          namespace "http://xml.juniper.net/dmi";<--- same namespace
>          prefix "dmi";
>          revision "2008-11-05" {
>              ...
>          }
>          ...
>      }
>      module license {
>          namespace "http://xml.juniper.net/dmi";<--- same namespace
>          prefix "dmi";
>          revision "2008-11-05" {
>              ...
>          }
>          ...
>      }
>

Guess what?
I had way too much time to think about stuff like this on my flight home,
and I realized that what you are trying to do fits the current software world view
wrt/ namespaces and solves the 'std' namespace update churn problem without
the need to keep adding 'include-stmts' to a master container module.

You are the centralized naming authority for xml.juniper.net.
It should be perfectly valid for you to reuse the same namespace for multiple modules.
(Makes the capability list in the hello really important).  It assumes
you know the difference between a cut-and-paste error and intended namespace sharing.
Tools like yuma don't support this yet, but it wouldn't be that hard
to support 1:N instead of 1:1 mappings.

It means that submodules are seriously redundant and we should get rid of them.
They don't work exactly the same as imported modules, just different enough
to confuse people.

It would require a new version of YANG (IMO) to allow this change.

> Thanks,
> Kent

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sun, 20 Nov 2011 22:22:36 +0100

> It would require a new version of YANG (IMO) to allow this change.

So what is the benefit of this compared to a solution in which
submodules are announced in the <hello> exchange?

/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: Sun, 20 Nov 2011 13:49:13 -0800

On 11/20/2011 01:22 PM, Juergen Schoenwaelder wrote:
> submodules are announced in the<hello>  exchange?
>
>

1) simpler for readers/writers
   * just import, no include
   * submodules are flat, not nested like modules, which is confusing
2) no need to keep updating a main module with include-stmts
3) no changes to NETCONF needed at all
4) YANG version may not need to be updated if submodules retained
     and maybe extensions used

An online registry of modules for each namespace could be maintained.
Either way, the server must send a complete module capability list in the <hello>,
and it is already outside the scope of the standard how YANG file locations are mapped
to the <capability> URIs.

IMO, it matches how Python and C++ treat namespaces and modules.
They have no need or notion of submodules.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Nov 2011 11:28:37 +0100

On Sun, Nov 20, 2011 at 01:49:13PM -0800, Andy Bierman wrote:

[...]

>   * submodules are flat, not nested like modules, which is confusing

I am not sure what "flat" means here - so I am confused. ;-)

> 3) no changes to NETCONF needed at all

Did we not agreed that neither solution requires changes to NETCONF?

> An online registry of modules for each namespace could be maintained.

But then this online registry almost mimics the main module with
include-stmts, no?

> Either way, the server must send a complete module capability list
> in the <hello>, and it is already outside the scope of the standard
> how YANG file locations are mapped to the <capability> URIs.

Submodules allow a compiler to check what is in a namespace and in
particular that the namespace is collision free. My understanding is
that this feature would be lost. Submodules require you to be specific
about what is in your namespace.

> They have no need or notion of submodules.

[... JS is not sure this is correct but long discussion removed ...]

The question for me is whether we want YANG compilers to be able to
detect any collisions in the module namespaces at module compile time
or not. YANG was originally designed to be able to do that.

-- break --

Let me see the difference by walking through an example (perhaps this
helps others as well). Suppose we have two modules A and B, both
implementing the namespace http://example.com/foo. Then the <hello>
would look like this:

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capability>
       http://example.com/foo?module=A&amp;revision=2008-04-01
     </capability>
     <capability>
       http://example.com/foo?module=B&amp;revision=2009-04-01
     </capability>
   </hello>

If both A and B contain a typedef for 't', YANG compilers would not
catch this.

If I understand correctly, the alternative would be to extend YANG
such that submodules are announced as well in the <hello>. Then we
would get (assuming M is a module importing submodules A and B):

   <hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
     <capability>
       http://example.com/foo?module=M&amp;revision=2010-04-01
     </capability>
     <capability>
       http://example.com/foo?submodule=A&amp;revision=2008-04-01
     </capability>
     <capability>
       http://example.com/foo?submodule=B&amp;revision=2009-04-01
     </capability>
   </hello>

If both A and B contain a typedef for 't', a YANG compiler will
detect this when compiling M.

Of course, there are additional questions like can I announce
submodule specific features or deviations that would need to be
answered and what happens if I announce submodules that are
inconsistent with the module definition or what happens if the same
namespace is announced with multiple modules. But some of these
questions are orthogonal to the question whether we go down the road
of ad-hoc shared namespaces or controlled sharing of namespaces using
submodules.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Nov 2011 13:43:39 +0100

Hi,

I am using YANG submodules in my non-IETF work and they work fine for me. So I have to ask again: What is the problem that any of the proposed changes are supposed to solve?

If the only argument is that many namespaces are difficult to read, then it is merely a marginal optimization and I am against it. We have more serious problems to discuss.

The charter says that the WG will not work on another version of YANG and IMO we should stick to this promise, unless we run at a real showstopper. Let's first finish the work we have on the table. 

Lada

On Nov 21, 2011, at 11:28 AM, Juergen Schoenwaelder wrote:

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

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 21 Nov 2011 14:50:53 +0100

On Mon, Nov 21, 2011 at 01:43:39PM +0100, Ladislav Lhotka wrote:
> Hi,
> 
> I am using YANG submodules in my non-IETF work and they work fine
> for me. So I have to ask again: What is the problem that any of the
> proposed changes are supposed to solve?
>
> If the only argument is that many namespaces are difficult to read,
> then it is merely a marginal optimization and I am against it. We
> have more serious problems to discuss.

I personally do believe that dealing with too many namespaces scales
badly. Think where we are in 10-15 years. You might nor might not
agree. And what we have produced so far as YANG modules for NETCONF is
rather unorganized in terms of namespaces and common roots, which also
has implications on usability. For me it is a rather fundamental
question how we plan to structure our data models and to what extend
we expose the procedural reality of IETF processes to people who's
main task is to write applications.

Anyway, my concern how we organize things triggered the question
whether submodules help. After all, they were designed to provide
modularity within a single namespace.  Apparently, there are concerns
with submodules since they are "invisible", that is they are not
announced (with version information) during the <hello> exchange. I am
trying to understand whether this is a major problem (Andy clearly
said yes, apparently based on practical experience) and if so what to
do about this.

/js

---

From: Andy Bierman <[email-masked]>
Date: Mon, 21 Nov 2011 06:55:36 -0800

On 11/21/2011 05:50 AM, Juergen Schoenwaelder wrote:
> announced (with version information) during the<hello>  exchange. I am

There is a big difference between the NETMOD WG putting 4 or 5 submodules
in an RFC, and a vendor putting 150 submodules in a kitchen sink data model.

I do not see any problem at all with the way the NETMOD WG is using submodules.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 21 Nov 2011 17:33:03 +0100

> rather unorganized in terms of namespaces and common roots, which also

Why? All start with "urn:ietf:params:xml:ns:yang" and differ only in their suffix, which is the module name. For the time being, we can quite easily cope with the existing situation.

And in 10-15 years? I think it will be necessary anyway to revise YANG in more aspects than just this - and few of them have already been identified (e.g. XPath functions). So let's postpone changes to modules/submodules/namespaces to YANG 2.0, and then do the right thing - hopefully we will know what it is by that time. 

> with submodules since they are "invisible", that is they are not

This is an issue only if the main module revision cannot be changed with each change in submodules. But if it is the  case, I'd suggest NOT to use submodules and use separate modules.

Lada

--
Ladislav Lhotka, CESNET
PGP Key ID: E74E8C0C