Extended the standin usage texts by marenamat · Pull Request #10 · cabo/yang-standin

marenamat · 2024-08-19T11:11:51Z

this is my try on reworking the standin usage sections, and on defining how to specify the standin usage in standalone messages

there are lots of formally bad wordings, i wanted first to state my intent to have something for discussion before actually putting the time into proper formal specification

cabo

Quick first reaction.
Will look more closely later today.

cabo · 2024-08-19T11:19:53Z

  I-D.ietf-netmod-rfc6991-bis: legacy-bis
  RFC5952:
  RFC8943: date
+  I-D.ietf-cbor-time-tag: extended-time


That is RFC 9581 now.

fixed, thanks

cabo · 2024-08-19T11:21:05Z

+time-no-zone | string | {{-legacy-bis}} | tag 1001
+timeticks | uint32 | {{-yang-types}} | tag 1002
+timestamp | uint32 | {{-yang-types}} | tag 1001
+hours32        | int32 | {{-legacy-bis}} | tag 1002


I didn't see a need to do these, as they already are binary (integers).

you are completely right, dropped

cabo · 2024-08-19T11:23:44Z

+In this case, no conversions are involved.
+
+Producing a stand-in MUST be always triggered by schema usage. Intermediate encoders
+MUST NOT encode stand-ins when no schema is available. This avoids problems with


That is opposite to what I would have decided -- I would have accepted a binary standin for a string that doesn't have a known date/time-y schema node.

This paragraph is explicitly targeted on intermediate encoders without schema. Let's say the intermediate encoder chooses hex string over date, and encodes 15:32:46 as 43 15 32 46. But the schema (which the intermediate encoder isn't aware of) says time. This looks quite confusing for me when expecting either 68 31 35 3A 33 32 3A 34 36 or … aha, we don't have a tag for just a time not bound to a date, probably. That looks like an issue.

Anyway, what I wanted to say, is that one string may actually have many different meanings depending on context, which is what we are already experiencing in BIRD configuration language. With that, I'm advocating for "standins strictly only with schema", otherwise we're getting into a rabbit hole of reinterpreting e.g. times to hex strings, or even some weirder things with e.g. BGP large communities … which can be also 15:32:46, see draft-ietf-idr-bgp-model-17 and bgp-large-community-type … but this time encoded probably as something like 4C 00 00 00 0F 00 00 00 20 00 00 00 2E probably with an appropriate tag. And that's what the implementors of CBOR decoders are going to hate us for if we allow it.

Do you have an example for a rfc 6991 "time"?
I wasn't planning to spend time on this; tag 1001 of course can model this as the duration from a start-of-day (which is even more compact than a hex0string :-).

marenamat · 2024-08-19T15:23:30Z

rebased on current main

marenamat · 2024-08-19T16:32:46Z

… and pushed another change, now with the stand-in declaration YANG module actually valid (hopefully) and with an added proposed feature of tagmarking groupings.

The simplest usage I can think of: the server has some memory usage statistics and it is provided splitted by logical functional parts of the server. When a new logical part is added, the old client app/lib doesn't know about it but it can get at least the information that "this specific part of the data is actually memory usage statistics" and display it well to the user. Without the tagmarking, it would see just a map of weird numbers.

marenamat · 2024-08-19T22:39:44Z

… proposed feature of tagmarking groupings.

Now my mind finally came to a conclusion that this is probably not needed as soon as we adopt SIDs. This is much harder than I expected, tbh!🤦🏼‍♀️

… SIDs

cabo

A few more detail comments, but I think we need to adjust our direction at some point.
I wanted to keep this really simple, not inviting a lot of complexity.
This of course means there will be limited functionality, but I'm sure 80 % of the benefit can be had with 5 % of the complexity.

cabo · 2024-08-20T14:07:28Z

+aforementioned types of values. Values of type `time` and `time-no-zone`
+are encoded with a date of 1 January 1970.
+
+If the encoder supports tag 1001, it MUST NOT use tags 100 and 1 as stand-ins.


Why? Tags 100 and 1 are significantly more compact.

Well, I thought I had a reason when I was writing it and then it just stayed there. I'm ok with dropping this now as I don't have a reason now.

cabo · 2024-08-20T14:10:31Z

+are encoded with a date of 1 January 1970.
+
+If the encoder supports tag 1001, it MUST NOT use tags 100 and 1 as stand-ins.
+Intolerant decoders should specify which kind of tags they expect.


