[core] CoRECONF Topic Interim: CORECONF (Re: CoRE WG Virtual Interim 2023-03-15)

[Carsten Bormann <[e-mail]>]

Since we have a number of issues in the area of CORECONF and other YANG-related efforts, we decoded to focus today’s interim on a single wider topic:
bringing the YANG and CoRE ecosystems closer together.

[3] has a some detailed agenda (which I will fill some more in after sending this email).
This is definitely open for BYOI (bring your own issue).

Slightly reordering the list in the agenda, I’d like us to cover the following ground:

> SID allocation:
>   <draft-ietf-core-sid-20.txt>
>   <draft-toutain-lpwan-sid-allocation-02.txt>

CoRE-SID is in IESG processing, with a parallel working group last call verifying the technical changes we made in IESG processing (WGLC closes tomorrow).
Please get your comments in!

One issue is that there doesn’t seem to be a tool we can use for validating our examples and the SID file against the YANG model for SID files.
A number of necessary fixes have been identified and implemented.
One fix is outstanding:

* SID completeness

It does not seem the PYANG tool we are using to generate the SID file generates a complete set of SIDs (thank you for pointing this out, Jernej [4]).
So do we agree what a complete set would be?
How do we get PYANG to emit this complete set, or do we add the missing parts manually?
(Of course, new SIDs can always be added, so missing one is not catastrophic.)

The LPWAN draft cited above proposes the specific allocations for certain LPWAN protocols. How do we check a document like this?  Is it complete?

See also Appendix A of draft-bormann-cbor-cddl-csv-02 [5] for an efficient way to discuss SID allocations.

> Access to YANG information bases via CoAP:
>   <draft-ietf-core-comi-12.txt>

This is the mapping of CORECONF onto CoAP, like RFC 8040 provides the details of using HTTP for RESTCONF.

This already went through a Working Group Last-call, but then underwent some simplifications after discussing -11 at the IETF 115 hackathon.

I am pretty certain that these simplifications are the way to go, but I would like to hear concerns.

* simplify/optimize URI representation of instance identifiers?

Also, there is a proposal for going one step further in aligning e.g. the FETCH payload and the GET URI, and I’d like to have some feedback:

For an instance identifier like [1533, "eth0”] (RFC 9254 notation), COMI-12 uses the URI:

/c/X9?ZGV0aDA

Where X9 is the base64-encoded SID 1533, and ZGV0aDA is base64-encoded ["eth0”] (as a CBOR sequence).

This meshes well with using a GET for /c/X9 for the entirety of SID 1533, but a FETCH for the above would simply have the binary encoding of the CBOR data item [1533, "eth0”] in the payload.  Should we do that (as a base64-encoded CBOR sequence) in the URI as well?

/c/GQX9ZGV0aDA

(In this particular case, the X9 and ZGV0aDA components stand out, but that relationship will only be as obvious for SIDs between 256 and 65535.)

We might also go in the inverse direction, and add a special case for an instance identifier with a single string key, such as

/c/X9?k=eth0

This looks good in hand-crafted examples, but I’m not sure it’s worth the additional code.

> A YANG Library tailored to constrained environments:
>   <draft-ietf-core-yang-library-03.txt>

* yang-library next steps

This draft essentially encodes a simplified form of the regular YANG library, optimized for constrained devices.
Has the YANG environment changed in any way that requires us to make fundamental changes?
Any small updates needed?

> YANG models relevant or close to CoAP/CoRE:
>   <draft-marin-yang-edhoc-oscore-00.txt>
>   <draft-toutain-lpwan-access-control-01.txt>
>   <draft-tiloca-lpwan-8824-update-00.txt> (Well, no YANG model yet, but see [6].)


Of course, here we “eat our own dog food”.
Not all these YANG models are used in constrained environments all the time, but they will need to work well in constrained environments as well.

Anything we can learn from these YANG models that we could make use of for making CORECONF better?

Any best practices we could extract to tell model developers?

> Binary YANG Push
>   <draft-ietf-netconf-udp-notif-09.txt>
>   <draft-ahuang-netconf-notif-yang-01.txt>


I try not to meddle with other WGs’ pet projects, but draft-ietf-netconf-udp-notif looks seriously weird.  (A text-based encapsulation for a sequence of binary payloads?  A free get-out-of-jail card for congestion control?  I could go on and on…)
Any elucidation on how something like this could even happen and then reach a -09 as a Working Group document would be interesting.

The yang model in draft-ahuang-netconf-notif-yang also is interesting.

                .oOo.

* anything else?

As I said, please bring your own issues (bonus if you can announce them here beforehand).
At the end of the meeting, I would like to have more clarity at least on the CoRE-SID completeness/tool issue, and on the remaining open issue on comi (URI encoding of instance identifiers).  Any elucidation on the other issues would be a big bonus!

See you in 2½ hours...

Grüße, Carsten



[1]: https://datatracker.ietf.org/meeting/interim-2023-core-05/session/core

[2]: https://meetings.conf.meetecho.com/interim/?short=2bb7b8fc-7fd0-4371-b700-db7aac9b5ec3

[3]: https://notes.ietf.org/notes-ietf-interim-2023-core-05-core

[4]: https://mailarchive.ietf.org/arch/msg/core/df5WITICBA6tbqS-gNKmc2xwq7A

[5]: https://www.ietf.org/archive/id/draft-bormann-cbor-cddl-csv-02.html#name-example-ietf-systemsid-repr

[6]: https://gitlab.com/crimson84/draft-tiloca-lpwan-8824-update/-/blob/main/[e-mail]