[Call-home] Re: last call for a Call Home BoF

Andy Bierman <ietf@andybierman.com> Thu, 13 October 2005 17:40 UTC

Received: from localhost.localdomain ([] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ73p-0005bC-CZ; Thu, 13 Oct 2005 13:40:09 -0400
Received: from odin.ietf.org ([] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQ5ZO-0000tr-56 for call-home@megatron.ietf.org; Thu, 13 Oct 2005 12:04:38 -0400
Received: from ietf-mx.ietf.org (ietf-mx []) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25859 for <call-home@ietf.org>; Thu, 13 Oct 2005 12:04:34 -0400 (EDT)
Received: from mail.networksolutionsemail.com ([]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQ5jw-0007pk-1w for call-home@ietf.org; Thu, 13 Oct 2005 12:15:32 -0400
Received: (qmail 30685 invoked by uid 78); 13 Oct 2005 16:00:50 -0000
Received: from unknown (HELO ? ( by mail.networksolutionsemail.com with SMTP; 13 Oct 2005 16:00:50 -0000
Message-ID: <434E8474.7080409@andybierman.com>
Date: Thu, 13 Oct 2005 08:59:48 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Eliot Lear <lear@cisco.com>
References: <434CC589.2020608@cisco.com>
In-Reply-To: <434CC589.2020608@cisco.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 34d35111647d654d033d58d318c0d21a
Content-Transfer-Encoding: 7bit
X-Mailman-Approved-At: Thu, 13 Oct 2005 13:40:08 -0400
Cc: call-home@ietf.org, ops-nm@ops.ietf.org, isms@ietf.org
Subject: [Call-home] Re: last call for a Call Home BoF
X-BeenThere: call-home@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <call-home.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/call-home>
List-Post: <mailto:call-home@ietf.org>
List-Help: <mailto:call-home-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=subscribe>
Sender: call-home-bounces@ietf.org
Errors-To: call-home-bounces@ietf.org

Eliot Lear wrote:

> After all of the mail last month, Bert is considering allowing a BoF 
> on the topic of Call Home.  I initially posted a note to the call-home 
> mailing list announcing the possibility of a BoF.  Response to that 
> note was - well - underwhelming.  If you are interested in seeing one, 
> could you please reply to this email, CCing the call-home mailing 
> list.  Here is a draft agenda.  It is subject to your input.
> If we do not see much input, I'm going to drop the request to Bert.

IMO there is a disconnect between the BoF charter text below and the
email discussions I (mostly) followed in the last month. 
I am in favor of sharply defined work that will achieve integration
between NETCONF and ISMS through foresight and planning.  I'm
not so keen about the open-ended charter text below.

[IMO, this feature is simply defined as "the NETCONF peer
acting in the agent role initiates the session establishment".
There may be additional ISMS requirements, but I don't know.]

I suspected (back at the first NETCONF interim in Sunnyvale)
that our decision to provide this "reverse connect" feature
for BEEP only would come back to bite us -- then even more
when we picked SSH as the mandatory transport.   I think this
functionality is important enough to be available via the
mandatory transport.  (IMO the work can be done as an extension
to the 1.0 specification set.)

Beyond the firewall/NAT issues, I think there are some
important use cases for this feature, especially when
notification generator applications are introduced in NETCONF.
Issues such as mobility, scale, and auto-configuration may
make applications a lot easier to design if the agent
connects to the manager.

> Eliot


> Title: callhome
> Period of time: 1 hour
> Area: ops-nm
> Expected # attendees: 40-60 (small room)
> Don't conflict with: ISMS, ops-area, netconf (if there is one)
> Short Description: Discussion of Architectural Issues Concerning
>            protocols that could benefit from reversing
>            of roles
> Long Description:
> Certain protocols, and in particular management protocols where
> devices on either end of connection take client server roles may
> be able to take advantage of "Call Home" functionality, when
> traditional roles are reversed, and a server connect to a client.
> Examples of existing protocols that make use of call home include
> SMTP [ETRN] and COPS.  At this BoF we will look at extending such
> functionality into other protocols, as well as any architectural
> issues this raises.
> This work stems from efforts in ISMS to extend SNMP to run over SSH,
> as well as work as work that has gone on in NETCONF.
> We will begin with a discussion of 
> draft-lear-callhome-description-0[1,2].txt, which contains a 
> description of call home, what problems it can solve, and what some of 
> the architectural issues are.  During the BoF we may identify 
> additional such issues as well as protocols other than management 
> protocols that could benefit from this work.  An additional potential 
> question should be whether a generic standard or process should be 
> used to implement call home, such as rules for SSH.
> There are three possible outcomes: a working group to add "call home"
> functionality to existing protocols such as SNMP/SSH and NETCONF/SSH,
> use of existing working groups for this purpose, or nothing.
> Chair: Eliot Lear (or tbd)
> Agenda:
> Agenda bashing - 1 minute
> Presentation of draft-lear-callhome-description-00.txt 19 minutes
> Application to SNMP and open areas - 10 minutes
> Discussion including architectural issues - 20 minutes
> Moving Forward Options  - 10 minutes

Call-home mailing list