Subject: [Netconf] restconf and namespaces and unique module names.

From: Kent Watsen <[email-masked]>
Date: Tue, 22 Sep 2015 13:41:39 +0000

My issue is with RESTCONF, but the concern extends to YANG and JSON
encoding as well.

YANG's namespace statement is intended to make module names unique.
While IETF-defined modules tend to have a unique namespace per module (why
is that?), this is not required and I wonder if it will interfere with our
module-structure aspirations.

But back to my concern, RESTCONF's URL-encoding uses module names (not
namespace) as a prefix to uniquely identify the module and yet there is no
guarantee that the module names are unique.  For instance:

  module system {
    namespace "http://vendor-foo.com";
    leaf hostname {
      type string;
    }
  }

  module system {
    namespace "http://openconfig.net";  <--- using OC just to make a point
    leaf hostname {
      type string;
    }
  }

And then we have the RESTCONF call:

  GET https://<server>/data/system:hostname HTTP/1.1

So which module is used?  Is this an error condition?  - do we need a
statement that no two modules can have the same name?  Should we use YANG
library to provide an alternate module-name (e.g., system-1) for when
collisions occur?

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Tue, 22 Sep 2015 07:24:46 -0700

> library to provide an alternate module-name (e.g., system-1) for when

The server MUST support the ietf-yang-library module which will identify
which system module
is used.  It is true that modules within a single server need unique
names.  That is why
we have naming conventions like ietf-system, instead of just system.

So if vendors or other SDOs choose to ignore these naming conventions,
then that's their problem. The ietf-foo modules are not the problem.

Thanks,
> Kent

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2015 16:26:15 +0200

> library to provide an alternate module-name (e.g., system-1) for when

RFC 6020:

   The names of all standard modules and submodules MUST be unique.
   Developers of enterprise modules are RECOMMENDED to choose names for
   their modules that will have a low probability of colliding with
   standard or other enterprise modules, e.g., by using the enterprise
   or organization name as a prefix for the module name.

Apparently, both module names in the example violate this. Note that
module names are used to resolve imports and hence they better are
unique. For the IETF, we can manage that via the IANA registry. For
the other modules, there is a clear recommendation.

/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, 22 Sep 2015 17:25:04 +0000

>the other modules, there is a clear recommendation.

OK, that's fair, but it doesn't seem to be a followed often outside of the
IETF.

For instance,

  - ETSI NFV-MANO has module names like "nsd", "vnfd" and "vld"
  - Open Config has module names beginning with "bgp-" and "mpls-"
  - IEEE has module names like "ethernet"
  - ODL has some module names like "config" and "flow-errors"

So it seems that we need to do a better job promoting module name
prefixes.  6087bis, Section 5.1 seems to say what needs to be said,
though, so maybe there isn't much more IETF can do...other than YANG
doctor guidance.

BTW, this sentence in 6087bis may be overreaching "All published module
names MUST be unique." - as it is only enforceable within the scope of a
specific registrar like IANA.  Perhaps replace MUST with SHOULD, or limit
the scope to IANA-published modules?

Kent

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2015 21:03:08 +0200

>   - ODL has some module names like "config" and "flow-errors"

Because people often do not read specifications and if tools do not
complain they assume everything is fine. The YANG spec has clear
words, there is text in the guidelines. We can write more text and it
will likely not help. Perhaps tutorials need to stress these points.

> the scope to IANA-published modules?

IANA does not publish modules. The IETF can enforce unique module
names.  I would hope that once the IEEE _publishes_ YANG modules they
also find ways to enforce unique module names. Perhaps ODL, ETSI, OC
etc will eventually get this right as well.

/js

---

From: "Jonathan Hansford" <[email-masked]>
Date: Wed, 23 Sep 2015 09:58:30 +0100

Are there tutorials out there on how to construct YANG modules? Can we
have links to some to ease the pain of those starting out on the
journey?
Thanks

----- Original Message -----
From: "Juergen Schoenwaelder" 
To:"Kent Watsen" 
Cc:"[email-masked]" 
Sent:Tue, 22 Sep 2015 21:03:08 +0200
Subject:Re: [Netconf] restconf and namespaces and unique module names.

:

:

 /js

 Fax: +49 421 200 3103

---

From: Xiang Li <[email-masked]>
Date: Wed, 23 Sep 2015 11:08:23 -0500

Hi
> will likely not help. Perhaps tutorials need to stress these points.

I agree for standard modules it "MUST" have unique names since it is 
enforceable.

To ensure maximum interoperability, a private module designer better 
follow the
recommendation and carefully choose a name that is unlikely conflicting 
with
others.  We see many private MIBs use a name with company name prefixed, and
for some MIB designers, I believe that is a learned lesson.

--Xiang Li

---

From: Mahesh Jethanandani <[email-masked]>
Date: Mon, 28 Sep 2015 14:22:17 -0700

[Cross posting to netmod mailing list since this discussion affects YANG]

> On Sep 22, 2015, at 12:03 PM, Juergen Schoenwaelder <[email-masked]> wrote:
> 
>>  - IEEE has module names like “ethernet"

IEEE models did that because they did not have a namespace reserved. As IEEE goes through the motions of registering for a URN namespace, all IEEE standard models will be prefixed with ieee-.

> etc will eventually get this right as well.

That is the plan for IEEE and MEF, where we are working on getting them a URN namespace and have them manage uniqueness between the models they produce.

> /js

Mahesh Jethanandani
[email-masked]