Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh

Phil Shafer <phil@juniper.net> Tue, 19 July 2011 18:50 UTC

Return-Path: <phil@juniper.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D5D11E8084; Tue, 19 Jul 2011 11:50:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8erCQWAdXKrD; Tue, 19 Jul 2011 11:50:09 -0700 (PDT)
Received: from exprod7og116.obsmtp.com (exprod7og116.obsmtp.com [64.18.2.219]) by ietfa.amsl.com (Postfix) with ESMTP id DF34211E8082; Tue, 19 Jul 2011 11:50:07 -0700 (PDT)
Received: from P-EMHUB01-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob116.postini.com ([64.18.6.12]) with SMTP ID DSNKTiXR305lLaBIGZmiUbzSR/WPTe1umD+z@postini.com; Tue, 19 Jul 2011 11:50:08 PDT
Received: from magenta.juniper.net (172.17.27.123) by P-EMHUB01-HQ.jnpr.net (172.24.192.33) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 19 Jul 2011 11:49:43 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id p6JInev12633; Tue, 19 Jul 2011 11:49:40 -0700 (PDT) (envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.3/8.14.3) with ESMTP id p6JINNRq002843; Tue, 19 Jul 2011 18:23:23 GMT (envelope-from phil@idle.juniper.net)
Message-ID: <201107191823.p6JINNRq002843@idle.juniper.net>
To: Randy Presuhn <randy_presuhn@mindspring.com>
In-Reply-To: <005201cc463f$b0b90060$6801a8c0@oemcomputer>
Date: Tue, 19 Jul 2011 14:23:23 -0400
From: Phil Shafer <phil@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain
Cc: opsawg@ietf.org, netconf@ietf.org
Subject: Re: [Netconf] [OPSAWG] guidance on draft-kwatsen-reverse-ssh
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Network Configuration WG mailing list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netconf>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 19 Jul 2011 18:50:10 -0000

"Randy Presuhn" writes:
>One (I'll call it the "narrow" one) is the question of how a device new to the
>network lets management know that it exists so that it can be (more fully)
>configured. The other (I'll call it the "broad" one) includes the issues of
>overcoming NAT.

The terms "broad" and "narrow" seem meaningless in this discussion.
Can we choose better terms?  "new-device" and "reachability" are
perhaps more self-explanitory.

>The broad problem is a different matter.  David
>Harrington's most persuasive arguments were addressed to it, rather than
>the narrow problem.

Under "Alternative Proposals", he lists:

    Develop call-home as an add-on to existing transports, changing
    only the initiator

which is essentially what Kent's done.

So given that this is an existing problem for which there is no
current solution, what's the best path forward?  Are there issues
with Kent's draft?

Thanks,
 Phil