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

Andy Bierman <ietf@andybierman.com> Fri, 14 October 2005 20:38 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWKM-0007Ks-3Y; Fri, 14 Oct 2005 16:38:54 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EQWKJ-0007Io-Uk for call-home@megatron.ietf.org; Fri, 14 Oct 2005 16:38:52 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23230 for <call-home@ietf.org>; Fri, 14 Oct 2005 16:38:45 -0400 (EDT)
Received: from mail.networksolutionsemail.com ([205.178.146.50]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EQWV4-0005Ui-Ki for call-home@ietf.org; Fri, 14 Oct 2005 16:50:01 -0400
Received: (qmail 5460 invoked by uid 78); 14 Oct 2005 20:38:22 -0000
Received: from unknown (HELO ?127.0.0.1?) (24.24.133.237) by mail.networksolutionsemail.com with SMTP; 14 Oct 2005 20:38:22 -0000
Message-ID: <4350173B.3070408@andybierman.com>
Date: Fri, 14 Oct 2005 13:38:19 -0700
From: Andy Bierman <ietf@andybierman.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: "Wijnen, Bert (Bert)" <bwijnen@lucent.com>
Subject: Re: [Call-home] Re: last call for a Call Home BoF
References: <7D5D48D2CAA3D84C813F5B154F43B15508490441@nl0006exch001u.nl.lucent.com>
In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B15508490441@nl0006exch001u.nl.lucent.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.0 (/)
X-Scan-Signature: a492040269d440726bfd84680622cee7
Content-Transfer-Encoding: 7bit
Cc: call-home@ietf.org, ops-nm@ops.ietf.org, isms@ietf.org
X-BeenThere: call-home@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: "Discussion of issues relating to &quot; call home&quot; functionality and firewall traversal" <call-home.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/call-home>
List-Post: <mailto:call-home@ietf.org>
List-Help: <mailto:call-home-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/call-home>, <mailto:call-home-request@ietf.org?subject=subscribe>
Sender: call-home-bounces@ietf.org
Errors-To: call-home-bounces@ietf.org

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


_______________________________________________
Call-home mailing list
Call-home@ietf.org
https://www1.ietf.org/mailman/listinfo/call-home