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

Raymond Burkholder <ray@oneunified.net> Tue, 08 January 2019 22:46 UTC

Return-Path: <ray@oneunified.net>
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 8EA741311D7 for <ipv6@ietfa.amsl.com>; Tue, 8 Jan 2019 14:46:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ResyefnoFN6b for <ipv6@ietfa.amsl.com>; Tue, 8 Jan 2019 14:46:05 -0800 (PST)
Received: from mail1.oneunified.net (mail1.oneunified.net [63.85.42.215]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 263E21311CF for <ipv6@ietf.org>; Tue, 8 Jan 2019 14:46:05 -0800 (PST)
X-One-Unified-MailScanner-Watermark: 1547592360.8924@Rks3IGr7HCUFe9lZBFuYpg
X-One-Unified-MailScanner-From: ray@oneunified.net
X-One-Unified-MailScanner: Not scanned: postmaster@oneunified.net
X-One-Unified-MailScanner-ID: x08Mjwr8017349
X-OneUnified-MailScanner-Information: Please contact the ISP for more information
Received: from [10.55.40.115] (h96-45-2-121-eidnet.org.2.45.96.in-addr.arpa [96.45.2.121] (may be forged)) (authenticated bits=0) by mail1.oneunified.net (8.14.4/8.14.4/Debian-4) with ESMTP id x08Mjwr8017349 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NOT); Tue, 8 Jan 2019 22:46:00 GMT
Subject: Re: New Version Notification for draft-troan-6man-universal-ra-option-01.txt
To: Ole Troan <otroan@employees.org>, Carsten Bormann <cabo@tzi.org>
Cc: 6man WG <ipv6@ietf.org>
References: <154602855914.21618.6591622501322594455.idtracker@ietfa.amsl.com> <414CE9D9-6103-4955-9D37-3A424F64F99D@employees.org> <441b7a9c-2891-6e5c-dbd7-3b3e3263567e@gmail.com> <D349CB68-5F7B-4A46-9658-A2B03B3ED0A0@employees.org> <664FAFF0-8559-4022-9446-D25EBF215373@tzi.org> <930E753D-8D1C-4EA2-9705-7AC11380CA54@employees.org>
From: Raymond Burkholder <ray@oneunified.net>
Organization: One Unified Net Limited
Message-ID: <cf80b0f3-a31a-8644-b7e6-d75c984b71a7@oneunified.net>
Date: Tue, 08 Jan 2019 15:45:58 -0700
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <930E753D-8D1C-4EA2-9705-7AC11380CA54@employees.org>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/3VUf8GvpyaJDEwWyU1FP-wFoSvY>
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: Tue, 08 Jan 2019 22:46:08 -0000

On 2018-12-30 10:36 a.m., Ole Troan wrote:
> Wouldn’t that cause interoperability problems for a host stack receiving CBOR that cannot be decoded to JSON?
>> I’m late to this discussion and apparently missed the part where it was divulged why JSON support might be a good idea in the first place.
>> RA information is often binary in nature and benefits from a compact representation.  For me, this screams for CBOR, but I may be missing something (see above).
> The current drafts says:
>
>    The option data is described using the schema language CDDL   [
>    I-D.ietf-cbor-cddl], with the limitation described in appendix E
>    "Use with JSON" and encoded in CBOR [RFC7049].  The restriction is
>    there to ensure an easy representation in JSON [RFC8259].
In case it is relevant to the JSON side of things, on another mailing 
list, this was presented:

http://seriot.ch/parsing_json.php -- Parsing JSON is a Minefield 
(caveats for something, which at first blush, seems to be a simple protocol)
> Brian suggested relaxing the appendix E restriction. I think that would result in interoperability issues, and suggested we discuss removing the restriction altogether.
> The downside is user-friendlyness. User-friendly decoders would require type knowledge either through tags or knowing the CDDL.
> Which wouldn’t be required for JSON representation of course.