[core] yang-cbor and core-sid comments

Michael Richardson <mcr+ietf@sandelman.ca> Wed, 15 May 2019 19:35 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: core@ietfa.amsl.com
Delivered-To: core@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5917912015C for <core@ietfa.amsl.com>; Wed, 15 May 2019 12:35:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 SJQkfLUvlubC for <core@ietfa.amsl.com>; Wed, 15 May 2019 12:35:02 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 94B561200F1 for <core@ietf.org>; Wed, 15 May 2019 12:35:01 -0700 (PDT)
Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id 879B038271 for <core@ietf.org>; Wed, 15 May 2019 15:34:14 -0400 (EDT)
Received: by sandelman.ca (Postfix, from userid 179) id 6C65AE3B; Wed, 15 May 2019 15:34:59 -0400 (EDT)
Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 6A04FA2 for <core@ietf.org>; Wed, 15 May 2019 15:34:59 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: core@ietf.org
X-Attribution: mcr
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, 15 May 2019 15:34:59 -0400
Message-ID: <4502.1557948899@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/core/3B_sBQb1n8gp5VL2VojH4268kBI>
Subject: [core] yang-cbor and core-sid comments
X-BeenThere: core@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <core.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/core>, <mailto:core-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/core/>
List-Post: <mailto:core@ietf.org>
List-Help: <mailto:core-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/core>, <mailto:core-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 15 May 2019 19:35:05 -0000

In my listening in catch-up, just got to:
   https://youtu.be/2EP-qms-IEU?t=5245

which is Alex Pelov on YANG-CBOR status.

I'm okay with things that change the SID files, as early adopters are going
to have to deal with some changes anyway, and so we need to pin things down
without automation today.  So if there are changes, then please don't rush,
let's think them through.
Let's also think about if we can arrange to pin things.

We have some interop to report from the Fairhair Alliance constrained voucher
work that occured March 25/26.  This was between open source and
vendor-proprietary.  We would have four or five participants, but we had
layer-3 issues that prevented it.

I think that the "work that will be done before the end of the week"
is included in the updates to sid-06?
I don't think that I understood the IANA conversation that was reported on.
(Also, I've been falling off IETF lists due to new spam filter, so I may have
missed something, feel free to tell me so)

I'm so glad that this is advancing. I reviewed the changes between:
draft-ietf-core-sid-05.txt  and -06:

I found the text improved by the use of Appendix C.

I would like to know if the WG will grandfather the
draft-ietf-anima-constrained-voucher use of the comi.space allocation, or if
we need to renumber, and if so, how can we do this soonest, as we have
multiple implementers with running code.
Given that the 3rd party registries are now out of scope.

I also looked at draft-ietf-core-yang-cbor-07 and draft-ietf-core-yang-cbor-10:

I looked again at the enumeration support, trying to remember why did not
use it before in constrained-voucher.  Perhaps we still can/should.
It is unclear if refinement of a yang module can add value{} statements.
I feel insecure relying on RFC7950 9.6.4.2 algorithm.
I wouldn't mind using SIDs for enumerations as well.

--
Michael Richardson <mcr+IETF@sandelman.ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-