Re: Capabilities and MIBs

[Andy Bierman <ietf@andybierman.com>]

Cridlig Vincent wrote:

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

> > 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. (!)
>
> 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 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?)
>
> 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




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


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