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

Commentary: ... an example
The sender can use the elective Max-Message-Size Option to indicate
the maximum size of a message in bytes that it can receive.  The
message size indicated includes the entire message, starting from the
first byte of the message header and ending at the end of the message
payload.
Note that there is no relationship of the message size to the overall
request or response body size that may be achievable in block-wise
transfer.  For example, consider the GET with BERT block-wise
transfer in fig-bert1.  If the CoAP client indicates a value of 6000
bytes using the Max-Message-Size option then the exchange will
succeed since none of the three transfers will be above the indicated
maximum size limit (ignoring the size of the CoAP header and options,
which are not shown in the message flow).  Consider a second case
where the same CoAP client indicates a value of 4000 bytes using the
Max-Message-Size option then the CoAP stack on the server will refuse
the transmission (or adjust the transmission size) since the payload
exceeds the limit indicated by the client.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: s / Unless there is an option with delaying semantics / Unless the PING carries an option with delaying semantics/
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.
Upon receipt of a Ping message, the receiver MUST return a Pong
message with an identical token in response.  Unless the Ping carries
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: ( 1 ) s / between 0 and 12/ & inclusive/ ( 2 ) maybe revisit the language about default values vs. origin values for CSM options :
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.
These are not default values for the option, as defined in
Section 5.4.4 in RFC7252.  Default values apply on a per-message
basis and thus reset when the value is not present in a given
Capabilities and Settings message.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: 1 : It is not clear how the protocol reacts the errors from transport layers ( e.g. connection failure ) . The protocol will just inform apps of the events and the app will decide what to do or the protocol itself will do something ? The WebSockets case is addressed by RFC6455 : -and- After review with the authors , we 'll append a clarification for CoAP over TCP in its Connection Health section .
When the underlying TCP connection is closed or reset, the signaling
state and any observation state (see observe-cancel) associated with
the reliable connection are removed.  In flight messages may or may
not be lost.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Add to Updates Updated Abstract Added IANA section to update related references for Block1 and Block2 
 : 3 : Since this draft defines new SZX value , I think the doc needs to update RFC7959 . This point should be clarified more in the doc . My sense is that we should treat this as an update to RFC7959 based on the original language : and the use of " extension " in coap - tcp - tls : This also requires an IANA addition , since the entries for Block1 and Block2 need to also reference coap - tcp - tls in addition to RFC7959 .
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 RFC 7641 for use with these
transports, and RFC 6455 to extend the well-known URI mechanism (RFC
5785) to the ws and wss URI schemes.
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 RFC 7641 for use with these
transports, RFC 7959 to enable the use of larger messages over a
reliable transport, and RFC 6455 to extend the well-known URI
mechanism (RFC 5785) to the ws and wss URI schemes.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: : Section 8.1 makes it Mandatory to Implement the protocol without any security ( " NoSec " ) . This seems counter to best practice in the IETF , but I 'll defer to the Security Area review . I  's position that this could become optional . History : Some context - during the security discussions in the WG , there was a recommendation to " mirror " the similar section in  . states : The NoSec and RawPublicKey modes are mandatory to implement for this specification . which is why NoSec is MTI .
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.
The "NoSec" mode is optional-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.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Updates for acronyms Minor style change to Abstract 
 Please spell out acronyms at first use . I will correct the BERT case and also review for other potential cases .
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, and RFC 6455 to extend the well-known URI mechanism (RFC
5785) to the ws and wss URI schemes.
The RFC7252 was designed for Internet of Things (IoT) deployments,
assuming that UDP RFC0768 or DTLS RFC6347 over UDP can be used
unimpeded.  UDP is a good choice for transferring small amounts of
data across networks that follow the IP architecture.
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 RFC 7641 for use with these
transports, and RFC 6455 to extend the well-known URI mechanism (RFC
5785) to the ws and wss URI schemes.
The RFC7252 was designed for Internet of Things (IoT) deployments,
assuming that UDP RFC0768 or Datagram Transport Layer Security (DTLS)
RFC6347 over UDP can be used unimpeded.  UDP is a good choice for
transferring small amounts of data across networks that follow the IP
architecture.
BERT extends RFC7959 to enable the use of larger messages over a
reliable transport.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: I realize that the specific review feedback was for the Introduction - but might we also want to " minimize " the number of WS configurations discussed in Section 4 to focus on the browser motivation ? 
 While the third configuration is not mentioned in the introduction , all three are motivated by in - browser app use cases . So I do n’t see a need to cut down the discussion in Section 4 . Grüße ,  
 : The introduction motivates the layering of COAP over WebSockets to allow it to be used in a network that only allows external access through a HTTP proxy . In fact , it is not necessary to use WebSockets to do so ; HTTP CONNECT provides a tunnel in this scenario . WebSockets is a specialised protocol that allows bidirectional , stream - based transport from a Web browser -- it is effectively TCP wrapped into the Web browser 's security model , to make doing so safe . Using it for other purposes ( i.e. , non - browser use cases ) is n't really appropriate . I 'd suggest either removing the WebSockets binding , or changing its motivation in the Introduction . For reference , the original motivation :
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 WebSocket client and a WebSocket 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.
CoAP applications running inside a web browser without access to
connectivity other than HTTP and the RFC6455 may cross-proxy their
CoAP requests via HTTP to a HTTP-to-CoAP cross-proxy or transport
them via the the WebSocket protocol, which provides two-way
communication between a WebSocket client and a WebSocket server after
upgrading an RFC7230 connection.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: RFC 7252 says about : in Section 6.1 of RFC 7252 ; it is maybe an erratum that we did n’t do the same in Section 6.2 . In any case , we need to do this for all the new URI schemes we define in the current spec , probably best by a blanket statement for all of them at the start of section 7 . 
 RFC 7252 Section 6.2 specifies support for .well - known paths by saying All of the requirements listed above for the " coap " scheme are also requirements for the " coaps " scheme [ ... ] At least that 's the intention . 
 OK , it is not clear that extending is a " requirement " , so to me this is at least a " hold for document update " style erratum for RFC 7252 . But it is good that the right intention is in there , even if not unambiguously said so .
