Static Context Header Compression (SCHC) for the Constrained Application Protocol (CoAP)
draft-ietf-lpwan-coap-static-context-hc-19

[Ballot comment]
Thanks for the updates in the -17 and -18, they do address my remaining
Discuss points and most of my comments.  I do have a few further
remarks, most notably a suggested rephrasing for the security
considerations section, but I believe they are all editorial in nature.

Section 5

nit: s/based header/basic header/

nit: s/stock/incorporate/ (or similar)

Section 5.3.1

  SCHC will send the second element of the URI-Path with the length
  (i.e., 0x2 X 6) followed by the query option (i.e., 0x05 "eth0").

I don't think I understand where the 0x05 comes from -- aren't there
only four non-NUL characters in "eth0"?

Section 6.3

(nit) I think the "The [RFC7967] defines a No-Response option limiting
the responses made by a server to a request" was better than the current
"The [RFC7967] defines a No-Response".

Section 7.1

  Note that a client located in an Application Server sending a request
  to a server located in the Device may not be compressed through this
  Rule since the MID will not start with 7 bits equal to 0.  A CoAP

nit(?): I am not 100% sure I understand the specifics here, but I think
the concern is just that the CoAP client in the Application Server might
be using the simple "single Message ID" strategy for all its outbound
requests, and thus might use more than 9 bits of message-ID space and
achieve the "not start with 7 bits equal to 0" condition.  As far as I
can tell, though, there is no fundamental reason why such requests would
*always* have a MID that does not start with 7 bits equal to zero, so I
would suggest s/will not/might not/.

Section 7.3

I recognize the width constraints of the table, but in Figure 13 the
"mapp-sent" CDA is not a term that seems to be used anywhere else in the
document.  I believe that it is okay to format this with a line break,
so that "mapping-" is on the first line and "sent" on the second.

  must include it without compression.  The use of integrity translates
  into an overhead in total message length, limiting the amount of
  compression that can be achieved and plays into the cost of adding
  security to the exchange.

nit: s/integrity/integrity protection/

  The piv field lends itself to having some bits masked off with "MSB"
  MO and "LSB" CDA.  This SCHC description could be useful in
  applications where the message frequency is low such as LPWAN
  technologies.  Note that compressing the sequence numbers may reduce
  the maximum number of sequence numbers used in an exchange.  Once the
  sequence number exceeds the maximum value, the OSCORE keys need to be
  re-established.

nit: s/maximum number of sequence numbers used in an exchange/maximum
number of sequence numbers that can be used in an exchange/

Section 9

The change to say that "when using another layer two, integrity
protection is mandatory" is enough to address my discuss point, but the
section as a whole is still fairly inscrutable in general.  If it's
useful, here's my take on how it could be written -- feel free to ignore
or take whichever parts you do/don't want.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

The use of SCHC header compression for CoAP header fields only affects
the representation of the header information.  SCHC header compression
itself does not increase or decrease the overall level of security of
the communication.  When the connection does not use a security protocol
(such as OSCORE, DTLS, etc.), it is necessary to use a layer-two
security mechanism to protect the SCHC messages.

If LPWAN is the layer-two technology, the SCHC security considerations
of [RFC8724] continue to apply.  When using another layer-two protocol,
use of a cryptographic integrity-protection mechanisms to protect the
SCHC headers is REQUIRED.  Such cryptographic integrity protection is
necessary in order to continue to provide the properties that [RFC8724]
relies upon.

When SCHC is used with OSCORE, the security considerations of [RFC8613]
continue to apply.

When SCHC is used with the OSCORE outer headers, the Initialization
Vector (IV) size in the Compression Residue must be carefully selected.
There is a tradeoff between compression efficiency (with a longer "MSB"
MO prefix) and the frequency at which the Device must renew its key
material (in order to prevent the IV from expanding to an uncompressable
value).  The key renewal operation itself requires several message
exchanges and requires energy-intensive computation, but the optimal
tradeoff will depend on the specifics of the device and expected usage
patterns.

If an attacker can introduce a corrupted SCHC-compressed packet onto a
link, DoS attacks are possible by causing excessive resource consumption
at the decompressor.  However, an attacker able to inject packets at the
link layer is also capable of other, potentially more damaging, attacks.

SCHC compression emits variable-length Compression Residues for some
CoAP fields.  In the compressed header representation, the length field
that is sent is not the length of the original header field but rather
the length of the Compression Residue that is being transmitted.  If a
corrupted packet arrives at the decompressor with a longer or shorter
length than the original compressed representation possessed, the SCHC
decompression procedures will detect an error and drop the packet.

SCHC header compression rules MUST remain tightly coupled between
compressor and decompressor.  If the compression rules get out of sync,
a Compression Residue might be decompressed differently at the receiver
than the initial message submitted to compression procedures.
Accordingly, any time the context Rules are updated on an OSCORE
endpoint, that endpoint MUST trigger OSCORE key re-establishment.
Similar procedures may be appropriate to signal Rule udpates when other
message-protection mechanisms are in use.

[Ballot discuss]
This point from my previous review does not seem to be addressed:

While the expanded security considerations do cover several important
points, I think it's important to specifically state that the RFC 8724
procedures assume that SCHC is implemented on top of LPWAN technologies
that implement security mechanisms.  I think we also need to specify
that either (a) this assumption remains for the CoAP usage of SCHC, or
that (b) CoAP has use cases outside of LPWAN, and when SCHC is used in
those non-LPWAN cases, the attacks (such as are now described in the
-15) are more readily performed than in the secure LPWAN environment
when no other integrity protection mechanism is in place for the
compressed packets.

I'm also still a bit confused by the examples in Section 2 -- the prose
says:

  In the first example, Figure 1, a Rule compresses the complete header
  stack from IPv6 to CoAP.  In this case, SCHC C/D (Static Context
  Header Compression Compressor/Decompressor) is performed at the
  device and the application.  The host communicating with the device
  does not implement SCHC C/D.

but the figure itself shows a box for SCHC in the NGW, and does not show
such a box in the Application.  How is the figure consistent with the
quoted prose?  (The new paragraph added after the figure seems to match
up more naturally with the figure; was the paragraph before the figure
intended to be deleted?)

[Ballot comment]
A few final editorial notes/nits.

Section 1

  REST-based (Representational state transfer) services.  Although CoAP
  was designed for Low-Power Wireless Personal Area Networks (6LoWPAN),
  a CoAP header's size is still too large for LPWAN (Low Power Wide
  Area Networks) and some compression of the CoAP header is required

I confess I read this too fast the first time and thought the "6LoWPAN"
was another "LPWAN" (which would be a pretty strange thing to say,
effectively that CoAP failed at its mission).  I can't speak with
certainty one way or the other whether 6LoWPAN was the sole focus of
CoAP development, so if you can't speak with certainty either, the more
generic "constrained devices" might be a better choice.

  RuleID and some residual bits.  Thus, different Rules may correspond
  to divers protocols packets that a device expects to send or receive.

nits: s/divers protocols/diverse protocol/

  In that case, a Compression/Decompression Action (CDA) associated
  with each field give the method to compress and decompress each

nit: s/give/gives/

Section 2

  This use case needs an end-to-end context initialization between the
  device and the application and is out-of-scope of this document.

nit: s/and is out-of-scope/that is out of scope/

  In the case of several SCHC instances, as shown in Figure 3 and
  Figure 3, the rulesets may come from different provisioning domains.

