Hi Brian, Holding it for the last call comments is fine. I've just kicked off the last call request.
Regards, Rob -----Original Message----- From: Brian E Carpenter <[email protected]> Sent: 29 November 2021 20:04 To: Rob Wilton (rwilton) <[email protected]>; [email protected]; [email protected]; Toerless Eckert <[email protected]> Subject: Re: AD review of draft-ietf-anima-asa-guidelines-03 Rob, OK, thanks, I will put your suggested change in the working copy. Shall we post an update, or just hold it until we see the Last Call comments too? Regards Brian On 30-Nov-21 03:27, Rob Wilton (rwilton) wrote: > Hi Brian, > > Thanks for the reply and updated doc. > > I've put a couple of comments/answers inline but the only actionable comments > that I have relates to the NETCONF management client description, which I > have brought to the top: > >>> 6. I presume that the ASA would be treated like any other NETCONF >> management client? Perhaps this is worth stating, and that it may need to >> coordinate configuration updates with other management clients. >> >> >> Oh, it's so confusing to me that the NETCONF server (in the protocol sense) >> is >> in the managed device, which in the big picture is not really a server at >> all. >> Here's my attempt: >> >> For example, if such management is performed by NETCONF >> <xref target="RFC6241"/>, >> the ASA must interact directly with the NETCONF server in the same >> node, >> to avoid any inconsistency between configuration changes delivered >> via NETCONF and configuration changes made by the ASA. > > The key bit is that ASA should logically be like any other NETCONF management > client, .e.g., if you did "show config history" then I would expect to see > the config update by the ASA, just like any other config update, so I suggest > tweaking the text to something like: > > For example, if such management is performed by NETCONF > <xref target="RFC6241"/>, the ASA must interact with the NETCONF > server as an independent NETCONF client in the same node to avoid > any inconsistency between configuration changes delivered > via NETCONF and configuration changes made by the ASA. > > Further comments inline ... but none are actionable. > > >> -----Original Message----- >> From: Brian E Carpenter <[email protected]> >> Sent: 24 November 2021 02:56 >> To: Rob Wilton (rwilton) <[email protected]>; [email protected]; draft-ietf- >> [email protected]; Toerless Eckert <[email protected]> >> Subject: Re: AD review of draft-ietf-anima-asa-guidelines-03 >> >> Hi Rob, thanks for such a careful review. The -04 version posted a few >> seconds ago should respond to your points, but we have inserted comments >> below. >> >> On 19-Nov-21 07:27, Rob Wilton (rwilton) wrote: >>> Hi Authors, ANIMA, Toerless, >>> >>> My AD review of draft-ietf-anima-asa-guidelines-03 is inline. I have also >> attached a copy of my review because the IETF mailer likes to truncate my >> review emails, so please check that you reached my signature for the full >> review. >>> >>> Toerless, please can you also update the Shepherd writeup to indicate that >> I'm the responsible AD for this document. >>> >>> The draft is well written, and mostly I have fairly minor comments to >> improve the readability of the document in a few places. I also ran the >> document through an automatic grammar checker, and the nits raised are at >> the end of my review. >>> >>> >>> >>> 1. Would it be useful to have a terminology section for some of the >> acronyms, to make >>> it easier for readers to refer back to? This could also help indicate where >> the terms are defined? I'm happy to leave this entirely to the authors >> discretion. >> >> >> Yes, this seems useful (and should have been in RFC8993). Will add as an >> Appendix. > > Looks good. Thanks. > > >> >>> 1. Introduction >>> >>> Another example is that an existing script for locally monitoring or >>> configuring functions or services on a router could be upgraded as an >>> ASA that could communicate with peer scripts on neighboring or remote >>> routers. A high-level API will allow such upgraded scripts to take >>> full advantage of the secure ACP and the discovery, negotiation and >>> synchronization features of GRASP. Familiar tasks such as >>> configuring an Interior Gateway Protocol (IGP) on neighboring routers >>> or even exchanging IGP security keys could be performed securely in >>> this way. This document mainly addresses issues affecting quite >>> complex ASAs, but the most useful ones may in fact be rather simple >>> developments from existing scripts. >>> >>> 2. In this example, is the assumption that the scripts are running on the >> devices? It wasn't entirely clear to me. If so, perhaps reword the first >> part of >> the paragraph to make this more clear? >> >> >> Yes, done. >> >>> 2. Logical Structure of an Autonomic Service Agent >>> >>> As mentioned above, all but the simplest ASAs will need to suport >>> asynchronous operations. Not all programming environments explicitly >>> support multi-threading. In that case, an 'event loop' style of >>> implementation could be adopted, in which case each thread would be >>> implemented as an event handler called in turn by the main loop. For >>> this, the GRASP API (Section 3.3) must provide non-blocking calls and >>> possibly support callbacks. When necessary, the GRASP session >>> identifier will be used to distinguish simultaneous operations. >>> >>> >>> 3. Various languages have better concurrency paradigms than threads and >> locks (e.g., actors, futures, goroutines, etc). So, I think that you are >> using >> threads here as a way to describe what operations are expected to be >> handled in an asynchronous fashion, and to describe that using a fairly >> simple frame of reference. You cover the single threaded case, but I didn't >> know whether it would be helpful to indicate that other concurrency >> mechanisms can be used, or perhaps that would just be obvious to folks who >> are familiar with them anyway ... >> >> >> Well, I'd say "different concurrency paradigms" to avoid a value judgment, >> but yes. We did cover this at more length in the API (RFC8992) so probably >> we should point to that discussion. To avoid confusing text, I will move most >> of the text about asynchronous operations into the section about the API. >> >> (( From a quick glance at goroutines, I can only see a syntactic sugar >> difference between _tcp_listen(listen_sock).start() in Python and go >> _tcp_listen(listen_sock) in Go, for example. All these things are event loops >> under the skin, anyway. )) > > The updated text looks good. > > By better concurrency paradigms, I mean ones where it generally easier to > write correct performant concurrent code than using threads & locks (which > are hard to get good concurrency if global state is shared, but conversely > very easy to get data races or deadlocks). But this is probably a discussion > over a glass of wine or beer if we manage to meet in person again ... ;-) > > I think that the key difference between Go and Python is that the goroutines > will run concurrently (assuming a multi-core processor), whereas in Python > the global interpreter lock prevents concurrent execution - which is not as > efficient on modern multi-core CPUs. > > = >>> >>> >>> 5. Design of GRASP Objectives >>> >>> The general rules for the format of GRASP Objective options, their >>> names, and IANA registration are given in [RFC8990]. Additionally >>> that document discusses various general considerations for the design >>> of objectives, which are not repeated here. However, note that the >>> GRASP protocol, like HTTP, does not provide transactional integrity. >>> In particular, steps in a GRASP negotiation are not idempotent. The >>> design of a GRASP objective and the logic flow of the ASA should take >>> this into account. For example, if an ASA is allocating part of a >>> shared resource to other ASAs, it needs to ensure that the same part >>> of the resource is not allocated twice. The easiest way is to run >>> only one negotiation at a time. If an ASA is capable of overlapping >>> several negotiations, it must avoid interference between these >>> negotiations. >>> >>> 7. Is the alternative approach valid here, which is to design the GRASP >> Objectives such that they can be treated idempotently? I.e., where the >> receiver can detect that it is a duplicate request and ignore it. >> Generally, I >> find that to be a simple and robust way to do concurrent system design. >> >> >> True, will add. For example, Toerless has a model that amounts to DNS-SD >> lookup over GRASP. That is idempotent. But a shared resource objective can't >> be idempotent, I don't think, because if A gives some resource to B, that >> needs to be an atomic transaction. > > I agree for the case where an ASA is the owner of the block of resource and > it is reallocating part of that resource to another ASA. > > But I still suspect that this could potentially be modelled in a different > way that would mean that the messages themselves are idempotent. E.g., if > ASA persistently track what resources have been allocated to each other ASA. > > Thanks, > Rob > _______________________________________________ Anima mailing list [email protected] https://www.ietf.org/mailman/listinfo/anima
