RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirementforconfigurationby SNMP

["Romascanu, Dan \(Dan\)" <[e-mail]>]

(I took out Mark from the distribution list, I do not believe that he is
interested to follow, as the discussion raised at a more generic level) 
 
I believe that we tried to work a single protocol solution for about ten
years or more. By 2002 we acknowledged for all practical purposes that
we failed or at least that the operators world does not buy our approach
and started to work on NETCONF for configuration operations. In reality
we are already in a multi-protocol world even without NETCONF, as
multiple protocols are being used for management operations. People use
today RADIUS and XCAP for example for different configuration
operations. Even if we believed (I am skeptic) that the development of a
new single protocol is possible, or that NETCONF can be developped into
becoming one, it will take years to get there. Until then we need to
provide a new management framework that accommodates the reality of the
multi-protocol world of today on the lines of what you suggest in the
last two paragraphs of your mail. We also need to somehow relax the
manageability requirements from the authors of protocol documents in the
IETF, so that they do not feel obliged to develop MIB modules that are
not used or only partially used. 
 
Dan
 
 
 
 


  _____  

	From: David B Harrington [mailto:[e-mail]] 
	Sent: Tuesday, November 07, 2006 3:44 AM
	To: 'Jon Saperia'
	Cc: 'MIB Doctors'; 'Mark Townsley'; [e-mail]
	Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory
Requirementforconfigurationby SNMP 
	
	
	Hi,
	 
	I think the OPS-NM community and the whole IETF and the operator
community need to make a decision about whether the right approach is to
have a multi-protocol solution, or a single protocol solution.
	 
	If we accept a multi-protocol approach, then the MUST should be
a SHOULD in the management requirements. However, we need to be very
clear how to make the different interfaces "interoperable" (e.g. they
need to be able to share data, reuse security approaches, correlate
different access control policies, etc.). The balance of security
properties is a special concern, because it maks little sense to put a
multi-lock stell door on the front of the house, and only an unsecured
screen door on the back of the house.
	 
	If we accept one-protocol-to-do-all-FCAPS, then the MUST should
be a MUST, and the IETF NM community needs to define how the protocol
and data models and transport and secuirty can be extended to perform
the functions which the original protocol does not necessarily do well.
So if SNMP is kept as the single protocol, we need to make it possible
to add such things as task-oriented interfaces (functions/methods), and
support for XML rather than ASN.1 and BER, among other things.
	 
	My personal preference is to stay with a single protocol to do
all things, because it offers the best interoperability, BUT NOT because
I like SNMP. I find the peek-poke design of SNMP to be comparable to
assembly language. That was approrpriate for 1988, but it is no longer
adequate in 2006. We need to bring our one-interface up to at least a
functional programming interface style, and possibly to a design that
offers some of the benefits (and hopefully not all the problems of) an
object-oriented design. A one-protocol solution needs to be changed to
allow support of functionality that is more consistent with real
operational requirements.  
	 
	If we cannot update our one protoocl to an interface that is
more consistent with good software programming approaches, then we
should move to a multi-protocol approach and at least shoot for
interoperable monitoring, plus interoperable configuration, plus
interoperable accounting, and so on.
	 
	One approach that is a compromise is to allow multiple protocols
to utilize a consistent MIB approach, but to update the MIB information
model to use an XML interface rather than OIDs/ASN.1/BER, and to develop
mechanisms to extend the capabilities of the MIB information modeling to
match real world data structures.
	 
	(and Mark, I apologize if you don't want to be involved in this
whole discussion.)
	 
	David Harrington
	[e-mail]
	[e-mail]
	[e-mail]
	

	 
	 
	 
	 


  _____  

		From: Jon Saperia [mailto:[e-mail]] 
		Sent: Monday, November 06, 2006 4:00 PM
		To: David B Harrington
		Cc: 'Randy Presuhn'; 'MIB Doctors'; [e-mail];
'Mark Townsley'
		Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory
Requirement forconfigurationby SNMP 
		
		
		David, 

		This is certainly one way to go. Another possibility
would be to:

		1. Create a single standard that all believe meet all
needs WRT FCAPS. 
		2. The IETF would then be in a position to define a core
set of objects in all areas that would support interoperability better
and with less cost than is currently the case.

		In the interim, your suggestion is perhaps the best that
can be done.
		/jon
		
		On Nov 6, 2006, at 3:14 PM, David B Harrington wrote:


			Hi Randy,

			I think we need to prepare other WGs to move to
a multi-protocol
			Management Framework, but we do not yet have a
standardized
			multi-protocol solution for them to move to.
Until we have a data
			model for netconf (presuming netconf will be the
second NM protocol
			supported), we should still stress the
importance of making IETF
			technologies manageable with standardized NM
solutions. 

			That means we still need to stress the
importance of providing a data
			model in our only existng standard data modeling
language, SMIv2,
			until a new data modeling language becomes
available.

			Between now and then we should ask the
managed-technology WGs to
			develop a MIB module for management now, and
request a corresponding
			information model that can be used to develop a
netconf data model
			later.

			AND between now and then, the management
protocol development
			community needs to figure out how to make the
two protocols
			compatible, so we do not have two standard
protocols that cannot share
			information.

			David Harrington
			[e-mail] 
			[e-mail]
			[e-mail]



				-----Original Message-----
				From: Randy Presuhn
[mailto:[e-mail]] 
				Sent: Monday, November 06, 2006 11:03 AM
				To: 'MIB Doctors'; [e-mail]
				Cc: 'Mark Townsley'
				Subject: Re: [OPS-NM] RE: [MIB-DOCTORS]
Mandatory Requirement 
				forconfigurationby SNMP 

				Hi -


				From: "David B Harrington"
<[e-mail]>
				To: "'Romascanu, Dan (Dan)'"
<[e-mail]>; "'MIB 

				Doctors'" <[e-mail]>;
<[e-mail]>

				Cc: "'Mark Townsley'"
<[e-mail]>
				Sent: Sunday, November 05, 2006 10:34 AM
				Subject: [OPS-NM] RE: [MIB-DOCTORS]
Mandatory Requirement 

				for configurationby SNMP 
				...

				Since possible alternatives are on the
horizon, and the IETF
				management framework has always
permitted the support for 

				alternative

				protocols for carrying MIB module data,
I suggest that any 

				long-lived

				requirements section RECOMMEND, but not
REQUIRE, SNMP so that
				alternative protocols could be used in
the future to meet these
				management functionality requirements.

				However, I believe that MIB modules and
support for SNMP should
				continue to be required as a condition
of IETF standards-track
				advancement until suitable alternative
solutions are completed and
				available.

				...

				I'm having trouble fitting these two
paragraphs together.
				The first is consistent with the changes
suggested, but
				the second is a strong argument against
making those
				changes.

				Randy


	
_______________________________________________
				MIB-DOCTORS mailing list
				[e-mail]
	
https://www1.ietf.org/mailman/listinfo/mib-doctors





			_______________________________________________
			OPS-NM mailing list
			[e-mail]
			https://www1.ietf.org/mailman/listinfo/ops-nm


		
		Jon Saperia

_______________________________________________
OPS-NM mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/ops-nm