Great Circle Associates Network-Automation
(May 2005)
 

Indexed By Date: [Previous] [Next] Indexed By Thread: [Previous] [Next]

Subject: Re: ACL compiler [was: Network Automation: An Architects View]
From: Lori Barfield <itdirector @ gmail . com>
Date: Tue, 24 May 2005 04:52:45 -0700
To: Francis Liu <Francis . Liu @ optus . com . au>
Cc: network-automation @ greatcircle . com
Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Jxq8lO3Fbk/uNZYq+fw/1oDv19wES47WaOCMkhlsasKI+9MSavNnSEeRn7lpRwzEdOhpG/4imAqOHxR13xZ75ZKc3LcAS1Emf1rfYE5mJWLs1Mcn8xlawxHNRebh5QSCRsmtRtb1hb3oqSpomWK4L/XdkZSlYxVP2EtO6LkI6hk=
In-reply-to: <799B0CDA650143429C5EA103965B59F82C2842@shqw2ke001.optus.com.au>
References: <799B0CDA650143429C5EA103965B59F82C2842@shqw2ke001.optus.com.au>
Reply-to: Lori Barfield <itdirector @ gmail . com>

actually, those quotes are inaccurately attributed to me, francis.
those are Ian Glossop's good suggestions. :)

one thing i will say, though.  having been both a programmer 
and system administrator for many years, i understand how 
an implementation can limit the scope of the solution.  it's
not just an automatic thing "taken care of by someone doing 
the coding."  so let's continue to develop a wish list, but i'd 
enjoy seeing implementation suggestions (and experiences
from existing projects) as well.  we don't necessarily have to
wait for money to get an idea out of the theoretical.  let's see
what it takes to solve first.


...lori

On 5/23/05, Francis Liu <Francis.Liu@optus.com.au> wrote:
> > At 17:03 22/05/2005 -0700, Lori Barfield wrote:
> >
> > What I'm really suggesting is a community-based
> > standardisation effort to try to define in detail the "strict syntax".
> 
> I think this is a killer. I think the problem is too large, too
> apparently intractable for a community project. This sounds like
> something that the IETF (or a large enough vendor) would have a whole
> team working on. There may be difficulties in negotiating with vendors
> to provide a more-or-less static interface to the their systems.
> 
> There should be some level of "official" support, otherwise the various
> vendors may intentionally break compatibility with this config tool.
> (There are many reasons why they might do this.)
> 
> > I'd envisage that the interpreter would save the configs it
> > derived in a standardised filesystem layout (what ITIL might call a
> Configuration
> > Management DataBase) and call out to the deployment subsystem to
> supply the ...
> 
> As you say, you're not a programmer, so don't worry about the
> implementation, it'll be taken care of by someone doing the coding. The
> issues Daniel Hagerty has identified need some resolution first.
> 
> I think it's excellent that we've produced a wishlist. Now we need some
> money and time thrown at intelligent types to produce a workable idea
> that the business/community types can code and develop.
> 
> I wonder if anyone besides Daniel is actively analysing and thinking
> about this issue from a hard comsci perspective (turing, completeness,
> etc).
> 
> Regards,
> Francis
>


References:
Indexed By Date Previous: Re: ACL compiler [was: Network Automation: An Architects View]
From: "Francis Liu" <Francis.Liu@optus.com.au>
Next: Re: ACL compiler [was: Network Automation: An Architects View]
From: Cat Okita <cat@reptiles.org>
Indexed By Thread Previous: Re: ACL compiler [was: Network Automation: An Architects View]
From: "Francis Liu" <Francis.Liu@optus.com.au>
Next:
From: (nil)

Google
 
Search Internet Search www.greatcircle.com