jiebi/ids-paragraph-commentary-corpus huggingface dataset:
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Corrected title for ( leaving open while we discuss examples ) Corrected version for new since - draft section 
 It only has examples of Ping and Pong . ( It would probably help to have an example of an initial CSM exchange . ) 
 Or perhaps eliminate the examples ? I note that  does not include Option examples . 
 I 'd rather do the work to include an initial CSM exchange . Just not sure I can get to that tomorrow . ( This kind of example is counter - intimidating — after all the verbiage you see that it is all really very simple ... ) 
 I 'm not sure that it was intimidating although I like counter - intimidating . It was certainly not a source of confusion during WGLC that then required clarification in examples . I worry about simply adding noise . And if pursued further , we should avoid Default - Uri - Host which would leave Max - Message - Size and Block - wise Transfer . 
 I corrected the title in . I 'm wo n't fixing the suggestion for CSM examples based on my previous comment . This can be revisited if there 's any related confusion during subsequent reviews .
Upon receipt of a Ping message, a single Pong message is returned
with the identical token.  As with all Signaling messages, the
recipient of a Ping or Pong message MUST ignore elective options it
does not understand.
Upon receipt of a Ping message, the receiver MUST return a Pong
message with an identical token in response.  Unless there is an
option with delaying semantics such as the Custody Option, it SHOULD
respond as soon as practical.  As with all Signaling messages, the
recipient of a Ping or Pong message MUST ignore elective options it
does not understand.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Apart from the possibly confusing " No " , this looks fine .
The active value of the Server-Name Option is replaced each time the
option is sent with a modified value.  Its starting value is its base
value (if available).
The active value of the Max-Message-Size Option is replaced each time
the option is sent with a modified value.  Its starting value is its
base value.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Address feedback from Hannes - Minor updates to
During the provisioning phase, a CoAP device is provided with the
security information that it needs, including keying materials,
access control lists, and authorization servers.  At the end of the
provisioning phase, the device will be in one of four security modes
with the following information for the given mode.  The "NoSec" mode
in mandatory-to-implement for the TLS binding.  The remaining
mandatory-to-implement mode depends on the credential type used with
the device.  "PreSharedKey", "RawPublicKey", or "Certificate" is
mandatory-to-implement for the TLS binding.
In the "NoSec" mode, the system simply sends the packets over normal
TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP
default port.  The system is secured only by keeping attackers from
being able to send or receive packets from the network with the CoAP
nodes.
The other three security modes are achieved using TLS and are
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
port.
The security considerations of RFC7252 apply.
CoAP over WebSockets and CoAP over TLS-secured WebSockets do not
introduce additional security issues beyond RFC7252.  The security
considerations of RFC6455 apply.
The "NoSec" mode is mandatory-to-implement.  The system simply sends
the packets over normal TCP which is indicated by the "coap+tcp"
scheme and the TCP CoAP default port.  The system is secured only by
keeping attackers from being able to send or receive packets from the
network with the CoAP nodes.
"PreSharedKey", "RawPublicKey", or "Certificate" is mandatory-to-
implement for the TLS binding depending on the credential type used
with the device.  These security modes are achieved using TLS and are
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
port.
The security considerations of RFC7252 apply.  For CoAP over
WebSockets and CoAP over TLS-secured WebSockets, the security
considerations of RFC6455 also apply.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: And changed  to Len=0 for websocket message format in Figure 14 . 
 Figure 4 : CoAP frame with 8 - bit Extended Length field . This ( and neither does the text ) does not make clear that the payload marker is sent only if there is a non - zero - length payload . ( Same for other below . ) Please cf . text from Section 3 of RFC 7252 : Figure 14 : CoAP Message Format over WebSockets Maybe show 0 , not  here . ( This also does not make clear that the payload marker is sent only if there is a non - zero - length payload . ) 
 It 's a bit awkward to insert text about the Payload Marker , since other fields are not re - introduced from  . In RFC8030 , we used the Conventions and Terminology section to also provide more context for examples based on feedback from the reviewers . One possibility is to use a similar approach here and indicate that all framing examples have the Payload Marker set . And of course , the " ( if any ) " would need to be removed . And then there 's still the need to clarify the WS case due to the requirement to set the  to 0 and rely on the WS frame .
The Payload Marker indicates the start of the optional payload and is
absent for zero-length payloads (see section 3 of RFC7252).
Draft: draft-ietf-core-coap-tcp-tls

