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

From: "Wijnen, Bert (Bert)" <[email-masked]>
Date: Fri, 14 Oct 2005 12:38:08 +0200

Here is my AD-view on this:

First the NM aspects:
- The topic came up strong in the last ISMS f2f meeting in Paris.
- I (as AD, but also as an individual contributor) worry/worried that
  we might make something (like call-home) a MUST for ISMS while it
  was not a MUST in NETCONF. I think we should be conistsent in our
  NM protocols and try to make sure that the same (security) 
  infrastructure can be used for ISMS and NetConf (and others).
- I also worry/worried about what impact it may have on SNMPv3 (hence
  the discussion on authoritative (engine, information etc). I am 
  happy to see that that is being well discussed on ISMS list

Then the IETF-wide aspects
- I worry/worried that we might be doing a point-solution in the NM
  space, while it seems to me that the CH fiunctionality is an IETF
  wide issue.
- So I at least want to get a much better understanding of what the
  IETF-wide or Architectural aspects/possibilities are.
- Even if we decide to do a point-solution, then I still want to try
  and make sure that we do so based on a well-informed set of 
  discussions including those from other areas.
  
So that is what the BOF (in my view) needs to address.
The result is (as yet) unknown. It may turn out that there are
(reasonably) simple solutions at the IETF-wide level. If so, then we
(NM folk) may want to help define/specify a generic solution that
we can then also use in NM protocols.
If we need to go down the road of a point-solution, then I would hope 
that we at least take into consideration all the things we learn during
the BOF.

Makes sense?

Bert

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Andy Bierman
> Sent: Thursday, October 13, 2005 18:00
> To: Eliot Lear
> Cc: [email-masked]; [email-masked]; [email-masked]
> Subject: [Call-home] Re: last call for a Call Home BoF
> 
> 
> 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
> 
> 
> Andy
> 
> >
> > 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
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/call-home
> 

_______________________________________________
Call-home mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/call-home

---

From: Andy Bierman <[email-masked]>
Date: Fri, 14 Oct 2005 13:38:19 -0700

>that we at least take into consideration all the things we learn during

makes sense to me to do both.

Consider the high-level architectural issues for the generalized problem 
space,
but don't deadlock over a long requirements definition phase.

Use the NETCONF/ISMS problem-space to create a specific/point solution
that meets the architectural needs, get it deployed, learn from the 
experience,
and move on.

Andy