Draft: draft-ietf-taps-interface

Commentary: . Partially addresses . 
 Section 7.3.1 : The word “ lifetime ” appears several times in the architecture document . I am unsure whether any of these uses are the same as the use here . This would be helped ( of course ) a little , if this section were renamed as “ Message Lifetime ” What is the default ? if any ? — — Section 7.3.2 What is the default priority ? Interesting question , but I suggest it could be useful to still have a default even if the meaning and range are varying . If the default were , say , “ 100 ” then anything less than 100 is less priority and anything more is more than default priority . That ’s useful if I supply no param in one connection and then supply a param in other connections . — Section 7.3.3 . Ordered I think this needs to default to safety : i.e. TRUE - Required . — Section 7.3.4 . Idempotent -I think this needs to default to safety : i.e. “ FALSE ” . — Section 7.3.5 . Final I think this should default to the most common : i.e. “ FALSE ” . — Data Transfer ( Message ) this should default to something . — Transmission What is the default ? — 
 PR addresses this . Some details below : Regarding " lifetime " , the use is indeed different . However , all these occurrences seem to clearly refer to a different thing than the Message Property from context ( e.g. , by saying " the lifetime of a connection " ) . Renaming this into Message Lifetime seems clumsy and inconsistent ( as in : why are all the other Message Properties not prefaced with " Message " ? ) , so I decided to leave this as it is . Regarding 7.3.7 : I chose " true " as a default because it is probably the most common ( and allows TCP as a protocol choice ) . Regarding 7.3.9 : I chose " false " as a default because it is probably the most common ( and allows TCP as a protocol choice ) . 
 In section 6.4 : This para opens with the words “ Groups of Connections ” Please check which letter groups should be capitalised in this section , I think it should be “ Connection Group ” , so this should be “ Groups of connections ” . — In Section 7 : “ Data is sent in terms of Messages , ” Is it true that “ blocks of data supplied by the application are sent as Messages ” or what does “ in terms of ” refer to ? — In Section 7.1 : “ Message data is created as an array of octets ” even I have a a hard time remembering 6 - bit bytes , can we declare “ octet”as historic and use “ bytes ” . is the data “ created ” or “ transferred ” — In Section 7.1 : “ Applications can query the protocol property Maximum Message Size on Send to determine the maximum size allowed for a single Message . ” I do n’t know how the app does this across the API , can we be more clear ? ( It could be the example below seeks to explain this , in which case maybe a little wording change would help me ? ) — Section 7.2 : “ There are several events ” - should this be “ Events ” ? — Section 7.2.1 : “ and is no longer the responsibility of the implementation of this interface ” : why use the words “ the implementation of ” , is there something more subtle that needs explained , or can these words be deleted ? — Section 7.3 : “ The simpler form of Send that does not take any messageContext is equivalent to passing a default MessageContext with not values . ” These read wrong : /not/ /is equivalent/ , could this be better ? “ The simpler form of Send , which does not take any messageContext , is equivalent to passing a default MessageContext without adding any values . ” Also , what are values here : properties or something else ? — Section 7.5 : “ In order to reduce the overhead ” please remove /In order/ to avoid any misunderstanding about ordering . — Section 9.1.2 . Required minimum coverage of the Corruption Protection for receiving The default needs to be protect the entire message . 
 PR addresses this . A detail below : Regarding : Sure this can ( and should ! ) lead to some form of grouping of transport connections below , but it is meant as a construct applying to the Connections that an application sees - conceptually these are the ones that are grouped . So I think it should be " Connections " , not " connections " . 
 In Section 5.2.7 Control checksum coverage on sending “ The recommended default is to  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  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 . 
 this seems reasonable to me , I do n't recall how we ended up at  . 
 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 . 
 Yes , this seems to be a misunderstanding . Perhaps we also need to clarify that  just means that the property is ignored when ranking alternatives for candiadet selection and racing , not that the application can ignore it ? 
 I do n'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 do n't we just have a property that says you want to have ( require ) or would like to have ( prefer ) , or do n't care ( ignore ) some size of limited checksum coverage - as in 7.3.6 . If you do n'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 do n'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 ?    TAPS interim , let 's Avoid this . 
 PR partially addresses this : 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 . 
 PR addresses the last missing bit here : 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 . 
 fixed by 
 thanks for adding this - makes things more consistent
