Draft: draft-ietf-taps-interface

Commentary: This replacement for PR was discussed at the last interim . 
 5 from this . Slightly modified as a result of . Should “ Type ” line also include ( non - negative ) like s9.1.3.2 does ? Just trying to be matchy - matchy . 
 3 from this . This issue was addressed via . I included this only for completeness . Close at your leisure . I read this definition a bunch . Are there two special values ? The Type line says “ Full Coverage ” is special , but then the description says “ 0 ” is special too . Maybe look at s91.3.6 for inspiration ? 
 This issue on coverage is resolved in the latest . 
 I cringe at systems that define Integers to be integers and some other enumerated things ( " special values " ) . Is it necessary to define things this way ? I understand it 's currently typical to have this behavior in the APIs of the protocols this system is attempting to abstract , but is it impossible to stop propagating that kind of type confusion ? This API could move the things special values are being used for into separate arguments for example . 
 This only appears to be used for checksum coverage ; do n't overload integer for this application . 
 Use type enumerations instead . Some languages let you do this . Otherwise you just pick an out - of - range integern . 
 The " special value " also shows up for numeric in 8.1.3 , 8.1.4 , 8.1.8 and 8.1.9 
 We discussed this in the last interim , but I do n't think the tuple - based approach in works well , and prefer the type enumeration suggestion made . That is , do n't say : rather say : 
 ACK - already in my todo list ... 
 In the interface draft , section 1.1 : Do we need to conflate numeric types and enumerations , or can numbers be numbers ? 
 From interim : add a clarification on what this is about , why it ( symbolic values ) is there . 
 Fixed by
Paragraph (version A):
Integer: Instances take positive or negative numeric integer
values, or sometimes special non-numeric (symbolic) values.
Paragraph (version A):
Numeric: Instances take positive or negative numeric values, or
sometimes special non-numeric (symbolic) values.
Paragraph (version B):
Integer: Instances take positive or negative integer values.
Paragraph (version B):
Numeric: Instances take positive or negative real number values.
Paragraph (version A):
This property specifies the minimum number of bytes in a received
message that need to be covered by a checksum.  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.  A special value of 0
means that a received packet may also have a zero checksum field.
Paragraph (version B):
If this property is an Integer, it specifies the minimum number of
bytes in a received message that need to be covered by a checksum.  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.  A
special value of 0 means that a received packet may also have a zero
checksum field.
Paragraph (version A):
This property specifies how long to wait before deciding that an
active Connection has failed when trying to reliably deliver data to
the Remote Endpoint.  Adjusting this Property will only take effect
when the underlying stack supports reliability.  The special value
"Disabled" means that no timeout is scheduled.
Paragraph (version A):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  This property specifies the maximum
length of time an idle connection (one for which no transport packets
have been sent) should wait before the Local Endpoint sends a keep-
alive packet to the Remote Endpoint.  Adjusting this Property will
only take effect when the underlying stack supports sending keep-
alive packets.  Guidance on setting this value for datagram
transports is provided in RFC8085.  A value greater than the
connection timeout (conn-timeout), or the special value "Disabled",
will disable the sending of keep-alive packets.
Paragraph (version B):
If this property is Numeric, it specifies how long to wait before
deciding that an active Connection has failed when trying to reliably
deliver data to the Remote Endpoint.  Adjusting this Property will
only take effect when the underlying stack supports reliability.  If
this property has the enumerated value "Disabled", it means that no
timeout is scheduled.
Paragraph (version B):
A Transport Services API can request a protocol that supports sending
keep alive packets keep-alive.  If this property is an Integer, it
specifies the maximum length of time an idle connection (one for
which no transport packets have been sent) should wait before the
Local Endpoint sends a keep-alive packet to the Remote Endpoint.
Adjusting this Property will only take effect when the underlying
stack supports sending keep-alive packets.  Guidance on setting this
value for datagram transports is provided in RFC8085.  A value
greater than the connection timeout (conn-timeout) or the enumerated
value "Disabled" will disable the sending of keep-alive packets.
Paragraph (version A):
This property specifies an upper-bound rate that a transfer is not
expected to exceed (even if flow control and congestion control allow
higher rates), and/or a lower-bound rate below which the application
does not deem it will be useful.  These are specified in bits per
second.  The special value "Unlimited" indicates that no bound is
specified.
Paragraph (version A):
This property controls the number of Connections that can be accepted
from a peer as new members of the Connection's group.  Similar to
SetNewConnectionLimit(), this limits the number of ConnectionReceived
Events that will occur, but constrained to the group of the
Connection associated with this property.  For a multi-streaming
transport, this limits the number of allowed streams.
Paragraph (version B):
Integer values of this property specify an upper-bound rate that a
transfer is not expected to exceed (even if flow control and
congestion control allow higher rates), and/or a lower-bound rate
below which the application does not deem it will be useful.  These
are specified in bits per second.  The enumerated value "Unlimited"
indicates that no bound is specified.
Paragraph (version B):
If this property is an Integer, it controls the number of Connections
that can be accepted from a peer as new members of the Connection's
group.  Similar to SetNewConnectionLimit(), this limits the number of
ConnectionReceived Events that will occur, but constrained to the
group of the Connection associated with this property.  For a multi-
streaming transport, this limits the number of allowed streams.
Paragraph (version A):
This property specifies the minimum length of the section of a sent
Message, starting from byte 0, that the application requires to be
delivered without corruption due to lower layer errors.  It is used
to specify options for simple integrity protection via checksums.  A
value of 0 means that no checksum needs to be calculated, and "Full
Coverage" means that the entire Message needs to be protected by a
checksum.  Only "Full Coverage" is guaranteed, any other requests are
advisory, which may result in "Full Coverage" being applied.
Paragraph (version B):
If this property is an Integer, it specifies the minimum length of
the section of a sent Message, starting from byte 0, that the
application requires to be delivered without corruption due to lower
layer errors.  It is used to specify options for simple integrity
protection via checksums.  A value of 0 means that no checksum needs
to be calculated, and the enumerated value "Full Coverage" means that
the entire Message needs to be protected by a checksum.  Only "Full
Coverage" is guaranteed, any other requests are advisory, which may
result in "Full Coverage" being applied.