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

Commentary: Partially addresses 
 It is analogous , because the structure of the subregistry is slightly different ( additional column ) . We can add a sentence that the value of the additional column does not influence the choice of the policy . Good point . OK , “ update ” is not the right word them . Good point . It was smeared all over the document , and then we collected it in an appendix . I do n’t think anyone would have a strong opposition against making it a mainline section . Should we ? 
 In general , I prefer to separate out unrelated issues ( editorial or not ) to simplify tracking / closing : Regarding : There are at least three similar cases of " both endpoints " which would need to be corrected together . 
 - Regarding  's comment ( which you seem to concur with ... ): 7.6 : The " updates " in this section are confusing . I understand this to mean that the procedures for TCP and WS are identical to those for UDP except for the mentioned steps . But the language of the form of " This step from [ RFC7252 ] is updated to : " makes it sound like this intends to actually change the language in 7252 to this new language . If the latter , then that effectively removes UDP support from 7252 as updated . This could easily be fixed by changing that to something to the effect of " When using TCP , this step changes to ... " The text actually updates  to address all cases . I do n't see how it effectively removes UDP support since the text is additive . For example : This step from [ RFC7252 ] : If does not equal the request ’s destination UDP port , include a Uri - Port Option and let that option ’s value be . is updated to : If does not equal the request ’s destination UDP port or TCP port , include a Uri - Port Option and let that option ’s value be . 
 - I do not feel strongly about moving    but I 'm open to suggestions . It 's hard to find the right place in the flow - perhaps before / after Section 6 ? 
 This issue is partially addressed by - which I 'm merging now since I 'm on leave for the next two weeks . The other potential editorial changes are pending responses from
Once a connection is established, both endpoints MUST send a
Capabilities and Settings message (CSM see csm) as their 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.
Once a connection is established, each endpoint MUST send a
Capabilities and Settings message (CSM see csm) as their 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.
As with CoAP over TCP, both endpoints MUST send a Capabilities and
Settings message (CSM see csm) as their first message on the
WebSocket connection.
As with CoAP over TCP, each endpoint MUST send a Capabilities and
Settings message (CSM see csm) as their first message on the
WebSocket connection.
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.
One CSM MUST be sent by each endpoint at the start of the connection.
Further CSM MAY be sent at any other time by either endpoint over the
lifetime of the connection.
The IANA policy for future additions to this sub-registry is based on
number ranges for the option numbers, analogous to the policy defined
in Section 12.2 of RFC7252.