Paragraph (version A):
If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol which provides
a reliable ordered octet stream, an application may receive this
octet stream as partial Messages and transform it into application-
layer Messages.  Alternatively, an application may provide a
Deframer, which is a function that transforms an octet stream into a
sequence of Messages, see receive-framing.
Paragraph (version B):
If none of the available transport protocols provides Preservation of
Message Boundaries, but there is a transport protocol which provides
a reliable ordered byte stream, an application may receive this byte
stream as partial Messages and transform it into application-layer
Messages.  Alternatively, an application may provide a Deframer,
which is a function that transforms a byte stream into a sequence of
Messages, see receive-framing.
Paragraph (version A):
Once a Connection has been established, it can be used for sending
data.  Data is sent in terms of Messages, which allow the application
to communicate the boundaries of the data being transferred.  By
default, Send enqueues a complete Message, and takes optional per-
Message properties (see send-basic).  All Send actions are
asynchronous, and deliver events (see send-events).  Sending partial
Messages for streaming large data is also supported (see send-
partial).
Paragraph (version B):
Once a Connection has been established, it can be used for sending
data.  Data is sent as Messages, which allow the application to
communicate the boundaries of the data being transferred.  By
default, Send enqueues a complete Message, and takes optional per-
Message properties (see send-basic).  All Send actions are
asynchronous, and deliver events (see send-events).  Sending partial
Messages for streaming large data is also supported (see send-
partial).
Paragraph (version A):
The most basic form of sending on a connection involves enqueuing a
single Data block as a complete Message, with default Message
Properties.  Message data is created as an array of octets, and the
resulting object contains both the byte array and the length of the
array.
Paragraph (version B):
The most basic form of sending on a connection involves enqueuing a
single Data block as a complete Message, with default Message
Properties.  Message data is transferred as an array of bytes, and
the resulting object contains both the byte array and the length of
the array.
Paragraph (version A):
Some transport protocols can deliver arbitrarily sized Messages, but
other protocols constrain the maximum Message size.  Applications can
query the protocol property Maximum Message Size on Send to determine
the maximum size allowed for a single Message.  If a Message is too
large to fit in the Maximum Message Size for the Connection, the Send
will fail with a SendError event (send-error).  For example, it is
invalid to send a Message over a UDP connection that is larger than
the available datagram sending size.
Paragraph (version B):
Some transport protocols can deliver arbitrarily sized Messages, but
other protocols constrain the maximum Message size.  Applications can
query the Connection Property "Maximum Message size on send" (conn-
max-msg-send) to determine the maximum size allowed for a single
Message.  If a Message is too large to fit in the Maximum Message
Size for the Connection, the Send will fail with a SendError event
(send-error).  For example, it is invalid to send a Message over a
UDP connection that is larger than the available datagram sending
size.
Paragraph (version A):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of the implementation of this interface.  The exact
disposition of the Message (i.e., whether it has actually been
transmitted, moved into a buffer on the network interface, moved into
a kernel buffer, and so on) when the Sent Event occurs is
implementation-specific.  The Sent Event contains an implementation-
specific reference to the Message to which it applies.
Paragraph (version B):
The Sent Event occurs when a previous Send Action has completed,
i.e., when the data derived from the Message has been passed down or
through the underlying Protocol Stack and is no longer the
responsibility of this interface.  The exact disposition of the
Message (i.e., whether it has actually been transmitted, moved into a
buffer on the network interface, moved into a kernel buffer, and so
on) when the Sent Event occurs is implementation-specific.  The Sent
Event contains an implementation-specific reference to the Message to
which it applies.
Paragraph (version A):
The simpler form of Send that does not take any messageContext is
equivalent to passing a default MessageContext with not values added.
Paragraph (version B):
The simpler form of Send, which does not take any messageContext, is
equivalent to passing a default MessageContext without adding any
Message Properties to it.
Paragraph (version A):
This property specifies the length of the section of the 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.  By default,
the entire Message is protected by a checksum.  A value of 0 means
that no checksum is required, and a special value (e.g. -1) can be
used to indicate the default.  Only full coverage is guaranteed, any
other requests are advisory.
Paragraph (version B):
This property specifies the minimum length of the section of the
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 is required, and -1 means that the
entire Message is protected by a checksum.  Only full coverage is
guaranteed, any other requests are advisory.
Paragraph (version A):
In order to reduce the overhead of sending multiple small Messages on
a Connection, the application may want to batch several Send actions
together.  This provides a hint to the system that the sending of
these Messages should be coalesced when possible, and that sending
any of the batched Messages may be delayed until the last Message in
the batch is enqueued.
Paragraph (version B):
To reduce the overhead of sending multiple small Messages on a
Connection, the application may want to batch several Send actions
together.  This provides a hint to the system that the sending of
these Messages should be coalesced when possible, and that sending
any of the batched Messages may be delayed until the last Message in
the batch is enqueued.
Paragraph (version A):
See receive-framing for handling Message framing in situations where
the Protocol Stack provides octet-stream transport only.
Paragraph (version B):
See receive-framing for handling Message framing in situations where
the Protocol Stack provides byte-stream transport only.
Paragraph (version A):
The Receive Event is intended to be fired once per application-layer
Message sent by the remote endpoint; i.e., it is a desired property
of this interface that a Send at one end of a Connection maps to
exactly one Receive on the other end.  This is possible with Protocol
Stacks that provide message boundary preservation, but is not the
case over Protocol Stacks that provide a simple octet stream
transport.
Paragraph (version B):
The Receive Event is intended to be fired once per application-layer
Message sent by the remote endpoint; i.e., it is a desired property
of this interface that a Send at one end of a Connection maps to
exactly one Receive on the other end.  This is possible with Protocol
Stacks that provide message boundary preservation, but is not the
case over Protocol Stacks that provide a simple byte stream
transport.
Paragraph (version A):
For preserving message boundaries over stream transports, this
interface provides receiver-side de-framing.  This facility is based
on the observation that, since many of our current application
protocols evolved over TCP, which does not provide message boundary
preservation, and since many of these protocols require message
boundaries to function, each application layer protocol has defined
its own framing.  A Deframer allows an application to push this de-
framing down into the interface, in order to transform an octet
stream into a sequence of Messages.
Paragraph (version B):
For preserving message boundaries over stream transports, this
interface provides receiver-side de-framing.  This facility is based
on the observation that, since many of our current application
protocols evolved over TCP, which does not provide message boundary
preservation, and since many of these protocols require message
boundaries to function, each application layer protocol has defined
its own framing.  A Deframer allows an application to push this de-
framing down into the interface, in order to transform an byte stream
into a sequence of Messages.