Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt

Ole Troan <otroan@employees.org> Thu, 08 October 2020 22:17 UTC

Return-Path: <otroan@employees.org>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 074F53A0EFC for <ipv6@ietfa.amsl.com>; Thu, 8 Oct 2020 15:17:26 -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, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, 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 5vgydHDpMEbl for <ipv6@ietfa.amsl.com>; Thu, 8 Oct 2020 15:17:24 -0700 (PDT)
Received: from clarinet.employees.org (clarinet.employees.org [IPv6:2607:7c80:54:3::74]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FD083A0CE6 for <ipv6@ietf.org>; Thu, 8 Oct 2020 15:17:24 -0700 (PDT)
Received: from [192.168.10.181] (201.51-175-101.customer.lyse.net [51.175.101.201]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by clarinet.employees.org (Postfix) with ESMTPSA id 3391D4E11A64; Thu, 8 Oct 2020 22:17:24 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail-DC298524-7011-4AC5-BDDD-F85C2382B78F"
Content-Transfer-Encoding: 7bit
From: Ole Troan <otroan@employees.org>
Mime-Version: 1.0 (1.0)
Subject: Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt
Date: Fri, 09 Oct 2020 00:17:22 +0200
Message-Id: <242F3F87-5DC4-4E17-AB3F-B0451CFCDA74@employees.org>
References: <FEF28145-A2CC-4464-AC1D-DA4DC40A66AB@fugue.com>
Cc: Michael Richardson <mcr+ietf@sandelman.ca>, ipv6@ietf.org
In-Reply-To: <FEF28145-A2CC-4464-AC1D-DA4DC40A66AB@fugue.com>
To: Ted Lemon <mellon@fugue.com>
X-Mailer: iPhone Mail (18A393)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/ZYZkxqzvlIzvGaW1XpLZWn8KedE>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Oct 2020 22:17:26 -0000

Which is why the objects are described in CDDL. 

Ole

> On 9 Oct 2020, at 00:10, Ted Lemon <mellon@fugue.com> wrote:
> 
> On Oct 8, 2020, at 2:09 PM, Michael Richardson <mcr+ietf@sandelman.ca> wrote:
>> Assuming you only write one TLV parser, and one JSON parser, and you use them
>> both once, then your comparison is valid.
> 
> You missed my main point, which is that you have to write a validator for each data object. So yes, maybe in the ideal case you have a really great CBOR parser that even lives up to some of the promises that Brian quoted from the abstract. And maybe you have good validators for some data objects, and not as good validators for other data objects. Who knows?
> 
>> How many TLV formats does the IETF have?  Seven? Ten?
> 
>> How many are written with the same care as the CBOR (apples to apples here), parser?
>> The goal here is not to enable embedded systems to parse RA option in
>> python[%], but to enable new RA options to be passed through to
>> *applications* (not kernels) that need them.
> 
> “the CBOR parser?”
> 
> I don’t disagree that it would be nice to have a common TLV format document that specified all the data types, how arrays are represented, how dictionaries are represented, etc. What I am saying is simply that specifying CBOR not only doesn’t automatically make things safe, but in fact actually makes it a lot easier to write code that is unsafe, for exactly the reason Brian mentioned—it’s really easy to throw a binary blob at a CBOR parser and get a data structure back, and it’s really easy to not fully validate that data structure. You can always do that later.
> 
> What you really want is something like what PHB did a while back: define the data encapsulation as a grammar from which a parser can simply be compiled.
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------