Paul, We had a bit of delay on updating the ASA Guidelines draft, but the new version tries to cover your point at:
https://www.ietf.org/archive/id/draft-ietf-anima-asa-guidelines-01.html#section-5-2 Regards Brian Carpenter On 05-Dec-20 07:21, Paul Kyzivat wrote: > Brian, > > Thanks. I'm happy now. > > Paul > > On 12/3/20 4:22 PM, Brian E Carpenter wrote: >> 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
