Hi Thomas, See https://github.com/ietf-wg-scone/scone/pull/161 for my version of your suggested actions.
Thanks for helping make this work better. On Fri, Aug 28, 2026, at 10:41, Thomas Fossati via Datatracker wrote: > 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]
