Subject: Callhome draft?

From: Andy Bierman <[email-masked]>
Date: Fri, 04 Aug 2006 08:15:25 -0700

Hi,

I was wondering if anyone is willing to be the Editor/author
of 2 drafts to fully specify the Callhome feature for both
BEEP and SSH.  I don't know if this would be Informational,
Experimental, or standards track.

If done correctly, not one sentence in the protocol or notification
drafts will be impacted by the Callhome feature.

IMO, the "southbound interface" for Callhome is application-independent,
and should work the same for any protocol mapping to SSH or BEEP
(BEEP already has this part).  The "northbound interface" of the
Callhome mechanism is protocol-specific, and a mapping to NETCONF
is needed. (NETCONF over BEEP already has this part.)

I think there was interest at the Callhome BOF in a generic
solution, but I hope this doesn't mean the problem will
be abstracted so far away nobody ever works on it.

thanks,
Andy

--
to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.
archive: <http://ops.ietf.org/lists/netconf/>

---

From: Balazs Lengyel <[email-masked]>
Date: Mon, 07 Aug 2006 09:22:17 +0200

Hello,
On the IETF Jurgen in the ISMS group presented a solution. Do you propose we base our 
solution on that one? I feel it would be good. He had some problems with security but I 
believe those can be solved.
Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
TSP System Manager
ECN: 831 7320                        Fax: +36 1 4377792
Tel: +36-1-437-7320     email: [email-masked]

---

From: Andy Bierman <[email-masked]>
Date: Mon, 07 Aug 2006 16:43:51 -0700

Balazs Lengyel wrote:
> Hello,
> On the IETF Jurgen in the ISMS group presented a solution. Do you 
> propose we base our solution on that one? I feel it would be good. He 
> had some problems with security but I believe those can be solved.

I guess that would take care of most of it,
except for the direct mapping to NETCONF.

Andy

---

From: "David B Harrington" <[email-masked]>
Date: Tue, 8 Aug 2006 13:58:18 -0400

Hi,

It is unclear from your message just which proposal you refer to when
saying Juergen presented a solution. I have seen a number of porposals
considered in ISMS that relate to callhome, but none so far that solve
all the problems.

I don't believe that Juergen's proposal has been accepted by the ISMS
WG yet. There is ongoing discussion about multiple approaches to
session reuse and callhome functionality and data access controls that
are related.

As editor of the TMSM and SSHSM WG drafts, I believe the current
consensus in ISMS is to permit session reuse regardless of whether the
session was created as a R/R session or a notification session, in
order to support a callhome functionality, if we can resolve the
security issues presented by a client-server transport session versus
the SNMPv3/VACM security requirements.  

Stay tuned, but the ISMS "solution" is not yet ready to be the basis
of the Netconf WG solution.

David Harrington
[email-masked] 
[email-masked]
[email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Balazs Lengyel
> Sent: Monday, August 07, 2006 3:22 AM
> To: Andy Bierman
> Cc: Netconf (E-mail)
> Subject: Re: Callhome draft?
> 
> Hello,

---

From: Andy Bierman <[email-masked]>
Date: Tue, 08 Aug 2006 11:16:06 -0700

Hi Dave,

Thanks for this clarification.

As I said in a previous email, this feature is generic
enough that the protocol-independent bits should be
done one way, in one document.

There are protocol-specific bits, like the impact on the
capabilities list in the NETCONF <hello>.

IMO we also need a standard "reason-for-calling-home" mechanism.
(Perhaps just a message, not rigid standard content).

The other features are just bells and whistles.

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Sat, 12 Aug 2006 23:36:16 +0200

On Mon, Aug 07, 2006 at 09:22:17AM +0200, Balazs Lengyel wrote:

> propose we base our solution on that one? I feel it would be
> good. He had some problems with security but I believe those can be
> solved.

I am less optimistic there is a reasonable generic solution for SSH
anytime soon. So far, I have only collected a list of reasons why
various approaches do _not_ work. It is too early to document a call
home solution for SSH since we have not found one yet.

/js

-- 
Juergen Schoenwaelder		    International University Bremen
<http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 28725 Bremen, Germany