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