Commentary: The draft header indicates that this document updates RFC7641 , but the abstract does n't seem to mention this , which it should . 
    to RFC7641 Observing Resources in the Constrained Application Protocol ( CoAP ) This needs to be referenced from the main body in some form .
Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS.  This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets
transports.
Some environments benefit from the availability of CoAP carried over
reliable transports such as TCP or TLS.  This document outlines the
changes required to use CoAP over TCP, TLS, and WebSockets
transports.  It also formally updates RFC7641 for use with these
transports.
In addition, some corporate networks only allow Internet access via a
HTTP proxy.  In this case, the best transport for CoAP would be the
RFC6455.  The WebSocket protocol provides two-way communication
between a client and a server after upgrading an RFC7230 connection
and may be available in an environment that blocks CoAP over UDP.
Another scenario for CoAP over WebSockets is a CoAP application
running inside a web browser without access to connectivity other
than HTTP and WebSockets.
In addition, some corporate networks only allow Internet access via a
HTTP proxy.  In this case, the best transport for CoAP might be the
RFC6455.  The WebSocket protocol provides two-way communication
between a client and a server after upgrading an RFC7230 connection
and may be available in an environment that blocks CoAP over UDP.
Another scenario for CoAP over WebSockets is a CoAP application
running inside a web browser without access to connectivity other
than HTTP and WebSockets.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Adds new Securing CoAP section and removes material from Security Considerations One open question is whether any of the " enabled " modes should be MTI . Even RFC7925 states : 
 Leaving open until there is broader review in the WG . 
 In : TLS does not protect the TCP header . This may , for example , allow an on - path adversary to terminate a TCP connection prematurely by spoofing a TCP reset message . This seems non - specific to coap - tcp - tls . I propose that it be removed .
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).
The TLS usage guidance in RFC7925 SHOULD be followed.
TLS does not protect the TCP header.  This may, for example, allow an
on-path adversary to terminate a TCP connection prematurely by
spoofing a TCP reset message.
CoAP over WebSockets and CoAP over TLS-secured WebSockets do not
introduce additional security issues beyond CoAP and DTLS-secured
CoAP respectively RFC7252.  The security considerations of RFC6455
apply.
A security solution MUST be implemented to protect CoAP over TCP and
MUST be enabled by default.  This document defines the TLS binding,
but alternative solutions at different layers in the protocol stack
MAY be used to protect CoAP over TCP when appropriate.  Note that
there is ongoing work to support a data object-based security model
for CoAP that is independent of transport (see I-D.ietf-core-object-
security).
The TLS usage guidance in RFC7925 applies.
During the provisioning phase, a CoAP device is provided with the
security information that it needs, including keying materials,
access control lists, and authorization servers.  At the end of the
provisioning phase, the device will be in one of four security modes
with the following information for the given mode.  The "NoSec" mode
in mandatory-to-implement for the TLS binding.  The remaining
mandatory-to-implement mode depends on the credential type used with
the device.  "PreSharedKey", "RawPublicKey", or "Certificate" is
mandatory-to-implement for the TLS binding.
TLS is disabled.
TLS is enabled.  The guidance in Section 4.2 of RFC7925 applies.
TLS is enabled.  The guidance in Section 4.3 of RFC7925 applies.
TLS is enabled.  The guidance in Section 4.4 of RFC7925 applies.
In the "NoSec" mode, the system simply sends the packets over normal
TCP which is indicated by the "coap+tcp" scheme and the TCP CoAP
default port.  The system is secured only by keeping attackers from
being able to send or receive packets from the network with the CoAP
nodes.
The other three security modes are achieved using TLS and are
indicated by the "coaps+tcp" scheme and TLS-secured CoAP default
port.
CoAP over WebSockets and CoAP over TLS-secured WebSockets do not
introduce additional security issues beyond RFC7252.  The security
considerations of RFC6455 apply.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: The table 2 below is n't correct as it includes names not the signal codes from Table 1 
 Cl.8.2 : I wonder if the first column in Table 3 should be " Applies to " ? It seems more natural to look up the Signal Code to find the option , instead of the options which could have the same number . 
 8.2 . CoAP Signaling Option Numbers Registry s / one / one or more/
IANA is requested to create a sub-registry for signaling options
similar to the CoAP Option Numbers Registry (Section 12.2 of
RFC7252), with the single change that a fourth column is added to the
sub-registry that is one of the codes in the Signaling Codes
subregistry (message-codes).
The name of this sub-registry is "CoAP Signaling Option Numbers".
IANA is requested to create a sub-registry for Options Numbers used
in CoAP signaling options within the "CoRE Parameters" registry.  The
name of this sub-registry is "CoAP Signaling Option Numbers".
Each entry in the sub-registry must include one or more of the codes
in the Signaling Codes subregistry (message-codes), the option
number, the name of the option, and a reference to the option's
documentation.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Also updated one more case of " messaging layer " rather than " message layer of " 
 Consider either removing the UDP to TCP gateway section ( ) or merging into another section as an example . Given the differences in message format in UDP vs TCP , this is a topic that may be useful as an example , but left as an implementation detail of a gateway . 
 Good point - in Hannes 's earlier draft , this was more of an example than a separate section - A UDP - to - TCP gateway will therefore discard all empty messages , such as empty ACKs ( after operating on them at the message layer ) , and re- pack the contents of all non - empty CON , NON , or ACK messages ( i.e. , those ACK messages that have a piggy - backed response ) into untyped messages ( that happen to look like NON messages ) .
