Re: [lp-wan] FW: I-D Action: draft-ietf-lpwan-schc-over-lorawan-07.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Julien:

The mapping of terms must be very clearly indicated early in the document. But from then on this is an LPWAN document being worked on and published by LPWAN so it must speak the LPWAN language.

Considering that we have a simple one to one mapping that should not be an issue for an implementer. I expect that the functional specs would already be ‘translated’.

Keep safe,

Pascal

Le 15 mai 2020 à 22:33, Julien CATALANO <[e-mail]> a écrit :



Dear Olivier, dear LPWAN'ers,

Thank you Olivier for bringing this document forward!

In this latest git update, you changed the nomenclature used in the draft, moving away from LoRaWAN namings. [1] [2]

IMHO, in the context of LoRaWAN, we should keep the LoRaWAN nomenclature. This document addresses LoRaWAN implementers, we should talk their language.

I would like draft-ietf-lpwan-schc-over-lorawan to use the terms "end-device" and "Network Server", especially when used in the context of LoRaWAN, but also as much as possible, instead of the SCHC terms "Device (Dev)" and "Network Gateway".

We obviously need to keep the links between those terms in the text, as done in -07 section 4 "LoRaWAN Architecture".

Any advice from the group?

Thank you
Julien

[1] https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7
[2] https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6


Le 15/05/2020 à 16:13, Olivier Gimenez a écrit :

Hi Dominique,



Thank you for your comments and pull requests. I answered in your email and updated the draft:

https://github.com/Acklio/schc-over-lorawan/blob/draft-ietf-lpwan-schc-over-lorawan-08/draft-ietf-lpwan-schc-over-lorawan.md



Best regards

Olivier



> -----Original Message-----

> From: [e-mail]<mailto:[e-mail]> <[e-mail]><mailto:[e-mail]>

> Section 5.6.2 "For non-battery powered devices, SCHC receiver MAY also

> choose to"

> The above line is not crystal clear. It could mean "Non-battery powered

> devices acting as SCHC receivers MAY ...".

> I know you mean "When a non-battery powered device acts as a SCHC

> sender, the SCHC receiver …", because this is Section 5.6.2 Uplink

> fragmentation.

> I suggest that in Section 5.6.2, we have

>

> "For battery powered devices acting as SCHC sender, it is RECOMMENDED …

> "

> "Non-battery powered devices acting as SCHC receivers MAY …"



[OG] Updated as discussed, see ccb3aea<https://github.com/Acklio/schc-over-lorawan/commit/ccb3aea8b36148be3c1ebf156dbdedb92888741f>



> Section 5.6.2.2

> We now have the option of sending the last tile with the All-1 Fragment.

> There should be an optional tile shown in Fig 8, or a Fig 9 added with a tile

> present and text explaining that both cases are possible.



[OG] Fixed, see 885d4c9<https://github.com/Acklio/schc-over-lorawan/commit/885d4c9d43f8dd791f617ceb2585ba175cbab77d>



> Section 5.6.2.3

> Fig 9 says 0 to 63 bits of bitmap. Actually, only a few discrete values for the

> number of bits are possible. Is it worth spelling them out? So that readers

> dont think padding will be needed?



[OG] Fixed, see 04e976c<https://github.com/Acklio/schc-over-lorawan/commit/04e976c580cdb07d22262b4941c513c8c8c9171a>



> Section 5.6.3.2

> Figure 13 does not show a payload.



[OG] Fixed, see 04cb13d<https://github.com/Acklio/schc-over-lorawan/commit/04cb13d4da81f811a0f48cfe564f5e661243fa33>



> The terms "device", "end-device", "Dev" are used in various places. Same for

> "server", etc. I think we should align terminology to that used in RFC8376.



[OG] Fixed, see 9e300f7<https://github.com/Acklio/schc-over-lorawan/commit/9e300f780c92bc1b27a89922c721513a1cd278d6> and 0bb8dbd<https://github.com/Acklio/schc-over-lorawan/commit/0bb8dbd133b7717a4066b952c1026c9a49415ea7>





To view our privacy policy, including the types of personal information we collect, process and share, and the rights and options you have in this respect, see www.semtech.com/legal<http://www.semtech.com/legal>.



_______________________________________________
lp-wan mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/lp-wan


_______________________________________________
lp-wan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/lp-wan