Re: [netconf] Adoption call for draft-lindblad-netconf-transaction-id-02

[Jan Lindblad <[e-mail]>]

Andy, WG,

> On Wed, Aug 10, 2022 at 6:37 AM Kent Watsen <[e-mail] <mailto:[e-mail]>> wrote:
> NETCONF WG,
> 
> This message starts a two week poll ending on Aug 24, to decide if the document in the Subject line should be made a WG document or not. Please reply-all to this email as to whether or not you support adoption of this draft by the WG. Indications that the draft has been read are also appreciated.  From the IPR-poll, there is no known IPR associated with this draft.
> 
>         https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id <https://datatracker.ietf.org/doc/draft-lindblad-netconf-transaction-id>
> 
> 
> 
> I have some concerns about WG adoption this draft. 
> 
> There should be a clear consensus on the problem statement
> before any serious discussion of the solution in the draft.

Yes, this sounds reasonable. Section 3.1 lists the use cases we have in mind.

> I support a direct (as possible) translation of the RESTCONF mechanisms
> defined in RFC 8040 (3.4.1).  Consistent terminology and protocol mechanisms
> for NETCONF and RESTCONF are needed for developers and operators.
> No additional functionality is needed.

I think examining the use cases emerging from the field, and then designing solutions to them, like you advocated for above would be the way to go. To me, "a direct (as possible) translation of the RESTCONF mechanisms" sounds like starting with the solution (feature parity with RESTCONF), rather than looking at the problem statement.

I think the transaction-id solution in RESTCONF is reasonable for the typical RESTCONF usage patterns. In RESTCONF there is no candidate datastore, most changes tend to be rather small and localized, and anonymous YANG-Push echos might be tolerable.

In the NETCONF world, I believe the ability to communicate multiple transaction-ids for different branches in the data tree is crucial for efficient device management. The performance improvement numbers I quoted in earlier IETF quarterly meetings, at least, depend on this. But perhaps this falls within "a direct (as possible) translation"?

In any case, this is an entirely optional NETCONF extension that servers can choose to implement or not. If it's not providing value for the use cases you care about, you can safely ignore it. I believe there are many users that would benefit substantially.

> The solution should not impose any new implementation restrictions
> that are not already specified in RFC 8040 and RFC 7232.
> Only configuration datastores should be in scope (same as RESTCONF).

The use cases we have in mind (see section 3.1) are all config use cases.

Best Regards,
/jan