Subject: [OPSAWG] FW: (final) WGLC on draft-ietf-opsawg-operations-and-management

From: "David B Harrington" <[email-masked]>
Date: Wed, 25 Feb 2009 16:36:20 -0500

Hi,

Adrian and I have different perspectives on what the document should
say.
Can you please review this thread and comment on the list so the
chairs can decide what the document should say?

Thanks,
dbh

-----Original Message-----
From: David B Harrington [mailto:[email-masked]] 
Sent: Monday, February 16, 2009 10:59 AM
To: 'Adrian Farrel'
Subject: RE: [OPSAWG] (final) WGLC on
draft-ietf-opsawg-operations-and-management

Hi Adrian,

I think there is some correlation between security considerations and
management considerations.
I think part of the motivation for this document is to make it more
so.

For security, you start by analyzing the security needs, and deciding
which ones are relevant to your protocol. You might need to deal with
authentication, confidentiality, integrity checking, replay
protoction, etc. There are a reasonably standardized set of threats to
consider. 

Sometimes, you need to make some adjustment to your protocol to
address threats, but often using an existing standard protocol as-is
can mitigate the threats just fine. Then you normally recommend one of
the standard protocols to mitigate the threats. For interoperability
purposes, it is considered important to specify a
mandatory-to-implement solution, even if other solutions are
acceptable as well.

For management, you should start by analyzing the needs, and deciding
which are relevant to your protocol. Needs often include notifications
for fault or threshold conditions, logging, configuration, performance
monitoring, usage accounting, and security of the management messages
and management datastores. By documenting these common needs here, we
hope to "standardize" them more than they are now. (and this
discussion with you might help me immensely figure out how to
reorganize the document to "tell a story" better).

A protocol may need be adjusted to address the management needs, such
as specifying th eneed to maintain counters, and identifying which
events should be counted. Then, I think it would be very appropriate
to show how one of the standard protocols can be used to address these
needs in an interoperable manner. The IEEE uses this model - it
defines an information model, and then shows how one protocol (GDMO or
a MIB) can represent the information.

This document is not trying to dictate what protocol should be used,
nor is it recommending that the suggested management protocol be
mandatory. 

The IESG can decide whether they want to start requiring
mandatory-to-implement management, similar to BCP61. As far as I am
concerned, if the IESG wants to mandate "strong management" for IETF
protocols, that should be a different document than this discussion of
common "threats".

dbh

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]] 
> Sent: Monday, February 16, 2009 7:25 AM
> To: David B Harrington
> Subject: Re: [OPSAWG] (final) WGLC on 
> draft-ietf-opsawg-operations-and-management
> 
> Hi David,
> 
> > would this be better?
> > OLD:
> >   This document suggests protocol designers consider operations
and
> >   management needs and then recommend appropriate standard 
> management
> >   protocols and data models to address the relevant operations and
> >   management needs.  This is similar to a WG considering which
> >   security threats are relevant to their protocol, and then 
> recommending
> >   appropriate standard security protocols to mitigate the relevant
> >   threats.
> > NEW:
> > Protocol designers should consider operations and management
needs,
> > document how to meet those needs, and suggest standard management
> > protocols and data models that could meet the operations and
> > management needs. This is similar to a working group (WG) that
> > considers which security threats are relevant to their protocol,
> > documents how threats should be mitigated, and then suggests
> > appropriate standard protocols that could mitigate the threats.
> 
> Thanks for engaging...
> 
> My main issue is that it is not germane to the specification 
> of one protocol 
> which other protocol is used for management interactions with 
> devices that 
> implement the specified protocol.
> 
> For example, OSPF is widely implemented. It seems to me that 
> if the OSPF 
> specification had said that "OSPF implementations MUST/SHOULD be 
> configurable using TL1" we would have achieved one of two results:
> 1. OSPF would not have bee successfully or widely deployed.
> 2. Most people would have ignored the specification.
> 
> We don't want to arrive at either of these situation for new 
> protocols.
> 
> I understand that you want to arrive at interoperability of 
> management 
> systems, but I don't think it works like that! For example, we do
not 
> require that all routers support PIM. We say that there is a bunch
of 
> routing protocols, and people can implement what they want. 
> We do specify 
> that a network that runs OSPF must be made up of OSPF-capable 
> routers, and 
> we specify how those routers interoperate when they run OSPF.
> 
> Which routing protocols a device supports is a commercial decision. 
> Purchasers decide which protocols they want to deploy, and 
> buy equipment 
> accordingly. If they want OSPF and PIM, they do not buy 
> devices that support 
> only IS-IS and PIM, or only OSPF and BGP.
> 
> Surely the same applies for management protocols?
> 
> I also really think that this is not like the security 
> considerations. 
> Security techniques are imbedded into the protocol being designed. 
> Management is an adjunct (no matter how important).
> 
> How about...
> 
> Protocol designers should consider operations and management 
> needs, document 
> how to meet those needs, and define a data model for the 
> configuration and 
> management of the protocol. Protocol designers may also 
> suggest the use of 
> one or more standard management protocols as a core subset of 
> management 
> access techniques for implementations of the protocol being
designed.
> Adrian