Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI

Toerless Eckert <> Wed, 17 July 2019 17:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7634D120861 for <>; Wed, 17 Jul 2019 10:39:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.95
X-Spam-Status: No, score=-3.95 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id upz0pLAnDL7s for <>; Wed, 17 Jul 2019 10:39:48 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 268C4120848 for <>; Wed, 17 Jul 2019 10:39:47 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D8B7454800B; Wed, 17 Jul 2019 19:39:42 +0200 (CEST)
Received: by (Postfix, from userid 10463) id C966A440041; Wed, 17 Jul 2019 19:39:42 +0200 (CEST)
Date: Wed, 17 Jul 2019 19:39:42 +0200
From: Toerless Eckert <>
To: Michael Richardson <>
Cc:,, Sean Turner <>, Ignas Bagdonas <>, max pritikin <>, Benjamin Kaduk <>
Message-ID: <>
References: <> <> <17732.1563383448@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <17732.1563383448@localhost>
User-Agent: NeoMutt/20170113 (1.7.2)
Archived-At: <>
Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Autonomic Networking Integrated Model and Approach <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jul 2019 17:39:51 -0000

On Wed, Jul 17, 2019 at 01:10:48PM -0400, Michael Richardson wrote:
> Toerless Eckert <> wrote:
>     > Errata 5107 on the other hand seems to be asking to remove CTE header
>     > by default, but doesn't really say what to do with 7030 base64 payload.
>     > One could interpret it to send binary which would be backward
>     > incompatible, or one could interpret it as sending base64 by mutual
>     > agreement, but without explicitly writing this into a text its
>     > guesswork.
> Based upon feedback on the -00 and -01, it appears that nobody actually sends
> the CTE header, so we have no signal about it being binary or base64, and
> everyone just sends base64.  So the clarification becomes that the CTE
> header is redundant, should be ignored, and the payload is always base64.

Great. That could be written more explicitly in the draft.

> If we did an rfc7030bis, then we might define new end-points, but that seems
> like busy work to me.

Agreed. A small update RFC will be much more economical and if well
written also much easier to understand.

>     > What seems to be incomplete in your draft is whether to send or not to
>     > sent CTE, it only says to ignore it upon receipt. So, whats the minimum
>     > requirement for fully backward compatibility on sending ?
> always base64 the payloads

I figured that. But i think you are also saying that you do
not need to send CTE to be backward compatible, thats even better.

>     >> 4) ANIMA BRSKI needs to clarify things itself, and I will add a
>     >> section on this, but I'm hesistant to add a normative reference here.
>     >> I have an idea of appropriate text that I will post on Tuesday.
>     >> Getting clarity here is really the most important thing for me.
>     > I would like to see avoiding to drag this issue into BRSKI text unless
>     > we have to. I would simply have a reference to this draft in BRSKI and
>     > one sentence about it near the first mentioning of 7030 in BRSKI.
> I have added a section to BRSKI that clarifies that, despite EST7030 being
> base64 encoded, BRSKI payloads (voucher, voucher-request) are binary.

Thats ok. to ensure that BRSKI is as independent of an rfc7030 update
draft as possible, but it would be good to also suggest doing this in your updte
draft so that any other rfc7030 extensions could foolow that lead.

Btw: If there is no more feedback from the WGs you addressed in this
mail, please consider asking for a slot on the agenda of eithre of them
anyhow. Much harder for them to ignore the issue in email than in the
room ;-)

(which of course doesn't mean that we shouldn't discuss in ANIMA, but i
guess we agree that any better http/est? expert opinion input would be helpfull).


> -- 
> ]               Never tell me the odds!                 | ipv6 mesh networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
> ]        |   ruby on rails    [