Hi Xavi; From my experience in SDOs and Alliances, the profile allows multiple vendors to create and configure devices that will interoperate with other devices and serve desired applications. To do so, a profile defines which optional behaviors from a standard that are required (it may also declare which mandatory behaviors are required), and what configurations and parameter settings are to be used.
For instance, a profile could state that the default settings for TSCH operation as stated in 802.15.4 will be used, the PHY will be the 2.4 GHz PHY using O-QPSK modulation over 15 channels, additionally security will be used with the parameters defined by the profile. So, from my perspective, a profile is not a standard, rather it defines how a user will use “generic” standards (e.g. 802.15.4, 6tisch, 6LoWPAN) to assure interoperability in a way that serves the stated application(s). Pat On 3, Dec2015, at 1:27, Xavier Vilajosana <[email protected]> wrote: Hi Tero, Brian, I would like to understand better the difference from what you consider a profile (and should be BCP) and what is a document in the standard track. If I take for example IPv6 over BTLE, https://tools.ietf.org/html/rfc7668 <https://tools.ietf.org/html/rfc7668> I can see it both as a profile of rfc4944 or as different specification, it depends on my pre-conceived idea. (I think the same applies for the IPv6 over NFC under development). As far as I understand this RFC does not define any new field for a header but only how you use 6lowpan on top of BTLE, that is how you set some MAC layer fields and how you use the MAC layer information from an above perspective. You may argue that it defines how addresses are auto-configured which I can argue this is a profile as it takes a set of already existing MAC layer fields and prepends them with a prefix. This prefix is something already known and defined in other RFCs. We can look into it in detail and I am sure we can find arguments to say it is a profile. Given that context can you please provide solid and objective arguments on why the specification of a the profile of IPv6 on BTLE is an standard and what we define in minimal (the 15.4e profile) it is not? Does this depends on having sections saying for example that in minimal address auto-configuration is done in the same way as IPv6 over 15.4 does (rfc4944)? thanks and sorry for asking, I am not able to see a clear boundary. regards, Xavi 2015-12-01 13:21 GMT+01:00 Tero Kivinen <[email protected] <mailto:[email protected]>>: Xavier Vilajosana writes: > 4) minimal defines when EBs are sent and what information from the wide set of > options (IEs) provided by 15.4 TSCH is sent in an EB. I.e. provides profile for 15.4 to be used in 6tisch. > 5) it defines the specific 15.4 header settings so 2 nodes can talk together > and establish an initial configuration without discarding frames from one and > another. Again profiling. > 6) it defines the number of security keys that are needed. The actual keys do not belong to this document. If you are trying to say that this document profiles 802.15.4 security by telling that we use two different key, one for the EBs and one for the rest of the data, then this is again profiling. On the other hand it does not provide the information how those two keys are identified, i.e which key id mode and key index are used for K1 and K2. It does give example using Key Identification Mode of 0x01, but there is no text explaining how device knows what KeyIndex is used for K1 and K2. > 7) it defines how the routing information is used to hint the network > structure. That is, how the join priority is used to match the routing > topology. Btw, the join priority field in the TSCH Synchronization IE was renamed to Join Metric in the 802.15.4 revision. This is because term priority is also used for priority traffic etc, thus using it here too caused confusion. And also the join metric is not really a priority, it specifies how far the node sending EBs are from the root, i.e. node sending EBs is setting join metric to be its parent join metric + 1. > 8) it defines the default number, default slot-offset, channel offset of the > cells in the schedule of all nodes in a 6tisch network so the network can be > easily initiated. It also defines the default timing of the slots and the > default slotframe length, etc.. It does not however specify are those numbers fixed for the duration of the network. I.e. can any of those change? It is clear that some of them cannot be changed without tearing down the network (timeslot timing, channel hopping sequence), but what about the number of timeslots in the slotframe, or the number of scheduled cells, or parameters of those cells. > Without that, 2 vendors can be running 15.4e but chances are that they do not > interoperate. The ETSI/6TiSCH plugtest event corroborated the need of such > specification so vendors are able to easily interoperate. This is true, but that is just the reason I think this document is more of an profile than a standard. I.e. if gives defaults, limits some features away, specifies how things are set up etc, so we can have interoperability. There is nothing there that is not already specified in the 802.15.4-2015, it is just profiling the use of it. -- [email protected] <mailto:[email protected]> _______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
