Re: ISMS working group and charter problems
Michael Thomas <mat@cisco.com> Wed, 07 September 2005 20:28 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6XD-0005as-ML; Wed, 07 Sep 2005 16:28:43 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED6XC-0005an-FO for ietf@megatron.ietf.org; Wed, 07 Sep 2005 16:28:42 -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 QAA20327 for <ietf@ietf.org>; Wed, 7 Sep 2005 16:28:40 -0400 (EDT)
Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED6aP-0003IM-DC for ietf@ietf.org; Wed, 07 Sep 2005 16:32:03 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 07 Sep 2005 13:28:18 -0700
X-IronPort-AV: i="3.96,177,1122879600"; d="scan'208"; a="658697792:sNHT1375063284"
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 j87KSC4u022483; Wed, 7 Sep 2005 13:28:13 -0700 (PDT)
Received: from [171.71.192.47] (dhcp-171-71-192-47.cisco.com [171.71.192.47]) by imail.cisco.com (8.12.11/8.12.10) with ESMTP id j87KNQ2L012386; Wed, 7 Sep 2005 13:23:27 -0700
Message-ID: <431F4D5E.90307@cisco.com>
Date: Wed, 07 Sep 2005 13:28:14 -0700
From: Michael Thomas <mat@cisco.com>
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Thunderbird/0.8 Mnenhy/0.7.2.0
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Margaret Wasserman <margaret@thingmagic.com>
References: <431DD3BD.9090108@cisco.com> <431DD94C.8070907@dcrocker.net> <261A1E9D259E6FA3B9203B61@B50854F0A9192E8EC6CDA126> <431EB020.8090101@zurich.ibm.com> <431F0A2B.4060805@cisco.com> <p06200743bf44c0efe0a1@[192.168.2.7]>
In-Reply-To: <p06200743bf44c0efe0a1@[192.168.2.7]>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: a=rsa-sha1; q=dns; l=2773; t=1126124607; x=1126556807; c=nowsp; s=nebraska; h=Subject:From:Date:Content-Type:Content-Transfer-Encoding; d=cisco.com; i=mat@cisco.com; z=Subject:Re=3A=20ISMS=20working=20group=20and=20charter=20problems| From:Michael=20Thomas=20<mat@cisco.com>| Date:Wed,=2007=20Sep=202005=2013=3A28=3A14=20-0700| Content-Type:text/plain=3B=20charset=3DISO-8859-1=3B=20format=3Dflowed| Content-Transfer-Encoding:7bit; b=XztQKRyJU9r4WxlA+EYW+TI40CtgY0bycodlXIjA/16u+E+DDZiWSy8DaciJmaIQzIsHqBGU G6xKObEyB2HiUtJ1eJKC7HXR9zeGiz5FqUbcNYRsbL+WWKQTwBLBWPW3OIGrCBja8lFW+8f0242 72OHtqrtoliLJdLOXM6vATzg=
Authentication-Results: imail.cisco.com; header.From=mat@cisco.com; dkim=pass ( message from cisco.com verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88
Content-Transfer-Encoding: 7bit
Cc: Harald Tveit Alvestrand <harald@alvestrand.no>, dcrocker@bbiw.net, Eliot Lear <lear@cisco.com>, IETF Discussion <ietf@ietf.org>
Subject: Re: ISMS working group and charter problems
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
Margaret Wasserman wrote: > > Hi Mike, > > At 8:41 AM -0700 9/7/05, Michael Thomas wrote: > >> In answer to Margaret's question about how it would know >> where to "call home", it seems to me to be about the same >> problem as with traps/informs. I haven't had anything to do >> with this wg, but it seems pretty plausible that you'd >> initiate the session from the agent using a trap/inform >> over tcp/ssh/whatever and then just reuse the connection >> for subsequent pdu's sort of akin to http 1.1 reuse. It >> would just all sort of fall out of the overall snmp >> architecture. > > > So, every time a notification sender sends a trap or notification it > would set-up a TCP connection to each of the notification receivers in > its list and keep that connection up indefinitely? Would it reestablish > ithose connections when they fail? How long would it keep a connections > up if it never receives a command request on that particular > connection? Please remember that not all notification receivers _are_ > command requestors, and not all command requestors are notification > receivers. I think there's a fair amount of room between "never" and "indefinitely" on how/when to keep a connection up. As I mentioned, http 1.1 seems to handle this and if nothing else we certain have a lot of data about its efficacy. > I do think that if you built a mechanism for a command responder to open > a connection to a command requestor, the MIB for configuring the new > mechanism might resemble the MIB that is used to determine notifications > should be sent, but I don't think that it will be identical and I do not > think that the current MIB should be overloaded in this way. Correct me if I'm wrong, but I thought that http 1.1 was pretty spartan on any sort of settings and/or negotiation of the kinds of parameters you brought up. That is, each side decides for itself what those values ought to be, and the provisioning of them is out of scope. Since the web is essentially an any-any kind of environment, is there some reason to believe that a more restrictive relationship -- as one would expect manager to managed to be -- would bring new or different considerations than we already have a lot of experience with? > BTW, nothing about your note explains to me why you think that this > mechanism should be defined in a Security area WG that is working on a > completely separable problem. If you really think that defining call > home for SNMP is something that the IETF should do, I would encourage > you to get together with Eliot and request a BOF in the OPS area. That's because I haven't formed an opinion on it. My main point is that this doesn't seem to me to be any sort of wildly divergent architectural proposition, at least on the front of who "initiates" a connection. As Harald pointed out, I really can't see how you'd prevent some industrious developers from using SNMP in this way regardless of how the working group is chartered, and from that standpoint it might be better to get ahead of the ball on it if it were inevitable, and it does seem to have a fair number of security considerations. The question I have for Eliot though is why he believes that SNMP is the right vehicle for this kind of "call home" functionality in the first place. Maybe it's my own prejudice, but SNMP seems a little klunky for what I'd envision "call home" is trying to achieve. Mike _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
- ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Daniel Senie
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Pekka Savola
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Dave Crocker
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- RE: ISMS working group and charter problems Thomas Gal
- RE: ISMS working group and charter problems Daniel Senie
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- RE: ISMS working group and charter problems Thomas Gal
- Re: ISMS working group and charter problems Steven M. Bellovin
- Re: ISMS working group and charter problems Randy Presuhn
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Harald Tveit Alvestrand
- Re: ISMS working group and charter problems Dave Singer
- Re: ISMS working group and charter problems Iljitsch van Beijnum
- Re: ISMS working group and charter problems Brian E Carpenter
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Jari Arkko
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Jari Arkko
- Firewall considerations (Re: ISMS working group a… Harald Tveit Alvestrand
- Re: ISMS working group and charter problems Melinda Shore
- Re: ISMS working group and charter problems Margaret Wasserman
- Re: ISMS working group and charter problems Margaret Wasserman
- Re: ISMS working group and charter problems Michael Thomas
- Re: ISMS working group and charter problems Margaret Wasserman
- Confusion about ISMS rechartering Sam Hartman
- Re: Confusion about ISMS rechartering Dave Crocker
- RE: ISMS working group and charter problems Fleischman, Eric
- RE: ISMS working group and charter problems Fleischman, Eric
- RE: ISMS working group and charter problems Margaret Wasserman
- RE: ISMS working group and charter problems Fleischman, Eric
- Re: ISMS working group and charter problems Spencer Dawkins
- Re: ISMS working group and charter problems Michael Thomas
- Re: ISMS working group and charter problems Sam Hartman
- Re: ISMS working group and charter problems Juergen Quittek
- Re: ISMS working group and charter problems Daniel Senie
- RE: ISMS working group and charter problems Nelson, David
- Re: ISMS working group and charter problems Tom Petch
- Fwd: ISMS working group and charter problems Rich Morin
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Eliot Lear
- Re: ISMS working group and charter problems Wes Hardaker
- ISMS working group and charter problems Brent Chapman