Sergey Fomin

The operational goal stated above can be easily achieved by using TARGET_DEFINED mode with the exception of "operator specified interval" (currently interval will be chosen by vendor, or by a...

>First TARGET_DEFINED is not well defined and varies between vendors as a result and not aligned with a common behavior across vendors I'd argue that it is reasonably well defined,...

In short, what I would propose is to - close this PR - start with a clear problem statement in `/issues`, where solutions can be discussed - get a consensus...

> AFAIU, unknown extensions should be ignored while requests with known extensions that are malformed or used in an inappropriate context should be rejected. I agree with that approach/interpretation.

Sorry, I'm not following.. IMO in either case it will be translated into a single `docker run` cmd (or equivalent). Can you provide an example how/where a second tag can...

Just to clarify further, I don't question the standalone StartContainer RPC. All I'm saying is that in `UpdateContainerRequest` an `image:tag` combination can be included twice (because the update request already...

Ok. Just to confirm, would it be fair to say that * `image_name` and `image_tag` at the top level of `UpdateContainerRequest` are mandatory. * we can silently ignore `image_name` and...

While I agree that a system-wide capabilities response is not always sufficient (I raised some of the questoins/issues in #149); I'm not a huge fan of per-interface approach. Typically in...

>We also have a use-cases that aren't distinguishable by an ASIC alone but rather configuration attributes of an interface that cascades towards separate capablities "per interface" Can you please elaborate...

>One example could be the modes set on an interface (e.g. channelization) - if we get into implementation detail, there could be a variety of reasons that capabilities can then...