Hi Francis, Thanks for your review and comments. In discussing the comment resolution process with Adrian, he suggests that I work directly with the commenter to resolve any issues. Please note my in-line comments below and let me know your thoughts.
BTW, I am not sure if I will be drafting a -08 version. I will discuss with Adrian how best to integrate your comments into the draft going forward. Best Regards, Jerry Francis Dupont <francis.dup...@fdupont.fr> Sent by: francis.dup...@fdupont.fr 10/02/2009 03:47 AM To gen-art@ietf.org cc jerald.p.marto...@jci.com, nicolas.r...@fr.schneider-electric.com, pieter.de...@intec.ugent.be, wou...@vooruit.be, adrian.far...@huawei.com Subject review of draft-ietf-roll-building-routing-reqs-07.txt I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-roll-building-routing-reqs-07.txt Reviewer: Francis Dupont Review Date: 2009-09-29 IETF LC End Date: 2009-09-24 IESG Telechat date: unknown Summary: Ready Major issues: None Minor issues: - IMHO the document is a bit USA centric (but it is not a problem if it is stated in the document, for instance with a reference from the (US) building automation community, cf 8.2 comment below) I have received a similar comment before from another reviewer. The other ID authors, as well as the WG chair and Adrian are all European . They have recommended a few terminology changes (e.g. elevator, K-12, HVAC) that might be US focused. Nits/editorial comments: - the language of the document is not at the usual level (but at it should be considered as better it is not a concern) o.k. - 2 page 4, 5.1 and 5.1.1 page 12, 5.3 page 13, 5.4.1 and 5.4.2 page 14. 5.7.2 and 5.7.4 page 16, 5.7.7 page 17. 5.8.4 page 18, 9.2.1 page 20: e.g. -> e.g., o.k. If I draft a version -08, I will make these changes, otherwise, I will ask Adrian to forward these changes to the editors. - 3.1 page 5: use the occasion to introduce the FMS abbrev, i.e., add "(MS)" after "facility management system" Not sure of your comment. The term FMS is actually introduced on p4. Here, the abbreviation is spelled out. FMS is also documented in the 'terminology' ID. - 4 page 10: the P in P2P (and MP2P / P2MP) is ambiguous: it can stand for point and the point-to-point term usually refers to link topology. I propose: P2P -> (peer-to-peer, P2P) (MP2P) -> (multi-peers-to-peer, MP2P) (P2MP) -> (peer-to-multi-peers, P2MP) I am ambivalent about the change; however will defer to the WG Chair (JP Vasseur). I believe JP has the opposite view of these terms being adamant that the abbreviations mean point-to-point, multipoint-to-point and point-to-multipoint respectively. - 4 page 10 and 5.4.3 page 14: acknowledgement -> acknowledgment (for uniformity with the section title where this spelling is enforced) (multiple occurrences) o.k. If I draft a version -08, I will make these changes, otherwise, I will ask Adrian to forward these changes to the editors. - 5.1 page 11: no network knowledge -> no communication network knowledge agreed. - 5.2.2 page 13: even it is also overloaded: point-to-point -> end-to-end Yes. As noted in your comment above (4 page 10), I will discuss with JP. You are correct that I have used 'point-to-point' and 'peer-to-peer' interchangably in this draft. Now you suggest 'end-to-end'. In this instance, I think 'end-to-end' is a good choice. However, with mesh networks we should be clear and consistent in our terms. I will forward a separate email to JP to ask him to clearly state the appropriate nomenclature we should be using. Once defined, I will make the changes throughout the specification accordingly and suggest these terms get added to the 'terminology' ID. - 5.4 page 14: i.e. -> i.e., Yep. ok. - 5.4.3 page 14: 2000mah -> 2000mAh ok. - 5.7.6 page 17: msec -> ms ok. - 7 page 19: J. P. -> JP. ok. - 8.2 page 19: I'd really like to get a reference from the building automation community: explaining networking to them or an introduction for us (networking community) or both. I expect there are at least some framework standards. BACnet (Building Automation Control Network) is an ISO Standard protocol defined and used world-wide for commercial building use. It fully describes six different data link implementations (including UDP IP) with full timing, transport, fragmentation and routing support, as well as a complete object model. I'd suggest this be the Standard you might be looking for. I had BACnet defined as an informative reference in earlier versions of the draft, but was asked to delete it while in review. Maybe this should be added back into the draft. - 9.1.2 page 19: 2.4Ghz -> 2.4GHz (BTW the ISM band text is very USA centric :-) ok. I thought the 2.4GHz ISM band was defined world-wide. I agree that the 900 ISM band is U.S. Centric. I will delete 'ISM' and '900' from the requirement. - 9.3.1 page 20: missing final '.' ok. - Authors' Addresses page 22: unfinished (???), add +1 for USA phone number, -- -> - (and BTW try to use the same separator) ok. Regards francis.dup...@fdupont.fr
_______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
