IETF Logo Mail Archive

Re: ISMS working group

Eliot Lear <lear@cisco.com> Tue, 13 September 2005 19:32 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGW2-0004Q5-KF; Tue, 13 Sep 2005 15:32:26 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFAFf-0007iz-FO; Tue, 13 Sep 2005 08:51:12 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19960; Tue, 13 Sep 2005 08:50:56 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFAJu-0001hp-FN; Tue, 13 Sep 2005 08:55:31 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 13 Sep 2005 05:50:48 -0700
X-IronPort-AV: i="3.97,105,1125903600"; d="scan'208"; a="341178149:sNHT31692188"
Received: from imail.cisco.com (imail.cisco.com [128.107.200.91]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j8DCoj4u028283; Tue, 13 Sep 2005 05:50:45 -0700 (PDT)
Received: from [144.254.23.127] (dhcp-data-vlan10-23-127.cisco.com [144.254.23.127]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j8DD3M20023143; Tue, 13 Sep 2005 06:03:23 -0700
Message-ID: <4326CB23.9000300@cisco.com>
Date: Tue, 13 Sep 2005 14:50:43 +0200
From: Eliot Lear <lear@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Brian E Carpenter <brc@zurich.ibm.com>
References: <431DD59A.4000400@ofcourseimright.com> <AE6514F0-4714-4A48-9F56-A155823489F2@moonhill.org> <p0620074bbf44d3d23a6d@[192.168.2.7]> <432531CB.3070109@cisco.com> <p062007e1bf4b28530a35@[192.168.2.7]> <43257A17.1050101@cisco.com> <p062007e2bf4b2b3db8dc@[192.168.2.7]> <4325A9A0.3080501@cisco.com> <4326C819.7020804@zurich.ibm.com>
In-Reply-To: <4326C819.7020804@zurich.ibm.com>
X-Enigmail-Version: 0.92.0.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=808; t=1126616604; x=1127048804; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=lear@cisco.com; z=Subject:Re=3A=20ISMS=20working=20group| From:Eliot=20Lear=20<lear@cisco.com>| Date:Tue,=2013=20Sep=202005=2014=3A50=3A43=20+0200| Content-Type:text/plain=3B=20charset=3DISO-8859-1| Content-Transfer-Encoding:7bit; b=MSB9cxDvT9iHWL2QllVjK3U0k6DA3fjxHEuWecW631QRALpb8TEUS+dBl834uciQwM0dFEkh RHVUz0CLR0PZm6GMN6EqSe8qLcDNfpDXTlgc9OvVe1NKHnuM6uKgwGqDYwatxf5KtD2P75H9tIi MXRiUzAkaAp4G3QU+SEtJG1o=
Authentication-Results: imail.cisco.com; header.From=lear@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3
Content-Transfer-Encoding: 7bit
Cc: ietf@ietf.org, iesg@ietf.org
Subject: Re: ISMS working group
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Brian,
> Let me be clear about what you mean here. You mean that getting through
> firewalls and NATs is equally possible with SSH or BEEP (or TLS or HTTP
> for that matter)?

Yes, pretty much.  The key useful function is an substrate that allows
for multiple channels.

> 
> I'd also observe in terms of charter language that the ability to
> have agents and managers indifferently either side of NATs and
> firewalls, and the ability to support traps in such scenarios,
> are potential charter requirements. But "call home" is a solution,
> and there might be others.

Brian, I would be very happy with the language you mentioned:

  Solution must support {pick your favorite SNMP terminology: command
generators/responders/.../agents/managers} on either side of
  NATs and firewalls

Whether it's CH or some other Thing, as long as it's not incredibly
contortive, I'm okay with it, and I'm perfectly fine with a WG
evaluating such solutions and making a considered decision.

Eliot

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email