Benoit - I think there's a more basic question. What is "ops" in this context and how do we as the IETF or OPSArea expect to represent it to "non-ops"? What's the desired outcome and audience - just to give those working within other areas of the IETF better guidance on tools? That sounds more like the operative word is "tools" or "management" not ops.
If you are instead referring to broader operational feedback outside of IETF, that asks a second question - is IETF still the right venue for this? Do we have the credibility and experience? There are other initiatives aimed at providing feedback from operations (BCOP, the *NOG community, Deploy 360, etc) that have better operator participation than IETF, so I'd be hesitant to reinvent the wheel here. If the main goal is to update guidance more consistently and frequently based on what tools are in common use, you'd get better results from surveying a much wider community periodically - e.g. publishing a survey on *NOG lists, and using that to inform your results. Your other fundamental question seems to be - how do we make IETF recommendations, discussions of pros/cons for different tools and solutions, etc more accessible for those who don't really fancy reading RFCs? Most of your examples seem to indicate that we'd be better with some sort of system that pulls the relevant info out of multiple RFCs and presents them in one place based on the subject, rather than expecting people to find the relevant document(s) and then follow a chain of document, updated document, updated updated document, obsoleted section, erratum, etc to synthesize the actual current recommendation from all of the pieces. It's a real issue, but one much larger than OpsArea. Wes George > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf > Of Benoit Claise > Sent: Thursday, October 31, 2013 1:06 PM > To: [email protected] > Cc: Dave Thaler > Subject: [OPSAWG] OPS guidance to the non-OPS community > > Dear all, > > During the OPSAWG/OPSAREA meeting, I will be addressing one issue that > is now on the top of my mind: OPS guidance to the non-OPS community. > > Problem 1: > How do we share our OPS knowledge? How do we advice which OPS tools > (NETCONF, SNMP, AAA, ping, syslog, IPFIX, etc...) the community should > be using? > > On regular basis, I have to provide these advice > How can we share this knowledge? > This is the perfect job for an OPS advisor, but one OPS advisor in all > WGs doesn't scale. > > Problem 2: > What are the OPS recommendations for future developments? > It might appear as the same problem as 1, but the audience is different. > Here, we speak about new charters for example. This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
