| Title: | DECmcc user notes file. Does not replace IPMT. |
| Notice: | Use IPMT for problems. Newsletter location in note 6187 |
| Moderator: | TAEC::BEROUD |
| Created: | Mon Aug 21 1989 |
| Last Modified: | Wed Jun 04 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 6497 |
| Total number of notes: | 27359 |
External vendors are questioning what they must do to be supported by
MCC if they support an industry standard protocol that MCC already
supports. For example, if vendor X supports either CMIP, SNMP, or the
OSI/NMF protocol suite, is there anything else they must do? I suspect
so, because while bridges and FDDI use the same protocol (RBMS), they
both get an AM. What's the difference between those two AM's? The
real question is, if something must be done, can the customer get the
guts of the 'x' AM so they can do their modifications, or are we asking
them to start from scratch? Inquiring minds want to know.
bill
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 55.1 | Push common functions into Kernel? | ALLZS::MORRISON | The Network IS the System | Mon Feb 19 1990 10:13 | 12 |
One possibility would be to merge the common functionality into the Kernel, as has already been done with things such as the ASN.1 routines for RBMS, and the Ethernet packet handling code for the Common Ethernet Access routines. This would make the writing of AMs that share protocols, etc. much simpler. Of course, the job of deciding what things merit this treatment will not be easy, and there is the danger that we might wind up pushing too much into the Kernel. However, I believe that this approach is preferable to duplicating much of the functionality across various AMs. But then, I just work on AMs. Perhaps one of the architects and someone from the Kernel group can comment further. Wayne | |||||