This assumes an encoder encodes for a specific decoder.
This work will deploy much faster if encoders can simply jump the gun and encode. So I think lots of optional functionality gets in the way of deployment massively.
(I probably also need some examples for how you want to use tag 1001 -- just encoding a timezone hint for date and time that will be dicarded anyway doesn't sound like a good reason for 1001.)

I don't see much of a use of "encoding for everybody / decoding from everybody" without some more specs. This is kinda coupled with the principle of "no standin without a schema" for me… but i can be wrong / oblivious to something.

Also the 1001 tag should be usable e.g. for sending microsecond / nanosecond abaolute time directly without recalculating to floats. Gonna produce a specific example in the evening.

cabo · 2024-08-20T14:12:03Z

-in place of date where that is applicable, or by excluding features of
-a YANG data type that cannot be represented in a stand-in-tag.
-
-ISSUE: Should this document define such restricted types, e.g.:


I still like this as a constraint on the emitting system.

cabo · 2024-08-20T14:14:03Z

+In this case, no conversions are involved.
+
+Producing a stand-in MUST be always triggered by schema usage. Intermediate encoders
+MUST NOT encode stand-ins when no schema is available. This avoids problems with


Do you have an example for a rfc 6991 "time"?
I wasn't planning to spend time on this; tag 1001 of course can model this as the duration from a start-of-day (which is even more compact than a hex0string :-).

cabo · 2024-08-20T14:15:09Z

+in place of date where that is applicable, or by excluding features of
+a YANG data type that cannot be represented in a stand-in-tag.
+
+The encoder and/or the decoder MAY also just declare their stand-in usage in


I wouldn't even mention this.

cabo · 2024-08-20T14:15:53Z

+their documentation. Using this negotiation method as the only one is generally
+not recommended.
+
+## In-message negotiation


That would be a massive change to existing protocols.
Kills deployment.

Are you referencing the in-message negotiation? (i'm confused by the github frontend probably)

cabo · 2024-08-20T14:18:31Z

 get lost in the bulk of that (and are only identified as YANG-CBOR
 stand-in Tags in the specification).

+I think we should create some registry saying "this tag may encode that types"


Well, new types are added all the time.
Running this via a registry has the problem that the people adding types generally don't know or care about standin-tags.
So someone else would need to step in.
This is on of the reasons why I thought pattern-matching would be the best way foreard.

The registry would be more like informative than actually normative… but this probably shows that there is a different solution, maybe just a table on the cbor.io website or something like that.

cabo · 2024-08-20T14:19:05Z


-ISSUE: Should the use of stand-in tags be mentioned in the various
-YANG-CBOR-based media types (as a media type parameter)?
+IANA is requested to register a media-type subparameter `standin`


This parameter does not make a lot of sense for ACCEPT.

Not exactly sure what you're here about.

cabo · 2025-03-03T22:59:16Z

Apologies for submitting -01 without merging this -- I have 62 minutes left and won't manage to do this otherwise...
It would be good to have the draft active (not expired) before Bangkok.
We can submit a -02 on March 16th.

marenamat · 2025-03-17T08:12:51Z

No problem, I have been overloaded by lots of other things lately, so thank you for submitting -01, and I'm expecting to look into this draft again during this spring.

marenamat · 2026-02-25T16:04:48Z

After studying an awful lot of RFCs and drafts, I'm suggesting to drop all the transcoding stuff from this draft, specify only the standin usage, and to draft a separate text covering not only standin vs. other CBOR but also considering JSON and XML. It's a much bigger can of worms than it looked like before.

The main reason for this suggestion is consistency, as both CBOR-YANG (RFC 9254) and JSON-YANG (RFC 7951) specify nothing about transcoding.

Gonna probably push a larger update in this direction tomorrow.

marenamat requested a review from cabo as a code owner August 19, 2024 11:11

cabo reviewed Aug 19, 2024

View reviewed changes

marenamat added a commit to marenamat/yang-standin that referenced this pull request Aug 19, 2024

Fixes to cabo's mentioned issues in PR cabo#10

33c5859

marenamat added 3 commits August 19, 2024 17:22

Use Extended date/time tags (1001,1002)

b9ae946

Rewritten stand-in usage

7c22c96

Fixes to cabo's mentioned issues in PR cabo#10

4c19bb7

marenamat force-pushed the maria-extended branch from 33c5859 to 4c19bb7 Compare August 19, 2024 15:23

Fixed the declaration YANG module, added partial validation block

a65f8eb

The tagmarks are actually not needed as this purpose may be served by…

66382d7

… SIDs

cabo reviewed Aug 20, 2024

View reviewed changes

Merge branch 'main' into maria-extended

3d8ad10

marenamat mentioned this pull request Feb 26, 2026

Dropped transcoding, added standin-file #20

Open

cabo added the obe Overtaken by events label Mar 2, 2026

Conversation

marenamat commented Aug 19, 2024

Uh oh!

cabo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

marenamat commented Aug 19, 2024

Uh oh!

marenamat commented Aug 19, 2024

Uh oh!

marenamat commented Aug 19, 2024

Uh oh!

cabo left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cabo commented Mar 3, 2025

Uh oh!

marenamat commented Mar 17, 2025

Uh oh!

marenamat commented Feb 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants