Subject: [6tisch] #41 (minimal): internded status for draft minimal

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:24:59 -0000

#41: internded status for draft minimal

 From Suresh's INT-DIR review

 * Intended Status:

 This looks more like a recommended set of network configuration parameters
 than a new protocol definition. Has the wg considered whether the Proposed
 Standard status is appropriate (as opposed to Info or BCP)?

-- 
-----------------------------------+-----------------------------------
 Reporter:  [email-masked]     |      Owner:  [email-masked]
     Type:  defect                 |     Status:  new
 Priority:  major                  |  Milestone:  milestone1
Component:  minimal                |    Version:  1.0
 Severity:  Submitted WG Document  |   Keywords:
-----------------------------------+-----------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:27:08 -0000

Comment (by [email-masked]):

 from the interim call minutes, Nov 27th

 o       [Michael] no intended surveys, but BCPs ("profile") say that,
 "when using protocol X in context Y, you SHOULD use parameters Z". This is
 for operators rather than implementors. Minimal says you to use RPL, which
 you would not implement if you were just using IEEE802.15.4e. AD asked
 whether this will be used beyond a plugtest.
 o       [Pascal] node requirements for IPv6 is informational, it does not
 mandate behaviors. Just information about the mote; but doesn't use
 "MUST". Minimal draft does say you need to compute the RPL rank according.
 That draft is what this is specified, so it's not just setting parameters.
 Think we are beyond informational.
 o       [Malisa] agreed with Pascal & Michael, would make sense to publish
 as standards track. The DTLS profile that is a similar scope, is intended
 to be published as standards track.
 o       [Michael] RFC6434 list RFCs that you are expected you should look
 at. RFC6434 should not have been informational. Strictly speaking,
 informational are not standards.
 o       [Michael] we have a BCP number, but no informational numbers.
 o       [Thomas] Consensus on Standards track. How do we proceed? We are
 building on top of it Default setup on top of it.
 o       [Michael] A good answer. We have not articulated that.
 o       [Thomas] It is important to publish this. Standard track. RPL rank
 no anywhere else. This is the spec.
 o       [Pascal] Nobody wants informational, better standard track.
 Recommendation for developers than for deployers.
 o       [Thomas] Discuss on the ML.

-- 
-----------------------------------+------------------------------------
 Reporter:  [email-masked]     |       Owner:  [email-masked]
     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:1>
6tisch <https://tools.ietf.org/6tisch/>
IPv6 over the TSCH mode of IEEE 802.15.4e

---

From: "6tisch issue tracker" <[email-masked]>
Date: Mon, 30 Nov 2015 12:28:31 -0000

#41: intended status for draft minimal

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Nov 2015 17:43:28 +0000

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:[email-masked]]
> Sent: lundi 30 novembre 2015 13:29
> To: [email-masked]; Pascal Thubert (pthubert) <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [6tisch] #41 (minimal): intended status for draft minimal (was:
> internded status for draft minimal)
>

---

From: Kris Pister <[email-masked]>
Date: Mon, 30 Nov 2015 09:47:52 -0800

are most "ipv6-over-foo" documents standards track, or something else?

ksjp

On 11/30/2015 9:43 AM, Pascal Thubert (pthubert) wrote:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Nov 2015 12:57:50 -0500

Hi Kris,

> are most "ipv6-over-foo" documents standards track, or something else?

Yes, the ipv6-over-foo documents are standards track. It should be noted
that those drafts specifically describe the detailed operation of the
IPv6 stack for the foo physical layer. The minimal document seems to be
more of a compilation of "set X to Y", where X is already defined in a
different specification.

Your question does raise an interesting point. Is this document supposed
to be the 802.15.4e equivalent of RFC 2464? It certainly doesn't read
that way to me.

Regards,
Brian

>> 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
>>
>>
>>> Ticket URL:
>>> <https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41#comment:2>

---

From: Kris Pister <[email-masked]>
Date: Mon, 30 Nov 2015 10:00:23 -0800

That was the original goal.

ksjp

On 11/30/2015 9:57 AM, Brian Haberman wrote:
> Is this document supposed
> to be the 802.15.4e equivalent of RFC 2464?

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Nov 2015 13:02:39 -0500

Pascal,

> 2) minimal is a recommendation for device builders, as opposed to network admin. Apparently this pleads for std track rather than BCP

BCP is not limited to network administration. They are also applicable
to implementers. RFCs 6881 and 7696 are examples of BCPs aimed at
implementers.

The key is whether you expect to promote this document from PS to IS.

Regards,
Brian

---

From: Brian Haberman <[email-masked]>
Date: Mon, 30 Nov 2015 13:10:36 -0500

