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

Andy Bierman <[email protected]> Fri, 14 Oct 2005 13:38:19 -0700
Newsgroups gmane.ietf.ops-nm
Message-ID <[email protected]>
Wijnen, Bert (Bert) wrote:

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

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

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