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 protected]>: > 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 protected] > https://www.ietf.org/mailman/listinfo/6tisch > -- Dr. Xavier Vilajosana Wireless Networks Lab *Internet Interdisciplinary Institute (IN3)Professor* (+34) 646 633 681 [email protected] <[email protected]> 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 [image: Universitat Oberta de Catalunya]
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
