RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP

["David B Harrington" <[e-mail]>]

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