Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD

["t.petch" <[e-mail]>]

----- Original Message -----
From: <[e-mail]>
To: "t.petch" <[e-mail]>
Cc: <[e-mail]>; <[e-mail]>; <[e-mail]>;
<[e-mail]>; <[e-mail]>
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!
>
>
> *************************************************
> 邮 件：[e-mail]
> 内 线：81543
> 外 线：025-52871543
> 手 机：13776637274
> 传 真：025-52872187
> *************************************************
>
> >
>
>
> > ----- Original Message -----
> From: <[e-mail]>; <[e-mail]>
> To: <[e-mail]>; <[e-mail]>; <[e-mail]>;
> <[e-mail]>
> Cc: <[e-mail]>; <[e-mail]>
> 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>