Re: [OPS-NM] RE: [MIB-DOCTORS] MandatoryRequirementforconfigurationby SNMP

["Randy Presuhn" <[e-mail]>]

Hi -

I think the question comes down to this:

    We have a sub-optimal technology.
    We have another, nascent technology.
    There are various other proprietary technologies.

    Stuff needs to be managed.

    Our choice is this:

       (a) because we don't have a perfect solution, we
            should use "SHOULD", giving up interoperability in
            order to encourage more experimentation

       (b) we recognize that (imperfect) interoperability
             is better than none at all, and use "MUST",
             recognizing that when the ultimate solution
             comes along, that guideline will need to be
             changed.

It's not about supporting multi-protocol environments or
recognizing the need for research into better solutions.
It's about deciding how pressing the need for interoperable
management is *now*.  Of course, the cynics will say that
since we've gotten this far without interoperable management,
why start mandating it?
    
Randy

----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <[e-mail]>
To: "David B Harrington" <[e-mail]>; "Jon Saperia" <[e-mail]>
Cc: "MIB Doctors" <[e-mail]>; <[e-mail]>
Sent: Monday, November 06, 2006 6:09 PM
Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] MandatoryRequirementforconfigurationby SNMP 


(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
> 


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