CBOR tag conflict :(

[mikeal]

Hello from the IPLD project ;)

For a few years we’ve been using CBOR tag 42 in dag-cbor. It’s actually the only tag we use, and we use it to note when something is a link to another piece of data. At the time we started using it there was nothing registered but we noticed that the IANA registry recently assigned it to this spec.

It would be very hard for us to migrate given the amount of data already created and persisted in the network.

[cabo]

Well, the point of a registry is that you can register code points so they are not taken from you.

Can you tell us more about the hardship you will be experiencing? If you make a very good point, maybe we can still fix this.

[lemikev]

Hi Carsten Changing these tags on our side is not too difficult. If we decide to change them, the decision need to be done quickly and applied to the IANA site and the draft. Ivaylo, I suggest to postpone the revision of the YANG to CBOR draft until a decision is taken. Regards, Michel From: cabo <notifications@github.com> Sent: 1 août 2019 15:23 To: core-wg/yang-cbor <yang-cbor@noreply.github.com> Cc: Subscribed <subscribed@noreply.github.com> Subject: Re: [core-wg/yang-cbor] CBOR tag conflict :( (#13) Well, the point of a registry is that you can register code points so they are not taken from you. Can you tell us more about the hardship you will be experiencing? If you make a very good point, maybe we can still fix this. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcore-wg%2Fyang-cbor%2Fissues%2F13%3Femail_source%3Dnotifications%26email_token%3DADZVLN766ALB27DP6RRXUDDQCMZZFA5CNFSM4IITHQQKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3LUCVA%23issuecomment-517423444&data=02%7C01%7CMichel.Veillette%40trilliant.com%7Ceda0562657bb48daadc408d716b5a993%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637002841808318493&sdata=eqckM4vSwM9Z0RZvhacnIqwuBpg5fbt3u2A39nScEYo%3D&reserved=0>, or mute the thread<https://can01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FADZVLN6YEQ72V3MP5U2GSATQCMZZFANCNFSM4IITHQQA&data=02%7C01%7CMichel.Veillette%40trilliant.com%7Ceda0562657bb48daadc408d716b5a993%7C4f6fbd130dfb415085c3d43260c04309%7C0%7C0%7C637002841808318493&sdata=%2Fy5QOJeWa1P9oXOmkVp5Adk6anE%2B1684s3KI9%2FAy%2FSM%3D&reserved=0>.

[vmx]

Here's a bit more background on this. We use Tag 42 to identify CIDs. Those CIDs are constructed out of several other specifcations. The plan is to get the CID (as well as the other specs) through the IETF standards process. Some early drafts were already submitted (multihash and multibase).

[cabo]

Thank you. Two more questions:

(1) is there a specification (specifications are required for 1+1-byte tags)?
(2) can you say more about the installed base that would be invalidated by using a different tag number for CIDs?

[vmx]

(1) is there a specification (specifications are required for 1+1-byte tags)?

I just read the RFCs about what "Specification Required" means. If I understood it correctly it doesn't need to be an IETF one. I would hope that this one: https://github.com/multiformats/cid/ is good enough to count as such a spec.

[cabo]

(1) is there a specification (specifications are required for 1+1-byte tags)?

I just read the RFCs about what "Specification Required" means. If I understood it correctly it doesn't need to be an IETF one.

That is correct.

I would hope that this one: https://github.com/multiformats/cid/ is good enough to count as such a spec.

I think so (well, maybe you could improve the references a bit), except that it doesn't say anything about how you use the CBOR tag.

[Stebalien]

That spec is here: https://github.com/ipld/specs/blob/master/block-layer/codecs/DAG-CBOR.md. The CID spec just defines the structure of the type we're tagging with 42.

[vmx]

(2) can you say more about the installed base that would be invalidated by using a different tag number for CIDs?

The biggest project which is using IPLD is certainly IPFS. A CID is used to identify the data. There's is thousands of nodes running (I should be able to get a better estimate if that's needed). Not all data is encoded as CBOR, depending on how you use it, you can choose which codec you want to use. One of them is CBOR. Though if you choose to encode data as CBOR, then Tag 42 will be used if you store a link to another object (hence a CID).

There are more projects using IPLD, I currently try to get numbers about their deployments.

[ianopolous]

We build an app, Peergos, on top of IPFS which has many users and everything we do is in cbor using the 42 tag. Users sign the merkle root of cbor trees so we can't even migrate users data for them because we don't have their keys.

Our implementation of the cbor encoding using the tag is:
https://github.com/Peergos/Peergos/blob/master/src/peergos/shared/cbor/CborObject.java#L245

[ivajloip]

@lemikev no problem on my side to wait a bit. I will check the merge that we discussed today, but I am not going to publish a new draft revision right away.

[mikeal]

Sounds like changing the tag on your side is doable. Is there anything else you need from us in order to facilitate this change?

We’re working on spec improvements on our side as well so that once the change lands we can request the tag in the IANA registry and avoid this problem surfacing again in the future.

[cabo]

I have asked to discuss this at the CBOR WG virtual interim at 1500Z today.
⁨https://mailarchive.ietf.org/arch/msg/cbor/m3sTRvBgdRGnJpxfv1a8X1uRiGM⁩

My summary of the situation is at: ⁨https://mailarchive.ietf.org/arch/msg/yot/Q0xVcC40K1mWIT4tKcqt2w7PRV0⁩

[abierman]

Now you know why I advocated for YANG Hash at the start of this work.
You have not even published an RFC.
You have not even allocated 50 SIDs.
And already there are conflicts because humans do not follow procedures.