Was one of the '3's supposed to be a '2'?

Section 3.1

  o  The CoAP protocol is asymmetric; the headers are different for a
      request or a response.  For example, the URI-Path option is
      mandatory in the request, and it may not be present in the
      response.  A request may contain an Accept option, and the
      response may include a Content-Format option.  [...]

I'd suggest to replace all the "may"s with "might"s, but that's mostly
editorial.  ("Might" is much less likely to be misread as granting
permission as opposed to indicating a possibility.)

Section 7.3

nitty nit: Figures 18 and 21 list the FL for CoAP Token as just "tkl",
but "tkl" measures bytes and FL measures bits, so in some sense it is
off by a factor of 8.  (Indicating this while still fitting in the table
width seems nearly impossible, though.  Perhaps just some prose to
relate TKL to tkl would be enough.)

Section 9

My previous comments on the security considerations section do not
appear to have been acted upon; I believe they remain relevant and will
duplicate them here:

The need for additional English review is particularly pronounced in the
new text here.  (I am not attempting to note all instances that would
benefit from extra attention.)

  DoS attacks are possible if an intruder can introduce a compressed
  SCHC corrupted packet onto the link and cause a compression

nit: I think this would be "introduce a corrupted SCHC compressed
packet".

  efficiency reduction.  However, an intruder having the ability to add

Usually I think of "compression efficiency" as relating to the ratio of
sizes between compressed and uncompressed form.  What seems to be
described here is instead the resource efficiency of the entity
performing the decompression function, so I'd suggest using a different
phrasing, such as "excessive resource consumption at the decompressor".

  SCHC compression returns variable-length Residues for some CoAP
  fields.  In the compressed header, the length sent is not the
  original header field length but the length of the Residue.  So if a
  corrupted packet comes to the decompressor with a longer or shorter
  length than the one in the original header, SCHC decompression will
  detect an error and drops the packet.

I don't think I understand the mechanism being described here.  It
sounds as if there is supposed to be some error-checking ability between
the recovered (uncompressed) text and the original header, but I don't
see such a mechanism.  The length in the compressed packet is used to
interpret the residue and produce the recovered (uncompressed) value,
but the original packet is not available for comparison at that time.
If the length in the compressed packet is modified, then the
decompressor will get desychronized from the bit stream and start trying
to parse "random" data as the rest of the packet; that would be expected
to usually produce an error eventually, but I'm not convinced that this
is the mechanism referred to by "detect an error and drops [sic] the
packet".

The secdir review of the -15 made some good points and suggestions,
including pointing out in the security considerations that the typical
compression attacks we worry about aren't an issue here (and why).

[Ballot comment]
Thanks for this document.  A couple of minor comments:

1.  Introduction

  SCHC is a general mechanism that can be applied to different
  protocols, the exact Rules to be used depend on the protocol and the
  application.  The section 10 of the [rfc8724] describes the
  compression scheme for IPv6 and UDP headers.  This document targets
  the CoAP header compression using SCHC.

So what does this document actually define?

I read it as providing a mix of constraints that apply when encoding some CoAP fields in SDHC rules, and in other cases it provides guidance on how CoAP fields can be encoded in SDHC rules.  Is my understanding correct?  If so, a bit of text at the end of the introduction might be helpful.

Related to this, I note that some of the sub-sections in section 5 make use of RFC 2119 language and others don't.  Possibly the document would be more internally consistent if all the sub-sections in section 5 used 2119 language.


    2.  Applying SCHC to CoAP headers

    In the second example, Figure 2, ...  This use case realizes an End-to-
      End context initialization between the sender and the receiver and is
      out-of-scope of this document.
   
    ...
   
    This document focuses on CoAP compression represented in
    the dashed boxes in the previous figures.
   
These two comments seem to conflict with each other as to whether the second use case is covered or not?

    7.3.  Example OSCORE Compression

    Plaintext can be compressed up to only 1 byte (size of the RuleID).

"compressed down" would read better than "compressed up"

Thanks,
Rob

[Ballot comment]
Thanks for addressing Alexey's and Francesca's earlier DISCUSS positions.

Abstract:

OLD:
  This draft defines the way Static Context Header Compression (SCHC)
  header compression can be applied to the Constrained Application
  Protocol (CoAP). [...]
NEW:
  This draft defines the way Static Context Header Compression (SCHC)
  can be applied to the Constrained Application Protocol (CoAP). [...]

Generally, "SCHC header compression" everywhere beyond the Abstract seems redundant to me and can be replaced with just "SCHC".

Section 1:

* The text here introduces several terms with curious capitalization, such as "End-to-End" and "Rules".  If they have special meaning, they should be explicitly defined somewhere, otherwise I suggest just leaving them all lowercase.

* "... some bits to be sent, these values are ..." -- comma splice; start a new sentence here

* "... applied to different protocols, the exact Rules to be used ..." -- same

Section 2:

* "... defined in [rfc8724] document." -- remove "document"

Section 3.1:

* "The field Code have as well the same behavior, the 0.0X code format value in the request and Y.ZZ code format in the response." -- I'm afraid I don't understand this.

Section 4.3:

* "The code field indicates the Request Method used in CoAP, a IANA registry [rfc7252]." -- I can't parse this.  Does that mean the code field's possible values are listed in an IANA registry?  Which one?

Section 4.4:

* "... and the Least Significant Bits (LSB) CDA, see section ..." -- the stuff after the comma should be parenthesized instead; there are several instances of this in the document

[Ballot comment]
Abstract:

OLD:
  This draft defines the way Static Context Header Compression (SCHC)
  header compression can be applied to the Constrained Application
  Protocol (CoAP). [...]
NEW:
  This draft defines the way Static Context Header Compression (SCHC)
  can be applied to the Constrained Application Protocol (CoAP). [...]

Generally, "SCHC header compression" everywhere beyond the Abstract seems redundant to me and can be replaced with just "SCHC".

Section 1:

* The text here introduces several terms with curious capitalization, such as "End-to-End" and "Rules".  If they have special meaning, they should be explicitly defined somewhere, otherwise I suggest just leaving them all lowercase.

* "... some bits to be sent, these values are ..." -- comma splice; start a new sentence here

* "... applied to different protocols, the exact Rules to be used ..." -- same

Section 2:

* "... defined in [rfc8724] document." -- remove "document"

Section 3.1:

* "The field Code have as well the same behavior, the 0.0X code format value in the request and Y.ZZ code format in the response." -- I'm afraid I don't understand this.

Section 4.3:

* "The code field indicates the Request Method used in CoAP, a IANA registry [rfc7252]." -- I can't parse this.  Does that mean the code field's possible values are listed in an IANA registry?  Which one?

Section 4.4:

* "... and the Least Significant Bits (LSB) CDA, see section ..." -- the stuff after the comma should be parenthesized instead; there are several instances of this in the document

[Ballot comment]
[[ comments ]]

[ section 1 ]

* "interop" -> "inter-operate"

[ section 2 ]

* "The host ... do not implement" -> "does not implement"

* Figure 2: "ene-to-end" -> "end-to-end"

* "and that they do not include" -> "and they do not include"

[ section 4.3 ]

* "cannot be compressed an the value" -> "cannot be compressed and the value"

[ section 5.0 ]

* "these assymetry" -> "this asymmetry"

[ section 5.3 ]

* "are a repeatable options" -> "are repeatable options"

[ section 9 ]

