RE: RE: [MIB-DOCTORS] Mandatory Requirementforconfigurationby SNMP
"Romascanu, Dan \(Dan\)" <[email protected]> Tue, 7 Nov 2006 04:09:17 +0200
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <AAB4B3D3CF0F454F98272CBE187FDE2F0BAC6AA1@is0004avexu1.global.avaya.com> |
This is a multi-part message in MIME format. --===============1421866067== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C70211.BAEF8090" This is a multi-part message in MIME format. ------_=_NextPart_001_01C70211.BAEF8090 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable (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)=20 =20 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.=20 =20 Dan =20 =20 =20 =20 _____ =20 From: David B Harrington [mailto:[email protected]]=20 Sent: Tuesday, November 07, 2006 3:44 AM To: 'Jon Saperia' Cc: 'MIB Doctors'; 'Mark Townsley'; [email protected] Subject: RE: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirementforconfigurationby SNMP=20 =09 =09 Hi, =20 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. =20 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. =20 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. =20 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. =20 =20 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. =20 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. =20 (and Mark, I apologize if you don't want to be involved in this whole discussion.) =20 David Harrington [email protected] [email protected] [email protected] =09 =20 =20 =20 =20 _____ =20 From: Jon Saperia [mailto:[email protected]]=20 Sent: Monday, November 06, 2006 4:00 PM To: David B Harrington Cc: 'Randy Presuhn'; 'MIB Doctors'; [email protected]; 'Mark Townsley' Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP=20 =09 =09 David,=20 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.=20 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 =09 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.=20 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 [email protected]=20 [email protected] [email protected] -----Original Message----- From: Randy Presuhn [mailto:[email protected]]=20 Sent: Monday, November 06, 2006 11:03 AM To: 'MIB Doctors'; [email protected] Cc: 'Mark Townsley' Subject: Re: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement=20 forconfigurationby SNMP=20 Hi - From: "David B Harrington" <[email protected]> To: "'Romascanu, Dan (Dan)'" <[email protected]>; "'MIB=20 Doctors'" <[email protected]>; <[email protected]> Cc: "'Mark Townsley'" <[email protected]> Sent: Sunday, November 05, 2006 10:34 AM Subject: [OPS-NM] RE: [MIB-DOCTORS] Mandatory Requirement=20 for configurationby SNMP=20 ... Since possible alternatives are on the horizon, and the IETF management framework has always permitted the support for=20 alternative protocols for carrying MIB module data, I suggest that any=20 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 =09 _______________________________________________ MIB-DOCTORS mailing list [email protected] =09 https://www1.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ OPS-NM mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-nm =09 Jon Saperia ------_=_NextPart_001_01C70211.BAEF8090 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; = charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.2900.2963" name=3DGENERATOR></HEAD> <BODY=20 style=3D"WORD-WRAP: break-word; khtml-nbsp-mode: space; = khtml-line-break: after-white-space"> <DIV><SPAN class=3D353395401-07112006><FONT face=3DArial color=3D#0000ff = size=3D2><STRONG><EM>(I took out Mark from the distribution list, I do = not believe=20 that he is interested to follow, as the discussion raised at a more = generic=20 level) </EM></STRONG></FONT></SPAN></DIV> <DIV><SPAN class=3D353395401-07112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></EM></STRONG></SPAN> </DIV> <DIV><SPAN class=3D353395401-07112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>I believe that we tried to work a single protocol solution for = about ten=20 years or more. By 2002 we acknowledged for all practical purposes that = we failed=20 or at least that the operators world does not buy our approach and = started to=20 work on NETCONF for configuration operations. In reality we are already = in a=20 multi-protocol world even without NETCONF, as multiple protocols are = being used=20 for management operations. People use today RADIUS and XCAP for example = for=20 different configuration operations. Even if we believed (I am skeptic) = that the=20 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=20 we need to provide a new management framework that accommodates the = reality of=20 the multi-protocol world of today on the lines of what you suggest = in the=20 last two paragraphs of your mail. We also need to somehow relax the=20 manageability requirements from the authors of protocol documents in the = IETF,=20 so that they do not feel obliged to develop MIB modules that are not = used or=20 only partially used. </FONT></EM></STRONG></SPAN></DIV> <DIV><SPAN class=3D353395401-07112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></EM></STRONG></SPAN> </DIV> <DIV><SPAN class=3D353395401-07112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2>Dan</FONT></EM></STRONG></SPAN></DIV> <DIV><SPAN class=3D353395401-07112006><STRONG><EM><FONT face=3DArial = color=3D#0000ff=20 size=3D2></FONT></EM></STRONG></SPAN> </DIV> <DIV> </DIV> <DIV> </DIV> <DIV> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> David B Harrington=20 [mailto:[email protected]] <BR><B>Sent:</B> Tuesday, November = 07, 2006=20 3:44 AM<BR><B>To:</B> 'Jon Saperia'<BR><B>Cc:</B> 'MIB Doctors'; 'Mark = Townsley'; [email protected]<BR><B>Subject:</B> RE: [OPS-NM] RE: = [MIB-DOCTORS]=20 Mandatory Requirementforconfigurationby SNMP <BR></FONT><BR></DIV> <DIV></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>Hi,</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>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.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>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=20 need to be able to share data, reuse security approaches, correlate = different=20 access control policies, etc.). The balance of security properties is = a=20 special concern, because it maks little sense to put a multi-lock = stell door=20 on the front of the house, and only an unsecured screen door on the = back of=20 the house.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>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=20 to 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),=20 and support for XML rather than ASN.1 and BER, among other=20 things.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>My personal preference is to stay with a = single protocol=20 to do all things, because it offers the best interoperability, BUT NOT = because=20 I 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=20 2006. We need to bring our one-interface up to at least a functional=20 programming interface style, and possibly to a design that offers some = of the=20 benefits (and hopefully not all the problems of) = an object-oriented=20 design. A one-protocol solution needs to be changed to allow support = of=20 functionality that is more consistent with real operational=20 requirements. </FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>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 = monitoring, plus interoperable configuration, plus interoperable = accounting,=20 and so on.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>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=20 to match real world data structures.</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2>(and Mark, I apologize if you don't want to = be involved=20 in this whole discussion.)</FONT></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><!-- = Converted from text/plain format --> <P><FONT size=3D2>David=20 = Harrington<BR>[email protected]<BR>[email protected]<BR>ietfd= [email protected]<BR></FONT></P></SPAN></DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV> <DIV dir=3Dltr align=3Dleft><SPAN class=3D140413900-07112006><FONT = face=3DArial=20 color=3D#0000ff size=3D2></FONT></SPAN> </DIV><BR> <BLOCKQUOTE dir=3Dltr=20 style=3D"PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #0000ff 2px = solid; MARGIN-RIGHT: 0px"> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr = align=3Dleft> <HR tabIndex=3D-1> <FONT face=3DTahoma size=3D2><B>From:</B> Jon Saperia=20 [mailto:[email protected]] <BR><B>Sent:</B> Monday, November 06, = 2006 4:00=20 PM<BR><B>To:</B> David B Harrington<BR><B>Cc:</B> 'Randy Presuhn'; = 'MIB=20 Doctors'; [email protected]; 'Mark Townsley'<BR><B>Subject:</B> Re: = [OPS-NM]=20 RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP=20 <BR></FONT><BR></DIV> <DIV></DIV>David,=20 <DIV><BR class=3Dkhtml-block-placeholder></DIV> <DIV>This is certainly one way to go. Another possibility would be = to:</DIV> <DIV><BR class=3Dkhtml-block-placeholder></DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: = pre"></SPAN>1. Create a=20 single standard that all believe meet all needs WRT FCAPS. </DIV> <DIV><SPAN class=3DApple-tab-span style=3D"WHITE-SPACE: = pre"></SPAN>2. The IETF=20 would then be in a position to define a core set of objects in all = areas=20 that would support interoperability better and with less cost than = is=20 currently the case.</DIV> <DIV><BR class=3Dkhtml-block-placeholder></DIV> <DIV>In the interim, your suggestion is perhaps the best that can be = done.</DIV> <DIV>/jon<BR> <DIV> <DIV>On Nov 6, 2006, at 3:14 PM, David B Harrington wrote:</DIV><BR=20 class=3DApple-interchange-newline> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">Hi Randy,</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">I think we need to prepare other WGs to = move to a=20 multi-protocol</DIV> <DIV style=3D"MARGIN: 0px">Management Framework, but we do not yet = have a=20 standardized</DIV> <DIV style=3D"MARGIN: 0px">multi-protocol solution for them to = move to.=20 Until we have a data</DIV> <DIV style=3D"MARGIN: 0px">model for netconf (presuming netconf = will be the=20 second NM protocol</DIV> <DIV style=3D"MARGIN: 0px">supported), we should still stress the = importance=20 of making IETF</DIV> <DIV style=3D"MARGIN: 0px">technologies manageable with = standardized NM=20 solutions.<SPAN class=3DApple-converted-space> </SPAN></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">That means we still need to stress the = importance=20 of providing a data</DIV> <DIV style=3D"MARGIN: 0px">model in our only existng standard data = modeling=20 language, SMIv2,</DIV> <DIV style=3D"MARGIN: 0px">until a new data modeling language = becomes=20 available.</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">Between now and then we should ask the=20 managed-technology WGs to</DIV> <DIV style=3D"MARGIN: 0px">develop a MIB module for management = now, and=20 request a corresponding</DIV> <DIV style=3D"MARGIN: 0px">information model that can be used to = develop a=20 netconf data model</DIV> <DIV style=3D"MARGIN: 0px">later.</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">AND between now and then, the = management protocol=20 development</DIV> <DIV style=3D"MARGIN: 0px">community needs to figure out how to = make the two=20 protocols</DIV> <DIV style=3D"MARGIN: 0px">compatible, so we do not have two = standard=20 protocols that cannot share</DIV> <DIV style=3D"MARGIN: 0px">information.</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">David Harrington</DIV> <DIV style=3D"MARGIN: 0px"><A=20 = href=3D"mailto:[email protected]">[email protected]</A><SPAN=20 class=3DApple-converted-space> </SPAN></DIV> <DIV style=3D"MARGIN: 0px"><A=20 = href=3D"mailto:[email protected]">[email protected]</A></DI= V> <DIV style=3D"MARGIN: 0px"><A=20 href=3D"mailto:[email protected]">[email protected]</A></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">-----Original Message-----</DIV> <DIV style=3D"MARGIN: 0px">From: Randy Presuhn [<A=20 = href=3D"mailto:[email protected]">mailto:randy_presuhn@mindspr= ing.com</A>]<SPAN=20 class=3DApple-converted-space> </SPAN></DIV> <DIV style=3D"MARGIN: 0px">Sent: Monday, November 06, 2006 11:03 = AM</DIV> <DIV style=3D"MARGIN: 0px">To: 'MIB Doctors'; <A=20 href=3D"mailto:[email protected]">[email protected]</A></DIV> <DIV style=3D"MARGIN: 0px">Cc: 'Mark Townsley'</DIV> <DIV style=3D"MARGIN: 0px">Subject: Re: [OPS-NM] RE: = [MIB-DOCTORS]=20 Mandatory Requirement<SPAN class=3DApple-converted-space> = </SPAN></DIV> <DIV style=3D"MARGIN: 0px">forconfigurationby SNMP<SPAN=20 class=3DApple-converted-space> </SPAN></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">Hi -</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">From: "David B Harrington" <<A=20 = href=3D"mailto:[email protected]">[email protected]</A>>= </DIV> <DIV style=3D"MARGIN: 0px">To: "'Romascanu, Dan (Dan)'" <<A = href=3D"mailto:[email protected]">[email protected]</A>>; = "'MIB<SPAN class=3DApple-converted-space> = </SPAN></DIV></BLOCKQUOTE> <DIV style=3D"MARGIN: 0px">Doctors'" <<A=20 = href=3D"mailto:[email protected]">[email protected]</A>>; = <<A=20 href=3D"mailto:[email protected]">[email protected]</A>></DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">Cc: "'Mark Townsley'" <<A=20 = href=3D"mailto:[email protected]">[email protected]</A>></DIV> <DIV style=3D"MARGIN: 0px">Sent: Sunday, November 05, 2006 = 10:34=20 AM</DIV> <DIV style=3D"MARGIN: 0px">Subject: [OPS-NM] RE: [MIB-DOCTORS] = Mandatory=20 Requirement<SPAN class=3DApple-converted-space> = </SPAN></DIV></BLOCKQUOTE> <DIV style=3D"MARGIN: 0px">for configurationby SNMP<SPAN=20 class=3DApple-converted-space> </SPAN></DIV> <DIV style=3D"MARGIN: 0px">...</DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">Since possible alternatives are on = the=20 horizon, and the IETF</DIV> <DIV style=3D"MARGIN: 0px">management framework has always = permitted the=20 support for<SPAN class=3DApple-converted-space> = </SPAN></DIV></BLOCKQUOTE> <DIV style=3D"MARGIN: 0px">alternative</DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">protocols for carrying MIB module = data, I=20 suggest that any<SPAN class=3DApple-converted-space>=20 </SPAN></DIV></BLOCKQUOTE> <DIV style=3D"MARGIN: 0px">long-lived</DIV> <BLOCKQUOTE type=3D"cite"> <DIV style=3D"MARGIN: 0px">requirements section RECOMMEND, but = not=20 REQUIRE, SNMP so that</DIV> <DIV style=3D"MARGIN: 0px">alternative protocols could be used = in the=20 future to meet these</DIV> <DIV style=3D"MARGIN: 0px">management functionality = requirements.</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">However, I believe that MIB modules = and=20 support for SNMP should</DIV> <DIV style=3D"MARGIN: 0px">continue to be required as a = condition of=20 IETF standards-track</DIV> <DIV style=3D"MARGIN: 0px">advancement until suitable = alternative=20 solutions are completed and</DIV> <DIV style=3D"MARGIN: 0px">available.</DIV></BLOCKQUOTE> <DIV style=3D"MARGIN: 0px">...</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">I'm having trouble fitting these two = paragraphs=20 together.</DIV> <DIV style=3D"MARGIN: 0px">The first is consistent with the = changes=20 suggested, but</DIV> <DIV style=3D"MARGIN: 0px">the second is a strong argument = against making=20 those</DIV> <DIV style=3D"MARGIN: 0px">changes.</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MARGIN: 0px">Randy</DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV=20 style=3D"MARGIN: = 0px">_______________________________________________</DIV> <DIV style=3D"MARGIN: 0px">MIB-DOCTORS mailing list</DIV> <DIV style=3D"MARGIN: 0px"><A=20 = href=3D"mailto:[email protected]">[email protected]</A></DIV> <DIV style=3D"MARGIN: 0px"><A=20 = href=3D"https://www1.ietf.org/mailman/listinfo/mib-doctors">https://www1.= ietf.org/mailman/listinfo/mib-doctors</A></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: = 0px"><BR></DIV></BLOCKQUOTE> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV style=3D"MIN-HEIGHT: 14px; MARGIN: 0px"><BR></DIV> <DIV=20 style=3D"MARGIN: = 0px">_______________________________________________</DIV> <DIV style=3D"MARGIN: 0px">OPS-NM mailing list</DIV> <DIV style=3D"MARGIN: 0px"><A=20 href=3D"mailto:[email protected]">[email protected]</A></DIV> <DIV style=3D"MARGIN: 0px"><A=20 = href=3D"https://www1.ietf.org/mailman/listinfo/ops-nm">https://www1.ietf.= org/mailman/listinfo/ops-nm</A></DIV></BLOCKQUOTE></DIV><BR> <DIV><SPAN class=3DApple-style-span=20 style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: = none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; = LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px = 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: = auto; orphans: 2; widows: 2"><SPAN=20 class=3DApple-style-span=20 style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: = none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; = LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px = 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: = auto; orphans: 2; widows: 2"><SPAN=20 class=3DApple-style-span=20 style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: = none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; = LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px = 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: = auto; orphans: 2; widows: 2"><SPAN=20 class=3DApple-style-span=20 style=3D"WORD-SPACING: 0px; FONT: 12px Helvetica; TEXT-TRANSFORM: = none; COLOR: rgb(0,0,0); TEXT-INDENT: 0px; WHITE-SPACE: normal; = LETTER-SPACING: normal; BORDER-COLLAPSE: separate; border-spacing: 0px = 0px; khtml-text-decorations-in-effect: none; apple-text-size-adjust: = auto; orphans: 2; widows: 2"> <DIV>Jon=20 Saperia</DIV></SPAN></SPAN></SPAN></SPAN></DIV><BR></DIV></BLOCKQUOTE></B= LOCKQUOTE></BODY></HTML> ------_=_NextPart_001_01C70211.BAEF8090-- --===============1421866067== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPS-NM mailing list [email protected] https://www1.ietf.org/mailman/listinfo/ops-nm --===============1421866067==--