Skip to content

Minimal-change revision for WGLC: drop atomicity, scope out NMDA #24

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
apelov wants to merge 5 commits into
base: main
Choose a base branch
from
Open

Minimal-change revision for WGLC: drop atomicity, scope out NMDA #24

Changes from all commits
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
4f67d06
WI-1: remove atomicity/rollback requirements; add best-effort process…
apelov Jul 23, 2026
5bfe6a3
WI-2: reserve the atomicity/strict-processing extension point
apelov Jul 23, 2026
32134ce
WI-3: explicitly scope out NMDA datastore selection
apelov Jul 23, 2026
6fca3b8
WI-4: note partial-application risk in Security Considerations
apelov Jul 23, 2026
1343c07
WI-5: reflect reduced scope in abstract and introduction
apelov Jul 23, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
76 changes: 67 additions & 9 deletions draft-ietf-core-comi.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -105,7 +105,10 @@ in YANG, or SMIv2 converted to YANG. CORECONF uses the YANG to CBOR mapping and
YANG identifier strings to numeric identifiers for payload size reduction.
CORECONF extends the set of YANG based
protocols, NETCONF and RESTCONF, with the capability to manage constrained devices
and networks.
and networks. Atomic (transaction) semantics for requests carrying multiple
data items, and the selection among Network Management Datastore Architecture
(NMDA) datastores, are out of scope of this document and may be provided by
future extensions.

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sec 3.2.3.1 shows an iPATCH example where 3 data nodes are being edited at once.
iPATCH is atomic so why doesn't this count?

RESTCONF uses YANG Patch (RFC 8072) to provide an ordered sequence of edits.
It is implementation-specific how the datastores are used but it is important because of
cross references like leafref. The draft could say the order of edits within an iPATCH MUST be followed


--- middle

Expand All @@ -130,9 +133,14 @@ as YANG, promotes interoperability between devices and applications from
different manufacturers.

CORECONF and RESTCONF are intended to work in a stateless client-server fashion.
They use a single round-trip to complete a single editing transaction, where
They use a single round-trip to complete a single editing operation, where
NETCONF needs multiple round trips.

Atomic (transaction) semantics for requests that carry multiple data items, and
the selection among the datastores of the Network Management Datastore
Architecture (NMDA) {{RFC8342}}, are outside the scope of this document; these
may be addressed by future extensions.

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is confusing (see previous comment about iPATCH)

A concrete example of what NMDA support might look like can be found in RFC 8527.

To promote small messages, CORECONF uses a YANG to CBOR mapping
{{-yang-cbor}} and numeric identifiers {{-core-sid}}
to minimize CBOR payloads and URI length.
Expand Down Expand Up @@ -201,7 +209,7 @@ can be automatically converted to CBOR.
# CORECONF Architecture {#comi-architecture}

This section describes the CORECONF architecture to use CoAP for reading and
modifying the content of datastore(s) used for the management of the instrumented
modifying the content of the datastore used for the management of the instrumented

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the datastore(s) might be more accurate.
RESTCONF takes the position that the server will deal with its datastores as an implementation detail.
Similar hand-waving could apply to CORECONF. iPATCH provides all-or-none semantics.
It is up to the server how that is accomplished.

node.


Expand Down Expand Up @@ -366,9 +374,13 @@ The different Media-Type usages are summarized in the table below:

CORECONF supports a simple datastore model consisting of a single unified datastore. This datastore provides access to both configuration and operational data. Configuration updates performed on this datastore are reflected immediately or with a minimal delay as operational data.

More complex datastore models such as the Network Management Datastore
Architecture (NMDA) as defined by {{RFC8342}} are out of scope of the
present specification.
CORECONF operates on this single conceptual datastore, which represents the
server's view of its applied configuration and operational state. More complex
datastore models, such as the Network Management Datastore Architecture (NMDA)

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is an important definition
The term 'conceptual datastore' might be better than datastore(s)

as defined by {{RFC8342}}, and the selection among multiple NMDA datastores,
are out of scope of the present specification. A future extension may define
datastore selection (for example, by means of a query parameter or a URI
structure) without changing the semantics defined here.

Characteristics of the unified datastore are summarized in the table below:

Expand Down Expand Up @@ -542,6 +554,44 @@ RES: 2.05 Content
CORECONF allows datastore contents to be created, modified and deleted using
CoAP methods.

### Request Processing {#request-processing}

A request body MAY contain multiple data node instances, for example an iPATCH
request as defined in {{ipatch-operation}}. The items in a request body are
processed in the order in which they appear.