TCP ensures reliable message transmission, so the CoAP over TCP
messaging layer is not required to support acknowledgements or to
detect duplicate messages.  As a result, both the Type and Message ID
fields are no longer required and are removed from the CoAP over TCP
message format.
TCP ensures reliable message transmission, so the message layer of
CoAP over TCP is not required to support acknowledgements or to
detect duplicate messages.  As a result, both the Type and Message ID
fields are no longer required and are removed from the CoAP over TCP
message format.
A UDP-to-TCP gateway MUST discard all Empty messages (Code 0.00)
after processing at the message layer.  For Confirmable (CON), Non-
Confirmable (NOM), and Acknowledgement (ACK) messages that are not
Empty, their contents are repackaged into untyped messages.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Also clarifies that " same kind " in Alternate - Address refers to scheme . 
 When I submitted the original pull request , I also posed a question on the but did not receive a response . One open question is whether we want to allow a client to immediately send messages after sending its CSM without waiting for the server CSM . This would be similar to HTTP/2 : To avoid unnecessary latency , clients are permitted to send additional messages to the server immediately after sending the client connection preface , without waiting to receive the server connection preface . It is important to note , however , that the server connection preface SETTINGS frame might include parameters that necessarily alter how a client is expected to communicate with the server . Upon receiving the SETTINGS frame , the client is expected to honor any parameters established . In some configurations , it is possible for the server to transmit SETTINGS before the client sends additional frames , providing an opportunity to avoid this issue . 
 I support not blocking the device until the server CSM . The server can choose to not process messages that are invalid ( e.g. too large ) and immediately follow up with the server CSM . From the perspective of a cloud and gateway software provider , the CoAP ( using TCP / TLS ) server will usually be in the cloud or gateway and therefore usually not power constrained . I may be missing other scenarios where a battery powered device is acting as a CoAP / TCP server . Does anyone have plans for any of those scenarios ? 
 a related comment to ( which is closed ) From your message I understand that in HTTP/2 the client can send messages immediately without waiting for the server to respond either . To me it feels like we should be doing what has been done in the HTTP/2 case even though there is a risk that some problems occur when the client sends data in way that the server will subsequently not handle well . If that is the case , the client will have to re - send the data , I guess . For the currently defined options I do n't see problems .
To avoid unnecessary latency, a client MAY send additional messages
without waiting to receive the server CSM; however, it is important
to note that the server CSM might advertise capabilities that impact
how a client is expected to communicate with the server.  For
example, the server CSM could advertise a Max-Message-Size option
(See max-message-size) that is smaller than the base value (1152).
The Alternative-Address elective option requests the peer to instead
open a connection of the same kind as the present connection to the
alternative transport address given.  Its value is in the form
"authority" as defined in Section 3.2 of RFC3986.
The Alternative-Address elective option requests the peer to instead
open a connection of the same scheme as the present connection to the
alternative transport address given.  Its value is in the form
"authority" as defined in Section 3.2 of RFC3986.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: There 's no longer an informative reference to this expired draft . Originally , it was included in the Introduction of draft - savolainen - core - coap - websockets-07 .
The payload of a CoAP message that is affected by a BERT Option in
descriptive usage (Section 2.1 of I-D.ietf-core-block).
The payload of a CoAP message that is affected by a BERT Option in
descriptive usage (Section 2.1 of RFC7959).
Requests and response messages can be fragmented as specified in
Section 5.4 of RFC6455, though typically they are sent unfragmented
as they tend to be small and fully buffered before transmission.  The
WebSocket protocol does not provide means for multiplexing.  If it is
not desirable for a large message to monopolize the connection,
requests and responses can be transferred in a block-wise fashion as
defined in I-D.ietf-core-block.
Requests and response messages can be fragmented as specified in
Section 5.4 of RFC6455, though typically they are sent unfragmented
as they tend to be small and fully buffered before transmission.  The
WebSocket protocol does not provide means for multiplexing.  If it is
not desirable for a large message to monopolize the connection,
requests and responses can be transferred in a block-wise fashion as
defined in RFC7959.
A sender can use the Block-wise Transfer elective Option to indicate
that it supports the block-wise transfer protocol I-D.ietf-core-
block.
A sender can use the Block-wise Transfer elective Option to indicate
that it supports the block-wise transfer protocol RFC7959.
The use of this new extension is signaled by sending Block1 or Block2
Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved
value in I-D.ietf-core-block.
The use of this new extension is signaled by sending Block1 or Block2
Options with SZX == 7 (a "BERT option").  SZX == 7 is a reserved
value in RFC7959.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Replacing " CoAP over TCP , TLS and Websockets " with " CoAP over reliable transports " is a good idea to reduce repetition . I feel it might be a good idea to clarify when we refer to reliable transports , that we actually refer to stream - based reliable transports . Datagram - based reliable transports ( eg DCCP , QUIC , etc ) exist , which render the Message Framing layer in Figure 1 unnecessary . I 'm not advocating that we run CoAP over QUIC , DCCP etc but perhaps clarification would be wise . 
 See also 
 I would add a note to the terminology section that CoAP over reliable transports refers to stream - based transport protocols , such as TCP . 
 Sounds reasonable : The term " reliable transport " only refers to stream - based transport protocols such as TCP . 
 The term " reliable transport " only refers to stream - based transport protocols such as TCP . We could say more explicitly : sequenced / order - preserving , reliable ... ( Stream might be byte stream or message stream . ) s / only refers / is used only to refer/ 
 - I would probably avoid " sequenced " which suggests sequence numbers and acknowledgements which are the mechanism to provide reliability . Perhaps too much detail ? How about : The term " reliable transport " is used only to refer to transport protocols such as TCP which provide reliable and ordered delivery of a byte - stream . 
 wrote : This concisely clarifies my initial concern , and I 'm ok with this .
