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.

 

 

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]

Reply via email to