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

Hi Christian,

Med's suggestion looks good to me - especially as there is potential for
lines being too long in the existing table if that was extended.

Regards

Jon

> -----Original Message-----
> From: mohamed.boucadair@orange.com [mailto:mohamed.boucadair@orange.com]
> Sent: 10 December 2020 09:09
> To: Christian Amsüss; Core WG mailing list
> Subject: Re: [core] Updated CoAP option template and OSCORE handling
> 
> 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:core-bounces@ietf.org] De la part de Christian
> > Amsüss
> > Envoyé : mercredi 9 décembre 2020 15:28
> > À : Core WG mailing list <core@ietf.org>
> > 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.
> 
> _______________________________________________
> core mailing list
> core@ietf.org
> https://www.ietf.org/mailman/listinfo/core