* "decompression will detect an error and drops the packet" ->
  "decompression will detect an error and drop the packet"

[Ballot comment]
Being new to both CoAP and SCHC, I found parts of this draft extremely tough going. Thanks very much for the examples; I would have been totally lost without them. I trust that my comments here are mostly due to limited understanding, rather than some deeper issue...

Sec 1. I cannot parse this sentence at all: "CoAP is an End-to-End protocol at the application level, so CoAP
  compression requires to install common Rules between two hosts and IP
  Routing may be needed to allow End-to-End communication."

What are you trying to say here?

Sec 2. I do not understand the symbolism of these figures.

- What are the many parentheses and dashed lines at the bottom of each one?

- I take it that the "SCHC" box implies that everything above it is header-compressed, up until it hits another "SCHC?" IIUC SCHC compresses one or two layers in the stack, rather than being a layer below.

- Finally, the explanation of dashed boxes vs dotted boxes is at the very end of the section. Please move it to before the first figure.

Sec 3. Expand "TV" on first use.

Sec 4.5. "  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 Compression Residue."

After looking through the example, I think this means that because the Token Length is being repurposed, it is not available to define variable token lengths. Maybe switch the order of the sentences. It seems like the first flows from the second. In addition, for Token Value not to be sent as variable length, that imposes constraints on the rule set, right? It would be good to clarify exactly what a rule set must do to create this outcome.

Sec.5. s/these assmetry/this asymmetry

[Ballot discuss]
I don't think we quite managed to catch all the collatoral damage from
my previous discuss points on the -13.  In particular, while Sections
5.x no longer attempt to discuss directionality of CoAP Options, there
are some in-passing references to them in Section 3.1:

- There's a claim that URI-Path (though, spelled as "URI-path") is not
  present in the response, which is incorrect.

- There's a reference to a nonexistent "Content" option as being present
  only in a response, but the "Content-Format" option is allowed in both
  requests and responses.  (See, e.g., the PUT method for use of
  Content-Format in a request.)

- The "Accept" option is referenced as only being present in requests.
  This seems to be accurate as far as I can see in RFC 7252, though in
  light of the near-complete removal of such references from this
  document, perhaps it should also be removed.

While the expanded security considerations do cover several important
points, I think it's important to specifically state that the RFC 8724
procedures assume that SCHC is implemented on top of LPWAN technologies
that implement security mechanisms.  I think we also need to specify
that either (a) this assumption remains for the CoAP usage of SCHC, or
that (b) CoAP has use cases outside of LPWAN, and when SCHC is used in
those non-LPWAN cases, the attacks (such as are now described in the
-15) are more readily performed than in the secure LPWAN environment
when no other integrity protection mechanism is in place for the
compressed packets.

As Francesca noted on the -13, we need to acknowledge that there are and
will be in the future CoAP options that are not included in this
document and provide some indication of how they might be handled.
Whether that's to define new compression rules/guidance for them, always
send them as full residuals, or some other behavior can be decided in
the future on a per-option basis, but we can give some guidance here on
how we plan to support extensibility of options.

---

The -15 introduced some new text in the Introduction:

  CoAP is an End-to-End protocol at the application level, so CoAP
  compression requires to install common Rules between two hosts and IP

It's not entirely clear to me that this is true, given that CoAP proxies
are a first-class protocol feature.  OSCORE is probably fair to describe
as end-to-end, but CoAP itself may not be.

Also, the new examples in Section 2 are sufficiently hard to follow that
I can't be sure the figures and the prose descriptions are internally
consistent.  (See COMMENT for a few more specifics.)

[Ballot comment]
Thank you for the updates in response to my comments on the -13; they do
help.  I have a smaller volume of comments this time around :)

Abstract

References are not allowed in the abstract, so you should probably just
write out "RFC 8724".

