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

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

Hi -

> From: Andy Bierman
> Sent: Sep 28, 2015 10:12 AM
> To: Randy Presuhn
> Cc: Netconf
> Subject: Re: [Netconf] restconf and namespaces and unique module names.
...
> Doesn't the same situation exist in SNMP-land?The SMIv2 module uses
> import-by-name, not raw OIDs.

Yes.  It's a perfectly avoidable problem that Yang inherited from
SMI.  The bug was introduced when SMI "subsetted" ASN.1 and
failed to preserve the option of referencing modules by OID.

However, the problem is much less severe in SNMP-land, since
module names don't appear on the wire.  In the very few cases
where one might be tempted to do such a thing, the module OID
is used.  It *is* a problem for IMPORTS, but that's only a minor
tractable headache, since an outside-the-scope-of-standardization
mapping from module names to file names is needed anyway.

> 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 andthen needs to map that namespace to a
> module name.  This will certainlyfail (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.

This is in the *best* case.  In the worst case, there might
be sufficient syntactic similarity between when the models
permit to allow an operation to succeed, even though the
intent/semantics understood by the endpoints could
be radically different.

> 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 createdthe duplicate module name.

Agreed, this is essentially the case for "MUST" for uniqueness of
both enterprise and standard modules.  When a "MUST" puts vendors
or operators in an untenable situation, it's time to revisit the
design assumptions of the specification.  However, I'm not fully
convinced that things are so bad as to require replacement of
the naming mechanism, although that would be required to completely
eliminate all collisions.

I'm more concerned about honesty in specification.  Embracing JSON,
as you've detailed, brings more serious consequences for collisions.
The softest language I could support for module name collisions
would be something like "Use of enterprise modules with non-unique
names is NOT RECOMMENDED."  But I'd still prefer a blanket "MUST be
unique", since that's the truth if things are to work correctly.

Randy