[P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD
peng.yonglin@zte.com.cn Wed, 26 October 2011 03:03 UTC
Return-Path: <peng.yonglin@zte.com.cn>
X-Original-To: p2psip@ietfa.amsl.com
Delivered-To: p2psip@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1E21F8BDE; Tue, 25 Oct 2011 20:03:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -91.801
X-Spam-Level:
X-Spam-Status: No, score=-91.801 tagged_above=-999 required=5 tests=[AWL=-3.375, BAYES_05=-1.11, CHARSET_FARAWAY_HEADER=3.2, DC_GIF_UNO_LARGO=2.275, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lu9uG4SGVqtw; Tue, 25 Oct 2011 20:03:28 -0700 (PDT)
Received: from mx5.zte.com.cn (mx6.zte.com.cn [95.130.199.165]) by ietfa.amsl.com (Postfix) with ESMTP id 92F8621F8BD5; Tue, 25 Oct 2011 20:03:21 -0700 (PDT)
Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 466213465113155; Wed, 26 Oct 2011 10:55:33 +0800 (CST)
Received: from [10.30.3.21] by [192.168.168.16] with StormMail ESMTP id 75161.4569552579; Wed, 26 Oct 2011 11:02:59 +0800 (CST)
Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id p9Q32xt0059465; Wed, 26 Oct 2011 11:02:59 +0800 (GMT-8) (envelope-from peng.yonglin@zte.com.cn)
In-Reply-To: <048b01cc9320$97727900$4001a8c0@gateway.2wire.net>
To: "t.petch" <ietfc@btconnect.com>
MIME-Version: 1.0
X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005
Message-ID: <OFFBC2B0F5.00FFAF8C-ON48257935.0005B6DE-48257935.0010B7FA@zte.com.cn>
From: peng.yonglin@zte.com.cn
Date: Wed, 26 Oct 2011 11:02:43 +0800
X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.1FP4|July 25, 2010) at 2011-10-26 11:03:00, Serialize complete at 2011-10-26 11:03:00
Content-Type: multipart/related; boundary="=_related 0010B7F748257935_="
X-MAIL: mse02.zte.com.cn p9Q32xt0059465
Cc: hao.zhenwu@zte.com.cn, opsawg@ietf.org, p2psip@ietf.org, meng.yu@zte.com.cn
Subject: [P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD
X-BeenThere: p2psip@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Peer-to-Peer SIP working group discussion list <p2psip.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/p2psip>, <mailto:p2psip-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/p2psip>
List-Post: <mailto:p2psip@ietf.org>
List-Help: <mailto:p2psip-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/p2psip>, <mailto:p2psip-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 26 Oct 2011 03:03:29 -0000
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" If you till have questions, please tell us. Thanks! ************************************************* 邮 件:peng.yonglin@zte.com.cn 内 线:81543 外 线:025-52871543 手 机:13776637274 传 真:025-52872187 ************************************************* "t.petch" <ietfc@btconnect.com> 2011-10-25 22:15 收件人 <p2psip@ietf.org>, <opsawg@ietf.org>, <peng.yonglin@zte.com.cn> 抄送 <hao.zhenwu@zte.com.cn> 主题 Re: [OPSAWG] An SNMP Usage for RELOAD ----- Original Message ----- From: <peng.yonglin@zte.com.cn>; <peng.yonglin@zte.com.cn> To: <p2psip@ietf.org>; <opsawg@ietf.org>; <p2psip@ietf.org>; <opsawg@ietf.org> Cc: <hao.zhenwu@zte.com.cn>; <hao.zhenwu@zte.com.cn> 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> -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
- [P2PSIP] 答复: An SNMP Usage for RELOAD wang.wei108
- [P2PSIP] An SNMP Usage for RELOAD David Harrington
- Re: [P2PSIP] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD t.petch
- [P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD t.petch
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD Romascanu, Dan (Dan)
- [P2PSIP] 答复: Re: Re: [OPSAWG] An SNMP Usage for R… peng.yonglin
- [P2PSIP] 答复: Re: [OPSAWG] An SNMP Usage for RELOAD peng.yonglin
- Re: [P2PSIP] [OPSAWG] An SNMP Usage for RELOAD Juergen Schoenwaelder