[core] [core]: I-D.core-comi or CORECONF Comments

[Vojtech Vilimek <[e-mail]>]

Hi all,

my comments to the CORECONF document [1] follows.

Identification of nodes:
Both of the MIME types used by the current version of the document uses 
the 'instance-identifier' YANG datatype. The only think the datatype 
miss is ability to identify whole list or leaf-list not just one 
particular instance. This _can_ be worked around be putting the selected 
list into a container but this work around for example does not work on 
most of the current IETF YANG models. Therefore I define a new type 
'node-identifier', which is allowed to have the last list/leaf-list 
identifier with unspecified key/index. This 'node-identifier' would used 
in places that use 'instance-identifier' now.
(Related sections: 2.3 Media types, ...)

YANG-CBOR:
The YANG-CBOR has some missing pieces. As I already pointed out in my 
draft to fix this [2]. I think we should consider this a blocking issue 
and find a consensus of the ideal solution. I think the extension of the 
RFC9254 (YANG-CBOR) [3] should be references along side the the RFC9254 
references or at least on point of introduction of the RFC9254.

CORECONF vs RESTCONF:
I think that everything accessible by 'node-identifier' (or 
'instance-identifier') can be places as target for CoAP FETCH and iPATCH 
requests/responses. However this will bring more differences between 
CORECONF and RESTCONF that must be dealt with by the protocol proxies.

YANG standins:
I think that the document should require the implementation to have 
reasonable subset or full conformance to the YANG standin [4]. In the 
introduction, the document says that most of the decisions are taken to 
save bytes of the messages. Also the document requires the usage of SIDs 
so the inclusion of YANG standins feels pretty much natural. I also 
think that the YANG standins should be part of the YANG-CBOR 
serialization model from the beginning.

Atomicity of message processing:
In the past wrote some code for SNMP, which mandates that all messages 
must be process atomically. Is this requirement also put on the 
CORECONF? I feel like in the microcontroller/constrained world, it is 
not that expensive. But for more of a HPC kind of software, it may be 
really expensive to process larger request in atomic way.

Unified datastore semantics etc.:
I don't fully understand the expected semantics of the Unified 
datastore. Is it expected that the server holds basically two views of 
the datastore model, the config instance data tree and the runtime state 
instance data tree? Because I need to implemented FETCH on both runtime 
and config instances. While FETCHing an node with both config=true and 
config=false instances and query parameter 'c=a' content all descendant 
nodes, should the config=false take precedence? Is it possible to have 
two instances with config=false and config=true at the same time in the 
Unified datastore?
The iPATCH cannot have a content query parameter, so it only work on the 
config=true data tree? (Based on the fact that YANG has config=true 
read-write and config=false read-only).

Let's say a have a counter of some events instantiated in config=false 
mode only. It it than impossible to zero the counter simply be write 0 
to it?

CORECONF over TCP, CORECONF over WS, CORECONF over Unix domain sockets:
Should the document speak about the alternative transport-layer protocols?

Discovery:
It is good to have the '/.well-known/core' to have text-based format. 
But I worry that the Link format is much bigger than the transmitted data.
I also think that the constrained YANG library should use CBOR over JSON 
with one URI the the JSON version.


Best regards,

Vojtech Vilimek
CZ.NIC z.s.p.o
Czech Republic

[1]: https://www.ietf.org/archive/id/draft-ietf-core-comi-20.html
[2]: https://github.com/vvilimek/draft-vilimek-yang-cbor-inst-id
[3]: https://www.rfc-editor.org/rfc/rfc9254
[4]: https://github.com/cabo/yang-standin