Re: [netmod] [core] WG Last Call on draft-ietf-core-comi-16

[Andy Bierman <[e-mail]>]

Hi,

I have some minor comments about this draft.
I did not find any major issues.  It is almost ready for publication.


Andy


# comments on draft-ietf-core-comi-16

## sec 2.3

Examples of each media type would be helpful here

## sec 2.4

It is not clear how any interoperability would be possible
if the server used some other datastore design.
Para 2 should be removed or there should be a complete
specification how NMDA datastores work in CORECONF.

## sec 3.1.3

    For compactness, indexes of the list instance identifiers
    returned by the FETCH response SHOULD be elided, only the
    SID is provided.

If this encoding is used then the FETCH response will
not conform to the application/yang-instances+cbor-seq
media-type.

It could be more clear that the client is responsible
for remembering the instance information for each
varbind in the request since no key values will be in
the response.

## FETCH design issues

The client must know all of the key values in advance
before being able to use the SID of a data node
in a FETCH request.  It is difficult and expensive
to retrieve the entire datastore contents at once,
just to discover the key values in use for the YANG list
entries within the datastore.

RESTCONF has the 'depth' and 'fields' filter parameters
to address this issue. NETCONF has subtree and XPath filtering.
NETCONF servers can generally support selection of 1 value or all
values, for each key.

Perhaps CORECONF will need the 'depth' filter parameter.

## sec 3.2.3

It is not clear if there are any server requirements
for error handling.  What happens if some (but not all)
of the edit varbinds succeed?  Is the datastore left
in a state such that YANG validation does not pass?
How Are partial edits reported to the client?

Most NETCONF and RESTCONF servers implement an all-or-none
design so that error-option='rollback-on-error' is always done.
Perhaps CORECONF needs a SHOULD apply all-or-none for iPATCH?

## sec 3.5.1

IMO there should be a SID file 'item' list shown for
the examples.  IMO it is confusing that the SID assignments
do not follow the standard algorithm.

Since the 'input' or 'output' SID is actually used in
protocol messages, the delta values for the child nodes
are not optimal unless the correct path strings are sorted.

There is a cur-and-paste error:

OLD:

     This example invokes the 'reboot' RPC (SID 61000), of the
     server instance with name equal to "myserver".

NEW:

     This example invokes the 'reboot' RPC (SID 61000).

## sec 3.5.1

    REQ:  POST </c>
          (Content-Format: application/yang-instances+cbor-seq)

    { 61000:
      {
        1 : 77
      }
    }
    RES:  2.04 Changed
          (Content-Format: application/yang-instances+cbor-seq)

    { 61000:
      null
    }

I am not sure 2.04 Changed the the correct status to match '200 OK'

The example RPC does not define any 'output' section
so the response should not have any payload at all.
RESTCONF uses the 'input' and 'output' nodes in the
payloads. CORECONF is using the RPC method node instead.


## sec 3.5.2


IMO the extra layer in the encoding for '0' is wrong.
It should match the format used for RPC.

It should be clear that if an RPC or action does not
have any input parameters (either direct or augments),
then the payload will not have any input parameters.

Is this the correct encoding (should have examples in the draft)

RPC:

    { 61000:
      null
    }

ACTION:

    { [60002, "myserver"]:
      null
    }

It should be clear that order of YANG list and leaf-list data nodes
are significant if they have the ordered-by 'user' property.
Note that this applies only to the entries within a parameter.
The RPC or action input/output child nodes do not need to
be supplied in order. The text in RFC 7950 (e.g. 7.14.4)
applies only to NETCONF.

## Appendix A and B

There should be a sentence declaring each appendix to
be normative, or move to a numbered section instead.



On Mon, Sep 4, 2023 at 1:24 PM Marco Tiloca <marco.tiloca=
[e-mail]> wrote:

> Dear all,
>
> This email starts a Working Group Last Call for the document:
>
> https://datatracker.ietf.org/doc/html/draft-ietf-core-comi-16
>
> (CoAP Management Interface (CORECONF))
>
>
> The document status can be found at:
>
> https://datatracker.ietf.org/doc/draft-ietf-core-comi/
>
>
> Please provide your comments and feedback by Friday, 2023-09-15.
>
> This WGLC is also copied to the NETMOD WG mailing list.
>
> Best,
> /Marco
>
> --
> Marco Tiloca
> Ph.D., Senior Researcher
>
> Phone: [phone]
>
> RISE Research Institutes of Sweden AB
> Box 1263
> 164 29 Kista (Sweden)
>
> Division: Digital Systems
> Department: Computer Science
> Unit: Cybersecurity
> https://www.ri.se
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core
>