RE: Capabilities and MIBs

["Romascanu, Dan \(Dan\)" <dromasca@avaya.com>]

I believe it's a good thing.

Would not it be useful to include a last-updated-time parameter in the
format for a data model module capability URN? Like 

 
urn:<orgname>:params:netconf:module:<module-name>[:<module-version>][:<l
ast-updated-time>]

I would like to avoid future CLRs about how we sub-version
work-in-progress data-models. 

Experimental by now, Normative if it catches and especially if we decide
to standardize data models some time. 

Regards,

Dan


 
 

> -----Original Message-----
> From: owner-netconf@ops.ietf.org 
> [mailto:owner-netconf@ops.ietf.org] On Behalf Of Andy Bierman
> Sent: Saturday, February 18, 2006 9:52 PM
> To: Vincent Cridlig
> Cc: netconf@ops.ietf.org
> Subject: Re: Capabilities and MIBs
> 
> 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-updat
> ed-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</ca
> pability>
> >    <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
> >
> >
> 
> 
> --
> 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/>
> 

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