Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG31-0002OJ-6x; Mon, 06 Nov 2006 20:46:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GhG2z-0002NZ-88; Mon, 06 Nov 2006 20:46:41 -0500 Received: from sccrmhc12.comcast.net ([63.240.77.82]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GhG2y-0003gN-Hd; Mon, 06 Nov 2006 20:46:41 -0500 Received: from harrington73653 (dhcp71-105.ietf67.org[130.129.71.105]) by comcast.net (sccrmhc12) with SMTP id <2006110701463801200ms4roe>; Tue, 7 Nov 2006 01:46:38 +0000 From: "David B Harrington" To: "'Jon Saperia'" Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP Date: Mon, 6 Nov 2006 17:44:04 -0800 Message-ID: <052901c7020e$36357820$0600a8c0@china.huawei.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 In-reply-to: <73FEF235-3091-48E5-BAAF-7850240F4FF2@jdscons.com> Thread-Index: AccB/7BVucB/2EtHSpegI5EYiulfbAABYXTA X-Spam-Score: 0.0 (/) X-Scan-Signature: 0aa23132abbc731e36938583486affe0 Cc: 'MIB Doctors' , 'Mark Townsley' , ops-nm@ietf.org X-BeenThere: ops-nm@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: OPS Area NM e-mail list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0404713294==" Errors-To: ops-nm-bounces@ietf.org This is a multi-part message in MIME format. --===============0404713294== Content-Type: multipart/alternative; boundary="----=_NextPart_000_052A_01C701CB.28123820" This is a multi-part message in MIME format. ------=_NextPart_000_052A_01C701CB.28123820 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net _____ From: Jon Saperia [mailto:saperia@jdscons.com] Sent: Monday, November 06, 2006 4:00 PM To: David B Harrington Cc: 'Randy Presuhn'; 'MIB Doctors'; ops-nm@ietf.org; '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 dharrington@huawei.com dbharrington@comcast.net ietfdbh@comcast.net -----Original Message----- From: Randy Presuhn [mailto:randy_presuhn@mindspring.com] Sent: Monday, November 06, 2006 11:03 AM To: 'MIB Doctors'; ops-nm@ietf.org Cc: 'Mark Townsley' Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP Hi - From: "David B Harrington" To: "'Romascanu, Dan (Dan)'" ; "'MIB Doctors'" ; Cc: "'Mark Townsley'" 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 MIB-DOCTORS@ietf.org https://www1.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ OPS-NM mailing list OPS-NM@ietf.org https://www1.ietf.org/mailman/listinfo/ops-nm Jon Saperia ------=_NextPart_000_052A_01C701CB.28123820 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
 
I think the OPS-NM community and the whole IETF = and the=20 operator community need to make a decision about whether the right = approach is=20 to have a multi-protocol solution, or a single protocol=20 solution.
 
If we accept a multi-protocol approach, then = the MUST=20 should be a SHOULD in the management requirements. However, we need = to be=20 very clear how to make the different interfaces "interoperable" (e.g. = they need=20 to be able to share data, reuse security approaches, correlate different = access=20 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=20 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=20 should be a MUST, and the IETF NM community needs to define how the=20 protocol and data models and transport and secuirty can = be extended to=20 perform the functions which the original protocol does not necessarily = do=20 well.  So if SNMP is kept as the single protocol, we need to = make it=20 possible to add such things as task-oriented interfaces = (functions/methods), and=20 support for XML rather than ASN.1 and BER, among other=20 things.
 
My personal preference is to stay with a single = protocol to=20 do all things, because it offers the best interoperability, BUT NOT = because I=20 like SNMP. I find the peek-poke design of SNMP to be comparable to = assembly=20 language. That was approrpriate for 1988, but it is no longer adequate = in 2006.=20 We need to bring our one-interface up to at least a functional = programming=20 interface style, and possibly to a design that offers some of the = benefits (and=20 hopefully not all the problems of) an object-oriented design. A=20 one-protocol solution needs to be changed to allow support of = functionality that=20 is more consistent with real operational requirements. =20
 
If we cannot update our one protoocl to an = interface that=20 is more consistent with good software programming approaches, then we = should=20 move to a multi-protocol approach and at least shoot for interoperable=20 monitoring, plus interoperable configuration, plus interoperable = accounting, and=20 so on.
 
One approach that is a compromise is to allow = multiple=20 protocols to utilize a consistent MIB approach, but to update the MIB=20 information model to use an XML interface rather than OIDs/ASN.1/BER, = and to=20 develop mechanisms to extend the capabilities of the MIB information = modeling to=20 match real world data structures.
 
(and Mark, I apologize if you don't want to be = involved in=20 this whole discussion.)
 

David=20 Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfd= bh@comcast.net

 
 
 
 

From: Jon Saperia = [mailto:saperia@jdscons.com]=20
Sent: Monday, November 06, 2006 4:00 PM
To: David = B=20 Harrington
Cc: 'Randy Presuhn'; 'MIB Doctors'; = ops-nm@ietf.org;=20 'Mark Townsley'
Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] = Mandatory=20 Requirement forconfigurationby SNMP

David,

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

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

In the interim, your suggestion is perhaps the best that can be=20 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=20 multi-protocol
Management Framework, but we do not yet = have a=20 standardized
multi-protocol solution for them to move = to. Until=20 we have a data
model for netconf (presuming netconf will = be the=20 second NM protocol
supported), we should still stress the = importance=20 of making IETF
technologies manageable with standardized = NM=20 solutions.

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

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

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

David Harrington
dharrington@huawei.com
dbharrington@comcast.net
ietfdbh@comcast.net


-----Original Message-----
From: Randy Presuhn [mailto:randy_presuhn@mindspr= ing.com]
Sent: Monday, November 06, 2006 11:03 = AM
To: 'MIB Doctors'; ops-nm@ietf.org
Cc: 'Mark Townsley'
Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] = Mandatory=20 Requirement
forconfigurationby SNMP

Hi -

From: "David B Harrington" <dbharrington@comcast.net>=
To: "'Romascanu, Dan (Dan)'" <dromasca@avaya.com>; = "'MIB
Doctors'" <mib-doctors@ietf.org>; = <ops-nm@ietf.org>
Cc: "'Mark Townsley'" <townsley@cisco.com>
Sent: Sunday, November 05, 2006 10:34 = AM
Subject: [OPS-NM] RE: [MIB-DOCTORS] = Mandatory=20 Requirement =
for configurationby SNMP
...
Since possible alternatives are on = the horizon,=20 and the IETF
management framework has always = permitted the=20 support for =
alternative
protocols for carrying MIB module = data, I=20 suggest that any=20
long-lived
requirements section RECOMMEND, but = not=20 REQUIRE, SNMP so that
alternative protocols could be used = in the=20 future to meet these
management functionality = requirements.

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

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

Randy


_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www1.= ietf.org/mailman/listinfo/mib-doctors




_______________________________________________
OPS-NM mailing list
OPS-NM@ietf.org
https://www1.ietf.= org/mailman/listinfo/ops-nm

Jon=20 Saperia

------=_NextPart_000_052A_01C701CB.28123820-- --===============0404713294== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-NM mailing list OPS-NM@ietf.org https://www1.ietf.org/mailman/listinfo/ops-nm --===============0404713294==--