The recommended default and can we specify rather than recommend?

[gorryfair]

Section 5.2: “The recommended default”

Thsi may sound radical for TAPS, however, I have trouble understanding why we do not simply not specify the defaults, rather than recommend them.

I think we provide plenty of ways that an app can using a system can over-ride defaults, but if we do not agree on the meaning of a default, there are real dangers in interior problems between systems - we say common language helps, in this case it hinders. I propose that we make all the default recomendations as requirements for the default case?

[mwelzl]

Makes sense to me. (just to be clear, I think you meant to say "...why we do not simply specify the defaults" instead of "do not simply not specify" - i.e. you WANT to specify the defaults)

[gorryfair]

I was motivating specifying a default for each, by motivagting why and stating something like:

The dafault MUST be xxx."

[philsbln]

I guess relying on the defaults from the defaults in the API is dangerous anyway, but this really depends on the properties:

• For some properties, e.g., Notification of ICMP soft error message arrival this is harmless and having a should-default is fine.
• For semantic-changers like Reliable Data Transfer or Preservation of data ordering we need either a MUST or no default at all and require the application to explicitly specify what it wants.

[gorryfair]

Right. I'm keener on making the dafault "safe" than requiring specification. A "safe" default means that actually means if the app wants something, different it has to specify. Happy to review a set of defaults if this helps.

[MaxF12]

I agree that the current phrasing "An implementation of this interface must provide sensible defaults ..." is quite ambiguous as anything can be "sensible" given the right context.

There is also the system policy to consider, which would still provide a way to deviate from the default on a system to system basis.

[philsbln]

@MaxF12 The system policy is the reason why not all defaults are MUSTs.

So, I am very much in favor to cut through the properties and turn the defaults to MUST for a well-chosen set of them.

[gorryfair]

I think I don't have the same viewpoint. Pehaps we need to understand what is intended by "default" - do you see this as a "TAPS system default"... I am quite happy that the TAPS system default is over-ridden in the application code or in a policy - presumably whoever made the policy change had a good reason to do this and they will then get the behaviour they tweak - and that may change what the application sees when it expresses no preference itself?

[philsbln]

Possibly… the evaluation of Preferences is a complicated beast. Let me write up what my perspective is:

1. There is a "TAPS default" (in the document).
   • If this is Require or Prohibit, there is no way for an implementation to get around the requirement even if it is "just the default".
   • Changing "TAPS default" in an implementation is considered harmful, because it breaks portability.
2. The "TAPS default" is used unless the application sets something.
3. A System Configuration (you may call this policy) may override the applications' preference within bounds:
   • It MUST honour require/prohibit
   • It may change prefer/ignore/avoid to anything it likes
4. The Policy/Racing component (you may call this differently) chooses the transport options that
   • honour require/prohibit
   • somehow weight prefer/ignore/avoid and express it in penalties for the racing

This results in a simple consequence:

• If the "TAPS default" is Require or Prohibit, this is a MUST default.
• If the "TAPS default" is something else, it is either a SHOULD or we can remove it completely.

[gorryfair]

Why is this so:

"A System Configuration (you may call this policy) may override the applications' preference within bounds:
It MUST honour require/prohibit"

• I can see that an IETF BCP for UDP mandates the default to be REQUIRES Checksum coverage. That is way the IETF has reached consensus on the default. Now, if I invent a tunnel-broker application, I may have good erasons to not stick to teh default, and I could indeed find other guidance that lets me do different when I can provide other checks. So if I know what I am doing I can include policy or application configuration to change that. That's quite OK.

• Back to the app that doesn't want something special - it needs to get the checksum coverage feature, otherwise it doesn't function normally in some cases. That to me is why the default system value is REQUIRES.

I think if we think, we know the default for many functions and can cite PS or BCP documents to support these choices.

I am however, unsure what you write above about understanding of the "consequences"...

[adfalk]

<Chair interrupt>This seems like a policy discussion that would be better had on the wg email list.</>

…

On 30 Apr 2019, at 9:28, Gorry Fairhurst wrote: Why is this so: "A System Configuration (you may call this policy) may override the applications' preference within bounds: It MUST honour require/prohibit" - I can see that an IETF BCP for UDP mandates the default to be REQUIRES Checksum coverage. That is way the IETF has reached consensus on the default. Now, if I invent a tunnel-broker application, I may have good erasons to not stick to teh default, and I could indeed find other guidance that lets me do different when I can provide other checks. So if I know what I am doing I can include policy or application configuration to change that. That's quite OK. - Back to the app that doesn't want something special - it needs to get the checksum coverage feature, otherwise it doesn't function normally in some cases. That to me is why the default system value is REQUIRES. I think if we think, we know the default for many functions and can cite PS or BCP documents to support these choices. I am however, unsure what you write above about understanding of the "consequences"... -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: #317 (comment)

[philsbln]

If an application relies on Checksum coverage of the whole message and expresses this either by specifying it or not specifying it because it knows it is the default behaviour, changing this behaviour "by policy" may cause the application to malfunction.
If you change the protocol behaviour "on path" and implement the required functionality in a different way, it does not feel like a policy thing any more, but as some kind of path/middlebox behaviour.

[gorryfair]

I'm not going down the on-path discussion.

In answer to the first question: "yes" if someone deploys stupid policies - then it will break applications. That was always true of NEAT policy, when we had the NEAT framework and I guess of any other polcie: If theres is a request nonsense properties it will break the app, just as surely as broken code asking for wrong properties will also break it.

But, I could write a policy that says my App can tolerate XXX, and providing I supply code to support this, my app would work just as well as if I had requested a property XXX via the API. I can also do something more complex - like when I use network YYY and I can use ZZZ and then I don't need XXX. Whether that is easier by defining policy or by writing code using the API depends.

If we understand one another, we can continue on the list...

[philsbln]

I think I got your point … this also rises the question whether properties specified by the application and properties specified by the policy/configuration are equivalent / should use the same language / may override each other or fail in case of a conflict.

I always implied that the application will only set a minimal set of properties (bare necessary requirements + runtime-dependent information), and the configuration/policy will do the fine-tuning, but hat is not a canonical view of things.

Lets' take this discussion to the list.

[gorryfair]

OK - let's do that.

Could we also try to start a discussion about the set of default values in a seprate thread. I think we can address some of these quickly, albeit we wait for the list discussion (or wider consensus) on whether they are SHOULD or MUST.

[britram]

From discussion in Montréal: "the default is"