Re: [netmod] [Anima] mcr's YANG question raised during the ANIMA WG session

Toerless Eckert <tte@cs.fau.de> Tue, 02 August 2022 00:09 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3FF0C13CCE7; Mon, 1 Aug 2022 17:09:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.661
X-Spam-Level:
X-Spam-Status: No, score=-1.661 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.248, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0_ye7Xyx9Ps0; Mon, 1 Aug 2022 17:09:18 -0700 (PDT)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24403C147920; Mon, 1 Aug 2022 17:09:15 -0700 (PDT)
Received: from faui48e.informatik.uni-erlangen.de (faui48e.informatik.uni-erlangen.de [131.188.34.51]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTPS id 1937358C4AF; Tue, 2 Aug 2022 02:09:08 +0200 (CEST)
Received: by faui48e.informatik.uni-erlangen.de (Postfix, from userid 10463) id 02AD74EB627; Tue, 2 Aug 2022 02:09:07 +0200 (CEST)
Date: Tue, 02 Aug 2022 02:09:07 +0200
From: Toerless Eckert <tte@cs.fau.de>
To: Michael Richardson <mcr+ietf@sandelman.ca>
Cc: "Fries, Steffen" <steffen.fries@siemens.com>, "Anima@ietf.org" <anima@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>
Message-ID: <YuhrI/iINFJxPOC7@faui48e.informatik.uni-erlangen.de>
References: <DU0PR10MB5196F26C92DD2F266A4FAC28F3949@DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM> <365823.1658933390@dooku> <DU0PR10MB5196ADB3702B7417B0589555F3979@DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM> <446675.1659033968@dooku> <DU0PR10MB51966008D0EA49AC6FCD3FB9F3999@DU0PR10MB5196.EURPRD10.PROD.OUTLOOK.COM> <539974.1659103385@dooku>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <539974.1659103385@dooku>
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/5fdmCRAyWwMgzyOWxrLQ6KwXKCA>
Subject: Re: [netmod] [Anima] mcr's YANG question raised during the ANIMA WG session
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 02 Aug 2022 00:09:19 -0000

Let me rephrase to make clear i understand.

We've got (A) BRSKI, and (B) and (C) two "independent" amendmentds
driven as independent RFCs. And neither (B) has (C) as reference,
nor vice versa, but both refer only to (A).

When a user wants to build product incorporating (A), (B), (C),
i am sure there is something we could have done wrong in (B), (C) so
you can not build an (A) amended by both (B) and (C). Worst case
(B) and (C) do conflicting amendmends by amending with the same
names. Which i guess we can safely exclude, but is that really the
only thing that can go awry ?

But lets assume we're past the "conflict" stage, and know the right
way to amend without conflict:

How much value is then in duplicating these amendmends into rfc8366bis ?
I guess we could amend (A), (B) and (C) in it if we wanted to, without
changing the semantic (and optional aspects) of what was added in
(A), (B) (C) ? And if we can do it, we should do it after (B), (C) became
(RFC, just to pull all stuff together ?

Cheers
    Toerless

On Fri, Jul 29, 2022 at 10:03:05AM -0400, Michael Richardson wrote:
> 
> Fries, Steffen <steffen.fries@siemens.com> wrote:
>     > Thank you for the clarification. This means we don't have to change
>     > anything in either BRSKI-PRM and constraint voucher, resp. in the
>     > general approach we use the voucher.
> 
> Yes!
> I was worred that there were dragons in the future, but seems not.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
>  -= IPv6 IoT consulting =-
> 
> 
> 



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