Re: [OPSAWG] An SNMP Usage for RELOAD

"t.petch" <ietfc@btconnect.com> Tue, 25 October 2011 15:20 UTC

Return-Path: <ietfc@btconnect.com>
X-Original-To: opsawg@ietfa.amsl.com
Delivered-To: opsawg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DEC21F83EF; Tue, 25 Oct 2011 08:20:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.072
X-Spam-Level:
X-Spam-Status: No, score=-2.072 tagged_above=-999 required=5 tests=[AWL=-0.073, BAYES_00=-2.599, J_CHICKENPOX_74=0.6]
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 jSrnxI5TJIaw; Tue, 25 Oct 2011 08:20:52 -0700 (PDT)
Received: from mail.btconnect.com (c2bthomr09.btconnect.com [213.123.20.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2E64021F8BBF; Tue, 25 Oct 2011 08:20:51 -0700 (PDT)
Received: from host86-163-151-98.range86-163.btcentralplus.com (HELO pc6) ([86.163.151.98]) by c2bthomr09.btconnect.com with SMTP id EYR01884; Tue, 25 Oct 2011 16:20:46 +0100 (BST)
Message-ID: <048b01cc9320$97727900$4001a8c0@gateway.2wire.net>
From: "t.petch" <ietfc@btconnect.com>
To: p2psip@ietf.org, opsawg@ietf.org, peng.yonglin@zte.com.cn
References: <OF6B726AFE.B03E2E5F-ON48257934.000821E3-48257934.000D1EC1@zte.com.cn>
Date: Tue, 25 Oct 2011 16:15:08 +0200
MIME-Version: 1.0
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Fair-1, source=Queried, refid=tid=0001.0A0B0303.4EA6D3CE.0008, actions=tag
X-Junkmail-Premium-Raw: score=9/50, refid=2.7.2:2011.10.25.143623:17:9.535, ip=86.163.151.98, rules=__HAS_MSGID, __OUTLOOK_MSGID_1, __SANE_MSGID, __TO_MALFORMED_2, __TO_NO_NAME, __BOUNCE_CHALLENGE_SUBJ, __BOUNCE_NDR_SUBJ_EXEMPT, __MIME_VERSION, __CT, __CHAR_CHINESE_CT, __CT_TEXT_PLAIN, __CTE, __HAS_X_PRIORITY, __HAS_MSMAIL_PRI, __HAS_X_MAILER, USER_AGENT_OE, __OUTLOOK_MUA_1, __USER_AGENT_MS_GENERIC, __ANY_URI, CN_TLD, __CP_URI_IN_BODY, __LINES_OF_YELLING, BODYTEXTP_SIZE_3000_LESS, BODY_SIZE_2000_2999, __MIME_TEXT_ONLY, RDNS_GENERIC_POOLED, BODY_SIZE_5000_LESS, RDNS_SUSP_GENERIC, LOCALE_CHINESE, __OUTLOOK_MUA, RDNS_SUSP, BODY_SIZE_7000_LESS
X-Junkmail-Status: score=10/50, host=c2bthomr09.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B020A.4EA6D3D2.0191, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=multiengine
X-Junkmail-IWF: false
Cc: hao.zhenwu@zte.com.cn
Subject: Re: [OPSAWG] An SNMP Usage for RELOAD
X-BeenThere: opsawg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OPSA Working Group Mail List <opsawg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/opsawg>, <mailto:opsawg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/opsawg>
List-Post: <mailto:opsawg@ietf.org>
List-Help: <mailto:opsawg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/opsawg>, <mailto:opsawg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 25 Oct 2011 15:20:53 -0000

----- 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>