Default for Control checksum coverage

[gorryfair]

In Section 5.2.7 Control checksum coverage on sending

“The recommended default is to Ignore this option.”

I argue that this default is much braver than specified in the IETF present in RFC 8085. The default for IPv6 is also that this is required by default. Again, I would argue that applications need to explicitly be designed to accept this.

—
In Section, 5.2.8. Control checksum coverage on receiving

“The recommended default is to Ignore this option.”

I argue that this default is much braver than specified in the IETF present in RFC 8085. The default for IPv6 is also that this is required by default. Again, I would argue that applications need to explicitly be designed to accept this.

[britram]

this seems reasonable to me, I don't recall how we ended up at Ignore.

[philsbln]

@gorryfair I think we need to re-phrase this as I guess you mis-read it.

The property only defines whether you want a protocol that provides this feature, not whether it should be enabled. The latter is controlled by the property in 7.3.6.

[abrunstrom]

Yes, this seems to be a misunderstanding. Perhaps we also need to clarify that Ignore just means that the property is ignored when ranking alternatives for candiadet selection and racing, not that the application can ignore it?

[gorryfair]

I don't understand something about 5.2.7 and 5.2.8 ... So let me ask a more stupid question:

• IETF transports always do provide full coverage by default.
• Why do we have a property to request control of checksum coverage at all, why don't we just have a property that says you want to have (require) or would like to have (prefer), or don't care (ignore) some size of limited checksum coverage - as in 7.3.6.

If you don't get the coverage that you ask for, then you will get more coverage. ... so "require" is in some way "prefer a protocol that gives at least an ability to provide this much?".

---

Then in 7.3.6:

I think " This property specifies the length of the section of the Message...." is actually the minimum length of message - the transport can always protect more.

I don't understand: " ... a special value (e.g. -1) can be used to indicate the default. "

• the default is full coverage, how is this different to a zero parameter?

Gorry

[britram]

per TAPS interim, let's Avoid this.

[mwelzl]

PR #330 partially addresses this:
7.3.6 was re-written to include "minimum" and fix the special value related text, also using the same style as in the other Message Properties now to specify the default.

[mwelzl]

PR #335 addresses the last missing bit here:

IETF transports always do provide full coverage by default.
Why do we have a property to request control of checksum coverage at all, why don't we just have a property that says you want to have (require) or would like to have (prefer), or don't care (ignore) some size of limited checksum coverage - as in 7.3.6.

I changed both Selection Properties to ask for full coverage and have them default to Require. The effect is similar to before, but intuitively this is clearer and makes more sense, I suppose.

[britram]

fixed by #335