Original text:
3.3. <del> Once a connection is established, both endpoints MUST send a </del>  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 4.3. <del> As with CoAP over TCP, both endpoints MUST send a Capabilities and </del>  Settings message (CSM see csm) as their first message on the WebSocket connection. Each setting option indicates a setting that will be applied by the sender. <del> 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. </del>  Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined <del> in Section 12.2 of RFC7252. </del>  The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following

Reviewer comments:
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 don’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.
NAME - Regarding Ben'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 RFC7252 to address all cases. I don'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 .
NAME - I do not feel strongly about moving Appendix A - 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 NAME

Revised text:
3.3.  <ins> Once a connection is established, each endpoint MUST send a </ins> 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 4.3.  <ins> As with CoAP over TCP, each endpoint MUST send a Capabilities and </ins> Settings message (CSM see csm) as their first message on the WebSocket connection. Each setting option indicates a setting that will be applied by the sender.  <ins> 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. </ins> Both capability and setting options are cumulative.  A CSM does not invalidate a previously sent capability indication or setting even if The IANA policy for future additions to this sub-registry is based on number ranges for the option numbers, analogous to the policy defined  <ins> in Section 12.2 of RFC7252.  (The policy is analogous rather than identical because the structure of the subregistry includes an additional column; however, the value of this column has no influence on the policy.) </ins> The documentation for a Signaling Option Number should specify the semantics of an option with that number, including the following