Subject: RE: Capabilities and MIBs

From: "McDonald, Ira" <[email-masked]>
Date: Wed, 15 Feb 2006 09:36:20 -0800

Hi,

And besides versioning (RFC number is an excellent solution),
your base tag for a MIB should certainly be the case-sensitive
value on the BEGIN statement in the first line of the MIB
(NOT the tag on the MODULE-IDENTITY, which only works for
SMIv2 MIBs and is not the target of an IMPORTS clause).

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: [email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Phil Shafer
> Sent: Wednesday, February 15, 2006 8:29 AM
> To: Vincent Cridlig
> Cc: [email-masked]
> Subject: Re: Capabilities and MIBs 
> 
> 
> Vincent Cridlig writes:
> >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/>
> 

--
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: "McDonald, Ira" <[email-masked]>
Date: Wed, 15 Feb 2006 14:21:22 -0800

Hi Randy,

Actually, a URL to a network copy of an AGENT-CAPABILITIES
and/or to an optional MODULE-COMPLIANCE statement would be
a good method of being very clear.

But most vendors (maybe only many) don't seem to have ever
written MODULE-COMPLIANCE statements.

So a lighter weight solution is just to name the MIB and
the version (by URL to an RFC or a private vendor MIB).

Cheers,
- Ira

> Behalf Of Randy Presuhn
> Sent: Wednesday, February 15, 2006 3:45 PM
> To: [email-masked]
> Hi -
> > From: "Phil Shafer" <[email-masked]>
> > To: "Vincent Cridlig" <[email-masked]>
> > Cc: <[email-masked]>
> > Sent: Wednesday, February 15, 2006 5:28 AM
> ...
> 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: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 16 Feb 2006 22:28:39 +0200

Some people believe that there will be :-)

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of David B Harrington
> Sent: Thursday, February 16, 2006 10:26 PM
> To: 'Randy Presuhn'; [email-masked]
> Subject: RE: Capabilities and MIBs
> 
> Will there be any netconf data models? ;-)
> 
> David Harrington
> [email-masked]
>

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Sun, 19 Feb 2006 09:05:07 +0200

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

> [mailto:[email-masked]] On Behalf Of Andy Bierman
> Sent: Saturday, February 18, 2006 9:52 PM
> To: Vincent Cridlig
> Cc: [email-masked]
> 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 [email-masked] 
> with the word 'unsubscribe' in a single line as the message text body.