Original text:
This property specifies the minimum number of bytes in a received message that need to be covered by a checksum.  A special value of 0 means that a received packet does not need to have a non-zero <del> checksum field.  A receiving Endpoint will not forward messages to the application that have less coverage.  The application is </del>  responsible for handling any corruption within the non-protected part of the message RFC8085.

Reviewer comments:
I was so confused, if people like this PR I think I might be less confused in future.
Thought to
PR for issue:
Why is the name not rather something like perMsgChecksumFullSend?
Happy with a change if making this more consistent.
There are some related changes in
NAME : Did the merged PR 839 happen to address this? - If not please make a PR.
NAME PR 839 updated the name, but still found it confusing so made a PR.
See review.
The Required Minimum Corruption Protection Coverage for Receiving current text says: This property specifies the minimum number of bytes in a received message that need to be covered by a checksum. A special value of 0 means that no checksum is permitted. A receiving Endpoint will not forward messages to the application that have less coverage. The application is responsible for handling any corruption within the non-protected part of the message [RFC8085]. I have thought, and there seem to be various problems with how this finally emerged: in the UDP-Lite API, the. Value 0 indicates full coverage, not zero coverage. If the zero is intentionally redefined this way, what is the expected value for full coverage? The words “No checksum is permitted” can be read in multiple ways.... if this means a message can be received without checking a checksum, then this should be said. Finally, can we specify the receiver outcome when the API requires x bytes of coverage, but the message header protects fewer bytes, is the message discarded, as per UDP-Lite? Section 7.1.3.6. Sending Corruption Protection Length, is the zero case interpreted differently to UDP-LIte? Note: I THINK setting the to zero presently forces IPv4, (since UDP for IPv6 requires a checksum except for an upper-layer that explicitly performs this function).
I have updated your comment to use numbers so I can answer it a little easier here. It's defined as a special value (see: "Type: Integer, with special value Full Coverage"). This answers 4) too: in UDP-Lite, also on sending, "0" indicates full coverage, whereas here it means the opposite "that no checksum is required". [side note, it says "non-negative" for sending, in 7.1.3.6, but it should say so for receiving, in 6.1.1, as well]. I agree. I think this would be good to specify, yes, and I agree that it should be discarded. Clearly, since this is called "required minimum corruption protection length", it is a promise that must be kept. see above I'm lost (yes I'm aware that IPv6 has no checksum, but still). Are you talking about 0 as I write here ("no checksum required"), or 0 as in UDP-Lite (requiring full checksum coverage) ?
Ping NAME
Thanks - great catch about s/perMsgChecksumLenSend/perMsgChecksumSend (and -Recv) in particular, these must have been historical remnants. I added one comment related to English, take a look to see if you agree.

Revised text:
This property specifies the minimum number of bytes in a received message that need to be covered by a checksum.  A special value of 0 means that a received packet does not need to have a non-zero  <ins> checksum field.  A receiving endpoint will not forward messages that have less coverage to the application.  The application is </ins> responsible for handling any corruption within the non-protected part of the message RFC8085.