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
