Subject: [netmod] advertising module capabilities

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Sep 2009 04:30:41 -0700

Hi,

I do not understand why there would be
any problem for a server to send all its
module capabilities.

As I've pointed out several times,
only the namespace URI is unique.
Letting the client guess that import 'foo'
matches whatever namespace the client
has for module 'foo' is completely broken.
We are making IANA keep track of these strings,
so let's use them.

The <hello> is only sent once.
It is not a burden if the server MUST send
a complete set of module capabilities.

The draft currently says MAY send. Why?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Sep 2009 14:04:59 +0200 (CEST)

> The draft currently says MAY send. Why?

It says:

   Modules that do not contribute any data definitions, rpcs,
   notifications, or deviations to the device MAY be advertised in the
   <hello> message.

So, a type-only module like ietf-inet-types MAY be advertised.

Hmmm.. I guess it actually might help the client to know which version
of a type-only module is implemented by a server, in the case that
some module imports it w/o revision.

Suppose we have this:

  module A-types: revisions 2009-04-01 and 2010-04-01
  module B imports A-types w/o revision
  module C imports A-types, revision 2009-04-01

A server might advertise:

  module B, some revision
  module C, some revision
  module A-types, 2010-04-01

It is still clear that module C uses the types from A-types
2009-04-01.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Sep 2009 08:07:39 -0700

>    notifications, or deviations to the device MAY be advertised in the

Where does it say all these are MUST aer SHOULD?

> It is still clear that module C uses the types from A-types

So what is the namespace URI of A_types?
Since everybody is allowed to use a module
name over again, what good is it for finding
a module?

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Sep 2009 20:17:16 +0200 (CEST)

> Where does it say all these are MUST aer SHOULD?

Section 5.6.4 says:

   The namespace URI is advertised as a capability in the NETCONF
   <hello> message to indicate support for the YANG module by a NETCONF
   server.

Would it be more clear to s/is advertised/MUST be advertised/?

> name over again, what good is it for finding

Everybody is not allowed to use a module name over again.  Section 5.1
says:

   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.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Sep 2009 12:02:45 -0700

> Would it be more clear to s/is advertised/MUST be advertised/?

yes

>    or organization name as a prefix for the module name.

RECOMMENDED doesn't mean much at all.

Why is so hard to advertise the typedefs/groupings, if they happen
to be in a separate module?

module nctypes {
   namespace http://example.com/ns/nctypes;
   ...
}

module nctypes {
  namespace http://acme.com/nctypes;
  ...
}

Why rely on example-nctypes and acme-nctypes?
It just takes an extra 50 bytes or so of XML to
get it right 100% of the time.

I guess this is another one of those 'extra credit if
your code is robust' kind of details.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 07 Sep 2009 21:56:48 +0200 (CEST)

> to be in a separate module?

In my earlier post I agreed that it might make sense to do this.  Then
you started to talk about module names not being unique.  I don't see
the connection.

>   namespace http://acme.com/nctypes;

So what if a server advertises:

  <capability>http://example.com/ns/nctypes?module=nctypes</capability>
  <capability>http://acme.com/nctypes?module=nctypes</capability>

and another module imports nctypes?

My point is that advertising all module namespaces does not help if
there are module names that are not unique.  But I also do not think
that this will be a problem.  As was discussed earlier, it seems to
work for SMI.

/martin

---

From: "Randy Presuhn" <[email-masked]>
Date: Mon, 7 Sep 2009 14:26:11 -0700

Hi -

> From: "Martin Bjorklund" <[email-masked]>
> To: <[email-masked]>
> Cc: <[email-masked]>
> Sent: Monday, September 07, 2009 11:17 AM
> Subject: Re: [netmod] advertising module capabilities
...
>    or organization name as a prefix for the module name.

As a practical matter this means is that implementations MUST NOT
rely on the names of modules or submodules being unique.  There is
no guarantee of uniqueness, so using it to find a module would be a bad idea.
SMI made the same mistake, relaying on not-guaranteed-to-be-unique
module names, rather that using the guaranteed-to-be-unique
object identifier notation for modules provided by the ASN.1 notation
from which it was derived.  This did cause real problems for MIB
compilers and management systems.  Let's not repeat the mistake.

Randy

---

From: Phil Shafer <[email-masked]>
Date: Mon, 14 Sep 2009 15:13:42 -0400

>no guarantee of uniqueness, so using it to find a module would be a bad idea.

I would be happy to see module names as "MUST be unique" and use
the java-style reverse domain name to ensure it ("module org.ietf.ipfix",
"module net.juniper.junos").

---

From: Andy Bierman <[email-masked]>
Date: Tue, 15 Sep 2009 08:20:00 -0700

> "module net.juniper.junos").

This seems rather verbose, and we already have 1 globally unique
string per module -- the module namespace.  Maintaining 2 globally
unique strings is a waste of resources.

The premise in the YANG draft that the module capability
is sometimes optional for the server to send is really
baffling to me.  The <hello> PDU is sent once, and the
number of grouping/typedef only modules is likely to
be very small anyway.  Since a default-stmt can appear in
a typedef or grouping, these 'special' modules need to be
advertised just as much as any other 'real' module.

By advertising every module in use, the server provides
a namespace-to-module/revision binding, and the client does not
have to guess, and hope, it picked the same module as the server.

Andy