Subject: [Anima] Charter/DevOps

From: Brian E Carpenter <[email-masked]>
Date: Mon, 5 Nov 2018 20:49:47 +1300

>  including the evolution of DevOps for networks through the support of more agile and modular developed and deployed networking automation.

I don't understand why this different from the discussion of an ecosystem for ASAs, plus coordination and life cycle management, already developed by Laurent and colleagues. Am I missing something? (Listening to Laurent speak now, I think he probably agrees.)

Whether this is protocol development is a separate question, but we are an Ops Area WG.

   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 7 Nov 2018 04:44:35 +0100

Brian:

To sum up my undersandin of the rooms feedback, comments said
that DevOps is a badly defined term and easily perceived as
empty marketing.

I was using this term in the charter to highlight that the WG
should want to focus in its work especially on the ASA
ecosystem on making it support the evolving deveopment
and operational practices of networks. DevOps specifically
(IMHO) describes the approach in which there are not two
strictly separated development and operations team: Such as
the traditional deveopment team in a vendor and an operations
theam in the network owner/operator. 

s
Ultimately, i would like to be able to compose the running
software on a router from separate software module binaries
for example on a per autonomic-function basis relying only
on standardized interfaces beteween them. Would allow for
example the network owner/operator to replace an existing
autonomic function with a new better implement the operator
implemented themselves. That of course is something that would only
happen if the network owners use some form of DevOps, aka: dare
to write software - or even dare to combine software from
different vendors running on the same system.

One key outcome of these considerations is also that we
could end up in a situation where we should or might want to
have APIs for AF/ASA's be standard track like it was done
recently in TAPS.

In TAPS, to the best of my understanding, the abstract APIs
where made standards track because external entities such as
w3c expressed the interest to develop concrete APIs out of these 
abstract IETF APIs, something which if we are lucky would
also happen with APIs for ANIMA AF/ASA. And this external
use of IETF abstract APIs was seen as best supported by employing
the much elaborate standards-track review to those documents to also
give those external SDO's the best guarantee that they are
developing against well cooked specs.

Cheers
    Toerless

On Mon, Nov 05, 2018 at 08:49:47PM +1300, Brian E Carpenter wrote:
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima