[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Call-home] Re: last call for a Call Home BoF
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: call-home-bounces@ietf.org [mailto:call-home-bounces@ietf.org]On
> Behalf Of Andy Bierman
> Sent: Thursday, October 13, 2005 18:00
> To: Eliot Lear
> Cc: call-home@ietf.org; ops-nm@ops.ietf.org; isms@ietf.org
> 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
> Call-home@ietf.org
> https://www1.ietf.org/mailman/listinfo/call-home
>