[core] Updated CoAP option template and OSCORE handling

[Christian Amsüss <[e-mail]>]

Hello CoRE,

it is custom so far with all RFCs that introduce CoAP options to
summarize their options in a table like 


 +--------+---+---+---+---+-----------+--------+--------+---------+
 | Number | C | U | N | R | Name      | Format | Length | Default |
 +========+===+===+===+===+===========+========+========+=========+
 | 16     |   |   |   |   | Hop-Limit | uint   | 1      | 16      |
 +--------+---+---+---+---+-----------+--------+--------+---------+

With OSCORE, its [table 5] introduces two more columns that, when
plainly added, but their naming conflicts on "U" as noted in the Genart
review[1].

As "how is this handled with object security" is a good thing to have at
hand, I propose 

 +--------+---+---+---+---+-----------+--------+--------+---------+---+
 | Number | C | U | N | R | Name      | Format | Length | Default | O |
 +========+===+===+===+===+===========+========+========+=========+===+
 | 16     |   |   |   |   | Hop-Limit | uint   | 1      | 16      | U |
 +--------+---+---+---+---+-----------+--------+--------+---------+---+

annotated as "O: OSCORE classification (U: unprotected)", and intend to
use this with echo-request-tag (ERT).

The practical alternative is to leave that information out of the table,
and only have it present textually; I think that would make it harder
for an implementer to grasp at one look how the option is supposed to
behave.


KR
Christian

PS. Yeah I know this is not something that needs WG-wide agreement on or
  would be binding for anyone registering an option, but still we can
  contribute to a consistent ecosystem here.

[table 5]: https://tools.ietf.org/html/rfc8613#page-17
[1]: https://datatracker.ietf.org/doc/review-ietf-core-echo-request-tag-11-genart-lc-robles-2020-12-02/

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom