Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt

Rob Austein <sra@hactrn.net> Tue, 04 August 2015 13:50 UTC

Return-Path: <sra@hactrn.net>
X-Original-To: sidr@ietfa.amsl.com
Delivered-To: sidr@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 657361B2E0D for <sidr@ietfa.amsl.com>; Tue, 4 Aug 2015 06:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.31
X-Spam-Level:
X-Spam-Status: No, score=-1.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_71=0.6, T_RP_MATCHES_RCVD=-0.01] autolearn=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 eQx6exwdbVCF for <sidr@ietfa.amsl.com>; Tue, 4 Aug 2015 06:50:55 -0700 (PDT)
Received: from cyteen.hactrn.net (cyteen.hactrn.net [66.92.66.68]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D45671B31EE for <sidr@ietf.org>; Tue, 4 Aug 2015 06:48:41 -0700 (PDT)
Received: from minas-ithil.hactrn.net (c-24-34-34-101.hsd1.ma.comcast.net [24.34.34.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "nargothrond.hactrn.net", Issuer "Grunchweather Associates" (verified OK)) by cyteen.hactrn.net (Postfix) with ESMTPS id A3C867CBD for <sidr@ietf.org>; Tue, 4 Aug 2015 13:48:39 +0000 (UTC)
Received: from minas-ithil.hactrn.net (localhost [IPv6:::1]) by minas-ithil.hactrn.net (Postfix) with ESMTP id 6347819EBD3A for <sidr@ietf.org>; Tue, 4 Aug 2015 09:48:55 -0400 (EDT)
Date: Tue, 04 Aug 2015 09:48:55 -0400
From: Rob Austein <sra@hactrn.net>
To: sidr@ietf.org
In-Reply-To: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com>
References: <44C6D623-C513-41FA-9B20-09FFAF0CEED7@tislabs.com>
User-Agent: Wanderlust/2.15.5 (Almost Unreal) Emacs/22.3 Mule/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka")
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-Id: <20150804134855.6347819EBD3A@minas-ithil.hactrn.net>
Archived-At: <http://mailarchive.ietf.org/arch/msg/sidr/_rfXRRIVTh9-RJaZTlnVgTYKUY0>
Subject: Re: [sidr] base64 line breaks and draft-ietf-sidr-rfc6490-bis-04.txt
X-BeenThere: sidr@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Secure Interdomain Routing <sidr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidr>, <mailto:sidr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidr/>
List-Post: <mailto:sidr@ietf.org>
List-Help: <mailto:sidr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidr>, <mailto:sidr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Aug 2015 13:50:56 -0000

At Tue, 4 Aug 2015 07:06:22 -0400, Sandra Murphy wrote:
> 
> Speaking as document shepherd.
> 
> The IETF Last Call for  draft-ietf-sidr-rfc6490-bis-04.txt  ended on 23 July 2015.
> 
> One issue of substance arose - permitting or forbidding line breaks
> in the base64 encoding of the trust anchor, and, if permitted, at
> what max line length.

I know I'm going to regret this, but somebody has to say it.

This is not a substantive issue.  This is an example of:

   https://en.wikipedia.org/wiki/Parkinson%27s_law_of_triviality

In this case it's even sillier than usual, because we have multiple
interoperable implementations in the field and there is no real
problem here that needs to be solved.  So the bikeshed was built years
ago and we are now arguing about what color it should have been
painted in some alternate universe.

> Preferences for Richard?s option #2 (allow but do not mandate line
> breaks) or for Richard?s option #3 (mandate line breaks)?  Note that
> option #3 means we have to settle on a max line length.

Option #2 matches the running code.

Absent some pressing need to make TALs fit on punch cards, the only
benefit that option #3 brings is the opportunity to declare running
code retroactively out of spec for trivial reasons.