RE: Goals for netconf - moving towards the charter description

["Faye Ly" <faye@pedestalnetworks.com>]

Ran,

TFTP moves configuration file for network device to boot from.  But
again as described by the email I sent to Dave, if netconf is NOT
addressing the configuration file for restart, backup, restore and
upgrade.  This is not an issue for netconf at all, I agree.  I thought
this is actually required by the operator's requirement though?  Did I
interpret them wrong?

This is actually becoming clearer and clearer now.  The blobs of
configuration data is "IP user traffic configuration data" only, is this
correct?  The rest of the solution that deals with device, physical
port, management channel and configuration file are all out of scope?

-faye

-----Original Message-----
From: RJ Atkinson [mailto:rja@extremenetworks.com] 
Sent: Monday, March 24, 2003 10:49 AM
To: Faye Ly
Cc: xmlconf@ops.ietf.org
Subject: Re: Goals for netconf - moving towards the charter description


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