Hi, Dave, Thank you for the thorough and constructive IoTdir early review — the overall "On the Right Track" label is appreciated, and your comments are well-targeted. We've reviewed each point carefully. Responses inline below.
> On Jan 23, 2026, at 7:01 PM, Dave Thaler via Datatracker <[email protected]> > wrote: > > Document: draft-ietf-opsawg-rfc5706bis > Title: Guidelines for Considering Operations and Management in IETF > Specifications > Reviewer: Dave Thaler > Review result: On the Right Track > > I am the assigned iotdir reviewer for this draft. For background on iotdir, > please see the [FAQ](https://wiki.ietf.org/en/group/iotdir). Please resolve > these comments along with any other comments you may receive. > > A marked-up PDF copy with my comments inline is at > https://1drv.ms/b/c/dc2b364f3f06fea8/IQBuO9rPPwGxRLZZi9kQSJncAT_Aktrn9MuIurcZp88NRjs?e=2boyoh Thanks for sharing this — I am applying all editorials first, and addressing the main comments below. > > I found the checklist of key questions in Appendix A to be well written, > useful, and widely applicable to areas across the IETF, including IoT > protocols. Similarly the content in the body is well-written and useful. Great to see — as wide applicability across IETF areas and usefulness are two of our explicit goals. > > I do have a bunch of comments on the body of the document however to make it > more widely applicable to areas across the IETF. A summary of my main > technical feedback follows, and many other minor editorial points (which > I don't expect should need WG discussion) can be found in my marked up > PDF copy. > > 1) Applicability of requirement: Three different places in the document make > three different, contradictory, statements about which RFCs would be > required to have this section. > a) abstract says all "RFCs in the IETF Stream" > b) 3.1 says all IETF RFCs "that document a technical specification" > c) Appendix B says "all new Standards Track RFCs" > I think section 3.1 is the best and the abstract and Appendix B should > both be changed. Indeed. Agreed. Section 3.1 is the most precise formulation. > > 2) Architecture RFCs: Most places in the document are consistent in saying > documents that specify a "New Protocol" or "Protocol Extension", but one > place in section 3.1 throws in "or an architecture". Generally speaking, > an implementation does not claim conformance to an architecture/framework > document, and so depending on how it is written and the content it may not > be considered a “technical specification”, just a roadmap document. In > that case, the previous paragraph would not require it in such an > architecture document. Furthermore, elsewhere in the document, like the > abstract, focused on requiring it in New Protocols and Protocol Extensions. > As such, I’d remove “or an architecture”. It might be ok in the preceding > paragraph to clarify that “anything an implementation would claim > conformance to is considered a technical specification”, and in my view > that would cover it. Partly agreed. We see the intent of including architecture documents, as they can establish operational patterns that downstream protocol specifications must respect. However, your point about conformance is well-taken. We will revise the text to clarify that architecture documents are expected to include the section only where they introduce new operational considerations with downstream normative implications, and that the exemption in Section 3.2 applies otherwise. We will also remove "or an architecture" from the second paragraph of 3.1. > > 3) Requirements around individual draft -00 submissions: Section 3.1 says > "early revisions of Internet-Drafts are expected to include an > Operational Considerations section". I'd find it a huge process hurdle > to “expect” all -00 versions of individual drafts to have such a section > as that would discourage many new entrants from participating in the IETF. > I might say "encouraged" instead of "expected". Agreed. We will change "expected" to “highly encouraged" for -00 revisions. The intent is to establish a good-practice norm, not create a barrier to participation. > > 4) Operator: I found much of the document, as currently worded, to be way too > _network_ operator focused, for a document that creates a requirement for > all areas, including IoT. Some places say "network operator" and other > places just say "operator". If you widen the term "operator" to be any > person or organization responsible for managing the protocol > implementations, then "operator" is fine but it should be added to the > Terminology section. E.g., is a cloud hosting service an "operator"? Is > a standalone DNS server admin an "operator"? Is an NTP server admin an > "operator"? In a home network, is the household member who configures > devices an "operator"? I'd want the definition to be such that the answer > to all of those is Yes (or else pick a different term that is generic), > so that the recommendations in the document are as widely applicable and > useful as possible. The checklist in Appendix A certainly is good already. Agreed, and this is a substantive improvement. We will add a definition of "Operator" to the Terminology section (Section 2) that encompasses any person or organization responsible for deploying, configuring, and managing protocol implementations — explicitly including network operators, cloud service administrators, IoT fleet managers, home network administrators, DNS/NTP server administrators, and similar roles. We will then do a pass to replace "network operator" with "operator" except where the specific context warrants the narrower term. We will also broaden references to "their network" to include "their systems and devices" where appropriate (e.g., Sections 4.6 and 4.7). > > Similarly there are a bunch of places that only talk about "their network" > (e.g., section 4.6) and "impact ... on the network" (e.g., section 4.7), > rather than about "their devices and bandwidth" or whatever. Impact on > the network is good to talk about but from an operations perspective, the > impact on hosts/devices is also important in my view, and largely missing > it seems. Similarly agreed. > > 5) Network Operation: Section 4.5 contains a statement: >> If the protocol specification requires changes to end hosts, it >> should also indicate whether safeguards exist to protect networks >> from potential overload. > > This statement seems asymmetric and biased in terms of only being from the > perspective of a network operator. Shouldn’t there be a similar statement > that if a protocol specification requires changes to routers it should > indicate whether safeguards exist to protect hosts from potential > overload? My point is really that it seems to be more about protecting > one organization from entities that aren’t under their control. In some > cases the hosts/servers may be more strictly managed than the network > boxes (e.g., in some home networks), and indexing on host vs network is, > in my view, not the right axis here if one is going to be asymmetric in > recommendation. My point is consistent with the wording in 2.1.2 of > RFC 5218 “Protocols that can be deployed by a single group or team … have > a greater chance of success than those that require cooperation across > organizations“ (which makes no distinction between network vs host per se). > We will revise it to make the overload-protection guidance symmetric with respect to both network infrastructure and end hosts/devices. > Section 5.4.4 (Fault Isolation) is ok but seems overly network centric. > Say you have a docker container that is misbehaving in some way… the host > could isolate or quarantine the container. Same for VMs. Or say you have > a process in a host that is misbehaving… the kernel could isolate or > quarantine the process. I’d make the wording here more generic and less > network operator centric. Operations and management is about more than > just network operators per se. The guidance is good and just using more > generic terminology here in terms of stating the principles would make > the section stronger and more impactful in my view. For 5.4.4, we will broaden the fault isolation discussion beyond network-layer isolation to include host-level isolation mechanisms (e.g., process quarantine, container/VM isolation), consistent with the generic section title. > > 6) Internationalization: Section 4.8 suggests that English should be the > default language in implementations for human readable messages. I don't > think this document should make any such recommendation. I do, however, > recommend adding that it must also be possible to identify which language > a message intended for humans is in (e.g., via a language tag). Otherwise, > it cannot be reliably displayed correctly. On Section 4.8: Agreed. We will remove the recommendation that English be the default language, and instead add a recommendation that human-readable messages include a language tag to enable correct identification and rendering. > > Section 5.5 also has an internationalization issue. It cites an IAB > workshop RFC (where such RFCs reflect the consensus of workshop > participants, not the IAB or IETF per se), and then makes a blanket > statement about configuration files that "human-readable strings should > utilize UTF-8" which comes across as saying this is now an IETF consensus > statement. There is IETF consensus on UTF-8 _in protocols_, and more > specifically UTF-8 with NFC (see section 2 of RFC 5198, which can be > cited as a normative reference here) but not in _device-local files_. > The IETF has no recommendation about files since they’re outside the > scope of Protocols per se. Different OS's already diverge in terms of > both normalization form and UTF-8 vs UTF-16. Hence either change the > text to be about strings in protocols (not textual configuration files > like the preceding sentence says) or make it clear that it is not an > IETF recommendation, or else be prepared for an IETF-wide discussion that > will never converge. > On Section 5.5: Agreed. The current text conflates protocol strings with device-local configuration files. We will revise the UTF-8 recommendation to apply specifically to strings in protocols (citing RFC 5198 as a normative reference for UTF-8 with NFC), and either remove or clearly qualify the statement about textual configuration files. > 7) Information Model Design: The document nicely recommends in point 1 of > 5.3.1 to "start with a small set of essential objects", which is great. > I’ve seen cases where someone just exposes everything just because it’s > there, not because there’s any need (“someone might want it”). As a > result, querying all state can be burdensome since it can be large and/or > expensive to query a given value, and can also disincent someone from > implementing the mechanism for querying them as too burdensome to > implement. To determine what is “essential”, I usually recommend > determining what questions need to be answered to troubleshoot, configure, > etc. and exposing the things that are needed to answer those questions. > It might help to say something like this to help readers understand what > is “essential” here. And I think that's consistent with the purpose of > Appendix A's checklist. > > Point 2 in 5.3.1 says "Require that all objects be essential for > management" but I don't follow what that means. Elaborate. > > Point 6 says "Avoid causing critical sections to be heavily instrumented" > I think it’s not just “critical sections” per se, but anything that would > be expensive. E.g., if someone wants to expose a summary object _rather > than the components of it from which the client could do the computation_ > it would still meet criteria 4, but may be expensive to compute. All very good suggestions. We will add clarifying text to Point 1 explaining that "essential" objects are those needed to answer the diagnostic, configuration, and operational questions the protocol is expected to support — avoiding the trap of exposing everything that is technically accessible. We will revise Point 2 to make its intent clearer. We will also revise Point 6 to generalise beyond "critical sections" to anything that would be expensive to query or compute. > > 8) Liveness Detection: section 5.4.1 says: >> Protocol Designers should always build in basic testing features >> (e.g., ICMP echo, UDP/TCP echo service, NULL RPCs (remote procedure >> calls)) that can be used to test for liveness, with an option to >> enable and disable them. > > I’m not convinced there aren’t exceptions, such as maybe for very > constrained IoT devices. Recommend removing “always” and just leaving > it as lower case “should” like other statements in this doc. Agreed. We will remove "always" and retain the lowercase "should", accommodating constrained-device scenarios > > 9) Configuration Management: Continuing my theme of making the document > less network-operator-centric in order to apply more generally, including > to IoT cases... section 5.5 (Configuration Management) comes across to > me as overly network centric for the section title which is nicely > generic. So if you manage a bunch of end hosts, or a bunch of Kubernetes > pods, or a bunch of IoT devices, or a bunch of VMs on a cloud service, > or a bunch of processes on one or more devices, this section should > still apply, but it provides little or no guidance. Either change the > section title and narrow the scope, or else (my preference) broaden the > discussion. For example, it would be remiss to not mention Kubernetes > in a general discussion of configuration management. Similarly, for > IoT devices there are various centralized configuration management > services such as Balena, SocketXP, Golioth, ThingsBoard, etc. One need > not name them (I wouldn't), but simply acknowledging the existence of > popular centralized management platforms would seem appropriate. Agreed. We will broaden Section 5.5 to make it applicable to diverse managed environments > > 10) Operational Consideration section: The rest of the document already > says that this section shouldn't be required in documents that aren't > technical specifications and section 3.1 specifically uses process > documents as an example of when they're not required. Since this > document itself is a process document, it's not required, so why is > it here? If you do keep this section, you could say that explicitly > that it's not required in a document of this type, so people don’t try > to use this as a precedent to create barriers that aren’t required. The section is already written to explicitly acknowledge that no new requirements arise ("there are no new operations or manageability requirements introduced by this document"). However, we can add a sentence explicitly stating that this section is not required for a process document of this type, and that it is included purely to illustrate the exemption mechanism described in Section 3.2, not as a normative precedent. > > 11) Network Device: This term is used in several places (e.g., section 9 > among others) without definition. Is it "a device managed by a > network operator"? Is it "any device on the network, whether > router or end host"? Is it "a device that implements the New Protocol > or Protocol Extension in question"? If you use this term, an entry > in the Terminology section might help. Agreed. We will add. > > 12) Password-based authentication: Section 9 (Security Considerations) > says "The security implications of password-based authentication should > be taken into account when designing a New Protocol or Protocol > Extension." True but this should already be stated in other RFCs, > not specific to O&M considerations per se. So is this sentence really > needed in _this_ document too? It seems anachronistic to me, even > though it's clearly good advice. > Fair observation. The sentence is inherited from RFC 5706. We can reframe as a reference rather than standalone statement. Thank you again for the high-quality review. We look forward to your confirmation that the above resolutions are satisfactory, and will be applying them in our working copy. Best, Carlos. > Dave Thaler > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
