Toerless, We will provide a slot, most likely during the 2nd meeting. Please send an email to RTGWG with a short intro so people who might be interested have the time read up.
Thanks! Cheers, Jeff On Nov 10, 2020, 11:48 AM -0800, Brian E Carpenter <[email protected]>, wrote: > I'd like to underline what Toerless said. I looked at the two use casess > in the protocol-assisted-protocol draft and they seem very easy to > map onto GRASP. I don't really have time before the meeting to do > that but they are certainly use cases we could have included in the > original use case BOF that led to ANIMA. > > Regards > Brian Carpenter > > On 11-Nov-20 05:57, Toerless Eckert wrote: > > 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: <[email protected]> > > > > 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 > > > > [email protected] > > > > https://www.ietf.org/mailman/listinfo/rtgwg > > > > > > -- > > > --- > > > [email protected] > >
_______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