As with the "coap" and "coaps" schemes defined in RFC7252, all URI
schemes defined in this section also support the path prefix "/.well-
known/" defined by RFC5785 for "well-known locations" in the
namespace of a host.  This enables discovery as per Section 7 of
RFC7252.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Does n't this need an IANA considerations section - 
 We are not creating a registry here ; we are extending the semantics of the existing registry created by RFC 5875 to two existing URI schemes . No IANA action required . ( We do have an IANA action for registering in that existing registry . ) 
 I was thinking of something like this - 
 Yes -- 
 Doh . For some reason , I got hung up on needing a separate reference for RFC6455 , but only the URI suffix is registered . I can appreciate that the lack of a separate draft could be confusing based on the layout of the registry - which will only reference coap - tcp - tls . Sorry for the noise . 
 : Section 7.4 shows how to convert a " coap+ws:// " URI into a " wss:// " URI , using a well - known URI in the " wss " scheme . However , " wss " is not defined to use well - known URIs , so this is an invalid use ...
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.
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, and RFC 6455 to extend the well-known URI mechanism (RFC
5785) to the ws and wss URI schemes.
The WebSocket endpoint is identified by a "wss" URI that is composed
of the authority part of the "coaps+ws" URI and the well-known path
"/.well-known/coap" RFC5785.  The path and query parts of a
"coaps+ws" URI identify a resource within the specified endpoint
which can be operated on by the methods defined by CoAP.
The WebSocket endpoint is identified by a "wss" URI that is composed
of the authority part of the "coaps+ws" URI and the well-known path
"/.well-known/coap" RFC5785.  The present specification formally
updates RFC6455, extending the well-known URI mechanism defined in
RFC5785 to also cover the "wss" URI scheme defined in that document.
The path and query parts of a "coaps+ws" URI identify a resource
within the specified endpoint which can be operated on by the methods
defined by CoAP.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: Based on the further refine the earlier commit -
The connection is bi-directional, so requests can be sent both by the
entity that established the connection (Connection Initiator) and the
remote host (Connection Acceptor).  If one side does not implement a
CoAP server, an appropriate error response such as 4.04 (Not Found)
or 5.01 (Not Implemented) MUST be returned for all CoAP requests from
the other side.
The connection is bi-directional, so requests can be sent both by the
entity that established the connection (Connection Initiator) and the
remote host (Connection Acceptor).  If one side does not implement a
CoAP server, an error response MUST be returned for all CoAP requests
from the other side.  The simplest approach is to always return 5.01
(Not Implemented).  A more elaborate mock server could also return
appropriate.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: WGLC review by    20 : Alternative - Address Option - the semantics of including multiple of these options is not defined . Can the receiver pick any of the addresses ? Or does it need to try the first address first ? And then keep trying all alternatives until one succeeds , or not ? 
 Unless    ( authors of draft - bormann - core - coap - sig-02 ) have a preference , I would suggest that the addresses are unordered ( pick any ) .
