Re: Goals for netconf - moving towards the charter description

[RJ Atkinson <rja@extremenetworks.com>]

On Monday, Mar 24, 2003, at 12:53 America/Montreal, Faye Ly wrote:
>  According to your opinion that netconf
> will not address inventory mgmt nor fault configuration.
That is not an accurate summary of what I said.

> But they are
> part of the configuration file for the IP device as well
We aren't focusing on what variables are in/not-in the
configuration file right now.  The proposal on the table
moves vendor-proprietary blobs of configuration data
around using a common convention for transmission over
the wire.  It is each vendor's decision about what stuff
is in their product's configuration file, in the current
proposal.

> how are we going to address the need to bring up
> the configuration of an IP device at reboot time
> where the fault manipulation by the device requires
> re-configuration?
That is not part of the current focus.

(Aside: I don't think any new tools are needed for that concern.
For example, DOCSIS cable modems boot up using existing IETF
protocols such as DHCP and TFTP.  DHCP is how the CM gets its
IP address and so forth.  TFTP is how they get their remaining
configuration in a downloaded configuration file.)

The current focus is *only* on a mechanism for transmission
of vendor-proprietary blobs of configuration data, AFAIK.  It
is not addressing anything more than that very basic capability.

> As for the question regarding diag/testing for the IP device, don't
> people use 'ping' or 'traceroute' to do diag/testing all the time?
I've never seen either be part of a configuration file,
but maybe someone would put them in it somehow.

More generally, I don't think that most folks here are trying
to create a panacea protocol to solve all problems.  Operators
have indicated interest in having a conventional, vendor-neutral
way to move vendor-proprietary configuration data around.
Lets please address that first and defer other stuff until
after that is sorted out.

IMHO,

Ran
rja@extremenetworks.com


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