NETCONF Interim Meeting 2023

restconf

AB: let's focus on what actually needs a new protocol version

PA: (sharing screen) goes through the restconf-next issue list,
suggesting to mark each issue according to whether it requires protocol
changes (label "need-next").

Closes #1

Discussion #2:

AB: Does next version include errata?
Piecemeal approach is confusing
PA: s/resource-denied/data-exists/

Discussion #3:

PA: very much needs new protocol version

Discussion #4:

AB: Appears to be a request to treat lists and leaf-lists as a
collection; today you have to specify an instance, can't access entire
list; that would require a protocol change (no longer must have keys
specified in the URI)
Soft change: no change if client does not do that

PA: Pagination, Section 2.2, adds... makes collection, part of ongoing
work

MJ: Can do that without changing protocol?
PA: You need to change by adding RFC
AB: would be violating MUST in 8040; restconf has already defined list
encoding, this would be different encoding
RW: classify this as a minor change?

Discussion #5:

AB: Two different ways to encode a list -- also need to support
streaming server, need to always start the array.
Any change that allows flexibility without value -- don't know why we'd
do that.
I.e., not supporting.

Would need new protocol version

RW: Question for Andy, could allow server to return either encoding.
AB: Not in favor. Why have client guess what is returned.
This WG is server-centric, would be good idea to stop doing that.

PA: Supply list-entry without supplying contents would be convenient?

Needs new protocol version.

Discussion #7:

Needs new protocol version.

Discussion #8:

RW: Benefits for QUIC: Separate streams for different flow control
(e.g., separate telemetry); Downside: has to be encrypted

PA: UDP-Notif would solve that
RW: With QUIC, you would get fragmentation for free

RW: Protocol change would be for making use of streams (H/2 and H/3)
Other advantage: Request in first packet; does that matter?

Discussion #9:

RW: Moving to NMDA; Restconf to target the datastores directly; can
deprecate or obsolete combined then

AB: one request to implement 8527; can't take away the combined
datastore; breaks everything; 95 % non-NMDA
(People like NMDA for operational value of config=true)

KW: Use case -- why would it be NMDA in the first place?
State models as a transition for legacy; technical debt carrying
forward, could get rid of that

Discussion #10:

JL: Not a smart approach as server tends to evolve. Even if the server
changes are backwards compatible, the client would be surprised by new
data arriving because it did not predict new branches to be excluded.
Motion to close.

Discussion #11:

Keepalive needed?

AB: Detail in RESTCONF that could use some work.
Problems configuring nginx to handle SSE correctly, don't flush
correctly, timeout
KW: Client-server draft enables config of keepalive; needed to call-home
-- server needs to test the aliveness of client
Certainly can do keepalive today
(Noone suggest TCP keepalive; can do keeplive at TLS or SSH; could do at
Restconf protocol layer)

AB: Client initiates the SSE, doesn't send anything, only server sends
SSE; need application-layer pings
Don't want transport specific solution
(Future work replacing SSE, http-notif)

PA: Going through proxies where you terminate TLS...
KW: SSE fix, introduce dummy message
PA: Leading colon is one already

Discussion #12/#13:

PA: backwards compatible
AB: netconf operations through restconf
no namespace bindings

AB: Operation resource: invoke GET operation from restconf
via POST operation

netconf

Same procedure for the netconf-next issue list

RW: is maintaining netconf/restconf split the right answer?
PA: deprecate one protocol?
AB: Access to yang-data is interesting; existing netconf harder to use;
a lot more interest in netconf with JSON/CBOR. Nobody is having problems
with RESTCONF.
Drafts are using JSON examples...

RW: Restconf mandates XML and offers JSON?
AB: We didn't force XML (KW: That's right)
Popularity of JSON cannot be understated

MJ: ?
RW: Both questions worth asking
netconf has a higher prio of fixing
feature parity maybe not needed

KW: Web Services, swagger etc. very inferior to restconf/YANG -- whole
ecosystem is horrendous...
Only thing really missing: confirmed commit
AB: We implemented
Bring both protocols up to date; use experience from 6-10 years
Level of detail way beyond vs application programmer

Discussion #2:

AB: ?
RW: What is the issue?
Why not just use copy-data?
deprecate copy-config?
KW, MJ: use case?

Discussion #3:

we want to do this!

Discussion #4:

AB: Wouldn't need a protocol version
could be we already have clarified this
(Yes, needs to revert after reboot; persist is over)
KW: yes, needs more examination; issue confirming commit after a
connectivity outage?

Discussion #6:

JL: Good idea, multiple requests for this, needs to have been negotiated

AB: netconf: XSD: OK or data or rpc-error.
cf. RPC warnings; add warning to OK
Now allowing warnings was major oversight in 6241
(can't include data in error either)

Discussion #7:

RW:
MJ: Clarification label
RW: People found this unclear, came up with different behavior
AB: copy-config intentionally will delete what is not there; must be
confusing

Discussion #8:

MJ: There is a draft.
RW: replacement for TCP (no HTTP)
RW: Little gain over TLS, unless we say how to use streams.
Each your subscriptions could be in different stream.

Discussion #9:

RW: Is there energy to clean up the specs?
MJ: could happen along yang-next work?
KW: Allow yang-next to remove netconf; define equivalent of 7951 or XML

AB: Martin has brought up that ripping out exampls from netconf makes it
harder to implement
Maybe move normative text to another RFC and reference it here.
RW: Yes!
AB: Examples stay in same RFC as operations.
RW: Yes!

Discussion #10:

PA: More cleanup,
see also #26

KW: need-next so we can whittle down hello at startup
JL: YANG 1.1 fixes that already
MJ: next version of netconf would change hello
PA: Maybe new netconf RFC should not talk about YANG modules
AB: needs to provide backwards compatibility; don't know version before
hello... Removing already taken care of in 7950 5.6.4

Discussion #11:

tag this as "encoding"

Discussion #13:

AB: should be NACM-next
KW: no tracker yet
KW: netconf published NACM
MJ: keep it here until we have nacm-next

Discussion #14:

PA: close as work is ongoing

Discussion #15:

OK, need-next

Discussion #16:

ditto
JL: less interested; moving to lock-less world
KW: It is already optional to use
Is this about optional to implement?
(Yes)

Discussion #17:

MJ: second one ongoing
close

Discussion #18:

similar

Discussion #19:

KW: If implementations are commonly combining and not replacing, we
should document that
KW: clarifying, maybe errata report? separate for leaf-list and bits
AB: It certainly doesn't mix bits, which is just one leaf.
leaf-lust: It only affects the leafs that are there; can't replace leafs
as the value is the key; want to replace whole leaf-lists
MJ: how about ... mark update ...

Wrapup

MJ: Need one more meeting to finish this list
Interest level and who wants to take on the work

January interim (also netmod, ivy)

AB: everyone to update issues on github, please!
Want activity on encodings
Flexible mesages like in HTTP
KW: HTTP = Accept parameter/media type
Focus on restconf going forward

AB: Accept: too complicated, cf. CoAP Content-Type
"I want JSON or CBOR back"
With YANG-Push you just specify the encoding; not there for large RPC
replies
The same kind of flexibility we already have in restconf would be good
for netconf

KW: sorry for being late; mail didn't go through...