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

From: Randy Presuhn <[email-masked]>
Date: Mon, 28 Sep 2015 10:00:05 -0700 (GMT-07:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Sep 28, 2015 2:40 AM
>To: Randy Presuhn <[email-masked]>
>Cc: [email-masked]
>Subject: Re: [Netconf] restconf and namespaces and unique module names.
>
>On Wed, Sep 23, 2015 at 08:11:30AM -0700, Randy Presuhn wrote:
>> Hi -
>> 
>> (1) My question remains: why a "MUST" for "standard" modules but
>>     not enterprise ones?  It sounds like you're arguing that a
>>     "SHOULD" or "RECOMMENDED" would suffice in both cases.
>
>In a perfect world, module names would be globally unique. This is,
>however, difficult to guarantee in practice unless we force all
>modules to be registered with IANA (and even then some people will
>simply not follow the rules and not register). Within an SDO, it can
>be possible to guarantee that all module names released by that SDO
>are unique.

It's more than a little ironic that there'd be such a basic
configuration management problem here, particularly when
a well-understood distributed solution has been around for
at least thirty years.  :-(

>> (2) A question of curiousity: what does a client do when it encounters
>>     different servers using different modules of the same name, and
>>     how does it know they are indeed different, using only mandatory
>>     features of the protocol and mandatory-to-implement models?
>
>It depends. A smart client can fetch the module information from the
>server

I didn't realize server support for this was mandatory to implement.

>and adapt to what the server implements and if two servers
>implement 'foo' such a smart client would be able to figure out 'foo'
>may mean different things. There will, however, be clients that simply
>assume module 'foo' means module 'foo' everywhere or that resolve
>imports of 'foo' against a local module library without carefully
>checking with the server and in this case client and server likely run
>into failing RPCs since the data models do not match.

These are the things that worry me.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Mon, 28 Sep 2015 10:12:59 -0700

> These are the things that worry me.
Doesn't the same situation exist in SNMP-land?
The SMIv2 module uses import-by-name, not raw OIDs.

XML is more robust than JSON (is so many ways, but here wrt/ namespace).
The client or server will only get the namespace in an XML message and
then needs to map that namespace to a module name.  This will certainly
fail (if the wrong 'foo' is used) since the namespace URIs should be
different.

With JSON, each peer will just think the other is sending invalid data.

I agree that this is a serious weakness.
We rely on conventions where MUST is more appropriate.
But in real operations, the module names need to be unique.
If not, it will be reported as a bug to the vendor who created
the duplicate module name.

> Randy

Andy

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Sep 2015 09:23:10 +0200

> I agree that this is a serious weakness.

Andy,

if you want to raise this as an issue with the JSON encoding, please
raise it on the NETMOD mailing list since the JSON document is in WG
last call there. The JSON encoding could have used namespace URIs
instead of module names, there is nothing inherent in JSON itself that
forces us to use module names.

/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: Tue, 29 Sep 2015 13:32:16 +0200

> XML is more robust than JSON (is so many ways, but here wrt/

Well, James Clark, one of XML top gurus, wrote this [1]:

"[...] the pain that is caused by XML Namespaces seems massively out of
proportion to the benefits that they provide."

Apparently, there is no silver bullet - and maybe the requirement that
module names be globally unique isn't really necessary.

I would see it positively - unlike other uses of JSON, YANG module names
provide natural namespaces that, together with yang-libary, should be
good enough for most uses.

Lada

[1] http://blog.jclark.com/2010/01/xml-namespaces.html

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