Introduction

  CoAP [rfc7252] is designed to easily interop with HTTP (Hypertext

What does "designed to easily interop with" mean?  CoAP and HTTP don't
interoperate directly, given that they are different protocols...

  done.  The context is known by both ends before transmission.  The
  way the context is configured, provisioned or exchanged is out of the
  scope of this document.

(editorial) I'd suggest rephrasing to something more like "The SCHC
compression scheme assumes as a prerequisite that the static context is
known to both endpoints before transmission."

  CoAP is an End-to-End protocol at the application level, so CoAP
  compression requires to install common Rules between two hosts and IP
  Routing may be needed to allow End-to-End communication.  Therefore,
  SCHC compression may apply at two different levels, one to compress
  IP and UDP as described in [rfc8724] in the LPWAN network and another
  at the application level.  These two compressions may be independent.

I think you want to reframe this in terms of the potential for there to
be multiple IP (UDP seems perhaps less likely?) entities processing the
packet between CoAP entities that process the packet, and note that the
IP compression may be removed by an intermediary in situations where
configured to do so.

  The Compression Rules can be set up by two independent entities and
  are out of the scope of this document.  In both cases, SCHC mechanism
  remains the same.

(nit) I don't think "remains the same" is the best wording here; there
are clearly going to be differences of some form between compression at
the UDP layer and compression at the CoAP layer, even though the overall
structure/procedures for compressing/decompressing at those layers are
analogous to each other.

  A Matching Operator (MO) is associated to each header field
  description.  The Rule is selected if all the MOs fit the TVs for all
  fields of the incoming header.

I strongly suggest reiterating that the presence of a header field that
does not have a corresponding MO in the Rule means that the Rule does
not apply to that packet.

  After applying the compression there may be some bits to be sent,
  these values are called Compression Residues.

nit: comma splice.

Section 2

I think that these examples would benefit from a fair bit more
description/discussion text.  For example, if SCHC in Figure 1 is
supposed to be compressing everything from IPv6 to CoAP, why is SCHC
beween LPWAN and IPv6 (vs above IPv6), and why does the full stack still
appear at the 'device'?  If the Sender and Receiver are to be the device
and App, then why is SCHC not apparent at the Receiver (app)?  I can't
find a consistent way to interpret the text and the figure.
(Figures 2 and 3 have both dotted lines and dashed lines.  Why are they
different?  Etc.)

Section 3.1

  o  The CoAP protocol is asymmetric, the headers are different for a
      request or a response.  For example, the URI-path option is

nit: comma splice.

  o  Headers in IPv6 and UDP have a fixed size.  The size is not sent
      as part of the Compression Residue, but is defined in the Rule.
      Some CoAP header fields have variable lengths, so the length is
      also specified in the Field Description.  For example, the Token

RFC 8724 uses "Field Descriptor", not "Field Description".

Section 5

  the description of the Option by using in the Field ID the Option
  Number built from D-T; in TV, the Option Value; and the Option Length
  uses section 7.4 of RFC8724.  When the Option Length has a wellknown

(It looks like the subsections of 7.4 are also important, though we
probably don't need to literally say "section 7.4 and subsections".)

Section 5.2

I'm still confused why Max-Age, Uri-Host, and Uri-Port are in the same
section.  We talk about "the duration", but that seems to only apply to
Max-Age.

  Otherwise these options can be sent as a Compression Residue (fixed
  or variable length).

I'm not sure that there's going to be a practical scenario where a
fixed-length residue is workable for anay of these three CoAP Options.

Section 5.4

As far as I can tell, Proxy-URI and Proxy-Scheme are indeed
unidirectional (only sent in requests).  It would perhaps be appropriate
to codify this restirction in the compression rules, though I can
understand if the general desire is to not add an additional layer of
restrictions beyond the core CoAP specificiation.

Section 6.2

  Since an RST message may be sent to inform a server that the client
  does not require Observe response, a Rule MUST allow the transmission
  of this message.

Is this saying that if you have a rule that allows sending Observe, you
MUST also have a rule allowing RST?  It might be worth making that more
explicit.

Section 6.4

  The first byte specifies the content of the OSCORE options using
  flags.  The three most significant bits of this byte are reserved and

nit: s/options/option/.

  This specification recommends identifying the OSCORE Option and the
  fields it contains Conceptually, it discerns up to 4 distinct pieces
  of information within the OSCORE option: the flag bits, the piv, the

I'm not sure what was intended to happen here.  Either there's a missing
full stop or a wrongly capitalized word, at a start, but perhaps there
was also supposed to be some additional rewording to join the sentences
together more fluidly.

  The OSCORE Option shows superimposed these four fields using the
  format Figure 6, the CoAP OSCORE_kidctxt field includes the size bits
  s.

The rewording went awry here.  I think it's supposed to be more like
"Figure 6 shows the OSCORE Option format with those four fields
superimposed on it.  Note that the CoAP OSCORE_kidctxt field includes
the size octet s".

(Also, I am not sure I've seen the "ctxt" abbreviation anywhere other
than this document.  Just "ctx" seems much more common in my
experience.)

Section 7.1

  immediately acknowledged by the Device.  For this simple scenario,
  the Rules are described Figure 7.

nit: "described in".

Section 9

The need for additional English review is particularly pronounced in the
new text here.  (I am not attempting to note all instances that would
benefit from extra attention.)

  DoS attacks are possible if an intruder can introduce a compressed
  SCHC corrupted packet onto the link and cause a compression

nit: I think this would be "introduce a corrupted SCHC compressed
packet".

  efficiency reduction.  However, an intruder having the ability to add

Usually I think of "compression efficiency" as relating to the ratio of
sizes between compressed and uncompressed form.  What seems to be
described here is instead the resource efficiency of the entity
performing the decompression function, so I'd suggest using a different
phrasing, such as "excessive resource consumption at the decompressor".

  SCHC compression returns variable-length Residues for some CoAP
  fields.  In the compressed header, the length sent is not the
  original header field length but the length of the Residue.  So if a
  corrupted packet comes to the decompressor with a longer or shorter
  length than the one in the original header, SCHC decompression will
  detect an error and drops the packet.

I don't think I understand the mechanism being described here.  It
sounds as if there is supposed to be some error-checking ability between
the recovered (uncompressed) text and the original header, but I don't
see such a mechanism.  The length in the compressed packet is used to
interpret the residue and produce the recovered (uncompressed) value,
but the original packet is not available for comparison at that time.
If the length in the compressed packet is modified, then the
decompressor will get desychronized from the bit stream and start trying
to parse "random" data as the rest of the packet; that would be expected
to usually produce an error eventually, but I'm not convinced that this
is the mechanism referred to by "detect an error and drops [sic] the
packet".

The secdir review of the -15 made some good points and suggestions,
including pointing out in the security considerations that the typical
compression attacks we worry about aren't an issue here (and why).

[Ballot comment]
Thank you for addressing my COMMENTs raised in March 2020 and thank you for also addressing other DISCUSS and COMMENT from the March 2020 IEGS evaluation.

Regards

-éric

[Ballot 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 .
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.

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

[Ballot discuss]
Reviewing this document and its application to compress case two and three stacks in Figure 1, i.e. with some end-to-end encryption appears to significantly change an assumption from the SCHC for IPv6/UDP. Namely, the assumption about context establishment. In normal SCHC the contexts are established between the Device and the NGW. In these end-to-end encrypted case the context establishing party for the COAP compression is the APP and the APP layer in the device. This difference appear completely ignored in this document. I think this is a significant difference as having the device and NGW run a protocol for establishing context over the L2 or L3 with the local context knowledge is fairly straightforward. However, in this case when the COAP peer on the internet side of the NGW this determination and configuration is a different matter.

From my perspective some more discussion of the fact that this is a different context and that it have different challenges in establishing the context should be made clear in the document.

[Ballot comment]
I would also note that the TSV-ART review did find an issue with the an underlying assumption in draft-ietf-lpwan-ipv6-static-context-hc which is not yet published. The issue is that the assumption that the UDP length field is redundant will not be true when https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/ gets approved. Thus the question arises if this assumption should be amended or not in the underlying technology. I note this here primarily so that it is discussed by the WG and the responsible AD.

[Ballot comment]
The TSV-ART review flagged a problem with draft-ietf-lpwan-ipv6-static-context-hc (Thanks Joe) which is a normative dependency but is already in RFC editor state. Ben also already captured this in his ballot. I also think it would be important to address this problem before final publication (of both docs) and the TSV ADs will coordinate with the INT ADs on this.

Minor comment:
Sec 7.3:
"  The Outer SCHC Rules (Figure 16) MUST process the OSCORE Options
  fields. "
The example section should probably not have normative language.

[Ballot comment]
Thank you for the work put into this document. With the heavy load on this week telechat and all meetings related to the cancellation of the IETF-107 in-person meeting, I must admit that this review was not as thorough as I would hope :-(

I am also trusting the ART AD for their review of the CoAP protocol compression.

Please find below some non-blocking COMMENTs and NITs.
Regards,

-éric

== COMMENTS ==
I support Barry's COMMENT on the section 1.

-- Section 2 --
Would benefit from a clear explanation of the "Sender" and "Receiver" probably in the terminology section.

== NITS ==
In many places, the acronyms are followed by their expansions, I recommend to use the other way: expansion (acronym)

-- section 1 --
Fix the bullet list that appears broken in the text "one of 4 actions:..."

-- Section 3.1 --
Same as above for "applying the CDA:..."

[Ballot comment]
This first item is almost a DISCUSS, but as I'm sure it's not a controversial point and just an editorial thing that will get fixed, I'm just putting it down here.

— Section 1 —

  CoAP [rfc7252] is a transfer protocol that implements a subset of
  HTTP (Hypertext Transfer Protocol) and is optimized for REST-based
  (Representational state transfer) services.

Important: this statement is not true.  CoAP is not a subset of HTTP, and nowhere does CoAP claim that.  You might instead combine some of these statements from the CoAP spec:

  CoAP is designed to easily interface with HTTP
  for integration with the Web while meeting specialized requirements
  such as multicast support, very low overhead, and simplicity for
  constrained environments.

  One of the main goals of CoAP is to design a generic web protocol for
  the special requirements of this constrained environment

  The goal of CoAP is not to blindly compress HTTP,
  but rather to realize a subset of REST common with HTTP
  but optimized for M2M applications.

However you fix this, please do fix it.

— Section 3 —
It appears as if a different author wrote this, compared with the earlier text.  I’m not calling out every issue, in the interest of review time, but am only citing some examples.  In general, it would be good to have someone go through and edit this sections 3 and 3.1 for clarity.  If you wait for the RFC Editor staff to do it, we could end up with errors that we miss catching, because they don’t have the technical background in this topic.

  SCHC with CoAP will be used exactly the same way as it is applied in
  any protocol as IP or UDP with the difference that the fields
  description needs to be defined based on both headers and target
  values of the request and the responses.  SCHC Rules description use
  the direction information to optmize the compression by reducing the
  number of Rules needed to compress traffic.

I’ve tried several times to understand the first sentence, and I can’t.  It isn’t parseable, and I don’t know what you’re trying to say.  The second sentence also needs work to make it readable.  Can you please try to reword these?

— Section 3.1 —
The title and the first sentence stopped me for a bit: why would you be comparing CoAP with IPv6?  You should be clear right up front that you’re talking about differences in compressing CoAP compared with compressing the other protocols, to explain why there’s a difference in how the compression works.  Please say that at the start.  (Perhaps that’s part of what you tried to say in Section 3, which I didn’t understand?)

  o  In IPv6 and UDP, header fields have a fixed size, defined in the
      Rule, which is not sent.

The Rule is not sent?  Or do you mean the size is not sent?  I think you want to say something like, “Header fields in IPv6 and UDP have fixed sizes.  The size is not sent as part of the header, but is defined in the Rule.”

      In CoAP, some fields in the header have
      a variable length, for example the Token size may vary from 0 to 8
      bytes, the length is given by a field in the header.

Sentences like this are actually multiple sentences glued together, and are hard to read.  In this example, I suggest this: “Some CoAP header fields have variable lengths, so the length is also specified in a header field.  For example, the Token field can vary from 0 to 8 bytes in length.”

— Section 4.5 —

  Token Value MUST not be sent as a variable length residue

Make it “MUST NOT”.

[Ballot comment]
I support Roman's and Benjamin's DISCUSS positions about the security considerations. The Gen-ART reviewer raised concerns about this as well that have not been fully addressed.

[Ballot discuss]
**  Section 9. (as Paul Wouters mentioned in his SECDIR review, thanks Paul!) Per “This document does not have any more Security consideration than the ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]”, this reference in Section 12 (Security Considerations) contains the statement that “SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures.”, this assumption doesn't necessarily seem valid here?  What are the implications?

** Section 9.  Per “The size of the Initialisation Vector residue size must be considered carefully. A too large value has a impact on the compression efficiency and a too small value will force the device to renew its key more often.”, can you be a bit clearer on the tradeoff:

-- how small is still acceptable given the security properties that still need to be preserved in the AEAD nonce?

-- Given a particular smaller size, what factors would would influence more frequent key renewal?

[Ballot discuss]
**  Section 9. (as Paul Wouters mentioned in his SECDIR review, thanks Paul!) Per “This document does not have any more Security consideration than the ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc]”, this reference in Section 12 (Security Considerations) contains the statement that “SCHC is expected to be implemented on top of LPWAN technologies, which are expected to implement security measures.”, is that assumption valid here?  If it is not, what are the implications?

** Section 9.  Per “The size of the Initialisation Vector residue size must be considered carefully. A too large value has a impact on the compression efficiency and a too small value will force the device to renew its key more often.”, can you be a bit clearer on the tradeoff:

-- how small is still acceptable given the security properties that still need to be preserved in the AEAD nonce?

-- Given a particular smaller size, what factors would would influence more frequent key renewal?

[Ballot comment]
I support Ben Kaduk's DISCUSS position.

** Section 9.  Does it make sense to: s/the packet must be dropped by the decompressor/the packet MUST be dropped by the decompressor/?

** Editorial Nits:
-- Section 3.1. s/knwoledge/knowledge/
-- Section 3. Typo. s/optmize/optimize/

[Ballot discuss]
Section 5.2 claims that Uri-Host and URI-Port are unidirectional from
server to client and "[are] never found in client requests", which seems
to contradict Section 5.10.1 of RFC 7252.  It seems like maybe this
section is supposed to only cover Max-Age, with Uri-Host and Uri-Port
rolled into Section 5.3 along with Uri-Path and Uri-Query?

Similarly, Section 5.4 says that size1 and size2 are unidirectional
(only in requests), which does not seem to be accurate given my reading
of RFCs 7252 and 7599.

I also think that we need some further discussion (e.g., in the security
considerations) about how the base LPWAN SCHC document assumes that
MAC-layer LPWAN security mechanisms are in use, but that CoAP is not
restricted to such contexts.  What additional security considerations
are relevant when this compression is used for CoAP without LPWAN
MAC-layer cryptographic protection?

Perhaps not really a Discuss on this document, but what is the planned
disposition of the tsv-art reviewer's comments regarding
draft-ietf-lpwan-ipv6-static-context-hc and UDP Options?  I did not see
anything pertinent in the mailarchive.

[Ballot comment]
Please respond to the secdir review; I don't trust my own response to be
a comprehensive one that addresses all the raised potential issues.

This document is targeting Proposed Standard status, but in some sense
it's not clear that it is specifying a protocol per se, as opposed to
illustrating a set of choices that can be made for applying the SCHC
technique to CoAP messages.  These choices are expected to be generally
useful, but since the SCHC rules must be preagreed by all entities in
advance, there's not really anything to prevent a deployment from using
a modified version of these procedures, in terms of lost
interoperability.  In addition, the shepherd writeup mentions that there
may be some desire to do a refresh in the future, after more
implementation experience is gained.  So I don't have a great sense as
to which parts of this document are better as Proposed Standard vs.
Informational.

Abstract

  This draft defines the way SCHC (Static Context Header Compression)
  header compression can be applied to the CoAP protocol.  SCHC is a
  header compression mechanism adapted for constrained devices.  SCHC

Is it also in some sense a key requirement that these constrained
devices produce a fairly consistent or deterministic class of output?

Section 1

  SCHC compresses and decompresses headers based on shared contexts
  between devices.  Each context consists of multiple Rules.  Each rule
  can match header fields and specific values or ranges of values.  If
  a rule matches, the matched header fields are substituted by the rule
  ID and optionally some residual bits.  Thus, different Rules may

Do I remember corectly that an SCHC rule matching implies that the
entire header structure matches (i.e., there are no fields in the header
not listed in the rule)?  If so, perhaps a slight rephrasing to "If a
packet header fully matches a rule" would be helpful.

  Compression mainly results in one of 4 actions: * send the field
  value, * send nothing, * send some least significant bits of the
  field or * send an index.  After applying the compression there may
  be some bits to be sent, these values are called Compression
  Residues.

[It looks like this is generated from Markdown and needs additional
blank lines between bullet points]

  SCHC is a general concept mechanism that can be applied to different

nit: "concept" is a noun, not an adjective, so this doesn't parse
properly.

  protocols, the exact Rules to be used depend on the protocol and the
  application, and CoAP differs from UDP and IPv6, see Section 3.

nit: comma splice ("the exact rules [...]" is a complete sentence).

Section 2

  In the third example, OSCORE [rfc8613] is used.  In this case, two
  rulesets are used to compress the CoAP message.  A first ruleset
  focused on the inner header and is applied end to end by both ends.
  A second ruleset compresses the outer header and the layers below and
  is done between the Sender and the Receiver.

Is it worth having a parllel style and mentioning that the outer
compression can be modified hop by hop (in contrast to the inner
end-to-end compression)?

Section 3

  SCHC with CoAP will be used exactly the same way as it is applied in
  any protocol as IP or UDP with the difference that the fields
  description needs to be defined based on both headers and target
  values of the request and the responses.  SCHC Rules description use

If there's a difference, it's not "exactly the same".

Section 3.1

      return path (e.g. source and destination addresses fields).  The
      CoAP headers instead are asymmetric, the headers are different for
      a request or a response.  For example, the URI-path option is

nit: comma splice

  o  Even when a field is "symmetric" (i.e. found in both directions)
      the values carried in each direction are different.  To performs
      the compression a matching list in the TV might be use because

nit: "used".

      field two cases may be raised after applying the CDA: * The result
      of the compression is of fixed length and the compressed value is
      sent in the residue.  * Or the result of the compression is of
      variable-length and in this case, the size is sent with the
      compressed value in the residue.

[another presumed-markdown list, though this one might be easier to
reformat just as running text, since there are only two options]

  o  In CoAP headers, a field can appear several times.  This is
      typical for elements of a URI (path or queries).  The SCHC
      specification [I-D.ietf-lpwan-ipv6-static-context-hc] allows a
      Field ID to appears several times in the rule, and uses the Field
      Position (FP) to identify the correct instance, and thereby
      removing the ambiguity of the matching operation.

draft-ietf-lpwan-ipv6-static-context-hc notes that there can be issues
when using a FP of zero for "don't care"; perhaps it's worth noting that
these issues are pretty certain to occur for URI-path?

  o  Field sizes defined in the CoAP protocol can be too large
      regarding LPWAN traffic constraints.  This is particularly true
      for the Message ID field and the Token field.  SCHC uses different
      Matching operators (MO) to performs the compression, see section
      7.4 of [I-D.ietf-lpwan-ipv6-static-context-hc].  In this case the
      Most Significant Bits (MSB) MO can be applied to reduce the
      information carried on LP

This text was a bit hard for me to unwind, especially "field sizes [...]
too large regarding LPWAN traffic constraints".  At first I thought it
was saying that CoAP fields were problematic for SCHC (though I can no
longer see why I would think that), and then that the "length" of
various length+value encodings in CoAP allowed me to pick a length that
would be problematic for LPWAN, before arriving to my current conclusion
that it's just saying "some fields in CoAP are large and will only take
on a narrow range of values in a LPWAN context, providing a lot of
static bits that can be compressed using the MSB MO".  In essence, I
don't know that the "regarding LPWAN traffic constraints" is the most
effective language to use; emphasizing that the fields are large and
mostly unchanging, and that LPWAN needs to care about those wasted bits,
seems to be the important part.

Section 4.3

  If the device only implements a CoAP client, the request code can be
  reduced to the set of requests the client is able to process.

nit(?): "process" or "produce"?

  A mapping list can be used for known values, for other values the
  field cannot be compressed an the value needs to be sent in the
  residue.

nit: s/an/and/

Section 4.4

It seems like some guidance is in order about choosing how many bits to
compress, based on the frequency of traffic generated,
EXCHANGE_LIFETIME, and any other factors used to pick a message ID range
for a given device.

Section 4.5

  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.
  [...]
  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.

I'm not sure I understand how these two parts fit together.  I
understand that CoAP places a tight binding betwen the TKL value and the
length of the token field, and so if SCHC tried to treat them
differently we could break a CoAP invariant (this seems to be the
"ambiguity" that we seek to avoid, per the trimmed quote).  But the last
part seems to say that the TKL function to give the actual token length
is part of the Rule, and the former part says that if the CoAP Token
Length is variable, it will be sent in the compression residue -- if the
Token Length is a compression residue then that seems to imply that it
is not fixed by the Rule, and thus I'm not sure what the procedure is
supposed to be with this "TKL function".  Furthermore, I don't see
specification of the TKL function later in the document.  I guess it's
supposed to take as input information from the Rule's definition and the
token length residue in order to output the length of the transmitted
token residue, but that does not seem very clearly spelled out.  (Also,
I'm not sure whether the token residue would necessarily be the entire
token or the rule could allow some prefix to be compressed...)

Section 5

Would it be appropriate to give some guidance about who will have to do
what in order to cope with new CoAP Options defined in the future?

I'm also not sure that there's much rhetorical benefit in trying to
distinguish between Options defined in the core CoAP spec and subsequent
additions Section 5 vs. Section 6); they seem to be functionally the
same from an implementor's point of view.  (Well, maybe not OSCORE.)

There are also a few of Options in the current registry that are not
given any treatment here (whether in Section 5 or Section 6); should we
mention that?  (Hop-Limit, OCF-*, ...)

Section 5.1

I see only "Content-Format" and "Accept" Options defined in RFC 7252, but
no "Content" option.

  used to limit the size of the residue.  Otherwise, the value has to
  be sent as a residue (fixed or variable length).

The content format is an integer in the range 0-65535, and if we don't
know enough about what can be used to have a match-list, how can we make
assumptions about a variable-length residue being better than a
fixed-length one?

Section 5.3

[Perhaps the interaction between FP and Uri-Path that I mentioned above
could be discussed here instead.]

This specification of the regrouping operation and the table in the
figure seem a bit in need of further clarification.  Perhaps "Even
though there are two distinct URI-Path fields to match, the target
values for all regrouped path components are consolidated into a single
logical "target value" (with the appropriate number of path components)
to be matched.  The components of the target value must individually
match with the URI-Path field values in the indicated field positions.
Note specifically that the FP values, as indicated in the example, are
not required to be consecutive values; in this case the path components
in the target value are a matter of convenience and would have
additional components inserted in order to match the actual resource
path in question.  For the subsequent Uri-Path fields in the rule, no
target value is given and the match operation is listed as "ignore" for
convenience; the actual matching has occured on the grouped value listed
in the first field's entry."  (I'm not sure why the CDA is listed as
"value-sent" for FP 3 in the example, though.)

