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

[Xavier Vilajosana <[e-mail]>]

Hi,

my 2 cents.

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.
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.
6) it defines the number of security keys that are needed.
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.
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..

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.

kind regards,
Xavi


2015-11-30 18:43 GMT+01:00 Pascal Thubert (pthubert) <[e-mail]>:

> Dear all:
>
> I created that issue to follow up on whether standard track is really the
> intention for this document or, as Suresh and Brian suggest, we would
> explore an alternative, BCP or informational.
> At the call, there was a sense that informational was not the right path,
> and that std track was slightly preferred. If that is so, we must now make
> the case in the shepherd writeup and defend it in front of the IESG. I
> would like that we explorein depth the pros and cons of each, and we really
> want all the arguments on the table.
>
> What I have so far:
>
> 1) minimal is a base that we expect will operate in many networks since it
> appears to be needed to build the next stage where dedicated time slots can
> be negotiated. Apparently this pleads against informational
> 2) minimal is a recommendation for device builders, as opposed to network
> admin. Apparently this pleads for std track rather than BCP
> 3) minimal defines a way to compute the Rank that cannot be obtained with
> a simple parameter in an existing implementation. The operation SHOULD be
> programmed in the device for interoperation and that operation is not
> specified in a preexisting RFC. This pleads for std track
>
> What else?
>
> Pascal
>
>
> > -----Original Message-----
> > From: 6tisch issue tracker [mailto:[e-mail]]
> > Sent: lundi 30 novembre 2015 13:29
> > To: [e-mail]; Pascal Thubert (pthubert) <[e-mail]
> >
> > Cc: [e-mail]
> > Subject: Re: [6tisch] #41 (minimal): intended status for draft minimal
> (was:
> > internded status for draft minimal)
> >
> > #41: intended status for draft minimal
> >
> >
> > --
> > -----------------------------------+------------------------------------
> >  Reporter:  [e-mail]     |       Owner:  [e-mail]
> >      Type:  defect                 |      Status:  new
> >  Priority:  major                  |   Milestone:  milestone1
> > Component:  minimal                |     Version:  1.0
> >  Severity:  Submitted WG Document  |  Resolution:
> >  Keywords:                         |
> > -----------------------------------+------------------------------------
> >
> > Ticket URL: <
> https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41#comment:2>
> > 6tisch <https://tools.ietf.org/6tisch/>
> > IPv6 over the TSCH mode of IEEE 802.15.4e
>