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

From: Xavi Vilajosana Guillen <[email-masked]>
Date: Thu, 21 Jun 2018 12:42:40 +0200

Dear Ben,

today we published a new version of the draft including the changes
mentioned in our responses.

thanks for the provided reviews.
Xavi

2018-04-05 12:09 GMT+02:00 Xavi Vilajosana Guillen <[email-masked]>:

> 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]>:
>
>> 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.
>>
>>
>>>
>>> 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."
>>
>>
>>> §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?
>>
>>
>
>>
>>
>> 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.
>>
>>
>>>
>
>>
>>
>>
>>> 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)
>>
>>
>>>
>
>> XV: thanks for this catch. We expanded it in title, abstract and
>>> introduction.
>>
>>
>>>
>
>> §1: Please expand 6TiSCH on first mention.
>>
>>
>>>
>
>> XV: Done, thanks.
>>
>>
>>>
>
>> §3.1.1, Figure 4, step 2: "Node A locks the candidate cells in it schedule
>>
>> until..." doesn't parse. Should "it" be "its"?
>>
>>
>>>
>
>> XV: thanks we corrected that.
>>
>>
>>>
>
>> §4: This section seems to be about 6top scheduling function
>>> _specification_,
>>
>> not the functions themselves. Is this correct?
>>
>>
>>>
>
>> XV: yes this is correct. We propose to add to the section title the word
>>> Specification:
>>
>> "Requirements for 6top Scheduling Functions (SF) Specification"
>>
>>
>>>
>
>>
>>> Appendix A: Seems like this should be part of the IANA considerations.
>>
>>
>>>
>
>> 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
> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g>
> 08860 Castelldefels (Barcelona). Catalonia. Spain
> <https://maps.google.com/?q=Av+Carl+Friedrich+Gauss+5,+B3+Building+08860+Castelldefels+(Barcelona).+Catalonia.+Spain&entry=gmail&source=g>
> 
>

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