Re: [6tisch] Fwd: I-D Action: draft-ietf-6tisch-6top-protocol-02.txt

Thanks for the great work. This is Jiliang Wang from Tsinghua University. I
am very interested in this version and I just have several questions.

1.       In 4.3.10, it says “If node A requests more cells than can fit in
the response, node B MUST return code RC_ERR_NORES and an empty cell list.”

1.- Is there any fragmentation method to transmit all the cells if the
requested cells cannot be fit in a response?

2.       Will the clear command result in inconsistency in current design?
For example, a clear command is sent from A to B and the response from B to
A is lost.

3.       Currently, the add command supports best-effort cell adding, i.e.,
when the cells is not enough, partial of the cells can be added – if I
understand correctly.

 –what is the purpose of best-effort adding. Why not just return success
and fail?
best,

-------------
Jiliang Wang
Assistant Professor
http://tns.thss.tsinghua.edu.cn/~jiliang/

On Tue, Jul 26, 2016 at 2:32 PM, Xavier Vilajosana <
xvilajosana@eecs.berkeley.edu> wrote:

> Dear all,
>
> we have submitted a revision of the 6top draft. It includes most of the
> changes proposed in the WG meeting in Berlin.
>
> please send us your comments.
>
> kind regards,
> Xavi
>
> ---------- Forwarded message ----------
> From: <internet-drafts@ietf.org>
> Date: 2016-07-26 8:30 GMT+02:00
> Subject: [6tisch] I-D Action: draft-ietf-6tisch-6top-protocol-02.txt
> To: i-d-announce@ietf.org
> Cc: 6tisch@ietf.org
>
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IPv6 over the TSCH mode of IEEE 802.15.4e
> of the IETF.
>
>         Title           : 6top Protocol (6P)
>         Authors         : Qin Wang
>                           Xavier Vilajosana
>         Filename        : draft-ietf-6tisch-6top-protocol-02.txt
>         Pages           : 28
>         Date            : 2016-07-25
>
> Abstract:
>    This document defines the 6top Protocol (6P), which enables
>    distributed scheduling in 6TiSCH networks.  6P allows neighbor nodes
>    in a 6TiSCH network to add/delete TSCH cells to one another.  6P is
>    part of the 6TiSCH Operation Sublayer (6top), the next higher layer
>    of the IEEE802.15.4 TSCH medium access control layer.  The 6top
>    Scheduling Function (SF) decides when to add/delete cells, and
>    triggers 6P Transactions.  Several SFs can be defined, each
>    identified by a different 6top Scheduling Function Identifier (SFID).
>    This document lists the requirements for an SF, but leaves the
>    definition of the SF out of scope.  Different SFs are expected to be
>    defined in future companion specifications.
>
>
>
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/
>
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-6tisch-6top-protocol-02
>
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-6tisch-6top-protocol-02
>
>
> Please note that it may take a couple of minutes from the time of
> submission
> until the htmlized version and diff are available at tools.ietf.org.
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>
> _______________________________________________
> 6tisch mailing list
> 6tisch@ietf.org
> https://www.ietf.org/mailman/listinfo/6tisch
>
>