RE: RE: [MIB-DOCTORS] Mandatory Requirement forconfigurationby SNMP
"David B Harrington" <[email protected]> Mon, 6 Nov 2006 17:44:04 -0800
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <[email protected]> |
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 [email protected] [email protected] [email protected] _____ From: Jon Saperia [mailto:[email protected]] 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 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 [email protected] [email protected] [email protected] -----Original Message----- From: Randy Presuhn [mailto:[email protected]] 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 forconfigurationby SNMP Hi - From: "David B Harrington" <[email protected]> To: "'Romascanu, Dan (Dan)'" <[email protected]>; "'MIB 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 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 [email protected] https://www1.ietf.org/mailman/listinfo/mib-doctors _______________________________________________ OPS-NM mailing list [email protected] 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 <!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 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 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.</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 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.</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 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 </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=20 monitoring, plus interoperable configuration, plus interoperable = accounting, and=20 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 to=20 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 in=20 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 = [mailto:[email protected]]=20 <BR><B>Sent:</B> Monday, November 06, 2006 4:00 PM<BR><B>To:</B> David = B=20 Harrington<BR><B>Cc:</B> 'Randy Presuhn'; 'MIB Doctors'; = [email protected];=20 'Mark Townsley'<BR><B>Subject:</B> Re: [OPS-NM] RE: [MIB-DOCTORS] = Mandatory=20 Requirement forconfigurationby SNMP <BR></FONT><BR></DIV> <DIV></DIV>David, <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 that=20 would support interoperability better and with less cost than is = currently the=20 case.</DIV> <DIV><BR class=3Dkhtml-block-placeholder></DIV> <DIV>In the interim, your suggestion is perhaps the best that can be=20 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. Until=20 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] = Mandatory=20 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=20 href=3D"mailto:[email protected]">[email protected]</A>>; = "'MIB<SPAN=20 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 = 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 horizon,=20 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 support=20 for SNMP should</DIV> <DIV style=3D"MARGIN: 0px">continue to be required as a = condition of IETF=20 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= ODY></HTML> ------=_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 [email protected] https://www1.ietf.org/mailman/listinfo/ops-nm --===============0404713294==--