Hi Paul,
Comments in line. There's one definite good catch in your
review, and obviously more clarifications are needed.
On 01-Dec-20 15:06, Paul Kyzivat wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area
> Review Team (Gen-ART) reviews all IETF documents being processed by the
> IESG for the IETF Chair. Please wait for direction from your document
> shepherd or AD before posting a new version of the draft. For more
> information, please see the FAQ at <
> http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-anima-grasp-api-08
> Reviewer: Paul Kyzivat
> Review Date: 2020-11-30
> IETF LC End Date: 2020-10-28
> IESG Telechat date: 2020-12-01
>
> Summary:
>
> This draft is on the right track but has open issues, described in the
> review.
>
> General:
>
> This document has addressed some of the concerns I had during the last
> call review. However some of my concerns remain and some new ones have
> arisen in this version.
>
> Issues:
>
> Major: 3
> Minor: 6
> Nits: 1
>
> 1) MAJOR: Negotiation
>
> The text in section 2.3.5 now makes clear that the sequence of steps in
> the negotiation is non-deterministic - both sides can call
> negotiate_step and negotiate_wait. I believe this can result in the two
> sides not agreeing on what values have been negotiated. (For instance,
> what if one side calls negotiate_step concurrently with the other side
> calling end_negotiate? Which value has been agreed upon?)
The negotiate_step calls alternate between the two peers, until one of them
calls end_negotiate (or a timeout kills the session). I hoped that
was clear in the protocol diagram. We can make it explicit, for people
who haven't fully digested the protocol spec. Since that's ~50 pages, it
certainly takes some digestion.
(negotiate_wait would be interjected by the peer who has the next go, simply
indicating that the next step is delayed. That could happen, for example,
if the ASA needed to negotiate something with a third party before
continuing.)
> The loop_count
> adds to the confusion. Are the two sides intended to have independent
> loop count values? It seems these too can become unsynchronized.
The loop count also bounces backwards and forwards in alternate steps.
Again, we can underline that in the text.
> Also, the goal of negotiation isn't clear to me. I gather it must be for
> the two sides to agree on a particular value for the objective. But for
> that to work there must be some rules about how values can change in
> each step so that the result stabililizes, rather than causing a battle
> that ends with loop count exhaustion. This could be achieved by always
> negotiating *down*, or always *up*. But that requires that the objective
> value type have an ordering function. Given the general nature of the
> objective I don't think that can be assumed.
No, it explicitly is not defined either in the protocol nor the API.
The syntax and semantics of the objective value are defined per-objective,
and the objective might or might not be ordered. So there is intentionally
no answer to your question.
In most cases I'd expect that there would be an ordering but we didn't want
to constrain the use cases in that way. Also note that a failed negotiation
(e.g. the loop count expires, or where one end simply rejects the other's
offer) is not a protocol failure.
>
> ISTM that more work is needed to define the negotiation process in a way
> that ensures it ends with both sides agreeing on a single value for the
> objective.
As noted, that is per-objective. The most complicated case I've coded
is IP prefix assignment, and it works fine, except that if there is
no prefix available of the maximum desired length, the requester ends
up unsatisfied - as intended. There should be no condition in which
the negotiation loops indefinitely; it either succeeds or fails.
>
> 2) MINOR: Dry Run Negotiation
>
> Dry Run negotiation is very under-specified. Why would it be used? I
> guess that an ASA might use dry run negotiation to inform future actual
> negotiation. Can anything be inferred from a dry run negotiation about
> how an actual negotiation will go? When participating in a dry run
> negotiation, how should an ASA decide what response to make? Should it
> take into account current resource availability? Or should it respond
> based on best-case or worst-case resource availability? Or what?
>
> This requires further clarification.
Again, *all* these issues are specific to the objective in question,
and they are intentionally not addressed in the protocol design or
the API.
> 3) MAJOR: Confusing semantics of 'request_negotiate'
>
> In section 2.3.5 I don't understand the following:
>
> 1. The 'session_nonce' parameter is null. In this case the
> negotiation has succeeded in one step and the peer has
> accepted the request. The returned 'proffered_objective'
>