Section 5.3.2

  be created to cover all the possibilities.  Another possibility is to
  define the length of Uri-Path to variable and send a compression
  residue with a length of 0 to indicate that this Uri-Path is empty.

I'm not sure I understand this proposal.  Is it to say that you could
have a single rule that lists the maximum expected number of path
components, and then use "empty component"s to represent the compressed
form of shorter paths?  It seems like this still has a hard cap on the
number of path components that could be represented by a given Rule,
which would be a significant limitation and needs to be called out.

Section 5.4

  [I-D.ietf-lpwan-ipv6-static-context-hc].  They are used only by the
  client to access a specific resource and are never found in server
  response.

nit: singular/plural mismatch "they are"/"server response"

  If the field value has to be sent, TV is not set, MO is set to
  "ignore" and CDA is set to "value-sent".  A mapping MAY also be used.

  Otherwise, the TV is set to the value, MO is set to "equal" and CDA
  is set to "not-sent".

Please reword/reformat to give equal treatment to the three options
(send full residue, mapping list, target value) in terms of the
formatting and the use of normative keywords.

Section  5.5

  These fields are unidirectional.

In which directions?

Section 6.1

I suggest using rhetoric that is consistent with the two different block
options, even though they conceptually fit together as a functional
unit.

  includes a fragmentation protocol.  They are compatible.  If a block
  option is used, its content MUST be sent as a compression residue.

