Re: [lp-wan] Alexey Melnikov's Discuss on draft-ietf-lpwan-coap-static-context-hc-13: (with DISCUSS and COMMENT)

[Ana Minaburo <[e-mail]>]

Dear Alexey and Francesca,

Thank you for your review.

Your comment raises two points on the same subject. One is about the way
SCHC compresses a bidirectional field where this field could be a CoAP
option or any other field in the header, and the second is the global way
to compress any CoAP Option.

- The first part of the comment is a Unidirectional/Bidirectional problem.
Let us explain how SCHC works
SCHC compression does not change the nature of the fields, but it will take
into consideration the values this field may drive in the Up/Dw
communication ways to describe the field in the Rule. When a field uses the
same value in both communication directions, it can be compressed as a
bidirectional field with the same TV/MO/CDA for both directions. When a
field is BI but uses different values for each direction, it will be
described twice in the Rule as a double unidirectional field (Up/Dw) with
the corresponding value for each direction.

Example:
CoAP Version is BI TV=01 MO=Equal CDA=not-sent

CoAP Type is BI but takes a different value in each direction; SCHC will
describe in the Rule, this field as:
CoAP Type in UP TV=0 MO=Equal CDA=not-sent
CoAP Type in DW TV=1 MO=Equal CDA=not-sent

-The second part of your comment is about how to compress other Options or
new Options not included in the current version of the document.
Good input,
We plan to add an introduction to Section5 CoAP Options to explain how SCHC
will compress any Option using the TLV (Type/Length/Value) definition.

A new version of the draft with your inputs will be published soon.

Thank you for your inputs.

Ana, Laurent & Ricardo

On Thu, Mar 12, 2020 at 11:46 AM Alexey Melnikov via Datatracker <
[e-mail]> wrote:

> Alexey Melnikov has entered the following ballot position for
> draft-ietf-lpwan-coap-static-context-hc-13: Discuss
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I agree with Ben's first 2 DISCUSS points.
>
> **********************************************************************
> * Note, that I am conducting an experiment when people aspiring to be*
> * Area Directors get exposed to AD work ("AD shadowing experiment"). *
> * As a part of this experiment they get to review documents on IESG  *
> * telechats according to IESG Discuss criteria document and their    *
> * comments get relayed pretty much verbatim to relevant editors/WGs. *
> * As an AD I retain responsibility in defending their position when  *
> * I agree with it.                                                   *
> * Recipients of these reviews are encouraged to reply to me directly *
> * about perceived successes or failures of this experiment.          *
> **********************************************************************
>
> The following comments were provided by Francesca Palombini
> <[e-mail]>. My comments are marked with
> [[Alexey:]]
> below.
>
> Francesca would have balloted *DISCUSS* on this document. She wrote:
>
> Discuss:
>
> Either I am missing something about "unirectional" and "bidirectional"
> definition (which I read as can either be present in only one direction
> request/response or both), or the following sections are wrong:
>
> section 5.1 - assuming it is Content-Format, the option is bidirectional,
> it
> can be set either in a request or response, for example a PUT request can
> contain a Content-Format section 5.4 - Size1 and Size2 are bidirectional,
> and
> can be used both in req and resp (see RFC7959 sect 4) Section 5.5 - ETag is
> also Bidirectional (see RFC7252 section 5.10.6.1 and 5.10.6.2)
>
> There are more options being defined and not specified in the document:
>
> https://www.iana.org/assignments/core-parameters/core-parameters.xhtml#option-numbers
> for example, Hop-Limit is one. There needs to be some discussion about
> those,
> or some considerations on those being out of scope.
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Francesca also provided the following comments:
>
> Comment:
>
> Section 4.2 CoAP type field: better to reference the IANA registry rather
> than
> this section, as additional Code fields not defined in RFC7252 can be
> registered. Section 7.4 : s/CONTENT/Content
>
>
>
>