Subject: [6tisch] 6top review

From: Charlie Perkins <[email-masked]>
Date: Fri, 14 Apr 2017 06:35:11 -0700

Hello folks,

I have reviewed draft-ietf-6tisch-6top-protocol-04 (see attached).

I didn't review the IANA considerations, but I did get through most of 
the document.

I think the document has issues, some technical, mostly editorial.  They 
can be easily fixed but some decisions have to be made.  All of my 
comments can be found in the attached output of 'rfcdiff'.  The 
editorial suggestions I mostly incorporated into a revised version of 
the file, which is also visible in the output of 'rfcdiff'.  If this is 
unclear, please let me know.  I think that there should be a new section 
for "Terminology", and various TSCH, 6TiSCH, and 6top terms explained in 
that section for convenience.

Here are some of my technical comments about the document.  Some of my 
questions might arise from my own misunderstandings, in which case 
perhaps a few more sentences or cross-references could be inserted for 
explanations.

  * ERR_EOL is defined as an error, but it is used as a flag for
    protocol signaling
  * Why is any negotiation needed for node A to delete cells?
  * If a negotiation is needed, then isn't NumCells needed somewhere in
    the message format?
  * In Figure 13, If you have a Candidate CellList, don't you also need
    "NumCandCells"?
  * GEN and SeqNum play similar roles.  The protocol could be cleaner if
    their roles were combined.  Plus you would have more bits, making
    rollover far less frequent.
  * Some of the suggestions for SF specification seem impractical.
  * Not clear why LIST and COUNT are needed except possibly for reboot
    or operating system errors.
  * Not clear how to abort the CONFIRMATION step of a 3-step transaction.
  * In Figure 14, is NumCells needed for the RELOCATE Response?

Regards,
Charlie P.

Regards,
Charlie P.

---

From: Thomas Watteyne <[email-masked]>
Date: Fri, 14 Apr 2017 15:38:40 +0200

Carlie,
Thanks a million for that. I will add a slide for the 6TiSCH call in 22min
which contains your key points.
Thomas

On Fri, Apr 14, 2017 at 3:35 PM, Charlie Perkins <
[email-masked]> wrote:

> I didn't review the IANA considerations, but I did get through most of the
> document.
>
> can be easily fixed but some decisions have to be made.  All of my comments
> can be found in the attached output of 'rfcdiff'.  The editorial
> suggestions I mostly incorporated into a revised version of the file, which
> is also visible in the output of 'rfcdiff'.  If this is unclear, please let
> me know.  I think that there should be a new section for "Terminology", and
> various TSCH, 6TiSCH, and 6top terms explained in that section for
> convenience.
>
> questions might arise from my own misunderstandings, in which case perhaps
> a few more sentences or cross-references could be inserted for explanations.
>
>    - ERR_EOL is defined as an error, but it is used as a flag for
>    protocol signaling
>    - Why is any negotiation needed for node A to delete cells?
>    - If a negotiation is needed, then isn't NumCells needed somewhere in
>    the message format?
>    - In Figure 13, If you have a Candidate CellList, don't you also need
>    "NumCandCells"?
>    - GEN and SeqNum play similar roles.  The protocol could be cleaner if
>    their roles were combined.  Plus you would have more bits, making rollover
>    far less frequent.
>    - Some of the suggestions for SF specification seem impractical.
>    - Not clear why LIST and COUNT are needed except possibly for reboot
>    - Not clear how to abort the CONFIRMATION step of a 3-step transaction.
>    - In Figure 14, is NumCells needed for the RELOCATE Response?
>
> Regards,
> Charlie P.
>
>
>
> Regards,
> Charlie P.
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>
>

-- 
_______________________________________

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
_______________________________________