Subject: [6tisch] Ben Campbell's No Objection on draft-ietf-6tisch-6top-protocol-11: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 03 Apr 2018 12:55:03 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-6tisch-6top-protocol-11: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-6tisch-6top-protocol/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Substantive Comments:

Requirements Language: The document contains at least a few instances of lower
case "must". Please consider using the boilerplate from RFC 8174.

§3.1.1, figure 4: Did I miss an explanation of why A sends 3 candidate cells
when it needs 2 new cells? I can guess why, but it would be best to explicitly
explain it.

§6.2.2 and §6.2.3: Do you really expect new message types and commands to be
added routinely enough to justify
 a registry?

Editorial Comments and Nits:

Abstract: Please expand 6top on first mention.  You do so later in the
paragraph, but not the first time. (This pattern repeats in the document body)

§1: Please expand 6TiSCH on first mention.

§3.1.1, Figure 4, step 2: "Node A locks the candidate cells in it schedule
until..." doesn't parse. Should "it" be "its"?

§4: This section seems to be about 6top scheduling function _specification_,
not the functions themselves. Is this correct?

Appendix A: Seems like this should be part of the IANA considerations.

---

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 5 Apr 2018 12:09:35 +0200

Dear Ben,

thanks so much for your review. We answer to your comments inline. The
proposed changes will be materialized in a new version of the draft,
collecting all the received reviews. We provide inline our responses
prepended with "XV:".

2018-04-03 21:55 GMT+02:00 Ben Campbell <[email-masked]>:

>> XV: thanks for this comment. We propose to clarify the text with the
>> following sentence.
>
>
>> "The SF running on node A selects 3 candidate cells. More than the
>> required cells are selected to enable node B to select a subset of them and
>> facilitate a successful allocation."
>
>

>
>
> XV: We do not know what future updates can be made to the 6P protocol, we
>> think having a registry may facilitate the extension of 6P with new
>> commands or even new message types.
>
> This is relevant now as there are still few SFs and hence it may happen
>> that new commands are required as long as new SFs are developed. We are
>> open to discussion if this is not considered a good approach.
>
>
>>

> XV: thanks for this catch. We expanded it in title, abstract and
>> introduction.
>
>
>>

> XV: Done, thanks.

> XV: thanks we corrected that.
>
>
>>

> XV: yes this is correct. We propose to add to the section title the word
>> Specification:
>
> "Requirements for 6top Scheduling Functions (SF) Specification"
>
>
>>

> XV: We need further advise on this. We are ok on moving that content to
>> the IANA Considerations sections if this is the general practice in that
>> type of content. Please advise.
>
>
>>

kind regards
Xavi

>
>
> _______________________________________________
> 6tisch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6tisch
>

-- 
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