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

[Julien CATALANO <[e-mail]>]

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] <[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.
>
> _______________________________________________
> lp-wan mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/lp-wan