Subject: [core] yang-cbor and core-sid comments

From: Michael Richardson <[email-masked]>
Date: Wed, 15 May 2019 15:34:59 -0400

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 <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Michel Veillette <[email-masked]>
Date: Wed, 15 May 2019 20:27:48 +0000

Hi Michael

About "Given that the 3rd party registries are now out of scope."

What do you means exactly?
The "SID Mega-Range" registry (https://tools.ietf.org/html/draft-ietf-core-sid-06#section-6.2.2) is still supported for the delegation of the management of a block of SIDs to  third parties (e.g.  SDOs, registrars, etc).

Regards,
Michel

-----Original Message-----
From: core <[email-masked]> On Behalf Of Michael Richardson
Sent: Wednesday, May 15, 2019 3:35 PM
To: [email-masked]
Subject: [core] yang-cbor and core-sid comments

In my listening in catch-up, just got to:
   https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fyoutu.be%2F2EP-qms-IEU%3Ft%3D5245&amp;data=02%7C01%7C%7C586dcdea3a064da2e98308d6d96c7501%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C636935457191339911&amp;sdata=vU0SQ0%2FEQ7npVt2D3XFxxYZEj6TbsFVVOTMmo%2BxXM5M%3D&amp;reserved=0

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 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 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 <[email-masked]>, Sandelman Software Works  -= IPv6 IoT consulting =-

---

From: Michael Richardson <[email-masked]>
Date: Wed, 15 May 2019 18:08:26 -0400

> About "Given that the 3rd party registries are now out of scope."

Hmm. I thought I understood that from one of the slides.
   https://youtu.be/2EP-qms-IEU?t=5245

I thought it said that on slide "SID changes in future v06"
Looking again... seems I misunderstood!

I still don't know what will happen to comi.space allocated ranges.

Sorry for confusion!