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

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 17 July 2019 17:10 UTC

Return-Path: <mcr+ietf@sandelman.ca>
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 21956120786 for <anima@ietfa.amsl.com>; Wed, 17 Jul 2019 10:10:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3MdxwTLdbgha for <anima@ietfa.amsl.com>; Wed, 17 Jul 2019 10:10:51 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F57B12072D for <anima@ietf.org>; Wed, 17 Jul 2019 10:10:50 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 182803808A; Wed, 17 Jul 2019 13:10:44 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 41B128EF; Wed, 17 Jul 2019 13:10:48 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: Toerless Eckert <tte@cs.fau.de>
cc: anima@ietf.org, lamps@ietf.org, Sean Turner <turners@ieca.com>, Ignas Bagdonas <ibagdona@gmail.com>, max pritikin <pritikin@cisco.com>, Benjamin Kaduk <kaduk@mit.edu>
In-Reply-To: <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de>
References: <6535.1560786935@dooku.sandelman.ca> <20190710145907.ypo57aacomi73bdx@faui48f.informatik.uni-erlangen.de>
X-Mailer: MH-E 8.6; nmh 1.7+dev; GNU Emacs 24.5.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Date: Wed, 17 Jul 2019 13:10:48 -0400
Message-ID: <17732.1563383448@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/anima/dbPW_5bvtxGV0pBimlp_QnIZ8eQ>
Subject: Re: [Anima] addressing Content-Type-Encoding errata on EST / RFC7030 --- relationship to BRSKI
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: Wed, 17 Jul 2019 17:10:53 -0000

Toerless Eckert <tte@cs.fau.de> 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.

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

    > 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

    >> 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.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        |    IoT architect   [
]     mcr@sandelman.ca  http://www.sandelman.ca/        |   ruby on rails    [