Re: [lp-wan] Profile Questions

[<[e-mail]>]

Hello Ana, all,

Thanks for this comment, sorry I haven't noticed it earlier, I was apparently too focused on AUTH48.
You raise valid points. Certainly many of these are going to be useful to other schc-over-foo drafts.
See some comments/answers inlined.
Best regards

Dominique

De : lp-wan <[e-mail]<mailto:[e-mail]>> on behalf of Ana Minaburo <[e-mail]<mailto:[e-mail]>>
Date : Tuesday 28 January 2020 16:53
À : lp-wan <[e-mail]<mailto:[e-mail]>>
Objet : [lp-wan] Profile Questions

Dear LPWANers,

The last version of SCHC document gives quite an extensive list of things that need to be defined in something called 'Profiles.' This concept is broadened, and I presume it is only a list of parameters to be set and functionalities that need to be restricted in used or avoided to be used. But while defining parameters for NB-IoT draft the following question raised:

The draft is not clear about where these profiles get into the communication or not, do they?
[DB] Not sure I understand your question, can you please elaborate?

How are they distinguishable from other profiles? Is an identifier needed?
Who can define a new one?
Do we need to be formal in the number of "profiles" we need?
[DB] Points to be taken. Do we want to organise the naming, versioning and archival of Profiles, or just leave it to those operating SCHC over constrained links?

Does a profile contain Rules or Rules are separate things?
[DB] a long discussion was held on this topic. What was the official outcome?

Is profile a configuration that is used locally and then only requires to define all the SCHC parameters and so these configurations are merely informative and not mandatory?
[DB] mandatory to whom for what? I'm not sure I captured the essence of the question.

Here I put a non-exhaustive list of what the draft talks about profiles:
The draft SCHC specifies in page 7 the definition of Profiles as
"Profile: SCHC offers variations in the way it is operated, with a
 number of parameters listed in Appendix D.  A Profile indicates a
      particular setting of all these parameters.  Both ends of a SCHC
      communication must be provisioned with the same Profile
      information and with the same set of Rules before the
      communication starts, so that there is no ambiguity in how they
      expect to communicate."

But all are not in Appendix D because you can find through the document a number of things that need to be addressed as:
-The use or not of Fragmentation (page 9, 21)
[DB] this is listed in Appendix D
-The size of the Rule_ID (page 11)
[DB] this is listed in Appendix D
-The way the Rule ID is sent (page 16)
[DB] this is listed in Appendix D
-The IID value (page 20)
[DB] indeed, this needs to be defined by a SCHC-over-foo document. Does it belong to a Profile? Good point.
- The Fragmentation Modes used (page 21)
[DB] this is listed in Appendix D
- The restriction or not of interleaving fragments for different fragmented SCHC packets" (page 21)
[DB] this is listed in Appendix D
- Window_Size (page 23)
[DB] this is listed in Appendix D
- Specify how integrity check is performed (page 24)
[DB] this is listed in Appendix D
- The size  and presence of DTag
[DB] this is listed in Appendix D
- The size and presence of W- The FCN size for each Rule_ID
[DB] this is listed in Appendix D
- The size and algorithm for RCS field for each Rule_ID
[DB] this is listed in Appendix D
- The All-1 SCHC Fragment is distinguishable from Send-Abort msg
[DB] this is listed in Appendix D
- Which Rule_ID values correspond to SCHC F/R msg
[DB] this is listed in Appendix D
- The expiration time of the Inactivity Timer
[DB] this is listed in Appendix D
- The meaning of values sent in the FCN field
[DB] good catch, thanks!
- Which Rule ID corresponds to each SCHC F/R
[DB] this is listed in Appendix D
- The penultimate tile is regular size or regular minus L2 Word
[DB] this is listed in Appendix D
- Last tile must be sent either as regular fragment or multi-tiles or alone in an All-1 SCHC fragment
[DB] this is listed in Appendix D
- Other times the sender must listen for SCHC ACK msg
[DB] good catch, thanks!
- the size of L2 Word
[DB] this is listed in Appendix D
- The value of padding bits
[DB] this is listed in Appendix D
- Whether and when the UDP CHECKSUM is elided
[DB] you're right, this is not listed, good catch! But the "Assessment of LPWAN integrity checking" is listed.
- MAX_PACKET_SIZE
[DB] this is listed in Appendix D
- A delay to be added after each SCHC message transmission
[DB] this is listed in Appendix D
- The MAX_ACK_REQUESTS
[DB] this is listed in Appendix D
- Settings and choices specific to a technology or a product
[DB] well, this boils down to all the items listed in Appendix D
and many others that I've not listed
[DB] thanks for this already comprehensive list.

[DB] By the way, Appendix D is a little cheat-sheet for schc-over-foo authors, it's not normative.

Thanks,
 Ana










_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.