The server applies each item on a best-effort basis. Partial failure is
permitted: when the processing of an item fails, the server is not required to
revert items that were already applied. On failure, the server returns an error
response as described in {{error-handling}}; processing of the remaining items
MAY stop at the first failure.

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to contradict text in RFC 8132

   PATCH and iPATCH are both atomic.  The server MUST apply the entire
   set of changes atomically and never provide a partially modified
   representation to a concurrently executed GET request.  Given the
   constrained nature of the servers, most servers will only execute
   CoAP requests consecutively, thus preventing a concurrent partial
   overlapping of request modifications.  In other words, modifications
   MUST NOT be applied to the server state when an error occurs or when
   only a partial execution is possible on the resources present in the
   server.

It is the responsibility of the client to construct requests that do not create
an inconsistent datastore state, and to detect and repair any partial
application, for example by re-reading the affected resources.

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is not possible for the client to be responsible for transaction validation.
Rollback in NETCONF is optional to implement but widely supported because it is needed.

The server needs to return an error if any parts of the edit failed.
The client is still responsible for figuring out how to fix the unapplied config.

### Future processing extensions {#processing-extensions}

Requests as defined in this document have the best-effort, non-atomic
processing semantics specified in {{request-processing}}. Future extensions to
CORECONF MAY define stricter processing semantics, such as the atomic
(all-or-nothing) application of a multi-item request.

Any such stricter semantics MUST be explicitly signalled in the request, for
example by means of a CoAP option or a media-type (Content-Format) parameter
defined by the extension. It is the presence of this signal, rather than the
method or media type alone, that selects the stricter semantics. An extension
MUST NOT change the semantics of requests that do not carry its signal; such
requests retain the best-effort semantics defined here.

The signalling mechanism MUST be defined so that a server that does not
recognize the signal fails the request rather than silently applying
best-effort semantics. For example, an extension that uses a CoAP option is
expected to define it as a critical option (see {{Section 5.4.1 of RFC7252}}),
so that a server that does not understand the option rejects the request. This
document reserves this extension point but does not define or register any such
option or parameter.

@abierman abierman Jul 25, 2026

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean an option that says the server MUST implement iPATCH correctly?
IMO iPATCH cannot be changed to ignore MUST requirements.

### Data Ordering {#DataOrdering}

A CORECONF server MUST preserve the relative order of all user-ordered list
Expand All @@ -568,6 +618,7 @@ In summary, if the CBOR patch payload contains a data node instance that is not
in the target, this instance is added. If the target contains the specified instance,
the content of this instance is replaced with the value of the payload.
A null value indicates the removal of an existing data node instance.
When the payload contains multiple data node instances, they are processed as described in {{request-processing}}.


~~~~
Expand Down Expand Up @@ -1067,7 +1118,6 @@ Each datastore returned is further qualified using the "ds" Link-Format attribut
This attribute is set to the SID assigned to the datastore identity.
When a unified datastore is implemented, the ds attribute is set to 1029 as
specified in {{ietf-coreconf-sid}}.
For other examples of datastores, see the Network Management Datastore Architecture (NMDA) {{RFC7950}}.

~~~~ abnf
link-extension = ( "ds" "=" sid )
Expand Down Expand Up @@ -1143,8 +1193,7 @@ title="Discovery Example: Event Stream"}
# Error Handling {#error-handling}

In case a request is received which cannot be processed properly, the CORECONF server MUST return an error response. This error response MUST contain a CoAP 4.xx or 5.xx response code.
Requests that result in an error response MUST NOT have an effect on
the datastore.
A request body MAY contain multiple data node instances; such requests are processed on a best-effort, non-atomic basis as described in {{request-processing}}. Consequently, a request that results in an error response MAY already have applied some of the items it contained before the failure occurred.

Errors returned by a CORECONF server can be broken into two categories, those associated with the CoAP protocol itself and those generated during the validation of the YANG data model constraints as described in {{Section 8 of RFC7950}}.

Expand Down Expand Up @@ -1260,6 +1309,15 @@ As {{-yang-cbor}} and {{RFC4648}} are used for payload and SID
encoding, the security considerations of those documents also need to be
well-understood.

Because a request body may contain multiple data node instances that are
applied on a best-effort, non-atomic basis ({{request-processing}}), a request
that fails part-way can leave the datastore in a state that the client did not
intend. Clients SHOULD construct internally consistent requests and SHOULD
verify the state of the affected resources after an error response, for example
by re-reading them. Deployments that require atomic application of multi-item
requests need to wait for, and use, a future extension providing such semantics
(see {{processing-extensions}}).

# IANA Considerations

## Resource Type (rt=) Link Target Attribute Values Registry
Expand Down