Draft: draft-ietf-core-coap-tcp-tls

Commentary: One more 7.01 change to 7.00 . Removed redundant requirement for references to abort : MAY immediately abort the connection ( see Section 4.6 ) . since the Abort section already has the SHOULD . 
 Signaling s / Share / Relate/ ( the nodes do not " share these characteristics " )  down s / Ordered / Orderly/ Provide diagnostic information when terminating a connection in ... 4.3 . Capability and Settings Messages ( CSM ) Hmm , should this be " Capabilities and Settings Messages " ? ( Need to change throughout . ) s / A / One/ s / Capability and Settings message / CSM/ s / and/. Further CSM/ s / settings / setting/ 4.3.2 .        ( above 1152 ? ) 
    Protocol Versions s / Capability and Settings / Capabilities and Settings Messages ( CSM)/ 
 Cl.4.5/4.6 : The text mentions a " diagnostic payload " , is some standard envisaged for this or is it implementation dependent ? This is implementation dependent , although it might be helpful to adapt or reference - 
 Reviewed in more detail . There is a reference to  in an earlier section 
 Perhaps the  references needs to be emphasized more . Options : Blockquote related RFC7252 Section 5.5.2 in section 4.1 to call more attention to it Include an xref with each related normative statement The simplest mitigation is the xref : A Release message indicates that the sender does not want to continue maintaining the connection and opts for an orderly shutdown . The details are in the options . A diagnostic payload ( see Section 5.5.2 of [ RFC7252 ] ) MAY be included .
Both the client and the server MUST send a Capability and Settings
message (CSM see csm) as its first message on the connection.  This
message establishes the initial settings and capabilities for the
endpoint such as maximum message size or support for block-wise
transfers.  The absence of options in the CSM indicates that base
values are assumed.
Both the client and the server MUST send a Capabilities and Settings
message (CSM see csm) as its first message on the connection.  This
message establishes the initial settings and capabilities for the
endpoint such as maximum message size or support for block-wise
transfers.  The absence of options in the CSM indicates that base
values are assumed.
The Version (Vers) field is elided as well.  In constrast to the
UDP message layer for UDP and DTLS, the CoAP over TCP message
layer does not send a version number in each message.  If required
in the future, a new Capability and Settings Option (see
negotiation) could be defined to support version negotiation.
The Version (Vers) field is elided as well.  In contrast to the
message format of CoAP over UDP, the message format for CoAP over
TCP does not include a version number.  CoAP is defined in RFC7252
with a version number of 1.  At this time, there is no known
reason to support version numbers different from 1.  If version
negotiation needs to be addressed in the future, then Capabilities
and Settings Messages (CSM see csm) have been specifically
designed to enable such a potential feature.
A code in the 7.01-7.31 range indicates a Signaling message.  Values
in this range are assigned by the "CoAP Signaling Codes" sub-registry
(see message-codes).
Payloads in Signaling messages are diagnostic payloads (see
Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling
message option.
A code in the 7.00-7.31 range indicates a Signaling message.  Values
in this range are assigned by the "CoAP Signaling Codes" sub-registry
(see message-codes).
Payloads in Signaling messages are diagnostic payloads as defined in
Section 5.5.2 of RFC7252), unless otherwise defined by a Signaling
message option.
A Capability and Settings message MUST be sent by both endpoints at
the start of the connection and MAY be sent at any other time by
either endpoint over the lifetime of the connection.
Both capability and settings options are cumulative.  A Capability
and Settings message does not invalidate a previously sent capability
indication or setting even if it is not repeated.  A capability
message without any option is a no-operation (and can be used as
such).  An option that is sent might override a previous value for
the same option.  The option defines how to handle this case if
needed.
Base values are listed below for CSM Options.  These are the values
for the Capability and Setting before any Capability and Settings
messages send a modified value.
These are not default values for the option as defined in
Section 5.4.4 in RFC7252.  A default value would mean that an empty
Capability and Settings message would result in the option being set
to its default value.
Capability and Settings messages are indicated by the 7.01 code
(CSM).
One CSM MUST be sent by both endpoints at the start of the
connection.  Further CSM MAY be sent at any other time by either
endpoint over the lifetime of the connection.
Both capability and setting options are cumulative.  A CSM does not
invalidate a previously sent capability indication or setting even if
it is not repeated.  A capability message without any option is a no-
operation (and can be used as such).  An option that is sent might
override a previous value for the same option.  The option defines
how to handle this case if needed.
Base values are listed below for CSM Options.  These are the values
for the capability and setting before any Capabilities and Settings
messages send a modified value.
These are not default values for the option as defined in
Section 5.4.4 in RFC7252.  A default value would mean that an empty
Capabilities and Settings message would result in the option being
set to its default value.
Capabilities and Settings messages are indicated by the 7.01 code
(CSM).
As per Section 4.6 of RFC7252, the base value (and the value used
when this option is not implemented) is 1152.  A peer that relies on
this option being indicated with a certain minimum value will enjoy
limited interoperability.
As per Section 4.6 of RFC7252, the base value (and the value used
when this option is not implemented) is 1152.
A Release message indicates that the sender does not want to continue
maintaining the connection and opts for an orderly shutdown.  The
details are in the options.  A diagnostic payload MAY be included.  A
peer will normally respond to a Release message by closing the TCP/
TLS connection.  Messages may be in flight when the sender decides to
send a Release message.  The general expectation is that these will
still be processed.
A Release message indicates that the sender does not want to continue
maintaining the connection and opts for an orderly shutdown.  The
details are in the options.  A diagnostic payload (see Section 5.5.2
of RFC7252) MAY be included.  A peer will normally respond to a
Release message by closing the TCP/TLS connection.  Messages may be
in flight when the sender decides to send a Release message.  The
general expectation is that these will still be processed.
An Abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
abort (and may or may not wait for a Release or Abort message or
connection shutdown in the inverse direction).  A diagnostic payload
SHOULD be included in the Abort message.  Messages may be in flight
when the sender decides to send an Abort message.  The general
expectation is that these will NOT be processed.
An Abort message indicates that the sender is unable to continue
maintaining the connection and cannot even wait for an orderly
release.  The sender shuts down the connection immediately after the
abort (and may or may not wait for a Release or Abort message or
connection shutdown in the inverse direction).  A diagnostic payload
(see Section 5.5.2 of RFC7252) SHOULD be included in the Abort
message.  Messages may be in flight when the sender decides to send
an Abort message.  The general expectation is that these will NOT be
processed.
TLS version 1.2 or higher is mandatory-to-implement and MUST be
enabled by default.  An endpoint MAY immediately abort a CoAP over
TLS connection that does not meet this requirement (see sec-abort)
and SHOULD include a diagnostic payload.
TLS version 1.2 or higher is mandatory-to-implement and MUST be
enabled by default.  An endpoint MAY immediately abort a CoAP over
TLS connection that does not meet this requirement (see sec-abort).