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

From: Randy Presuhn <[email-masked]>
Date: Tue, 22 Sep 2015 10:34:48 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Sep 22, 2015 7:26 AM
>To: Kent Watsen <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [Netconf] restconf and namespaces and unique module names.
>
>On Tue, Sep 22, 2015 at 01:41:39PM +0000, Kent Watsen wrote:
>> 
>> 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?
>>
>
>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.

A couple of questions on the RFC 6020 text cited...

  (1) is "standard modules" intended to include those from *all* SDOs?
 
  (2) "MUST" is normally used in situations where "if you don't
      do this this way, this protocol/process won't work correctly."
      If that is indeed so for standard modules, why is it not
      also true for enterprise modules?  That is, what is different
      about enterprise modules that allows them to operate correctly
      without the "MUST"?

I suspect this language may have been (subconsciously) borrowed from
the conventions for SMI module names which, unlike Yang module names,
don't show up in the corresponding protocols.

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 22 Sep 2015 20:58:38 +0200

> don't show up in the corresponding protocols.

You may propose alternative wording. Yes, the wording has been
borrowed from SMI specifications and for resolving imports SMI module
names better are unique as well. Also note that YANG module names only
show up in the JSON encoding on the wire, not im XML. But they are
also used to annouce capabilities - so they better be unique, as the
text says.

/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: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Sep 2015 11:15:38 +0200

>       do this this way, this protocol/process won't work correctly."

This is not the case unless different modules of the same name are used
by the same server.

BTW, there are also no hard guarantees that all URIs are unique.

Lada

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

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 23 Sep 2015 11:22:01 +0200

> show up in the JSON encoding on the wire, not im XML. But they are

Not true, they also show up in Request-URI.

Lada