The Alternative-Address Option is a repeatable option as defined in
Section 5.4.5 of RFC7252.
The Alternative-Address Option is a repeatable option as defined in
Section 5.4.5 of RFC7252.  When multiple occurrences of the option
are included, the peer can choose any of the alternative transport
addresses.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: RFC 7252 section 5.10.1 says : The default value of the Uri - Host Option is the IP literal representing the destination IP address of the request message . Likewise , the default value of the Uri - Port Option is the destination UDP port . The default values for the Uri - Host and Uri - Port Options are sufficient for requests to most servers .     and Uri - Port Options are typically used when an endpoint hosts multiple virtual servers . Do we expect this default value to be applicable ( and/or useful ) for all the cases we are looking at ? Maybe keeping Default - Uri - Host is not such a bad idea after all , or maybe we should clarify that this means for , say , a WebSocket server . 
 We should simply document appropriate defaults for TLS and WebSockets . There is already text for WS : 
 Regarding this scenario in  : Explicit Uri - Host and Uri - Port Options are typically used when an endpoint hosts multiple virtual servers . This is no longer relevant in CoAP over reliable transports . As  noted in the earlier TRAC issue : In CoAP over WebSockets , the virtual server is specified during the WebSocket handshake in the Host header field . The Uri - Host Option is therefore not needed . A client wishing to talk to multiple virtual servers running on the same IP address has to open one WebSocket connection to each virtual server . ( Please correct me if I 'm wrong . ) In CoAP over TLS we have the SNI extension , so I would expect that CoAP over TLS behaves like CoAP over WebSockets : no Uri - Host Option in requests , one connection to each virtual server . For the TLS+SNI case , the default value of the URI - Host is the underlying destination address that 's shared across the virtual servers . Further note that the Hostname passed in the TLS SNI extension is not an " IP literal " : - Literal IPv4 and IPv6 addresses are not permitted in " HostName " . would still require our draft to support the URI - Host Option for this case : At the moment , this issue does not appear actionable .
The default values for the Uri-Host and Uri-Port Options are
sufficient for requests to most servers.
Unless otherwise noted, the default value of the Uri-Host Option is
the IP literal representing the destination IP address of the request
message.  The default value of the Uri-Port Option is the destination
TCP port.
For CoAP over TLS, these default values are the same unless Server
Name Indication (SNI) RFC6066 is negotiated.  In this case, the
default value of the Uri-Host Option in requests from the TLS client
to the TLS server is the SNI host.
For CoAP over WebSockets, the default value of the Uri-Host Option in
requests from the WebSocket client to the WebSocket server is
indicated by the Host header field from the WebSocket handshake.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: 2/1 Conference call with Signaling authors BERT support can be enabled and then disabled :    - Size=1153 + Block - wise Transfer = Block - wise on + BERT on    - Size=1152 = Block - wise on + BERT off This should be noted .
If the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-wise Transfer Option.  If a Max-Message-Size Option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-wise Transfer Option also indicates
support for BERT (see bert).
If the option is not given, the peer has no information about whether
block-wise transfers are supported by the sender or not.  An
implementation that supports block-wise transfers SHOULD indicate the
Block-wise Transfer Option.  If a Max-Message-Size Option is
indicated with a value that is greater than 1152 (in the same or a
different CSM message), the Block-wise Transfer Option also indicates
support for BERT (see bert).  Subsequently, if the Max-Message-Size
Option is indicated with a value equal or less than 1152, BERT
support is no longer indicated.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: The next pass will add text related to the default URI - Host for TLS SNI cases .
An endpoint can use the critical Default-Uri-Host Option to indicate
the default value for the Uri-Host Options in the messages that it
sends to the other endpoint.  Its value MUST be a valid value for the
Uri-Host Option (Section 5.10.1 of RFC7252).
For TLS, the base value for the Default-Uri-Host Option in the
direction from the Connection Initiator to the Connection Acceptor is
given by the SNI value.
For WebSockets, the base value for the Default-Uri-Host Option in the
direction from the Connection Initiator to the Connection Acceptor is
given by the HTTP Host header field.
The active value of the Default-Uri-Host Option is replaced each time
the option is sent with a modified value.  Its starting value is its
base value (if available).
The elective Bad-Default-Uri-Host Option indicates that the default
indicated by the CSM Default-Uri-Host Option is unlikely to be useful
for this server.
SNI vs. Default-Uri-Host: Any security negotiated in the TLS
handshake is for the SNI name exchanged in the TLS handshake and
checked against the certificate provided by the server.  The
Default-Uri-Host Option cannot be used to extend these security
properties to the additional server name.
Draft: draft-ietf-core-coap-tcp-tls

Commentary: can you review ( do n't see you in the Reviewers list ) ? 
 Referencing , I have these comments : I feel the text in Section 7 discussing security solutions pertains to both TCP as well as WebSockets , and therefore propose the following amendment : " A security solution MUST be implemented to protect CoAP over reliable transports 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 reliable transports when appropriate . " In addition I have the following suggestion for a new subsection as follows : A CoAP client requesting a resource identified by a “ coaps+ws ” URI negotiates a secure WebSocket connection to a WebSocket server endpoint , with a “ wss " URI . This is described and depicted in section 6.4 . As provided by the guidance in Section 4.1 of [ RFC6455 ] , the client MUST perform a TLS handshake after opening the connection to the server . The guidance in Section 4.4 of [ RFC7925 ] applies towards mandatory - to - implement TLS functionality for certificates , when a CoAP server exposes resources identified by a “ coaps+ws ” URI . For the server - side requirements in accepting incoming connections over port 443 , guidance given in Section 4.2 of [ RFC6455 ] applies . 
 Minor . Regarding for the server - side requirements in accepting incoming connections over port 443 , guidance given in Section 4.2 of [ RFC6455 ] applies .... RFC6455 actually refers to an HTTPS ( HTTP - over - TLS ) port in this section : 
 Thanks  , this is ok with me
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).
A security solution MUST be implemented to protect CoAP over reliable
transports 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 reliable transports
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).
A CoAP client requesting a resource identified by a "coaps+ws" URI
negotiates a secure WebSocket connection to a WebSocket server
endpoint with a "wss" URI.  This is described in coaps-ws-scheme.
The client MUST perform a TLS handshake after opening the connection
to the server.  The guidance in Section 4.1 of RFC6455 applies.  When
a CoAP server exposes resources identified by a "coaps+ws" URI, the
guidance in Section 4.4 of RFC7925 applies towards mandatory-to-
implement TLS functionality for certificates.  For the server-side
requirements in accepting incoming connections over a HTTPS (HTTP-
over-TLS) port, the guidance in Section 4.2 of RFC6455 applies.