I agree with Adrian's point about focusing the document on the description/contents of the Operational Considerations section.
I understand the importance of considering operations and management from the start, and how calling it out in a charter may help. However, requiring (or even suggesting) items on a charter is not what this document should be about. My 1c. Alvaro. On July 16, 2025 at 4:40:59 AM, Adrian Farrel ([email protected]) wrote: My feeling is that *any* discussion of what a charter bcp14-includes is a very good thing: the current IESG is all over the place, lacking consistency, and randomly blicking (re)charters with personal opinions of what the process is. I even believe that the community must write this stuff down and take it out of the IESG's hands. However, *this* is not the document to cover that topic, and I strongly feel that it should not go near it. Not even a hint that ADs should think about operational aspects when chartering. This document is about what goes in a subset of all new RFCs. Anything else is a distraction. A On 16/07/2025 09:08 BST [email protected] wrote: Hi Benoît, all As an input to the chartering discussion but without any intention to interfere with the ongoing discussion, I’d like to remind that we do have the following OPS-related items in rfc2418#Section 2.2: == To facilitate evaluation of the intended work and to provide on- going guidance to the working group, the charter must describe the ^^^^^^^^^^ problem being solved and should discuss objectives and expected ^^^^^^^^^^^^^^ ^^^^^^^^ impact with respect to: ^^^^^^^^^^^^^^^^^^ - Architecture - Operations <======================= - Security - Network management <================== - Scaling <============================= - Transition (where applicable) <======= == Cheers, Med *De :* Benoit Claise <[email protected]> *Envoyé :* mercredi 16 juillet 2025 09:39 *À :* Alvaro Retana <[email protected]>; [email protected] *Cc :* [email protected]; BOUCADAIR Mohamed INNOV/NET < [email protected]> *Objet :* Re: Scope creep: Initial Shepherd Review of draft-opsarea-rfc5706bis-03 Hi Alvaro, Thanks for your review. Just one comment has not been discussed so far. (5) Scope creep? §1.2 (Audience) mentions several potential uses of this document beyond documenting the operational and manageability considerations for New Protocols or Protocol Extensions, for example: "Area Director who is in the process of creating a new WG Charter...OPS Directorate can use this document to guide performing reviews". But there is no guidance on how ADs should use the document when chartering. A reference is provided to the OPS Dir checklist. IMO, both potential uses should be outside the scope of the document. [May be related to https://github.com/IETF-OPSAWG-WG/draft-opsarea-rfc5706bis/issues/65] Regarding "But there is no guidance on how ADs should use the document when chartering", I understand that the following text is a little bit light: As an Area Director who is in the process of creating a new WG Charter, this document lists some considerations of the functionality needed to operate and manage New Protocols and Protocol Extensions. As previous OPS AD, I was convinced of the importance of addressing the manageability and operational aspects early in the process (to state the obvious). A DISCUSS, at the very last step in the process, has never been an ideal tool to send the WG back to the drawing board. This sentence above, which I wrote, wanted to stress that this RFC *can *be used as input at charter creation time, with a list of "OPS things" that the new WG & IESG in the end might be thinking about when approving the charter text. Before updating the text, do we agree about the intended goal? Regards, Benoit ____________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.
_______________________________________________ OPSAWG mailing list -- [email protected] To unsubscribe send an email to [email protected]
