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
>
>
>