Anything to say about fixed vs. variable length encoding?

Section 6.2

  Since an RST message may be sent to inform a server that the client
  does not require Observe response, a rule MUST allow the transmission
  of this message.

Is it worth assembling a consolidated table of specific rules or rule
functionality that must be present to have a functional CoAP SCHC setup
(incorporating this and the base SCHC requirements for, e.g., a rule to
capture otherwise non-matching traffic that is sent without
compression)?

Section 6.3

  Otherwise, if the value is changing over time, TV is not set, MO is
  set to "ignore" and CDA to "value-sent".  A matching list can also be
  used to reduce the size.

Similarly to my comment above, it might be nice to give parallel
rhetorical treatment to the three options.

Section 6.4

This section feels more like a sketch of how someone could implement
SCHC with OSCORE, as compared to previous Options' handling that has a
pretty well-defined procedure.

Would it be desirable, for example, to have a separate Rule for each
value of the OSCORE flags that was expected?

Section 7.2

  The Plaintext is now encrypted by an AEAD algorithm which integrity
  protects Security Context parameters and eventually any class I
  options from the Outer Header.  Currently no CoAP options are marked
  class I.  The resulting Ciphertext becomes the new Payload of the

I suggest dropping "eventually", as it will no longer make sense if/when
class-I options are defined.

  Note that since the Inner part of the message can only be decrypted
  by the corresponding end-point, this end-point will also have to
  implement Inner SCHC Compression/Decompression.

