PleaseAck.md document

[alexsdsr]

This PR is an attempt to make a start point of discussion how to implement the please_ack decorator support in ACA-Py. The PR contains initial version of the document that aims to find the final solution. It contains some thoughts/ideas about possible implementations.

[alexsdsr]

created a PoC (#2546) for the option 2 described in the document provided by this PR.

[swcurran]

Outstanding document and assessment. Great work! Sorry it has taken so long for feedback.

I agree with your assessment on the options, and that 2 and 3 are preferred, with the choice hinging on the question: do we need to support the please_ack in all messages?

Let’s discuss this at the ACA-Pug to seek other opinions, but my view would be that we go with Option 2 (since it appears to be the easiest) and that we limit the implementation to the relevant protocols in AIP 2.0. In my reading that would include, at most:

• 0023 DID Exchange
• 0048 Trust Ping — although since it is just a request response, there should be no need for it. Do we care about that?
• 0183 Revocation Notification
• 0434 Out of Band — would not apply to the actual out of band messages, but perhaps to the “reuse” message?
• 0453 Issue Credential v2
• 0454 Present Proof v2
• 0557 Discover Features v2
• 0095 Basic Message

Assuming the ACK requested is different from any other Ack in the protocol, we may want to ignore the duplication of sending ACKs.

A relevant question for me is whether a controller is able to decide on a message by message basis whether or not to respond to Please Ack requests. There could be configuration settings “Always”, “Never”, but should we allow a setting “Maybe” where the controller is given the option on each call? I lean towards no, but...

[alexsdsr]

Outstanding document and assessment. Great work! Sorry it has taken so long for feedback.

I agree with your assessment on the options, and that 2 and 3 are preferred, with the choice hinging on the question: do we need to support the please_ack in all messages?

Let’s discuss this at the ACA-Pug to seek other opinions, but my view would be that we go with Option 2 (since it appears to be the easiest) and that we limit the implementation to the relevant protocols in AIP 2.0. In my reading that would include, at most:

• 0023 DID Exchange
• 0048 Trust Ping — although since it is just a request response, there should be no need for it. Do we care about that?
• 0183 Revocation Notification
• 0434 Out of Band — would not apply to the actual out of band messages, but perhaps to the “reuse” message?
• 0453 Issue Credential v2
• 0454 Present Proof v2
• 0557 Discover Features v2
• 0095 Basic Message

Assuming the ACK requested is different from any other Ack in the protocol, we may want to ignore the duplication of sending ACKs.

A relevant question for me is whether a controller is able to decide on a message by message basis whether or not to respond to Please Ack requests. There could be configuration settings “Always”, “Never”, but should we allow a setting “Maybe” where the controller is given the option on each call? I lean towards no, but...

Hello @swcurran. Thank you for the review.

Answering your questions I think options "Never"/"Maybe" may be a problem if we speak about please_ack('OUTCOME'). Why do I think so? Some protocols (at least, issue-credential-v2) relies on the ack message to transit to the done state.

The documentation says

the Issuer will move to the credential-issued or done state, depending on whether or not the ~please-ack decorator is included in the message

It means that an Issuer will not reach the done state if it sends please_ack(OUTCOME) but a holder doesn't answer it with an ack message.
In my opinion we should not let a controller to 'break' the protocol.

[swcurran]

Good find @alexsdsr — thanks. Agreed! And it is much easier!

[swcurran]

After reviewing the 0317 Please Ack RFC and your excellent investigation into the protocol and the state of ACA-Py, here are my comments and suggestions:

1. I think we should not in any way alter the states, messages sent, or processing of a protocol just because there is a ~please_ack decorator on it. The processing of a ~please_ack is independent of the rest of the processing -- an extra message sent when requested.
2. Regards the on RECEIPT usage. Based on this line in the RFC It implicitly means the agent was able to unpack the message, it would be ideal (if possible...) to detect and process the decorator at that moment, sending an ack message, independent of the protocol being used. It would have to go back to the respondent, using the same thread, as an Explicit ACK using RFC 0015 ACKs. Is that possible in ACA-Py?
   1. Failing that, it would go into the per protocol handling (Option 2) with no impact on the handling of the message other than to send an extra message immediately using the Explicit ACK mentioned above.
   2. The message would be from an RFC 0015 ACK Message (using the Ack protocol family), and not a message in the protocol family of the decorated message. That distinguishes the requested ACK message from the
3. For the on OUTCOME, I suggest the handling be:
   1. When a message is received with that flag, set a field (e.g., ack_on_outcome) to true and continue processing.
   2. When the state transition to a positive terminal state is made (the protocol is DONE) and the ack_on_outcome (or whatever) is true, send an extra Explicit Ack, regardless of whether the protocol already sends an ACK or not. In other words, if asked for, send an extra message, regardless of the messaging done in the protocol.
      1. Presumably, each protocol has 1 or a small set of positive terminal states to check on, and the state transition is explicit.
      2. If the transition is done to a negative terminal state, an ACK should not be sent. It's up to the protocol to decide what to do.
4. As we update protocols in ACA-Py to support PleaseAck functionality, add a "standardized" ADMIN API option to enable the sending of the ~please_ack decorator. We'll have to look at the protocol to decide if that needs to be an individual query parameter set to (perhaps) RECEIPT|OUTCOME|BOTH, or is just added to the POST JSON.
5. We add integration tests for the use of the parameters -- setting them and processing them as we add them to protocols.

What do you think? Does that make sense to you, given the investigation you have done?

[alexsdsr]

After reviewing the 0317 Please Ack RFC and your excellent investigation into the protocol and the state of ACA-Py, here are my comments and suggestions:

1. I think we should not in any way alter the states, messages sent, or processing of a protocol just because there is a ~please_ack decorator on it. The processing of a ~please_ack is independent of the rest of the processing -- an extra message sent when requested.

2. Regards the on RECEIPT usage. Based on this line in the RFC It implicitly means the agent was able to unpack the message, it would be ideal (if possible...) to detect and process the decorator at that moment, sending an ack message, independent of the protocol being used. It would have to go back to the respondent, using the same thread, as an Explicit ACK using RFC 0015 ACKs. Is that possible in ACA-Py?

   1. Failing that, it would go into the per protocol handling (Option 2) with no impact on the handling of the message other than to send an extra message immediately using the Explicit ACK mentioned above.
   2. The message would be from an RFC 0015 ACK Message (using the Ack protocol family), and not a message in the protocol family of the decorated message. That distinguishes the requested ACK message from the

3. For the on OUTCOME, I suggest the handling be:

   1. When a message is received with that flag, set a field (e.g., ack_on_outcome) to true and continue processing.

   2. When the state transition to a positive terminal state is made (the protocol is DONE) and the ack_on_outcome (or whatever) is true, send an extra Explicit Ack, regardless of whether the protocol already sends an ACK or not. In other words, if asked for, send an extra message, regardless of the messaging done in the protocol.

      1. Presumably, each protocol has 1 or a small set of positive terminal states to check on, and the state transition is explicit.
      2. If the transition is done to a negative terminal state, an ACK should not be sent. It's up to the protocol to decide what to do.

4. As we update protocols in ACA-Py to support PleaseAck functionality, add a "standardized" ADMIN API option to enable the sending of the ~please_ack decorator. We'll have to look at the protocol to decide if that needs to be an individual query parameter set to (perhaps) RECEIPT|OUTCOME|BOTH, or is just added to the POST JSON.

5. We add integration tests for the use of the parameters -- setting them and processing them as we add them to protocols.

What do you think? Does that make sense to you, given the investigation you have done?

Hello @swcurran. Thanks for your comments.

1. I agree with you. It is better (and, in fact, seems to be easier to implement) to avoid any impact on protocol state while the please_ack decorator processing. It should be possible for the RECEIPT option, but, probably, not for OUTCOME (see my comment about it below).

2. Yes, I have the same idea. I have checked the code again and found that it should be possible to create some code, called before the message-specific handler, that will be responsible for detection and processing the RECEIPT option (independent on any other protocol-specific code).

I think we should answer to the question "should we handle the ack message that is received in response to the please_ack decorated message?" So far we have only discussed about please_ack-decorated messages, but not about ACKs (explicit responses). According to the ACA-py code such ACKs will be just mentioned in the logs but nothing else. In your opinion, should they be processed in some specific way?

3. I found your idea quite interesting. But, at the same time, I see that some things can be interpreted in a different way. For example:

i. Your idea is to consider the OUTCOME option (no matter which exactly message is docarated with it) as an option applied for a protocol itself, not for the message. I have checked the please_ack RFC and it seems like the please_ack is only "bound" to the message (not to the protocol) and should affect only the way how we process this message only. Theoretically, some agent can decorate several messages while communication by the protocol. And, probably, they should be considered as different requests for sending ACKs (after processing each of such decorated messages).
Of course, since the way how we process an OUTCOME option is a part of each protocol we can implement it differently in each protocol. But in my opinion, it seems it would be correct just to ignore an OUTCOME option if it decorates a message where there is no any real outcome expected. Actually, is is even easier because there is no need to update each message handler code in protocols.
Moreover, I see that protocol RFCs define explicitly where the please_ack (OUTCOME) is expected. That means if we receive an OUTCOME option on the cred-offer message, for example, and send explicit ACK after the cred-issue message is received (but not decorated with OUTCOME) it may be considered not correct according to the protocol.
In fact, it is a question how to interpret please_ack (OUTCOME). Reading the please_ack RFC I would say we should consider each please_ack decorator to be "bound" to the decorated message, not the protocol. What do you think?

ii. As I have mentioned previously, I see that protocols declare where the OUTCOME decorator is expected. And RFCs tell how to befave depending on wheter OUTCOME is received or not. Example from issue-credential-v2:

the Issuer will move to the credential-issued or done state, depending on whether or not the ~please-ack decorator is included in the message

Unfortunately, nothing directly said about the Holder's behavior, but it seems like it is implied that Holder sends either one ACK (if the please_ack is set) or nothing (if the please_ack is not set). In my opinion we should follow protocol RFCs while processing the OUTCOME and not to try send extra messages or something like that. If there is nothing said about please_ack (OUTCOME) then just ignore it. Does it make sense in your opinion?

[swcurran]

Good points. Here are my thoughts after reviewing:

1. Good to hear we should be able to handle “RECEIPT” independent of the protocols. That is cleaner.

2. I reviewed the ~please_ack RFC and it is definitely not clear on the question of whether the ACK is bound to the message or the protocol. RECEIPT is clearly message, but it is not the challenge. Unhelpfully, the examples in the RFC are both ones where the ~please_ack is on the last message of the protocol 😞 .

If we go with the OUTCOME being the protocol, the implementation is MUCH easier, I think. We note in the message receipt processing that we need an outcome ACK, decorate the “terminal” state change with a check to see if an extra ACK is needed, and if so send it. If we have to track each message, I think it is much more complicated.

I think there is also a good argument that a protocol based OUTCOME ACK is most important, as once the “outcome” of a message is known, a message is sent to convey that to the other side(s). However, some protocols (such as "Present Proof v2.0” does not send a finishing ACK from the verifier to the holder and so is a great candidate for this decorator.

We can talk it to the Aries community, but I would say that we should go with protocol OUTCOME only.

3. In thinking about the “no state impacts”, I realize that is not possible when one participant adds a “~please_ack” to the last message of the protocol. Back to Present Proof v2.0 — if the holder adds a ~please_ack to the presentation, the “DONE” state is not reached until the ACK is received. As such, in those cases, we need to introduce an artificial new state such as awaiting_please_ack before the terminal state. This is not a concern on the ACK sending side — just the receiver.

4. One more fun issue — I don’t know the code well enough to know if this is an issue or the best way to handle it. What happens if the ACK message on OUTCOME is in the ACK message family, and not an adopted message into the in-flight protocol? Should we require that all sent ACKs triggered by ~please_ack be in the ack message family, or in the message family of the decorated protocol?

Let’s see if we can get to a brief summary of the answers and then talk to the broader Aries community.

[alexsdsr]

Hello @swcurran. There are some answers and questions below.

If we have to track each message, I think it is much more complicated

Since the please_ack RFC is not 100% clear about OUTCOME I see 3 options:

1. To check each message (all message types in the cred-issue-v2) whether it contains OUTCOME option or not. If yes, set some flag (ack_required, for example) and then in the final step of the protocol send an ACK if the flag is set. It's an approach proposed by you.

   Comments:

   • we, probably, should have the same logic of OUTCOME processing in all Aries agents to have compatibility between them. It may make sense to discuss it with community before implementation of this approach
   • anyway we have to add some additional code (to set the flag) in each message handler (in the protocol)

2. To have additional code for OUTCOME processing only in message handlers where it is explicitly mentioned in protocol RFCs (V20CredIssue message in issue-credential-v2 protocol, V20Pres message in present-proof-v2 protocol). If any other message is OUTCOME-decorated (where it is not mentioned in a protocol RFC), please_ack will be just ignored. It is my initial idea that is implemented in my PoC.

   Comments:

   • we can consider this approach correct only in case OUTCOME is message-bound option (not protocol-bound as discussed above)

3. Check each message (all message types in the cred-issue-v2) whether it contains OUTCOME option or not. But, unlike option 1, just log that fact that OUTCOME is attached to the message. And if it is the message type, where OUTCOME is explicitly mentioned in the RFC, process it as defined in the RFC.

   Comments:

   • unlike option 1 we don't implement any logic that is not well-defined (in please_ack RFC) and can be implemented in different way in other Aries agents, but have some code (kind of a stub) that can be extended with required behavior (setting the ack_required flag or any other code) after Aries community has decided what is the best approach.
   • Implementing this approach we just postpone decision how to process OUTCOME where it is not defined by protocol RFCs. Once it is discussed and decided that OUTCOME option is protocol-bound we can update the code and replace logging with setting the ack_required flag, for example. If it is decided that OUTCOME option is message-bound we can implement some message-specific code for that.
   • In fact, this option is almost the same as option 2 and only includes additional code in each message type handler to check if OUTCOME is attached (and to put message in logs if yes).

That means may be we should choose between option 1 (if we are sure that protocol-bound OUTCOME is exactly what the please_ack RFC implies or Aries community decides so) and option 2/option 3 (they are almost the same) in case if we want to implement initial version of OUTCOME support in such a way that, at least, behave correctly according to the protocol RFC, and can be extended for all other message types when it is clear how to process them correctly (when it is clear wheter OUTCOME is message-bound or protocol-bound, etc).
What do you think?

In thinking about the “no state impacts”, I realize that is not possible when one participant adds a “~please_ack” to the last message of the protocol.

Yes, "no state impact" is only possible for the RECEIPT. OUTCOME option affects sequence of protocol states. A side who sends OUTCOME must wait for an ACK message before transition to the DONE state. It is defined in protocol RFCs (at least, for credential-issue-v2 and present-proof-v2)

Back to Present Proof v2.0 — if the holder adds a ~please_ack to the presentation, the “DONE” state is not reached until the ACK is received. As such, in those cases, we need to introduce an artificial new state such as awaiting_please_ack before the terminal state.

I see that, at least, credential-issue-v2 and present-proof-v2 protocols have such states (STATE_ISSUED and STATE_PRESENTATION_SENT accordingly). In this states the protocols wait for an ACK message. I think we don't need to introduce any new states.

Should we require that all sent ACKs triggered by ~please_ack be in the ack message family, or in the message family of the decorated protocol?

ACA-py finds a handler for message using special Handler property of each incoming message.
That means we should require all ACK messages to be adopted by a particular protocol. Especially, if we are speaking about ACK that are sent in response to OUTCOME option since some protocols (for example, present-proof-v2) define some additional fields in an adopted ACK message type.
If we are speaking only about ACKs sent in response to RECEIPT we need to decide either to adopt ACK in each protocol or to make the logic of the Dispatcher class more complicated to let it handle the original ACK message (not adopted) using ~thread, for example. There are advantages of each approach.

Disadvantages of ACK message adoptation:

• it has to be done for each protocol. It is not difficult, but lot of new similar classes would be added
• some protocols (for example, credential-issue-v2 and present-proof-v2) have already adopted ACK for their purposes. It requires some additional logic to be implemented to distinguish in which protocol state an adopted message is sent and how it should be processed (it is easy now since an ACK is received in only some particular state before DONE)

Disadvantages of using original ACK messages:

• we have to implement additional logic to find a handler using only ~thread decorator

Actually, we need to use adopted messages in case of OUTCOME option is being processed. But maybe we can use original ACK for case when RECEIPT is received.
But it is kind of inconsistent solution to send different ACK types in response to different options of please_ack. I'm not sure if it is ok or not.

One more thing I would like to discuss is compatibility issue. I have mentioned it here.

What is the problem? Let's assume an issuer agent is based on current version of code but a holder agent is based on new version of code (where please_ack is supported).

Then the issuer sends credentials and waits for an ACK (it is always sent in current version of ACA-py). But the holder doesn't send the ACK message because the OUTCOME is not attached by the issuer. The issuer can't reach the DONE state.

I see three possible options:

1. Quick and temporary solution. The idea is to send an ACK message always no matter if the issuer supports please_ack or not (since the holder agent doesn't know it) just to have backward compatibility with all ACA-py agents.

Disadvantages:

• the issuer may log error in case it supports the please_ack and doesn't attach it to the V20CredIssue message (therefore doesn't wait for the ACK message)

2. Quick and not good solution. The idea is to have some config value that will specify if ACA-py agent behaves in backward-compatible way (as mentioned in option 1) or not (ignore that fact that some agents may not support please_ack yet).

3. Good and not quick solution. The idea is to use discover-features protocol to check if the other side supports the please_ack or not and behave taking it into account.

Disadvantages:

• it requires additional effort to implement a good solution based on it.
  First, currently discovery protocol is not performed automatically (after connection is established between agents) in order to ask the other side what features it supports.
  Second, there is no any specific code to associate set of supported features with the particular agent/connection (to use it to check if the agent has to communicate in backward-compatible way or not).
  In the end, the discover-features-v2 protocol doesn't allow to ask about decorator support in context a particular protocol (it would be fine to ask if the please_ack is supported by the credential-issue-v2 protocol, for example).

I think option 1 (to send an ACK always to keep compatibility) may be a good choice for the first version of OUTCOME support. But ideally we need to implement solution based on discover-features-v2 protocol. What do you think?

[alexsdsr]

Hello @swcurran

We can talk it to the Aries community, but I would say that we should go with protocol OUTCOME only.

Have you had a chance to discuss it with the Aries community? Any thoughts?

[swcurran]

Very sorry for the long delay in responding — lots of things are going on. 🧑‍🏭

I re-read the whole RFC (paying more attention this time…) and I’ve reversed my stance. It is pretty clear that the RFC says that the outcome is message-based, not protocol-based. To quote — The OUTCOME acknowledgement is the more advanced ack mechanism and requests that an ack is sent on outcome of the message. Doh — I don’t know how I missed that on first re-read. Sorry about that.

So, to fully support ~please_ack, we would need to add as generic a way as possible to flag that a “please_ack” is needed at whatever is defined to be the next “outcome” — presumably the next state change. At the point of the state change, we check if a please_ack message is needed and send it. Seems like it would be tricky, but you would know better.

I like your option 2 idea for now, but I would also be happy if we just implement the “On Receipt” part of the protocol.

This is a bit of a rabbit hole, but as I’ve been thinking about this, I do see a possible issue with the intent of adding a ~please_ack on the presentation message for the Present Proof use case. Does the protocol end when the presentation is verified cryptographically, or after the controller decides if it will accept the presentation for the business process? What is wanted is that the acceptance of the presentation for the business purpose is ACKed, but I’m not sure that is possible in our current Aries implementations.

This is a pretty complicated protocol...

[alexsdsr]

Hello @swcurran. Thank you for the answer.

flag that a “please_ack” is needed at whatever is defined to be the next “outcome” — presumably the next state change. At the point of the state change, we check if a please_ack message is needed and send it.

Yes, it is how I have implemented my PoC code (option 2 in my message above).

I like your option 2 idea for now, but I would also be happy if we just implement the “On Receipt” part of the protocol.

Unfortunately, we have some unclear things related to the "common handler" (generic code to process the RECEIPT-decorated messages) that block us. I have mentioned them here.
The most important question is "should we adopt ACK message in each protocol?" It is, unfortunately, not defined by the please-ack RFC.
The answer to this questions affects the implementation and, more important, compatibility between different Aries agents. It seems like it should be discussed by the Aries community and added to the please-ack RFC.

Does the protocol end when the presentation is verified cryptographically, or after the controller decides if it will accept the presentation for the business process?

Currently ACA-Py sends the ACK message after the presentation is verified. It happens automatically if the auto_verify is set to true or by controller via AdminAPI otherwise.
But anyway, I think it is a question out of the scope of please_ack (OUTCOME) implementation because the protocol already has this ACK message and all that assumed to change is to let the holder request the ACK from the verifier explicitly. I think it's a good idea not to change the place where the ACK is sent from. It should be, probably, considered as a different task. Does it make sense?

How can we continue this task?

My idea is to start from something minimal that doesn't break backward compatibility between current and new versions of ACA-Py. And then to continue little-by-little.
As a first step we can transform my PoC into final version of the code.
It should include:

• support only for OUTCOME option (not for RECEIPT, I've mentioned why it is not so easy for now) and only for the 0453-issue-credential-v2 protocol
• additional flag ack_required in the AdminAPI that let the controller decide if the OUTCOME is sent or not
• unconditional the ACK message sending from the holder to the issuer (in order not to break backward compatibility, I have mentioned it here)
• unit tests

Once it is done we can continue with the 0454-present-proof-v2 protocol (I don't expect it may take much time) and so on one-by-one.

The biggest downside, in my opinion, is unconditional ACK. It means that please_ack (OUTCOME) becomes useless. It should be considered only as a temporary solution until ACA-Py is able to check if the other side supports the please_ack or not.
If you find the unconditional ACK not good even as a temporary solution we have to start work from the solving this compatibility issue.
One of the possible solution may be based on the 0557-discover-features-v2 protocol. Unfortunately, it seems not to be quick solution. May be there are other possible ways how to resolve the issue.

I don't like the 'unconditional ACK' idea but we must not break backward compatibility. Alternative way is to postpone the please_ack support and try to focus on the issues like that and resolve them (as a precondition).

What do you think?

[swcurran]

Thanks for the notes and suggestions. The unconditional Ack is messy. Even the “simple” on receipt is tricky. And the whole, per protocol impacts are too hard to understand/account for. Trying use an approach that is both useful and has a minimum impact is very, very difficult. This is what happens when introducing protocols without implementing as they are defined. 😭

Unfortunately, I don’t think we can progress right now — I just feel like the community is not ready for this. The impact of the protocol is too large, there are too many questions that have to be addressed about how it should be implemented, and it is not clear that there is a need for the feature. What I would like to do is have a discussion with production implementers to see where they would use the protocol if it were available. However, I think even that would be difficult — implementers probably wouldn’t think they needed it.

The most important thing is how not to lose this information you have learned. Closing these PRs without put the learning some where would be a bad idea.

How about I take on to do a presentation for the Aries Working Group in the next few weeks about what was found, to learn what others think, and to at minimum, put references into the Please Ack RFC to a summary of what was discovered in investigating this?

Sorry for introducing this topic. What a mess!

[swcurran]

I've added a discussion section that I plan to go over at the next ACA-Pug meeting -- https://wiki.hyperledger.org/display/ARIES/2023-11-14+Aries+Cloud+Agent+-+Python+Users+Group+Community+Meeting. It is a bit of a dry-run for a similar discussion at an Aries Working Group meeting.

[alexsdsr]

Hello @swcurran

The most important thing is how not to lose this information you have learned. Closing these PRs without put the learning some where would be a bad idea.

I have updated the document in this PR. I've tried to summarize important things and remove unnecessary according to our discussion here in comments. It would be excellent if you have a chance to review it. It is quite short, btw. I would ask you to think if this document (research, in fact) could be stored in the repo or not. If not, may be there is another place to store it.
Thank you.

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[alexsdsr]

Hello @swcurran

Could you please take a look at the final version of the document?
Is it worth having it in the repo? What do you think?
Thank you.

[dbluhm]

We will not be moving forward with support for the please_ack decorator right now. Thanks for your efforts!

[swcurran]

To be more precise about the resolution for this PR, why it is being closed and to show how effort is linked to further explanations. The Aries Community is removing please_ack from AIP 2.0 and retiring the please_ack protocol in this Aries RFC PR that should be merged Real Soon Now. In that PR, links are provided to the PRs done here (but not merged) to provide extra details as to why the protocol is being retired — because a “general purpose” please_ack feature is not viable and if wanted, MUST be part of each protocol.

Thanks again for the work, @alexsdsr. Even though it didn’t get merged we learned a lot from this and moved DIDComm forward. The biggest learning is to make sure that we don’t “throw in” cross-cutting or optional features that alter the protocols state machines. For example — as recently come up — throwing in an optional, extra “problem-report” in response to a flawed final message of a protocol breaks the state machine. Either the extra message MUST be made every time, or not ever made — not sometimes...