Re: [core] draft-ietf-core-comi-11 shepherd review

[Carsten Bormann <[e-mail]>]

On 2021-02-28, at 23:09, Ivaylo Petrov <[e-mail]> wrote:
> 
>> *** 5: This whole section is rather disappointing.  What does this
>>    really do except for pointing at RFC 7959?  Is there any
>>    recommendation in how to work around the race condition?  The
>>    recommendation to use indefinite length is not solving any problem
>>    (does not work except in very fortuitous cases).
> 
> [IP]: I understand your disappointment. It appears to me that we
> should try to state more clearly the issue that is being discussed and
> for me there are two separate ones that are mixed. The first one is
> insufficient resources to send the response. It might be insufficient
> bandwidth of the network (maybe can be solved with SCHC as well) or
> insufficient memory on the server. If it is the latter, I am really
> not certain if that is something we should be solving.
> 
> The second issue is obtaining a snapshot of a consistent snapshot of
> the state. For me we can call this out as a possible issue, but indeed
> recommending indefinite length arrays solves such a small part of the
> issue, that probably it is better not mentioning it at all.

I think my point was that this is a set of problems that all applications that use block-wise transfer have.  RFC 7959 has some brief guidance in its section 7.1, but I agree that a more extensive treatment should be written up.
Just not here…

I believe there should not be a section 5, and the one sentence or so that points out the issue can maybe merged with the item down below.

>> *** 6.2.2 How does the pagination work, then?
>>    This SHOULD is not actionable.
> 
> [IP]: If I understand correctly your objection is that we are not
> prescribing anything concrete, therefore the SHOULD is not helping in
> reality. If that is the case, do you still agree that this is a
> problem worth solving? If so, should we specify in more details a
> mechanism (or refer to one that is already well described elsewhere),
> or can you think of better options.

Resource-directory actually went ahead and put in a basic form of pagination.

But, again, this is a general YANG problem, and we should defer to that being solved for YANG, e.g., as in
https://tools.ietf.org/html/draft-wwlh-netconf-list-pagination-nc-01 (*)
Putting in a SHOULD for something that isn’t defined yet is not the right approach here, but we could very well mention that future additions to YANG/*CONF for pagination could be used to mitigate the problem.

Grüße, Carsten

(*) Does anyone know what happened to this draft?