|
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
|
