[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: minutes for NETCONF WG interim meeting (09/03)

Hi -

> From: "Juergen Schoenwaelder" <schoenw@ibr.cs.tu-bs.de>
> To: <randy_presuhn@mindspring.com>
> Cc: <netconf@ops.ietf.org>
> Sent: Thursday, October 16, 2003 10:04 AM
> Subject: Re: minutes for NETCONF WG interim meeting (09/03)
...
> Not sure I understand this remark. Are you saying that using URIs
> for identifying capabilities is "structure" or "anarchy"?

It's on the road to structure, in my view.  (I also agree with your
comments on the horrors of capability versioning.)

Now, switching from capabilities to object models:

> [In fact, I liked the RDF inspired exercise to view a whole device as
>  a collection of resources where each resource is identified by a URI
>  so the whole instance naming would be based on URIs. I am not
>  suggesting to do this in netconf - but it is an interesting approach
>  to think through. Perhaps this is what you would call "anarchy" since
>  we would no longer dictate how a vendor has to identify its
>  interfaces? But perhaps this is not even bad since we know from
>  experience that getting indexing right is hard and we went to
>  introduce and use contexts in SNMP land for those cases where we
>  screwed up. And contexts per se are rather opaque - I would call
>  that anarchy - not sure that matches your definition.]

I *like* the idea of URI naming for resources.  I think it's an appropriate
amount of structure.  It also happens to mesh nicely with what I wanted
to do with the nm-webdav i-d, if anyone wants to think about configuration
management in the traditional sense of being able to do versioning, etc.

I agree SNMP contexts are at best a necessary evil.  They were
necessitated by the way the SMI combined indexing with class definitions.
I think CMIP got it right in separating the two.  Using URIs would allow
us to do very similar things to what CMIP does with distinguished names,
and I think this would be a very good thing.

Randy



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