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

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Nov 2015 14:09:43 -0800 (GMT-08:00)

Hi -

>From: Juergen Schoenwaelder <[email-masked]>
>Sent: Nov 5, 2015 4:54 AM
>To: Martin Bjorklund <[email-masked]>
>Cc: [email-masked], [email-masked]
>Subject: Re: [Netconf] restconf and namespaces and unique module names.
>
>On Thu, Nov 05, 2015 at 09:38:56PM +0900, Martin Bjorklund wrote:
>> Hi Randy,
>> 
>> Randy Presuhn <[email-masked]> wrote:
>> > 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.
>> 
>> When I went back to the text to do the edits, I realized that I'm not
>> really sure that I understand what you meant.  The original text is
>> this:
>> 
>>   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.
>> 
>> Did you mean that we should add your proposed sentence at the end of
>> this paragraph, or replace the text with it?
>> 
>> I am thinking that maybe we instead can add "Within a server, all
>> module names MUST be unique".
>
>There are two things here - the uniqueness requirement and a
>recommendation how to produce likely unique names. I think adding
>"Within a server, all module names MUST be unique" is important and
>should be done. I would also like to keep the recommendation how to
>produce likely unique names since this actually helps people and more
>importantly organization to understand what they are supposed to do.

Agreed.  If we're stuck with the vulnerabilities of the current
approach to naming, we should at least encourage folks to do
something that will probably reduce the frequency of failures.

Randy