Just to make sharper the statements made by Tom. In the SNMP architecture in order for two entities to exchange management information we have a protocol (basic primitives to fetch pieces of information, set values of pieces of information or send notifications related to the pieces of information) and a data model (e.g. MIB model) expressed in a Data Modeling Language (e.g. SMI). The proposed text talks about the protocol (SNMP) but not about the information exchanged (data model). This is of little help.
Dan > -----Original Message----- > From: [email protected] [mailto:[email protected]] On > Behalf Of t.petch > Sent: Thursday, October 27, 2011 12:09 PM > To: [email protected] > Cc: [email protected]; [email protected]; [email protected] > Subject: Re: [OPSAWG] An SNMP Usage for RELOAD > > ----- Original Message ----- > From: <[email protected]> > To: "t.petch" <[email protected]> > Cc: <[email protected]>; <[email protected]>; <[email protected]>; > <[email protected]>; <[email protected]> > Sent: Wednesday, October 26, 2011 5:02 AM > > > In short, the relation between SNMP Usage and RELOAD as follows: > > SNMP Usage get a available IP address, which is used for SNMP > > communication, for snmeEngineID or NodeID or ResourceID or Manager > name by > > RELOAD mechanism, such as AppAttach, Store, Fetch. > > Then SNMP Usage uses this IP address for SNMP communication between > SNMP > > entities by the SNMP mechanism and architecture which defined in > RFC3411 > > and RFC5953 and other SNMP RFCs (as depicted in the diagram below). > And > > now there is little relation between SNMP Usage and RELOAD besides > using > > RELOAD certificate. So we say "SNMP entities talk to each other using > SNMP > > protocol on dedicated connections" > > No, it still does not make sense. You understand that an SNMP engine > can do > nothing until it has been customised - snmpEngineID, > snmpTargetAddrTable, etc - > and you use RELOAD to obtain that information; I assume you are > familiar with > the MIB modules into which that information must then be placed before > an engine > can communicate. > > Two engines can then communicate but cannot do anything useful without > suitable > MIB modules; the I-D says > " SNMP usage for RELOAD SHOULD provide the management functions ... > ... monitoring the number of the messages > initiated, forwarded or processed by nodes, reporting program > failure > , message forwarding failure or other error on nodes." > > This is a typical usage for SNMP but is quite impossible unless and > until a > suitable > MIB module is defined, which is what everyone using SNMP for management > then does. Your earlier response to David rejected the idea of > creating a MIB > module, which leaves me with two SNMP engines able to talk to each > other but > having nothing useful to say. > > The I-D also says > "As traditional network > management protocols (e.g., SNMP) cannot be directly applied to > RELOAD network management, it is necessary to introduce new RELOAD > usage of SNMP." > which is only true in the sense that SNMP cannot be directly applied to > any > network > management, unless and until there is a suitable MIB module. Once > there is, > and you have two communicating engines (which you say you will have), > then > of course SNMP can be used to manage anything, including RELOAD. > > Tom Petch > > > > > If you till have questions, please tell us. Thanks! > > > > > > ************************************************* > > 邮 件：[email protected] > > 内 线：81543 > > 外 线：025-52871543 > > 手 机：13776637274 > > 传 真：025-52872187 > > ************************************************* > > > > > > > > > > > > ----- Original Message ----- > > From: <[email protected]>; <[email protected]> > > To: <[email protected]>; <[email protected]>; <[email protected]>; > > <[email protected]> > > Cc: <[email protected]>; <[email protected]> > > Sent: Tuesday, October 25, 2011 4:23 AM > > > > > We have done more research on security and other issues based on > David's > > > comments, and updated our draft. > > > > > > This is the new version of draft: > > > http://www.ietf.org/id/draft-peng-p2psip-snmp-03.txt > > > > > > We welcome any comments! Thanks! > > > > > > Our analysis of David's comments as follows(blue text): > > > > > > 1) Use SNMPv3 terminology > > > Apparently, you come from the RELOAD side of things, not the SNMP > > > side. > > > Your text doesn't use the common SNMP terminology for various > > > SNMP-related things. > > > You will have a better chance of success if you describe SNMP- > related > > > things using the normal SNMPv3 terminology. > > > This isn't critical; your ideas seem reasonable, but since you > don't > > > use the standard terminology, you might mean slightly different > things > > > than what it would mean if you used the standard terminology. > > > > > > (I don't have a RELOAD background, so some of my comments might > seem > > > wrong because I don't know the RELOAD concepts and terminology. Now > > > you'll understand my point ;-) > > > > > > PYL: We have updated the draft using SNMP terminology. As we are > not > > SNMP > > > experts, some terminology may not be accurate. We will try to > improve > > this > > > over time. > > > > You are indeed using SNMP terminology, but I struggle to see how its > usage > > is > > the same as in RFC3411. > > > > RELOAD defines a messaging network, on top of which run applications, > > which > > RELOAD calls Usages, so when you define an SNMP Usage, you would > appear to > > be > > discarding most of an Architecture for SNMP as defined in RFC3411, > perhaps > > providing instead a gateway for functionality such as that specified > in > > RFC3414; > > or perhaps not, I do not find the I-D clear on this. Thus you have > > > > Application > > > > +-------+ +-------+ +-------+ > > | SIP | | XMPP | | SNMP | ... > > | Usage | | Usage | | Usage | > > +-------+ +-------+ +-------+ > > ------------------------------------------- Messaging API > > > > RELOAD > > > > but elsewhere you say > > ' SNMP entities talk to each other using SNMP protocol on dedicated > > connections' > > which is rather different. > > > > The I-D reads more like a wish list of requirements, than an > overview, > > architecture or framework. Or perhaps it is all beyond me:-( > > > > Tom Petch > > > > <snip> > > _______________________________________________ > OPSAWG mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/opsawg _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
