[Anima] draft-li-rtgwg-protocol-assisted-protocol (was: Re: IETF 105 mic comments on draft-li-rtgwg-protocol-assisted-protocol)

Toerless Eckert <tte@cs.fau.de> Tue, 10 November 2020 16:52 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: anima@ietfa.amsl.com
Delivered-To: anima@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 220CB3A0AA7; Tue, 10 Nov 2020 08:52:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.649
X-Spam-Level:
X-Spam-Status: No, score=-1.649 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VSbXWlrPp-d1; Tue, 10 Nov 2020 08:52:42 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [131.188.34.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DCBC3A0B60; Tue, 10 Nov 2020 08:52:41 -0800 (PST)
Received: from faui48f.informatik.uni-erlangen.de (faui48f.informatik.uni-erlangen.de [131.188.34.52]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 86FD0548687; Tue, 10 Nov 2020 17:52:35 +0100 (CET)
Received: by faui48f.informatik.uni-erlangen.de (Postfix, from userid 10463) id 7DABA440059; Tue, 10 Nov 2020 17:52:35 +0100 (CET)
Date: Tue, 10 Nov 2020 17:52:35 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Jeffrey Haas <jhaas@pfrc.org>, Chenshuanglong <chenshuanglong@huawei.com>, Brian E Carpenter <brian.e.carpenter@gmail.com>, "anima-chairs@ietf.org" <anima-chairs@ietf.org>, Lizhenbin <lizhenbin@huawei.com>, "anima@ietf.org" <anima@ietf.org>, Guyunan <guyunan@huawei.com>
Cc: rtgwg@ietf.org, anima@ietf.org, rwilton@cisco.com
Message-ID: <20201110165235.GA17445@faui48f.informatik.uni-erlangen.de>
References: <20190722150231.GE28302@pfrc.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <20190722150231.GE28302@pfrc.org>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/gjmuVjpaow_NFTeCk_f2W6dFcVM>
Subject: [Anima] draft-li-rtgwg-protocol-assisted-protocol (was: Re: IETF 105 mic comments on draft-li-rtgwg-protocol-assisted-protocol)
X-BeenThere: anima@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <anima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/anima>, <mailto:anima-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/anima/>
List-Post: <mailto:anima@ietf.org>
List-Help: <mailto:anima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/anima>, <mailto:anima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Nov 2020 16:52:44 -0000

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