It might be worth being even more explicit that the SCHC context for the
inner and outer parts may differ as well, since they may be processed by
different entities.

Section 7.3

  The piv field lends itself to having a number of bits masked off with
  MO MSB and CDA LSB.  This could be useful in applications where the
  message frequency is low such as that found in LPWAN technologies.
  Note that compressing the sequence numbers effectively reduces the
  maximum amount of sequence numbers that can be used in an exchange.
  Once this amount is exceeded, the OSCORE keys need to be re-
  established.

Just to check: one could also allocate additional Rules to match a
different prefix, and get additional sequence number space?

  Compression residue:
  0b0001 010 (7 bits -> 1 byte with padding)
    mid  tkn

We had a space after "0b" in the request portion, which seems to aid
readibility.

  As can be seen, the difference between applying SCHC + OSCORE as
  compared to regular SCHC + COAP is about 10 bytes of cost.

I'd suggest noting that this is about what one would expect, given the
fixed and uncompressible overhead of the 8-byte tag, plus the need for
the dual compression with inner and outer contexts (each of which have
their own octet for rule ID).


IIUC additional Rule information would be needed to handle Observer
responses/updates, but it's not really clear that we need to mention
that fact in the context of this specific example.

Section 9

  This document does not have any more Security consideration than the
  ones already raised on [I-D.ietf-lpwan-ipv6-static-context-hc].

Given that we then go on to talk about more stuff, am I to conclude that
the additional discussion is merely exposition on topics already covered
in the reference (vs. new content that would make this quoted statement
invalid)?

In particular, I think there is another new security consideration worth
discussion here, relating to the interaction of compression and OSCORE.
To illustrate how this might come intoi play, consider the example in
Section 7.3, where the response can be compressed to a single byte,
since there is only one request message defined/expected by the Rules.
In such a scenario where the number of potential plantexts is extremely
small, an attacker with knowledge that SCHC is in use (and, perhaps, the
Rules in question) will have a very easy time of traffic analysis, which
to some extent will defeat the message protection that OSCORE is
intended to provide.

  Variable length residues may be used to compress URI elements.  They
  cannot produce a packet expansion either on the LPWAN network or in
  the Internet network after decompression.  The length send is not

We should probably say why ("because the static context embedded in the
Rule used for compression can only remove/replace a static, fixed-length
prefix of the URI component")

nit: s/send/sent/

  used to indicate the information that should be reconstructed at the
  other end, but on the contrary the information sent as a Residue.

nit: "on the contrary the length of the information sent as a Residue",
I think.

  OSCORE compression is also based on the same compression method
  described in [I-D.ietf-lpwan-ipv6-static-context-hc].  The size of
  the Initialisation Vector residue size must be considered carefully.

I suggest adding a note that there is a tradeoff between the efficiency
of compression and the number of protected messages that can be sent
using a given key/SCHC context; the following two sentences don't seem
as clear as they could be.  So ...

  A too large value has a impact on the compression efficiency and a
  too small value will force the device to renew its key more often.
  This operation may be long and energy consuming.

Perhaps,

% The OSCORE initialization vector holds a message sequence number, and
% a unique such number is needed for each distinct message.  The SCHC
% procedure gives compression efficiency by assuming that a fixed prefix
% of the IV remains static and eliding that fixed prefix from the
% transmitted message.  However, such compression has the corresponding
% effect of reducing the number of distinct sequence numbers available
% to the sender.  When the usable sequence number space is exhausted,
% the OSCORE security context must be rekeyed; since this rekeying can
% be an expensive operation in terms of time and energy consumption, the
% creation of SCHC Rules for OSCORE compression should take into
% consideration the tradeoff between (amortized )rekeying cost and the
% recurring transmission overhead for the uncompressed portion of the
% initialization vector.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-lpwan-coap-static-context-hc-12, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2020-02-20):

From: The IESG
To: IETF-Announce
CC: pthubert@cisco.com, draft-ietf-lpwan-coap-static-context-hc@ietf.org, Pascal Thubert , lpwan-chairs@ietf.org, lp-wan@ietf.org, suresh@kaloom.com
Reply-To: last-call@ietf.org
Sender:
Subject: Last Call:  (LPWAN Static Context Header Compression (SCHC) for CoAP) to Proposed Standard


The IESG has received a request from the IPv6 over Low Power Wide-Area
Networks WG (lpwan) to consider the following document: - 'LPWAN Static
Context Header Compression (SCHC) for CoAP'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
last-call@ietf.org mailing lists by 2020-02-20. Exceptionally, comments may
be sent to iesg@ietf.org instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract


  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols 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 document
  explains how to use the SCHC compression mechanism for CoAP.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-lpwan-coap-static-context-hc/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information:
    rfc7967: Constrained Application Protocol (CoAP) Option for No Server Response (Informational - Independent Submission Editor stream)

As required by RFC 4858, this is based on the current template for the
Document Shepherd Write-Up dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  => All is correct. We are going after a Proposed Standard.
  This document specifies the behaviour of a SCHC encoder/decoder for CoAP.
  The tracker indicates Proposed Standard and the draft Standards Track
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  =>
  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

=>
  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  =>
  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  =>
  Document Shepherd: Pascal Thubert
  Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  =>
  The shepherd considered the readability of the content and its
  form (e.g., NITs). The recommendations were applied in two
  rounds, v10 and v11.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  =>
  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  =>
  Not so. the document mostly needs exposure to the real world, and
  feedback from implementer's who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  => No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  => All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  => No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  => The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  => No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  => The nits and shepherd review items were cleaned up between
  v09 and v11. There are still alerts like on BCP14 but that's false
  positive.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  =>  No such need

(13) Have all references within this document been identified as
either normative or informative?

  => Yes. Interestingly there's no informative. The shepherd scrutinized that
  and found that all references actually qualify as normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  => The main SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc) is the
  only reference that is not RFC yet,but is more advanced than this.
  It could be nice to ship both documents with consecutive numbers
  and I'd suggest that the RFC editor reserves the number right after
  SCHC for this document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  =>  No such thing. There is no informative reference at all.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  =>  No such thing.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  => No such thing.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  => No such thing.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  => No such thing.

As required by RFC 4858, this is based on the current template for the
Document Shepherd Write-Up dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  => All is correct. We are going after a Proposed Standard.
  This document specifies the behaviour of a SCHC encoder/decoder for CoAP.
  The tracker indicates Proposed Standard and the draft Standards Track
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  =>
  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

