Re: [Gen-art] Genart last call review of draft-ietf-lpwan-coap-static-context-hc-12

[Theresa Enghardt <[e-mail]>]

Dear Ana,

Thank you for the responses to my comments and for the improvements to
the document.

Please find responses to some of your points and some suggestions inline:

On 25.02.20 23:26, Ana Minaburo wrote:
>
>     Minor issues:
>
>     Abstract
>     To make the abstract more self-contained, I suggest adding a brief
>     description
>     of what SCHC is, then stating explicitly that so far SCHC has been
>     defined for
>     UDP and IPv6, and this document defines it for CoAP. Then the
>     abstract can keep
>     the two examples of how CoAP presents some unique challenges for
>     using SCHC,
>     but it should clearly say that these are examples, as Section 3
>     later lists
>     more differences. Finally, perhaps it's worth making the last
>     sentence more
>     concrete to say how the document addresses these challenges. Maybe
>     something
>     like: The document gives guidance on how to apply SCHC to flexible
>     headers and
>     how to leverage the asymmetry for more efficient compression rules.
>
> Ana: Thanks for this input, the new version of the abstract is:
>
> "This draft defines the way SCHC (Static Context Header Compression)
> header compression can be applied to CoAP protocol. SCHC is a header
> compression mechanism adapted for constrained devices. SCHC uses a
> static description of the header to reduce the redundancy and the size
> of the information in the header. While the RFC8724 describes the SCHC
> compression and fragmentation framework, and its application for
> IPv6/UDP headers, this document applies the use of SCHC for CoAP
> headers. The CoAP header structure differs from IPv6 and UDP one since
> CoAP uses a flexible header with a variable number of options,
> themselves of variable length. The CoAP protocol messages format is
> asymmetric: the request messages have a header format different from
> the one in the response messages. This specification gives guidance on
> how to apply SCHC to flexible headers and how to leverage the
> asymmetry for more efficient compression Rules."

TE: Thanks, this makes the abstract much more self-contained. Some
suggested nits here:
"can be applied to CoAP protocol" --> "can be applied to the CoAP protocol"
"While the RFC8724 describes" --> "While RFC8724 describes"
"differs from IPv6 and UDP one" --> "differs from IPv6 and UDP" or
"differs from the IPv6 and UDP one"


>
>     "The context(s) is(are) known by both ends before transmission." -
>     As someone
>     not yet familiar with SCHC, it would be really helpful to have one
>     or two
>     sentences here explaining how this usually works. Are the contexts
>     typically
>     configured on the devices when installing the application? Are
>     contexts
>     exchanged out of band and/or using some kind of protocol exchange?
>
> Ana: The way the context is configured or exchanged is out of the
> scope of this document because we are trying to explain the problem of
> CoAP header compression.

TE: I see. Could you briefly point this out in the document, i.e., say
"The way the context is configured or exchanged is out of the scope for
this document", please?


>
>     "[I-D.ietf-lpwan-ipv6-static-context-hc] defines the use of a
>     message direction
>     (DI) in the Field Description, which allows a single Rule to
>     process message
>     headers differently depending of the direction." - I think here it
>     makes sense
>     to say how this point relates to the point before, that CoAP is
>     asymmetric. Is
>     this in conflict, so it makes SCHC more difficult to use for CoAP?
>     Or does this
>     just mean that the SCHC rules have to be different for CoAP?
>
> Ana: It is not a conflict neither more difficult nor different, as
> SCHC includes the DI in the Rule the CoAP asymmetric problem is
> solved. Because the value in DI will be used to define which fields
> are in which direction in the same Rule. So instead of describing two
> Rules, one for each direction, we only have to define one Rule for
> both directions, paying attention to give the correct field description.

TE: Thanks for the explanation. Maybe here it's worth rephrasing "which
allows a single Rule to process message headers differently depending of
the direction" to make this more explicit.


>  
>
>     "The direction allows splitting in two parts the possible values
>     for each
>     direction in the same Rule." - Sentence is hard to parse. What
>     does "the
>     direction" refer to here - a part of the rule? the direction the
>     packet is sent?
>
> Ana: Direction is the Request or Response format (up, down,
> bidirectional). Yes is part of the Rule and yes 
> it describes the direction the packet is sent from client to server or
> from server to client, request/response format headers

TE: I see. Suggested new phrasing:
"The direction allows splitting the range of values in two parts, one
for each direction, and allows the same rule to handle traffic in both
directions."


>  
>
>     "In IPv6 and UDP, header fields have a fixed size and it is not
>     sent." - What
>     does "it" refer to here? The size?
>
> Ana: Yes, each field in the header has a length in bits or bytes; when
> a field in the header format has a fixed length, you know it, and it
> has been defined in the protocol document. 
> Example: The IPv6 version is 4-bit length and the value is 6, so in
> SCHC field description this field will have a size of 4 bits and the
> target value will be 6

TE: I see. Suggested new phrasing:
"In IPv6 and UDP, header fields have a fixed size, which is not sent."


>  
>
>     Section 4.5
>     "Token Value size cannot be defined directly in the rule in the
>     Field Length
>     (FL).  Instead, a specific function designated as "TKL" MUST be
>     used and length
>     does not have to be sent with the residue. During the
>     decompression, this
>     function returns the value contained in the Token Length field." -
>     Why can the
>     Token Value size (is this the length of this header field?) not be
>     defined
>     directly? And what is this specific function "TKL" supposed to do?
>     Is there a
>     reference for it? From this sentence, it's also not clear why
>     length does have
>     to be sent.
>
> Ana: Token is defined through two CoAP fields, Token-Length in the
> mandatory header and Token-Value directly following the mandatory CoAP
> header.
> Token Length is processed as any protocol field. If the value does not
> change, the size can be stored in the TV and elided during the
> transmission. Otherwise, it will have to be sent in the compression
> residue.
> Token Value MUST not be sent as a variable-length residue to avoid
> ambiguity with Token Length. Therefore, Token Length value MUST be
> used to define the size of the residue. 
> A specific function designated as "TKL" MUST be used in the Rule.
> During the decompression, this function returns the value contained in
> the Token Length field.

TE: Makes sense. I suggest adding this explanation to the document.


I'm looking forward to the next revision.

Best,
Theresa