>><js> Sorry, this is a bug. The protocol knows how to do this
>>because of the underlying information model, which hasn't
>>yet been addressed.
>></js>
>I disagree. It is merely a coupling between the protocol
>operations and the data model. The underlying instrumentation
>will know which data is config and which is not. Part of the
>netconf charter is to identify this type of data model requirement.
OK, we can agree to disagree, I'm saying that the data model DRIVES the design of the protocol and you're not.
regards,
John
John Strassner
Chief Strategy Officer
Intelliden Corporation
90 South Cascade Avenue
Colorado Springs, CO 80903 USA
phone: +1.719.785.0648
FAX: +1.719.785.0644
email: john.strassner@intelliden.com
-----Original Message-----
From: Andy Bierman [mailto:abierman@cisco.com]
Sent: Saturday, April 05, 2003 5:24 PM
To: John Strassner
Cc: Randy Presuhn; xmlconf@ops.ietf.org
Subject: RE: netconf WG charter proposal
At 04:56 PM 4/5/2003 -0700, John Strassner wrote:
>Andy writes:
>
>I'm not putting words in your mouth. I was making
>a reference to the NM data structures the IETF has the
>most experience with -- MIBs. Please be specific -- what
>data structures are you suggesting we use?
>
><js> I think (the other) Randy was recommending that we look at the
>appropriate **management information** sans implementation (i.e.,
>ipRoutingTable). If he wasn't, I will. </js>
>
>...
>
>Andy writes:
>
>I understand these meta-attributes are part of the data model. I am
>only suggesting that it is a feature (not a bug) in the protocol to be
>able to ask a device "give me this blob of configuration data" instead
>of (the SNMP way) the NMS needing to know every attribute of every
>object, down to the instance level, and extract only those data
>elements with multiple (or complex) retrieval operations.
>
><js> Sorry, this is a bug. The protocol knows how to do this because of
>the underlying information model, which hasn't yet been addressed.
></js>
I disagree. It is merely a coupling between the protocol operations and the data model. The underlying instrumentation will know which data is config and which is not. Part of the netconf charter is to identify this type of data model requirement.
>...
>
>Andy continues:
>
>It shows up in the protocol and the data model.
>
><js> No. It shows up in the data model, and the protocol implements one
>or more primitives to get at the data. </js>
The part that shows up in the protocol is the ability to retrieve config data.
>regards,
>John
Andy
>
>John Strassner
>Chief Strategy Officer
>Intelliden Corporation
>90 South Cascade Avenue
>Colorado Springs, CO 80903 USA
>phone: +1.719.785.0648
> FAX: +1.719.785.0644
>email: john.strassner@intelliden.com
>
>
>-----Original Message-----
>From: Andy Bierman [<mailto:abierman@cisco.com>mailto:abierman@cisco.com]
>Sent: Friday, April 04, 2003 11:43 AM
>To: Randy Presuhn
>Cc: xmlconf@ops.ietf.org
>Subject: Re: netconf WG charter proposal
>
>At 10:26 AM 4/4/2003 -0800, Randy Presuhn wrote:
>>Hi -
>>
>>> From: "Andy Bierman"
>>> <<<mailto:abierman@cisco.com>mailto:abierman@cisco.com>abierman@cisco.com>
>>> To: "Randy Presuhn"
>>> <<<mailto:randy_presuhn@mindspring.com>mailto:randy_presuhn@mindspring.com>randy_presuhn@mindspring.com>
>>> Cc: <<<mailto:xmlconf@ops.ietf.org>mailto:xmlconf@ops.ietf.org>xmlconf@ops.ietf.org>
>>> Sent: Thursday, April 03, 2003 11:54 PM
>>> Subject: Re: netconf WG charter proposal
>>>
>>> At 11:41 PM 4/3/2003 -0800, Randy Presuhn wrote:
>>> >Hi -
>>> >
>>> >> From: "Andy Bierman"
>>> >> <<<mailto:abierman@cisco.com>mailto:abierman@cisco.com>abierman@cisco.com>
>>> >> To: "Randy Bush" <<<mailto:randy@psg.com>mailto:randy@psg.com>randy@psg.com>
>>> >> Cc: <<<mailto:xmlconf@ops.ietf.org>mailto:xmlconf@ops.ietf.org>xmlconf@ops.ietf.org>
>>> >> Sent: Thursday, April 03, 2003 11:04 PM
>>> >> Subject: Re: netconf WG charter proposal
>>> >...
>>> >> >> The Netconf Working Group is chartered to produce a protocol
>>> >> >> suitable for network configuration, with the following
>>> >> >> characteristics:
>>> >> >>
>>> >> >> - Provides a clear separation of configuration data
>>> >> >> from non-configuration data
>>> >> >
>>> >> >is this necessary to the task? clearly universally achievable?
>>> >>
>>> >> It was listed as an operator requirement at the NM workshop. It
>>> >> could be easy to achieve. It was never realized with SNMP.
>>> >...
>>> >
>>> >As a property of the protocol per se? It might be better to
>>> >consider it a property of the information model that should be
>>> >represented in the data model so that configuration management
>>> >applications can focus on the right bits.
>>>
>>> Actually, I think this is cleaner as a protocol feature
>>> than an artifact of the data organization. We never had much luck
>>> writing MIBs that kept all state info in a separate sub-tree from
>>> config info.
>>...
>>
>>Please don't put words in my mouth. I'm not suggesting
>>using OID tree structure. We all know it doesn't work. There's more to
>>data models than sub-tree structures.
>
>I'm not putting words in your mouth. I was making
>a reference to the NM data structures the IETF has the
>most experience with -- MIBs. Please be specific -- what
>data structures are you suggesting we use?
>
>>
>>> And what about objects that
>>> are used for both (e.g. the ipRoutingTable uses the
>>> same objects for static and learned routes)?
>>
>>Such things need to be identified as "dual use" in the data model, and
>>when the information source matters, as in this case, that bit of data
>>also needs to be in the model.
>>
>>> It's better to tag
>>> the data with meta-attributes, and have the device return config or
>>> state data, depending on the protocol operation.
>>...
>>
>>Those "meta-attributes" should be assigned in the data model. If
>>they're not in the data model, either as properties of the object
>>attribute definitions (qualifiers in CIM-speak), or in the form of
>>additional attributes (as in your example) how does a managed element
>>or configuration management system know what bits to use?
>
>I understand these meta-attributes are part of the data model. I am
>only suggesting that it is a feature (not a bug) in the protocol to be
>able to ask a device "give me this blob of configuration data" instead
>of (the SNMP way) the NMS needing to know every attribute of every
>object, down to the instance level, and extract only those data
>elements with multiple (or complex) retrieval operations.
>
>>
>>If the config/state distinction only shows up at the protocol level,
>>then we'll end up with the "device is configuration of record", and
>>provisioning/configuration management applications will be no better
>>off than today.
>
>It shows up in the protocol and the data model.
>
>>
>>Randy
>
>Andy
>
>--
>to unsubscribe send a message to xmlconf-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
>
>archive:
><<http://ops.ietf.org/lists/xmlconf/>http://ops.ietf.org/lists/xmlconf/
>>