RE: Goals for netconf - moving towards the charter description

[Andy Bierman <abierman@cisco.com>]

At 06:12 PM 3/23/2003 -0800, Faye Ly wrote:
>Eliot,
>
>I looked at my previous email and thought it was really not addressing
>your questions.  I think I am also suffering from being too general and
>too brief to the degree where point is not clearly made.  I apologize
>for that.
>
>Regarding power management and environment control system, the later is
>a temperature control system?  If you would let me assume so, then they
>both involve the following:
>
>1. Inventory configuration management
>
>2. Fault configuration management (threshold etc)
>
>3. Other configuration that involves testing/diagnostic configuration
>and monitoring.  The monitoring part is clearly out of scope for netconf
>so I won't go there.  The testing/diagnostic were placed under fault
>configuration in my original email but I might be totally wrong. If you
>will share your experience with us, I will be more than happy to learn.
>
>Video recorder is really not a network device (Unless you are referring
>to video recorder over the network as an appliance?  Then it is really
>categorized as user traffic configuration).  
>
>I am not sure what kind of physical security device you are referring
>to?  Please clarify.  Is this the box that sits in front of the PC to
>ensure data secrecy?  Isn't the configuration of such a device falls
>right into inventory and security configuration?
>
>But anyway, when I went into this lengthy discussion on the
>configuration categories.  I am really trying to make sure the protocol
>is not missing out on any categories.  And also not to be carried away
>to think that this protocol will address all the network management
>issues existed today.  The protocol will address certain urgent issue
>such as replacing the scripting pain and file management head-ache.  The
>narrow the scope the easier netconf will succeed.  At the same time a
>sanity check is necessary to make sure the protocol is not too general
>that it missed some configuration categories that are necessary to
>completely address the configuration needs. 
>
>What is your thought on this?  

Why do you think the NETCONF WG should be concerned with the 
configuration data for specific technologies?  Why would the 
protocol need to be different to manipulate fault configuration
data vs. port configuration data, or any other kind of 
configuration data for that matter?  From the protocol POV,
configuration data is just text payload.


>-faye 

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