Re: [core] Updated CoAP option template and OSCORE handling

[[e-mail]]

Hi Christian, 

As we need to capture both E ad U for OSCORE and the need for consistent use of "x" to tag a given characteristic, another approach would be:

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

But given the conflict with the already used "Unsafe" column, I tend to prefer not overloading the existing table, but have a dedicated table that mimics Figure 5 of RFC8613: 

                   +------+-----------------+---+---+
                   | No.  | Name            | E | U |
                   +------+-----------------+---+---+
                   |  16  | Hop-Limit       |   | x |
                   +------+-----------------+---+---+

If this approach is followed, we will update the new-block draft to include this NEW table:

                   +------+-----------------+---+---+
                   | No.  | Name            | E | U |
                   +------+-----------------+---+---+
                   | TBA1 | Q-Block1        | x | x |
                   | TBA2 | Q-Block2        | x | x |
                   +------+-----------------+---+---+
          Table 2: Protection of Q-Block1 and Q-Block2 Options

Cheers,
Med

> -----Message d'origine-----
> De : core [mailto:[e-mail]] De la part de Christian
> Amsüss
> Envoyé : mercredi 9 décembre 2020 15:28
> À : Core WG mailing list <[e-mail]>
> Objet : [core] Updated CoAP option template and OSCORE handling
> 
> 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

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.