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

Ted Lemon <mellon@fugue.com> Fri, 09 October 2020 16:09 UTC

Return-Path: <mellon@fugue.com>
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 1153F3A0B5A for <ipv6@ietfa.amsl.com>; Fri, 9 Oct 2020 09:09:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fugue-com.20150623.gappssmtp.com
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 c-T42RsoXSg8 for <ipv6@ietfa.amsl.com>; Fri, 9 Oct 2020 09:09:29 -0700 (PDT)
Received: from mail-qt1-x833.google.com (mail-qt1-x833.google.com [IPv6:2607:f8b0:4864:20::833]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1EFF23A0A50 for <ipv6@ietf.org>; Fri, 9 Oct 2020 09:09:29 -0700 (PDT)
Received: by mail-qt1-x833.google.com with SMTP id m9so8290061qth.7 for <ipv6@ietf.org>; Fri, 09 Oct 2020 09:09:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fugue-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=rfBrPlxmMcmyHz/4q2sNHe2Opa9zW5qL60RxZdWSZnY=; b=AUi2gNiVYhmTHE8GQ89WOeL2Sh2sq4ICrUWPrxUFbs7oY46cSxK7g2v1FDraQKfnsm 9MkeS3xoNYWO/DyfylYSaGBe0fETI58W34plZjosEX0+xxfIoAsvpj2rhQN6iIseR76/ y7d5UAZB4XtB8mod4p+kGGdUVyEAuECgLs1XYx3bd5y5Fq9NFAnpKncOuI+x/e8qAYUt I1xBX44j74kA6XZ7Vyh6SDeBffVb/pqXrj14yxB234K7qDY0p6cPo9BMQYItugqOi/em UZMctUIVbdjzpFW2U8Z6RN6pMidw6yRrZrCbmmdsYXHdqpcKEjxyAq3QkTWHu8Dz4bqI dJ0Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=rfBrPlxmMcmyHz/4q2sNHe2Opa9zW5qL60RxZdWSZnY=; b=Rb5G4cPGqwZWI+P/KfjZG/DDTGJUQyF6BN6iT3hFDS7q4DP3+EwjZDb7kdHi3c9GF6 ulfLEZBQgfE1vL//P+lxz63RSKYZiwpGMO/6h37YA8BqQgoz0T8GJosZqkS01g7a73gJ meOC+5g5j6mWi5BxQvnUl7owuMSIifBU2NhK3ly/ZVGiVBghCCLogHtmFWgoWqWl+KOj 2E4InsiksyhKsVvuCKj2oyvkpxTYTQJu9Ye1Q8B+qZC3S5PStu3/ozXE6vuxgdmB1VP5 NnNxz7dkyPJQxnZEDXf58ywXPfm663FpZQqMP492IJf1mxqbx7Mn1qxcdVR6MiYZ90HU AlWg==
X-Gm-Message-State: AOAM533LV16H+qiALGOfCg+NaVNACweDNaM2xmCNyy/7tul9IR/cge2p Ma9feKQFtNgTS+wsajGu2ELu2w==
X-Google-Smtp-Source: ABdhPJyZBjTOxBrOcfAxWvr3elEdzs+vbBwIaKMEql4N1U/UQ4JuflUONRUzGjF+Koe6awmg6YKLvA==
X-Received: by 2002:aed:2434:: with SMTP id r49mr13912824qtc.370.1602259766854; Fri, 09 Oct 2020 09:09:26 -0700 (PDT)
Received: from mithrandir.lan (c-24-91-177-160.hsd1.nh.comcast.net. [24.91.177.160]) by smtp.gmail.com with ESMTPSA id g19sm6351173qkm.64.2020.10.09.09.09.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 09 Oct 2020 09:09:26 -0700 (PDT)
From: Ted Lemon <mellon@fugue.com>
Message-Id: <AEFB6A49-E4DE-4254-AF95-977577735BD6@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_875560BA-7461-41A2-A26A-97BF46F5CEBA"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.0.3.2.82\))
Subject: Re: New Version Notification for draft-troan-6man-universal-ra-option-03.txt
Date: Fri, 09 Oct 2020 12:09:23 -0400
In-Reply-To: <7D8D67F3-6D08-434E-8CB1-58EDE76BFD46@employees.org>
Cc: Brian E Carpenter <brian.e.carpenter@gmail.com>, Michael Richardson <mcr+ietf@sandelman.ca>, 6man WG <ipv6@ietf.org>
To: otroan@employees.org
References: <7ab73890-62e3-8078-c55e-a4b896469082@gmail.com> <832804D8-5CFE-4922-9D7F-B8961F36EAFF@fugue.com> <7D8D67F3-6D08-434E-8CB1-58EDE76BFD46@employees.org>
X-Mailer: Apple Mail (2.3654.0.3.2.82)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/tzUDdLQrdpTOdL924WPArNny_t4>
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: Fri, 09 Oct 2020 16:09:31 -0000

On Oct 9, 2020, at 8:28 AM, otroan@employees.org wrote:
> The motivation for this work was to "make 6man out of a job", since I thought we spent way too much time discussing configuration information options. :)
> 
> Do you have other concerns around this too Ted?
> It's hard to predict how this could be used of course. I suppose you could define an DHCP route option with this. But you'd still need an agent in the OS that would act upon that configuration. And if you had that, you could obviously also do that with whatever other protocol you'd like to invent.

I think your motivation is interesting, but you’re still going to need a WG to write documents describing new options in this new format—we still need interop.

The DHC working group actually wrote a document on how to encode TLVs because we saw the same problem; this predated CBOR, and I don’t know if we would have been tempted by CBOR had it been available. My parser in ISC DHCP had a little option definition language that was used to parse options. Not exactly CDDL, but same idea.

I think formal descriptions of options as you have done with CDDL is definitely a good idea. I’m less enamored of CBOR simply because it’s the wrong tool for the job—we have to do extra work because it does extra stuff we don’t need. I get that because there are CBOR parsers readily available, it’s the most attractive nuisance, and I am not necessarily saying “definitely not,” but as I’ve already expressed, I definitely have reservations about it. 

It would be interesting to think through what we get extra with CBOR that actually matters for this use case—I’m obviously highlighting the negatives, but perhaps there are positives I’m missing other than “there are already high quality parsers available.”  E.g., one advantage I can see for CBOR with a validator is that if the two ends don’t actually agree on the data format, you’ll notice the problem quickly, whereas if you were just parsing a binary blob it might be less obvious that you, e.g., got the fields out of order or something.

I think if you aren’t actually proposing to redo existing options in CBOR, it would be good to make that really clear. I will admit that I skimmed, so I might have missed your dire warnings to that effect.