Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)

"Fries, Steffen" <steffen.fries@siemens.com> Thu, 17 June 2021 16:12 UTC

Return-Path: <steffen.fries@siemens.com>
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 EB6AF3A2560; Thu, 17 Jun 2021 09:12:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.795
X-Spam-Level:
X-Spam-Status: No, score=-1.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 4NdDt114E7ZP; Thu, 17 Jun 2021 09:12:55 -0700 (PDT)
Received: from gw-eagle1.siemens.com (gw-eagle1.siemens.com [194.138.20.72]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79FAE3A257F; Thu, 17 Jun 2021 09:12:54 -0700 (PDT)
Received: from mail1.dc4ca.siemens.de (mail1.dc4ca.siemens.de [139.25.224.78]) by gw-eagle1.siemens.com (Postfix) with ESMTPS id 43F0F4F0339; Thu, 17 Jun 2021 18:12:49 +0200 (CEST)
Received: from DEMCHDC8A1A.ad011.siemens.net (sop-solman.siemens.com [139.25.226.107]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id B7C7D1A280189; Thu, 17 Jun 2021 18:12:49 +0200 (CEST)
Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A1A.ad011.siemens.net (139.25.226.107) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Thu, 17 Jun 2021 18:12:49 +0200
Received: from DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) by DEMCHDC89XA.ad011.siemens.net ([139.25.226.103]) with mapi id 15.01.2176.014; Thu, 17 Jun 2021 18:12:49 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Kent Watsen <kent+ietf@watsen.net>, Michael Richardson <mcr+ietf@sandelman.ca>, "netmod@ietf.org" <netmod@ietf.org>, "anima@ietf.org" <anima@ietf.org>, "Werner, Thomas" <thomas-werner@siemens.com>
Thread-Topic: [Anima] [netmod] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)
Thread-Index: AQHXYwO5qG4OVLZ5lUaNPr0y7qLU/qsYOWZg///3M4CAACzS4A==
Date: Thu, 17 Jun 2021 16:12:49 +0000
Message-ID: <06674cb9709f4bd6bc2af297b929163f@siemens.com>
References: <anima-wg/anima-brski-async-enroll/issues/18@github.com> <19872.1623779796@localhost> <0100017a16ff590b-6803346f-2ef6-4b19-88bf-3c670e32d5a0-000000@email.amazonses.com> <CABCOCHQRJB3nca36bz+gVykw5fxym7ji3GJrVMcrsW+6uUopYg@mail.gmail.com> <c8c4ea615bb2450c9a1a9fccb956909f@siemens.com> <CABCOCHRs7npz4nv3KnfHSGaDEuskPbdOSn-bjXt83r+46VEaRg@mail.gmail.com>
In-Reply-To: <CABCOCHRs7npz4nv3KnfHSGaDEuskPbdOSn-bjXt83r+46VEaRg@mail.gmail.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Enabled=true; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SetDate=2021-06-17T16:12:48Z; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Method=Standard; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_Name=restricted-default; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_SiteId=38ae3bcd-9579-4fd4-adda-b42e1495d55a; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ActionId=13e8d305-8e2d-4b70-ad16-2e3a6fdcef52; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [144.145.220.66]
Content-Type: multipart/alternative; boundary="_000_06674cb9709f4bd6bc2af297b929163fsiemenscom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/wqHMGNqxstai2-G37b3yt7QodU4>
Subject: Re: [netmod] [Anima] [anima-wg/anima-brski-async-enroll] Definition of new assertion type (agent-proximity) for the voucher (#18)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 17 Jun 2021 16:12:59 -0000

Hi Andy,

Thanks for the reference. I have to dive into that a little deeper. Based on your previous comment, it would be possible to use the “deviate replace” to and replace the existing enum in the voucher definition by an enhanced enum definition in our document. If I understood this right, it is probably the easiest way.

Best regards
Steffen

From: Andy Bierman <andy@yumaworks.com>
Sent: Donnerstag, 17. Juni 2021 17:19


I am not really following this specific issue.
I was just pointing out that YANG enumeration types cannot be augmented.
It is the wrong terminology, since only schema nodes can be augmented.

>From: Anima anima-bounces@ietf.org<mailto:anima-bounces@ietf.org> On Behalf Of Andy Bierman
>An enumeration type is hard-wired.
Hardwired in terms of a fixed definition of values for the enum in RFC 8366?

>No enums can be added via augmentation.
That means just the definition of an additional enum value is not enough.

>You have to "deviate replace" the type-stmt to add an enum externally,
As I’m not too deep in YANG, could you provide more information on this part?  Would this be an approach to (just) redefine the type enumeration in the leaf “assertion” (https://datatracker.ietf.org/doc/html/rfc8366#page-11<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc8366%23page-11&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7Cccdb6da524d24947105d08d931a33d66%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595399442930701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=8VRqAnhX6Ug7JfUYJYi6VPDmwnXcFg3oa1B9GcMDf7g%3D&reserved=0>) and adding the new assertion type “agent-proximity”? Would this require to keep all enums already defined in RFC 8366 or could we just use the ones necessary in BRSKI-AE?


https://datatracker.ietf.org/doc/html/rfc7950#section-7.20.3<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc7950%23section-7.20.3&data=04%7C01%7Ccef9763c-149c-4881-b9c2-5fedc277663a%40ad011.siemens.com%7Cccdb6da524d24947105d08d931a33d66%7C38ae3bcd95794fd4addab42e1495d55a%7C1%7C0%7C637595399442930701%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=eytq7Vf%2BXgcEIa8TfsAozmJ9sKINN6a%2FHgdLrKvJNX8%3D&reserved=0>


>or you have to update the module and add the enum inline.
Does this result in an update of the module “ietf-voucher” or to define a new module, which imports and augments the voucher by adding the new enum?

Best regards
Steffen


Andy