[Lake] Comments on draft-ietf-lake-reqs-00

[Ivaylo Petrov <[e-mail]>]

Dear all,

I have reviewed this document and overall I believe it is well
written, easy to follow and provides a good amount of information
about the requirements the AKE protocol needs to meet in order to be
truly useful in combination with OSCORE.

Here I will try to avoid repeating points that others have brought up
already or that are present in the github issue tracker. I believe we
will discuss those in the interim meeting.

Here are a few comments and questions:

sec 2.5

   The AKE is required to protect the identity against active attackers
   of one of the peers and protection against passive attackers of the
   other peer in the case of public key identities.

Seems difficult to read. It feels like due to an attempt to be
concise, I needed to read it a few times to understand it.

sec 2.9:

  Increased power consumption is unavoidable in poor network
  conditions, such as most wide-area settings including LoRaWAN.

While I agree that poor network conditions would increase power
consumption at least on average, I am not sure how this is connected
to this happening on a wide-area setting and whether there is a
specific reason only LoRaWAN to be specifically named here. The
formulation of the sentence makes me wonder if I am missing something
here.

sec 2.9.1:

  LoRaWAN employs unlicensed radio frequency bands in the 868 MHz ISM
   band.  As a case in point, we focus here on deployment in Europe,
   where this is regulated by ETSI EN 300 220.

I think possibly in an attempt for brevity those statements could be
misleading. In current deployments in Europe LoRaWAN uses 868 MHz ISM
band. There is the possibility to use LoRaWAN on a licensed band, but
I am not aware of anyone doing it. At the same time in the US, where I
believe LoRaWAN is still a bit less popular, it uses 902 to 928 MHz
band, it is regulated by another organization and has different size
limits and rules for sharing the spectrum than the ones described
here. I would suggest pointing out in the first sentence that
reflecting deployment reality as of now, only European regulation is
described in the following paragraphs. This way there will be no
confusion.

  For LoRaWAN the most
   relevant metric is the Time-on-Air, which determines the back-off
   times and can be used as an indicator to calculate energy
   consumption.

I am not aware of a term back-off time in relation to duty cycle (I
have heard it often for retries). If this is not a common term, a
suggested rephrasing is:

  For LoRaWAN the most relevant metric is the Time-on-Air, which
  also determines the period before the next communication can occur
  and which can be used as an indicator to calculate energy
  consumption.

sec 2.9.1.1

  LoRaWAN has a header size of 13 bytes,

This is not considering fopts, which could be fine, maybe just adding
some word like "generally" could make it much more correct
formulation.

While I did try not to look too closely at the language usage as long
as the text is understandable, here is a nit that caught my attention:
* sec 2.4: s/the all COSE/all the COSE/

Best regards,
Ivaylo