mcdaniel%hqeis.decnet@HQAFSC-VAX.AF.MIL ("HQEIS::MCDANIEL") (09/15/89)
Andrews AFB
I N T E R O F F I C E M E M O R A N D U M
Date: 15-Sep-1989 09:40am EST
From: Mr Rodney A McDaniel
MCDANIEL
Dept: HQ AFSC/SCXP
Tel No: 981-7909/AV 858
Owner: Mr Rodney A McDaniel *
TO: _MAILER! ( _DDN[TCP-IP@NIC.DDN.MIL] )
Subject: RE: DOD ---> CMOT VERSUS SNMP
I HAVE BEEN READING ALL THE VARIOUS REPLIES CONCERNING DOD CMOT
VERSUS SNMP, HOWEVER I HAVE BEEN UNABLE TO FIND A DEFINITION FOR
CMOT.
WHAT DOES CMOT STAND FOR???
SECONDLY, DOES ANYONE HAVE OR KNOW THE OFFICIAL DOD POLICY
CONCERNING THE CMOT REQUIREMENT?? PLEASE SITE A DIRECTIVE OR OFFICIAL
PUBLICATION STATING CMOT WILL BE USED VICE SNMP FOR THE FUTURE.
THIRDLY, I DON'T SEE A COMPLETE ANSWER TO THE FIRST MESSAGE CONCERNING DOD
CMOT VERSUS SNMP. BOTH QUESTIONS HAVE BEEN SIDE-TRACKED BY THE OSI &
ISO PROTOCOL ISSUES. ALSO DOES ANYONE ACTUALLY HAVE A CMOT
IMPLEMENTATION, WHICH COULD REALLY ADVISE THE REST OF THE WORLD THE
ADVANTAGES OR DRAWBACKS VERSUS THE EXISTING SNMP BEING USED???
ATTACHED IS A LISTING OF ALL THE REPLIES CONCERNING THIS SUBJECT,
BUT HAVE THE ORIGINAL QUESTIONS REALLY BEEN ANSWERED AND PROVIDED THE
NEEDED INFORMATION TO END THE CONTROVERSY ON CMOT AND SNMP.
I HAVE ADDED A ASBESTOS AND THREE FOOT THICK STEEL WALLS AROUND MY
EMAIL TERMINAL FOR ANY POSSIBLE FLAMING REPLIES OR LAUNCHING OF ANY
MISSILES. SO REPLIES CAN BE SENT TO: MCDANIEL@HQAFSC-VAX.AF.MIL.
RODNEY A. MCDANIEL
AFSC DDN PROGRAM MANAGER
PROGRAMS DIVISION
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 1 Sep 89 22:35:28 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 11:04:39 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
id AA13385; Fri, 1 Sep 89 10:35:18 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 1 Sep 89 11:28:54 GMT
From: mcsun!cernvax!cgch!wasc@uunet.uu.net (Armin Schweizer)
Organization: WRZ, CIBA-GEIGY Ltd, Basel, Switzerland
Subject: DoD --> CMOT and SNMP
Message-Id: <873@cgch.UUCP>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL
From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT.
I did not hear the same for SNMP. Is this valid for SNMP too?
What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)
Who knows of or runs a CMOT implementation? I would like
to have a direct contact.
kind regards
armin
Armin R. Schweizer, CIBA-GEIGY AG, R1045.P.06, WRZ
4002 Basel / Switzerland
phone: -41-61-697'79'46
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sat, 2 Sep 89 07:38:04 EDT
Received: from ahwahnee.Stanford.EDU by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 21:47:14 PDT
Received: by ahwahnee.Stanford.EDU; Fri, 1 Sep 89 21:40:26 PDT
Date: Fri, 1 Sep 89 21:40:26 PDT
From: Dave Crocker <dcrocker@ahwahnee.Stanford.EDU>
Subject: Re: DoD --> CMOT and SNMP
To: tcp-ip@nic.ddn.mil
(Sorry. I intended to send this to the entire list. DHC)
From dcrocker Fri Sep 1 21:28:53 1989
From: Dave Crocker <dcrocker>
Subject: Re: DoD --> CMOT and SNMP
To: mcsun!cernvax!cgch!wasc@uunet.uu.net
The Internet Activities Board has declared SNMP and CMOT to be co-equal
standards. If effect, this means that they both have a stamp of approval
from a significant "standards" body. (For the TCP/IP technology, the
IAB fills the kind of role that ISO and CCITT and ECMA do in various
parts of international communities.
So much for the stamp of approval.
Your question is more to the point and asks about actual support by
vendors. (A nicely practical point to have concern for.)
A number of companies are currently shipping products that use SNMP.
Further, the NSFNet is managed using it. It is my impression that virtually
all TCP/IP vendors have announced intent to support SNMP, if they are not
already doing so.
SNMP is unique to the TCP/IP community, although it uses the OSI ASN.1
encoding standard, for specifying the format of objects. CMOT is derived
from the OSI CMOT standards effort, although I am told there are some
differences. It is not clear to me that these differences are in the
management protocol, itself, it does run over a modified stack of
support protocols. Most significantly, is uses TCP or, perhaps, UDP,
instead of an OSI transport. Hence, CMOT gets you closer to the future
of OSI network management protocol details.
However, there does not appear to be any vendor that currently ships
CMOT and, therefore, there is no field (production network) experience
using it. While a number of vendors have announced plans to support
CMOT, I am not aware of any official, announced, delivery dates from
these vendors.
A further point about the recent decision to make SNMP and CMOT co-equal
standards is that their use of the Management Information Base (MIB) was
entirely de-coupled. While one should expect them to continue to use the
original 100 variable, there having additional variable in common is
problematic. At the least, such sharing should be expected to organic or
accidental, rather than formally enforced. (That should be "expected to
be organic..." I am on a thin wire with a poor editor.)
As always, I trust that others will elaborate on, as well as correct,
the above. Dive in!
Dave Crocker
Digital Equipment Corp.
P.S. On review, I note that I did not respond to your query about
federal requirements for CMOT support: There is strong governmental
pressure for moving to OSI. This is embodied in the GOSIP document.
In general, however, the requirements are careful to allow use of
alternatives. Perhaps the most extreme way of viewing this is that a
vendor certainly cannot consider ignoring the OSI CMOT. I am less clear
about their ability to dodge CMOT (but am sure that someone out there in
tcp-land will chime in to clarify, please?) Enough vendors have stated
intent to support CMOT and enough are working on it, that I would expect it
to start showing up in the future.
P.P.S. I should use this opportunity to suggest a personal bias. It is NOT
about which protocol I prefer. In fact, the brouhaha has, in my opinion,
distracted us from worrying about how to manage multi-administration
inter-networks. The chosen protocol is not irrelevant to this, but my
suspicion is that we could start with a hopelessly incomplete one and
still not know how to use it to its fullest.
That is, our general understanding and pursuit of specifying and
developing management (application) SERVICES has been quite limited
and that we would do well to focus on MIB enhancement and specification
of standard applications for management. (I.e., focus on the bottom
and top of the management architecture.)
D/
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Wed, 6 Sep 89 22:22:50 EDT
Received: from solbourne.nyser.net by NIC.DDN.MIL with TCP; Wed, 6 Sep 89 13:14:12 PDT
Received: from localhost by solbourne.nyser.net (5.61/2.1-NYSERNet Research & Development)
id AA06725; Wed, 6 Sep 89 16:07:48 -0400
Message-Id: <8909062007.AA06725@solbourne.nyser.net>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net (Armin Schweizer)
Cc: tcp-ip@NIC.DDN.MIL
Subject: Re: DoD --> CMOT and SNMP
In-Reply-To: Your message of 01 Sep 89 11:28:54 +0000.
<873@cgch.UUCP>
Date: Wed, 06 Sep 89 16:07:46 -0400
From: "Marty Schoffstall" <schoff@solbourne.nyser.net>
>From one of our network devices suppliers I got the information,
that the DoD will request from all suppliers, that their
respective products support CMOT.
I did not hear the same for SNMP. Is this valid for SNMP too?
On paper according to the RFC's they are both to be implemented by
vnedors/suppliers. SNMP exists and this for the most part all TCP/IP
vendors either ship SNMP in their product or are committed to in
their next release. Marketing research orgnizations are responsible
for exact numbers and analysis but I'm aware of 20-25 implementations
that you can buy today.
What are the advantages of CMOT compared with SNMP, which
make the DoD chose CMOT as their favorite network management
vehicle? (Both, CMOT and SNMP use the same management information
base!?)
CMOT's advantage is that it is theoretically aligned with the International
Standard Organizations (ISO) program.
Who knows of or runs a CMOT implementation? I would like
to have a direct contact.
To my knowledge no one runs this in an operational network and I haven't
heard of the availablility of interoperable CMOT implementations.
Marty
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 8 Sep 89 02:58:15 EDT
Received: from ucbvax.Berkeley.EDU by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 22:50:53 PDT
Received: by ucbvax.Berkeley.EDU (5.61/1.37)
id AA08939; Thu, 7 Sep 89 22:42:26 -0700
Received: from USENET by ucbvax.Berkeley.EDU with netnews
for tcp-ip@sri-nic.arpa (tcp-ip@sri-nic.arpa)
(contact usenet@ucbvax.Berkeley.EDU if you have questions)
Date: 7 Sep 89 19:53:16 GMT
From: fernwood!asylum!karl@apple.com (Karl Auerbach)
Organization: The Asylum; Belmont, CA
Subject: Re: DoD --> CMOT and SNMP
Message-Id: <3853@asylum.SF.CA.US>
References: <8909021142.AA08148@ucbvax.Berkeley.EDU>
Sender: tcp-ip-relay@NIC.DDN.MIL
To: tcp-ip@NIC.DDN.MIL
In article <8909021142.AA08148@ucbvax.Berkeley.EDU> dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) writes:
> SNMP is unique to the TCP/IP community,
Not quite true -- one could use SNMP to manage an OSI network.
--karl--
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 8 Sep 89 23:37:26 EDT
Received: from trwind.ind.TRW.COM by NIC.DDN.MIL with TCP; Thu, 7 Sep 89 10:39:27 PDT
Received: by trwind.ind.TRW.COM (5.54/1.36)
id AA04966; Thu, 7 Sep 89 10:38:59 PDT
Date: Thu, 7 Sep 89 10:38:59 PDT
From: robert@trwind.ind.trw.com (Robert W. Snyder)
Message-Id: <8909071738.AA04966@trwind.ind.TRW.COM>
To: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil
Subject: Re: DoD --> CMOT and SNMP
Cc: robert@trwind.ind.TRW.COM
>>From one of our network devices suppliers I got the information,
>that the DoD will request from all suppliers, that their
>respective products support CMOT.
>I did not hear the same for SNMP. Is this valid for SNMP too?
>
A major Air Force contract (ULANA) is considering requiring either SNMP
or CMOT implementations. There are two major contractors on this
contract that are competing against one another. One contractor
(TRW - us) is supporting SNMP, the other contractor (EDS teamed with
3com/bridge) is supporting CMOT. Since the government is
considering requiring the code after the contract award,
they were sort of forced into excepting both or getting into a hassle
with one of the two vendors by giving the other an unfair advantage.
Since this contract will be a buying vehicle DoD wide, it could
by that this is what your vendor is talking about. I could give
you a good breakdown of vendor support for both, but I dont think
that would be fair since I do not represent a disinterested third
party. For anyone interested in gathering this information. I
suggest that they attend Interop in San Jose where all the vendors
will be available to ask.
If anyone is aware of anything else that might be influencing
SNMP vs CMOT in the DOD world I would appreciate a reply
Hope this helps
Robert Snyder Disclaimer -- nobody claims dis, but me
TRW Information Networks Division 23800 Hawthorne Blvd, Torrance CA 90505
USENET: trwind!robert
INTERNET: robert@trwind.TRW.COM Phone 213-373-9161
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Sun, 10 Sep 89 14:13:32 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Sun, 10 Sep 89 09:52:05 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
id AA21304; Sun, 10 Sep 89 02:42:04 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
id AA04290; Sun, 10 Sep 89 02:40:49 EDT
Date: Sun, 10 Sep 89 02:40:49 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909100640.AA04290@tien.Wellfleet.Com>
To: fernwood!asylum!karl@apple.com
Subject: Re: DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil
>> SNMP is unique to the TCP/IP community,
> Not quite true -- one could use SNMP to manage an OSI network.
Or DECnet, or XNS, or NetWare, or even a bridge (via SNMP over Ethernet).
(We don't have bridge control yet).
-Philip
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 10:12:06 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 05:41:00 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
id AA24396; Mon, 11 Sep 89 05:35:14 -0700
Date: Mon, 11 Sep 89 05:35:14 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909111235.AA24396@WLV.IMSD.CONTEL.COM>
To: fernwood!asylum!karl@apple.com, pprindev@wellfleet.com
Subject: Re: DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil
>>> SNMP is unique to the TCP/IP community,
>> Not quite true -- one could use SNMP to manage an OSI network.
Excuse me, I'm confused. I thought that OSI was a model which described
the procedures (steps) to establish a connection and transfer data between
two nodes on a network regardless of the protocol suite employed. The ISO
IP/TPn and Internet TCP/IP protocol suites can be described by the model
as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
and the ISO 1745 protocol.
Merton
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 14:24:26 EDT
Received: from ASLAN.SAIC.COM by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 08:15:42 PDT
Received: by ASLAN.SAIC.COM (4.0/4.7) id AA04861; Mon, 11 Sep 89 11:12:43 EDT
Date: Mon, 11 Sep 89 11:12:43 EDT
From: Mike Little <little@SAIC.COM>
Message-Id: <8909111512.AA04861@ASLAN.SAIC.COM>
To: mcc@WLV.IMSD.CONTEL.COM
Subject: Re: DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil
>> Not quite true -- one could use SNMP to manage an OSI network.
>Excuse me, I'm confused. I thought that OSI was a model which described
>the procedures (steps) to establish a connection and transfer data between
>two nodes on a network regardless of the protocol suite employed. The ISO
>IP/TPn and Internet TCP/IP protocol suites can be described by the model
>as can networks based on Digital's DCA protocol suite, IBM's BSC protocol,
>and the ISO 1745 protocol.
OSI is an architectural model (one of many and the one with the most
name recognition). I believe the confusion arises here from what I
find to be common misspeak - refering to OSI when one actually should
refer to ISO. Particularly, the phrase "an OSI network" where the
intention is "a network based upon the ISO protocol suite". This may not
be exactly what Phillip intended (Phillip please interject if this is
nowhere close), but looks like where the confusion is arising from.
-Mike
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 19:28:38 EDT
Received: from shadooby.cc.umich.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 15:37:32 PDT
Received: from ummts.cc.umich.edu by shadooby.cc.umich.edu (5.61/1.0)
id AA01459; Mon, 11 Sep 89 18:35:22 -0400
Date: Mon, 11 Sep 89 18:34:52 EDT
From: Dave_Katz@um.cc.umich.edu
To: tcp-ip@NIC.DDN.MIL
Message-Id: <4865673@um.cc.umich.edu>
Subject: Re: DoD --> CMOT and SNMP
>name recognition). I believe the confusion arises here from what I
>find to be common misspeak - refering to OSI when one actually should
>refer to ISO. Particularly, the phrase "an OSI network" where the
>intention is "a network based upon the ISO protocol suite". This may not
I don't believe that the term "OSI network" is incorrect. There are
numerous protocols with ISO standards numbers, but only a subset of
those are protocols intended to support the OSI service definitions of
particular layers. For example, the official title of ISO 8473,
commonly known as "ISO IP", is "Protocol for providing the connectionless
mode network service" (where said service is defined by the OSI network
service definition).
For what it's worth, in my experience folks around the standards community
commonly refer to these things as "OSI protocols" and "OSI networks."
[cue the sound of a hair splitting]
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Mon, 11 Sep 89 21:17:50 EDT
Received: from talcott.harvard.edu by NIC.DDN.MIL with TCP; Mon, 11 Sep 89 16:56:04 PDT
Received: from tien.Wellfleet.Com by wellfleet.com (3.2/SMI-3.2)
id AA25964; Mon, 11 Sep 89 19:36:48 EDT
Received: by tien.Wellfleet.Com (3.2/SMI-3.2)
id AA11964; Mon, 11 Sep 89 19:35:30 EDT
Date: Mon, 11 Sep 89 19:35:30 EDT
From: Philip Prindeville <pprindev@wellfleet.com>
Message-Id: <8909112335.AA11964@tien.Wellfleet.Com>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM
Subject: Re: DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil
I don't think I'm the one who originally mentioned ISO, though
Mike is correct about the loose general use of ISO vs OSI.
Since ISO seems to be the only stack that is strictly compliant
(complacent?) with the 7 layer model, most people mix the two.
I believe I only mentioned XNS and DECnet. Karl Auerbach
originally threw out OSI [sic].
I assumed that Karl was referring to ISO 8473 (CLNS), etc. Did
I misunderstand?
-Philip
P.S. Merton: Did you switch employers recently?
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Tue, 12 Sep 89 12:11:22 EDT
Received: from WLV.IMSD.CONTEL.COM by NIC.DDN.MIL with TCP; Tue, 12 Sep 89 05:56:01 PDT
Received: by WLV.IMSD.CONTEL.COM (5.61/1.25)
id AA26604; Tue, 12 Sep 89 05:53:47 -0700
Date: Tue, 12 Sep 89 05:53:47 -0700
From: mcc@WLV.IMSD.CONTEL.COM (Merton Campbell Crockett)
Message-Id: <8909121253.AA26604@WLV.IMSD.CONTEL.COM>
To: little@SAIC.COM, mcc@WLV.IMSD.CONTEL.COM, pprindev@wellfleet.com
Subject: Re: DoD --> CMOT and SNMP
Cc: tcp-ip@nic.ddn.mil
Over the past year, I've noticed the more frequent use of OSI in briefings
and publications to refer to the ISO suite of protocols. I was beginning to
wonder if while mucking about with AUTODIN, IDHS, and a host of other lesser
known networks I had missed something.
Merton
P.S. Phil: I'm still at the same stand. Since Bunker Ramo was formed by
Martin and Ramo Woolridge, we've been Allied, Eaton, and Contel.
The last change occurred a year ago but the domain name change
didn't occur until June.
Return-Path: <tcp-ip-RELAY@NIC.DDN.MIL>
Received: from NIC.DDN.MIL by hqafsc-vax.af.mil with SMTP ; Fri, 15 Sep 89 02:33:29 EDT
Received: from A.ISI.EDU by NIC.DDN.MIL with TCP; Thu, 14 Sep 89 21:53:16 PDT
Date: Fri 15 Sep 89 00:48:41-EDT
From: Dan Lynch <LYNCH@A.ISI.EDU>
Subject: Re: DoD --> CMOT and SNMP
To: robert@trwind.ind.trw.com
cc: mcsun!cernvax!cgch!wasc@uunet.uu.net, tcp-ip@nic.ddn.mil, lynch@A.ISI.EDU
In-Reply-To: <8909071738.AA04966@trwind.ind.TRW.COM>
Message-ID: <12526341449.22.LYNCH@A.ISI.EDU>
Robert, I've been away, so sorry for a late reply, but I have also
had a chance to see other replies and must add my two cents worth.
OSI stands for Open Systems Interconnection. ISO stands for International
Organization for Standardization. (Yes, I know that the English/American
abbreviation for that should be IOS, but it ain't that way this time...)
OSi describes a model of communication among consenting systems. It was
described in an ISO document many years ago. Then ISO committees
began to fill out thier interpretations of how to accomplish the lofty
goals of the OSI model. All of those "interpretations" have come aout as ISO
documents. It is easy to mix the two acronyms up because of their
use of the same alphabet symbols. I used to find it useful to make
the distinction batween OSI and OSI. I thought (and still do think) that
the TCP/IP suite of protocols are quite in line withthe OSI "model".
So is DECNET, so is SNA, etc. (I mean, hey, an application has just got to
shove the bits out the "right" interface/wire to an equally receptive
application at the target system; how many ways can you describe to do that?
In 1976 it was an accomplishment to even make that description. By this
tim ein history it is a freshman problem, right?)
So, today, we should quit splitting haris, and let the meaning of "OSI"
be those protocols that are promulgated by ISO with regard to communications
between consenting computers. (ISO also sets standards
for cement ingredients, numbers of threads per inch/millimeter for screws,
etc...)
In other words, it is a waste of energy for someone to say they are OSI
complinat unless they use the actual ISO protocols. We technologists
may be able to sort his all out, but our customers should not have
to sort out our internal debates. Let us let them see one label.
That label is OSI.
Dan
-------LYNCH@A.ISI.EDU (Dan Lynch) (09/17/89)
Rodney, Your last message got me to feel guilty about my earlier reply. Sometimes those of us who "know the answers" don't realize how those who are asking the questions are essentially so far removed from all the stupid insider knowledge that our answers seem very opaque. I will try to answer your questions directly. CMOT is an acronym for CMip Over Tcp. (I lowercased stuff to make the point.) CMIP is the ISO protocol for network management. CMOT is a design that allows the ISO CMIP applications to manage objects on a TCP/IP network as well as on an ISO network. (At least thats the goal statement.) I do not know of any official DoD policy stating that SNMP and/or CMOT is the preferred/required network management protocol. The IAB (Internet Activities Board), of which I am a member, has stated that either protocol is acceptable as a network management protocol and that entities that wish to be network manageable must implement at least one of those protocols. The history of this situation is a longish one, but essentially SNMP was viewed as a stopgap measure (albeit an excellent one) for network management and that CMOT was a long term measure that would incorporate the ISO network entities that are in our future. The current situation in the marketplace is that there are dozens of SNMP implementations out there. To date, I know of no CMOT implementations that are offered as commercial products. A year ago there was a demonstration of CMOT prototypes at a technical conference. The distance from a prototype to a product is sometimes large, eh? My conclusion from this is that of someone is telling you that CMOT is mandatory for a certain equipment buy, then you are probably being lied to. If you are not being lied to, then whoever set the requirement is not in tune with product avaiability and the spec should be redone. (I'm assuming this is for a product that someone wants to install this year or next...) Dan Lynch Advanced Computing Environments 415-941-3399 -------
oconnor@SCCGATE.SCC.COM (Mike O'Connor) (09/17/89)
Dan, I could use a little clarification. On the one hand, your last message stated that, "To date, I know of no CMOT implementations that are offered as commercial products." On the other hand, the INTEROP 89 brochure states that, "This year, the vendors who have developed CMOT-compliant software for their systems will be showing products which implement the CMOT network management architecture. Attendees will be able to see current packages which conform to this specification." Is the apparent dichotomy caused by time? That is, does your message reflect the fact that despite INTEROP 89 plans, there are no CMOT products to show? Mike
LYNCH@A.ISI.EDU (Dan Lynch) (09/17/89)
Mike, your conclusions are completely accurate. 6 months ago there were solid plans for a CMOT demo of realproducts at INTEROP 89. It fell through because not enough vendors were able to commit to making the deadline. As far as i know they are still working on making products, but they aren't ready yet. I could be suprised by one or two vendors showing up with actual products in the next few weeks, but that would not be enough to bother putting on an actual demo. It takes a heck of a lot of coordination (read that as WORK) to put on a public demo of products from many sources. We spend about 6 months each year working with the dozens of vendors who are willing to prove to their potential customers that thier products actually do work well together. The TCP/IP related demos have been easier to pull together because the products are more mature. The OSI related demos have been tougher for the simple reason that the products are less mature and therefore the vendors are not as sure they can meet the deadlines. This year we are having two OSI related demos and the amouht of effort that has gone into them is not small. But, the results will be very impressive. (With only two weeks to go, it is easy to predict what is already known... Paul Baran (the father of packet switching) said once that "predicting is hard; predicting the future is even harder".) Dan -------
dcrocker@AHWAHNEE.STANFORD.EDU (Dave Crocker) (09/18/89)
Just to add to the confusion, I should note that I am beginning to hear increasing rumblings that some vendors might wish to suggest moving directly to full CMIP over TCP, rather than using the constrained CMOT. While I don't have anything more substantial than citing 'rumor', in terms of hearing about vendor plans, the technical distinction is significant: CMOT has two differences from CMIP. The first is that it operates over TCP, rather than OSI transport. This turns out to be relatively uninteresting, from the standpoint of management protocol discussions and it is NOT the change that I am hearing rumored. Much more importantly, CMOT specified a subset of the ASN.1 data types and, I believe, a subset of the management protocol operations from 'pure' CMIP (draft international standard or slightly before). Moving to "full" CMIP, even over TCP, therefore involves some amount of enhancement to the application protocol. The original subsetting was done out of the usual desire to streamline the initial implementation effort, for the demo that was schedules and accomplished at last year's Interop. Privately (i.e., not burdening the tcp-ip list with the traffic) I would be interested in hearing about vendor feelings on this topic. Dave Crocker Digital Equipment Corp.
caj@itivax.iti.org (Celia A. Joseph) (09/21/89)
Dave- To clarify what I think you're talking about: 1) Functional differences between CMOT and CMIP - in comparing the two documents, the only functional differences I can find are that CMOT does not include the current CMIP addenda, namely CancelGet and Add/Remove. 2) ASN.1 data type differences - I think what you are refering to is what falls under Structure of Management Information (SMI) in ISO. The ISO SMI includes some data types that weren't used in the Internet's equivalent document (rfc1065 - Internet Structure and Identification of Managenet Information for TCP/IP-based internets). However, the Internet document also defines some types that aren't in the ISO documents. The ISO work in this area is far from being turned into final standards, although their basic data type definitions have been fairly stable over the past year or so. The intent in ISO is to give a basic set of data types that appear to be generally useful -- not to define a cast-in-stone set of definitions that have to be used. Furthermore, the data type definitions are a separate issue from CMIP. CMIP merely provides the means to carry the information. It doesn't care what the contents of the data are. Thus, a vendor could implement CMIP with the current Internet data type definitions and change these definitions at a latter date without having to change their CMIP implementation. On the subject of GOSIP - GOSIP version 1 and the draft GOSIP version 2 do not specify network management yet. GOSIP's stated intention is to follow the work being done in the NIST workshops. Since the NIST NM SIG has not yet finalized its work, it is not yet included in GOSIP. NIST, however, is closely tracking the ISO standards. Hope this clarifies things somewhat, Celia Joseph Industrial Technology Institute Internet: caj@iti.org Phonenet: (313) 769-4153