Remove "conformance" language, clean up open issues.

[mjoras]

This is an alternative to #107.

Our thinking is that the "conformance" language is superfluous. The core issue that people have highlighted is that there is a potential need for clients to signal that they can receive the limits, and also that they have received them.

The former requirement is borne out of the fact that in order for a network element to send such signals it is useful to know the client can receive them and there will not be problems.

The latter is more of an acknowledgment mechanism, rather than a "I will abide" mechanism, hence "conformance" is the wrong word. There is a general sense that signaling "conformance" is immaterial to the network's decision making, as some degree of "trust-but-verify"

This PR attempts to resolve this by rewording the open issues section to explicitly call out these two determinations. It also removes the goal referencing them so as to not confuse the matter, as calling it out as an open issue is sufficient to provide the WG scope to work on this problem.

[dkg]

i'd like to understand both of those needs more clearly -- i don't think i even heard anyone suggest that the client needs to signal that it received them. can you point me to that message?

This edit seems to suggest that the client signalling mechanism, if considered, needs to provide both ability to receive and acknowledgement of receipt. what if analysis and discussion reveals that only one of those is needed but not the other? Will the charter imply that we need to do both?

[mjoras]

i'd like to understand both of those needs more clearly -- i don't think i even heard anyone suggest that the client needs to signal that it received them. can you point me to that message?

@dkg I'll let @ihlar elaborate more on this point since he has expressed this before (though I think not on the current thread).

This edit seems to suggest that the client signalling mechanism, if considered, needs to provide both ability to receive and acknowledgement of receipt. what if analysis and discussion reveals that only one of those is needed but not the other? Will the charter imply that we need to do both?

Our intention here is that both would be analyzed and considered separately by the working group for inclusion. Do you have a recommendation that makes that point more clear?

[ihlar]

i'd like to understand both of those needs more clearly -- i don't think i even heard anyone suggest that the client needs to signal that it received them. can you point me to that message?

@dkg I'll let @ihlar elaborate more on this point since he has expressed this before (though I think not on the current thread).

From my perspective, clients signaling the ability to receive 'application limits' is the most important aspect. Acknowledgement signaling could be nice, but I do not have a particularly strong motivating reason for it. It could be useful in making the solution robust to packet loss, but whether something like an ack is needed for that depends on the type of solution we actually develop.

This edit seems to suggest that the client signalling mechanism, if considered, needs to provide both ability to receive and acknowledgement of receipt. what if analysis and discussion reveals that only one of those is needed but not the other? Will the charter imply that we need to do both?

Our intention here is that both would be analyzed and considered separately by the working group for inclusion. Do you have a recommendation that makes that point more clear?

Yes, both should be analyzed decided on separately. @martinthomson has a good suggested edit.

[mjoras]

From my perspective, clients signaling the ability to receive 'application limits' is the most important aspect. Acknowledgement signaling could be nice, but I do not have a particularly strong motivating reason for it. It could be useful in making the solution robust to packet loss, but whether something like an ack is needed for that depends on the type of solution we actually develop.

Indeed, from my point of view leaving the investigation in scope is perfectly fine. We are in the early stages still of exploring the potential solution space, and I think there is not much to gain by keeping it out of scope. The charter is not saying the mechanism must have this property but rather the working group is allowed to consider it and its implications.