Subject: [Roll] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft

From: Ines Robles <[email-masked]>
Date: Tue, 18 Jul 2017 10:19:08 +0200

Dear all,

Yesterday at 6tisch meeting was suggested to add this document,

https://tools.ietf.org/html/draft-munoz-6tisch-examples-02

as an Appendix section in useofrplinfo draft.

We would like to know your opinion on that,

- Should we add this draft as an appendix? or

- Should this draft be presented in lwig? or

- Additional Suggestions?

Thank you,

The authors.

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 10:30:07 +0200

Hi Ines,

I don't see the relation between the examples and the rplinfo draft.
RPLinfo is about routes through the DODAG and the use of IP-in-IP and 
RPI.
The examples do not reflect that topic in my opinion.

Peter

Ines  Robles schreef op 2017-07-18 10:19:
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch

---

From: Michael Richardson <[email-masked]>
Date: Tue, 18 Jul 2017 11:36:39 +0200

peter van der Stok <[email-masked]> wrote:
    > RPI.  The examples do not reflect that topic in my opinion.

    >> https://tools.ietf.org/html/draft-munoz-6tisch-examples-02

This document is a set of examples packets using RPL and 6tisch.

Section 3.6 includes packets from the data plane that are 6loRH compressed.
The examples do not include very much of useofrplinfo examples, but the idea
would be to include such packets.

I'm not sure what we would do with the beacons and other L2 examples.
Maybe this was a poor idea in the end.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 18 Jul 2017 13:23:25 +0000

Hell Peter

The document also indicates when to encaps and which artifacts are needed. Whereas 6LoRH describes how to compress the artifacts and the encaps.
An annex somewhere that captures the resulting shape of the packets is of great help for implementers. I think it does not hurt as annex, all the contrary.

Take care,

Pascal

-----Original Message-----
From: Roll [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: mardi 18 juillet 2017 10:30
To: Ines Robles <[email-masked]>
Cc: Michael Richardson <[email-masked]>; roll <[email-masked]>; [email-masked]
Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for 6TiSCH Configuration into useofrplinfo draft

Hi Ines,

I don't see the relation between the examples and the rplinfo draft.
RPLinfo is about routes through the DODAG and the use of IP-in-IP and RPI.
The examples do not reflect that topic in my opinion.

Peter

_______________________________________________
Roll mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/roll

---

From: peter van der Stok <[email-masked]>
Date: Tue, 18 Jul 2017 15:52:09 +0200

Well Pascal,

The authors should decide, but I recommend some structuring and 
additional text.

Peter

Pascal Thubert (pthubert) schreef op 2017-07-18 15:23:
> Hell Peter
> 
> The document also indicates when to encaps and which artifacts are
> needed. Whereas 6LoRH describes how to compress the artifacts and the
> encaps.
> An annex somewhere that captures the resulting shape of the packets is
> of great help for implementers. I think it does not hurt as annex, all
> the contrary.
> 
> Take care,
> 
> Pascal
> 
> Subject: Re: [Roll] [6tisch] Suggestion to add Example Packets for
> 6TiSCH Configuration into useofrplinfo draft
> 
> Hi Ines,
>

---

From: Thomas Watteyne <[email-masked]>
Date: Wed, 19 Jul 2017 15:46:46 +0200

Thinking about it, I believe it's better to
keep draft-munoz-6tisch-examples as a standalone document. I will be easier
to maintain, compared to splitting the contents across multiple drafts, or
worse, replicating the contents in multiple drafts.

On Tue, Jul 18, 2017 at 3:52 PM, peter van der Stok <[email-masked]>
wrote:

> Well Pascal,
>
> The authors should decide, but I recommend some structuring and additional
> text.
>
> Peter
>

-- 
_______________________________________

Thomas Watteyne, PhD
Research Scientist & Innovator, Inria
Sr Networking Design Eng, Linear Tech
Founder & co-lead, UC Berkeley OpenWSN
Co-chair, IETF 6TiSCH

www.thomaswatteyne.com
_______________________________________

---

From: Abdussalam Baryun <[email-masked]>
Date: Wed, 19 Jul 2017 19:01:38 +0200

+1

On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne <[email-masked]>
wrote:

> Thinking about it, I believe it's better to keep draft-munoz-6tisch-examples
> as a standalone document. I will be easier to maintain, compared to
> splitting the contents across multiple drafts, or worse, replicating the
> contents in multiple drafts.
>

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Wed, 19 Jul 2017 19:41:43 +0200

Hi,

same opinion here. I am thinking on a developer that needs this to work on
the protocol implementation. Having it in a single document is really handy.

regards,
X

2017-07-19 19:01 GMT+02:00 Abdussalam Baryun <[email-masked]>:

> +1
>
> On Wed, Jul 19, 2017 at 3:46 PM, Thomas Watteyne <[email-masked]
> > wrote:
>

-- 
Dr. Xavier Vilajosana
Wireless Networks Lab

*Internet Interdisciplinary Institute (IN3)Professor*
(+34) 646 633 681
[email-masked] <[email-masked]>
http://xvilajosana.org
http://wine.rdi.uoc.edu
Parc Mediterrani de la Tecnologia
Av Carl Friedrich Gauss 5, B3 Building
08860 Castelldefels (Barcelona). Catalonia. Spain

---

From: Michael Richardson <[email-masked]>
Date: Fri, 21 Jul 2017 10:07:43 +0200

Thomas Watteyne <[email-masked]> wrote:
    > Thinking about it, I believe it's better to keep
    > draft-munoz-6tisch-examples as a standalone document. I will be easier
    > to maintain, compared to splitting the contents across multiple drafts,
    > or worse, replicating the contents in multiple drafts.

I don't mind leaving it seperate.  I suggest that a well curated wiki
would work best here, at least in the short term.  Given that the IESG is
pulling back on the number of non-standards track documents they want to
process, I think that would better.

But perhaps we will still want to grab a few example packets both
uncompressed and compressed for useofrplinfo.

(There is a reason to implement uncompressed RPI, which is because you extend
the RPL DODAG across non-constrained media)