[Anima] RTGWG-chairs: slot for RTGWG@109 to present on GRASP ? (was: Re: draft-li-rtgwg-protocol-assisted-protocol (was: Re: IETF 105 mic comments on draft-li-rtgwg-protocol-assisted-protocol))

In followup to the discuss on  draft-li-rtgwg-protocol-assisted-protocol:

Checking RTGWG agenda, it seems you might still have time available,
so if you are interested, i would be happy to whip up a few slides
to five an overview of GRASP and how we imagine it to be useable
to automate operational workflows for various services, including
routing protocols.

Cheers
    Toerless

In-Reply-To: <20201110165235.GA17445@faui48f.informatik.uni-erlangen.de>

On Tue, Nov 10, 2020 at 05:52:35PM +0100, Toerless Eckert wrote:
> I see subject draft is again on the agenda of RTGWG'109 and the authors also asked
> for a slot to present to ANIMA (which we would be happy to have, time permitting). 
> 
> Some thoughts as contributor, maybe ANIMA chair:
> 
> Reading the draft it looks like a reinvention of the ANIMA GRASP protocol
> that we finished almost 3 years ago, but without many of the mechanisms
> that make GRASP a well reuseable, easily extensible protocol. So i wonder
> why we would want to also do another more imited protocol for the same
> goals.
> 
> On the mike RTGWG @IETF105, interest was raised to see a more comprehensive
> signalling enxchange example. Version 03 of the document seems to have
> expanded the BGP example a bit, but still not comprehensive enough for me
> to understand if/how this approach would ultimately work.
> 
> I would like to encourage the authors to concentrate on fully specifying
> intended use-cases - ideally by simply specifying the use-case as
> solution using GRASP (we call this GRASP objectives). I am sure
> ANIMA participants (including me) would be happy to help explaining how
> to specify such a protocol on top of GRASP once we understand the use-case.
> 
> Cheers
>     Toerless
> 
> On Mon, Jul 22, 2019 at 11:02:31AM -0400, Jeffrey Haas wrote:
> > To repeat my comments from the microphone regarding this draft:
> > 
> > We already have per-protocol operational and configuration state via the
> > IETF yang models for a given protocol.
> > 
> > We also have mechanisms to fetch operational state for such protocols; e.g.
> > netconf and restconf.
> > 
> > Rather than inventing a new mechanism to do troubleshooting for a protocol,
> > I'd suggest it makes better sense to augment existing IETF yang models to
> > include RPCs for interacting with troubleshooting for that protocol.
> > 
> > -- Jeff
> > 
> > _______________________________________________
> > rtgwg mailing list
> > rtgwg@ietf.org
> > https://www.ietf.org/mailman/listinfo/rtgwg
> 
> -- 
> ---
> tte@cs.fau.de

-- 
---
tte@cs.fau.de