Re: [Isms] IsmsQuestions on TLSTM/TSM and RFC 5343

Frank Fock <fock@agentpp.com> Sun, 23 January 2011 17:24 UTC

Return-Path: <fock@agentpp.com>
X-Original-To: isms@core3.amsl.com
Delivered-To: isms@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4E133A6930 for <isms@core3.amsl.com>; Sun, 23 Jan 2011 09:24:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5Ee2LVj6cqyt for <isms@core3.amsl.com>; Sun, 23 Jan 2011 09:24:05 -0800 (PST)
Received: from moutng.kundenserver.de (moutng.kundenserver.de [212.227.17.9]) by core3.amsl.com (Postfix) with ESMTP id B3ED73A692E for <isms@ietf.org>; Sun, 23 Jan 2011 09:24:04 -0800 (PST)
Received: from [127.0.0.1] (p5B207F06.dip.t-dialin.net [91.32.127.6]) by mrelayeu.kundenserver.de (node=mreu0) with ESMTP (Nemesis) id 0MYrLj-1PmCVD2BUJ-00Vkjw; Sun, 23 Jan 2011 18:26:52 +0100
Message-ID: <4D3C6451.7020000@agentpp.com>
Date: Sun, 23 Jan 2011 18:24:33 +0100
From: Frank Fock <fock@agentpp.com>
Organization: AGENT++
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: Wes Hardaker <wjhns1@hardakers.net>
References: <4D32C788.5060604@agentpp.com> <sdvd1mvybg.fsf@wjh.hardakers.net>
In-Reply-To: <sdvd1mvybg.fsf@wjh.hardakers.net>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V02:K0:z2gpGirv14kxuxaYr6FAvhiVGxozmwztRt46lZCZXPH Zs0aaRMmpIBBJe086d6Vm87L4GEn77hXT8NjqL80QyFosPq58w 7Jc3/DObXaM78Z2agbhOxD7k7EpMQROt+Da07Kzp6ZszQVVQTH lKXVaDcdqVwAjhzTJOkvF6gA6W98eIbYAMHdmwPyOiEnzF6eNH aGT93QLwPCurZXMYkTNOg==
Cc: isms@ietf.org
Subject: Re: [Isms] IsmsQuestions on TLSTM/TSM and RFC 5343
X-BeenThere: isms@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mailing list for the ISMS working group <isms.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/isms>
List-Post: <mailto:isms@ietf.org>
List-Help: <mailto:isms-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/isms>, <mailto:isms-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Jan 2011 17:24:05 -0000

Hi Wes,

Thanks for your reply (and also those of Tom
and Juergen).

I understand that RFC 5343 solves the
contextEngineID discovery problem, but
within the last 10 years with SNMPv3
I learned, that most SNMPv3 users do not
understand the authoritative and context engine
ID concepts.

There are also a couple of companies
creating SNMPv3 devices with identical
authoritative engine ID for all instances
of their device. We API developers are then
asked to work around these problems :-(

That's why I thought about simplifying
the SNMPv3 and making the discovery of
a contextEngineID unnecessary if not
required by the command generator.

Nevertheless, I agree that using a single
magic contextEngineID for the local context,
would interfere with proxy applications,
for example.

I will now first finish my implementation
and then make a complete report and analysis
of the result. This will also include using
contextEngineId discovery with USM.

Best regards,
Frank