Re: [6tisch] #41 (minimal): intended status for draft minimal

[Brian Haberman <[e-mail]>]

Hi Xavier,
     I think there are two things that separate 7668 from minimal. I
will point out that this is based on my reading of the documents, but I
want the WG to understand the differences in the tracks and make a
conscious decision on which is most applicable.

1. RFC 7668 is very clear on what it is defining. The intro contains an
explicit statement on that ("This document describes how IPv6 is
transported over Bluetooth LE..."). Minimal is far less definitive in
what it is defining ("One goal of this document is to define the
simplest set of rules for building a TSCH-compliant network...",
"...this minimal mode of operation MAY also be used during network
bootstrap...", and "...minimal configuration MAY be used as a fall-back
mode of operation..."). To me, that raises some questions. What exactly
is a TSCH-compliant network? Will networks fail if some devices do not
implement minimal for bootstrapping or fall-back since it is optional?

2. RFC 7668 falls in the standards track, in my opinion, due to the
strict guidance provided in sectins 3.2.3, 3.2.4, and 3.2.5. If those
rules are not followed, IPv6-over-BTLE won't work. Those types of
statements can be advanced along the standards track (PS -> IS). The
"advice" in minimal is far less declarative and appears to be advisory.

As I said in Yokohama, I can see minimal being re-worded as a standards
track document, but today it reads like a BCP or Informational document.

Regards,
Brian


On 12/3/15 2:27 AM, Xavier Vilajosana 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
> 
> 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 <[e-mail]>:
> 
>> 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.
>> --
>> [e-mail]
>>
> 
> 
> 
> _______________________________________________
> 6tisch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/6tisch
>