FWIW, the challenges in management are not related to protocols, we have too many as it is. It is good for groups to have focus, and if this group has its focus on protocols, that is fine. Another protocol will only make things more difficult for operational people and likely add cost to the products we buy.
/jon On Nov 4, 2013, at 11:53 PM, Dave Thaler <[email protected]> wrote: > As a WG chair, I would find "management" guidance extremely useful. > Outside of the OPS area, my WGs do protocols. But of course people > want to do management, monitoring, logging, etc. of those protocols. > > So we get proposals to do logging with IPFIX, Syslog, etc. > And we get proposals to do management with Netconf, SNMP, etc > (and if you extend "management" to include all types of configuration > that would include DHCP and Router Advertisements in that list too). > And we get RADIUS, etc proposals. > > People in other WGs are experts on their own protocol, rather than > on the protocols for all the other aspects mentioned above, and > any guidance is not only appreciated, it is needed. > > How should non-OPS WGs evaluate which ones they need, or do > we just arbitrarily adopt specific proposals just because no one proposed > alternatives? > > Thanks Benoit for starting this discussion, > -Dave > >> -----Original Message----- >> From: George, Wes [mailto:[email protected]] >> Sent: Sunday, November 3, 2013 2:57 PM >> To: Benoit Claise; [email protected] >> Cc: Dave Thaler; Joel jaeggli ([email protected]) >> Subject: RE: [OPSAWG] OPS guidance to the non-OPS community >> >> 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 Thank you /jon Jon Saperia [email protected] Enterprise Architect Harvard University Information Technology Innovation & Architecture (P) (617) 384-6683 1350 Mass Ave., room 758 Cambridge, MA 02138
_______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