=>
  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  =>
  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  =>
  Document Shepherd: Pascal Thubert
  Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  =>
  The shepherd considered the readability of the content and its
  form (e.g., NITs). The recommendations were applied in two
  rounds, v10 and v11.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  =>
  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  =>
  Not so. the document mostly needs exposure to the real world, and
  feedback from implementer's who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  => No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  => All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  => No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  => The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  => No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  => The nits and shepherd review items were cleaned up between
  v09 and v11. There are still alerts like on BCP14 but that's false
  positive.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  =>  No such need

(13) Have all references within this document been identified as
either normative or informative?

  => Yes. Interestingly there's no informative. The shepherd scrutinized that
  and found that all references actually qualify as normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  => The main SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc) is the
  only reference that is not RFC yet,but is more advanced than this.
  It could be nice to ship both documents with consecutive numbers
  and I'd suggest that the RFC editor reserves the number right after
  SCHC for this document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  =>  No such thing. There is no informative reference at all.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  =>  No such thing.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  => No such thing.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  => No such thing.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  => No such thing.

As required by RFC 4858, this is based on the current template for the
Document Shepherd Write-Up dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  => All is correct. We are going after a Proposed Standard.
  This document specifies the behaviour of a SCHC encoder/decoder for CoAP.
  The tracker indicates Proposed Standard and the draft Standards Track
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  =>
  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

=>
  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  =>
  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  =>
  Document Shepherd: Pascal Thubert
  Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  =>
  The shepherd considered the readability of the content and its
  form (e.g., NITs). The recommendations were applied in two
  rounds, v10 and v11.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  =>
  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  =>
  Not so. the document mostly needs exposure to the real world, and
  feedback from implementer's who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  => No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  => All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  => No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  => The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  => The nits and shepherd review items were cleaned up between
  v09 and v11. There are still alerts like on BCP14 but that's false
  positive.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  =>  No such need

(13) Have all references within this document been identified as
either normative or informative?

  => Yes. Interestingly there's no informative. The shepherd scrutinized that
  and found that all references actually qualify as normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  => The main SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc) is the
  only reference that is not RFC yet,but is more advanced than this.
  It could be nice to ship both documents with consecutive numbers
  and I'd suggest that the RFC editor reserves the number right after
  SCHC for this document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  =>  No such thing. There is no informative reference at all.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  =>  No such thing.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  => No such thing.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  => No such thing.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  => No such thing.

As required by RFC 4858, this is based on the current template for the
Document Shepherd Write-Up dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

=> All is correct. We are going after a Proposed Standard.
    This document specifies the behaviour of a SCHC encoder/decoder for CoAP.
    The tracker indicates Proposed Standard and the draft Standards Track
 
(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  =>
  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

=>
  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  =>
  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  =>
  Document Shepherd: Pascal Thubert
  Responsible Area Director: Suresh Krishnan

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  =>
  The shepherd considered the readability of the content and its
  form (e.g., NITs). The recommendations were applied in two
  rounds, v10 and v11.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  =>
  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  =>
  Not so. the document mostly needs exposure to the real world, and
  feedback from implementer's who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  => No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  => All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  => No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  => The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  => The nits and shepherd review items were cleaned up between
  v09 and v11. There are still alerts like on BCP14 but that's false
  positive.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  =>  No such need

(13) Have all references within this document been identified as
either normative or informative?

  => Yes. Interestingly there's no informative. The shepherd scrutinized that
  and found that all references actually qualify as normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  => The main SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc) is the
  only reference that is not RFC yet,but is more advanced than this.
  It could be nice to ship both documents with consecutive numbers
  and I'd suggest that the RFC editor reserves the number right after
  SCHC for this document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  =>  No such thing. There is no informative reference at all.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  =>  No such thing.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  => No such thing.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  => No such thing.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such thing.

Based in template dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The tracker indicates Proposed Standard and the draft Standards Track
  This is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  Document Shepherd: Pascal Thubert
  Responsible Area Director: Eric Vyncke

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  Not so. the document mostly needs exposure to the real world, and
  feedback from implementer's who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  The nits and shepherd review items were cleaned up between
  v09 and v11. There are still alerts like on BCP14 but that's false
  positive.


(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such need

(13) Have all references within this document been identified as
either normative or informative?

  Yes. Interestingly there's no informative. As shepherd I scrutinized that
  and found that all references actually qualify as normative.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  The main SCHC draft (draft-ietf-lpwan-ipv6-static-context-hc) is the
  only reference that is not RFC yet,but is more advanced than this.
  It could be nice to ship both documents with consecutive numbers
  and I'd suggest that the RFC editor reserves the number right after
  SCHC for this document.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No such thing. There is no informative reference at all.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No such thing.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  No such thing.


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such thing.


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such thing.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The tracker indicates Proposed Standard and the draft Standards Track
  This is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  Document Shepherd: Pascal Thubert
  Responsible Area Director: Eric Vyncke

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  Not so. the document mostly needs exposure to the real world, and
  feedback from implementors who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  v09 was missing informational references. v10 fixes this and other
  shepherd review items.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such need

(13) Have all references within this document been identified as
either normative or informative?

  Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  The main SCHC draft is not RFC yet but it more advanced than this.
  It could be nice to ship them with consecutive numbers.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  TBD with 10

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No such thing

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  No such thing


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such thing


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such thing

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  The tracker indicates Proposed Standard and the draft Standards Track
  This is correct.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary


  This draft defines the way SCHC header compression can be applied to
  CoAP headers.  The CoAP header structure differs from IPv6 and UDP
  protocols since CoAP uses a flexible header with a variable number of
  options, themselves of variable length.  The CoAP protocol is
  asymmetric in its message format: the format of the packet header in
  the request messages is different from that in the response messages.

Working Group Summary

  The draft does not introduce new methods as the original SCHC does.
  This made the work much easier for the WG. On the other hand, the
  draft specifies how the existing SCHC mechanisms are to be used
  for a number of usual fields. The limit of the work is that the
  group could not try every possible CoAP variations and there may
  be cases where SCHC as it stands today is suboptimal. The group
  decided to ship as is, and possibly publish a refresher when more
  experience is gained.

Document Quality

  This draft is implemented by at least one vendor, Acklio.
  There is also an openSCHC implementation in python.

Personnel

  Document Shepherd: Pascal Thubert
  Responsible Area Director: Eric Vyncke

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  The shepherd performed his review after the WGLC and found no issue.
  The document does not introduce new techniques, and is rather an
  howto type of document. It is very detailed and covers OSCORE is
  depth with multiple examples. Some corrections where asked like
  expand on first use for OSCORE terms, and cleanup of references.
  But all in all the document is in a great state and appears fit for
  publication request.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  Not so. the document mostly needs exposure to the real world, and
  feedback from implementors who suffered in certain situations, or
  failed to obtain an optimal compression with the tools at hand.
  The group accepted to deliver a solution that might not cover the
  extremely large set of possibilities, and preferred to ship a v2 in
  some future with extended capabilities than waiting forever to ship
  this.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No such thing

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  All authors confirmed that there is no IPR.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No such thing

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it?

  The group understands it. SCHC is the core deliverable of LPWAN.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No such thing

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  v09 was missing informational references. v10 fixes this and other
  shepherd review items.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  No such need

(13) Have all references within this document been identified as
either normative or informative?

  Yes

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  OSCORE

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  The main SCHC draft is not RFC yet but it more advanced than this.
  It could be nice to ship them with consecutive numbers.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No such thing

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 8126).

  No such thing


(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  No such thing


(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  No such thing