Re: [netconf] (Reaffirming) Poll on transaction ID

Jürgen,

Thanks for investigating thoroughly. :-) I wrote an attempt to explain the question a few minutes ago, I hope that helps a bit.

The question is really about whether I/we should take the time to describe the (optional to implement) enhancement in detail. Once written, the WG can examine the benefit/cost aspects of the addition and possibly reject it.

Best Regards,
/jan

> On 15 Aug 2023, at 09:50, Jürgen Schönwälder <jschoenwaelder@constructor.university> wrote:
> 
> I did not understand the question. I then looked at the slides but may
> have overlooked where they explain the difference between "true to RFC
> 8040" and "allow for variance". Is it possible to formulate the
> question in a more crisp wayso that we all have the same
> interpretation of the question?
> 
> The term 'transaction ID" does not exist in RFC 8040, all I find there
> is text explaining how the HTTP ETag mechanism applies to RC. So what
> is the "variance to allow"?
> 
> So I went to the YT recording, the relevant part stats at 23:00.
> Kent's question after the presentation helped me to get the idea what
> the question is about. The existing ETag mechanism of RFC 8040 does
> what it does. It seems the presentation was about a _different_
> mechanism, which Kent kind of summarized as:
> 
> - The server remembers past transaction ids
> - A client sends a get-config indicating his last known transaction id
> - The server can then produce a diff that matches the clients state
> 
> To me, I see value if a combined RC+NC server exposes the RC ETag
> mechanism also to NC clients. I think this was the original goal of
> draft-ietf-netconf-transaction-id.
> 
> What was proposed during the session is a soemwhat _different_
> transaction id, which, if adopted, should in my view work for both NC
> and RC as well. But perhaps we should not mix things up and maintain
> modularity.
> 
> /js
> 
> On Mon, Aug 14, 2023 at 06:04:13PM -0700, Mahesh Jethanandani wrote:
>> Hi WG,
>> 
>> One of the polls taken in IETF 117 during the WG session was on the question of whether we wanted to allow variance in how transaction ID is implemented in RESTCONF. In other words, should the transaction ID stay true to RFC 8040. If it is still not clear what the poll was asking, please refer to the following deck, and in particular the slides on “Comparing Variants”
>> 
>> https://datatracker.ietf.org/meeting/117/materials/slides-117-netconf-transaction-id-and-trace-00.pdf <https://datatracker.ietf.org/meeting/117/materials/slides-117-netconf-transaction-id-and-trace-00.pdf>
>> 
>> We wanted to re-affirm that poll on the mailing list here. Here it goes.
>> 
>> Question - Should transaction ID draft (draft-ieft-netconf-transaction-id-0) stay true to RFC 8040, or allow for variance in what is returned when requested for a versioned node?
>> 
>> Yes says it should stay true to RFC 8040.
>> No says it should allow for variance.
>> 
>> Please vote. Thanks.
>> 
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>> 
>> 
>> 
>> 
>> 
>> 
> 
>> _______________________________________________
>> netconf mailing list
>> netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf
> 
> 
> -- 
> Jürgen Schönwälder              Constructor University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         <https://constructor.university/>
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf