Below... On 04-Dec-20 04:17, Paul Kyzivat wrote: > Brian, > > One more thing occurred to me: > > On 12/2/20 12:29 PM, Paul Kyzivat wrote: > >>>> 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. >> >> Without that the result in non-deterministic. The two sides may have >> conflicting goals, and then the result will only be determined by the >> loop count and timeout. >> >> Alternately, implementors will establish side agreements that aren't >> governed by standards. >> >> That seems like an undesirable state of affairs. > > One possibility would be to define the negotiation policy on a > per-objective basis. This would be required as part of the definition of > the objective that is registered with IANA. It would define how the > value may change from step to step of negotiation to ensure convergence.
The IANA policy is Specification Required. We already have this in the GRASP spec itself: There must be a well-defined procedure for concluding that a negotiation cannot succeed, and if so deciding what happens next (e.g., deadlock resolution, tie-breaking, or revert to best-effort service). This MUST be specified for individual negotiation objectives. The natural place to expand on that is in draft-ietf-anima-asa-guidelines as it develops. Regards Brian _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art