Dynamic vs Static and Automated vs Interactive

["Hunkins, Andrew" <ahunkins@unimax.com>]

Agreed.  And this raises another point I've wanted to introduce, so
maybe this is the right time...

If we are successful, then the hard coded script writing will have a
very limited role.  Just as with the www and HTML, the HTML is now
almost always *dynamically* generated.  I don't know if this has been
discussed here before but I think it has some important ramifications
for the features and services xmlconf supports.

As a vendor of the higher level application layers for system
management, I'm all ready to dynamically generate the xmlconf right now.
So I view the CLI script author as a temporary customer... a very highly
skilled individual who should be doing something more productive than
debugging scripts.  Some of the xmlconf model assumes a human user
filling in forms, needing a certain type of feedback, etc.  Which is not
to say it won't work for an automated client app, I'm just saying that
we may be able to get a crisper spec if we drop the real time
interactive session requirement.  Or maybe it's not a requirement but
was not specifically excluded.

Are we willing to further define the xmlconf client app communication as
non-human-interactive?

-Andrew

p.s. I'll send you an off-list note regarding my interest in your
earlier paper.  Thanks!


> -----Original Message-----
> From: Margaret Wasserman [mailto:mrw@windriver.com]
> Sent: Thursday, June 12, 2003 6:45 PM
> To: Hunkins, Andrew
> Cc: Randy Presuhn; netconf@ops.ietf.org
> Subject: RE: Thoughts on NetConf Requirements
> 
> 
> 
> The goal is to help operators who currently have to use
> CLI and write perl and expect scripts to drive the
> configuration of devices.  Those scripts are very
> sensitive to seemingly benign CLI changes, like changing
> the formatting of a table, or the wording of an error
> message...
> 
> The outcome of the IAB network management workshop
> was instrumental in driving this work.  See RFC
> 3535 for details.
> 
> I also wrote a requirements I-D for this work, once upon
> a time, but it has since expired.  Although I'd like to
> think that it was instrumental in shaping the final
> protocol, it was only my personal work, not the work of
> an IETF WG.
> 
> If you're interested in seeing it, let me know and
> I'll send you a copy privately.
> 
> Margaret
> 
> 
> 

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