Subject: Re: [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:32:39 +0100

Hi,

I think we should have the discussion on the NETMOD mailing list only
since this is mainly a YANG issued and not so much a NETCONF issue.

So please help us staying focussed by removing NETCONF from any
further CCs on this topic.

/js