AW: RE: [MIB-DOCTORS] MandatoryRequirementforconfigurationby SNMP
"Haidegger, Wolfgang" <[email protected]> Tue, 7 Nov 2006 05:59:22 +0100
| Newsgroups | gmane.ietf.ops-nm |
|---|---|
| Message-ID | <1B8AF39CACF71744BE07006131091BBE432CBD@atnets15na.ww300.siemens.net> |
This is a multi-part message in MIME format.
--===============0724831570==
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C70229.7D636458"
This is a multi-part message in MIME format.
------_=_NextPart_001_01C70229.7D636458
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
If one intends to go into the direction of allowing various management
protocols, there are, I think, two issues which seem rather difficult to
solve.
=20
- does one limit the amount of different management protocols, which
have been standardized by some bodies like ITU-T, IETF, TMF, ... and if
so, what would be the criteria?
=20
- in case one goes with a multi protocol approach (one I would find
highly interesting), is there a way to define mappings between the
interface specifications on the one hand and the actual requests of the
protocols on the other hand? This would then allow the development of
"generic MIBs" (more like meta models), which could have different forms
depending on the interface definition selected and which would then
allow an automatic mechanism translating one form into another.
=20
Greetings
Wolfgang
________________________________
Von: Romascanu, Dan (Dan) [mailto:[email protected]]=20
Gesendet: Dienstag, 07. November 2006 03:09
An: David B Harrington; Jon Saperia
Cc: MIB Doctors; [email protected]
Betreff: RE: [OPS-NM] RE: [MIB-DOCTORS]
MandatoryRequirementforconfigurationby SNMP=20
(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
________________________________
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
________________________________
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_01C70229.7D636458
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=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>If one intends to go into the direction of =
allowing various=20
management protocols, there are, I think, two issues which seem rather =
difficult=20
to solve.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D945164704-07112006> <FONT=20
face=3DArial color=3D#0000ff size=3D2>- does one limit the amount of =
different=20
management protocols, which have been standardized by some bodies like =
ITU-T,=20
IETF, TMF, ... and if so, what would be the =
criteria?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN =
class=3D945164704-07112006> <FONT=20
face=3DArial color=3D#0000ff size=3D2>- in case one goes with a multi =
protocol=20
approach (one I would find highly interesting), is there a way to define =
mappings between the interface specifications on the one hand and the =
actual=20
requests of the protocols on the other hand? This would then allow the=20
development of "generic MIBs" (more like meta models), which could have=20
different forms depending on the interface definition selected and which =
would=20
then allow an automatic mechanism translating one form into=20
another.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2></FONT></SPAN> </DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Greetings</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D945164704-07112006><FONT =
face=3DArial=20
color=3D#0000ff size=3D2>Wolfgang</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dde dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>Von:</B> Romascanu, Dan (Dan)=20
[mailto:[email protected]] <BR><B>Gesendet:</B> Dienstag, 07. November =
2006=20
03:09<BR><B>An:</B> David B Harrington; Jon Saperia<BR><B>Cc:</B> MIB =
Doctors;=20
[email protected]<BR><B>Betreff:</B> RE: [OPS-NM] RE: [MIB-DOCTORS]=20
MandatoryRequirementforconfigurationby SNMP <BR></FONT><BR></DIV>
<DIV></DIV>
<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_01C70229.7D636458--
--===============0724831570==
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
--===============0724831570==--