Subject: [netmod] must every yang module have a unique namespace?

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2011 13:43:23 -0700

RFC 6020 section 5.3 says:

   All YANG definitions are specified within a module that is bound to a
   particular XML namespace [XML-NAMES], which is a globally unique URI
   [RFC3986].

After discussing this with Martin in Quebec, I understand that the intention was for each YANG module to have a unique namespace, but my initial reading of this paragraph did not lead me to this conclusion and, since it's been pointed out, I question why we care to impose such a restriction.

Regarding my reading of the paragraph, is parsed it in two distinct parts: (1) All YANG definitions are specified within a module that is bound to a particular XML namespace and (2) XML namespaces are defined by a globally unique URI, which is true.  I didn't string them together to understand that each module had to have unique namespace.  I've also asked a couple colleagues that have a strong command of the English language, and they agreed with my interpretation.

Regarding my questioning why we care to impose this restriction, this forces a technical solution for what could be handled by the maintainers for a *shared* namespace - that is, the maintainers could ensure no namespace collisions ever occur within their namespace without ever resorting to declaring a unique namespace per module.  This is what my team has been doing for a couple years now with our proprietary YANG modules...

One way or the other, we need a CLR for this paragraph.  I suggest we relax the constraint since it seems artificially contrived in the first place.  Relaxing the constraint would be backwards-compatible with the "intended" interpretation, so all existing modules would still be valid.

Thoughts?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Aug 2011 14:02:11 -0700

>     particular XML namespace [XML-NAMES], which is a globally unique URI

I do not think the YANG standard needs to be altered to let multiple modules
share the same namespace. (That is what sub-modules are for.)
For modules defined in YANG, the namespace-uri string needs to
be the exact URI identifying content from that module in XML.

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2011 23:07:59 +0200

> One way or the other, we need a CLR for this paragraph.  I suggest we relax the constraint since it seems artificially contrived in the first place.  Relaxing the constraint would be backwards-comp…

YANG has submodules and I think they do what you want today without
any changes to YANG.

/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: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2011 14:08:50 -0700

> share the same namespace. (That is what sub-modules are for.)

Heh - this was also Martin's first comment.  

We can't use sub-modules because each module is versioned independently and represents an optionally advertized capability, but they are all maintained by the same project and hence we can ensure no namespace collision can ever occur...

Thanks,
Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 2 Aug 2011 23:23:53 +0200

> We can't use sub-modules because each module is versioned
> independently and represents an optionally advertized capability,
> but they are all maintained by the same project and hence we can
> ensure no namespace collision can ever occur...

What does 'versioned' mean to you? A submodule has its own revision
clauses. The main module includes the versioned submodules and
attaches a revision to it. So it is always clear what is being
referred to.

/js

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Aug 2011 14:26:59 -0700

> We can't use sub-modules because each module is versioned independently and represents an optionally advertized capability, but they are all maintained by the same project and hence we can ensure n…

I don't agree.
You can put all the sub-modules in the netconf-monitoring <schema> list.
Sub-modules can have revision-stmts.  Include-by-revision can allow
multiple active top-level modules to include different versions of
particular sub-modules.  You can also put a proprietary capability for sub-modules
into the <hello>.

There are lots of options that do not involve breaking the mapping between XML namespace
and globally unique YANG namespace-stmt URI value.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2011 15:23:54 -0700

> attaches a revision to it. So it is always clear what is being

Let's assume we have project "X" that defines a number of modules using the *shared* namespace "http://xml.juniper.net/x".  These modules are, for instance, "hardware", "software", "license", etc.  Each of these modules are independently versioned (i.e. a YANG revision) and each of our various device-teams can pick and choose which modules and which revision of those modules they want their release to support.  

For instance, we could have the "current release" of routers advertising:

  http://xml.juniper.net/x?module=hardware&revision=2010-10-01
  http://xml.juniper.net/x?module=software&revision=2008-11-05
  http://xml.juniper.net/x?module=license&revision=2008-11-05

And Firewalls advertising:

  http://xml.juniper.net/x?module=hardware&revision=2008-11-05
  http://xml.juniper.net/x?module=software&revision=2010-10-01

And Switches advertising:

  http://xml.juniper.net/x?module=hardware&revision=2011-07-28
  http://xml.juniper.net/x?module=software&revision=2010-10-01

Of course, we have more kinds of devices and more kinds of modules, so there are numerous combinations.  I don't know how it is  possible for a single "parent" module to use sub-modules to express this.  Maybe the "deviations" concept could do it, but it is too under-specified and hacky for us to ever touch it, especially when the "intention" to force each module to have a unique namespace seems arbitrary and the YANG spec is worded in such a way as allow for our interpretation.

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 02 Aug 2011 16:23:17 -0700

>    http://xml.juniper.net/x?module=software&revision=2010-10-01

If you are going to advertise multiple YANG files per namespace URI,
then they might as well be sub-modules.  Just advertise all the submodules
and the main module in the <hello>.

I do not agree that deviations are hacky or relevant here.
Your interpretation of YANG XML namespace usage is not
supported by the RFC 6020 text.

Andy

---

From: Kent Watsen <[email-masked]>
Date: Tue, 2 Aug 2011 16:46:51 -0700

> and the main module in the <hello>.

Huh?  - the arbitrary combinations I mentioned before won't allow it.

> I do not agree that deviations are hacky or relevant here.

I least we agree that deviations are not relevant, albeit for different reasons  ;)

> supported by the RFC 6020 text.

6020 is only unambiguous for standards-based modules (i.e. IETF-defined).  Can you source the text, other than what I quoted, that cinches it for non standards-based modules?