A46: xDS NACK Semantics Improvement

[markdroth]

No description provided.

[ejona86]

Beautiful. That was well documented.

[dfawley]

A++++++++++++++++++ would read again.

[murgatroid99]

Should a NACK sent in this situation indicate which resources are rejected vs accepted in a machine-readable way (i.e. other than in the error message)?

[markdroth]

@murgatroid99

Should a NACK sent in this situation indicate which resources are rejected vs accepted in a machine-readable way (i.e. other than in the error message)?

There's no way to do that today. That's what I was referring to in the doc by saying that there will be some future work to change the xDS protocol to make that possible.

[srini100]

Looks great! Thanks for taking care of this.

[fuqianggao]

won't this be addressed by minor version support on server side?

[markdroth]

We still don't actually have a design for version negotiation, so that's not a solution for the immediate problem. And even once we do have such a design, I suspect that that's not going to be the best way to address this kind of use-case, because it would require the control plane to have a bunch of logic to determine how to configure older clients that don't support the current configuration.

I think having the control plane generate different versions of the config will make sense for cases where we are deprecating one set of fields and replacing them with another set, where the semantic meaning of the underlying config can be expressed equally well via both sets of fields. But I think it will be too complex to do in cases where the client simply does not support the features that the configuration is intending to configure, because I don't think the control plane can really know what to do in that case.