There is a need to support JSON encoding for NETCONF messages
RFC 7951
Flexible Message Encoding
The protocol needs some changes to support multiple encoding formats, including CBOR.
An extensible mechanism is needed to allow for future encoding besides XML, JSON, and CBOR.
Many use-cases exist for XML, JSON, and/or CBOR encoding for specific messages:
Notifications in CBOR
Large RPC Replies in CBOR
Data RPC Replies in JSON
Preserve XML compatibility on an a per-operation basis
NETCONF needs a much-simplified version of the HTTP Content-Type and Accept headers.
Protocol Non-Changes
The NETCONF 1.1 application layer message framing and chunking MUST be preserved.
There MUST NOT be any transport-specific encoding of application-layer content
The existing transport layers (SSH and TLS) MUST support flexible message encoding
The default encoding is XML for backwards compatibility
Hello Exchange Changes
The hello message will need to updated to allow both peers to agree on "base:1.2".
If so then the new enhanced message format is used (TBD).
Message Layer Changes
Somehow the client needs to opt-in for a different message encoding than XML
some sort of Content-Type parameter for requests
some sort of Accept parameter for replies or notifications
part of the Message Layer, NOT the YANG operation layer
cannot augment YANG operation with parameters
JSON Attributes
Some NETCONF request messages and data responses use XML attributes.
The JSON support in RFC 7951) is too stateful to be usable,
It is possible there are no implementations of the JSON attributes in RFC 7951.
Perhaps a simplified (forced order) can help entice developers to implement it.
CBOR attributes
CBOR does not support attributes at all. The work is TBD.
It is still suitable for notification messages now, but this CBOR work is needed for
full XML message replacement.
Previous Work
There was a previous attempt at this feature in 2018
Flexible Encoding of NETCONF Messages
YANG/CBOR
There is a need to support YANG/CBOR encoding for NETCONF messages RFC 9254
SID Files
SID draft-23
JSON
There is a need to support JSON encoding for NETCONF messages RFC 7951
Flexible Message Encoding
The protocol needs some changes to support multiple encoding formats, including CBOR. An extensible mechanism is needed to allow for future encoding besides XML, JSON, and CBOR. Many use-cases exist for XML, JSON, and/or CBOR encoding for specific messages:
NETCONF needs a much-simplified version of the HTTP Content-Type and Accept headers.
Protocol Non-Changes
Hello Exchange Changes
The hello message will need to updated to allow both peers to agree on "base:1.2". If so then the new enhanced message format is used (TBD).
Message Layer Changes
Somehow the client needs to opt-in for a different message encoding than XML
JSON Attributes
Some NETCONF request messages and data responses use XML attributes. The JSON support in RFC 7951) is too stateful to be usable, It is possible there are no implementations of the JSON attributes in RFC 7951. Perhaps a simplified (forced order) can help entice developers to implement it.
CBOR attributes
CBOR does not support attributes at all. The work is TBD. It is still suitable for notification messages now, but this CBOR work is needed for full XML message replacement.
Previous Work
There was a previous attempt at this feature in 2018
NETCONF Binary Encoding