[core] CoCoA / Editorial Issues

[Hannes Tschofenig <[e-mail]>]

Below are a few basic / editorial review remarks.

Shouldn't the title be changed into something else than "CoAP Simple
Congestion Control/Advanced"?

Currently, the title makes no sense. Either it is simple congestion
control (which it cannot be since that's what is currently in the CORE
specification) or it is advanced. I would prefer something "An Advanced
Congestion Control Scheme for CoAP"

Also I prefer if the following paragraph gets changed
"
   This specification defines some simple advanced CoRE Congestion
   Control mechanisms, Simple CoCoA.  It is making use of input from
   simulations and experiments in real networks.
"

Maybe something like "This specification defines an advanced congestion
control for CoAP."; again simple + advanced makes no sense.

It is also not necessary to state that you this work was done with input
from simulations and experiments. Without those you wouldn't be able to
standardize a congestion control mechanism in the IETF anyway.

Terminology:

Delete the following note since it is irrelevant for the specification
whether it is informational, experimental or something else with regards
to the use of RFC 2119 language.

   (Note that this document is itself informational, but it is
   discussing normative statements.)

RFC 2119 boilerplate text: Normally the following language is used:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in RFC
   2119 [RFC2119].

I don't know where you got this text from:

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119] when they
   appear in ALL CAPS.  These words may also appear in this document in
   lower case as plain English words, absent their normative meanings.

Section 2 "Context"

Historical stories are less useful for IETF document. I would suggest to
delete this paragraph

   In the Vancouver IETF 84 CoRE meeting, a path forward was defined
   that includes a very simple basic scheme (lock-step with a number of
   parallel exchanges of 1) in the base specification together with
   performance-enhancing advanced mechanisms.

I would move the core messages of the following two paragraphs to the
introduction:

   The present specification is based on the approved text in the
   [RFC7252] base specification.  It is making use of the text that
   permits advanced congestion control mechanisms and allows them to
   change protocol parameters, including NSTART and the binary
   exponential backoff mechanism.  Note that Section 4.8 of [RFC7252]
   limits the leeway that implementations have in changing the CoRE
   protocol parameters.

>From the paragraph above you want to explain the purpose of the NSTART
and the binary exponential backoff mechanism and why it is relevant to
this work. Ignore the rest.

   The present specification also assumes that, outside of exchanges,
   non-confirmable messages can only be used at a limited rate without
   an advanced congestion control mechanism (this is mainly relevant for
   [RFC7641]).  It is also intended to address the [RFC8085] guideline
   about combining congestion control state for a destination; and to
   clarify its meaning for CoAP using the definition of an endpoint.

The first sentence is a bit hard to parse. You are saying the following,
I believe: It is difficult to send non-confirmable messages at a high
rate since the sender has no information about potential congestion
situation of the network (and also flow control information at the
receiver side) since non-confirmable messages do not provide any response.

   The present specification does not address multicast or dithering
   beyond basic retransmission dithering.

It is useful to say upfront that you are not addressing multicast. I
don't understand what the second part of the sentence means. Btw, you
can also move the statement about multicast to Section 3. "Area of
Applicability".

The security section is empty but I don't expect it to say a lot.

Ciao
Hannes