Draft: draft-ietf-taps-interface

Commentary: 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 
 : Did the merged PR 839 happen to address this ? - If not please make a PR . 
 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 : 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 ? 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 . , 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 , the zero case interpreted differently to UDP - LIte ? : 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 . 's defined as a special value ( see : " Type :  , 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 ] . agree . 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 . above ' 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 
 Thanks - great catch about s / perMsgChecksumLenSend / perMsgChecksumSend ( and -Recv ) in particular , these must have been historical remnants . I one comment related to English , take a look to see if you agree .
Paragraph (version A):
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
checksum field.  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.
Paragraph (version B):
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
checksum field.  A receiving endpoint will not forward messages that
have less coverage to the application.  The application is
responsible for handling any corruption within the non-protected part
of the message RFC8085.