Hi Kris,

> That was the original goal.

Hmm... Then there may be more things missing from this document then.
IPv6 address generation rules/guidance, NDP operation, SLAAC
functionality, MTU behavior, etc. all come to mind for that kind of
document. Granted, those may be covered via reference to other RFCs...

The main point is that if that is the goal, it is not clear when the
Abstract starts with "This document describes the minimal set of rules
to operate an IEEE 802.15.4 Timeslotted Channel Hopping (TSCH) network."

Brian

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Mon, 30 Nov 2015 18:39:34 +0000

We have to explore that a bit. 

To start with, TSCH is a 802.15.4 and we planned to reuse all 6LoWPAN as is, and more importantly, minimal enables to follow 802.15.4 and 6LoWPAN as they evolves. 
So a product will have to say, minimal + 802.15.4 revision blah, plus 6LoWPAN RFCS xxxx xxxx xxxx, etc...
For instance 6TiSCH also defines a backbone mode with a 6BBR, the document is under adoption call at 6lo, and if the process succeeds, that will update 6LoWPAN and be usable by a minimal implementation.  Same goes for the RPL artifact compression, which is also under adoption at 6lo. 

How do you suggest we word this?

Pascal

> From: 6tisch [mailto:[email-masked]] On Behalf Of Brian Haberman
> Sent: lundi 30 novembre 2015 19:11
> To: Kris Pister <[email-masked]>; [email-masked]
> Subject: Re: [6tisch] #41 (minimal): intended status for draft minimal
> 
> Hi Kris,
> 
> IPv6 address generation rules/guidance, NDP operation, SLAAC functionality,
> MTU behavior, etc. all come to mind for that kind of document. Granted, those
> may be covered via reference to other RFCs...
> 
> The main point is that if that is the goal, it is not clear when the Abstract starts
> with "This document describes the minimal set of rules to operate an IEEE
> 802.15.4 Timeslotted Channel Hopping (TSCH) network."
> 
> Brian
> 
> > ksjp
> >

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 30 Nov 2015 21:35:41 +0100

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) <[email-masked]>:

> 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
>
>
> > To: [email-masked]; Pascal Thubert (pthubert) <[email-masked]
> >
> > Cc: [email-masked]
> (was:
> > Ticket URL: <
> https://trac.tools.ietf.org/wg/6tisch/trac/ticket/41#comment:2>

---

From: Xavier Vilajosana <[email-masked]>
Date: Mon, 30 Nov 2015 21:46:58 +0100

I support Kris point.

RFC 2464 for example indicates how to construct the link local address from
the MAC layer field

  The IPv6 link-local address [AARCH
<https://tools.ietf.org/html/rfc2464#ref-AARCH>] for an Ethernet
interface is
   formed by appending the Interface Identifier, as defined above, to
   the prefix FE80::/64.

In minimal, for example, we say what information to be used in the JP
field of the Synchronization IE or what specific IEs from all the
possible set have to be sent in the EB to advertise the network and
what are their specific values.

Both documents in my opinion build a link between the above and below
layers by defining a set of rules or conventions.

kind regards,
Xavi

---

From: Ralph Droms <[email-masked]>
Date: Mon, 30 Nov 2015 16:48:20 -0500

> On Nov 30, 2015, at 12:57 PM 11/30/15, Brian Haberman <[email-masked]> wrote:
> 
> Hi Kris,
> 

I think Brian's observation points to an important decision that the WG needs to make about this document.  Is the document intended to be:

(a) a supplement to an "IP-over-6TiSCH" document, that gives specific operational parameters for minimal operation of the IP-over-6TiSCH protocol suite; or
(b) a standalone document that explicitly describes the specific use of all the protocols required for minimal operation of 6TiSCH

In my opinion, the document is currently more (a) than (b).  However, (a) requires a completed IP-over-6TiSCH document.

- Ralph

---

From: "[email-masked]" <[email-masked]>
Date: Mon, 30 Nov 2015 18:33:10 -0600

This email is in response to Thomas Watteyne’s email dated 23 October requesting the IEEE 802.15 6T interest group to make a recommendation on IE format.  It also addresses correct settings for the PAN ID compression bit in response to the 6tisch minimal document.

These documents have been reviewed for accuracy and the IE format recommendation was approved by the 6T interest group.

Please respond to me or the 6T reflector ([email-masked]) with any concerns or issues you may have with these documents.

Sincerely, Pat Kinney

Pat Kinney
Kinney Consulting LLC
IEEE 802.15 WG vice chair, SC chair
ISA100 co-chair, ISA100.20 chair
O: +1.847.960.3715
[email-masked]