Emerging standards such as Lightweight Machine to Machine LWM2M
currently use CoAP over UDP as a transport and require support for
CoAP over TCP to address the issues above and to protect investments
in existing CoAP implementations and deployments.  Although HTTP/2
could also potentially address these requirements, there would be
additional costs and delays introduced by such a transition.
Currently, there are also fewer HTTP/2 implementations available for
constrained devices in comparison to CoAP.
The term "reliable transport" only refers to stream-based transport
protocols such as TCP.
fig-flow-comparison illustrates the difference between CoAP over UDP
and CoAP over reliable transport.  The removed Type (no type) and
Message ID fields are indicated by dashes.
fig-flow-comparison illustrates the difference between CoAP over UDP
and CoAP over reliable transport.  The removed Type and Message ID
fields are indicated by dashes.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: There needs to be guidance about the intersection of WebSocket Ping - Pong and     . 
 Since     is a superset of WebSockets Ping - Pong and to use a consistent mechanism across reliable transports , I will add guidance that     is preferred over WebSockets Ping - Pong .
To check the health of the WebSocket connection (and thereby of all
active requests, if any), the client can send a Ping frame or an
unsolicited Pong frame as specified in Section 5.5 of RFC6455.  There
is no way to retransmit a request without creating a new one.  Re-
registering interest in a resource is permitted, but entirely
unnecessary.
To check the health of the WebSocket connection (and thereby of all
active requests, if any), a client can send a CoAP Ping Signaling
message (sec-ping).  WebSocket Ping and unsolicited Pong frames as
specified in Section 5.5 of RFC6455 SHOULD NOT be used to ensure that
redundant maintenance traffic is not transmitted.
There is no way to retransmit a request without creating a new one.
Re-registering interest in a resource is permitted, but entirely
unnecessary.
In CoAP over TCP, Empty messages (Code 0.00) can always be sent and
MUST be ignored by the recipient (see also sec-ping).  This provides
a basic keep-alive function that can refresh NAT bindings.  In
contrast, Ping and Pong messages are a bidirectional exchange.
In CoAP over TCP, Empty messages (Code 0.00) can always be sent and
MUST be ignored by the recipient.  This provides a basic keep-alive
function that can refresh NAT bindings.  In contrast, Ping and Pong
messages are a bidirectional exchange.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: sig-02 did not define the length for options with uint values . Can you confirm whether 0 - 4 is correct ? I note that there are variants in the  options with uint values . 
 Good catch . 0 - 4 definitely is right for  - Message - Size . 0 - 4 is a bit over the top for Hold - Off , but arbitrarily limiting the time at , say , seconds ( 0 - 2 ) or seconds ( 0 - 3 ) does n't sound right either -- well , maybe half a year  ( 0 - 3 ) is about right . Option numbers are  , so Bad - CSM - Option needs to be 0 - 2 .
Capability options advertise the capabilities of the sender to the
recipient.
Each capability option advertises one capability of the sender to
the recipient.