IETF Logo Mail Archive

Re: [OPSAWG] We have submitted a drafts on SNMP usages for P2P networks. We would like to get some suggestions from SNMP experts on the scenario and design for P2P network management. The link to the draft is in the body of this email. thanks！

"Randy Presuhn" <randy_presuhn@mindspring.com> Thu, 09 June 2011 17:12 UTC

Return-Path: <randy_presuhn@mindspring.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 1413E11E81CD for <opsawg@ietfa.amsl.com>; Thu, 9 Jun 2011 10:12:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.147
X-Spam-Level:
X-Spam-Status: No, score=-102.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, SARE_SUB_ENC_UTF8=0.152, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jp6x0DZBgr20 for <opsawg@ietfa.amsl.com>; Thu, 9 Jun 2011 10:12:41 -0700 (PDT)
Received: from elasmtp-curtail.atl.sa.earthlink.net (elasmtp-curtail.atl.sa.earthlink.net [209.86.89.64]) by ietfa.amsl.com (Postfix) with ESMTP id 50C8011E817A for <opsawg@ietf.org>; Thu, 9 Jun 2011 10:12:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=d0V9Wz7ygz+3OCnOJaVKskO3M8xuZShlJuXaFBrf5tYa8HmhPOUA24fTLeWkQKyN; h=Received:Message-ID:From:To:References:Subject:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Priority:X-MSMail-Priority:X-Mailer:X-MimeOLE:X-ELNK-Trace:X-Originating-IP;
Received: from [99.30.227.199] (helo=oemcomputer) by elasmtp-curtail.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from <randy_presuhn@mindspring.com>) id 1QUime-0003ER-3H for opsawg@ietf.org; Thu, 09 Jun 2011 13:12:40 -0400
Message-ID: <006201cc26c8$f9595e00$6801a8c0@oemcomputer>
From: Randy Presuhn <randy_presuhn@mindspring.com>
To: opsawg@ietf.org
References: <OF28B3E6A8.812EF3E1-ON482578AA.0013B597-482578AA.001489EE@zte.com.cn>
Date: Thu, 09 Jun 2011 10:16:29 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478
X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d888cc964a8bf633b3826892f10d3f3a38a6cdbc8efb626ce5bd350badd9bab72f9c350badd9bab72f9c
X-Originating-IP: 99.30.227.199
Subject: Re: [OPSAWG] We have submitted a drafts on SNMP usages for P2P networks. We would like to get some suggestions from SNMP experts on the scenario and design for P2P network management. The link to the draft is in the body of this email. thanks！
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: Thu, 09 Jun 2011 17:12:42 -0000

Hi -

> From: <peng.yonglin@zte.com.cn>
> To: <opsawg@ietf.org>
> Cc: <hao.zhenwu@zte.com.cn>
> Sent: Wednesday, June 08, 2011 8:43 PM
> Subject: [OPSAWG] We have submitted a drafts on SNMP usages for P2P networks. We would like to get some suggestions from SNMP
experts on the scenario and design for P2P network management. The link to the draft is in the body of this email. thanks！
>
> http://tools.ietf.org/id/draft-peng-p2psip-snmp-01.txt
...

Skimming the draft, it was unclear to me how a few details would work
in this approach.  I think it would be helpful to explicitly talk about
  (1) how notifications are intended to work
  (2) key provisioning (indeed, provisioning in general)
  (3) what security model is in use

I *think* it might be helpful to treat this as a new transport
model, but you'll need to think through just how authentication
and privacy are to be handled (e.g., is it just USM atop RELOAD,
or does RELOAD provide the security services?).  This decision
may interract with how, for example, notification and Disman
targets are configured.  In particular, consider whether you need
to support the case where only *some* of the SNMP interractions
between two systems are carried via RELOAD.

Randy

v2.23.0 | Report a Bug | By Email