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

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Nov 2015 21:38:56 +0900 (JST)

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".

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Nov 2015 13:54:45 +0100

> 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.

/js (as contributor)

-- 
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/>