IETF Logo Mail Archive

Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?

"Fries, Steffen" <steffen.fries@siemens.com> Mon, 05 July 2021 09:38 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 5C9EE3A0CF2; Mon, 5 Jul 2021 02:38:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham 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 eRu0G0QAvw5t; Mon, 5 Jul 2021 02:38:03 -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 A8C913A0CD8; Mon, 5 Jul 2021 02:38:02 -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 490F34F0264; Mon, 5 Jul 2021 11:38:00 +0200 (CEST)
Received: from DEMCHDC8A0A.ad011.siemens.net (demchdc8a0a.ad011.siemens.net [139.25.226.106]) by mail1.dc4ca.siemens.de (Postfix) with ESMTPS id C3DA81A5714E3; Mon, 5 Jul 2021 11:37:58 +0200 (CEST)
Received: from DEMCHDC89XA.ad011.siemens.net (139.25.226.103) by DEMCHDC8A0A.ad011.siemens.net (139.25.226.106) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2176.14; Mon, 5 Jul 2021 11:37:58 +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; Mon, 5 Jul 2021 11:37:58 +0200
From: "Fries, Steffen" <steffen.fries@siemens.com>
To: Michael Richardson <mcr+ietf@sandelman.ca>, "Rob Wilton (rwilton)" <rwilton@cisco.com>, "anima@ietf.org" <anima@ietf.org>, "netmod@ietf.org" <netmod@ietf.org>, Toerless Eckert <tte@cs.fau.de>, Kent Watsen <kent+ietf@watsen.net>
Thread-Topic: [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
Thread-Index: AQHXcSJZCevmeqNnhUCF3zrB5xtXJqs0EVgg
Date: Mon, 05 Jul 2021 09:37:57 +0000
Message-ID: <46808a908497458db93ccbf16b8f0dd2@siemens.com>
References: <20210625190512.GB30200@faui48e.informatik.uni-erlangen.de> <5025.1624653668@localhost> <DM4PR11MB5438EE27158CDEAF63F89C97B5039@DM4PR11MB5438.namprd11.prod.outlook.com> <27560.1625013411@localhost> <b36e56b3970c4908af0d1cb00d08504c@siemens.com> <11899.1625437038@localhost>
In-Reply-To: <11899.1625437038@localhost>
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-07-05T09:37:56Z; 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=f48ed91c-279b-4b2f-9da4-7efba7aef191; MSIP_Label_a59b6cd5-d141-4a33-8bf1-0ca04484304f_ContentBits=0
document_confidentiality: Restricted
x-originating-ip: [139.21.146.182]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/MHP4nOv70BZzTNIhFqEumweVuGE>
Subject: Re: [netmod] [Anima] revising RFC8366 -- Re: BRSKI-AE enum issue -> empty, but what's he encoding ?
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: Mon, 05 Jul 2021 09:38:08 -0000

> From: Michael Richardson <mcr+ietf@sandelman.ca>
> Sent: Montag, 5. Juli 2021 00:17
> Fries, Steffen <steffen.fries@siemens.com> wrote:
>     >> I thought I wrote a really nice ASCII art version of what documents inherit
> from
>     >> RFC8366.  I can't find it in my outbox... I wonder if I nuked the draft by
> mistake.
>     >>
>     >> The short of it:
>     >> RFC8366 -> RFC8995 (voucher-request)
>     -> constrained-voucher (voucher-request, voucher)
>     -> brski-async-enroll (voucher-request)
> 
>     > Would it make sense to also state the voucher for BRSKI-AE as it also
>     > uses the voucher and tries to argue for a new assertion type
>     > (agent-proximity)?
> 
> I am of two feelings here.
> On the one hand, it would be IANA proceedurally simpler to include the new
> assertion type into the 8366bis document.
> 
> On the other hand, this means having some kind of explanation in RFC8366bis
> for the new choice, and that might force a lot of text to enter and get reviewed.
> 
> Once RFC8366bis is published, then async-enroll can make use of the IANA
> Considerations to allocate that new enum value.  That won't slow async-enroll
> down, because either way, it has to wait for RFC8366bis.
Yes true. Having the option doing it via an IANA considerations will be simpler for other drafts like async-enroll extending the assertions in the voucher. 

> Where I'm a bit blurry is how stuff like the YANG in RFC8995, which uses
> RFC8366 gets updated when IANA revises the module.  I think, it mostly doesn't
> matter because none of are generating code from YANG... AT THIS TIME.
> 
> --
> Michael Richardson <mcr+IETF@sandelman.ca>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
> 
> 
>

v2.23.0 | Report a Bug | By Email