Subject: Re: [OPSAWG] OPS guidance to the non-OPS community

From: Michael MacFaden <[email-masked]>
Date: Fri, 1 Nov 2013 17:22:45 -0700 (PDT)

> 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?
> The point is that we have multiple management frameworks, as opposed to
> only one in the past: SNMP

Right, SNMP is the Internet Standard Management Framework. Yet we've had
RADIUS/DIAMETER alongside SNMP for decades then others come up from time to time COPS-PR. 
So while we've had one primary protocol IETF has others. 

Today I don't think it likely we're ever going back to one. 

Multiple mgmt frameworks I think is a result of the nature of problem first
documented in Bellcore M.3010 breaking down operational practices into FCAPS. 
That the IETF now has more than one mgmt technology is imo a good thing.
But like you said it now takes a conversation to answer the question.

If often explain the role of SNMP in appliances to others who might prefer
to use one web service api for all of FCAPS this way:
In as much as I don't drive moving van to work opting for a small 
commuter car, I find that I do need to pick and choose among mgmt 
protocols appropriately. No one size fits all or plugs into the operational
environment of most operators w/o needing some new adapter.

So for instance if I want to monitor my network, 
its gonna be SNMP hands down. All the gear I have and will buy has it. 
Cost to develop cost to deploy known/cheap. Sure one can argue that IPFIX 
might do it better  but it is not better enough such that the 
cost would make any sense to  business to absorb such cost. 
And just as I'd use IPFIX for  flow accounting or use NETCONF for configuration, 
that's just what is gonna look like. No short cuts or easy asnwers.

My hope is that when IETF comes up with new protocols they build
a decent data model to monitor it and a data model to configure it 
and whatever other model that makes sense and whatever else.

The monitoring data model doesn't have to be SMIv2 but should be generated
such that we get IETF standard oids.

Then when it comes time for me to build a product that uses IETF technology
I am lucky to stand on the shoulders of giants and use high quality
MIB modules, example NTPv4-MIB, IP-MIB, not only in an SNMP agent
but also in the proprietary protocols. Then sometimes I'm not so lucky
as in no SYSLOG-MIB and NFS mib modules.

Mike MacFaden

---

From: "George, Wes" <[email-masked]>
Date: Sun, 3 Nov 2013 17:56:52 -0500

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-masked] [mailto:[email-masked]] On Behalf
> Of Benoit Claise
> Sent: Thursday, October 31, 2013 1:06 PM
> To: [email-masked]
> 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:
> 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.

---

From: Benoit Claise <[email-masked]>
Date: Sun, 03 Nov 2013 16:23:23 -0800

Hi,
> 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…
Good clarification. I meant "tools" or "management" , i.e. protocols and 
data models
> 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. pub…
Right, if we give guidance only based what is used today, we will never 
provide guidance for new tools.
> 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 r…
Exactly, this is what I would like to (try to) solve ... for OPS.

Regards, Benoit
> .

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 4 Nov 2013 02:23:04 +0100

On Thu, Oct 31, 2013 at 06:05:57PM +0100, Benoit Claise wrote:
 
> 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.

[...]

This topic seems to be coming up repeatedly. So either this is a real
problem to work on or it is something new ADs should be told about
because after getting into the job (which takes about two years I have
been told), they will raise this issue.

/js

PS: I am attaching my latest collection of ideas that was last
    modified in November 2012 (!) and I think I did send it to
    Benoit back then.

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Dave Thaler <[email-masked]>
Date: Tue, 5 Nov 2013 04:53:32 +0000

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

> From: George, Wes [mailto:[email-masked]]
> Sent: Sunday, November 3, 2013 2:57 PM
> To: Benoit Claise; [email-masked]
> Cc: Dave Thaler; Joel jaeggli ([email-masked])
> 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
> 
> 
> > From: [email-masked] [mailto:[email-masked]] On
> > Behalf Of Benoit Claise
> > On regular basis, I have to provide these advice How can we share this
> > knowledge?
> 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.

---

From: Saperia Jon <[email-masked]>
Date: Tue, 5 Nov 2013 14:55:35 -0500

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-masked]> wrote:

> _______________________________________________
> OPSAWG mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/opsawg

Thank you 
/jon

Jon Saperia
[email-masked]
Enterprise Architect
Harvard University Information Technology
Innovation & Architecture
(P) (617) 384-6683
1350 Mass Ave., room 758
Cambridge, MA 02138

---

From: Dave Thaler <[email-masked]>
Date: Tue, 5 Nov 2013 20:36:25 +0000

Agree we have too many protocols as is, and that's part of the problem... too much choice causes
confusion.  As the IETF has added protocols (and hence choices), confusion has increased.
The IETF hasn't sufficiently compensated enough by providing (enough) guidance to reduce that confusion.

-Dave (as chair of 2 groups that have had to deal with that confusion)

From: Saperia Jon [mailto:[email-masked]]
Sent: Tuesday, November 5, 2013 11:56 AM
To: Dave Thaler
Cc: George, Wes; Benoit Claise; [email-masked]
Subject: Re: [OPSAWG] OPS guidance to the non-OPS community

/jon
On Nov 4, 2013, at 11:53 PM, Dave Thaler <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: George, Wes [mailto:[email-masked]<http://twcable.com>]
Sent: Sunday, November 3, 2013 2:57 PM
To: Benoit Claise; [email-masked]<mailto:[email-masked]>
Cc: Dave Thaler; Joel jaeggli ([email-masked]<mailto:[email-masked]>)
Subject: RE: [OPSAWG] OPS guidance to the non-OPS community

Benoit -

Wes George

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On
Behalf Of Benoit Claise
Sent: Thursday, October 31, 2013 1:06 PM
To: [email-masked]<mailto:[email-masked]>
Cc: Dave Thaler
Subject: [OPSAWG] OPS guidance to the non-OPS community

Dear all,

Problem 1:

Problem 2:

[email-masked]<mailto:[email-masked]>

Thank you
/jon

Jon Saperia
[email-masked]<mailto:[email-masked]>
Enterprise Architect
Harvard University Information Technology
Innovation & Architecture
(P) (617) 384-6683
1350 Mass Ave., room 758
Cambridge, MA 02138