On 2023-02-26, at 00:02, Michael Richardson wrote:
>
> Thank you... but the YANG still went through your brain, not a tool :-)
> So, I'm still concerned that the content might be wrong in some way that
> deceives our brains.
Yep, somebody SHOULD write that tool.
(Hmm, need to find a BYGS
Carsten Bormann wrote:
> On 2023-02-25, at 23:21, Carsten Bormann wrote:
>>
>> Examples don’t validate.
> Patchup script included.
> (But errata not yet submitted.)
>
https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-01.html#name-rfc-8366
Thank
Carsten Bormann wrote:
> On 2023-02-25, at 22:52, Carsten Bormann wrote:
>>
>>> RFC8366.
>>
>> Good idea. Let’s see when I get to it…
> Examples don’t validate.
Yes, I know that the base64 isn't valid. I guess we should have made it
valid base64, even if it was
On 2023-02-25, at 23:21, Carsten Bormann wrote:
>
> Examples don’t validate.
Patchup script included.
(But errata not yet submitted.)
https://www.ietf.org/archive/id/draft-bormann-cbor-rfc-cddl-models-01.html#name-rfc-8366
Grüße, Carsten
___
Anima
On 2023-02-25, at 22:52, Carsten Bormann wrote:
>
>> RFC8366.
>
> Good idea. Let’s see when I get to it…
Examples don’t validate.
>> Base64.strict_encode64(Base64.decode64("base64encodedvalue=="))
=> "base64encodedvaluQ==“
Grüße, Carsten
___
> I think you did this manually, right?
Yes. To my best understanding of YANG and YANG-JSON.
(E.g., I needed to find out how to represent empty lists in YANG-JSON — this
was recently (2022!) still a discussion point on the mailing list, which needed
the author of RFC 7951 to resolve [1]...)
Carsten Bormann wrote:
> draft-ietf-core-sid defines a file format for the interchange of
> YANG-SID allocation information.
> This is a JSON file, a data model for which is provided in YANG (via
> RFC7951 YANG-JSON).
> The spec of course also contains an example instance of
