Subject: Capabilities and MIBs

From: Vincent Cridlig <[email-masked]>
Date: Wed, 15 Feb 2006 11:32:06 +0100

Hi,

I would like that our agent advertises its supported "MIBs".
Are capabilities the regular way to do it ?

Like, for example, for the agent to advertise that it supports "bgp" MIB, "routes" MIB and "network interfaces" MIB.

<hello xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
  <capabilities>
    <capability>urn:ietf:params:netconf:base:1.0</capability>
    <capability>urn:ietf:params:netconf:capability:startup:1.0</capability>
    <capability>urn:madynes:module:bgp</capability>
    <capability>urn:madynes:module:routes</capability>
    <capability>urn:madynes:module:interfaces</capability>
  </capabilities>
  <session-id>4</session-id>
</hello>

Is it acceptable ?

Thanks for your help.
Vincent Cridlig

---

From: Phil Shafer <[email-masked]>
Date: Wed, 15 Feb 2006 08:28:33 -0500

>Is it acceptable ?

Absolutely.  You might want some sort of versioning information
also, which could be done by including the rfc number in the
capability string.

Thanks,
 Phil

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Wed, 15 Feb 2006 12:44:49 -0800

Hi -

> From: "Phil Shafer" <[email-masked]>
> To: "Vincent Cridlig" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Wednesday, February 15, 2006 5:28 AM
> Subject: Re: Capabilities and MIBs 
>
> Vincent Cridlig writes:
> >Is it acceptable ?
> 
...

Do you see a need for anything analogous to a reference to an
AGENT-CAPABILITIES or MODULE-COMPLIANCE, whether coming from
an RFC or from some other source?

Randy

---

From: "David T. Perkins" <[email-masked]>
Date: Wed, 15 Feb 2006 15:16:23 -0800 (PST)

HI,

I believe that you should put the MIB module name (it starts
with an uppercase letter), and include for version the value
from the LAST-UPDATED clause in the MODULE-IDENTITY definition
for modules in SMIv2 format, and an associated date for modules
in the SMIv1 format.
Note that MIB module names are not globally unique, and
they need to be quallified. I believe the best qualifier
is the organization's "IANA Enterprise Number". Technically,
a system advertises what capabilities it has with
AGENT-CAPABILITIES definitions (a definition descriptor
that is qualified by Enterprise number, module name,
and last-update date).
Also, if you want a manager to tell the system what it
needs, you can you MODULE-COMPLIANCE definitions
(a definition descriptor that is qualified by 
Enterprise number, module name, and last-update date)

>   <session-id>4</session-id>

Regards,
/david t. perkins

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 15 Feb 2006 18:51:05 -0500

Hi,

Are you referring to SNMP (SMIv1 or v2) MIBs, or are you talking about
data models designed for use with netconf?

I think it is important to make the distinction between (SNMP) MIBs
and netconf data models.

David Harrington
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Vincent Cridlig
> Sent: Wednesday, February 15, 2006 5:32 AM
> To: [email-masked]
> Subject: Capabilities and MIBs
> 
> Hi,
> 
> Like, for example, for the agent to advertise that it 
> supports "bgp" MIB, "routes" MIB and "network interfaces" MIB.
>

---

From: Andy Bierman <[email-masked]>
Date: Wed, 15 Feb 2006 17:28:54 -0800

> I think it is important to make the distinction between (SNMP) MIBs

Yes please.
Some of us want to experiment with data modeling ideas
without being constrained by SNMP or SMI.

The original question was about advertising the data models that
a NETCONF agent supports.  If you want to call them NETCONF MIBs,
I don't care.  But they are not SNMP MIBs.

It was always the intent that the agent would advertise the namespace URI
of each data model it supports.  However, if you don't use a different
namespace for each data model, then this won't work.  You have to
list modules by name and version, as suggested.  IMO, you need to
also advertise the namespace used for each module.

In order for XML to work correctly, and distinguish
(in a NETCONF PDU) between the <blah> element in the FOO-MODULE
and the one defined in the BAR-MODULE, some mechanism like namespaces
is needed.  This is a standard, and we have to prevent 
cross-organization naming
collisions under the <config> element.

> [email-masked]

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Wed, 15 Feb 2006 23:59:53 -0500

Hi,

I was asking the original poster for clarification about what they
wanted to advertise.

It is possible they wanted to advertise SNMP MIBs that they wanted to
make available through netconf.
It is possible they wanted to advertise netconf-specific data models
that are not SNMP MIBs.

I think how to advertise either is similar, and Phil's answer
addressed that.
A lot of the discussion that followed the original question, however,
is about SNMP MIBs, not netconf-specific data models.
Such responses may not be appropriate to the original question asked.

David Harrington
[email-masked]

> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Wednesday, February 15, 2006 8:29 PM
> To: [email-masked]
> Cc: 'Vincent Cridlig'; [email-masked]

---

From: Vincent Cridlig <[email-masked]>
Date: Thu, 16 Feb 2006 09:31:33 +0100

>data models designed for use with netconf?
I was talking about data models designed for use with netconf.
I realize now that my question was ambiguous. I meant "MIB" in the 
general meaning of a Management Information Base (not SNMP MIB). Sorry 
about that.

Vincent

---

From: Andy Bierman <[email-masked]>
Date: Sat, 18 Feb 2006 11:51:47 -0800

Hi,

I want to follow-up on the namespace vs. module identity issue.

I like the idea of identifying the module, independent of its
namespace, in case namespaces aren't used. (!)

However, in order for an implementation to differentiate
data models from multiple organizations within the same
<config> element -- well, namespaces have already been invented for that.
(I can use an "owner" attribute instead of NS, but that's not standard.)

So knowing the module ID is not good enough.
You need to know the namespace to use with it.

I propose the following conventions (for comment, write-up TBD):

1) Agents SHOULD the advertise data model modules they support
   Managers MAY advertise modules (but why?)

2) The format for a data model module capability URN SHOULD be:

   urn:<orgname>:params:netconf:module:<module-name>[:<module-version>]
 
   e.g.  urn:madynes:params:netconf:module:bgp:1.0

3) The namespace URN to use for a particular module SHOULD be:

   urn:<orgname>:params:netconf:ns:<module-name>[:<module-version>]
 
   e.g.  urn:madynes:params:netconf:ns:bgp:1.0
        
   The extra "params:netconf" in the string makes IETF and vendor strings
   consistent.  Not sure how much this matters.

   If a hard-wired URN for namespace is not acceptable, then some
   extension to the <capability> element is needed to associate
   a namespace with a module.

4) SNMP MIB conversions are not standardized, but a convention for
   a module name could be:

   urn:<orgname>:params:netconf:module:<module-name>[:<last-updated-time>]

   e.g.,  urn:ietf:params:netconf:module:RMON2-MIB:9605270000Z

   This allows MIB modules that are not in RFCs to specify a version.
   Not sure this helps at all without a SMIv2 to XML translation standard.

Comments? 
Waste of time on CLRs?
Experimental? BCP? Informational? Normative?

Andy

> Like, for example, for the agent to advertise that it supports "bgp" 
> MIB, "routes" MIB and "network interfaces" MIB.
>

---

From: Andy Bierman <[email-masked]>
Date: Sun, 19 Feb 2006 12:32:09 -0800

Cridlig Vincent wrote:

[I cc:ed the WG list because your comments are important to the WG]

> I don't see why two different identities should be defined, even if 
> namespaces aren't used.
> In the hello message, there is no difference of using a module ID or a 
> namespace. It will match a unique data model in both cases.
> And in the config element, elements will belong to a namespace or not...
> Maybe I didn't get well something ??
> IMHO, using a unique ID (I mean a namespace) that can be used both as 
> a capability advertisement and as namespace, is more simple and 
> consistent.

I agree with you -- now.
When I wrote this mail, I was thinking
there is probably some IETF rule that says a namespace URN
has to have the "ns:" in the URN.  Who cares.  The capability
string can be the namespace identifier.

>
> However, I am very interested that the wg defines a format for data 
> model namespaces.
> In our prototype, we don't really know how to define them in a 
> standard way.

Nobody does. Yet. ;-)

I am using the per-module namespace approach now, but I don't like it.
A supported option -- one namespace per owner, and let the owner
manage name collision (like MIBs).  You can't load 2 modules
with owner-space collisions, so this is a compile time problem.
A "version" attribute in the data model start node can be used
to detect version mismatches, instead of namespaces.

> I agree. I don't find any use case where it will be useful for a 
> manager to advertise its supported data models.
>

No -- the WG discussed this in detail at an interim meeting.
The thinking was "is there a way the agent can save resources
by knowing which data model modules the manager cared about?".
This idea was quickly tossed because manager functionality
might be dynamically extensible and the list of supported modules
might keep changing.  It might be a really big list too.  Plus,
why do you need to tell an Acme agent about all the proprietary
data models from other vendors you support? 

Still, an agent must be able to at least ignore such capabilities
in the <hello> from the manager.  (Not that hard ;-)

Andy

>> Comments? Waste of time on CLRs?
> ___________________________________________________________________________ 
> Nouveau : téléphonez moins cher avec Yahoo! Messenger ! Découvez les 
> tarifs exceptionnels pour appeler la France et l'international.
> Téléchargez sur http://fr.messenger.yahoo.com
>
>
>

---

From: "David T. Perkins" <[email-masked]>
Date: Sun, 19 Feb 2006 22:08:40 -0800 (PST)

HI,

I'm cutting most of your response, and responding
to a single part.

On Sun, 19 Feb 2006, Andy Bierman wrote:
<lots cut>
> Cridlig Vincent wrote:
<lots cut>
> in the <hello> from the manager.  (Not that hard ;-)

I agree that "at connect time", that it is only needed that
the managed system provide to the manager its capabilities
to determine if "useful" work can be done. That is, a
manager does not need to tell the managed system what
it needs to be supported (unless the managed system
does not want to reveal, but that is a different
issue.)

However, I have always thought that it was a "good thing
to do" to describe the capabilities needed by a management
application. For example, for the management app to
perform function X, the managed system must have at
least capability Y. This assumes that a management app
is developed first, and vendors supply managed
systems with enough capabilities to be managed
by the management app. Experience has shown
that vendors just field products with what they
believe is needed, and management apps are written
later using what ever is provided by the managed
system. That is, the development of management
apps ALWAYS lags (and most times, by a great
amount) the development of a managed system.

Maybe it will be different this time around.
However, I doubt it.

Regards,
/david t. perkins