Document: draft-ietf-scone-protocol Title: Standard Communication with Network Elements (SCONE) Protocol Reviewer: Thomas Fossati Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART) reviews all IETF documents being processed by the IESG for the IETF Chair. Please treat these comments just like any other last call comments. For more information, please see the FAQ at <https://wiki.ietf.org/en/group/gen/GenArtFAQ>. Document: draft-ietf-scone-protocol-07 Reviewer: Thomas Fossati Review Date: 2026-08-28 IETF LC End Date: 2026-09-04 IESG Telechat date: Not scheduled for a telechat Summary: This draft is well written and, in the opinion of this Gen-ART reviewer, ready with just a few nits. By the way, the choice of 67s for the monitoring period is awesome and definitely meme-worthy :-) https://en.wikipedia.org/wiki/6-7 As I am new to SCONE, I read it alongside the companion appman draft to get a bit more context. While doing so, I noticed a few cross-document inconsistencies. Most of them are dangling section references from -appman to -protocol, and a few are terminology-related. I will raise these separately with the appman editors. Major issues: None Minor issues: The §4 title "Conventions and Definitions" is a tad misleading as there are no actual definitions, only BCP 14 boilerplate :-) I didn't notice this on the first read, but then appman's §2 explicitly states, "This document uses terms and definitions described in [I-D.ietf-scone-protocol]" so I went back to this section for terminology and got ENOTFOUND. Now, some key terms that are used throughout both domucents (e.g., "throughput advice", "rate signal", "monitoring period", "network element") are only defined informally and scattered across the Overview, Applicability, and Packet sections. My suggestion would therefore be either to rename §4 to "Requirements Language", or (better) to add a short list of terms so that appman's ref is meaningful. Nits/editorial comments: If this is supposed to be Python, I'd be suspicious of the following: packet[1] = (packet[1] & 0x7f) | (target_signal << 7). especially if "packet" is a bytearray. Perhaps use "(target_signal & 0x1) << 7", which should be equivalent in spirit and more robust. _______________________________________________ Gen-art mailing list -- [email protected] To unsubscribe send an email to [email protected]
