From nobody Mon Mar 3 02:05:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CE681A0D5B for ; Mon, 3 Mar 2014 02:05:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMcScvxrC7DQ for ; Mon, 3 Mar 2014 02:05:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id EFDA11A0DEA for ; Mon, 3 Mar 2014 02:05:21 -0800 (PST) Received: from localhost (dhcp-a6ed.meeting.ietf.org [31.133.166.237]) by mail.tail-f.com (Postfix) with ESMTPSA id E501937C2AA; Mon, 3 Mar 2014 11:05:17 +0100 (CET) Date: Mon, 03 Mar 2014 10:05:16 +0000 (GMT) Message-Id: <20140303.100516.142214666.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: <9285BE1A-181A-43CB-8E1A-DB1F564FA42A@juniper.net> References: <20140219.081730.397755032.mbj@tail-f.com> <9285BE1A-181A-43CB-8E1A-DB1F564FA42A@juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/CO7-Pg8D8xaIptsoLDlnwttxG_U Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:05:27 -0000 Dean Bogdanovic wrote: > > On Feb 19, 2014, at 2:17 AM, Martin Bjorklund > > wrote: > > > > Well, I still don't know if you are talking about TCP keep alives, TLS > > heartbeats / SSH keep alives or NETCONF-layer keep alive (whatever > > that is). I think you mean TLS/SSH but it needs to be spelled out. > > And as for SSH, is there even a standard for keep alives? > > You can configure SSH server and client to keep the sessions > open. There are two config options > ServerAliveInterval > and > ClientAliveInterval These are config parameters for one SSH implementation. This document needs to specify which SSH _mechanism_ is supposed to be used, so that any SSH implementation can be utilized. /martin From nobody Mon Mar 3 02:34:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA0BF1A0DEE for ; Mon, 3 Mar 2014 02:34:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BPO7m5-O5UJ8 for ; Mon, 3 Mar 2014 02:34:14 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id EF03B1A0CEC for ; Mon, 3 Mar 2014 02:34:11 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 485699C; Mon, 3 Mar 2014 11:34:08 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 3884B9A; Mon, 3 Mar 2014 11:34:08 +0100 (CET) Date: Mon, 3 Mar 2014 11:34:08 +0100 (CET) From: Mikael Abrahamsson To: "Reinaldo Penno (repenno)" In-Reply-To: Message-ID: References: User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0_DS7ah49iEn-W30mC9gnNdtsqc Cc: netconf Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:34:17 -0000 On Tue, 25 Feb 2014, Reinaldo Penno (repenno) wrote: > That does not seem the intention of the draft at all. Are we talking about > http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01? > > My expectation of a call home mechanism is about solving the important > problem of discovery decentralization. Well, there are some of us who want to solve the simple call-home problem as well. We proposed this in a separate draft at IETF88, but now we're trying to merge it into a single draft that should solve both. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Mar 3 05:12:27 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4928F1A00C9 for ; Mon, 3 Mar 2014 05:12:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.641 X-Spam-Level: X-Spam-Status: No, score=-0.641 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_SK=1.35, HOST_EQ_SK=0.555, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qm5CgSXqXIdD for ; Mon, 3 Mar 2014 05:12:24 -0800 (PST) Received: from amalka.pantheon.sk (amalka.pantheon.sk [81.89.59.174]) by ietfa.amsl.com (Postfix) with ESMTP id D379C1A00A5 for ; Mon, 3 Mar 2014 05:12:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 4CD1923A3F for ; Mon, 3 Mar 2014 14:12:20 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Authentication-Results: amalka.pantheon.sk (amavisd-new); dkim=neutral reason="invalid (public key: unsupported version)" header.d=pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fdlLGXQl4SWO for ; Mon, 3 Mar 2014 14:12:14 +0100 (CET) Received: from cipisek.dmz.pantheon.local (cipisek.pantheon.sk [81.89.59.176]) by amalka.pantheon.sk (Postfix) with ESMTP for ; Mon, 3 Mar 2014 14:12:14 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 59CBFC9C26 for ; Mon, 3 Mar 2014 14:12:14 +0100 (CET) Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 6RLbnd5fr2cZ for ; Mon, 3 Mar 2014 14:12:12 +0100 (CET) Received: from localhost (localhost.localdomain [127.0.0.1]) by cipisek.dmz.pantheon.local (Postfix) with ESMTP id 53C3FF5FD5 for ; Mon, 3 Mar 2014 14:12:12 +0100 (CET) DKIM-Filter: OpenDKIM Filter v2.7.1 cipisek.dmz.pantheon.local 53C3FF5FD5 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pantheon.sk; s=D7204E10-2735-11E2-9595-0BDFE9028503; t=1393852332; bh=RprtKbvwtSKRJTHYqguTlYuvTNxdV2uKA0w2S32oFlI=; h=Message-ID:Date:From:MIME-Version:To:Subject:Content-Type; b=v2Ao0FChhyZDiMYGmvt7kMGp8hYnMpkTxeQ/JQpUG1QOa9L7L9hdDD3fLQ67/mziY O1mGHB8BRXjq3HKoYmi0kNsPvnYy2T9K0ViLtcAAUrzayD4NC6IcQOtSldeZTbf4ZJ KZLz4pPZaJzl3k0GoLtuZeciVmywO2qdbz2GbFdo= X-Virus-Scanned: amavisd-new at pantheon.sk Received: from cipisek.dmz.pantheon.local ([127.0.0.1]) by localhost (cipisek.dmz.pantheon.local [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id OoP0VzC-PXTB for ; Mon, 3 Mar 2014 14:12:12 +0100 (CET) Received: from [31.133.164.54] (dhcp-a436.meeting.ietf.org [31.133.164.54]) by cipisek.dmz.pantheon.local (Postfix) with ESMTPSA id 124F6C9C26 for ; Mon, 3 Mar 2014 14:12:12 +0100 (CET) Message-ID: <53147F9F.3080404@pantheon.sk> Date: Mon, 03 Mar 2014 14:11:59 +0100 From: Robert Varga User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: netconf@ietf.org References: <20140303104320.23464.50614.idtracker@ietfa.amsl.com> In-Reply-To: <20140303104320.23464.50614.idtracker@ietfa.amsl.com> X-Forwarded-Message-Id: <20140303104320.23464.50614.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------070602020606020402090303" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_7LeReSlZJebaeKq3NQPSJLJL4w Subject: [Netconf] Fwd: New Version Notification for draft-varga-netconf-exi-capability-02.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:12:26 -0000 This is a multi-part message in MIME format. --------------070602020606020402090303 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit FYI, this update fixes a few typos and introduces an optional mechanism for dynamic discovery of available schemas and their use for EXI Schema-informed encoding. Any comments/questions are most welcome. Bye, Robert -------- Original Message -------- Subject: New Version Notification for draft-varga-netconf-exi-capability-02.txt Date: Mon, 03 Mar 2014 02:43:20 -0800 From: internet-drafts@ietf.org To: Robert Varga , Robert Varga A new version of I-D, draft-varga-netconf-exi-capability-02.txt has been successfully submitted by Robert Varga and posted to the IETF repository. Name: draft-varga-netconf-exi-capability Revision: 02 Title: Efficient XML Interchange Capability for NETCONF Document date: 2014-03-03 Group: Individual Submission Pages: 15 URL: http://www.ietf.org/internet-drafts/draft-varga-netconf-exi-capability-02.txt Status: https://datatracker.ietf.org/doc/draft-varga-netconf-exi-capability/ Htmlized: http://tools.ietf.org/html/draft-varga-netconf-exi-capability-02 Diff: http://www.ietf.org/rfcdiff?url2=draft-varga-netconf-exi-capability-02 Abstract: The Network Configuration Protocol (NETCONF) provides mechanisms to install, manipulate, and delete the configuration of network devices via exchange of XML messages in textual representation. Efficient XML Interchange (EXI) is a W3C-recommended binary representation of XML Information Set, which is more efficient from both CPU and bandwidth utilization perspective. This document defines a capability-based extension to the NETCONF protocol that allows peers to agree to exchange protocol messages using EXI encoding. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat --------------070602020606020402090303 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit FYI, this update fixes a few typos and introduces an optional mechanism for dynamic discovery of available schemas and their use for EXI Schema-informed encoding.

Any comments/questions are most welcome.

Bye,
Robert


-------- Original Message --------
Subject: New Version Notification for draft-varga-netconf-exi-capability-02.txt
Date: Mon, 03 Mar 2014 02:43:20 -0800
From: internet-drafts@ietf.org
To: Robert Varga <robert.varga@pantheon.sk>, Robert Varga <robert.varga@pantheon.sk> 


A new version of I-D, draft-varga-netconf-exi-capability-02.txt
has been successfully submitted by Robert Varga and posted to the
IETF repository.

Name:		draft-varga-netconf-exi-capability
Revision:	02
Title:		Efficient XML Interchange Capability for NETCONF
Document date:	2014-03-03
Group:		Individual Submission
Pages:		15
URL:            http://www.ietf.org/internet-drafts/draft-varga-netconf-exi-capability-02.txt
Status:         https://datatracker.ietf.org/doc/draft-varga-netconf-exi-capability/
Htmlized:       http://tools.ietf.org/html/draft-varga-netconf-exi-capability-02
Diff:           http://www.ietf.org/rfcdiff?url2=draft-varga-netconf-exi-capability-02

Abstract:
   The Network Configuration Protocol (NETCONF) provides mechanisms to
   install, manipulate, and delete the configuration of network devices
   via exchange of XML messages in textual representation.  Efficient
   XML Interchange (EXI) is a W3C-recommended binary representation of
   XML Information Set, which is more efficient from both CPU and
   bandwidth utilization perspective.  This document defines a
   capability-based extension to the NETCONF protocol that allows peers
   to agree to exchange protocol messages using EXI encoding.


                                                                                  


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat


--------------070602020606020402090303-- From nobody Mon Mar 3 05:16:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD061A0040 for ; Mon, 3 Mar 2014 05:16:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwtEOJ41iR4s for ; Mon, 3 Mar 2014 05:16:53 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 909DE1A00C9 for ; Mon, 3 Mar 2014 05:16:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 653E2F6E for ; Mon, 3 Mar 2014 14:16:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id b9CH4FqjjfNr for ; Mon, 3 Mar 2014 14:16:49 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Mon, 3 Mar 2014 14:16:49 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C13C2002C for ; Mon, 3 Mar 2014 14:16:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nNORXzXJIRR5; Mon, 3 Mar 2014 14:16:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B59B20017; Mon, 3 Mar 2014 14:16:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0382B2B8FFBC; Mon, 3 Mar 2014 14:16:45 +0100 (CET) Date: Mon, 3 Mar 2014 14:16:45 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140303131645.GA22071@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UJ_fmFuUmGNgbj_-fog_OfQifK8 Subject: [Netconf] reverse ssh document title X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:16:55 -0000 Hi, the title currently is 'Reverse Secure Shell (Reverse SSH)' but since this is only applicable to NETCONF, we may want to pick a more descriptive title. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Mar 3 05:42:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 652231A0179 for ; Mon, 3 Mar 2014 05:42:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzzjrNuU7518 for ; Mon, 3 Mar 2014 05:42:17 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 0A92B1A0175 for ; Mon, 3 Mar 2014 05:42:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EB3C893 for ; Mon, 3 Mar 2014 14:42:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 64dTbpnpyW5v for ; Mon, 3 Mar 2014 14:42:13 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP for ; Mon, 3 Mar 2014 14:42:13 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0CFC22002C for ; Mon, 3 Mar 2014 14:42:13 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kcePsaHnUbu9; Mon, 3 Mar 2014 14:42:12 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D6FFF20017; Mon, 3 Mar 2014 14:42:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8965B2B9018F; Mon, 3 Mar 2014 14:42:08 +0100 (CET) Date: Mon, 3 Mar 2014 14:42:08 +0100 From: Juergen Schoenwaelder To: netconf@ietf.org Message-ID: <20140303134208.GA22152@elstar.local> Mail-Followup-To: netconf@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Y9MPHckLTIeNj9tHzRlVcE8tD94 Subject: [Netconf] tls heartbeat extension X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 13:42:18 -0000 Hi, RFC 6520 defines a TLS heartbeat extension which may be used to provide a keep alive mechanism within TLS (unless we want to do keep alive within the application protocol proper). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Mar 3 06:01:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 212A41A012C; Mon, 3 Mar 2014 06:01:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RAr6CTk2iBbW; Mon, 3 Mar 2014 06:00:59 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id C62061A0114; Mon, 3 Mar 2014 06:00:56 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WKTQL-0001vz-32; Mon, 03 Mar 2014 15:00:53 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WKTQ8-000QDh-Ac; Mon, 03 Mar 2014 15:00:42 +0100 Date: Mon, 3 Mar 2014 15:00:40 +0100 From: David Lamparter To: netconf@ietf.org Message-ID: <20140303140039.GZ856433@jupiter.n2.diac24.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ksKgsruY_YICGTZ_aPpwAy4MNT8 Cc: netmod@ietf.org Subject: [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:01:01 -0000 Hi, (this is the mail version of the somewhat garbled comment on the mic) The original question was, how the configured device chooses a "VPN" for either incoming or outgoing connections. This referred to VRF instances. In particular, for the very simplest case where this matters, there are devices that have out of band management ports and treat those as a VRF. So, both for listening and for connecting, the device needs to choose between "VR-Default" and "VR-Mgmt" (actual names, guess the vendor.) It could even listen in both VRFs, to be manageable inband (normal ops maybe?) and out of band (network in flames?). Even though this was raised on the server config model, this is a rather generic problem. E.g. specifying a NTP or Syslog server has the same issue. (Cc' from netconf to netmod due to this.) NB: I haven't followed this topic, there might be some simple answer that I'm not aware of. -David (Sorry for the garbled jump to the mic, this wasn't on my radar, I was only able to parse the meaning of "VPN".) From nobody Mon Mar 3 06:02:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 32B671A0134 for ; Mon, 3 Mar 2014 06:02:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AGhoiO95jRUB for ; Mon, 3 Mar 2014 06:02:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id EEFB91A0112 for ; Mon, 3 Mar 2014 06:02:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=228; q=dns/txt; s=iport; t=1393855341; x=1395064941; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=32b8l8tNr8vcfbk9bHOkzqLeMkb6ypwHGDRuXIlHMKk=; b=JH+MkyJ7TvWM9P0C6dpA2nC69akZ4rkK1rysYygE1+wFBXMQyKjoqpj1 b+fCLEkF+E4E9QmK9pDewCq9eGgN8aSVy0qvpEo2gSJjsS2Tfv4EAGB8R 9VVkJ0Fyiwc1Mcw9v2duivaVfKfjxXVw4weMMUcxWdhXkUqGQ21tJyUtI U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAO6KFFOQ/khM/2dsb2JhbABagwbDAxZ0gmRAPRYYAwIBAgFLDQgBAYd1nHWvdBeTGAEDmDyGSothgy08 X-IronPort-AV: E=Sophos;i="4.97,577,1389744000"; d="scan'208";a="2194766" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-3.cisco.com with ESMTP; 03 Mar 2014 14:02:20 +0000 Received: from [10.61.205.203] ([10.61.205.203]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s23E2Jxr022834 for ; Mon, 3 Mar 2014 14:02:19 GMT Message-ID: <53148B6B.3020608@cisco.com> Date: Mon, 03 Mar 2014 14:02:19 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: NETCONF Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sy3iRxSDrkuozUsHJ2MvX-N5Udo Subject: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:02:24 -0000 Dear all, As briefly discussed today in the NETCONF session, I believe that a VRF-aware call home function is useful. This VRF-aware addition had to be done for syslog, IPFIX, etc... Regards, Benoit (as a contributor) From nobody Mon Mar 3 06:07:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D1AC1A0179 for ; Mon, 3 Mar 2014 06:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Xr0I6O4-Isxr for ; Mon, 3 Mar 2014 06:07:42 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 34EE01A0198 for ; Mon, 3 Mar 2014 06:07:41 -0800 (PST) Received: from localhost (dhcp-a6ed.meeting.ietf.org [31.133.166.237]) by mail.tail-f.com (Postfix) with ESMTPSA id 75A4837C2AD; Mon, 3 Mar 2014 15:07:37 +0100 (CET) Date: Mon, 03 Mar 2014 14:07:36 +0000 (GMT) Message-Id: <20140303.140736.508664771.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <53148B6B.3020608@cisco.com> References: <53148B6B.3020608@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hInjX3CNFf-KkqaDdCzM7SCgDgk Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:07:43 -0000 Benoit Claise wrote: > Dear all, > > As briefly discussed today in the NETCONF session, I believe that a > VRF-aware call home function is useful. > This VRF-aware addition had to be done for syslog, IPFIX, etc... Can you send pointers? /martin From nobody Mon Mar 3 06:16:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B8171A0132 for ; Mon, 3 Mar 2014 06:16:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QtTdDSUyLJc4 for ; Mon, 3 Mar 2014 06:16:31 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id C61A81A0162 for ; Mon, 3 Mar 2014 06:16:30 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WKTfL-0002ox-TY; Mon, 03 Mar 2014 15:16:23 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WKTf9-000R6U-4g; Mon, 03 Mar 2014 15:16:13 +0100 Date: Mon, 3 Mar 2014 15:16:11 +0100 From: David Lamparter To: Martin Bjorklund Message-ID: <20140303141611.GA856433@jupiter.n2.diac24.net> References: <53148B6B.3020608@cisco.com> <20140303.140736.508664771.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140303.140736.508664771.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QW6RR5KUGkCvN72JWh7xpVYP2CM Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:16:32 -0000 On Mon, Mar 03, 2014 at 02:07:36PM +0000, Martin Bjorklund wrote: > Benoit Claise wrote: > > Dear all, > > > > As briefly discussed today in the NETCONF session, I believe that a > > VRF-aware call home function is useful. > > This VRF-aware addition had to be done for syslog, IPFIX, etc... > > Can you send pointers? Effectively, we need to specify the routing-cfg's "routing/routing-instance/name" key along with any configured binding / connection IP address, since the IP address alone is not an unique identifier as soon as there's more than one routing instance / VRF. (For those unaware of what a VRF is - netconf isn't all routers - a VRF is simply an independent instance of the entire IP stack, with its own routing table, and its own IP addresses, and they can overlap when routing customer's private networks. You can't open a socket without specifying its VRF - that could even be a security problem - though sometimes there's a default management VRF.) -David From nobody Mon Mar 3 06:17:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15A9A1A0137 for ; Mon, 3 Mar 2014 06:17:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yx1JEogM-cZs for ; Mon, 3 Mar 2014 06:17:23 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 679C11A0108 for ; Mon, 3 Mar 2014 06:17:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=693; q=dns/txt; s=iport; t=1393856241; x=1395065841; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=csb6UT/LqhtQ5GHPQ6La3cMoHESrzlLucCo17KycKcw=; b=L367p2AkMKs5kVR2DyZdmc31lAZbNBQMsExbiHcXVtqyIYKmxoB2DqbX tXL5UfDlor6iJPDsY6GXN5S1TrGNcfVA30ylCc8/40j3OsBGA/Lit1I9Y KotrL6qk+PdK4HDAlvpsn8Fl5wGFPiivhDSZh/7Tztcw1aNjT4v7G+DUh c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFAJmOFFOQ/khL/2dsb2JhbABagwbBVwEJgSIWdIIlAQEBBDhAARALDgoJFg8JAwIBAgFFBg0BBQIBAYd1zGsXjlkHhDgBA5g8hkqLYYMtPA X-IronPort-AV: E=Sophos;i="4.97,577,1389744000"; d="scan'208";a="2196546" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-3.cisco.com with ESMTP; 03 Mar 2014 14:17:20 +0000 Received: from [10.61.205.203] ([10.61.205.203]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23EHJF0017300; Mon, 3 Mar 2014 14:17:19 GMT Message-ID: <53148EEF.9060605@cisco.com> Date: Mon, 03 Mar 2014 14:17:19 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Bjorklund References: <53148B6B.3020608@cisco.com> <20140303.140736.508664771.mbj@tail-f.com> In-Reply-To: <20140303.140736.508664771.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/f4Wc3TQ0XQGe8i_CSeQ1ug0bUm4 Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:17:25 -0000 On 3/03/2014 14:07, Martin Bjorklund wrote: > Benoit Claise wrote: >> Dear all, >> >> As briefly discussed today in the NETCONF session, I believe that a >> VRF-aware call home function is useful. >> This VRF-aware addition had to be done for syslog, IPFIX, etc... > Can you send pointers? Let me send you some CLI, for illustration. For syslog: Device(config)# logging host 10.10.10.10 vrf vpn1 For IPFIX: Device(config)# flow exporter MyExporter Device(config-flow)# destination 10.10.10.10 vrf vpn1 Device(config-flow)# export-protocol ipfix I'm sure you will be able to look up some documentation. Regards, Benoit > > > /martin > From nobody Mon Mar 3 06:39:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 562431A01E2 for ; Mon, 3 Mar 2014 06:39:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iXFpSautOBjH for ; Mon, 3 Mar 2014 06:39:17 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C96901A01DB for ; Mon, 3 Mar 2014 06:39:16 -0800 (PST) Received: from localhost (dhcp-a6ed.meeting.ietf.org [31.133.166.237]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E73C39438E; Mon, 3 Mar 2014 15:39:13 +0100 (CET) Date: Mon, 03 Mar 2014 14:39:12 +0000 (GMT) Message-Id: <20140303.143912.330330257.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <53148EEF.9060605@cisco.com> References: <53148B6B.3020608@cisco.com> <20140303.140736.508664771.mbj@tail-f.com> <53148EEF.9060605@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Zvw4ePCTx71-BXa3VrhDIUvaO_E Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:39:18 -0000 Benoit Claise wrote: > On 3/03/2014 14:07, Martin Bjorklund wrote: > > Benoit Claise wrote: > >> Dear all, > >> > >> As briefly discussed today in the NETCONF session, I believe that a > >> VRF-aware call home function is useful. > >> This VRF-aware addition had to be done for syslog, IPFIX, etc... > > Can you send pointers? > > Let me send you some CLI, for illustration. > > For syslog: > > Device(config)# logging host 10.10.10.10 vrf vpn1 > > For IPFIX: > Device(config)# flow exporter MyExporter > Device(config-flow)# destination 10.10.10.10 vrf vpn1 > Device(config-flow)# export-protocol ipfix I was looking for pointers to IETF documents, not vendor-specifics. I know how it is done in this product... /martin From nobody Mon Mar 3 06:47:45 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4C431A01F7 for ; Mon, 3 Mar 2014 06:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D53Z7OXhUUEw for ; Mon, 3 Mar 2014 06:47:42 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 6D12B1A01F1 for ; Mon, 3 Mar 2014 06:47:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1109; q=dns/txt; s=iport; t=1393858060; x=1395067660; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=GceTavEgrjsoW4Zf/IZw7VZvhnz9NLWoQfMuXDdc7Lg=; b=UD7O6MNTl2rkFptsu036ATZCbMRHpiuqPm3xFsuX+0ZsJ6KSqF7wyHeA cXjVcjyOemFe2+RueoYhqHdXsPnFEKNp6hPC35CGx54J/2yyuD1anco0l CYu4bwrqGRl0HKhwJ5e2f7yrdXKtx0L3JceXYBmVfuv2tVU7FzESBDHJ2 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgEFAHyVFFOQ/khR/2dsb2JhbABagwbBYoEhFnSCJQEBAQQ4QAEQCw4KCRYPCQMCAQIBRQYNAQUCAQGHdcxkF45ZB4Q4AQOYPIZKi2GDLTw X-IronPort-AV: E=Sophos;i="4.97,577,1389744000"; d="scan'208";a="2200237" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-3.cisco.com with ESMTP; 03 Mar 2014 14:47:38 +0000 Received: from [10.61.205.203] ([10.61.205.203]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s23ElcF2021097; Mon, 3 Mar 2014 14:47:38 GMT Message-ID: <5314960A.4040501@cisco.com> Date: Mon, 03 Mar 2014 14:47:38 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Bjorklund References: <53148B6B.3020608@cisco.com> <20140303.140736.508664771.mbj@tail-f.com> <53148EEF.9060605@cisco.com> <20140303.143912.330330257.mbj@tail-f.com> In-Reply-To: <20140303.143912.330330257.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/w5GXXe49BE5PfDbFsFWZ6myvTks Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:47:44 -0000 On 3/03/2014 14:39, Martin Bjorklund wrote: > Benoit Claise wrote: >> On 3/03/2014 14:07, Martin Bjorklund wrote: >>> Benoit Claise wrote: >>>> Dear all, >>>> >>>> As briefly discussed today in the NETCONF session, I believe that a >>>> VRF-aware call home function is useful. >>>> This VRF-aware addition had to be done for syslog, IPFIX, etc... >>> Can you send pointers? >> Let me send you some CLI, for illustration. >> >> For syslog: >> >> Device(config)# logging host 10.10.10.10 vrf vpn1 >> >> For IPFIX: >> Device(config)# flow exporter MyExporter >> Device(config-flow)# destination 10.10.10.10 vrf vpn1 >> Device(config-flow)# export-protocol ipfix > I was looking for pointers to IETF documents, not vendor-specifics. And that's exactly my point. Because the VRF-aware extension was not introduced day one in the IETF specs (most probably because the customer demand was not there day one), we're left with vendor-specific extensions. Regards, Benoit > I > know how it is done in this product... > > > /martin > . > From nobody Mon Mar 3 06:58:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A125E1A004A for ; Mon, 3 Mar 2014 06:58:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Anm6qKW_6D2o for ; Mon, 3 Mar 2014 06:58:56 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C5A71A0032 for ; Mon, 3 Mar 2014 06:58:56 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WKUKS-00051d-9X; Mon, 03 Mar 2014 15:58:52 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WKUKF-000TdK-OC; Mon, 03 Mar 2014 15:58:41 +0100 Date: Mon, 3 Mar 2014 15:58:39 +0100 From: David Lamparter To: Martin Bjorklund Message-ID: <20140303145839.GB104882@jupiter.n2.diac24.net> References: <53148B6B.3020608@cisco.com> <20140303.140736.508664771.mbj@tail-f.com> <53148EEF.9060605@cisco.com> <20140303.143912.330330257.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140303.143912.330330257.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/D4RmuJ5f0o6qaamoMQ0iQ7mpxIA Cc: netconf@ietf.org Subject: Re: [Netconf] VRF-aware call home function X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 14:58:57 -0000 On Mon, Mar 03, 2014 at 02:39:12PM +0000, Martin Bjorklund wrote: > Benoit Claise wrote: > > On 3/03/2014 14:07, Martin Bjorklund wrote: > > > Benoit Claise wrote: > > >> Dear all, > > >> > > >> As briefly discussed today in the NETCONF session, I believe that a > > >> VRF-aware call home function is useful. > > >> This VRF-aware addition had to be done for syslog, IPFIX, etc... > > > Can you send pointers? > > > > Let me send you some CLI, for illustration. > > > > For syslog: > > > > Device(config)# logging host 10.10.10.10 vrf vpn1 > > > > For IPFIX: > > Device(config)# flow exporter MyExporter > > Device(config-flow)# destination 10.10.10.10 vrf vpn1 > > Device(config-flow)# export-protocol ipfix > > I was looking for pointers to IETF documents, not vendor-specifics. I > know how it is done in this product... We've gotten as far as configuring VRFs in netmod's routing-cfg, where at some point it was determined that these had names which are strings. And, essentially, 5.1 on netmod-routing-cfg describes this nicely. It's just that we didn't add a reference to this name in places we have outgoing/incoming connections modeled. -David From nobody Mon Mar 3 09:06:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C94C81A01E7 for ; Mon, 3 Mar 2014 09:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PrCh3ACE6wdQ for ; Mon, 3 Mar 2014 09:05:58 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id C345E1A0258 for ; Mon, 3 Mar 2014 09:05:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1147; q=dns/txt; s=iport; t=1393866355; x=1395075955; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=yxhENZqSHzlH7hZZ2Hgg/jZMKJra1O2JrFti9ToTDg4=; b=RxYi96dPzoOjLRJ4bE5eSRwQvH6oqoMC7jrGbt4pDZdwRzMqBzhtrtKD bKjCxPzr+BSk2tiFI1II03gvCYDh8Pefcq2xFZo+341JkMoiMtTyTNei9 KsdqBrTa+oz5/y6wPJpt1lNx764K4D12YNwRm7C2a09332eJ1YbJvMUjC o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhgFAJG1FFOtJV2Z/2dsb2JhbABagwY7V8BQgSIWdIIlAQEBAwE6PwULAgEIDgMEAQELFBAyHQgCBA4FCIdpCA3MJxeNdxEBHzEHgySBFASZbpB5gy2BcTk X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="307704780" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-5.cisco.com with ESMTP; 03 Mar 2014 17:05:54 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23H5scK008369 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 17:05:54 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.98]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 11:05:54 -0600 From: "Reinaldo Penno (repenno)" To: Mikael Abrahamsson Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AIAAoZQA//+BeACAAIplAP//fbMAAStrnQAAAQomEQ== Date: Mon, 3 Mar 2014 17:05:53 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B7D500E@xmb-rcd-x04.cisco.com> References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.75.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/MrzfnPwOV9ntO5VrZs0zF-gsR0c Cc: netconf Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:06:01 -0000 Hi Mikael,=0A= =0A= what is the actual problem you are trying to solve that needs "call home" ?= Is it NAT traversal issues where device is on the public side of NAT?=0A= =0A= thanks,=0A= =0A= =0A= =0A= ________________________________________=0A= From: Mikael Abrahamsson [swmike@swm.pp.se]=0A= Sent: Monday, March 03, 2014 2:34 AM=0A= To: Reinaldo Penno (repenno)=0A= Cc: Juergen Schoenwaelder; netconf=0A= Subject: Re: [Netconf] NETCONF call home and new port assignment=0A= =0A= On Tue, 25 Feb 2014, Reinaldo Penno (repenno) wrote:=0A= =0A= > That does not seem the intention of the draft at all. Are we talking abou= t=0A= > http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01?=0A= >=0A= > My expectation of a call home mechanism is about solving the important=0A= > problem of discovery decentralization.=0A= =0A= Well, there are some of us who want to solve the simple call-home problem= =0A= as well. We proposed this in a separate draft at IETF88, but now we're=0A= trying to merge it into a single draft that should solve both.=0A= =0A= --=0A= Mikael Abrahamsson email: swmike@swm.pp.se=0A= From nobody Mon Mar 3 09:06:51 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0606F1A016A for ; Mon, 3 Mar 2014 09:06:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zRQPcD8s6pPT for ; Mon, 3 Mar 2014 09:06:48 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id DF64F1A01C3 for ; Mon, 3 Mar 2014 09:06:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=906; q=dns/txt; s=iport; t=1393866405; x=1395076005; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Y85T3ovHJmiXYFZmPbzSuS4P2EFq1FvJfcqBq3Txp8Y=; b=QhgSAH5tfy1tXD1ZYkFGc8WAbeI+SaxGpB1GXsSwk+joMbAYCjlY4Al4 oyfokkuOe4C5JMWkjrK5HVRuGnf24fmdkI/4Mm/TmOmjT5Oo7smZHXtEH g0YT/Nel/eRpdgPAxYUIN6lnHAj+8/SXqgJn6gEWqUuy79jIkl36FqTNx w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANy1FFOQ/khM/2dsb2JhbABagwbDBBZ0gmRAPRYYAwIBAgFLDQgBAYd1nHqvOheTGAEDiUuOcYZKi2GDSx4 X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="6969574" Received: from ams-core-3.cisco.com ([144.254.72.76]) by aer-iport-1.cisco.com with ESMTP; 03 Mar 2014 17:06:44 +0000 Received: from [10.61.103.190] (dhcp-10-61-103-190.cisco.com [10.61.103.190]) by ams-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s23H6ik9017339 for ; Mon, 3 Mar 2014 17:06:44 GMT Message-ID: <5314B6A3.2040602@cisco.com> Date: Mon, 03 Mar 2014 12:06:43 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/h0sZvCKgsjCrbvRxvR3dzcKHMYg Subject: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:06:50 -0000 Kent mentioned the open issue with unsigned configlets on USB keys (or near-field). He alluded to some comments that I had made on the ZeroTouch draft. While I see the convenience and benefit of allowing unsigned configlets, I was worried that if I have a device in a secure environment (e.g., clean room in a DC), that an attacker doesn't need to get into this room to circumvent security (i.e., they don't need _physical_ security). Instead, they just need to get a hold of my USB key and insert a malicious configlet. Then I need to insert it into my otherwise physically secure device, and it will load the [unsigned] malicious bootstrap config. Kent's argument was that one should check the contents of the configlet before loading (it is clear text after all). So this may be a non-issue. However, I wanted to raise it with the WG to see what others think. Joe From nobody Mon Mar 3 09:17:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D20BC1A01D6 for ; Mon, 3 Mar 2014 09:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JMYVV-1MxeGh for ; Mon, 3 Mar 2014 09:16:58 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id 4D9AD1A01CF for ; Mon, 3 Mar 2014 09:16:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=977; q=dns/txt; s=iport; t=1393867015; x=1395076615; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=SlS9iVmbCQWsJ5lOc6V35U0VpmyniFwmFLqAEIswbSI=; b=fvod64ajXLzpb3qs3/Y9BvDLEdyKvAxPw+XfNEZUundNjeysYqrWtmc3 pu63moJFu6gtJXYZSEwE/tNwHPSWS7q0O+4AWKmaBmGgrKqO6VlcRkmG0 J9bZcYWLGXD66cZm3xNkA8cf9TrODkbD3pZzqJ8CjgMSOglpW9ZjbTJcq E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFANq3FFOQ/khR/2dsb2JhbABagwbDBRZ0gmRAPRYYAwIBAgFLDQgBAYd1nH2vOheTGAEDiUuOcYZKi2GDSx6BLiQ X-IronPort-AV: E=Sophos;i="4.97,578,1389744000"; d="scan'208";a="6304338" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-2.cisco.com with ESMTP; 03 Mar 2014 17:16:54 +0000 Received: from [10.61.103.190] (dhcp-10-61-103-190.cisco.com [10.61.103.190]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s23HGsAm024496 for ; Mon, 3 Mar 2014 17:16:54 GMT Message-ID: <5314B906.6090107@cisco.com> Date: Mon, 03 Mar 2014 12:16:54 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "netconf@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/x9zr5uF0WZuYo5XhpxhroFLYpdM Subject: [Netconf] Upgrade vs. downgrade X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:17:01 -0000 A point was raised during the meeting that the ZeroTouch draft should allow for an image _upgrade_ only (where new image has a version > old image). There were counter points raised that as long as the image is signed, it shouldn't matter the direction (up or down[grade]). I agree with the counter points. We have seen cases where a newer rev of code (sometimes with newer features) includes new security bugs that can be exploited when the older version of code is safe. To say we can only go up doesn't protect the operator from a security vulnerability. Additionally, as was raised as a counter-point, operators may have a standard image that they need for their environment (sometimes to have the device work at all). This may be a down-revved image from what is shipped on the device. I think we should allow for image moves in any direction as long as they can be verified and validated as is pointed out in the draft currently. Joe From nobody Mon Mar 3 09:39:43 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F3CB1A02EE for ; Mon, 3 Mar 2014 09:39:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lFNXo7JY2wul for ; Mon, 3 Mar 2014 09:39:38 -0800 (PST) Received: from mail-ob0-x22e.google.com (mail-ob0-x22e.google.com [IPv6:2607:f8b0:4003:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id A69301A0256 for ; Mon, 3 Mar 2014 09:39:38 -0800 (PST) Received: by mail-ob0-f174.google.com with SMTP id wo20so4790422obc.5 for ; Mon, 03 Mar 2014 09:39:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qGCBVsepVGMFUFrFQfLvq95DK+UfKzoUP8AI4r91cKY=; b=SPknJjF6L7/ULpP4tnPEEi/Wt+7tQK46C1aX6YrDYGtEyuFGvmle/JnooDqhU56T8x JMuLi2XztObyhy3rI2vERrQlM9cXapBED5HU6A3KYMlKiel9XVEyj+o0O9NuVa6NecoB 0dKrdVK5tYY0YdclmPaopDrfBisd/y5mqd67ZOzcjCJqGDHBR7uvs10z/l08QSYfUfWW jO4y2qm3qLaPQT+NXIksIhScLGfHKhw5CVxA355t6Vw7c69tCHyDgsh3kwL/bn7+HvZb 1p3yitfy97bubpCdNE+LpM7Dr++NnTQspDYPKvpaDgR6I+s51arpWeh7BckzZacdg9Aw KpiQ== MIME-Version: 1.0 X-Received: by 10.182.102.7 with SMTP id fk7mr28077671obb.28.1393868375717; Mon, 03 Mar 2014 09:39:35 -0800 (PST) Received: by 10.182.241.2 with HTTP; Mon, 3 Mar 2014 09:39:35 -0800 (PST) In-Reply-To: <5314B906.6090107@cisco.com> References: <5314B906.6090107@cisco.com> Date: Mon, 3 Mar 2014 12:39:35 -0500 Message-ID: From: ian duncan To: Joe Marcus Clarke Content-Type: multipart/alternative; boundary=089e015369f065fc1804f3b74521 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6POmhPFF_rK4LB5BHZz9QBrc27k Cc: "netconf@ietf.org" Subject: Re: [Netconf] Upgrade vs. downgrade X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:39:41 -0000 --089e015369f065fc1804f3b74521 Content-Type: text/plain; charset=ISO-8859-1 Hello -- Having taken to the mike to challenge Wes I offer the following. Believe I understand a desire to confirm one is NOT regressing to a more broken code image. What I'd wanted to question is whether the mechanism suggested was suitable to achieve this goal, and in particular in a case where little to no correlation exists between the code running the initial ZTP firmware and the ultimate desired functional code image. Phrased as a question, how can one presumptively infer from arbitrary version numbering embedded that some code image has fewer issues--security related or otherwise? Thanks .. Ian On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke wrote: > A point was raised during the meeting that the ZeroTouch draft should > allow for an image _upgrade_ only (where new image has a version > old > image). There were counter points raised that as long as the image is > signed, it shouldn't matter the direction (up or down[grade]). > > I agree with the counter points. We have seen cases where a newer rev of > code (sometimes with newer features) includes new security bugs that can be > exploited when the older version of code is safe. To say we can only go up > doesn't protect the operator from a security vulnerability. > > Additionally, as was raised as a counter-point, operators may have a > standard image that they need for their environment (sometimes to have the > device work at all). This may be a down-revved image from what is shipped > on the device. > > I think we should allow for image moves in any direction as long as they > can be verified and validated as is pointed out in the draft currently. > > Joe > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e015369f065fc1804f3b74521 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hello --

Having taken to the mike to ch= allenge Wes I offer the following.

Believe I under= stand a desire to confirm one is NOT regressing to a more broken code image= . What I'd wanted to question is whether=A0the mechanism suggested was = suitable to achieve this goal, and in particular in a case where little to = no correlation exists between the code running the initial ZTP firmware and= the ultimate desired functional code image. Phrased as a question, how can= one presumptively infer from arbitrary version numbering embedded that som= e code image has fewer issues--security related or otherwise?

Thanks .. Ian


<= br>






On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke <jcl= arke@cisco.com> wrote:
A point was raised during the meeting that t= he ZeroTouch draft should allow for an image _upgrade_ only (where new imag= e has a version > old image). =A0There were counter points raised that a= s long as the image is signed, it shouldn't matter the direction (up or= down[grade]).

I agree with the counter points. =A0We have seen cases where a newer rev of= code (sometimes with newer features) includes new security bugs that can b= e exploited when the older version of code is safe. =A0To say we can only g= o up doesn't protect the operator from a security vulnerability.

Additionally, as was raised as a counter-point, operators may have a standa= rd image that they need for their environment (sometimes to have the device= work at all). =A0This may be a down-revved image from what is shipped on t= he device.

I think we should allow for image moves in any direction as long as they ca= n be verified and validated as is pointed out in the draft currently.

Joe

_______________________________________________
Netconf mailing list
Netconf@ietf.org<= br> https://www.ietf.org/mailman/listinfo/netconf

--089e015369f065fc1804f3b74521-- From nobody Mon Mar 3 09:55:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A04EE1A0002 for ; Mon, 3 Mar 2014 09:55:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTTl9cqlX3Hr for ; Mon, 3 Mar 2014 09:55:53 -0800 (PST) Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) by ietfa.amsl.com (Postfix) with ESMTP id 483991A00B6 for ; Mon, 3 Mar 2014 09:55:52 -0800 (PST) Received: by uplift.swm.pp.se (Postfix, from userid 501) id 2EA269C; Mon, 3 Mar 2014 18:55:48 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 2AB829A; Mon, 3 Mar 2014 18:55:48 +0100 (CET) Date: Mon, 3 Mar 2014 18:55:48 +0100 (CET) From: Mikael Abrahamsson To: "Reinaldo Penno (repenno)" In-Reply-To: <45A697A8FFD7CF48BCF2BE7E106F06040B7D500E@xmb-rcd-x04.cisco.com> Message-ID: References: , <45A697A8FFD7CF48BCF2BE7E106F06040B7D500E@xmb-rcd-x04.cisco.com> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) Organization: People's Front Against WWW MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mMrXXGrF2IZnSkutrNXYIvqaCo8 Cc: netconf Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 17:55:54 -0000 On Mon, 3 Mar 2014, Reinaldo Penno (repenno) wrote: > what is the actual problem you are trying to solve that needs "call > home" ? Is it NAT traversal issues where device is on the public side of > NAT? The CPE does SLAAC for WAN IPv6 address so we have no idea what address to talk to it on. -- Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Mar 3 10:00:31 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 971671A010F for ; Mon, 3 Mar 2014 10:00:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 54oAW-2uK3uS for ; Mon, 3 Mar 2014 10:00:29 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 4C38D1A010B for ; Mon, 3 Mar 2014 10:00:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=624; q=dns/txt; s=iport; t=1393869626; x=1395079226; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=tpBimd3xGuqZiWfPoP8de6FvZNjz9cvVKI5OpOy2/jg=; b=D5V0FLmIQ6wyKVohpv1sc5UN/zG2xfIhjPWDx47INCfD5GAypUdSKmTd P/sNhBMxdmijAfN+vUn/z6XxntK1bQpbfXrGgIcCcuMuWn0cTgE4Whoaz 1xdB5FobELuEeKGsVwf/AJpBKX/qgtVgEy7YzPJfjYgSbGoIwaBZ79vmo g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFAGLCFFOtJXG9/2dsb2JhbABagwaBEsBTgSQWdIIlAQEBBDo/EgEIDgoeQiUCBA4Fh3nMPheNdxEBUAeEOAEDmDySK4MtgXE5 X-IronPort-AV: E=Sophos;i="4.97,579,1389744000"; d="scan'208";a="307733850" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-6.cisco.com with ESMTP; 03 Mar 2014 18:00:26 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s23I0PvX024136 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 18:00:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.98]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 12:00:25 -0600 From: "Reinaldo Penno (repenno)" To: Mikael Abrahamsson Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AIAAoZQA//+BeACAAIplAP//fbMAAStrnQAAAQomEQAOYqgA//97MIA= Date: Mon, 3 Mar 2014 18:00:24 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.75.20] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kkjNyDURdq9XB40n35MFI9By9b0 Cc: netconf Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:00:30 -0000 Interesting use-case. I believe this is the type of problem the draft tries to tackle: installing devices without having to pre-provision IP addresses on NMS/Netconf. On 3/3/14, 9:55 AM, "Mikael Abrahamsson" wrote: >On Mon, 3 Mar 2014, Reinaldo Penno (repenno) wrote: > >> what is the actual problem you are trying to solve that needs "call >> home" ? Is it NAT traversal issues where device is on the public side >>of=20 >> NAT? > >The CPE does SLAAC for WAN IPv6 address so we have no idea what address >to=20 >talk to it on. > >--=20 >Mikael Abrahamsson email: swmike@swm.pp.se From nobody Mon Mar 3 10:30:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6B01A030E for ; Mon, 3 Mar 2014 10:29:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iW_p-vhVQQtk for ; Mon, 3 Mar 2014 10:29:55 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id A58B01A01C7 for ; Mon, 3 Mar 2014 10:29:55 -0800 (PST) Received: from mail39-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Mon, 3 Mar 2014 18:29:52 +0000 Received: from mail39-ch1 (localhost [127.0.0.1]) by mail39-ch1-R.bigfish.com (Postfix) with ESMTP id 6D404600B3; Mon, 3 Mar 2014 18:29:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail39-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(199002)(377454003)(189002)(51704005)(81542001)(65816001)(81342001)(47736001)(74876001)(74502001)(59766001)(50986001)(76796001)(36756003)(4396001)(77156001)(76786001)(49866001)(77096001)(47976001)(79102001)(69226001)(74662001)(63696002)(62966002)(80022001)(92566001)(77982001)(66066001)(47446002)(50226001)(83072002)(2656002)(92726001)(89996001)(87936001)(56816005)(56776001)(85852003)(31966008)(93916002)(88136002)(83322001)(19580405001)(94946001)(93516002)(57306001)(94316002)(86362001)(19580395003)(81816001)(81686001)(80976001)(87266001)(87286001)(85306002)(51856001)(90146001)(15975445006)(83716003)(93136001)(74366001)(46102001)(76482001)(53806001)(54316002)(82746002)(33656001)(95666003)(15202345003)(74706001)(95416001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB455; H:BN1PR05MB424.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:E6EAF105.AF1607E1.7DE03365.2E3ECC3.2019D; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail39-ch1 (localhost.localdomain [127.0.0.1]) by mail39-ch1 (MessageSwitch) id 139387139060956_6520; Mon, 3 Mar 2014 18:29:50 +0000 (UTC) Received: from CH1EHSMHS023.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.239]) by mail39-ch1.bigfish.com (Postfix) with ESMTP id F37321401BE; Mon, 3 Mar 2014 18:29:49 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS023.bigfish.com (10.43.70.23) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 3 Mar 2014 18:29:47 +0000 Received: from BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 3 Mar 2014 18:29:46 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB455.namprd05.prod.outlook.com (10.141.59.24) with Microsoft SMTP Server (TLS) id 15.0.888.9; Mon, 3 Mar 2014 18:29:45 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) with mapi id 15.00.0888.003; Mon, 3 Mar 2014 18:29:45 +0000 From: Dean Bogdanovic To: Martin Bjorklund Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0t1SbKw4IGxUS3TOG4H5JDBpq7vdcAgABxewCACHOGgIAKl1MAgACM7AA= Date: Mon, 3 Mar 2014 18:29:44 +0000 Message-ID: References: <20140219.081730.397755032.mbj@tail-f.com> <9285BE1A-181A-43CB-8E1A-DB1F564FA42A@juniper.net> <20140303.100516.142214666.mbj@tail-f.com> In-Reply-To: <20140303.100516.142214666.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 0139052FDB Content-Type: text/plain; charset="us-ascii" Content-ID: <0F14260BA2B06D44AB5EEDA3C9476234@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Whqp0LJcf-EXC1h2ofWpqKRDmPo Cc: "" Subject: Re: [Netconf] comments on draft-kwatsen-netconf-server-00 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:29:58 -0000 Martin, Check out http://www.ietf.org/rfc/rfc4254.txt, section 4 can be used for SS= H keep alive mechanism, so for SSH this RFC can be referenced. Dean On Mar 3, 2014, at 5:05 AM, Martin Bjorklund wrote: > Dean Bogdanovic wrote: >>=20 >> On Feb 19, 2014, at 2:17 AM, Martin Bjorklund >> > wrote: >>=20 >>=20 >>> Well, I still don't know if you are talking about TCP keep alives, TLS >>> heartbeats / SSH keep alives or NETCONF-layer keep alive (whatever >>> that is). I think you mean TLS/SSH but it needs to be spelled out. >>> And as for SSH, is there even a standard for keep alives? >>=20 >> You can configure SSH server and client to keep the sessions >> open. There are two config options >> ServerAliveInterval >> and >> ClientAliveInterval >=20 > These are config parameters for one SSH implementation. This document > needs to specify which SSH _mechanism_ is supposed to be used, so that > any SSH implementation can be utilized. >=20 >=20 > /martin >=20 >=20 From nobody Mon Mar 3 10:54:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E43971A035F for ; Mon, 3 Mar 2014 10:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmNt-1c-M-fd for ; Mon, 3 Mar 2014 10:54:36 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) by ietfa.amsl.com (Postfix) with ESMTP id AEDE11A0367 for ; Mon, 3 Mar 2014 10:54:35 -0800 (PST) Received: from [192.168.1.11] ([84.92.149.4]) by avasout04 with smtp id Z6uW1n00505w0Nk016uXdQ; Mon, 03 Mar 2014 18:54:32 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=eZmzft0H c=1 sm=1 tr=0 a=ay7+waBXjX2gYBYtdgtTjg==:117 a=ay7+waBXjX2gYBYtdgtTjg==:17 a=0Bzu9jTXAAAA:8 a=M-J7nEkbgdMA:10 a=sTTtFSd7HycA:10 a=0B8HqoTn75oA:10 a=6bkCdLdQAAAA:8 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=AUd_NHdVAAAA:8 a=48vgC7mUAAAA:8 a=kC2mcprPF5oG1NN2qwwA:9 a=wPNLvfGTeEIA:10 a=JfD0Fch1gWkA:10 a=lZB815dzVvQA:10 a=pGLkceISAAAA:8 a=36xkNHmIxyeuHbi46YwA:9 a=XNPcOwHdNTwVmfyL:21 a=_W_S_7VecoQA:10 a=tXsnliwV7b4A:10 Message-ID: <5314CFE3.3030107@hansfords.net> Date: Mon, 03 Mar 2014 18:54:27 +0000 From: Jonathan Hansford User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: ian duncan , Joe Marcus Clarke References: <5314B906.6090107@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090504020600080708080106" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/gw7191NYH3tpZVZjjw6LiQkk83U Cc: "netconf@ietf.org" Subject: Re: [Netconf] Upgrade vs. downgrade X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 18:54:39 -0000 This is a multi-part message in MIME format. --------------090504020600080708080106 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit There may also be occasions where a few devices are moved from a system running version n+1 to another running version n and it would be easier or even necessary to downgrade the few than upgrade the many. Jonathan On 03/03/2014 17:39, ian duncan wrote: > Hello -- > > Having taken to the mike to challenge Wes I offer the following. > > Believe I understand a desire to confirm one is NOT regressing to a > more broken code image. What I'd wanted to question is whether the > mechanism suggested was suitable to achieve this goal, and in > particular in a case where little to no correlation exists between the > code running the initial ZTP firmware and the ultimate desired > functional code image. Phrased as a question, how can one > presumptively infer from arbitrary version numbering embedded that > some code image has fewer issues--security related or otherwise? > > Thanks .. Ian > > > > > > > > > > On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke > wrote: > > A point was raised during the meeting that the ZeroTouch draft > should allow for an image _upgrade_ only (where new image has a > version > old image). There were counter points raised that as > long as the image is signed, it shouldn't matter the direction (up > or down[grade]). > > I agree with the counter points. We have seen cases where a newer > rev of code (sometimes with newer features) includes new security > bugs that can be exploited when the older version of code is safe. > To say we can only go up doesn't protect the operator from a > security vulnerability. > > Additionally, as was raised as a counter-point, operators may have > a standard image that they need for their environment (sometimes > to have the device work at all). This may be a down-revved image > from what is shipped on the device. > > I think we should allow for image moves in any direction as long > as they can be verified and validated as is pointed out in the > draft currently. > > Joe > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------090504020600080708080106 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit There may also be occasions where a few devices are moved from a system running version n+1 to another running version n and it would be easier or even necessary to downgrade the few than upgrade the many.

Jonathan

On 03/03/2014 17:39, ian duncan wrote:
Hello --

Having taken to the mike to challenge Wes I offer the following.

Believe I understand a desire to confirm one is NOT regressing to a more broken code image. What I'd wanted to question is whether the mechanism suggested was suitable to achieve this goal, and in particular in a case where little to no correlation exists between the code running the initial ZTP firmware and the ultimate desired functional code image. Phrased as a question, how can one presumptively infer from arbitrary version numbering embedded that some code image has fewer issues--security related or otherwise?

Thanks .. Ian









On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke <jclarke@cisco.com> wrote:
A point was raised during the meeting that the ZeroTouch draft should allow for an image _upgrade_ only (where new image has a version > old image).  There were counter points raised that as long as the image is signed, it shouldn't matter the direction (up or down[grade]).

I agree with the counter points.  We have seen cases where a newer rev of code (sometimes with newer features) includes new security bugs that can be exploited when the older version of code is safe.  To say we can only go up doesn't protect the operator from a security vulnerability.

Additionally, as was raised as a counter-point, operators may have a standard image that they need for their environment (sometimes to have the device work at all).  This may be a down-revved image from what is shipped on the device.

I think we should allow for image moves in any direction as long as they can be verified and validated as is pointed out in the draft currently.

Joe

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf



_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--------------090504020600080708080106-- From nobody Mon Mar 3 11:03:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8B41A03AB for ; Mon, 3 Mar 2014 11:03:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i2hEbRe7hbT2 for ; Mon, 3 Mar 2014 11:03:33 -0800 (PST) Received: from elasmtp-dupuy.atl.sa.earthlink.net (elasmtp-dupuy.atl.sa.earthlink.net [209.86.89.62]) by ietfa.amsl.com (Postfix) with ESMTP id 4676B1A03A6 for ; Mon, 3 Mar 2014 11:03:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=Z7d1G2AQ9m+xB3ePvP3xk6JL6UD/2d4eA18dJwUJxKdPIu71DbDl6rYS3mShX/hn; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-dupuy.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WKY9C-0005PI-8i for netconf@ietf.org; Mon, 03 Mar 2014 14:03:30 -0500 Received: from 99.187.237.93 by webmail.earthlink.net with HTTP; Mon, 3 Mar 2014 14:03:30 -0500 Message-ID: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Mon, 3 Mar 2014 11:03:30 -0800 (GMT-08:00) From: Randy Presuhn To: "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbceda842c959f4d5c662b5a6178d87bd0e350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qLI3Q3QQ5EkGovqQNui6xl0RrEY Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 19:03:35 -0000 Hi - >From: Joe Marcus Clarke >Sent: Mar 3, 2014 9:06 AM >To: "netconf@ietf.org" >Subject: [Netconf] Unsigned configlets and physical security ... >Instead, they just need to get a hold of my USB key and insert a >malicious configlet. Then I need to insert it into my otherwise >physically secure device, and it will load the [unsigned] malicious >bootstrap config. > >Kent's argument was that one should check the contents of the configlet >before loading (it is clear text after all). So this may be a >non-issue. However, I wanted to raise it with the WG to see what others >think. If detecting malicious misconfiguration were straightforward, we'd be able to prevent the inadvertent misconfigurations that are at the root of so many outages. Consequently, the "check the contents" line of reasoning doesn't convince me. Randy From nobody Mon Mar 3 15:57:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD27F1A0147 for ; Mon, 3 Mar 2014 15:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jCv802RaN6l6 for ; Mon, 3 Mar 2014 15:56:59 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC391A009E for ; Mon, 3 Mar 2014 15:56:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28255; q=dns/txt; s=iport; t=1393891016; x=1395100616; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=cZqF0EK3/41zVdtzD22zMw52rWds683XXcLAWzXnpeI=; b=C/RO1PF5i+UQnTmL3ecDD4uN0UKtOL4l2z7fyuPt1iJOupnAAsKnkWnV wGzx/OJDrUOqJcYA3WwchUQ4yEuaasWfzCLzguXlSAbpmVT1snuVOEOxx QAw3cEK2qXiTZcUe6nENaOu4n5lnnOom0YvOIrryOPNp0qb1qf8z22eVx U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAGAFAWFVOtJV2b/2dsb2JhbABagkJEO1EGuAaIXYEfFnSCJQEBAQQBAQFrCxIBCBEDAQIhBy4LFAkIAgQOBQmHcAgFzFcXjW1bDQQGAQYDhC8ElFGDa4EyizSFRYMtgXE5 X-IronPort-AV: E=Sophos; i="4.97,581,1389744000"; d="scan'208,217"; a="24628332" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-1.cisco.com with ESMTP; 03 Mar 2014 23:56:54 +0000 Received: from xhc-aln-x07.cisco.com (xhc-aln-x07.cisco.com [173.36.12.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s23NusAS018364 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 3 Mar 2014 23:56:54 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-aln-x07.cisco.com ([173.36.12.81]) with mapi id 14.03.0123.003; Mon, 3 Mar 2014 17:56:54 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt Thread-Index: AQHPKQi55ZiVQzOCGEa56F+k4ZHu9JrG1Z4AgAANDgCAAAIogIAABE8A//+EZoCAAIl6AP//kDcAgACKOYD//3zsAAAR22gAARz1OwA= Date: Mon, 3 Mar 2014 23:56:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.154.204.84] Content-Type: multipart/alternative; boundary="_000_CF3A55804E656albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WfDD7VtwmV95G7zd02G7pPqUNOM Cc: Netconf Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 23:57:03 -0000 --_000_CF3A55804E656albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, A generic parser can do that as long as the parser is aware of the contents= of the data models If the key names are included, a generic parser can create, say, a json tre= e without knowing anything about the data model. The creation of json tree is something a Netconf parser can do without know= ing about the model. Thanks, Alberto From: Andy Bierman > Date: Tuesday, February 25, 2014 3:57 PM To: Alberto Gonzalez Prieto > Cc: "Yi Yang (yiya)" >, Netconf > Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.t= xt Hi, What I proposed can be generically mapped to JSON arrays or generic YANG. The keys have to be in order and the mapping to key names is not really needed for a generic parser. Andy On Tue, Feb 25, 2014 at 3:26 PM, Alberto Gonzalez Prieto (albertgo) > wrote: Thanks Andy, I was proposing a way to provide more flexibility to agent designs, allowin= g the parsing of the URI + body to be semantic free wrt the yang modules Excluding the names of key leaves in the URI prevents that flexibility. Thanks, Alberto From: Andy Bierman > Date: Tuesday, February 25, 2014 3:15 PM To: Alberto Gonzalez Prieto > Cc: "Yi Yang (yiya)" >, Netconf > Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.t= xt On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzalez Prieto (albertgo) > wrote: Thanks Andy, That sounds good to me. Taking the example below, the URI would look something like this, I guess: /top/list;key1=3Dvalue1,key2=3Dvalue2,key3=3Dvalue3/=85 Actually I meant: container top { list list1 { key "key1 key2 key3"; ... list list2 { key "key4 key5"; ... leaf X { type string; } } } } /top/list1=3Dkey1val,key2val,key3val3/list2=3Dkey4val,key5val/X The key names are redundant because they are in the YANG module. This syntax has 1 conceptual YANG level per segment. Andy Thanks, Alberto From: Andy Bierman > Date: Tuesday, February 25, 2014 1:40 PM To: Alberto Gonzalez Prieto > Cc: "Yi Yang (yiya)" >, Netconf > Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.t= xt Hi, This URI syntax maps to the path component, defined in RFC 3986, sec. 3.3. Paragraph 5 suggest the semi-colon or comma reserved characters to delimit parameters. Either of those would be OK, if the WG wants to create a speci= al syntax for list keys. Andy On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzalez Prieto (albertgo) > wrote: Hi, An advantage of having keys encoded using a different character is that a m= odule parsing the URI + body could be semantic free wrt the yang modules. This would add flexibility in the agent design. Another consideration is that using [] for enclosing keys, would also make= URIs more similar to xpaths, which may make them more intuitive to some co= mmunities. Andy, can you comment on the cons of encoding keys using another character? Thanks, Alberto From: Andy Bierman > Date: Tuesday, February 25, 2014 12:51 PM To: "Yi Yang (yiya)" > Cc: Netconf > Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.t= xt On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya) > wrote: Hi Andy, I support to pass parameters in URL =97 what I meant is, using a sub-delim= , instead of slash ("/"), to separate key values in the URL. I understand what you mean. I just don't agree that using another characte= r to separate key values would be better. Yi Andy From: Andy Bierman > Date: Tuesday, February 25, 2014 3:28 PM To: Yi Yang > Cc: Netconf > Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.t= xt On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya) > wrote: Per RFC3986, slash ("/") is used to separate path segment. In other words, = it indicates a hierarchy. In current draft, if there are multiple keys for a list, the key values are= separated by slash ("/"), for example, /top/list/key1/key2/key3.. . Even t= hough these keys are on the same level. I understand that we need to separa= te these keys, but it doesn't have to be "/", as there are plenty of sub-de= lims available. For example, something like /top/list/key1&key2&key3 or /to= p/list/key1+key2+key3? I have seen REST-like APIs that pass parameters in the URL, which is what w= e are doing by putting the key values in the URL. IMO '/' is more generally accepted. Not sure this would be legal URI synta= x if nested lists were specified. The query string parameters are after the = path-expr. Yi Andy From: Andy Bierman > Date: Thursday, February 13, 2014 5:12 PM To: Netconf > Subject: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt FYI, A new version of the RESTCONF draft has been posted. There were only minor clarifications and bug-fixes done. See Appendix A.1 for details on the changes. Andy ---------- Forwarded message ---------- From: > Date: Thu, Feb 13, 2014 at 2:10 PM Subject: I-D Action: draft-bierman-netconf-restconf-04.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-bierman-netconf-restconf-04.txt Pages : 96 Date : 2014-02-13 Abstract: This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netconf-restconf-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-netconf-restconf-04 Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --_000_CF3A55804E656albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
Hi,

A generic parser can do that as long as the parser is aware of the con= tents of the data models
If the key names are included, a generic parser can create, say, a jso= n tree without knowing anything about the data model.
The creation of json tree is something a Netconf parser can do without= knowing about the model.

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 57 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com>
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>, Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt

Hi, 

What I proposed can be generically mapped to JSON arrays
or generic YANG.  The keys have to be in order and the mapping
to key names is not really needed for a generic parser.


Andy



On Tue, Feb 25, 2014 at 3:26 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

I was proposing a way to provide more flexibility to agent designs, al= lowing the parsing of the URI + body to be semantic free wrt the yang m= odules
Excluding the names of key leaves in the URI prevents that flexibility= .

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 15 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>,= Netconf <netconf@= ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

That sounds good to me.
Taking the example below, the URI would look something like this, I gu= ess:

/top/list;key1=3Dvalue1,key2=3Dvalue2,key3=3Dvalue3/=85


Actually I meant:

  container top {
     list list1 {
       key "key1 key2 key3";
       ...
       list list2 {
          key "key4 key5";
          ...
          leaf X { type string; }
       }
     }
  }

 /top/list1=3Dkey1val,key2val,key3val3/list2=3Dkey4val,key5val/X<= /div>

The key names are redundant because they are in the YANG module.
This syntax has 1 conceptual YANG level per segment.

Andy



 

 
Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 1:= 40 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>,= Netconf <netconf@= ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt

Hi,

This URI syntax maps to the path component, defined in RFC 3986, sec. = 3.3.
Paragraph 5 suggest the semi-colon or comma reserved characters to del= imit
parameters.  Either of those would be OK, if the WG wants to crea= te a special
syntax for list keys.


Andy



On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Hi,

An advantage of having keys encoded using a different character is tha= t a module parsing the URI + body could be semantic free wrt the yang m= odules.
This would add flexibility in the agent design.

Another consideration is that using [] for enclosing keys,  would= also make URIs more similar to xpaths, which may make them more intuitive = to some communities.

Andy, can you comment on the cons of encoding keys using another chara= cter?

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 12= :51 PM
To: "Yi Yang (yiya)" <= yiya@cisco.com><= br> Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya)= <yiya@cisco.com&= gt; wrote:
Hi Andy,

I support to pass parameters in URL =97 what I meant is,  using a= sub-delim, instead of slash ("/"), to separate key values in the= URL.


I understand what you mean.  I just don't agree that using anothe= r character
to separate key values would be better.

 
Yi

Andy
 

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 28 PM
To: Yi Yang <yiya@cisco.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya)= <yiya@cisco.com&= gt; wrote:
Per RFC3986, slash ("/") is used to separate path segment.&n= bsp;In other words, it indicates a hierarchy. 

In current draft, if there are multiple keys for a list, the key value= s are separated by slash ("/"), for example, /top/list/key1/key2/= key3.. . Even though these keys are on the same level. I understand that we= need to separate these keys, but it doesn't have to be "/", as there are plenty of sub-delims available. For= example, something like /top/list/key1&key2&key3 or /top/list/key1= +key2+key3?



I have seen REST-like APIs that pass parameters in the URL, which is w= hat we are doing
by putting the key values in the URL.

IMO '/' is more generally accepted.  Not sure this would be legal= URI syntax
if nested lists were specified.  The query string parameters are = after the path-expr.


Yi

Andy
 



From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, February 13, 2014 5= :12 PM
To: Netconf <netconf@ietf.org>
Subject: [Netconf] Fwd: I-D Action:= draft-bierman-netconf-restconf-04.txt

FYI,

A new version of the RESTCONF draft has been posted.
There were only minor clarifications and bug-fixes done.
See Appendix A.1 for details on the changes.


Andy


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


        Title           : REST= CONF Protocol
        Authors         : Andy Bier= man
                     = ;     Martin Bjorklund
                     = ;     Kent Watsen
                     = ;     Rex Fernando
        Filename        : draft-bie= rman-netconf-restconf-04.txt
        Pages           : 96         Date            := 2014-02-13

Abstract:
   This document describes a REST-like protocol that provides a    programmatic interface over HTTP for accessing data defined in= YANG,
   using the datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-= restconf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 4

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-ne= tconf-restconf-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt






 --_000_CF3A55804E656albertgociscocom_-- From nobody Mon Mar 3 16:17:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C729A1A0192 for ; Mon, 3 Mar 2014 16:17:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JCF4npH43zly for ; Mon, 3 Mar 2014 16:17:15 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 2C3CA1A00C9 for ; Mon, 3 Mar 2014 16:17:15 -0800 (PST) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WKd2k-0007vv-QP for netconf@ietf.org; Tue, 04 Mar 2014 01:17:11 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-2.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WKd2k-0003Rw-NE for netconf@ietf.org; Tue, 04 Mar 2014 01:17:10 +0100 Message-ID: <53151B85.2050204@bwijnen.net> Date: Tue, 04 Mar 2014 00:17:09 +0000 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: netconf@ietf.org References: <20140303131645.GA22071@elstar.local> In-Reply-To: <20140303131645.GA22071@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4f13d35c3c458df9d2cfe601434e8598c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WMu7pY_WbyMCKDa7PifjN9hrepY Subject: Re: [Netconf] reverse ssh document title X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 00:17:18 -0000 good idea Bert On 03/03/14 13:16, Juergen Schoenwaelder wrote: > Hi, > > the title currently is 'Reverse Secure Shell (Reverse SSH)' but since > this is only applicable to NETCONF, we may want to pick a more > descriptive title. > > /js > From nobody Mon Mar 3 16:36:14 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE281A01B6 for ; Mon, 3 Mar 2014 16:36:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fsWh4cJADi2h for ; Mon, 3 Mar 2014 16:36:08 -0800 (PST) Received: from mail-qa0-f48.google.com (mail-qa0-f48.google.com [209.85.216.48]) by ietfa.amsl.com (Postfix) with ESMTP id 571CE1A0192 for ; Mon, 3 Mar 2014 16:36:08 -0800 (PST) Received: by mail-qa0-f48.google.com with SMTP id m5so3607612qaj.7 for ; Mon, 03 Mar 2014 16:36:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=G1EjlTX6NGIinRGJRfy6rhqg2GFZlIBu+uzKJRywyU0=; b=Bj8soK4wfd2KGXQ5poCYRDbKyZGmoWLB8b2odSe7sSE34lzCQh1T6jJ4sy8SMTNrA/ Jfkxi/odKQn8n2GNS55+ipPcNo0NXWh+pd/fpJaI3E/+h2tyYsAqj8IMt3XSSf0/rmCl MoIQt82RDY1Da5sUK8oSZWIgpVRklXrEHOGXaQbuV/M8V6mpCac1t/OLM/pMY7n0YtK/ HaPfhSg0rgCq6gXh/bKWRbCA7RcCgPkA6SJe2Vk4VN93Nn1JW/T5IOmtt78MrG4zyW/j oLVNd/KOEkklKtZsL8D4HHtLfRl8ifQMW52HIJ0dmm3kA6yZOt14ELV+VSxbLsB3FJIf iAIg== X-Gm-Message-State: ALoCoQnwteu3sqYUQPbz2N3yS/Q4/XtmXj4IngpMhQoR0QVFWlIxxDM8nBMg1s0vGrEMG9nY6Ndq MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr25961807qgx.18.1393893365036; Mon, 03 Mar 2014 16:36:05 -0800 (PST) Received: by 10.140.104.194 with HTTP; Mon, 3 Mar 2014 16:36:04 -0800 (PST) In-Reply-To: References: Date: Mon, 3 Mar 2014 16:36:04 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c00434e0e60c04f3bd165f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/0lAhYkyRZdP7KUTATpqPMV4K88U Cc: Netconf Subject: Re: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 00:36:13 -0000 --001a11c00434e0e60c04f3bd165f Content-Type: text/plain; charset=ISO-8859-1 Hi, I do not agree that schema data needs to be included. Knowing the names of the keys but nothing else about them is not useful to a real application. A generic tool can make up names for the keys (like key1, key2, etc.) Including schema info wastes bandwidth. I don't see why the URI would be converted to a JSON array. The message body is already encoded in JSON or XML. Please explain why the target resource URI needs to be converted to JSON. Andy On Mon, Mar 3, 2014 at 3:56 PM, Alberto Gonzalez Prieto (albertgo) < albertgo@cisco.com> wrote: > Hi, > > A generic parser can do that as long as the parser is aware of the > contents of the data models > If the key names are included, a generic parser can create, say, a json > tree without knowing anything about the data model. > The creation of json tree is something a Netconf parser can do without > knowing about the model. > > Thanks, > > Alberto > > From: Andy Bierman > Date: Tuesday, February 25, 2014 3:57 PM > To: Alberto Gonzalez Prieto > Cc: "Yi Yang (yiya)" , Netconf > Subject: Re: [Netconf] Fwd: I-D Action: > draft-bierman-netconf-restconf-04.txt > > Hi, > > What I proposed can be generically mapped to JSON arrays > or generic YANG. The keys have to be in order and the mapping > to key names is not really needed for a generic parser. > > > Andy > > > > On Tue, Feb 25, 2014 at 3:26 PM, Alberto Gonzalez Prieto (albertgo) < > albertgo@cisco.com> wrote: > >> Thanks Andy, >> >> I was proposing a way to provide more flexibility to agent designs, >> allowing the parsing of the URI + body to be semantic free wrt the yang >> modules >> Excluding the names of key leaves in the URI prevents that flexibility. >> >> Thanks, >> >> Alberto >> >> From: Andy Bierman >> Date: Tuesday, February 25, 2014 3:15 PM >> To: Alberto Gonzalez Prieto >> Cc: "Yi Yang (yiya)" , Netconf >> Subject: Re: [Netconf] Fwd: I-D Action: >> draft-bierman-netconf-restconf-04.txt >> >> >> >> >> On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzalez Prieto (albertgo) < >> albertgo@cisco.com> wrote: >> >>> Thanks Andy, >>> >>> That sounds good to me. >>> Taking the example below, the URI would look something like this, I >>> guess: >>> >>> /top/list;key1=value1,key2=value2,key3=value3/... >>> >>> >> Actually I meant: >> >> container top { >> list list1 { >> key "key1 key2 key3"; >> ... >> list list2 { >> key "key4 key5"; >> ... >> leaf X { type string; } >> } >> } >> } >> >> /top/list1=key1val,key2val,key3val3/list2=key4val,key5val/X >> >> The key names are redundant because they are in the YANG module. >> This syntax has 1 conceptual YANG level per segment. >> >> Andy >> >> >> >> >> >> >> >>> Thanks, >>> >>> Alberto >>> >>> From: Andy Bierman >>> Date: Tuesday, February 25, 2014 1:40 PM >>> To: Alberto Gonzalez Prieto >>> Cc: "Yi Yang (yiya)" , Netconf >>> Subject: Re: [Netconf] Fwd: I-D Action: >>> draft-bierman-netconf-restconf-04.txt >>> >>> Hi, >>> >>> This URI syntax maps to the path component, defined in RFC 3986, sec. >>> 3.3. >>> Paragraph 5 suggest the semi-colon or comma reserved characters to >>> delimit >>> parameters. Either of those would be OK, if the WG wants to create a >>> special >>> syntax for list keys. >>> >>> >>> Andy >>> >>> >>> >>> On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzalez Prieto (albertgo) < >>> albertgo@cisco.com> wrote: >>> >>>> Hi, >>>> >>>> An advantage of having keys encoded using a different character is >>>> that a module parsing the URI + body could be semantic free wrt the yang >>>> modules. >>>> This would add flexibility in the agent design. >>>> >>>> Another consideration is that using [] for enclosing keys, would >>>> also make URIs more similar to xpaths, which may make them more intuitive >>>> to some communities. >>>> >>>> Andy, can you comment on the cons of encoding keys using another >>>> character? >>>> >>>> Thanks, >>>> >>>> Alberto >>>> >>>> From: Andy Bierman >>>> Date: Tuesday, February 25, 2014 12:51 PM >>>> To: "Yi Yang (yiya)" >>>> Cc: Netconf >>>> Subject: Re: [Netconf] Fwd: I-D Action: >>>> draft-bierman-netconf-restconf-04.txt >>>> >>>> >>>> >>>> >>>> On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya) wrote: >>>> >>>>> Hi Andy, >>>>> >>>>> I support to pass parameters in URL -- what I meant is, using a >>>>> sub-delim, instead of slash ("/"), to separate key values in the URL. >>>>> >>>>> >>>> I understand what you mean. I just don't agree that using another >>>> character >>>> to separate key values would be better. >>>> >>>> >>>> >>>>> Yi >>>>> >>>> >>>> Andy >>>> >>>> >>>>> >>>>> From: Andy Bierman >>>>> Date: Tuesday, February 25, 2014 3:28 PM >>>>> To: Yi Yang >>>>> Cc: Netconf >>>>> Subject: Re: [Netconf] Fwd: I-D Action: >>>>> draft-bierman-netconf-restconf-04.txt >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya) wrote: >>>>> >>>>>> Per RFC3986, slash ("/") is used to separate path segment. In other >>>>>> words, it indicates a hierarchy. >>>>>> >>>>>> In current draft, if there are multiple keys for a list, the key >>>>>> values are separated by slash ("/"), for example, >>>>>> /top/list/key1/key2/key3.. . Even though these keys are on the same level. >>>>>> I understand that we need to separate these keys, but it doesn't have to be >>>>>> "/", as there are plenty of sub-delims available. For example, something >>>>>> like /top/list/key1&key2&key3 or /top/list/key1+key2+key3? >>>>>> >>>>>> >>>>> >>>>> I have seen REST-like APIs that pass parameters in the URL, which is >>>>> what we are doing >>>>> by putting the key values in the URL. >>>>> >>>>> IMO '/' is more generally accepted. Not sure this would be legal >>>>> URI syntax >>>>> if nested lists were specified. The query string parameters are after >>>>> the path-expr. >>>>> >>>>> >>>>> Yi >>>>>> >>>>> >>>>> Andy >>>>> >>>>> >>>>>> >>>>>> >>>>>> >>>>>> From: Andy Bierman >>>>>> Date: Thursday, February 13, 2014 5:12 PM >>>>>> To: Netconf >>>>>> Subject: [Netconf] Fwd: I-D Action: >>>>>> draft-bierman-netconf-restconf-04.txt >>>>>> >>>>>> FYI, >>>>>> >>>>>> A new version of the RESTCONF draft has been posted. >>>>>> There were only minor clarifications and bug-fixes done. >>>>>> See Appendix A.1 for details on the changes. >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>>> ---------- Forwarded message ---------- >>>>>> From: >>>>>> Date: Thu, Feb 13, 2014 at 2:10 PM >>>>>> Subject: I-D Action: draft-bierman-netconf-restconf-04.txt >>>>>> To: i-d-announce@ietf.org >>>>>> >>>>>> >>>>>> >>>>>> A New Internet-Draft is available from the on-line Internet-Drafts >>>>>> directories. >>>>>> >>>>>> >>>>>> Title : RESTCONF Protocol >>>>>> Authors : Andy Bierman >>>>>> Martin Bjorklund >>>>>> Kent Watsen >>>>>> Rex Fernando >>>>>> Filename : draft-bierman-netconf-restconf-04.txt >>>>>> Pages : 96 >>>>>> Date : 2014-02-13 >>>>>> >>>>>> Abstract: >>>>>> This document describes a REST-like protocol that provides a >>>>>> programmatic interface over HTTP for accessing data defined in >>>>>> YANG, >>>>>> using the datastores defined in NETCONF. >>>>>> >>>>>> >>>>>> The IETF datatracker status page for this draft is: >>>>>> https://datatracker.ietf.org/doc/draft-bierman-netconf-restconf/ >>>>>> >>>>>> There's also a htmlized version available at: >>>>>> http://tools.ietf.org/html/draft-bierman-netconf-restconf-04 >>>>>> >>>>>> A diff from the previous version is available at: >>>>>> http://www.ietf.org/rfcdiff?url2=draft-bierman-netconf-restconf-04 >>>>>> >>>>>> >>>>>> Please note that it may take a couple of minutes from the time of >>>>>> submission >>>>>> until the htmlized version and diff are available at tools.ietf.org. >>>>>> >>>>>> Internet-Drafts are also available by anonymous FTP at: >>>>>> ftp://ftp.ietf.org/internet-drafts/ >>>>>> >>>>>> _______________________________________________ >>>>>> I-D-Announce mailing list >>>>>> I-D-Announce@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/i-d-announce >>>>>> Internet-Draftdirectories: >>>>>> http://www.ietf.org/shadow.html >>>>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >>>>>> >>>>>> >>>>> >>>> >>> >> > --001a11c00434e0e60c04f3bd165f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I do not agree that schema data nee= ds to be included.
Knowing the names of the keys but nothing else= about them
is not useful to a real application.  A generic = tool can make
up names for the keys (like key1, key2, etc.)

Including schema info wastes bandwidth. I don't see why the URI
<= div>would be converted to a JSON array.  The message body is already
encoded in JSON or XML.  Please explain why the target resource U= RI
needs to be converted to JSON.

Andy



On Mon, Mar 3, 2014 at 3:56 PM, Alberto Gonzalez Prieto (albertgo) <alber= tgo@cisco.com> wrote:
Hi,

A generic parser can do that as long as the parser is aware of the con= tents of the data models
If the key names are included, a generic parser can create, say, a jso= n tree without knowing anything about the data model.
The creation of json tree is something a Netconf parser can do without= knowing about the model.

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 57 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>,= Netconf <netconf@= ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt

Hi, 

What I proposed can be generically mapped to JSON arrays
or generic YANG.  The keys have to be in order and the mapping
to key names is not really needed for a generic parser.


Andy



On Tue, Feb 25, 2014 at 3:26 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

I was proposing a way to provide more flexibility to agent designs, al= lowing the parsing of the URI + body to be semantic free wrt the yang modul= es
Excluding the names of key leaves in the URI prevents that flexibility= .

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 15 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>,= Netconf <netconf@= ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 3:00 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Thanks Andy,

That sounds good to me.
Taking the example below, the URI would look something like this, I gu= ess:

/top/list;key1=3Dvalue1,key2=3Dvalue2,key3=3Dvalue3/…


Actually I meant:

  container top {
     list list1 {
       key "key1 key2 key3";
       ...
       list list2 {
          key "key4 key5";
          ...
          leaf X { type string; }
       }
     }
  }

 /top/list1=3Dkey1val,key2val,key3val3/list2=3Dkey4val,key5val/X<= /div>

The key names are redundant because they are in the YANG module.
This syntax has 1 conceptual YANG level per segment.

Andy



 

 
Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 1:= 40 PM
To: Alberto Gonzalez Prieto <albertgo@cisco.com= >
Cc: "Yi Yang (yiya)" <= yiya@cisco.com>,= Netconf <netconf@= ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt

Hi,

This URI syntax maps to the path component, defined in RFC 3986, sec. = 3.3.
Paragraph 5 suggest the semi-colon or comma reserved characters to del= imit
parameters.  Either of those would be OK, if the WG wants to crea= te a special
syntax for list keys.


Andy



On Tue, Feb 25, 2014 at 1:28 PM, Alberto Gonzale= z Prieto (albertgo) <albertgo@cisco.com> wrote:
Hi,

An advantage of having keys encoded using a different character is tha= t a module parsing the URI + body could be semantic free wrt the yang modul= es.
This would add flexibility in the agent design.

Another consideration is that using [] for enclosing keys,  would= also make URIs more similar to xpaths, which may make them more intuitive = to some communities.

Andy, can you comment on the cons of encoding keys using another chara= cter?

Thanks,

Alberto

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 12= :51 PM
To: "Yi Yang (yiya)" <= yiya@cisco.com><= br> Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 12:35 PM, Yi Yang (yiya)= <yiya@cisco.com&= gt; wrote:
Hi Andy,

I support to pass parameters in URL — what I meant is,  usi= ng a sub-delim, instead of slash ("/"), to separate key values in= the URL.


I understand what you mean.  I just don't agree that using an= other character
to separate key values would be better.

 
Yi

Andy
 

From: Andy Bierman <andy@yumaworks.com>
Date: Tuesday, February 25, 2014 3:= 28 PM
To: Yi Yang <yiya@cisco.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] Fwd: I-D Act= ion: draft-bierman-netconf-restconf-04.txt




On Tue, Feb 25, 2014 at 11:41 AM, Yi Yang (yiya)= <yiya@cisco.com&= gt; wrote:
Per RFC3986, slash ("/") is used to separate path segment.&n= bsp;In other words, it indicates a hierarchy. 

In current draft, if there are multiple keys for a list, the key value= s are separated by slash ("/"), for example, /top/list/key1/key2/= key3.. . Even though these keys are on the same level. I understand that we= need to separate these keys, but it doesn't have to be "/", as there are plenty of sub-delims available. For= example, something like /top/list/key1&key2&key3 or /top/list/key1= +key2+key3?



I have seen REST-like APIs that pass parameters in the URL, which is w= hat we are doing
by putting the key values in the URL.

IMO '/' is more generally accepted.  Not sure this would = be legal URI syntax
if nested lists were specified.  The query string parameters are = after the path-expr.


Yi

Andy
 



From: Andy Bierman <andy@yumaworks.com>
Date: Thursday, February 13, 2014 5= :12 PM
To: Netconf <netconf@ietf.org>
Subject: [Netconf] Fwd: I-D Action:= draft-bierman-netconf-restconf-04.txt

FYI,

A new version of the RESTCONF draft has been posted.
There were only minor clarifications and bug-fixes done.
See Appendix A.1 for details on the changes.


Andy


---------- Forwarded message ----------
From: <internet-drafts@ietf.org>
Date: Thu, Feb 13, 2014 at 2:10 PM
Subject: I-D Action: draft-bierman-netconf-restconf-04.txt
To: i-d-announce= @ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts director= ies.


        Title           : REST= CONF Protocol
        Authors         : Andy Bier= man
                     = ;     Martin Bjorklund
                     = ;     Kent Watsen
                     = ;     Rex Fernando
        Filename        : draft-bie= rman-netconf-restconf-04.txt
        Pages           : 96         Date            := 2014-02-13

Abstract:
   This document describes a REST-like protocol that provides a    programmatic interface over HTTP for accessing data defined in= YANG,
   using the datastores defined in NETCONF.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-netconf-= restconf/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netconf-restconf-0= 4

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bierman-ne= tconf-restconf-04


Please note that it may take a couple of minutes from the time of submissio= n
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
I-D-Announce@iet= f.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or = ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--001a11c00434e0e60c04f3bd165f-- From nobody Tue Mar 4 02:27:24 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 427031A063E for ; Tue, 4 Mar 2014 02:27:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.047 X-Spam-Level: X-Spam-Status: No, score=-10.047 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWTMaeJ5CpZ1 for ; Tue, 4 Mar 2014 02:27:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 91A661A0644 for ; Tue, 4 Mar 2014 02:27:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1917; q=dns/txt; s=iport; t=1393928833; x=1395138433; h=message-id:date:from:mime-version:to:subject; bh=ucjW95OZZdRTNmxAr6ZsDqssiqZgdgFLd44igRNeaXs=; b=UEML+utQRo4pQIWRROS7GB8f+ROJuWBIclcgQqL7IalK7GTPhG7Fai2r w4gVaFctCxx21ovY7ZEYsXBaW5sB1OfqTxLmmR+d/rrs9VOteBLbs6DLs w1ntpD74yKn5DBOqUN2hYjV5zpeTVwZLg/ZvBUXHkTCIohIslQWJXGgPo Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFAD6pFVOQ/khR/2dsb2JhbABagwaJcrktFnSCHHsNHwEdFhgDAgECAUsNCAEBh3WdA687F5MQBJg8hkqLYYMtPIEuJA X-IronPort-AV: E=Sophos;i="4.97,583,1389744000"; d="scan'208,217";a="7084403" Received: from ams-core-1.cisco.com ([144.254.72.81]) by aer-iport-1.cisco.com with ESMTP; 04 Mar 2014 10:27:11 +0000 Received: from [10.61.221.123] ([10.61.221.123]) by ams-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s24ARB1p017954 for ; Tue, 4 Mar 2014 10:27:11 GMT Message-ID: <5315AA7F.6080006@cisco.com> Date: Tue, 04 Mar 2014 10:27:11 +0000 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: NETCONF Content-Type: multipart/alternative; boundary="------------090400000104020209040006" Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ncwt-8ZqHK4HFHpRaT_7PAu4Tpk Subject: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a NETCONF server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 10:27:18 -0000 This is a multi-part message in MIME format. --------------090400000104020209040006 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf-reverse-ssh However, these techniques MUST only be used for a NETCONF server to initiate a connection to a NETCONF client, as described in this document. The way I understood this statement: the security experts wanted us to restrict the scope to only NETCONF. Fine. However, that "MUST" can't be enforced, at least with RFC 2119 keyword. This should be changed to "must". We should obviously validate this with the security experts. Regards, Benoit --------------090400000104020209040006 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf-reverse-ssh
   However, these techniques MUST only be used for a NETCONF server to
    initiate a connection to a NETCONF client, as described in this
    document.
The way I understood this statement: the security experts wanted us to restrict the scope to only NETCONF. Fine.
However, that "MUST" can't be enforced, at least with RFC 2119 keyword.
This should be changed to "must".

We should obviously validate this with the security experts.

Regards, Benoit


--------------090400000104020209040006-- From nobody Tue Mar 4 07:01:30 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ABD21A01B0 for ; Tue, 4 Mar 2014 07:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U4LDu15tzyT for ; Tue, 4 Mar 2014 07:01:26 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 26B781A0117 for ; Tue, 4 Mar 2014 07:01:25 -0800 (PST) Received: from mail26-tx2-R.bigfish.com (10.9.14.227) by TX2EHSOBE009.bigfish.com (10.9.40.29) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 15:01:22 +0000 Received: from mail26-tx2 (localhost [127.0.0.1]) by mail26-tx2-R.bigfish.com (Postfix) with ESMTP id 96D122601A9; Tue, 4 Mar 2014 15:01:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -21 X-BigFish: VPS-21(z579ehz9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail26-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(377454003)(95416001)(76482001)(51856001)(46102001)(36756003)(81542001)(94946001)(95666003)(74706001)(54316002)(76786001)(76796001)(86362001)(53806001)(81342001)(77982001)(94316002)(74366001)(56776001)(59766001)(54356001)(93516002)(69226001)(92726001)(81816001)(31966008)(63696002)(87266001)(81686001)(83072002)(93136001)(4396001)(47976001)(50986001)(83506001)(85306002)(79102001)(16236675002)(47446002)(74662001)(47736001)(49866001)(74502001)(87936001)(85852003)(80976001)(92566001)(77096001)(74876001)(19580405001)(66066001)(65816001)(83322001)(56816005)(2656002)(19580395003)(90146001)(80022001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB739; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:ADD8F7A6.9AC6A417.6BD19B4B.5E77715B.2018E; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail26-tx2 (localhost.localdomain [127.0.0.1]) by mail26-tx2 (MessageSwitch) id 13939452813475_20962; Tue, 4 Mar 2014 15:01:21 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.230]) by mail26-tx2.bigfish.com (Postfix) with ESMTP id ED92B2A0063; Tue, 4 Mar 2014 15:01:20 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 15:01:18 +0000 Received: from BLUPR05MB739.namprd05.prod.outlook.com (10.141.208.24) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 4 Mar 2014 15:01:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB739.namprd05.prod.outlook.com (10.141.208.24) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 4 Mar 2014 15:01:08 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.229]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) with mapi id 15.00.0883.010; Tue, 4 Mar 2014 15:01:06 +0000 From: Kent Watsen To: Benoit Claise , NETCONF Thread-Topic: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a NETCONF server Thread-Index: AQHPN7qRbEntuwYggEq2TH81C6tQ8g== Date: Tue, 4 Mar 2014 15:01:05 +0000 Message-ID: References: <5315AA7F.6080006@cisco.com> In-Reply-To: <5315AA7F.6080006@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 01401330D1 Content-Type: multipart/alternative; boundary="_000_CF3B991B602BFkwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xxzqXNDkNWFSkYTsghCpQut90ag Cc: Stephen Hanna Subject: Re: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a NETCONF server X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:01:28 -0000 --_000_CF3B991B602BFkwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable CC-ing Steve, who wrote the Applicability Statement. Kent From: Benoit Claise > Date: Tuesday, March 4, 2014 5:27 AM To: NetConf > Subject: [Netconf] draft-ietf-netconf-reverse-ssh: MUST only be used for a = NETCONF server Dear all, Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf= -reverse-ssh However, these techniques MUST only be used for a NETCONF server to initiate a connection to a NETCONF client, as described in this document. The way I understood this statement: the security experts wanted us to rest= rict the scope to only NETCONF. Fine. However, that "MUST" can't be enforced, at least with RFC 2119 keyword. This should be changed to "must". We should obviously validate this with the security experts. Regards, Benoit --_000_CF3B991B602BFkwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable


CC-ing Steve, who wrote the Applicability Statement.

Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Tuesday, March 4, 2014 5:27 A= M
To: NetConf <netconf@ietf.org>
Subject: [Netconf] draft-ietf-netco= nf-reverse-ssh: MUST only be used for a NETCONF server

Dear all,

Yesterday, Andy asked how this MUST could be enforced in draft-ietf-netconf= -reverse-ssh
   However, these techniques MUST only be used for a = NETCONF server to
    initiate a connection to a NETCONF client, as described = in this
    document.
The way I understood this statement: the security experts wanted us to rest= rict the scope to only NETCONF. Fine.
However, that "MUST" can't be enforced, at least with RFC 2119 ke= yword.
This should be changed to "must".

We should obviously validate this with the security experts.

Regards, Benoit


 --_000_CF3B991B602BFkwatsenjunipernet_-- From nobody Tue Mar 4 07:21:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FC511A007C for ; Tue, 4 Mar 2014 07:21:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id chuIWtCbOQy7 for ; Tue, 4 Mar 2014 07:21:54 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 5F3C41A014D for ; Tue, 4 Mar 2014 07:21:54 -0800 (PST) Received: from mail184-co9-R.bigfish.com (10.236.132.231) by CO9EHSOBE027.bigfish.com (10.236.130.90) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 15:21:51 +0000 Received: from mail184-co9 (localhost [127.0.0.1]) by mail184-co9-R.bigfish.com (Postfix) with ESMTP id 0E5D6B0029F; Tue, 4 Mar 2014 15:21:51 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail184-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(479174003)(377454003)(189002)(199002)(24454002)(46102001)(65816001)(80022001)(74366001)(54316002)(56776001)(87936001)(79102001)(94316002)(47446002)(66066001)(90146001)(85852003)(83072002)(74706001)(69226001)(95416001)(56816005)(74502001)(94946001)(93136001)(95666003)(74662001)(92726001)(31966008)(81342001)(86362001)(4396001)(36756003)(49866001)(47736001)(83506001)(47976001)(77096001)(93516002)(81816001)(74876001)(81686001)(87266001)(77982001)(53806001)(92566001)(80976001)(63696002)(76796001)(50986001)(51856001)(81542001)(85306002)(54356001)(19580395003)(2656002)(83322001)(76786001)(59766001)(19580405001)(76482001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB781; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:2E1141BC.2FF09BC9.CD6C837A.C4E2637E.2018C; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail184-co9 (localhost.localdomain [127.0.0.1]) by mail184-co9 (MessageSwitch) id 1393946509112825_19195; Tue, 4 Mar 2014 15:21:49 +0000 (UTC) Received: from CO9EHSMHS003.bigfish.com (unknown [10.236.132.231]) by mail184-co9.bigfish.com (Postfix) with ESMTP id 0D2A97000B4; Tue, 4 Mar 2014 15:21:49 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS003.bigfish.com (10.236.130.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 15:21:48 +0000 Received: from DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 4 Mar 2014 15:21:39 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 4 Mar 2014 15:21:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.229]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) with mapi id 15.00.0883.010; Tue, 4 Mar 2014 15:21:37 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" , "netconf@ietf.org" Thread-Topic: [Netconf] reverse ssh document title Thread-Index: AQHPNuLlqzu/2a35g0CLa8Uqb80Wl5rQEGOAgAD8s4A= Date: Tue, 4 Mar 2014 15:21:36 +0000 Message-ID: References: <20140303131645.GA22071@elstar.local> <53151B85.2050204@bwijnen.net> In-Reply-To: <53151B85.2050204@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 01401330D1 Content-Type: text/plain; charset="us-ascii" Content-ID: <8F2B98873498124FA4FFD6C5AD9F33C6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/44j2hcCwdLdFvUtSq0tnmCY8Nzg Subject: Re: [Netconf] reverse ssh document title X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 15:21:56 -0000 I agree - "Reverse Secure Shell for NETCONF" ??? While I still feel that this technique will be used for other TCP-based protocols, the YANG module defined in ietf-kwatsen-netconf-server is clearly NETCONF-specific (e.g. the top-level container node called "netconf"), so now there is more than just an Applicability Statement that makes this a NETCONF-specific solution. Thanks, Kent On 3/4/14 12:17 AM, "Bert Wijnen (IETF)" wrote: >good idea > >Bert > >On 03/03/14 13:16, Juergen Schoenwaelder wrote: >> Hi, >> >> the title currently is 'Reverse Secure Shell (Reverse SSH)' but since >> this is only applicable to NETCONF, we may want to pick a more >> descriptive title. >> >> /js >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue Mar 4 08:21:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27E801A01A8 for ; Tue, 4 Mar 2014 08:21:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PO-tEXKYx8z5 for ; Tue, 4 Mar 2014 08:21:34 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4985D1A0191 for ; Tue, 4 Mar 2014 08:21:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8AA5C12BA; Tue, 4 Mar 2014 17:21:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id lTvm6nqPjvgy; Tue, 4 Mar 2014 17:21:29 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 4 Mar 2014 17:21:29 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A9EA20033; Tue, 4 Mar 2014 17:21:29 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id qmY2O82VwWly; Tue, 4 Mar 2014 17:21:28 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAC442002F; Tue, 4 Mar 2014 17:21:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id E647B2B92E34; Tue, 4 Mar 2014 17:21:25 +0100 (CET) Date: Tue, 4 Mar 2014 17:21:25 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140304162125.GA27569@elstar.local> Mail-Followup-To: Kent Watsen , "Bert Wijnen (IETF)" , "netconf@ietf.org" References: <20140303131645.GA22071@elstar.local> <53151B85.2050204@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dl54kgRglHOOxiLAjG3W0Zp57J8 Cc: "netconf@ietf.org" Subject: Re: [Netconf] reverse ssh document title X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 16:21:37 -0000 On Tue, Mar 04, 2014 at 03:21:36PM +0000, Kent Watsen wrote: > > I agree - "Reverse Secure Shell for NETCONF" ??? Works for me. > While I still feel that this technique will be used for other TCP-based > protocols, the YANG module defined in ietf-kwatsen-netconf-server is > clearly NETCONF-specific (e.g. the top-level container node called > "netconf"), so now there is more than just an Applicability Statement that > makes this a NETCONF-specific solution. Here is the current abstract: This memo presents a technique for a NETCONF server to initiate a SSH connection to a NETCONF client. This is accomplished by the NETCONF client listening on IANA-assigned TCP port YYYY and starting the SSH client protocol immediately after accepting a TCP connection on it. This role-reversal is necessary as the NETCONF server must also be the SSH Server, in order for the NETCONF client to open the IANA- assigned SSH subsystem "netconf". This has NETCONF all over the place... /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 4 09:45:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACC6D1A0275 for ; Tue, 4 Mar 2014 09:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhGQC0Ii-Gv3 for ; Tue, 4 Mar 2014 09:45:41 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id E553F1A0232 for ; Tue, 4 Mar 2014 09:45:40 -0800 (PST) Received: from mail77-co9-R.bigfish.com (10.236.132.225) by CO9EHSOBE018.bigfish.com (10.236.130.81) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 17:45:37 +0000 Received: from mail77-co9 (localhost [127.0.0.1]) by mail77-co9-R.bigfish.com (Postfix) with ESMTP id 8D4FF3C050F; Tue, 4 Mar 2014 17:45:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -26 X-BigFish: VPS-26(zz98dI9371I1432I18a8Kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail77-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: =?us-ascii?Q?SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(51704005)(6?= =?us-ascii?Q?3124002)(199002)(189002)(377454003)(24454002)(86362001)(9541?= =?us-ascii?Q?6001)(74502001)(87266001)(74662001)(65816001)(93916002)(7910?= =?us-ascii?Q?2001)(87286001)(59766001)(77982001)(31966008)(94316002)(4744?= =?us-ascii?Q?6002)(63696002)(92726001)(85306002)(80022001)(93516002)(7487?= =?us-ascii?Q?6001)(83716003)(92566001)(94946001)(62966002)(76796001)(3365?= =?us-ascii?Q?6001)(93136001)(66066001)(74366001)(76786001)(81816001)(8134?= =?us-ascii?Q?2001)(47976001)(50986001)(77096001)(46102001)(36756003)(1958?= =?us-ascii?Q?0395003)(69226001)(77156001)(80976001)(47736001)(50226001)(4?= =?us-ascii?Q?9866001)(81686001)(74706001)(95666003)(83322001)(90146001)(4?= =?us-ascii?Q?396001)(19580405001)(89996001)(56816005)(76482001)(88136002)?= =?us-ascii?Q?(57306001)(85852003)(15975445006)(56776001)(81542001)(543160?= =?us-ascii?Q?02)(83072002)(87936001)(51856001)(2656002)(53806001)(8274600?= =?us-ascii?Q?2)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:110?= =?us-ascii?Q?1;SCL:1;SRVR:BLUPR05MB772;H:BN1PR05MB424.namprd05.prod.outlo?= =?us-ascii?Q?ok.com;CLIP:66.129.241.13;FPR:349CF9B6.A61687C9.F3EBB36B.82E?= =?us-ascii?Q?3DB41.2026B;PTR:InfoNoRecords;A:1;MX:1;LANG:en;?= Received: from mail77-co9 (localhost.localdomain [127.0.0.1]) by mail77-co9 (MessageSwitch) id 1393955135234047_32607; Tue, 4 Mar 2014 17:45:35 +0000 (UTC) Received: from CO9EHSMHS016.bigfish.com (unknown [10.236.132.227]) by mail77-co9.bigfish.com (Postfix) with ESMTP id 34AF3C00BD; Tue, 4 Mar 2014 17:45:35 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS016.bigfish.com (10.236.130.26) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 17:45:35 +0000 Received: from BLUPR05MB772.namprd05.prod.outlook.com (10.141.209.27) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 4 Mar 2014 17:45:33 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BLUPR05MB772.namprd05.prod.outlook.com (10.141.209.27) with Microsoft SMTP Server (TLS) id 15.0.893.10; Tue, 4 Mar 2014 17:45:32 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) with mapi id 15.00.0888.003; Tue, 4 Mar 2014 17:45:31 +0000 From: Dean Bogdanovic To: Randy Presuhn Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPNxNDvD7LZsKAt0y8O27fc1V2vprRNOgA Date: Tue, 4 Mar 2014 17:45:31 +0000 Message-ID: References: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> In-Reply-To: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.13] x-forefront-prvs: 01401330D1 Content-Type: text/plain; charset="us-ascii" Content-ID: <7E3C2109EF99D74CB3816D51C8BDE3FD@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/JRAtcrlYgPCz3pA-tK1rWdoGgCs Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 17:45:47 -0000 Security comes to policies. Using signed configlets could be left as option= al, as some DC operators will be happy to use unsigned configlets, but coul= d also mandate that only pre approved usb keys are used, or any USB key can= be used. Some other operators will state, only signed configlets can be used and the= y will go through the mapping of USB keys to the devices. So, voting to make it optional. Dean On Mar 3, 2014, at 2:03 PM, Randy Presuhn wr= ote: > Hi - >=20 >> From: Joe Marcus Clarke >> Sent: Mar 3, 2014 9:06 AM >> To: "netconf@ietf.org" >> Subject: [Netconf] Unsigned configlets and physical security > ... >> Instead, they just need to get a hold of my USB key and insert a=20 >> malicious configlet. Then I need to insert it into my otherwise=20 >> physically secure device, and it will load the [unsigned] malicious=20 >> bootstrap config. >>=20 >> Kent's argument was that one should check the contents of the configlet= =20 >> before loading (it is clear text after all). So this may be a=20 >> non-issue. However, I wanted to raise it with the WG to see what others= =20 >> think. >=20 > If detecting malicious misconfiguration were straightforward, > we'd be able to prevent the inadvertent misconfigurations that > are at the root of so many outages. Consequently, the "check > the contents" line of reasoning doesn't convince me. >=20 > Randy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 From nobody Tue Mar 4 10:35:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A1391A02C4 for ; Tue, 4 Mar 2014 10:35:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RsECH1d5-814 for ; Tue, 4 Mar 2014 10:35:28 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id A4FF41A02B5 for ; Tue, 4 Mar 2014 10:35:28 -0800 (PST) Received: from mail10-co9-R.bigfish.com (10.236.132.254) by CO9EHSOBE040.bigfish.com (10.236.130.103) with Microsoft SMTP Server id 14.1.225.22; Tue, 4 Mar 2014 18:35:25 +0000 Received: from mail10-co9 (localhost [127.0.0.1]) by mail10-co9-R.bigfish.com (Postfix) with ESMTP id 4BFAFE0500; Tue, 4 Mar 2014 18:35:25 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -11 X-BigFish: VPS-11(zz1dbaI1432Ic1dM4015I18a8Kzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail10-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(63124002)(199002)(164054003)(189002)(31014004)(51704005)(80976001)(81686001)(95416001)(81816001)(65816001)(77982001)(54316002)(92566001)(87266001)(93516002)(86362001)(94946001)(94316002)(92726001)(76786001)(76796001)(93136001)(51856001)(97186001)(56816005)(90146001)(79102001)(46102001)(85852003)(63696002)(77096001)(56776001)(83072002)(81342001)(53806001)(59766001)(66066001)(2656002)(87936001)(83322001)(69226001)(36756003)(80022001)(85306002)(76482001)(4396001)(49866001)(50986001)(47736001)(47976001)(31966008)(74502001)(54356001)(95666003)(83506001)(74366001)(47446002)(74662001)(81542001)(74876001)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB708; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:3EAEF216.36E2C709.F3D35F7B.8AE2EB8D.202BA; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail10-co9 (localhost.localdomain [127.0.0.1]) by mail10-co9 (MessageSwitch) id 1393958123684213_31587; Tue, 4 Mar 2014 18:35:23 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.248]) by mail10-co9.bigfish.com (Postfix) with ESMTP id 9950720081; Tue, 4 Mar 2014 18:35:23 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 4 Mar 2014 18:35:23 +0000 Received: from BLUPR05MB708.namprd05.prod.outlook.com (10.141.207.24) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 4 Mar 2014 18:35:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB708.namprd05.prod.outlook.com (10.141.207.24) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 4 Mar 2014 18:35:20 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.229]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.186]) with mapi id 15.00.0883.010; Tue, 4 Mar 2014 18:35:19 +0000 From: Kent Watsen To: Randy Presuhn , "netconf@ietf.org" Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPNxNDXJRY3wt5xU21sJN7KFRgh5rRQtUA Date: Tue, 4 Mar 2014 18:35:18 +0000 Message-ID: References: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> In-Reply-To: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 01401330D1 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eAmbpQJo3k1Nkr1Fdrgc2_g0Yg8 Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:35:31 -0000 >>Instead, they just need to get a hold of my USB key and insert a >>malicious configlet. Then I need to insert it into my otherwise >>physically secure device, and it will load the [unsigned] malicious >>bootstrap config. >> >>Kent's argument was that one should check the contents of the configlet >>before loading (it is clear text after all). So this may be a >>non-issue. However, I wanted to raise it with the WG to see what others >>think. > >If detecting malicious misconfiguration were straightforward, >we'd be able to prevent the inadvertent misconfigurations that >are at the root of so many outages. Consequently, the "check >the contents" line of reasoning doesn't convince me. That sounds more like a competency issue, but I'll grant you that administrators generating *signed* configlets are likely to be more thorough than others... FWIW, The Security thinking is that someone that can get physical access to a device already owns it. So, requiring the Configlet to be signed doesn't protect anything and, given the logistical overhead involved in getting/using *signed* Configlets, would only frustrate trusted administrators. In this case, the administrator is using the Configlet because it's easier/more-scalable than manual configuration. Joe brings up the special case where an adversary doesn't get physical access, but passes an unsigned Configlet to a trusted administrator, who initializes a device using it without inspecting it first. To be fair, it could be that trusted administrator could've been duped and actually thinks the Configlet is trusted and hence doesn't consider the need to [re]inspect it. =20 Maybe this last issue be addressed via a Security Consideration - e.g. "unsigned Configlets SHOULD be inspected before each use." What do you think? Thanks, Kent From nobody Tue Mar 4 10:47:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 491531A0224 for ; Tue, 4 Mar 2014 10:47:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wd2O2uin3CTw for ; Tue, 4 Mar 2014 10:47:05 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id BEAAC1A0187 for ; Tue, 4 Mar 2014 10:47:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1785613B4; Tue, 4 Mar 2014 19:47:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id USvAoHTho0Rj; Tue, 4 Mar 2014 19:46:59 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Tue, 4 Mar 2014 19:46:59 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id C73752002C; Tue, 4 Mar 2014 19:46:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6NrJnGjDFcQq; Tue, 4 Mar 2014 19:46:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D88B2002F; Tue, 4 Mar 2014 19:46:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 893772B9391E; Tue, 4 Mar 2014 19:46:56 +0100 (CET) Date: Tue, 4 Mar 2014 19:46:56 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140304184656.GB28225@elstar.local> Mail-Followup-To: Kent Watsen , "netconf@ietf.org" References: <10477101.1393873410104.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6eOyXX8yI2t6C3gNgf-n8eMgYlA Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 18:47:11 -0000 On Tue, Mar 04, 2014 at 06:35:18PM +0000, Kent Watsen wrote: > > Joe brings up the special case where an adversary doesn't get physical > access, but passes an unsigned Configlet to a trusted administrator, who > initializes a device using it without inspecting it first. To be fair, it > could be that trusted administrator could've been duped and actually > thinks the Configlet is trusted and hence doesn't consider the need to > [re]inspect it. > > Maybe this last issue be addressed via a Security Consideration - e.g. > "unsigned Configlets SHOULD be inspected before each use." What do you > think? > The person plugging the USB stick into a box may not have much clue what he is doing, technically. I doubt this can be taken easy - not all devices are deployed in safe environments by smart people. I am not sure there always is going to be a 'trusted administrator'. In fact, during the presentation, I was wondering myself whether the configlet should not instead be signed _and_ encrypted. The assumption that someone reads the configlet and is able to decide whether it is a good one or not seems a bit scary to me, in particular if I think about boxes deployed in the wild. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 4 12:07:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 399491A02B6 for ; Tue, 4 Mar 2014 12:07:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id g5VUXDqJpNnf for ; Tue, 4 Mar 2014 12:07:10 -0800 (PST) Received: from elasmtp-banded.atl.sa.earthlink.net (elasmtp-banded.atl.sa.earthlink.net [209.86.89.70]) by ietfa.amsl.com (Postfix) with ESMTP id E04CF1A02E3 for ; Tue, 4 Mar 2014 12:07:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=nlXss9P6lQhJlYyCT3QtnYA50pmt0gsOfT/PGah9nNzypHKMfKfUpZsRUyl1fyHz; h=Message-ID:Date:From:Reply-To:To:Subject:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.32] (helo=elwamui-cypress.atl.sa.earthlink.net) by elasmtp-banded.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1WKvcI-0005DK-03 for netconf@ietf.org; Tue, 04 Mar 2014 15:07:06 -0500 Received: from 76.254.50.8 by webmail.earthlink.net with HTTP; Tue, 4 Mar 2014 15:07:05 -0500 Message-ID: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Date: Tue, 4 Mar 2014 12:07:06 -0800 (GMT-08:00) From: Randy Presuhn To: "netconf@ietf.org" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88891b749bef7332bbc6f796596c05252c7f93f317ba882900d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.32 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/OUsB_r5fgaOxPL6d5KBfJUWHufM Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:07:13 -0000 Hi - >From: Kent Watsen >Sent: Mar 4, 2014 10:35 AM >To: Randy Presuhn , "netconf@ietf.org" >Subject: Re: [Netconf] Unsigned configlets and physical security ... >FWIW, The Security thinking is that someone that can get physical access >to a device already owns it. Stuxnet. >So, requiring the Configlet to be signed >doesn't protect anything and, given the logistical overhead involved in >getting/using *signed* Configlets, would only frustrate trusted >administrators. If it's the administrator typing things in at a console, yes. If it's the administrator bringing in the configuration data on other media or via the network, clearly no. >In this case, the administrator is using the Configlet >because it's easier/more-scalable than manual configuration. Thus increasing the likelihood that it's brought in on external media, along with all the vulnerabilities that come with that. >Joe brings up the special case where an adversary doesn't get physical >access, but passes an unsigned Configlet to a trusted administrator, who >initializes a device using it without inspecting it first. To be fair, it >could be that trusted administrator could've been duped and actually >thinks the Configlet is trusted and hence doesn't consider the need to >[re]inspect it. That's where signatures can help, assuming they're actually *checked* and the CAs involved haven't been subverted. >Maybe this last issue be addressed via a Security Consideration - e.g. >"unsigned Configlets SHOULD be inspected before each use." What do you >think? You're much more optimistic than I about the likelihood of discovering configuration errors by inspection. Consider possibilities like pointing to bogus DNS roots, installing trojan-horse user IDs, pre-compromised keys for little-used accounts, or weakening the encryption on selected links. After all, an attacker's objective might simply be to make sure that outgoing traffic is easily monitored. An attack could be as simple as changing a few bits in VACM's configuration to allow the attacker to use SNMP to complete the attack. Randy From nobody Tue Mar 4 15:52:29 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C37A1A00A8 for ; Tue, 4 Mar 2014 15:52:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.747 X-Spam-Level: X-Spam-Status: No, score=-4.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A0tKy-5tdLva for ; Tue, 4 Mar 2014 15:52:23 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 67BC21A002F for ; Tue, 4 Mar 2014 15:52:23 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id s24NnvSK002555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 4 Mar 2014 15:49:58 -0800 (PST) Message-ID: <531666A5.7070102@isi.edu> Date: Tue, 04 Mar 2014 15:49:57 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , "Bert Wijnen (IETF)" , netconf References: <52DD39AC.5070303@cisco.com> <530C7F17.1000500@bwijnen.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-eGGnijQOCka9ooZBQlF3NagZcU Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 23:52:26 -0000 A well designed protocol needs one port. What's the rationale for so many variants of the same service, and what happens if both run on the same machine and collide? (i.e., two independent ports could mean independent two servers). Joe On 2/25/2014 7:41 AM, Kent Watsen wrote: > > I believe that is the case as well, but note that we need two port > assignments - one for reverse-SSH and another for reverse-TLS. > > Cheers! > Kent > > > > On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" wrote: > >> NETCONF WG participants, >> >> there has been quite some discussion about this topic on our mailing list. >> We (WG chairs) have asked our AD (Benoit) to follow up in the IESG. >> >> Our current understanding is that if our WG has consensus on asking for >> a new port, then we can do so and we should get one. >> >> We (WG chairs) belive we have (at least rough) consensus on this matter >> and so we will ask for a new port. >> >> Bert and Mehmet >> >> >> -------- Original Message -------- >> Subject: Re: NETCONF call home and new port assignment >> Resent-To: bertietf@bwijnen.net, mehmet.ersue@nsn.com,, >> bclaise@cisco.com, joelja@bogus.com, jjaeggli@zynga.com >> Date: Mon, 20 Jan 2014 15:58:52 +0100 >> From: Benoit Claise >> CC: Joe Touch , "netconf-chairs@tools.ietf.org" >> , "Romascanu, Dan (Dan)" >> , Lemon Ted , >> "ops-ads@tools.ietf.org" , >> Kent Watsen >> >> Dear all, >> >> We discussed the issue of potentially allocating a new port for the >> NETCONF call home during our informal telechat last week. >> Personally, I wanted a confirmation on the procedure. >> Material: >> http://www.iana.org/assignments/service-names-port-numbers/service-names-p >> ort-numbers.xhtml >> an >> RFC 6335 >> >> Bottom line: The review of the port assignment via IETF standards >> (consensus based) does not go to the port review >> >> There is strong consensus to allocate this port in the NETCONF WG. >> - http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf >> 30 in favor, 0 against >> - doublechecked on the mailing list >> http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html >> >> So we're good here, let's proceed with the new port design >> >> Regards, Benoit >> >>> Hi, Benoit, >>> >>> On 11/4/2013 10:30 AM, Benoit Claise wrote: >>>> Hi Joe, >>>> >>>> Regarding the "NETCONF call home and new port assignment" discussion on >>>> the NETCONF mailer, I'm wondering if your comments are made as the port >>>> expert reviewer or as a contributor. >>> >>> The ports review team doesn't participate in that role on these >>> discussions on the lists; we review requests and report directly to >>> IANA. So I'm speaking as a contributor, but it's with the ports review >>> in the back of my mind. >>> >>>> In the NETCONF WG, there is strong consensus that the new port is the >>>> preferred way. We checked that today: by a show of hand, everybody >>>> wanted a new port. >>> >>> Everyone always does. >>> >>>> I want to understand if there is a major flaw in requesting this port. >>> >>> There's often a case where the individual request makes sense, but in >>> the broader context of "tragedy of the commons" it doesn't. That's my >>> impression here. There should be other ways to accomplish this - the >>> SYN attempt I recently saw looked like a good alternative that would >>> scale to other assignments, e.g. >>> >>>> Note: I contacted it you directly, because I'm not sure how to reach >>>> all >>>> the expert reviewers at the same time. >>> >>> There's no official way to do that. We respond to requests for reviews >>> from IANA, and report back to IANA directly. There's no "official" >>> role for us in the IETF directly. >>> >>> Joe >>> >>>> >>>> http://www.iana.org/assignments/service-names-port-numbers/service-names >>>> -port-numbers.xhtml >>>> >>>> is not explicit >>>> >>>> Regards, Benoit (OPS AD) >>> . >>> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Wed Mar 5 03:12:46 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DF51A03ED for ; Wed, 5 Mar 2014 03:12:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQ_5vMLmEJxM for ; Wed, 5 Mar 2014 03:12:39 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9707D1A0285 for ; Wed, 5 Mar 2014 03:12:35 -0800 (PST) Received: from localhost (dhcp-a6ed.meeting.ietf.org [31.133.166.237]) by mail.tail-f.com (Postfix) with ESMTPSA id C7D6437C2B2 for ; Wed, 5 Mar 2014 12:12:30 +0100 (CET) Date: Wed, 05 Mar 2014 11:12:28 +0000 (GMT) Message-Id: <20140305.111228.304368597.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/X0MIFgFj7JKjRFcykjWiWJAT2ho Subject: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:12:42 -0000 Hi, I have reviewed this document, and have just one comment. The last paragraph of section 2.4.1 says: If the NETCONF client has external information as to the expected identity of the NETCONF server, the hostname check MAY be omitted. There are some MUSTs in the preceding paragraphs, and it is not clear to me what "the hostname check" refers to. /martin From nobody Wed Mar 5 03:22:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CAAD31A04E9 for ; Wed, 5 Mar 2014 03:22:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FFKFskSMfeXY for ; Wed, 5 Mar 2014 03:22:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 784381A0503 for ; Wed, 5 Mar 2014 03:22:32 -0800 (PST) Received: from localhost (dhcp-a6ed.meeting.ietf.org [31.133.166.237]) by mail.tail-f.com (Postfix) with ESMTPSA id 6B2EA37C2B2; Wed, 5 Mar 2014 12:22:28 +0100 (CET) Date: Wed, 05 Mar 2014 11:22:27 +0000 (GMT) Message-Id: <20140305.112227.443033008.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140304162125.GA27569@elstar.local> References: <53151B85.2050204@bwijnen.net> <20140304162125.GA27569@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nh0wMw4WYGANrUpKnS2r6wewrY4 Cc: netconf@ietf.org Subject: Re: [Netconf] reverse ssh document title X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 11:22:34 -0000 Juergen Schoenwaelder wrote: > On Tue, Mar 04, 2014 at 03:21:36PM +0000, Kent Watsen wrote: > > > > I agree - "Reverse Secure Shell for NETCONF" ??? > > Works for me. +1 There are some other places in the document that also should be made more specific, e.g. the last paragraph in section 3 should probably be removed: One key benefit of using SSH as the transport protocol is its ability to multiplex an unspecified number of independently flow-controlled TCP sessions [RFC4254]. This is valuable as the network element only needs to be configured to initiate a single Reverse SSH connection to the management system, regardless the number of TCP-based protocols the management system wishes to support. For instance, in addition to having a SSH channel for NETCONF, the management system may "pin up" channels for Syslog, SNMP, or file-transfers. The IANA-requested port's service name should be "netconf-ssh-ch" (to align w/ 5539bis). /martin From nobody Wed Mar 5 08:08:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF5521A064F for ; Wed, 5 Mar 2014 08:08:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Too7mNl8Opjx for ; Wed, 5 Mar 2014 08:08:11 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id B95A91A01F5 for ; Wed, 5 Mar 2014 08:08:10 -0800 (PST) Received: from localhost (dhcp-83db.meeting.ietf.org [31.133.131.219]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E7C237C2B9 for ; Wed, 5 Mar 2014 17:08:06 +0100 (CET) Date: Wed, 05 Mar 2014 16:08:05 +0000 (GMT) Message-Id: <20140305.160805.103269227.mbj@tail-f.com> To: netconf@ietf.org From: Martin Bjorklund X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/m-fl70o9KUKY9Q2JFNcLKEw3eCw Subject: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:08:13 -0000 Hi, Here are some high-level comments on draft-kwatsen-netconf-zerotouch-01. Section 4.2 says: While initializing its networking, the device MAY receive some additional URIs for where a software image or configuration can be downloaded. This draft does not define how such URIs MAY be exchanged, for instance, using DHCP options. For this solution to be complete and interoperable, shouldn't we define the DHCP option for configuration / configlets? ---- Also, for the same reason, shouldn't there be some mandatory URI schemes (e.g. https/http)? ---- Section 4.2 also says: For URIs discovered while initializing its networking, the device MAY try both the raw URI as well as the permutation of it using its fingerprint. Why is this not a MUST? If I implement a configuration server, I'd like to know where to put the configlets. ---- I don't think you should define a data model that is just copy & pasted from ietf-system and ietf-netconf-server. Instead, I suggest that the configlet simply is an XML file with initial configuration for the device, matching whatever data models the device supports. This allows vendor-specific config, but also other standard config. In order to fully support the zerotouch procedure (with call-home), ietf-netconf-server and ietf-system MUST be supported by the device. (but I am not sure this is actually needed...) The XML file should be on "copy-config" format, i.e.: /martin From nobody Wed Mar 5 08:32:04 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0AB21A01BF; Wed, 5 Mar 2014 08:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9oxznD2I3Lf4; Wed, 5 Mar 2014 08:31:59 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id C4CAB1A01A7; Wed, 5 Mar 2014 08:31:58 -0800 (PST) Received: from localhost (dhcp-83db.meeting.ietf.org [31.133.131.219]) by mail.tail-f.com (Postfix) with ESMTPSA id A442C37C2BC; Wed, 5 Mar 2014 17:31:54 +0100 (CET) Date: Wed, 05 Mar 2014 16:31:54 +0000 (GMT) Message-Id: <20140305.163154.391777655.mbj@tail-f.com> To: equinox@diac24.net From: Martin Bjorklund In-Reply-To: <20140303140039.GZ856433@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4XMd7zTN7QZ5Sv6hYj2lrqyGp98 Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:32:01 -0000 Hi, David Lamparter wrote: > Hi, > > > (this is the mail version of the somewhat garbled comment on the mic) > > The original question was, how the configured device chooses a "VPN" > for > either incoming or outgoing connections. This referred to VRF > instances. In particular, for the very simplest case where this > matters, there are devices that have out of band management ports and > treat those as a VRF. So, both for listening and for connecting, the > device needs to choose between "VR-Default" and "VR-Mgmt" (actual > names, > guess the vendor.) It could even listen in both VRFs, to be > manageable > inband (normal ops maybe?) and out of band (network in flames?). > > Even though this was raised on the server config model, this is a > rather > generic problem. E.g. specifying a NTP or Syslog server has the same > issue. (Cc' from netconf to netmod due to this.) If I understand this correctly, the proposal is to include a reference to a routing-instance (rt:routing-instance-ref) in all cases where we currently have an ip-address (or host) and a port, since the combination of ip-adress and port is not guaranteed to be unique, on systems with multiple routing instances. leaf address { type inet:ip-address; } leaf port { type inet:port-number; } leaf routing-instance { type rt:routing-instance-ref; } The existsing data models (specifically ietf-system) are designed in a way that vendors can augment there own definition of routing-instance or vrf. (However, I noticed that ietf-snmp is not). The question is if the IETF models should include a standardized way to handle this. I can see three alternatives: 1) Do nothing. I.e., assume ip/port is unique. 2) In all our data models, always make sure we add an (optional) reference to a routing-instance, whenever we have a ip/port for inbound/outbound traffic. 3) Do not add the routing-instance references, but design our data models so that vendors can augment with this if they have to. /martin From nobody Wed Mar 5 08:47:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 740CB1A0759; Wed, 5 Mar 2014 08:47:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E6FvChnfPk6S; Wed, 5 Mar 2014 08:46:57 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AEEA61A071A; Wed, 5 Mar 2014 08:46:57 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C2DFF18E8; Wed, 5 Mar 2014 17:46:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EHWlYIzE9CTx; Wed, 5 Mar 2014 17:46:53 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 5 Mar 2014 17:46:53 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5BEBC2002C; Wed, 5 Mar 2014 17:46:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SpXYenMFT8Q8; Wed, 5 Mar 2014 17:46:52 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8F5C42002F; Wed, 5 Mar 2014 17:46:52 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 8845B2B95E23; Wed, 5 Mar 2014 17:46:50 +0100 (CET) Date: Wed, 5 Mar 2014 17:46:49 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140305164648.GC31132@elstar.local> Mail-Followup-To: Martin Bjorklund , equinox@diac24.net, netconf@ietf.org, netmod@ietf.org References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wenDKEElcpjve5OEf2G2QWDShrY Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:47:02 -0000 On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > Hi, > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. > My preference is 3) unless there is documented IETF agreement that addressing needs to include a routing instance (e.g., a standards-track RFC). My understanding is that 3) also allows IETF augmentations, not only vendor augmentations. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Mar 5 08:51:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5CAF61A0784; Wed, 5 Mar 2014 08:51:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w_EoYQ67Bbgw; Wed, 5 Mar 2014 08:51:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 813E31A078C; Wed, 5 Mar 2014 08:51:14 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 178E613F94C; Wed, 5 Mar 2014 17:51:09 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394038270; bh=eRyNDXhPrtbyG7sNqC2dKGt3mRBYRnh+FKZzyIf7KBQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kUWN5XYPbuK8/EaAJOk9BYuRWAt/CJMQ4kClBUQau9pqfadilC8yPOcrGGi7T4cXl 49B+7qk9XXq46/slznHylvf6Mg6kHdCzRdLZ2u00dFXBy5N9E5Lt6F84CGSedsn3ii D7tF9HBHICPu8QsxPX4PT55K2aZBLlknwB0pXfhA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> Date: Wed, 5 Mar 2014 16:51:08 +0000 Content-Transfer-Encoding: 7bit Message-Id: <9DA17C69-64BB-4F07-A5F8-91AF1ACB8796@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eWHF9Tf0KpRxu2zqmJzQzWuU9Lk Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:51:16 -0000 On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: > Hi, > > David Lamparter wrote: >> Hi, >> >> >> (this is the mail version of the somewhat garbled comment on the mic) >> >> The original question was, how the configured device chooses a "VPN" >> for >> either incoming or outgoing connections. This referred to VRF >> instances. In particular, for the very simplest case where this >> matters, there are devices that have out of band management ports and >> treat those as a VRF. So, both for listening and for connecting, the >> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >> names, >> guess the vendor.) It could even listen in both VRFs, to be >> manageable >> inband (normal ops maybe?) and out of band (network in flames?). >> >> Even though this was raised on the server config model, this is a >> rather >> generic problem. E.g. specifying a NTP or Syslog server has the same >> issue. (Cc' from netconf to netmod due to this.) > > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. > > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } > > > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. My preference is #3. Lada > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 08:53:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19B521A078F for ; Wed, 5 Mar 2014 08:53:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aN_tO_KuAvAa for ; Wed, 5 Mar 2014 08:53:19 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id E0EE21A0784 for ; Wed, 5 Mar 2014 08:53:18 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1D3E31880; Wed, 5 Mar 2014 17:53:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id RlOnDnlz_jfW; Wed, 5 Mar 2014 17:53:14 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Wed, 5 Mar 2014 17:53:14 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 701B22002F; Wed, 5 Mar 2014 17:53:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i5hBPElHXQ25; Wed, 5 Mar 2014 17:53:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 830DD2002C; Wed, 5 Mar 2014 17:53:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4C57D2B95F1A; Wed, 5 Mar 2014 17:53:12 +0100 (CET) Date: Wed, 5 Mar 2014 17:53:12 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140305165312.GE31132@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20140305.160805.103269227.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.160805.103269227.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ANn5IQGgxj7KOl9oEfpPaLnwB8Q Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 16:53:21 -0000 On Wed, Mar 05, 2014 at 04:08:05PM +0000, Martin Bjorklund wrote: > > I don't think you should define a data model that is just copy & > pasted from ietf-system and ietf-netconf-server. Instead, I suggest > that the configlet simply is an XML file with initial configuration > for the device, matching whatever data models the device supports. > This allows vendor-specific config, but also other standard config. I agree. > In order to fully support the zerotouch procedure (with call-home), > ietf-netconf-server and ietf-system MUST be supported by the device. > (but I am not sure this is actually needed...) > > The XML file should be on "copy-config" format, i.e.: > > > > > > > > Yes, makes a lot of sense. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Mar 5 09:01:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 714FE1A0140; Wed, 5 Mar 2014 09:01:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_378kv9R7yM; Wed, 5 Mar 2014 09:01:22 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EDA11A012A; Wed, 5 Mar 2014 09:01:22 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WLFC1-0002M0-Pz; Wed, 05 Mar 2014 18:01:17 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WLFBn-003IgT-Os; Wed, 05 Mar 2014 18:01:07 +0100 Date: Wed, 5 Mar 2014 18:01:03 +0100 From: David Lamparter To: Martin Bjorklund Message-ID: <20140305170103.GQ104882@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nCaRYW_xuIkVenhpZHpR4TY2REQ Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:01:25 -0000 (comments below) On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > David Lamparter wrote: > > The original question was, how the configured device chooses a "VPN" > > for > > either incoming or outgoing connections. This referred to VRF > > instances. In particular, for the very simplest case where this > > matters, there are devices that have out of band management ports and > > treat those as a VRF. So, both for listening and for connecting, the > > device needs to choose between "VR-Default" and "VR-Mgmt" (actual > > names, > > guess the vendor.) It could even listen in both VRFs, to be > > manageable > > inband (normal ops maybe?) and out of band (network in flames?). > > > > Even though this was raised on the server config model, this is a > > rather > > generic problem. E.g. specifying a NTP or Syslog server has the same > > issue. (Cc' from netconf to netmod due to this.) > > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. Indeed, with the caveat that this also applies to listening ports (which are specified just the same, just noting it so this doesn't get lost.) > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } > > > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). > > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: > > 1) Do nothing. I.e., assume ip/port is unique. > > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. > > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. It seems that 1) would imply a mixture of not having support for this and case 3) in places where we already allow extensions, and I'd claim that this inconsistency is undesirable. I would however argue for option 2), based on the fact that routing-cfg does have routing instances in a standardised way, and I don't see the point in each vendor defining a distinct extension to add this reference. Essentially, I would say that if there's a problem with 2) here, there's also a problem with routing instances in routing-cfg, which in turn means we fix that or we're headed for neverland on the express train. Cheers, -David From nobody Wed Mar 5 09:15:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3095D1A03BC; Wed, 5 Mar 2014 09:15:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PSnWNXYJmxCl; Wed, 5 Mar 2014 09:15:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id A9A411A01A7; Wed, 5 Mar 2014 09:15:28 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 3415913F94C; Wed, 5 Mar 2014 18:15:24 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394039724; bh=Zpw55qUaW7mexjOk/4UtM0PvhZZUDYCKgr5mKMju+vk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=VmqpiLrfd1TVOlGZJEqcZlBDMy8HFBU7LesZT52FGJvtDfuEZABghHAlLimvooDCe DN/ABkFeBg+Xh8WrT9sNTxoXk/VIcjHvdzMoTHLSnVZy94VW+w1p1IggpH2l1PBa16 lHxa5rPKWrX+zFSHvBMTV0fcZvG5i3oi+gVIvi8E= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305170103.GQ104882@jupiter.n2.diac24.net> Date: Wed, 5 Mar 2014 17:15:23 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305170103.GQ104882@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mdUChXRHZ3sRQPPAi1K3NdJAeY4 Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:15:32 -0000 On 05 Mar 2014, at 17:01, David Lamparter wrote: > (comments below) >=20 > On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: >> David Lamparter wrote: >>> The original question was, how the configured device chooses a "VPN" >>> for >>> either incoming or outgoing connections. This referred to VRF >>> instances. In particular, for the very simplest case where this >>> matters, there are devices that have out of band management ports = and >>> treat those as a VRF. So, both for listening and for connecting, = the >>> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >>> names, >>> guess the vendor.) It could even listen in both VRFs, to be >>> manageable >>> inband (normal ops maybe?) and out of band (network in flames?). >>>=20 >>> Even though this was raised on the server config model, this is a >>> rather >>> generic problem. E.g. specifying a NTP or Syslog server has the = same >>> issue. (Cc' from netconf to netmod due to this.) >>=20 >> If I understand this correctly, the proposal is to include a = reference >> to a routing-instance (rt:routing-instance-ref) in all cases where we >> currently have an ip-address (or host) and a port, since the >> combination of ip-adress and port is not guaranteed to be unique, on >> systems with multiple routing instances. >=20 > Indeed, with the caveat that this also applies to listening ports = (which > are specified just the same, just noting it so this doesn't get lost.) >=20 >> leaf address { type inet:ip-address; } >> leaf port { type inet:port-number; } >> leaf routing-instance { type rt:routing-instance-ref; } >>=20 >>=20 >> The existsing data models (specifically ietf-system) are designed in = a >> way that vendors can augment there own definition of routing-instance >> or vrf. (However, I noticed that ietf-snmp is not). >>=20 >> The question is if the IETF models should include a standardized way >> to handle this. I can see three alternatives: >>=20 >> 1) Do nothing. I.e., assume ip/port is unique. >>=20 >> 2) In all our data models, always make sure we add an (optional) >> reference to a routing-instance, whenever we have a ip/port for >> inbound/outbound traffic. >>=20 >> 3) Do not add the routing-instance references, but design our data >> models so that vendors can augment with this if they have to. >=20 > It seems that 1) would imply a mixture of not having support for this > and case 3) in places where we already allow extensions, and I'd claim > that this inconsistency is undesirable. >=20 > I would however argue for option 2), based on the fact that = routing-cfg > does have routing instances in a standardised way, and I don't see the > point in each vendor defining a distinct extension to add this > reference. Essentially, I would say that if there's a problem with 2) As Juergen already pointed out in his reply, a standard model can be = written for this purpose, too. Lada > here, there's also a problem with routing instances in routing-cfg, > which in turn means we fix that or we're headed for neverland on the > express train. >=20 >=20 > Cheers, >=20 >=20 > -David >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 09:15:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C8E951A029D; Wed, 5 Mar 2014 09:15:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EnNFQkX7QxKT; Wed, 5 Mar 2014 09:15:31 -0800 (PST) Received: from spaceboyz.net (spaceboyz.net [IPv6:2001:8d8:870:1000::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F2761A0183; Wed, 5 Mar 2014 09:15:31 -0800 (PST) Received: from [2001:8d8:81:5c2::] (helo=jupiter.n2.diac24.net) by spaceboyz.net with esmtps (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.80.1) (envelope-from ) id 1WLFPi-00035B-V0; Wed, 05 Mar 2014 18:15:27 +0100 Received: from equinox by jupiter.n2.diac24.net with local (Exim 4.80.1) (envelope-from ) id 1WLFPV-003JVS-Sp; Wed, 05 Mar 2014 18:15:16 +0100 Date: Wed, 5 Mar 2014 18:15:13 +0100 From: David Lamparter To: Martin Bjorklund , equinox@diac24.net, netconf@ietf.org, netmod@ietf.org Message-ID: <20140305171513.GR104882@jupiter.n2.diac24.net> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305164648.GC31132@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140305164648.GC31132@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_4eIN9uKXXHAAhgAo0jMYCzJGQw Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:15:38 -0000 On Wed, Mar 05, 2014 at 05:46:49PM +0100, Juergen Schoenwaelder wrote: > On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: > > Hi, > > > > The question is if the IETF models should include a standardized way > > to handle this. I can see three alternatives: > > > > 1) Do nothing. I.e., assume ip/port is unique. > > > > 2) In all our data models, always make sure we add an (optional) > > reference to a routing-instance, whenever we have a ip/port for > > inbound/outbound traffic. > > > > 3) Do not add the routing-instance references, but design our data > > models so that vendors can augment with this if they have to. > > > > My preference is 3) unless there is documented IETF agreement > that addressing needs to include a routing instance (e.g., a > standards-track RFC). My understanding is that 3) also allows > IETF augmentations, not only vendor augmentations. I've made this as an assumption in my previous answer, but didn't explicitly mention it: I believe having support for routing instances in routing-cfg and having a reference in addressing share the same reasoning: there are configurable systems that contain more than one VRF / IP stack / routing domain / whatever you call it. And as such, just like you can't add a static route without saying which of these instances you want to insert it in, it's underspecified from where you want to establish your syslog connection if you don't specify the IP stack instance to be used. Yes, there might be a default instance for management. But I believe the rather widespread case of a box with in-band + out-of-band management rectifies always having this reference. We're not talking about enterprise routers here, this is 400€ small-business COTS switches. Are there reasons for modeling routing instances in routing-cfg that don't apply here? NB: it might be an acceptable solution to fix this in a separate draft for existing extensible cases, so we don't need to reroll things. However, for future models, I don't think we want to create a VRF-for-this VRF-for-that extra spec each single time? -David From nobody Wed Mar 5 09:31:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01BAA1A01F4; Wed, 5 Mar 2014 09:31:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 928MQyVd_8_z; Wed, 5 Mar 2014 09:31:54 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id DC6EE1A01E2; Wed, 5 Mar 2014 09:31:53 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:81f5:2b14:607f:7f9c]) by mail.nic.cz (Postfix) with ESMTPSA id E951714014F; Wed, 5 Mar 2014 18:31:48 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394040709; bh=LhG10vUa1qMUMcrUgRV3J/PbFa/Jo9w6NsCiD00280A=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=oxW4LGM/sdzP6c0/efnhO9WgNppafb8cgYzQW8fpMlUqqLy6IFNFTE3+i1iwXZXOb jDqUieX5R++q/JtPV2chpoMW1rRlRJPnHypXrvvvsCH81FV2H+jSfuXvgbOf85aiWd vfCdez1JKfQiuihhLI3xHleiZjPCxtOASnTJATi8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305171513.GR104882@jupiter.n2.diac24.net> Date: Wed, 5 Mar 2014 17:31:47 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <6161D244-5AE2-4C0A-9EAF-67160E456AE7@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <20140305164648.GC31132@elstar.local> <20140305171513.GR104882@jupiter.n2.diac24.net> To: David Lamparter X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3hLuuPe8xFgqLujRfm_tanNeXso Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 17:31:56 -0000 On 05 Mar 2014, at 17:15, David Lamparter wrote: > On Wed, Mar 05, 2014 at 05:46:49PM +0100, Juergen Schoenwaelder wrote: >> On Wed, Mar 05, 2014 at 04:31:54PM +0000, Martin Bjorklund wrote: >>> Hi, >>>=20 >>> The question is if the IETF models should include a standardized way >>> to handle this. I can see three alternatives: >>>=20 >>> 1) Do nothing. I.e., assume ip/port is unique. >>>=20 >>> 2) In all our data models, always make sure we add an (optional) >>> reference to a routing-instance, whenever we have a ip/port for >>> inbound/outbound traffic. >>>=20 >>> 3) Do not add the routing-instance references, but design our data >>> models so that vendors can augment with this if they have to. >>>=20 >>=20 >> My preference is 3) unless there is documented IETF agreement >> that addressing needs to include a routing instance (e.g., a >> standards-track RFC). My understanding is that 3) also allows >> IETF augmentations, not only vendor augmentations. >=20 > I've made this as an assumption in my previous answer, but didn't > explicitly mention it: I believe having support for routing instances > in routing-cfg and having a reference in addressing share the same > reasoning: there are configurable systems that contain more than one > VRF / IP stack / routing domain / whatever you call it. And as such, > just like you can't add a static route without saying which of these > instances you want to insert it in, it's underspecified from where you > want to establish your syslog connection if you don't specify the IP > stack instance to be used. >=20 > Yes, there might be a default instance for management. But I believe > the rather widespread case of a box with in-band + out-of-band > management rectifies always having this reference. We're not talking > about enterprise routers here, this is 400=80 small-business COTS > switches. >=20 > Are there reasons for modeling routing instances in routing-cfg that > don't apply here? It should probably be spelled out somewhere, but in many cases there = will only be a single routing instance, so it is bound to be the default = to be used for all routing. =20 >=20 >=20 > NB: it might be an acceptable solution to fix this in a separate draft > for existing extensible cases, so we don't need to reroll things. > However, for future models, I don't think we want to create a > VRF-for-this VRF-for-that extra spec each single time? I see your point, a separate draft can only define augments for the = existing cases. Then #2 might be indeed better, perhaps using a feature = like =93multiple-routing-instances=94. Lada >=20 >=20 > -David >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Mar 5 11:28:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5E51A0302 for ; Wed, 5 Mar 2014 11:27:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UF8QCTp28oKh for ; Wed, 5 Mar 2014 11:27:55 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) by ietfa.amsl.com (Postfix) with ESMTP id 6A0711A02CE for ; Wed, 5 Mar 2014 11:27:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1757; q=dns/txt; s=iport; t=1394047659; x=1395257259; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=/KQx54Oc+ZncsnDhV0YQU3Xp+Pqb3uZZpaHO49Ezxmg=; b=Iv117NdmjIRDlkzWOc9T5fr4lxS4zhNVZ2G2zyaI9QEbZ+D5mgnlU+4W SvGAca4Mi8MiXJrSWii5Wg7H/pG70K7ynlrOE8VvmQiFlwvnYi5PjVChZ dnv2H2MfUsyKCaPYK+EzZAyQIJlqqRe1iKTahR2BcJtHfkJGuilwMi3OG k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgsFAKB5F1OQ/khL/2dsb2JhbABagwY7wWSBGhZ0giUBAQEEOEARCw4KCRYPCQMCAQIBRQYBDAgBAReHXs5oF45YhDgBA4lLjnKGSothg0se X-IronPort-AV: E=Sophos;i="4.97,594,1389744000"; d="scan'208";a="2561983" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-4.cisco.com with ESMTP; 05 Mar 2014 19:27:38 +0000 Received: from [10.82.229.195] (rtp-vpn1-1474.cisco.com [10.82.229.195]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s25JRaa2010787; Wed, 5 Mar 2014 19:27:37 GMT Message-ID: <53177AA8.2000605@cisco.com> Date: Wed, 05 Mar 2014 14:27:36 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Bjorklund , netconf@ietf.org References: <20140305.160805.103269227.mbj@tail-f.com> In-Reply-To: <20140305.160805.103269227.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/nadk12NZ-kr4U4KU19koqVMEmq8 Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:27:57 -0000 On 3/5/14, 11:08 AM, Martin Bjorklund wrote: > Hi, > > Here are some high-level comments on > draft-kwatsen-netconf-zerotouch-01. > > > Section 4.2 says: > > While initializing its networking, the device MAY receive some > additional URIs for where a software image or configuration can be > downloaded. This draft does not define how such URIs MAY be > exchanged, for instance, using DHCP options. > > For this solution to be complete and interoperable, shouldn't we > define the DHCP option for configuration / configlets? This makes sense to me. > > ---- > > Also, for the same reason, shouldn't there be some mandatory URI > schemes (e.g. https/http)? I can understand this request from a user convenience standpoint, but have an MTI URI scheme may make this harder to adopt by vendors. For DHCP, I can see having a standard option makes this much easier for users without putting too much burden on vendors, but forcing vendors to build out infrastructure for a specific protocol may be onerous. That said, I would think http[s] would be the most commonly implemented protocol... > > ---- > > Section 4.2 also says: > > For URIs > discovered while initializing its networking, the device MAY try both > the raw URI as well as the permutation of it using its fingerprint. > > Why is this not a MUST? If I implement a configuration server, I'd > like to know where to put the configlets. Vendors would pick one of the locations, but I don't see why we would need the raw URI. I know bulk configlets is something operators want, but in this manner we wouldn't be asserting any physical security, so I would think the fingerprint would need to be used. Joe From nobody Wed Mar 5 11:39:06 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D87121A011E for ; Wed, 5 Mar 2014 11:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XtSb6VjpmecU for ; Wed, 5 Mar 2014 11:39:03 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 020041A01D1 for ; Wed, 5 Mar 2014 11:39:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2509; q=dns/txt; s=iport; t=1394048339; x=1395257939; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=A3jfKyr1emuguGHn7ICSvLgHwZXHxHV87kxE+ERXzgI=; b=jRXAoKRnFe9Z3Hif6a/dmEwYgf8VKvz6qUBQvpX/1s29I+lFUUh7dewH 1NVSdXELszlr2NzsyYwCzGGr0UMzuGO+xUMYbg2t6cjR0GCE7tCVf6VTA At/xdu6icOHkhmi6zXx5ahGInk0l9mM6GNExoHajQ5nNagMkwLssTeZXo k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAN18F1OtJV2d/2dsb2JhbABagwY7V8A+T4EaFnSCJQEBAQQBAQE3NB0BCBgeNwslAgQBEhuHXg3OSxMEjliEOASYPZIrgy2CKg X-IronPort-AV: E=Sophos;i="4.97,594,1389744000"; d="scan'208";a="308307195" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 05 Mar 2014 19:38:59 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s25JcxTm026084 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 5 Mar 2014 19:38:59 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 5 Mar 2014 13:38:58 -0600 From: "Reinaldo Penno (repenno)" To: "Joe Clarke (jclarke)" , Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 Thread-Index: AQHPOKluNQy0LmVRJUO31aQjk4+E65rSwkAA Date: Wed, 5 Mar 2014 19:38:58 +0000 Message-ID: In-Reply-To: <53177AA8.2000605@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.2.3.120616 x-originating-ip: [10.21.114.238] Content-Type: text/plain; charset="us-ascii" Content-ID: <762028068344504597ED277BD0521F44@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PDpnpRIbQY4D6xo0ZJiIiiGxwI0 Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Mar 2014 19:39:05 -0000 On 3/5/14, 11:27 AM, "Joe Clarke (jclarke)" wrote: >On 3/5/14, 11:08 AM, Martin Bjorklund wrote: >> Hi, >> >> Here are some high-level comments on >> draft-kwatsen-netconf-zerotouch-01. >> >> >> Section 4.2 says: >> >> While initializing its networking, the device MAY receive some >> additional URIs for where a software image or configuration can be >> downloaded. This draft does not define how such URIs MAY be >> exchanged, for instance, using DHCP options. >> >> For this solution to be complete and interoperable, shouldn't we >> define the DHCP option for configuration / configlets? > >This makes sense to me. Yes, this text stands out since without the discovery part the solution is not complete. I would suggest using an Anycast address. DHCP is also okay, but anycast allows any device (with or without DHCP netconf option) or even any other method of self-provisioning to find Netconf client. > >> >> ---- >> >> Also, for the same reason, shouldn't there be some mandatory URI >> schemes (e.g. https/http)? > >I can understand this request from a user convenience standpoint, but >have an MTI URI scheme may make this harder to adopt by vendors. For >DHCP, I can see having a standard option makes this much easier for >users without putting too much burden on vendors, but forcing vendors to >build out infrastructure for a specific protocol may be onerous. > >That said, I would think http[s] would be the most commonly implemented >protocol... Right. The draft and some messages on this list alluded to FTP, HTTP or some other protocol being possible. I would suggest making at least one of them (HTTP) should? Must? > >> >> ---- >> >> Section 4.2 also says: >> >> For URIs >> discovered while initializing its networking, the device MAY try >>both >> the raw URI as well as the permutation of it using its fingerprint. >> >> Why is this not a MUST? If I implement a configuration server, I'd >> like to know where to put the configlets. > >Vendors would pick one of the locations, but I don't see why we would >need the raw URI. I know bulk configlets is something operators want, >but in this manner we wouldn't be asserting any physical security, so I >would think the fingerprint would need to be used. > >Joe > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 6 01:12:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 930B31A0194; Thu, 6 Mar 2014 01:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWQGgQa_qvX1; Thu, 6 Mar 2014 01:12:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6310F1A0170; Thu, 6 Mar 2014 01:12:48 -0800 (PST) Received: from wireless-v6.meeting.ietf.org (unknown [IPv6:2001:67c:370:160:6da5:2533:a87:3733]) by mail.nic.cz (Postfix) with ESMTPSA id 7915013F94C; Thu, 6 Mar 2014 10:12:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394097164; bh=Ewx+nNvdueux7BWm2ByqPT7pz9yI6xBdsUPtd4U0xdM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=FmDbnb8yoF9gL4Bd6Qh+WHQkEfkzX8HhyreKqVR3EIHWmxr3VQnS7Z9FBEvkXpfJs I6b9W/Zd4SpPczoKy6TNCD2i1hmaKNwdHaVSkM7ujw99VgTp8zS9L0vnDSZprFJ1Ih UIcUHmdWJ98uTjR+/tis/LJE9PUd0We61x67U4is= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140305.163154.391777655.mbj@tail-f.com> Date: Thu, 6 Mar 2014 09:12:41 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6GTVBQj_YrU26k2e9QiNooybD_s Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 09:12:51 -0000 On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: > Hi, >=20 > David Lamparter wrote: >> Hi, >>=20 >>=20 >> (this is the mail version of the somewhat garbled comment on the mic) >>=20 >> The original question was, how the configured device chooses a "VPN" >> for >> either incoming or outgoing connections. This referred to VRF >> instances. In particular, for the very simplest case where this >> matters, there are devices that have out of band management ports and >> treat those as a VRF. So, both for listening and for connecting, the >> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >> names, >> guess the vendor.) It could even listen in both VRFs, to be >> manageable >> inband (normal ops maybe?) and out of band (network in flames?). >>=20 >> Even though this was raised on the server config model, this is a >> rather >> generic problem. E.g. specifying a NTP or Syslog server has the same >> issue. (Cc' from netconf to netmod due to this.) >=20 > If I understand this correctly, the proposal is to include a reference > to a routing-instance (rt:routing-instance-ref) in all cases where we Hmm, it is actually not that simple. It is possible to have different = types of routing instances distinguished by the =93rt:type=94 child. So = it is not true that routing-instance =3D=3D VRF instance. Therefore, the correct approach is IMO this: 1. A module will be written defining the VRF type of routing instances = and specifying the semantics of this kind of virtualization. 2. Where necessary, vrf-id leafs will be added to the existing module = via augments. Before this is done, alternative #3 in Martin=92s list (i.e. enabling = step 2 above) seems to be the best option after all. Lada > currently have an ip-address (or host) and a port, since the > combination of ip-adress and port is not guaranteed to be unique, on > systems with multiple routing instances. >=20 > leaf address { type inet:ip-address; } > leaf port { type inet:port-number; } > leaf routing-instance { type rt:routing-instance-ref; } >=20 >=20 > The existsing data models (specifically ietf-system) are designed in a > way that vendors can augment there own definition of routing-instance > or vrf. (However, I noticed that ietf-snmp is not). >=20 > The question is if the IETF models should include a standardized way > to handle this. I can see three alternatives: >=20 > 1) Do nothing. I.e., assume ip/port is unique. >=20 > 2) In all our data models, always make sure we add an (optional) > reference to a routing-instance, whenever we have a ip/port for > inbound/outbound traffic. >=20 > 3) Do not add the routing-instance references, but design our data > models so that vendors can augment with this if they have to. >=20 >=20 > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Mar 6 02:45:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C64F1A020D for ; Thu, 6 Mar 2014 02:45:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzfhG-xPl0nk for ; Thu, 6 Mar 2014 02:45:35 -0800 (PST) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 1F9651A01C8 for ; Thu, 6 Mar 2014 02:45:35 -0800 (PST) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WLVnr-0002tr-Uv; Thu, 06 Mar 2014 11:45:29 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=dhcp-b47b.meeting.ietf.org) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WLVnr-0004zZ-Rm; Thu, 06 Mar 2014 11:45:27 +0100 Message-ID: <531851C4.5060500@bwijnen.net> Date: Thu, 06 Mar 2014 10:45:24 +0000 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Joe Touch , Kent Watsen , netconf References: <52DD39AC.5070303@cisco.com> <530C7F17.1000500@bwijnen.net> <531666A5.7070102@isi.edu> In-Reply-To: <531666A5.7070102@isi.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4ee08eaee7a7fd7200aaa7f07ab38cb64 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/afeMlduI_nbnBCRVzNvlj4JH4Qg Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:45:38 -0000 Joe, it does not help if you try to re-open the discussion. We have had the discussion The WG has concluded they want to ask for a new port, We have asked our AD to check with the IESG if this is acceptable, and our (WG chairs) understanding is that IF we as a WG want to ask for a port, we can do so. Bert speaking as co-chair. On 04/03/14 23:49, Joe Touch wrote: > A well designed protocol needs one port. > > What's the rationale for so many variants of the same service, and what happens if both run on the same machine and collide? (i.e., > two independent ports could mean independent two servers). > > Joe > > On 2/25/2014 7:41 AM, Kent Watsen wrote: >> >> I believe that is the case as well, but note that we need two port >> assignments - one for reverse-SSH and another for reverse-TLS. >> >> Cheers! >> Kent >> >> >> >> On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" wrote: >> >>> NETCONF WG participants, >>> >>> there has been quite some discussion about this topic on our mailing list. >>> We (WG chairs) have asked our AD (Benoit) to follow up in the IESG. >>> >>> Our current understanding is that if our WG has consensus on asking for >>> a new port, then we can do so and we should get one. >>> >>> We (WG chairs) belive we have (at least rough) consensus on this matter >>> and so we will ask for a new port. >>> >>> Bert and Mehmet >>> >>> >>> -------- Original Message -------- >>> Subject: Re: NETCONF call home and new port assignment >>> Resent-To: bertietf@bwijnen.net, mehmet.ersue@nsn.com,, >>> bclaise@cisco.com, joelja@bogus.com, jjaeggli@zynga.com >>> Date: Mon, 20 Jan 2014 15:58:52 +0100 >>> From: Benoit Claise >>> CC: Joe Touch , "netconf-chairs@tools.ietf.org" >>> , "Romascanu, Dan (Dan)" >>> , Lemon Ted , >>> "ops-ads@tools.ietf.org" , >>> Kent Watsen >>> >>> Dear all, >>> >>> We discussed the issue of potentially allocating a new port for the >>> NETCONF call home during our informal telechat last week. >>> Personally, I wanted a confirmation on the procedure. >>> Material: >>> http://www.iana.org/assignments/service-names-port-numbers/service-names-p >>> ort-numbers.xhtml >>> an >>> RFC 6335 >>> >>> Bottom line: The review of the port assignment via IETF standards >>> (consensus based) does not go to the port review >>> >>> There is strong consensus to allocate this port in the NETCONF WG. >>> - http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf >>> 30 in favor, 0 against >>> - doublechecked on the mailing list >>> http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html >>> >>> So we're good here, let's proceed with the new port design >>> >>> Regards, Benoit >>> >>>> Hi, Benoit, >>>> >>>> On 11/4/2013 10:30 AM, Benoit Claise wrote: >>>>> Hi Joe, >>>>> >>>>> Regarding the "NETCONF call home and new port assignment" discussion on >>>>> the NETCONF mailer, I'm wondering if your comments are made as the port >>>>> expert reviewer or as a contributor. >>>> >>>> The ports review team doesn't participate in that role on these >>>> discussions on the lists; we review requests and report directly to >>>> IANA. So I'm speaking as a contributor, but it's with the ports review >>>> in the back of my mind. >>>> >>>>> In the NETCONF WG, there is strong consensus that the new port is the >>>>> preferred way. We checked that today: by a show of hand, everybody >>>>> wanted a new port. >>>> >>>> Everyone always does. >>>> >>>>> I want to understand if there is a major flaw in requesting this port. >>>> >>>> There's often a case where the individual request makes sense, but in >>>> the broader context of "tragedy of the commons" it doesn't. That's my >>>> impression here. There should be other ways to accomplish this - the >>>> SYN attempt I recently saw looked like a good alternative that would >>>> scale to other assignments, e.g. >>>> >>>>> Note: I contacted it you directly, because I'm not sure how to reach >>>>> all >>>>> the expert reviewers at the same time. >>>> >>>> There's no official way to do that. We respond to requests for reviews >>>> from IANA, and report back to IANA directly. There's no "official" >>>> role for us in the IETF directly. >>>> >>>> Joe >>>> >>>>> >>>>> http://www.iana.org/assignments/service-names-port-numbers/service-names >>>>> -port-numbers.xhtml >>>>> >>>>> is not explicit >>>>> >>>>> Regards, Benoit (OPS AD) >>>> . >>>> >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >>> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From nobody Thu Mar 6 02:52:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 260AD1A0260 for ; Thu, 6 Mar 2014 02:52:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5S9S21Qg8v1h for ; Thu, 6 Mar 2014 02:52:12 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 42B971A0252 for ; Thu, 6 Mar 2014 02:52:11 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s26Aq4s9029133 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 11:52:04 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s26Aq3xo024695 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 11:52:03 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 11:52:03 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" , Benoit Claise Thread-Topic: Summary of the Netconf Session at IETF #89 Thread-Index: Ac7bZqFUoHi+yGZLT/ubQKOgn5pofBdvQV1Q Date: Thu, 6 Mar 2014 10:52:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.120] Content-Type: multipart/mixed; boundary="_004_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 16588 X-purgate-ID: 151667::1394103124-000059EE-0E9BE030/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wAc9ntUQWlev0hziCoeuHIyB-QA Subject: [Netconf] Summary of the Netconf Session at IETF #89 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 10:52:18 -0000 --_004_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_ Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_" --_000_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Benoit, NETCONF WG, below is a summary and action items from the NETCONF WG session on March 3,= 2014, London, England. A short version of this summary is also available at: http://trac.tools.iet= f.org/area/ops/trac/wiki/IETF89summary - We had approx. 75 participants in the 2 hour NETCONF session, - We reviewed the status of the WG, - We had a discussion on all 6 chartered documents. - Note takers were: Lada Lhotka and Dan Romascanu. The Jabber scribe was Be= nno Overeinder. Many thanks for volunteering. The session agenda is available at: http://www.ietf.org/proceedings/89/agen= da/agenda-89-netconf Reverse Secure Shell (Reverse SSH) http://www.ietf.org/proceedings/89/slides/slides-89-netconf-0.pptx The draft is ready for WGLC. The WGLC will be started with April 1st as dea= dline. NETCONF Over TLS update - RFC 5539bis http://www.ietf.org/proceedings/89/slides/slides-89-netconf-1.pdf The draft is ready for WGLC. The WGLC will be started with April 1st as dea= dline. A YANG Data Model for NETCONF Server Configuration http://www.ietf.org/proceedings/89/slides/slides-89-netconf-4.pptx Issue discussion showed that a new revision is needed. The document will be= submitted as WG document and be named as draft-ietf-netconf-server-model. Kent will explain in security considerations section, which objects are sen= sitive to attacks (see e.g. example text in draft-ietf-netmod-system-mgmt). RESTCONF Protocol http://www.ietf.org/proceedings/89/slides/slides-89-netconf-2.pdf Following the long issue discussion a new revision is needed. The draft wil= l be submitted as WG document. YANG Patch Media Type http://www.ietf.org/proceedings/89/slides/slides-89-netconf-3.pdf Andy will pickup results from discussion and submit a new revision as WG do= cument. Zero Touch Provisioning for NETCONF Call Home http://www.ietf.org/proceedings/89/slides/slides-89-netconf-5.pptx Kent will incorporate the results of the discussion and submit a new revisi= on as WG document. AOB Status of pending drafts: - draft-bierman-netconf-efficiency-extensions - draft-varga-netconf-exi-capability - draft-fa-netconf-dhcpv6-option - draft-mm-netconf-time-capability This part had to be skipped. However the co-chairs would like to recommend = to submit a revision and stimulate a discussion on the maillist, if the aut= hors want to follow up. Others on the maillist are also welcome to stimulate discussion if they bel= ieve this is worth pursuing in the WG. Mehmet & Bert --_000_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Benoit, NETCONF WG,

 

below is a summary and action items fro= m the NETCONF WG session on March 3, 2014, London, England.

A short version of this summary is also available at: <= a href=3D"http://trac.tools.ietf.org/area/ops/trac/wiki/IETF89summary"> http://trac.tools.ietf.org/area/ops/trac/wiki/IETF89summary =

 

- We had approx. 75 participants in the= 2 hour NETCONF session,

- We reviewed the status of the WG,

- We had a discussion on all 6 chartered documents.

- Note takers were: Lada Lhotka and Dan= Romascanu. The Jabber scribe was Benno Overeinder.

Many thanks for volunteering.

 

The session agenda is available at: http://www.ietf.org/proceedings/89/agenda/agenda= -89-netconf  

The draft is ready for WGLC. The WGLC w= ill be started with April 1st as deadline.

A YANG Data Model for NETCONF Server Configuration

http://www.ietf.org/p= roceedings/89/slides/slides-89-netconf-4.pptx

Issue discussion showed that a new revision is ne= eded. The document will be submitted as WG document and be named as draft-i= etf-netconf-server-model.

Kent will explain in security considerations sect= ion, which objects are sensitive to attacks (see e.g. example text in draft= -ietf-netmod-system-mgmt).

 <= /p>

Following the long issue discussion a new revisio= n is needed. The draft will be submitted as WG document.

 

YANG Patch Media=
 Type

http://www.ietf.org/pr= oceedings/89/slides/slides-89-netconf-3.pdf

Andy will pickup results from discussion and subm= it a new revision as WG document.

 

Zero Touch Provi=
sioning for NETCONF Call Home

http://www.ietf.org/proceedings/89/slides/sli= des-89-netconf-5.pptx

Kent will incorporate the results of the discussi= on and submit a new revision as WG document.

 

AOB

Status of pending drafts:

- draft-bierman-netconf-efficiency-extensions

- draft-varga-netconf-exi-capability

- draft-fa-netconf-dhcpv6-option

- draft-mm-netconf-time-capability

This part had to be skipped. However the co-chair= s would like to recommend to submit a revision and stimulate a discussion o= n the maillist, if the authors want to follow up.

Others on the maillist are also welcome to stimul= ate discussion if they believe this is worth pursuing in the WG.=

 

Mehmet & Bert

 <= /p>

--_000_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_-- --_004_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=136; creation-date="Thu, 07 Nov 2013 03:08:45 GMT"; modification-date="Thu, 07 Nov 2013 03:08:45 GMT" Content-ID: <60B839157199724EAF948BA6DAD1F4B4@internal.nsn.com> Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL25ldGNvbmYNCg== --_004_E4DE949E6CE3E34993A2FF8AE79131F82A2219DEMUMBX005nsnintr_-- From nobody Thu Mar 6 03:45:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EE091A023E for ; Thu, 6 Mar 2014 03:45:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tQKLXjnJxb8U for ; Thu, 6 Mar 2014 03:45:49 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 161381A02A7 for ; Thu, 6 Mar 2014 03:45:46 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s26BjdU6018826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 6 Mar 2014 12:45:40 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s26BjdSD006756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Mar 2014 12:45:39 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Mar 2014 12:45:38 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 12:45:38 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "ext Bert Wijnen (IETF)" , Joe Touch , Kent Watsen , netconf Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPOSktSnx7mHcrKEuFWBsKlVApO5rT73yA Date: Thu, 6 Mar 2014 11:45:38 +0000 Message-ID: References: <52DD39AC.5070303@cisco.com> <530C7F17.1000500@bwijnen.net> <531666A5.7070102@isi.edu> <531851C4.5060500@bwijnen.net> In-Reply-To: <531851C4.5060500@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.120] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5942 X-purgate-ID: 151667::1394106340-00004D48-39CF22E8/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zuoMEDvvD_ajhLcCCybZJ8G1EYw Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 11:45:52 -0000 Mehmet supports as the other co-chair. As a matter of fact we see this discussion as concluded! Cheers,=20 Mehmet=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of ext Bert > Wijnen (IETF) > Sent: Thursday, March 06, 2014 11:45 AM > To: Joe Touch; Kent Watsen; netconf > Subject: Re: [Netconf] NETCONF call home and new port assignment >=20 > Joe, it does not help if you try to re-open the discussion. > We have had the discussion The WG has concluded they want to ask for a > new port, > We have asked our AD to check with the IESG if this is acceptable, and > our (WG chairs) > understanding is that IF we as a WG want to ask for a port, we can do > so. >=20 > Bert speaking as co-chair. >=20 > On 04/03/14 23:49, Joe Touch wrote: > > A well designed protocol needs one port. > > > > What's the rationale for so many variants of the same service, and > what happens if both run on the same machine and collide? (i.e., > > two independent ports could mean independent two servers). > > > > Joe > > > > On 2/25/2014 7:41 AM, Kent Watsen wrote: > >> > >> I believe that is the case as well, but note that we need two port > >> assignments - one for reverse-SSH and another for reverse-TLS. > >> > >> Cheers! > >> Kent > >> > >> > >> > >> On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" > wrote: > >> > >>> NETCONF WG participants, > >>> > >>> there has been quite some discussion about this topic on our > mailing list. > >>> We (WG chairs) have asked our AD (Benoit) to follow up in the IESG. > >>> > >>> Our current understanding is that if our WG has consensus on asking > for > >>> a new port, then we can do so and we should get one. > >>> > >>> We (WG chairs) belive we have (at least rough) consensus on this > matter > >>> and so we will ask for a new port. > >>> > >>> Bert and Mehmet > >>> > >>> > >>> -------- Original Message -------- > >>> Subject: Re: NETCONF call home and new port assignment > >>> Resent-To: bertietf@bwijnen.net, mehmet.ersue@nsn.com,, > >>> bclaise@cisco.com, joelja@bogus.com, jjaeggli@zynga.com > >>> Date: Mon, 20 Jan 2014 15:58:52 +0100 > >>> From: Benoit Claise > >>> CC: Joe Touch , "netconf- > chairs@tools.ietf.org" > >>> , "Romascanu, Dan (Dan)" > >>> , Lemon Ted , > >>> "ops-ads@tools.ietf.org" , > >>> Kent Watsen > >>> > >>> Dear all, > >>> > >>> We discussed the issue of potentially allocating a new port for the > >>> NETCONF call home during our informal telechat last week. > >>> Personally, I wanted a confirmation on the procedure. > >>> Material: > >>> http://www.iana.org/assignments/service-names-port-numbers/service- > names-p > >>> ort-numbers.xhtml > >>> an > >>> RFC 6335 > >>> > >>> Bottom line: The review of the port assignment via IETF standards > >>> (consensus based) does not go to the port review > >>> > >>> There is strong consensus to allocate this port in the NETCONF WG. > >>> - http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf > >>> 30 in favor, 0 against > >>> - doublechecked on the mailing list > >>> http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html > >>> > >>> So we're good here, let's proceed with the new port design > >>> > >>> Regards, Benoit > >>> > >>>> Hi, Benoit, > >>>> > >>>> On 11/4/2013 10:30 AM, Benoit Claise wrote: > >>>>> Hi Joe, > >>>>> > >>>>> Regarding the "NETCONF call home and new port assignment" > discussion on > >>>>> the NETCONF mailer, I'm wondering if your comments are made as > the port > >>>>> expert reviewer or as a contributor. > >>>> > >>>> The ports review team doesn't participate in that role on these > >>>> discussions on the lists; we review requests and report directly > to > >>>> IANA. So I'm speaking as a contributor, but it's with the ports > review > >>>> in the back of my mind. > >>>> > >>>>> In the NETCONF WG, there is strong consensus that the new port is > the > >>>>> preferred way. We checked that today: by a show of hand, > everybody > >>>>> wanted a new port. > >>>> > >>>> Everyone always does. > >>>> > >>>>> I want to understand if there is a major flaw in requesting this > port. > >>>> > >>>> There's often a case where the individual request makes sense, but > in > >>>> the broader context of "tragedy of the commons" it doesn't. That's > my > >>>> impression here. There should be other ways to accomplish this - > the > >>>> SYN attempt I recently saw looked like a good alternative that > would > >>>> scale to other assignments, e.g. > >>>> > >>>>> Note: I contacted it you directly, because I'm not sure how to > reach > >>>>> all > >>>>> the expert reviewers at the same time. > >>>> > >>>> There's no official way to do that. We respond to requests for > reviews > >>>> from IANA, and report back to IANA directly. There's no "official" > >>>> role for us in the IETF directly. > >>>> > >>>> Joe > >>>> > >>>>> > >>>>> http://www.iana.org/assignments/service-names-port- > numbers/service-names > >>>>> -port-numbers.xhtml > >>>>> > >>>>> is not explicit > >>>>> > >>>>> Regards, Benoit (OPS AD) > >>>> . > >>>> > >>> > >>> > >>> > >>> > >>> _______________________________________________ > >>> Netconf mailing list > >>> Netconf@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netconf > >>> > >>> > >> > >> > >> _______________________________________________ > >> Netconf mailing list > >> Netconf@ietf.org > >> https://www.ietf.org/mailman/listinfo/netconf > >> > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 6 06:22:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF92C1A039A for ; Thu, 6 Mar 2014 06:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ibQDT-NJUg6s for ; Thu, 6 Mar 2014 06:22:42 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 936A61A0388 for ; Thu, 6 Mar 2014 06:22:29 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s26EMOrJ015377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 6 Mar 2014 15:22:24 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s26EMO4d003881 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 6 Mar 2014 15:22:24 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC003.nsn-intra.net (10.159.42.34) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 6 Mar 2014 15:22:23 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Thu, 6 Mar 2014 15:22:23 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: YANG Patch Optional or Mandatory Thread-Index: Ac85R3x2hs2pdNeiQoOvg0oaOcp59Q== Date: Thu, 6 Mar 2014 14:22:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.111] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F82A297BDEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 2151 X-purgate-ID: 151667::1394115744-00004D48-8E929030/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YFomwh-qqaoVxx9LncPhxLqyjGU Subject: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:22:44 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F82A297BDEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, there was a discussion in the IETF #89 NETCONF session on whether YANG patc= h for the RESTCONF protocol should be optional or mandatory. Although we heard different opinions there was no final conclusion. The chairs would like to raise this discussion again to come to an agreemen= t for the way forward. Please state your opinion with pro and contra. Thanks, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F82A297BDEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
there was a discussion in the IETF #89 NETCONF= session on whether YANG patch for the RESTCONF protocol should be optional= or mandatory.
Although we heard different opinions there was= no final conclusion.
 
The chairs would like to raise this discussion= again to come to an agreement for the way forward.
Please state your opinion with pro and contra.=
 
Thanks,
Mehmet
 
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F82A297BDEMUMBX005nsnintr_-- From nobody Thu Mar 6 06:36:05 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD4E21A0137 for ; Thu, 6 Mar 2014 06:36:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Wn7g2d9xwan for ; Thu, 6 Mar 2014 06:35:58 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4FD351A03B4 for ; Thu, 6 Mar 2014 06:35:58 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ADC6F1DA9; Thu, 6 Mar 2014 15:35:53 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id hlG0yKAPQ46J; Thu, 6 Mar 2014 15:35:52 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 15:35:52 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E1E5B2002F; Thu, 6 Mar 2014 15:35:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id TuUkIbpgfbGA; Thu, 6 Mar 2014 15:35:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 49F1420017; Thu, 6 Mar 2014 15:35:51 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 35F202B982E8; Thu, 6 Mar 2014 15:35:50 +0100 (CET) Date: Thu, 6 Mar 2014 15:35:50 +0100 From: Juergen Schoenwaelder To: "Ersue, Mehmet (NSN - DE/Munich)" Message-ID: <20140306143550.GF34026@elstar.local> Mail-Followup-To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3SQKqtdJwmN2NB1z7Jag0wazLMY Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:36:01 -0000 On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > there was a discussion in the IETF #89 NETCONF session on whether YANG patch for the RESTCONF protocol should be optional or mandatory. > Although we heard different opinions there was no final conclusion. > > The chairs would like to raise this discussion again to come to an agreement for the way forward. > Please state your opinion with pro and contra. > I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My first question is this YANG module only for RESTCONF or is the idea that NETCONF servers also implement this patch operation. The introduction is not quite clear, it says things such as "A new RPC operation can be defined to utilize YANG Patch in the NETCONF protocol.". There is text further down in the document how it would work with NETCONF but then I again read "For NETCONF, a YANG "rpc" statement must be defined.". I like to understand where we are heading regarding editing primitives in both NETCONF and RESTCONF. (Sorry that I am not really addressing your question whether this should be mandatory for RESTCONF.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Mar 6 06:57:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CF21A00DD for ; Thu, 6 Mar 2014 06:57:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9JVVHiipxvp for ; Thu, 6 Mar 2014 06:57:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A80F01A0083 for ; Thu, 6 Mar 2014 06:57:38 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 6449D38400D; Thu, 6 Mar 2014 15:57:34 +0100 (CET) Date: Thu, 06 Mar 2014 15:57:33 +0100 (CET) Message-Id: <20140306.155733.448892151.mbj@tail-f.com> To: mehmet.ersue@nsn.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/d6PnmBK0P6MH8P4WC0aDO60b-ZU Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 14:57:39 -0000 "Ersue, Mehmet (NSN - DE/Munich)" wrote: > Dear NETCONF WG, > > there was a discussion in the IETF #89 NETCONF session on whether YANG patch > for the RESTCONF protocol should be optional or mandatory. > Although we heard different opinions there was no final conclusion. > > The chairs would like to raise this discussion again to come to an agreement > for the way forward. > Please state your opinion with pro and contra. I strongly believe that *some* mechanism to CRUD all YANG-defined resources MUST be mandatory. Whether it is YANG Patch or something else I don't know. For example, it is not clear to me why we should have different edit-formats for NETCONF and RESTCONF. Since the edit-config format seems to work for NETCONF, it must be clarified why it doesn't work for RESTCONF. /martin From nobody Thu Mar 6 07:02:35 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF3051A018D for ; Thu, 6 Mar 2014 07:02:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o6I1X62b-sYW for ; Thu, 6 Mar 2014 07:02:31 -0800 (PST) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) by ietfa.amsl.com (Postfix) with ESMTP id 064891A017E for ; Thu, 6 Mar 2014 07:02:29 -0800 (PST) Received: by mail-qc0-f181.google.com with SMTP id e9so2928931qcy.26 for ; Thu, 06 Mar 2014 07:02:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=SNrEVxJc5+Lqzv7l5A2sMX3nU6cnWUX35dTupZnQsQQ=; b=A3dkG9xoNunrOt+7V16WRHxLrRKVdDa0PfW0YM4mX+fnno+MWws7sfIwDuTDowe/wW S4mn5dTA/uTtwtz2ShplX3GVG9WZnqKdskH9I+6R6sZ0KZGCqGgAx3I2WPHcU2Wnb1Yz SGz/mjRd0q2AuO22n54e/NpOM2xrV1T+DFlqOUQHkNKr173AgWFX/1dzj0l6ETEP8h+0 13mYrTgolcmDLqmDpcEsF+hvapYoLB8VXGfLu7Sn/PYQiU4aJy9V8S1HVz5KRZw+SUrx DUE6QXJbTuiwJxRpOw6Z13zZVXTzDsyMEet6VL5yqWGCMVNsPPx6ZGOY8XVNt9p66Hjt TwVw== X-Gm-Message-State: ALoCoQl28QzGRtNRm4SiGbprAi28u8w0m/vZktILIwQlAW0GF01e7DzAAuyxsPfw0ntD1ku5hSfF MIME-Version: 1.0 X-Received: by 10.224.36.129 with SMTP id t1mr14361847qad.88.1394118145915; Thu, 06 Mar 2014 07:02:25 -0800 (PST) Received: by 10.140.104.194 with HTTP; Thu, 6 Mar 2014 07:02:25 -0800 (PST) In-Reply-To: <20140306143550.GF34026@elstar.local> References: <20140306143550.GF34026@elstar.local> Date: Thu, 6 Mar 2014 07:02:25 -0800 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" , netconf Content-Type: multipart/alternative; boundary=089e0158a9e4dceecf04f3f16c0a Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NcdPLg_rQK4lnGMBOK6cxsCfkI4 Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:02:33 -0000 --089e0158a9e4dceecf04f3f16c0a Content-Type: text/plain; charset=ISO-8859-1 Hi, It is designed to be used in NETCONF and RESTCONF. The operation in draft-bierman-netconf-efficiency-extensions-00 uses it. As for YANG Patch being mandatory... Martin convinced be it needs to be mandatory or removed. The ability to change the appropriate data in 1 request is critical. How it is done is not. Andy On Thursday, March 6, 2014, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) > wrote: > > Dear NETCONF WG, > > > > there was a discussion in the IETF #89 NETCONF session on whether YANG > patch for the RESTCONF protocol should be optional or mandatory. > > Although we heard different opinions there was no final conclusion. > > > > The chairs would like to raise this discussion again to come to an > agreement for the way forward. > > Please state your opinion with pro and contra. > > > > I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My > first question is this YANG module only for RESTCONF or is the idea > that NETCONF servers also implement this patch operation. The > introduction is not quite clear, it says things such as "A new RPC > operation can be defined to utilize YANG Patch in the NETCONF > protocol.". There is text further down in the document how it would > work with NETCONF but then I again read "For NETCONF, a YANG "rpc" > statement must be defined.". I like to understand where we are heading > regarding editing primitives in both NETCONF and RESTCONF. (Sorry that > I am not really addressing your question whether this should be > mandatory for RESTCONF.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --089e0158a9e4dceecf04f3f16c0a Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi,

It is designed to be used in NETCONF and RESTCONF.
The <edit2> operation in draft-bierman-netconf-efficiency-ex= tensions-00
uses it.

As for YANG Patch b= eing mandatory...
Martin convinced be it needs to be mandatory or removed.
The= ability to change the appropriate data in 1 request is critical.
How it is done is not.


Andy


On Thursday, March 6, 2014, Juergen Schoenwaelder <j.schoenwaelder@jacobs-uni= versity.de> wrote:
On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) w= rote:
> Dear NETCONF WG,
>
> there was a discussion in the IETF #89 NETCONF session on whether YANG= patch for the RESTCONF protocol should be optional or mandatory.
> Although we heard different opinions there was no final conclusion. >
> The chairs would like to raise this discussion again to come to an agr= eement for the way forward.
> Please state your opinion with pro and contra.
>

I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My
first question is this YANG module only for RESTCONF or is the idea
that NETCONF servers also implement this patch operation. The
introduction is not quite clear, it says things such as "A new RPC
operation can be defined to utilize YANG Patch in the NETCONF
protocol.". There is text further down in the document how it would work with NETCONF but then I again read "For NETCONF, a YANG "rpc= "
statement must be defined.". I like to understand where we are heading=
regarding editing primitives in both NETCONF and RESTCONF. (Sorry that
I am not really addressing your question whether this should be
mandatory for RESTCONF.)

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--089e0158a9e4dceecf04f3f16c0a-- From nobody Thu Mar 6 07:40:15 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1BAF1A00A2 for ; Thu, 6 Mar 2014 07:40:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id doUmyC-Hz67d for ; Thu, 6 Mar 2014 07:40:03 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 3F3D01A0168 for ; Thu, 6 Mar 2014 07:40:03 -0800 (PST) Received: from [192.168.1.94] (pool-71-105-87-112.lsanca.dsl-w.verizon.net [71.105.87.112]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id s26FdXvs011920 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 6 Mar 2014 07:39:37 -0800 (PST) References: <52DD39AC.5070303@cisco.com> <530C7F17.1000500@bwijnen.net> <531666A5.7070102@isi.edu> <531851C4.5060500@bwijnen.net> In-Reply-To: <531851C4.5060500@bwijnen.net> Mime-Version: 1.0 (1.0) Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Message-Id: X-Mailer: iPad Mail (11B651) From: Joe Touch Date: Thu, 6 Mar 2014 07:39:34 -0800 To: "Bert Wijnen (IETF)" X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iqiQmFsEcwhw3ibtyvV2YwXk-YE Cc: netconf Subject: Re: [Netconf] NETCONF call home and new port assignment X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:40:07 -0000 > On Mar 6, 2014, at 2:45 AM, "Bert Wijnen (IETF)" wr= ote: >=20 > Joe, it does not help if you try to re-open the discussion. > We have had the discussion The WG has concluded they want to ask for a new= port, That one new port has now doubled to two. That is a new issue.=20 Joe > We have asked our AD to check with the IESG if this is acceptable, and our= (WG chairs) > understanding is that IF we as a WG want to ask for a port, we can do so. >=20 > Bert speaking as co-chair. >=20 >> On 04/03/14 23:49, Joe Touch wrote: >> A well designed protocol needs one port. >>=20 >> What's the rationale for so many variants of the same service, and what h= appens if both run on the same machine and collide? (i.e., >> two independent ports could mean independent two servers). >>=20 >> Joe >>=20 >>> On 2/25/2014 7:41 AM, Kent Watsen wrote: >>>=20 >>> I believe that is the case as well, but note that we need two port >>> assignments - one for reverse-SSH and another for reverse-TLS. >>>=20 >>> Cheers! >>> Kent >>>=20 >>>=20 >>>=20 >>>> On 2/25/14 6:31 AM, "Bert Wijnen (IETF)" wrote: >>>>=20 >>>> NETCONF WG participants, >>>>=20 >>>> there has been quite some discussion about this topic on our mailing li= st. >>>> We (WG chairs) have asked our AD (Benoit) to follow up in the IESG. >>>>=20 >>>> Our current understanding is that if our WG has consensus on asking for= >>>> a new port, then we can do so and we should get one. >>>>=20 >>>> We (WG chairs) belive we have (at least rough) consensus on this matter= >>>> and so we will ask for a new port. >>>>=20 >>>> Bert and Mehmet >>>>=20 >>>>=20 >>>> -------- Original Message -------- >>>> Subject: Re: NETCONF call home and new port assignment >>>> Resent-To: bertietf@bwijnen.net, mehmet.ersue@nsn.com,, >>>> bclaise@cisco.com, joelja@bogus.com, jjaeggli@zynga.com >>>> Date: Mon, 20 Jan 2014 15:58:52 +0100 >>>> From: Benoit Claise >>>> CC: Joe Touch , "netconf-chairs@tools.ietf.org" >>>> , "Romascanu, Dan (Dan)" >>>> , Lemon Ted , >>>> "ops-ads@tools.ietf.org" , >>>> Kent Watsen >>>>=20 >>>> Dear all, >>>>=20 >>>> We discussed the issue of potentially allocating a new port for the >>>> NETCONF call home during our informal telechat last week. >>>> Personally, I wanted a confirmation on the procedure. >>>> Material: >>>> http://www.iana.org/assignments/service-names-port-numbers/service-name= s-p >>>> ort-numbers.xhtml >>>> an >>>> RFC 6335 >>>>=20 >>>> Bottom line: The review of the port assignment via IETF standards >>>> (consensus based) does not go to the port review >>>>=20 >>>> There is strong consensus to allocate this port in the NETCONF WG. >>>> - http://www.ietf.org/proceedings/88/minutes/minutes-88-netconf >>>> 30 in favor, 0 against >>>> - doublechecked on the mailing list >>>> http://www.ietf.org/mail-archive/web/netconf/current/msg08445.html >>>>=20 >>>> So we're good here, let's proceed with the new port design >>>>=20 >>>> Regards, Benoit >>>>=20 >>>>> Hi, Benoit, >>>>>=20 >>>>>> On 11/4/2013 10:30 AM, Benoit Claise wrote: >>>>>> Hi Joe, >>>>>>=20 >>>>>> Regarding the "NETCONF call home and new port assignment" discussion o= n >>>>>> the NETCONF mailer, I'm wondering if your comments are made as the po= rt >>>>>> expert reviewer or as a contributor. >>>>>=20 >>>>> The ports review team doesn't participate in that role on these >>>>> discussions on the lists; we review requests and report directly to >>>>> IANA. So I'm speaking as a contributor, but it's with the ports review= >>>>> in the back of my mind. >>>>>=20 >>>>>> In the NETCONF WG, there is strong consensus that the new port is the= >>>>>> preferred way. We checked that today: by a show of hand, everybody >>>>>> wanted a new port. >>>>>=20 >>>>> Everyone always does. >>>>>=20 >>>>>> I want to understand if there is a major flaw in requesting this port= . >>>>>=20 >>>>> There's often a case where the individual request makes sense, but in >>>>> the broader context of "tragedy of the commons" it doesn't. That's my >>>>> impression here. There should be other ways to accomplish this - the >>>>> SYN attempt I recently saw looked like a good alternative that would >>>>> scale to other assignments, e.g. >>>>>=20 >>>>>> Note: I contacted it you directly, because I'm not sure how to reach >>>>>> all >>>>>> the expert reviewers at the same time. >>>>>=20 >>>>> There's no official way to do that. We respond to requests for reviews= >>>>> from IANA, and report back to IANA directly. There's no "official" >>>>> role for us in the IETF directly. >>>>>=20 >>>>> Joe >>>>>=20 >>>>>>=20 >>>>>> http://www.iana.org/assignments/service-names-port-numbers/service-na= mes >>>>>> -port-numbers.xhtml >>>>>>=20 >>>>>> is not explicit >>>>>>=20 >>>>>> Regards, Benoit (OPS AD) >>>>> . >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>=20 >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>=20 From nobody Thu Mar 6 07:48:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 286501A01B9 for ; Thu, 6 Mar 2014 07:48:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Dxg6pzPvZqgS for ; Thu, 6 Mar 2014 07:47:58 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 1C6041A01C2 for ; Thu, 6 Mar 2014 07:47:57 -0800 (PST) Received: from mail14-am1-R.bigfish.com (10.3.201.238) by AM1EHSOBE008.bigfish.com (10.3.204.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 15:47:52 +0000 Received: from mail14-am1 (localhost [127.0.0.1]) by mail14-am1-R.bigfish.com (Postfix) with ESMTP id A13A3340417; Thu, 6 Mar 2014 15:47:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -22 X-BigFish: VPS-22(zz9371I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail14-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(164054003)(199002)(189002)(56816005)(83506001)(69226001)(90146001)(97336001)(81542001)(92566001)(92726001)(86362001)(95666003)(81342001)(74876001)(93136001)(94946001)(81816001)(2656002)(83072002)(85852003)(74706001)(87266001)(74366001)(87936001)(85306002)(81686001)(63696002)(80976001)(80022001)(79102001)(77982001)(50986001)(47976001)(47736001)(54316002)(56776001)(76482001)(95416001)(4396001)(49866001)(53806001)(54356001)(19580405001)(83322001)(19580395003)(46102001)(51856001)(47446002)(74502001)(66066001)(31966008)(65816001)(94316002)(59766001)(93516002)(74662001)(97186001)(76796001)(76786001)(77096001)(76176001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB774; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:3C90D564.BDF29DC7.58F17F7B.86E2BDBB.202B0; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail14-am1 (localhost.localdomain [127.0.0.1]) by mail14-am1 (MessageSwitch) id 139412087133658_23284; Thu, 6 Mar 2014 15:47:51 +0000 (UTC) Received: from AM1EHSMHS016.bigfish.com (unknown [10.3.201.237]) by mail14-am1.bigfish.com (Postfix) with ESMTP id EDE3B20161; Thu, 6 Mar 2014 15:47:50 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS016.bigfish.com (10.3.207.154) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 15:47:48 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 15:47:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 15:47:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0883.010; Thu, 6 Mar 2014 15:47:37 +0000 From: Kent Watsen To: "Ersue, Mehmet (NSN - DE/Munich)" , netconf Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59Q== Date: Thu, 6 Mar 2014 15:47:37 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZF82xfbQozSieClKuimxZEPmRI0 Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:48:00 -0000 For RESTCONF, I think YANG-Patch SHOULD be supported. Why less than "MUST": 1. The PATCH operation is optional in HTTP. To require YANG-Patch would also=20 require support for said operation. 2. The PATCH operation only trades-off network bandwidth for server-processing. Thus it is just a nice-to-have (PUT could be used instead) 3. The afore-mentioned additional server-processing may not be acceptable for resource-constrained devices, one of the purported targets for RESTCONF. Why more than "MAY": 1. For large documents, the tradeoff mentioned above is easily worth-it 2. Inspecting a PATCH document easily conveys intent, useful for auditing and troubleshooting That said, I would be ok with the following statement: The RESTCONF server MAY implement the PATCH operation. If a RESTCONF server supports the PATCH operation, it MUST at least support YANG-Patch for all resources having Content-Type "application/yang.data+xml" or "application/yang.data+json". In order for RESTCONF clients to discover if a server supports the PATCH operation and which PATCH formats are supported, RESTCONF servers SHOULD return the "Accept-Patch" HTTP header, As specified in RFC 5789. =20 Thanks, Kent From: , "Mehmet (NSN - DE/Munich)" Date: Thursday, March 6, 2014 2:22 PM To: NetConf Subject: [Netconf] YANG Patch Optional or Mandatory Dear NETCONF WG, =20 there was a discussion in the IETF #89 NETCONF session on whether YANG patch for the RESTCONF protocol should be optional or mandatory. Although we heard different opinions there was no final conclusion. =20 The chairs would like to raise this discussion again to come to an agreement for the way forward. Please state your opinion with pro and contra. =20 Thanks, Mehmet=20 =20 =20 =20 From nobody Thu Mar 6 07:51:41 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D721A00BA for ; Thu, 6 Mar 2014 07:51:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RVUe1lbF44DB for ; Thu, 6 Mar 2014 07:51:37 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe005.messaging.microsoft.com [213.199.154.208]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC111A0048 for ; Thu, 6 Mar 2014 07:51:37 -0800 (PST) Received: from mail44-am1-R.bigfish.com (10.3.201.237) by AM1EHSOBE002.bigfish.com (10.3.204.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 15:51:32 +0000 Received: from mail44-am1 (localhost [127.0.0.1]) by mail44-am1-R.bigfish.com (Postfix) with ESMTP id A08ED360405; Thu, 6 Mar 2014 15:51:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -24 X-BigFish: VPS-24(zz98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail44-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(164054003)(51704005)(199002)(24454002)(377454003)(77982001)(59766001)(31966008)(86362001)(95416001)(74502001)(87266001)(79102001)(47446002)(74662001)(92566001)(94316002)(92726001)(97186001)(97336001)(85306002)(80022001)(94946001)(83506001)(81816001)(81342001)(74876001)(93516002)(63696002)(76796001)(46102001)(85852003)(47976001)(77096001)(93136001)(76786001)(36756003)(19580395003)(69226001)(80976001)(47736001)(49866001)(81686001)(74706001)(87936001)(2656002)(15975445006)(95666003)(90146001)(83322001)(66066001)(56776001)(50986001)(74366001)(65816001)(54316002)(81542001)(54356001)(51856001)(83072002)(4396001)(56816005)(76482001)(19580405001)(53806001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB772; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:BCA4F174.A0109418.39D77D7B.D2E2D169.20348; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail44-am1 (localhost.localdomain [127.0.0.1]) by mail44-am1 (MessageSwitch) id 13941210914464_8252; Thu, 6 Mar 2014 15:51:31 +0000 (UTC) Received: from AM1EHSMHS017.bigfish.com (unknown [10.3.201.236]) by mail44-am1.bigfish.com (Postfix) with ESMTP id F17FE30009C; Thu, 6 Mar 2014 15:51:30 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS017.bigfish.com (10.3.207.155) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 15:51:30 +0000 Received: from BLUPR05MB772.namprd05.prod.outlook.com (10.141.209.27) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 15:51:24 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB772.namprd05.prod.outlook.com (10.141.209.27) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 15:51:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0883.010; Thu, 6 Mar 2014 15:51:21 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" , netconf Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: Ac85R3x2hs2pdNeiQoOvg0oaOcp59QAAeIoAAADtrYAAAbUzgA== Date: Thu, 6 Mar 2014 15:51:21 +0000 Message-ID: References: <20140306143550.GF34026@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: text/plain; charset="us-ascii" Content-ID: <8A3A1650CAA70C4FB506B85213799779@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bB4jSqMwsuncmgqviGok3LmJgLI Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:51:40 -0000 > Martin convinced be it needs to be mandatory or removed. > The ability to change the appropriate data in 1 request is critical. I agree that being able to have all updates in a single request is critical, but can't a RESTCONF client PUT the entire configuration in one request and achieve this too? Thanks, Kent From: Andy Bierman Date: Thursday, March 6, 2014 3:02 PM To: Juergen Schoenwaelder , "Ersue, Mehmet (NSN - DE/Munich)" , NetConf Subject: Re: [Netconf] YANG Patch Optional or Mandatory Hi, It is designed to be used in NETCONF and RESTCONF. The operation in draft-bierman-netconf-efficiency-extensions-00 uses it. As for YANG Patch being mandatory... Martin convinced be it needs to be mandatory or removed. The ability to change the appropriate data in 1 request is critical. How it is done is not. Andy On Thursday, March 6, 2014, Juergen Schoenwaelder wrote: On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote: > Dear NETCONF WG, > > there was a discussion in the IETF #89 NETCONF session on whether YANG >patch for the RESTCONF protocol should be optional or mandatory. > Although we heard different opinions there was no final conclusion. > > The chairs would like to raise this discussion again to come to an >agreement for the way forward. > Please state your opinion with pro and contra. > I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My first question is this YANG module only for RESTCONF or is the idea that NETCONF servers also implement this patch operation. The introduction is not quite clear, it says things such as "A new RPC operation can be defined to utilize YANG Patch in the NETCONF protocol.". There is text further down in the document how it would work with NETCONF but then I again read "For NETCONF, a YANG "rpc" statement must be defined.". I like to understand where we are heading regarding editing primitives in both NETCONF and RESTCONF. (Sorry that I am not really addressing your question whether this should be mandatory for RESTCONF.) /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 6 07:59:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B54891A023E for ; Thu, 6 Mar 2014 07:59:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYwLF5PXVom7 for ; Thu, 6 Mar 2014 07:59:53 -0800 (PST) Received: from mail-qc0-f178.google.com (mail-qc0-f178.google.com [209.85.216.178]) by ietfa.amsl.com (Postfix) with ESMTP id 4EBB81A01F8 for ; Thu, 6 Mar 2014 07:59:53 -0800 (PST) Received: by mail-qc0-f178.google.com with SMTP id i8so3072350qcq.23 for ; Thu, 06 Mar 2014 07:59:49 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=grmi9QhJnY8I1U8rNBS/Jfvr2cYbDtLEJvobtQzNeA0=; b=GhvfWsuxA0GbDuJmFuEqTku/6qlyjB/GTwHY4q3NvzvOcOSlNhG5duX/mp5FdBz5XQ 4ff+bn5bUADhebxLtLOXP/S9Hme9x9AXkz0cEu3UVcWU92mo0yNYX4lad2mcfK4xdeRn knhr315kJayU7yBxtQ816XAIfu+SY0vn0ZJX9kJ0bwvFlbzEYORkpkQomMMXru5FX/1k OQnRCl82Wc8M42JrrZLwbFiQmhpgdFfXZtDSOLUmOHRUOqL/6J1psEzYuvfr3TXQ/ecO RItwOGjGfnba4H9anfQJq8TxcXT0a2mCOuNiDta1YpsxHGR3PaCOnPNz1dpJNcyhMUsh nEqA== X-Gm-Message-State: ALoCoQmOA+mKcQPwroKdhBjPzXhioa4UHqlGhpUOMo+DJP91OUFGUHp8y5QVc2hK0m/d9R1bSwLK MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr8693474qcu.2.1394121589060; Thu, 06 Mar 2014 07:59:49 -0800 (PST) Received: by 10.140.104.194 with HTTP; Thu, 6 Mar 2014 07:59:48 -0800 (PST) In-Reply-To: References: Date: Thu, 6 Mar 2014 07:59:49 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c3e4541725c704f3f23a42 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IkPr3aXB3q9inQ0ohSJ4RQRvoZI Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 15:59:56 -0000 --001a11c3e4541725c704f3f23a42 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, March 6, 2014, Kent Watsen wrote: > > For RESTCONF, I think YANG-Patch SHOULD be supported. > > > Why less than "MUST": > > 1. The PATCH operation is optional in HTTP. To require YANG-Patch would > also > require support for said operation. > > 2. The PATCH operation only trades-off network bandwidth for > server-processing. > Thus it is just a nice-to-have (PUT could be used instead) > > I do not agree. The ability to apply changes all-or-none can be critical, depending on the data model. If changes to multiple resources are needed then plain PATCH may not work. This is one of the ways that network management can not be treated as if the operation is patching a static XML document. Andy 3. The afore-mentioned additional server-processing may not be > acceptable for > resource-constrained devices, one of the purported targets for > RESTCONF. > > > Why more than "MAY": > > 1. For large documents, the tradeoff mentioned above is easily worth-it > > 2. Inspecting a PATCH document easily conveys intent, useful for auditing > and troubleshooting > > > > That said, I would be ok with the following statement: > > The RESTCONF server MAY implement the PATCH operation. If a RESTCONF > server supports the PATCH operation, it MUST at least support > YANG-Patch > for all resources having Content-Type "application/yang.data+xml" or > "application/yang.data+json". In order for RESTCONF clients to > discover > if a server supports the PATCH operation and which PATCH formats are > supported, RESTCONF servers SHOULD return the "Accept-Patch" HTTP > header, > As specified in RFC 5789. > > > Thanks, > Kent > > > From: , "Mehmet (NSN - DE/Munich)" > > > Date: Thursday, March 6, 2014 2:22 PM > To: NetConf > > Subject: [Netconf] YANG Patch Optional or Mandatory > > > Dear NETCONF WG, > > there was a discussion in the IETF #89 NETCONF session on whether YANG > patch for the RESTCONF protocol should be optional or mandatory. > Although we heard different opinions there was no final conclusion. > > The chairs would like to raise this discussion again to come to an > agreement for the way forward. > Please state your opinion with pro and contra. > > Thanks, > Mehmet > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c3e4541725c704f3f23a42 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thursday, March 6, 2014, Kent Watsen <kwatsen@juniper.net> wrote:

For RESTCONF, I think YANG-Patch SHOULD be supported.


Why less than "MUST":

=A0 1. The PATCH operation is optional in HTTP. =A0To require YANG-Patch wo= uld
also
=A0 =A0 =A0require support for said operation.

=A0 2. The PATCH operation only trades-off network bandwidth for
server-processing.
=A0 =A0 =A0Thus it is just a nice-to-have (PUT could be used instead)



I do not agree.
The ability to apply changes all-or-none can be critical,
depe= nding on the data model. =A0If changes to multiple resources
are = needed then plain PATCH may not work.

This is one of the ways that network management can not= be
treated as if the operation is patching a static XML document= .=A0

Andy



=A0 3. The afore-mentioned additional server-processing may not be
acceptable for
=A0 =A0 =A0resource-constrained devices, one of the purported targets for RESTCONF.


Why more than "MAY":

=A0 1. For large documents, the tradeoff mentioned above is easily worth-it=

=A0 2. Inspecting a PATCH document easily conveys intent, useful for auditi= ng
=A0 =A0 =A0and troubleshooting



That said, I would be ok with the following statement:

=A0 =A0 The RESTCONF server MAY implement the PATCH operation. =A0If a REST= CONF
=A0 =A0 server supports the PATCH operation, it MUST at least support
YANG-Patch
=A0 =A0 for all resources having Content-Type "application/yang.data+x= ml" or
=A0 =A0 "application/yang.data+json". =A0In order for RESTCONF cl= ients to
discover
=A0 =A0 if a server supports the PATCH operation and which PATCH formats ar= e
=A0 =A0 supported, RESTCONF servers SHOULD return the "Accept-Patch&qu= ot; HTTP
header,
=A0 =A0 As specified in RFC 5789.


Thanks,
Kent


From: =A0<Ersue>, "Mehmet =A0 (NSN - DE/Munich)" <mehmet.ersue@nsn.com>
Date: =A0Thursday, March 6, 2014 2:22 PM
To: =A0NetConf <netconf@ietf.org>
Subject: =A0[Netconf] YANG Patch Optional or Mandatory


Dear NETCONF WG,

there was a discussion in the IETF #89 NETCONF session on whether YANG
patch for the RESTCONF protocol should be optional or mandatory.
Although we heard different opinions there was no final conclusion.

The chairs would like to raise this discussion again to come to an
agreement for the way forward.
Please state your opinion with pro and contra.

Thanks,
Mehmet





_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
--001a11c3e4541725c704f3f23a42-- From nobody Thu Mar 6 08:06:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E7AF1A006B for ; Thu, 6 Mar 2014 08:06:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XPh4kfhTwiuO for ; Thu, 6 Mar 2014 08:06:07 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 3B7581A00D3 for ; Thu, 6 Mar 2014 08:06:05 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id j5so2742528qaq.0 for ; Thu, 06 Mar 2014 08:06:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=cNXHzHODbZAG3aaOcqRJpZ5r4Je6XMMIbAjQQCpIWyY=; b=Ply/5sreg2CLZbpJdRHBQsIGs+Q+6nZ2bG2avLSLTFgpSYqomxj/XGSeKcDGmqIqq/ 3xlWmsvY0aOqTg2WFYy9S/3oQLgrVKwz6hT6ki/gbxuTO4NvrwSYIYTbzWaHsK5RNUUB Vbwysa04o5inieC6m1e6Dw1bCKk33l3dj0pSzTwI004LExb1WmB4g6Gv6m8Gw9ihQ8dq gxKG5mOkE5OM/E+U7pmyPYiMU8jTbuQvmDV/O1wm2RJnnwVojecGpwqSWl7ZtG5DaQwS AOm9w7phN3Hq20RYWtyuUWkLl92oCZTf/iEgACrCA3c59zbj7XpVSaHol+GWsEqo+vn7 nkAA== X-Gm-Message-State: ALoCoQmLdUyvzpVcGYS8mY1orOx1fmvat/XUzXQ2fwBk/egUaZBVGZ0oMA0U6hiiJ8lm9f0rNxbI MIME-Version: 1.0 X-Received: by 10.229.66.202 with SMTP id o10mr8672478qci.7.1394121961018; Thu, 06 Mar 2014 08:06:01 -0800 (PST) Received: by 10.140.104.194 with HTTP; Thu, 6 Mar 2014 08:06:00 -0800 (PST) In-Reply-To: References: <20140306143550.GF34026@elstar.local> Date: Thu, 6 Mar 2014 08:06:00 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c2f4e64300eb04f3f250ad Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ksO0jMaMBVgrhdmdy2M_m-P6EAQ Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:06:10 -0000 --001a11c2f4e64300eb04f3f250ad Content-Type: text/plain; charset=ISO-8859-1 On Thursday, March 6, 2014, Kent Watsen wrote: > > > Martin convinced be it needs to be mandatory or removed. > > The ability to change the appropriate data in 1 request is critical. > > > I agree that being able to have all updates in a single request is > critical, but can't a RESTCONF client PUT the entire configuration > in one request and achieve this too? This is a very heavyweight way to do a patch. I am much more concerned with efficient NM than following all The CLRs in HTTP. The merge operation is mandatory in NETCONF so it needs to be mandatory in RESTCONF. > > Thanks, > Kent > > Andy > > From: Andy Bierman > > Date: Thursday, March 6, 2014 3:02 PM > To: Juergen Schoenwaelder >, > "Ersue, > Mehmet (NSN - DE/Munich)" >, NetConf > > > Subject: Re: [Netconf] YANG Patch Optional or Mandatory > > > Hi, > > It is designed to be used in NETCONF and RESTCONF. > The operation in draft-bierman-netconf-efficiency-extensions-00 > uses it. > > As for YANG Patch being mandatory... > Martin convinced be it needs to be mandatory or removed. > The ability to change the appropriate data in 1 request is critical. > How it is done is not. > > > Andy > > > On Thursday, March 6, 2014, Juergen Schoenwaelder > > wrote: > > On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) > wrote: > > Dear NETCONF WG, > > > > there was a discussion in the IETF #89 NETCONF session on whether YANG > >patch for the RESTCONF protocol should be optional or mandatory. > > Although we heard different opinions there was no final conclusion. > > > > The chairs would like to raise this discussion again to come to an > >agreement for the way forward. > > Please state your opinion with pro and contra. > > > > I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My > first question is this YANG module only for RESTCONF or is the idea > that NETCONF servers also implement this patch operation. The > introduction is not quite clear, it says things such as "A new RPC > operation can be defined to utilize YANG Patch in the NETCONF > protocol.". There is text further down in the document how it would > work with NETCONF but then I again read "For NETCONF, a YANG "rpc" > statement must be defined.". I like to understand where we are heading > regarding editing primitives in both NETCONF and RESTCONF. (Sorry that > I am not really addressing your question whether this should be > mandatory for RESTCONF.) > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a11c2f4e64300eb04f3f250ad Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thursday, March 6, 2014, Kent Watsen <kwatsen@juniper.net> wrote:

> Martin convinced be it needs to be mandatory or removed.
> The ability to change the appropriate data in 1 request is critical.

I agree that being able to have all updates in a single request is
critical, but can't a RESTCONF client PUT the entire configuration
in one request and achieve this too?

This i= s a very heavyweight way to do a patch.
I am much more concerned = with efficient NM than following all
The CLRs in HTTP. =A0The mer= ge operation is mandatory in NETCONF=A0
so it needs to be mandatory in RESTCONF.

=A0<= /div>

Thanks,
Kent



Andy
=A0

From: =A0Andy Bierman <andy@yumaworks.com>
Date: =A0Thursday, March 6, 2014 3:02 PM
To: =A0Juergen Schoenwaelder <j.scho= enwaelder@jacobs-university.de>, "Ersue,
Mehmet (NSN - DE/Munich)" <mehmet.ersue@nsn.com= >, NetConf
<netconf@ietf.org>
Subject: =A0Re: [Netconf] YANG Patch Optional or Mandatory


Hi,

It is designed to be used in NETCONF and RESTCONF.
The <edit2> operation in draft-bierman-netconf-efficiency-extensions-= 00
uses it.

As for YANG Patch being mandatory...
Martin convinced be it needs to be mandatory or removed.
The ability to change the appropriate data in 1 request is critical.
How it is done is not.


Andy


On Thursday, March 6, 2014, Juergen Schoenwaelder
<j.schoenwaelder@jacobs-university.d= e> wrote:

On Thu, Mar 06, 2014 at 02:22:23PM +0000, Ersue, Mehmet (NSN - DE/Munich) wrote:
> Dear NETCONF WG,
>
> there was a discussion in the IETF #89 NETCONF session on whether YANG=
>patch for the RESTCONF protocol should be optional or mandatory.
> Although we heard different opinions there was no final conclusion. >
> The chairs would like to raise this discussion again to come to an
>agreement for the way forward.
> Please state your opinion with pro and contra.
>

I assume we talk about draft-bierman-netconf-yang-patch-00.txt. My
first question is this YANG module only for RESTCONF or is the idea
that NETCONF servers also implement this patch operation. The
introduction is not quite clear, it says things such as "A new RPC
operation can be defined to utilize YANG Patch in the NETCONF
protocol.". There is text further down in the document how it would work with NETCONF but then I again read "For NETCONF, a YANG "rpc= "
statement must be defined.". I like to understand where we are heading=
regarding editing primitives in both NETCONF and RESTCONF. (Sorry that
I am not really addressing your question whether this should be
mandatory for RESTCONF.)

/js

--
Juergen Schoenwaelder =A0 =A0 =A0 =A0 =A0 Jacobs University Bremen gGmbH Phone: +49 421 200 3587 =A0 =A0 =A0 =A0 Campus Ring 1, 28759 Bremen, German= y
Fax: =A0 +49 421 200 3103 =A0 =A0 =A0 =A0 <http://www.jacobs-university.de/><= br>
_______________________________________________
Netconf mailing list
Netconf@ietf.org=A0<javascript:;>
https://www.ietf.org/mailman/listinfo/netconf


--001a11c2f4e64300eb04f3f250ad-- From nobody Thu Mar 6 08:09:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E2AD1A006B for ; Thu, 6 Mar 2014 08:09:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYaN9iEVLtfv for ; Thu, 6 Mar 2014 08:09:26 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id E533A1A0030 for ; Thu, 6 Mar 2014 08:09:23 -0800 (PST) Received: from mail201-ch1-R.bigfish.com (10.43.68.242) by CH1EHSOBE009.bigfish.com (10.43.70.59) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 16:09:19 +0000 Received: from mail201-ch1 (localhost [127.0.0.1]) by mail201-ch1-R.bigfish.com (Postfix) with ESMTP id 549992C04AA; Thu, 6 Mar 2014 16:09:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -28 X-BigFish: VPS-28(zz98dI9371I1432Ic1dMzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail201-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(377454003)(24454002)(189002)(199002)(31014004)(66066001)(83322001)(85306002)(54316002)(74706001)(83716003)(77156001)(56776001)(89996001)(2656002)(80976001)(80022001)(95416001)(33656001)(19580395003)(76482001)(87266001)(76796001)(95666003)(36756003)(85852003)(77096001)(19580405001)(56816005)(87286001)(90146001)(97186001)(83072002)(97336001)(87936001)(74502001)(4396001)(65816001)(93136001)(74876001)(81686001)(47736001)(50226001)(47446002)(49866001)(46102001)(79102001)(63696002)(74662001)(59766001)(77982001)(57306001)(51856001)(82746002)(47976001)(88136002)(94946001)(76786001)(15975445006)(31966008)(81542001)(92566001)(92726001)(53806001)(50986001)(69226001)(81816001)(93916002)(93516002)(81342001)(74366001)(62966002)(94316002)(86362001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB712; H:BN1PR05MB424.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:BE2CF125.14D6D7C5.E2D39C63.86E6D041.203E5; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail201-ch1 (localhost.localdomain [127.0.0.1]) by mail201-ch1 (MessageSwitch) id 1394122157290006_26472; Thu, 6 Mar 2014 16:09:17 +0000 (UTC) Received: from CH1EHSMHS025.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail201-ch1.bigfish.com (Postfix) with ESMTP id 42CA3480093; Thu, 6 Mar 2014 16:09:17 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS025.bigfish.com (10.43.70.25) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 16:09:16 +0000 Received: from BY2PR05MB712.namprd05.prod.outlook.com (10.141.222.155) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 16:09:15 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BY2PR05MB712.namprd05.prod.outlook.com (10.141.222.155) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 6 Mar 2014 16:09:14 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) with mapi id 15.00.0888.003; Thu, 6 Mar 2014 16:09:13 +0000 From: Dean Bogdanovic To: Randy Presuhn Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPN+VQvD7LZsKAt0y8O27fc1V2vprUPQeA Date: Thu, 6 Mar 2014 16:09:12 +0000 Message-ID: <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> In-Reply-To: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: text/plain; charset="us-ascii" Content-ID: <0C3337C2DC3E1F48A16FD0249CB86AE9@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xltWxDrDWPyyNMn0SVp13moGc_0 Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:09:33 -0000 Randy, Your points are valid, but we are seeing requests from data center operator= s to reduce some security levels for inside data centers, to make easier ma= nagement. For them the big issue is how to make the build up of data center= s as efficient as possible. Based on some requests seen so far, I would say= with pretty high confidence that they would not mind carrying single USB w= ith configs to setup basic functionality on network devices. Dean On Mar 4, 2014, at 8:07 PM, Randy Presuhn wr= ote: > Hi - >=20 >> From: Kent Watsen >> Sent: Mar 4, 2014 10:35 AM >> To: Randy Presuhn , "netconf@ietf.org" >> Subject: Re: [Netconf] Unsigned configlets and physical security > ... >> FWIW, The Security thinking is that someone that can get physical access >> to a device already owns it. >=20 > Stuxnet. >=20 >> So, requiring the Configlet to be signed >> doesn't protect anything and, given the logistical overhead involved in >> getting/using *signed* Configlets, would only frustrate trusted >> administrators. >=20 > If it's the administrator typing things in at a console, yes. > If it's the administrator bringing in the configuration data > on other media or via the network, clearly no. >=20 >> In this case, the administrator is using the Configlet >> because it's easier/more-scalable than manual configuration. >=20 > Thus increasing the likelihood that it's brought in on > external media, along with all the vulnerabilities that > come with that. >=20 >> Joe brings up the special case where an adversary doesn't get physical >> access, but passes an unsigned Configlet to a trusted administrator, who >> initializes a device using it without inspecting it first. To be fair, = it >> could be that trusted administrator could've been duped and actually >> thinks the Configlet is trusted and hence doesn't consider the need to >> [re]inspect it. =20 >=20 > That's where signatures can help, assuming they're actually > *checked* and the CAs involved haven't been subverted. >=20 >> Maybe this last issue be addressed via a Security Consideration - e.g. >> "unsigned Configlets SHOULD be inspected before each use." What do you >> think? >=20 > You're much more optimistic than I about the likelihood > of discovering configuration errors by inspection. Consider > possibilities like pointing to bogus DNS roots, installing > trojan-horse user IDs, pre-compromised keys for little-used > accounts, or weakening the encryption on selected links. > After all, an attacker's objective might simply be to make > sure that outgoing traffic is easily monitored. An attack > could be as simple as changing a few bits in VACM's > configuration to allow the attacker to use SNMP > to complete the attack. >=20 > Randy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 From nobody Thu Mar 6 08:13:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 642D91A0051 for ; Thu, 6 Mar 2014 08:13:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rhMIWjk4Girc for ; Thu, 6 Mar 2014 08:13:26 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 2982D1A006B for ; Thu, 6 Mar 2014 08:13:26 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 6753637C2C2; Thu, 6 Mar 2014 17:13:21 +0100 (CET) Date: Thu, 06 Mar 2014 17:13:21 +0100 (CET) Message-Id: <20140306.171321.298927830.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xISKX_4zZp1789lNQje4FTc9ei4 Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:13:32 -0000 Kent Watsen wrote: > > For RESTCONF, I think YANG-Patch SHOULD be supported. > > > Why less than "MUST": > > 1. The PATCH operation is optional in HTTP. Yes, in a "general-purpose server" (RFC 2616). In fact, only GET and HEAD are mandatory in "general-purpose servers". But this is not a general purpose server, and we decide which methods MUST be implemented. > To require YANG-Patch would > also > require support for said operation. We could use POST instead. I think we should ask some APPS folks about guidance - should we use PATCH or not. > 2. The PATCH operation only trades-off network bandwidth for > server-processing. > Thus it is just a nice-to-have (PUT could be used instead) This is not scalable, and has issues with access control. If I am not allowed to read/write everything, I can't PUT, and thus not change anything. /martin From nobody Thu Mar 6 08:22:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543831A0092 for ; Thu, 6 Mar 2014 08:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U5MPQbH9Svg4 for ; Thu, 6 Mar 2014 08:22:31 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 134AB1A00AA for ; Thu, 6 Mar 2014 08:22:31 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E0170F95; Thu, 6 Mar 2014 17:22:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qmjySZ1IaIlI; Thu, 6 Mar 2014 17:22:25 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 17:22:25 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2CD4820034; Thu, 6 Mar 2014 17:22:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 2J8p7R2dtQqK; Thu, 6 Mar 2014 17:22:23 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7A1A52002F; Thu, 6 Mar 2014 17:22:23 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 669962B988D9; Thu, 6 Mar 2014 17:22:21 +0100 (CET) Date: Thu, 6 Mar 2014 17:22:21 +0100 From: Juergen Schoenwaelder To: Dean Bogdanovic Message-ID: <20140306162221.GC34547@elstar.local> Mail-Followup-To: Dean Bogdanovic , "netconf@ietf.org" References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XonG170bkMBL1xmbSQEWpKlitAs Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:22:34 -0000 Hi, I somehow doubt that Further, this draft does not require Configlets to be signed, if loaded via a mechanism that asserts physical presence. or require those Configlets to have the device's unique identifier value set. All of these relaxations in Security are deemed acceptable because physical presence should only be accessible to trusted parties. will fly very high during security area review. Physical presence obviously not always imply trusted parties. There might be deployments where it does but in the general case it does not (and I personally believe that even deployments where people think it does it might actually not). /js On Thu, Mar 06, 2014 at 04:09:12PM +0000, Dean Bogdanovic wrote: > Randy, > > Your points are valid, but we are seeing requests from data center operators to reduce some security levels for inside data centers, to make easier management. For them the big issue is how to make the build up of data centers as efficient as possible. Based on some requests seen so far, I would say with pretty high confidence that they would not mind carrying single USB with configs to setup basic functionality on network devices. > > Dean > > On Mar 4, 2014, at 8:07 PM, Randy Presuhn wrote: > > > Hi - > > > >> From: Kent Watsen > >> Sent: Mar 4, 2014 10:35 AM > >> To: Randy Presuhn , "netconf@ietf.org" > >> Subject: Re: [Netconf] Unsigned configlets and physical security > > ... > >> FWIW, The Security thinking is that someone that can get physical access > >> to a device already owns it. > > > > Stuxnet. > > > >> So, requiring the Configlet to be signed > >> doesn't protect anything and, given the logistical overhead involved in > >> getting/using *signed* Configlets, would only frustrate trusted > >> administrators. > > > > If it's the administrator typing things in at a console, yes. > > If it's the administrator bringing in the configuration data > > on other media or via the network, clearly no. > > > >> In this case, the administrator is using the Configlet > >> because it's easier/more-scalable than manual configuration. > > > > Thus increasing the likelihood that it's brought in on > > external media, along with all the vulnerabilities that > > come with that. > > > >> Joe brings up the special case where an adversary doesn't get physical > >> access, but passes an unsigned Configlet to a trusted administrator, who > >> initializes a device using it without inspecting it first. To be fair, it > >> could be that trusted administrator could've been duped and actually > >> thinks the Configlet is trusted and hence doesn't consider the need to > >> [re]inspect it. > > > > That's where signatures can help, assuming they're actually > > *checked* and the CAs involved haven't been subverted. > > > >> Maybe this last issue be addressed via a Security Consideration - e.g. > >> "unsigned Configlets SHOULD be inspected before each use." What do you > >> think? > > > > You're much more optimistic than I about the likelihood > > of discovering configuration errors by inspection. Consider > > possibilities like pointing to bogus DNS roots, installing > > trojan-horse user IDs, pre-compromised keys for little-used > > accounts, or weakening the encryption on selected links. > > After all, an attacker's objective might simply be to make > > sure that outgoing traffic is easily monitored. An attack > > could be as simple as changing a few bits in VACM's > > configuration to allow the attacker to use SNMP > > to complete the attack. > > > > Randy > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Mar 6 08:23:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D14C71A00AB for ; Thu, 6 Mar 2014 08:23:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 204k-RqgOG9t for ; Thu, 6 Mar 2014 08:23:49 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7981A0092 for ; Thu, 6 Mar 2014 08:23:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3427; q=dns/txt; s=iport; t=1394123026; x=1395332626; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=KhP6QRv/neLxSk8iYLEpBlWTfoza3GYPfkNMnLXFx30=; b=ColNeCALrJ5XKi28EtaHu5xk+eg/WT6Yk8pm5RL1AqYQcMw68Ddq5TZj Gvu2/3UeAtMxUr0zw2vKC2QJ3zNSZ6faIIfUiBYh21JRJZpWxX6UaY3Rd Wf7kzrgukRvshsjrCdi8LBvIZ2AtjbuGnnFYI3Cx0MJ1zMiVCMuhoObkB g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAPSfGFOQ/khL/2dsb2JhbABagwY7wSdPgRgWdIIlAQEBAwEBAQE1NgoBEAsRBAEBAQkWDwkDAgECARUoCAYBDAEFAgEBh20IDc8xEwSOWweEOAEDiUyOcoZKi2GDSx4 X-IronPort-AV: E=Sophos;i="4.97,601,1389744000"; d="scan'208";a="7465531" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-1.cisco.com with ESMTP; 06 Mar 2014 16:23:44 +0000 Received: from [10.82.236.159] (rtp-vpn5-1179.cisco.com [10.82.236.159]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s26GNgcq003174; Thu, 6 Mar 2014 16:23:43 GMT Message-ID: <5318A10E.4030309@cisco.com> Date: Thu, 06 Mar 2014 11:23:42 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Dean Bogdanovic , Randy Presuhn References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> In-Reply-To: <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/7US19Y3scydQUeL9MuyjuMf-zrE Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:23:52 -0000 On 3/6/14, 11:09 AM, Dean Bogdanovic wrote: > Randy, > > Your points are valid, but we are seeing requests from data center operators to reduce some security levels for inside data centers, to make easier management. For them the big issue is how to make the build up of data centers as efficient as possible. Based on some requests seen so far, I would say with pretty high confidence that they would not mind carrying single USB with configs to setup basic functionality on network devices. I agree with this, but would they mind a USB stick with signed configlets where the device loads _its_ configlet based on the fingerprint? Joe > > Dean > > On Mar 4, 2014, at 8:07 PM, Randy Presuhn wrote: > >> Hi - >> >>> From: Kent Watsen >>> Sent: Mar 4, 2014 10:35 AM >>> To: Randy Presuhn , "netconf@ietf.org" >>> Subject: Re: [Netconf] Unsigned configlets and physical security >> ... >>> FWIW, The Security thinking is that someone that can get physical access >>> to a device already owns it. >> >> Stuxnet. >> >>> So, requiring the Configlet to be signed >>> doesn't protect anything and, given the logistical overhead involved in >>> getting/using *signed* Configlets, would only frustrate trusted >>> administrators. >> >> If it's the administrator typing things in at a console, yes. >> If it's the administrator bringing in the configuration data >> on other media or via the network, clearly no. >> >>> In this case, the administrator is using the Configlet >>> because it's easier/more-scalable than manual configuration. >> >> Thus increasing the likelihood that it's brought in on >> external media, along with all the vulnerabilities that >> come with that. >> >>> Joe brings up the special case where an adversary doesn't get physical >>> access, but passes an unsigned Configlet to a trusted administrator, who >>> initializes a device using it without inspecting it first. To be fair, it >>> could be that trusted administrator could've been duped and actually >>> thinks the Configlet is trusted and hence doesn't consider the need to >>> [re]inspect it. >> >> That's where signatures can help, assuming they're actually >> *checked* and the CAs involved haven't been subverted. >> >>> Maybe this last issue be addressed via a Security Consideration - e.g. >>> "unsigned Configlets SHOULD be inspected before each use." What do you >>> think? >> >> You're much more optimistic than I about the likelihood >> of discovering configuration errors by inspection. Consider >> possibilities like pointing to bogus DNS roots, installing >> trojan-horse user IDs, pre-compromised keys for little-used >> accounts, or weakening the encryption on selected links. >> After all, an attacker's objective might simply be to make >> sure that outgoing traffic is easily monitored. An attack >> could be as simple as changing a few bits in VACM's >> configuration to allow the attacker to use SNMP >> to complete the attack. >> >> Randy >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Mar 6 08:29:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A36D91A01D5 for ; Thu, 6 Mar 2014 08:29:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xzvoXCocw1Wy for ; Thu, 6 Mar 2014 08:29:28 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 539B61A0192 for ; Thu, 6 Mar 2014 08:29:22 -0800 (PST) Received: from mail142-co9-R.bigfish.com (10.236.132.233) by CO9EHSOBE014.bigfish.com (10.236.130.77) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 16:29:18 +0000 Received: from mail142-co9 (localhost [127.0.0.1]) by mail142-co9-R.bigfish.com (Postfix) with ESMTP id 0FF0D3E04BF; Thu, 6 Mar 2014 16:29:18 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85dhe0eah4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail142-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(199002)(189002)(95416001)(74366001)(80022001)(80976001)(56776001)(66066001)(46102001)(95666003)(79102001)(94316002)(87936001)(47446002)(54316002)(31966008)(56816005)(97186001)(74706001)(85852003)(16236675002)(74502001)(97336001)(93516002)(69226001)(86362001)(83072002)(94946001)(81342001)(90146001)(93136001)(36756003)(83506001)(81686001)(74662001)(51856001)(50986001)(49866001)(4396001)(81816001)(74876001)(47736001)(59766001)(87266001)(53806001)(92726001)(77096001)(2656002)(76786001)(76482001)(76796001)(65816001)(47976001)(63696002)(77982001)(83322001)(81542001)(54356001)(85306002)(92566001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB717; H:CO1PR05MB458.namprd05.prod.outlook Received: from mail142-co9 (localhost.localdomain [127.0.0.1]) by mail142-co9 (MessageSwitch) id 139412335657612_12144; Thu, 6 Mar 2014 16:29:16 +0000 (UTC) Received: from CO9EHSMHS006.bigfish.com (unknown [10.236.132.240]) by mail142-co9.bigfish.com (Postfix) with ESMTP id F3BAE6004A; Thu, 6 Mar 2014 16:29:15 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS006.bigfish.com (10.236.130.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 16:29:15 +0000 Received: from DM2PR05MB717.namprd05.prod.outlook.com (10.141.177.145) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 16:29:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by DM2PR05MB717.namprd05.prod.outlook.com (10.141.177.145) with Microsoft SMTP Server (TLS) id 15.0.888.9; Thu, 6 Mar 2014 16:29:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0883.010; Thu, 6 Mar 2014 16:29:13 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: Ac85R3x2hs2pdNeiQoOvg0oaOcp59QAAeIoAAADtrYAAAbUzgAAAg0cAAADPR4A= Date: Thu, 6 Mar 2014 16:29:12 +0000 Message-ID: References: <20140306143550.GF34026@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: multipart/alternative; boundary="_000_CF3E4DBF60785kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/DVmbCm38Q3K__QN8h94X6uf068k Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:29:30 -0000 --_000_CF3E4DBF60785kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > This is a very heavyweight way to do a patch. It's not a PATCH, not even a poor-man's PATCH - it's a PUT, and for some de= vices, that may be all they want to support. Again, I'm thinking about res= ource-constrained devices... > I am much more concerned with efficient NM than following all the CLRs in= HTTP. Me too, but RESTCONF purports itself as being lightweight. I don't want t= o make the same mistakes that drove us to want NETCONF Light - recall that = edit-config was going to be optional, because copy-config could support the= base case... > The merge operation is mandatory in NETCONF > so it needs to be mandatory in RESTCONF. That was a mistake, do we want to double-down? Thanks, Kent --_000_CF3E4DBF60785kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable


> This is a very heavyweight way to do a patch.

It's not a PATCH, not even a poor-man's PATCH – it's a PUT, and = for some devices, that may be all they want to support.  Again, I'm th= inking about resource-constrained devices...


> I am much more concerned with efficient NM than following all the= CLRs in HTTP.  

Me too, but RESTCONF purports itself as being lightweight.   I do= n't want to make the same mistakes that drove us to want NETCONF Light - re= call that edit-config was going to be optional, because copy-config could s= upport the base case...


> The merge operation is mandatory in NETCONF 
> so it needs to be mandatory in RESTCONF.

That was a mistake, do we want to double-down?


Thanks,
Kent
--_000_CF3E4DBF60785kwatsenjunipernet_-- From nobody Thu Mar 6 08:39:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB9291A00F4 for ; Thu, 6 Mar 2014 08:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eaEDqRUBGj6o for ; Thu, 6 Mar 2014 08:39:53 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe003.messaging.microsoft.com [216.32.181.183]) by ietfa.amsl.com (Postfix) with ESMTP id 5D7851A00E8 for ; Thu, 6 Mar 2014 08:39:53 -0800 (PST) Received: from mail66-ch1-R.bigfish.com (10.43.68.243) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 16:39:49 +0000 Received: from mail66-ch1 (localhost [127.0.0.1]) by mail66-ch1-R.bigfish.com (Postfix) with ESMTP id F2F92220624; Thu, 6 Mar 2014 16:39:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI9371I1432Ic1dMzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h947hd25he5bhf0ah1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail66-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(377454003)(31014004)(479174003)(199002)(189002)(51704005)(24454002)(56816005)(69226001)(83716003)(15975445006)(90146001)(89996001)(97336001)(92566001)(81342001)(86362001)(93916002)(92726001)(81542001)(74876001)(95666003)(94946001)(93136001)(81816001)(2656002)(83072002)(85852003)(82746002)(74706001)(88136002)(87266001)(74366001)(87936001)(85306002)(87286001)(81686001)(80976001)(80022001)(77982001)(79102001)(63696002)(50986001)(57306001)(47976001)(47736001)(54316002)(56776001)(76482001)(95416001)(4396001)(50226001)(49866001)(53806001)(19580405001)(83322001)(19580395003)(46102001)(51856001)(74502001)(47446002)(31966008)(66066001)(65816001)(59766001)(93516002)(74662001)(97186001)(94316002)(33656001)(76796001)(76786001)(77096001)(77156001)(62966002)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB774; H:BN1PR05MB424.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:FE2CF1A4.14D697E1.A6D39F7B.86A5D041.2048F; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail66-ch1 (localhost.localdomain [127.0.0.1]) by mail66-ch1 (MessageSwitch) id 1394123987342502_22124; Thu, 6 Mar 2014 16:39:47 +0000 (UTC) Received: from CH1EHSMHS028.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.228]) by mail66-ch1.bigfish.com (Postfix) with ESMTP id 3C16B1E00F8; Thu, 6 Mar 2014 16:39:47 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS028.bigfish.com (10.43.70.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 16:39:46 +0000 Received: from BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 16:39:45 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BY2PR05MB774.namprd05.prod.outlook.com (10.141.224.143) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 16:39:43 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) with mapi id 15.00.0888.003; Thu, 6 Mar 2014 16:39:42 +0000 From: Dean Bogdanovic To: Joe Marcus Clarke Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPN+VQvD7LZsKAt0y8O27fc1V2vprUPQeAgAAEDgCAAAR1gA== Date: Thu, 6 Mar 2014 16:39:41 +0000 Message-ID: References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> In-Reply-To: <5318A10E.4030309@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <2D46F61A6F0DFE4093EBD2EC73AA3906@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/VRZPoABH5bYtR-T6_oIuiyhPzUg Cc: Randy Presuhn , "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:39:56 -0000 Don't know. I was very surprised by the request from the operators (as it o= pens up a big security whole), but they were very adamant about it. At the moment, anything that inconvenience their process is a hinderance. OTH, once they get burned, things might (I actually believe will) change. T= his is the reason why I'm saying put it optional. If you put it mandatory, = it will hinder adoption. Dean On Mar 6, 2014, at 4:23 PM, Joe Marcus Clarke wrote: > On 3/6/14, 11:09 AM, Dean Bogdanovic wrote: >> Randy, >>=20 >> Your points are valid, but we are seeing requests from data center opera= tors to reduce some security levels for inside data centers, to make easier= management. For them the big issue is how to make the build up of data cen= ters as efficient as possible. Based on some requests seen so far, I would = say with pretty high confidence that they would not mind carrying single US= B with configs to setup basic functionality on network devices. >=20 > I agree with this, but would they mind a USB stick with signed configlets= where the device loads _its_ configlet based on the fingerprint? >=20 > Joe >=20 >>=20 >> Dean >>=20 >> On Mar 4, 2014, at 8:07 PM, Randy Presuhn = wrote: >>=20 >>> Hi - >>>=20 >>>> From: Kent Watsen >>>> Sent: Mar 4, 2014 10:35 AM >>>> To: Randy Presuhn , "netconf@ietf.org" <= netconf@ietf.org> >>>> Subject: Re: [Netconf] Unsigned configlets and physical security >>> ... >>>> FWIW, The Security thinking is that someone that can get physical acce= ss >>>> to a device already owns it. >>>=20 >>> Stuxnet. >>>=20 >>>> So, requiring the Configlet to be signed >>>> doesn't protect anything and, given the logistical overhead involved i= n >>>> getting/using *signed* Configlets, would only frustrate trusted >>>> administrators. >>>=20 >>> If it's the administrator typing things in at a console, yes. >>> If it's the administrator bringing in the configuration data >>> on other media or via the network, clearly no. >>>=20 >>>> In this case, the administrator is using the Configlet >>>> because it's easier/more-scalable than manual configuration. >>>=20 >>> Thus increasing the likelihood that it's brought in on >>> external media, along with all the vulnerabilities that >>> come with that. >>>=20 >>>> Joe brings up the special case where an adversary doesn't get physical >>>> access, but passes an unsigned Configlet to a trusted administrator, w= ho >>>> initializes a device using it without inspecting it first. To be fair= , it >>>> could be that trusted administrator could've been duped and actually >>>> thinks the Configlet is trusted and hence doesn't consider the need to >>>> [re]inspect it. >>>=20 >>> That's where signatures can help, assuming they're actually >>> *checked* and the CAs involved haven't been subverted. >>>=20 >>>> Maybe this last issue be addressed via a Security Consideration - e.g. >>>> "unsigned Configlets SHOULD be inspected before each use." What do yo= u >>>> think? >>>=20 >>> You're much more optimistic than I about the likelihood >>> of discovering configuration errors by inspection. Consider >>> possibilities like pointing to bogus DNS roots, installing >>> trojan-horse user IDs, pre-compromised keys for little-used >>> accounts, or weakening the encryption on selected links. >>> After all, an attacker's objective might simply be to make >>> sure that outgoing traffic is easily monitored. An attack >>> could be as simple as changing a few bits in VACM's >>> configuration to allow the attacker to use SNMP >>> to complete the attack. >>>=20 >>> Randy >>>=20 >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>>=20 >>>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >>=20 >=20 >=20 >=20 From nobody Thu Mar 6 08:40:12 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30AA11A0190 for ; Thu, 6 Mar 2014 08:40:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqVwxjdYu-iM for ; Thu, 6 Mar 2014 08:40:09 -0800 (PST) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) by ietfa.amsl.com (Postfix) with ESMTP id 863961A01CF for ; Thu, 6 Mar 2014 08:40:09 -0800 (PST) Received: by mail-qg0-f47.google.com with SMTP id 63so7865408qgz.6 for ; Thu, 06 Mar 2014 08:40:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=s55Af5OJWFOSvywrRqRo4uqNltL7vyaaI6OAk6loi3c=; b=gPoeQ5vpHXe007iG+WE5bueil/mJHlO7rDtTvyhPd1R4S3LNbZ/uxcT82hsBVk+yGB Bj5q7Hqtl/h9nV+j4vlGdwNEHS8fYcnZ49p7mhXX5CkXihHnOwIE6imrcullEplCUC43 n64Ct2/3HWn6GivIMA1sW1zU36S8eG7vVyQd8SEDOYeuwG9YkFPw83RgD7ZKS47TUYGT cuXyzRo6yITuzSZ+9DqZAGEe/VwHzT2DPNTwkLDttpaPW/lvosJCG3okisK1dpasYjcU xPk0JVFOQx4aRJxNYnY/ZUv1bsyfOe1nc63WDdx3rVmEl0ACL6IprvdQBw9hh2jk+QNm ECjg== X-Gm-Message-State: ALoCoQlbtbbHGIJLNh5PEGgnr42KiF0p9Z6jr9cUEr1bKVx1YUaugoQ1pSJ0qDUXZJP6yZIi+71p MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr14102907qgx.18.1394124005321; Thu, 06 Mar 2014 08:40:05 -0800 (PST) Received: by 10.140.104.194 with HTTP; Thu, 6 Mar 2014 08:40:05 -0800 (PST) In-Reply-To: References: <20140306143550.GF34026@elstar.local> Date: Thu, 6 Mar 2014 08:40:05 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c004341c422004f3f2ca66 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wGUCTCqAdGSdVuisxjgb6bwG71E Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 16:40:11 -0000 --001a11c004341c422004f3f2ca66 Content-Type: text/plain; charset=ISO-8859-1 On Thursday, March 6, 2014, Kent Watsen wrote: > > > > This is a very heavyweight way to do a patch. > > It's not a PATCH, not even a poor-man's PATCH - it's a PUT, and for some > devices, that may be all they want to support. Again, I'm thinking about > resource-constrained devices... > > > > I am much more concerned with efficient NM than following all the > CLRs in HTTP. > > Me too, but RESTCONF purports itself as being lightweight. I don't > want to make the same mistakes that drove us to want NETCONF Light - recall > that edit-config was going to be optional, because copy-config could > support the base case... > > > > The merge operation is mandatory in NETCONF > > so it needs to be mandatory in RESTCONF. > > That was a mistake, do we want to double-down? > > I don't agree that is a mistake. It is the most direct and efficient way to convey the intended changes to the server implementation. > > Thanks, > Kent > Andy --001a11c004341c422004f3f2ca66 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Thursday, March 6, 2014, Kent Watsen <kwatsen@juniper.net> wrote:


> This is a very heavyweight way to do a patch.

It's not a PATCH, not even a poor-man's PATCH – it's= a PUT, and for some devices, that may be all they want to support.  A= gain, I'm thinking about resource-constrained devices...


> I am much more concerned with efficient NM than following all the= CLRs in HTTP.  

Me too, but RESTCONF purports itself as being lightweight.   I do= n't want to make the same mistakes that drove us to want NETCONF Light = - recall that edit-config was going to be optional, because copy-config cou= ld support the base case...


> The merge operation is mandatory in NETCONF 
> so it needs to be mandatory in RESTCONF.

That was a mistake, do we want to double-down?


I don't agree that is a mi= stake.
It is the most direct and efficient way to convey the inte= nded
changes to the server implementation.

 

Thanks,
Kent


Andy
 
--001a11c004341c422004f3f2ca66-- From nobody Thu Mar 6 09:00:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83451A01D6 for ; Thu, 6 Mar 2014 09:00:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id neQskp0lxWGd for ; Thu, 6 Mar 2014 09:00:09 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id ABC501A01FB for ; Thu, 6 Mar 2014 09:00:09 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 693E91E21; Thu, 6 Mar 2014 18:00:05 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yOntoJCTeGUd; Thu, 6 Mar 2014 18:00:04 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 18:00:04 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C37EF20031; Thu, 6 Mar 2014 18:00:04 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id x5EPzWTxRR_y; Thu, 6 Mar 2014 18:00:03 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A35B82002F; Thu, 6 Mar 2014 18:00:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CEB762B98AFB; Thu, 6 Mar 2014 18:00:00 +0100 (CET) Date: Thu, 6 Mar 2014 18:00:00 +0100 From: Juergen Schoenwaelder To: Dean Bogdanovic Message-ID: <20140306170000.GA34736@elstar.local> Mail-Followup-To: Dean Bogdanovic , Joe Marcus Clarke , Randy Presuhn , "netconf@ietf.org" References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XFcWlea293Z56MDy15U_Li6Mgoo Cc: Randy Presuhn , "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:00:12 -0000 On Thu, Mar 06, 2014 at 04:39:41PM +0000, Dean Bogdanovic wrote: > Don't know. I was very surprised by the request from the operators (as it opens up a big security whole), but they were very adamant about it. > > At the moment, anything that inconvenience their process is a hinderance. > > OTH, once they get burned, things might (I actually believe will) change. This is the reason why I'm saying put it optional. If you put it mandatory, it will hinder adoption. > It needs to be mandatory to implement. If people then want to shoot themself, let them do it. But it does not work to make this optional to implement because this makes it hard for those who want to be responsible. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Mar 6 09:07:18 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C13D1A01F3 for ; Thu, 6 Mar 2014 09:07:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TdzNb8G9kjFc for ; Thu, 6 Mar 2014 09:07:12 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 858221A01E9 for ; Thu, 6 Mar 2014 09:07:12 -0800 (PST) Received: from mail45-ch1-R.bigfish.com (10.43.68.232) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 17:07:08 +0000 Received: from mail45-ch1 (localhost [127.0.0.1]) by mail45-ch1-R.bigfish.com (Postfix) with ESMTP id 42936C0495; Thu, 6 Mar 2014 17:07:08 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -2 X-BigFish: VPS-2(zz1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail45-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(51704005)(164054003)(36756003)(90146001)(56816005)(85852003)(83072002)(51856001)(53806001)(93516002)(86362001)(46102001)(77096001)(97336001)(97186001)(95666003)(66066001)(80022001)(65816001)(79102001)(59766001)(77982001)(81342001)(63696002)(1941001)(74706001)(81542001)(81686001)(50986001)(47736001)(47976001)(74876001)(87266001)(83506001)(15975445006)(69226001)(83322001)(15202345003)(19580395003)(49866001)(81816001)(2656002)(80976001)(74366001)(87936001)(93136001)(74502001)(92726001)(95416001)(54316002)(54356001)(76482001)(56776001)(47446002)(92566001)(31966008)(94316002)(74662001)(85306002)(94946001)(4396001)(76786001)(76796001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB427; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:FF3CF11D.A6D0570B.31D391B7.CAEBDBB1.20239; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail45-ch1 (localhost.localdomain [127.0.0.1]) by mail45-ch1 (MessageSwitch) id 1394125626150042_803; Thu, 6 Mar 2014 17:07:06 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.252]) by mail45-ch1.bigfish.com (Postfix) with ESMTP id 1FFFB320090; Thu, 6 Mar 2014 17:07:06 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 17:07:05 +0000 Received: from CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 17:07:02 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 17:06:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0883.010; Thu, 6 Mar 2014 17:06:59 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Dean Bogdanovic Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPN+VQXJRY3wt5xU21sJN7KFRgh5rUPQgAgAADrYCAAAx2gA== Date: Thu, 6 Mar 2014 17:06:58 +0000 Message-ID: References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <20140306162221.GC34547@elstar.local> In-Reply-To: <20140306162221.GC34547@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: text/plain; charset="us-ascii" Content-ID: <8CEACEF95B854641AEE4541CF70763B3@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fZz9x-JFkQioxf3qn0-109_LJRM Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:07:15 -0000 >I somehow doubt that > > Further, this draft does not require Configlets to be > signed, if loaded via a mechanism that asserts physical presence. or > require those Configlets to have the device's unique identifier value > set. All of these relaxations in Security are deemed acceptable > because physical presence should only be accessible to trusted > parties. > >will fly very high during security area review. Physical presence >obviously not always imply trusted parties. There might be deployments >where it does but in the general case it does not (and I personally >believe that even deployments where people think it does it might >actually not). I think there is a good chance it will fly because there is precedent in the TPM specification [1], which uses physical presence to perform certain administrative functions. See section 10 (Physical Presence) in the "Part 1: Design Principles" document. However, to your point, we'd still need their sign off. Since I'm on friendly terms with sec folks (my other foot is in their area), I'll ask the ADs when I see them next... [1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification Thanks, Kent From nobody Thu Mar 6 09:18:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61E6E1A028B for ; Thu, 6 Mar 2014 09:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uy4sNkoOww9l for ; Thu, 6 Mar 2014 09:18:45 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe005.messaging.microsoft.com [207.46.163.28]) by ietfa.amsl.com (Postfix) with ESMTP id 1A73C1A028F for ; Thu, 6 Mar 2014 09:18:45 -0800 (PST) Received: from mail67-co9-R.bigfish.com (10.236.132.245) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.22; Thu, 6 Mar 2014 17:18:41 +0000 Received: from mail67-co9 (localhost [127.0.0.1]) by mail67-co9-R.bigfish.com (Postfix) with ESMTP id 1FEA41E00A5; Thu, 6 Mar 2014 17:18:41 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zzc85dh4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh18c673h1de097hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail67-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(164054003)(36756003)(90146001)(56816005)(85852003)(83072002)(51856001)(53806001)(93516002)(46102001)(86362001)(77096001)(97336001)(97186001)(95666003)(66066001)(80022001)(65816001)(79102001)(77982001)(59766001)(81342001)(63696002)(74706001)(16236675002)(81542001)(81686001)(50986001)(47736001)(47976001)(74876001)(87266001)(83506001)(69226001)(83322001)(49866001)(81816001)(2656002)(80976001)(87936001)(54316002)(93136001)(74366001)(74502001)(92726001)(95416001)(54356001)(56776001)(76482001)(47446002)(92566001)(31966008)(94316002)(74662001)(85306002)(94946001)(4396001)(76786001)(76796001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB705; H:CO1PR05MB458.namprd05.prod.outlook Received: from mail67-co9 (localhost.localdomain [127.0.0.1]) by mail67-co9 (MessageSwitch) id 1394126319360676_7933; Thu, 6 Mar 2014 17:18:39 +0000 (UTC) Received: from CO9EHSMHS032.bigfish.com (unknown [10.236.132.232]) by mail67-co9.bigfish.com (Postfix) with ESMTP id 50322120081; Thu, 6 Mar 2014 17:18:39 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS032.bigfish.com (10.236.130.42) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 6 Mar 2014 17:18:38 +0000 Received: from BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 6 Mar 2014 17:18:37 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB705.namprd05.prod.outlook.com (10.141.207.11) with Microsoft SMTP Server (TLS) id 15.0.893.10; Thu, 6 Mar 2014 17:18:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.122]) with mapi id 15.00.0883.010; Thu, 6 Mar 2014 17:18:35 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: Ac85R3x2hs2pdNeiQoOvg0oaOcp59QAAeIoAAADtrYAAAbUzgAAAg0cAAADPR4AAAGF0gAABV5+A Date: Thu, 6 Mar 2014 17:18:34 +0000 Message-ID: References: <20140306143550.GF34026@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.12] x-forefront-prvs: 0142F22657 Content-Type: multipart/alternative; boundary="_000_CF3E5BD2608C8kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Xacnra6VqZEGRHMHNX9YNgDVeUc Cc: netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:18:47 -0000 --_000_CF3E5BD2608C8kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > I don't agree that is a mistake. > It is the most direct and efficient way to convey the intended > changes to the server implementation. No argument that granular-updates are great - forcing all implementation to= have to implement it is the mistake. A more modular approach would've all= owed implementation by more devices, as well as the creation of better adap= ters for those that don't. BTW, recall that I was the one that pushed for PATCH to be added the RESTCO= NF - I'm a huge supporter, but I don't think it needs to be a MUST. Thanks, Kent --_000_CF3E5BD2608C8kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
> I don't agree that is a mistake.
> It is the most direct and efficient way to convey the intended
> changes to the server implementation.


No argument that granular-updates are great – forcing all implem= entation to have to implement it is the mistake.  A more modular appro= ach would've allowed implementation by more devices, as well as the creatio= n of better adapters for those that don't.

BTW, recall that I was the one that pushed for PATCH to be added the R= ESTCONF – I'm a huge supporter, but I don't think it needs to be a MU= ST.

Thanks,
Kent

--_000_CF3E5BD2608C8kwatsenjunipernet_-- From nobody Thu Mar 6 09:20:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA8261A02AD for ; Thu, 6 Mar 2014 09:19:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BsyMuwD4vRc0 for ; Thu, 6 Mar 2014 09:19:56 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id A96ED1A028B for ; Thu, 6 Mar 2014 09:19:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7E7F01F00; Thu, 6 Mar 2014 18:19:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id R09tNuQCQmqg; Thu, 6 Mar 2014 18:19:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Thu, 6 Mar 2014 18:19:51 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 69E3C20045; Thu, 6 Mar 2014 18:19:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id z9NcPS3bRljB; Thu, 6 Mar 2014 18:19:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB9FE20017; Thu, 6 Mar 2014 18:19:49 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3341E2B98C22; Thu, 6 Mar 2014 18:19:48 +0100 (CET) Date: Thu, 6 Mar 2014 18:19:47 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140306171947.GA34810@elstar.local> Mail-Followup-To: Kent Watsen , Dean Bogdanovic , "netconf@ietf.org" References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <20140306162221.GC34547@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FRKLp1TaHQN9Ue-LwLQIlMLsNlg Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 17:19:58 -0000 On Thu, Mar 06, 2014 at 05:06:58PM +0000, Kent Watsen wrote: > > > >I somehow doubt that > > > > Further, this draft does not require Configlets to be > > signed, if loaded via a mechanism that asserts physical presence. or > > require those Configlets to have the device's unique identifier value > > set. All of these relaxations in Security are deemed acceptable > > because physical presence should only be accessible to trusted > > parties. > > > >will fly very high during security area review. Physical presence > >obviously not always imply trusted parties. There might be deployments > >where it does but in the general case it does not (and I personally > >believe that even deployments where people think it does it might > >actually not). > > > I think there is a good chance it will fly because there is precedent in > the TPM specification [1], which uses physical presence to perform certain > administrative functions. See section 10 (Physical Presence) in the > "Part 1: Design Principles" document. > > However, to your point, we'd still need their sign off. Since I'm on > friendly terms with sec folks (my other foot is in their area), I'll ask > the ADs when I see them next... > > [1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification > I am talking about the IETF. And it is not just physical presence, why would you trust the content on the USB stick to be valid? The argument someone can verify the content ad-hoc while plugging in the stick sounds not very convincing to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Mar 6 10:02:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D2E51A00E3 for ; Thu, 6 Mar 2014 10:02:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.048 X-Spam-Level: X-Spam-Status: No, score=-10.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvDO5Hi0eyUO for ; Thu, 6 Mar 2014 10:02:30 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) by ietfa.amsl.com (Postfix) with ESMTP id 384801A00BA for ; Thu, 6 Mar 2014 10:02:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1987; q=dns/txt; s=iport; t=1394128947; x=1395338547; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=hPKbIIFZdGSoo942vgOgHnKG9THtIY6p5Wgu2GQNbX8=; b=HyxxC/GSrjxbGopsNFsUDsREBJzr6hVVM1ElJf6mqnHYtipbYWADp5aI GgbgcAcLP94VoJNSaiSxS/ePCFx0HkqPbruSKPDl3CBcbCEDK/IuNyKXJ tn+jBFxrHyUL+C0NX08/9Epob0wxu4k3Y/Fm61BbyVr0eAV+Prd1ddr9v M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFACW3GFOQ/khL/2dsb2JhbABagwY7wSdPgRsWdIIlAQEBAwEBAQE1NgoBEAsOCgkWDwkDAgECARUwBgEMAQUCAQGHbQgNzzEXjlsHhDgBA4lMjnKGSothg0se X-IronPort-AV: E=Sophos;i="4.97,602,1389744000"; d="scan'208";a="2725101" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-3.cisco.com with ESMTP; 06 Mar 2014 18:02:26 +0000 Received: from [10.82.239.122] (rtp-vpn5-1907.cisco.com [10.82.239.122]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s26I2OQG017922; Thu, 6 Mar 2014 18:02:24 GMT Message-ID: <5318B82F.1060606@cisco.com> Date: Thu, 06 Mar 2014 13:02:23 -0500 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , Juergen Schoenwaelder , Dean Bogdanovic References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <20140306162221.GC34547@elstar.local> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fpyEEYWVyRcrVDcdPa3PtUyjm8M Cc: "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:02:32 -0000 On 3/6/14, 12:06 PM, Kent Watsen wrote: > > >> I somehow doubt that >> >> Further, this draft does not require Configlets to be >> signed, if loaded via a mechanism that asserts physical presence. or >> require those Configlets to have the device's unique identifier value >> set. All of these relaxations in Security are deemed acceptable >> because physical presence should only be accessible to trusted >> parties. >> >> will fly very high during security area review. Physical presence >> obviously not always imply trusted parties. There might be deployments >> where it does but in the general case it does not (and I personally >> believe that even deployments where people think it does it might >> actually not). > > > I think there is a good chance it will fly because there is precedent in > the TPM specification [1], which uses physical presence to perform certain > administrative functions. See section 10 (Physical Presence) in the > "Part 1: Design Principles" document. > > However, to your point, we'd still need their sign off. Since I'm on > friendly terms with sec folks (my other foot is in their area), I'll ask > the ADs when I see them next... > > > [1] http://www.trustedcomputinggroup.org/resources/tpm_main_specification Thanks for the pointer, Kent. In this section, though, I don't see the exact parallel to the USB stick idea. That is, in this TPM diagram the administrator isn't bringing anything other than herself into the secure area (i.e., having physical proximity to the device). With the USB example, the "malware" could be brought into the secure area without the administrator's knowledge (I agree, they should have checked first, but...). Getting strong security advice would be good. Joe > > > Thanks, > Kent > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Mar 6 10:17:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64D531A01AD for ; Thu, 6 Mar 2014 10:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id niCWpTUrfiOU for ; Thu, 6 Mar 2014 10:17:07 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 3CF401A0190 for ; Thu, 6 Mar 2014 10:17:05 -0800 (PST) Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta08.westchester.pa.mail.comcast.net with comcast id aELB1n0031c6gX858JH1nt; Thu, 06 Mar 2014 18:17:01 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta23.westchester.pa.mail.comcast.net with comcast id aJH01n00H2yZEBF3jJH0V4; Thu, 06 Mar 2014 18:17:01 +0000 From: "ietfdbh" To: "'Juergen Schoenwaelder'" , "'Dean Bogdanovic'" References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> <20140306170000.GA34736@elstar.local> In-Reply-To: <20140306170000.GA34736@elstar.local> Date: Thu, 6 Mar 2014 13:16:58 -0500 Message-ID: <038401cf3968$436be440$ca43acc0$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIZur/CKqDeD24mpnbHGJGexloSqgKVrIHuAhfLdQQBnlSEZQIgqjCdmfv3DLA= Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1394129821; bh=AELWPg7vMbHrzfAYGu/PS3ctq1uIkMrS97Ztsd14tRE=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=rITjRqBtHa148F201KtuELClFvo2c3WHMjJ914np4be8EEAS5PNsWRraX+Z0LRe/i 2GShzIn0RvjrvrYSUjBL6S22/77d1YQi2jFwiMnIgzQS1mAEuPUNU0ueyhJy89pXWw YaAknG7etxActZhz/CzpvAga6IyBtA/GmrUEg4n7oe+ASsDcjOdU9uGjYVjNsimAyR 4ZnmdljgzRp5tO2FMB7C9ZYltyGScQeTI2xnouKGFHxDrp/lNxXBfNVnqPtdCnvZyf qYkg3DrSCo+8iJ3x2ZJDFZqdt5ItStg2XrGzE/AUs7qhd/Kyf4Df3Bu4Rj4zj7ZAmy ZXoqNBE5Z6rtg== Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qLWDz90KADT-FUQo1ilFQazuEX0 Cc: 'Randy Presuhn' , netconf@ietf.org Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 18:17:09 -0000 +1 See RFC3365, BCP61 David Harrington ietfdbh@comcast.net +1-603-828-1401 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > Schoenwaelder > Sent: Thursday, March 06, 2014 12:00 PM > To: Dean Bogdanovic > Cc: Randy Presuhn; netconf@ietf.org > Subject: Re: [Netconf] Unsigned configlets and physical security > > On Thu, Mar 06, 2014 at 04:39:41PM +0000, Dean Bogdanovic wrote: > > Don't know. I was very surprised by the request from the operators (as it > opens up a big security whole), but they were very adamant about it. > > > > At the moment, anything that inconvenience their process is a hinderance. > > > > OTH, once they get burned, things might (I actually believe will) change. > This is the reason why I'm saying put it optional. If you put it mandatory, it will > hinder adoption. > > > > It needs to be mandatory to implement. If people then want to shoot > themself, let them do it. But it does not work to make this optional > to implement because this makes it hard for those who want to be > responsible. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Mar 6 12:14:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D66711A017D; Thu, 6 Mar 2014 12:14:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id shiK3nLBc_UZ; Thu, 6 Mar 2014 12:14:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id F1C3F1A0084; Thu, 6 Mar 2014 12:14:31 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 50AEC4775C7; Thu, 6 Mar 2014 21:14:26 +0100 (CET) Date: Thu, 06 Mar 2014 21:14:25 +0100 (CET) Message-Id: <20140306.211425.344710042.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bhypMnJG4MYrxIcL20JK64fJgJc Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 20:14:34 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+IE9uIDA1IE1hciAy MDE0LCBhdCAxNjozMSwgTWFydGluIEJqb3JrbHVuZCA8bWJqQHRhaWwtZi5jb20+IHdyb3RlOg0K PiANCj4gPiBIaSwNCj4gPiANCj4gPiBEYXZpZCBMYW1wYXJ0ZXIgPGVxdWlub3hAZGlhYzI0Lm5l dD4gd3JvdGU6DQo+ID4+IEhpLA0KPiA+PiANCj4gPj4gDQo+ID4+ICh0aGlzIGlzIHRoZSBtYWls IHZlcnNpb24gb2YgdGhlIHNvbWV3aGF0IGdhcmJsZWQgY29tbWVudCBvbiB0aGUgbWljKQ0KPiA+ PiANCj4gPj4gVGhlIG9yaWdpbmFsIHF1ZXN0aW9uIHdhcywgaG93IHRoZSBjb25maWd1cmVkIGRl dmljZSBjaG9vc2VzIGEgIlZQTiINCj4gPj4gZm9yDQo+ID4+IGVpdGhlciBpbmNvbWluZyBvciBv dXRnb2luZyBjb25uZWN0aW9ucy4gIFRoaXMgcmVmZXJyZWQgdG8gVlJGDQo+ID4+IGluc3RhbmNl cy4gIEluIHBhcnRpY3VsYXIsIGZvciB0aGUgdmVyeSBzaW1wbGVzdCBjYXNlIHdoZXJlIHRoaXMN Cj4gPj4gbWF0dGVycywgdGhlcmUgYXJlIGRldmljZXMgdGhhdCBoYXZlIG91dCBvZiBiYW5kIG1h bmFnZW1lbnQgcG9ydHMgYW5kDQo+ID4+IHRyZWF0IHRob3NlIGFzIGEgVlJGLiAgU28sIGJvdGgg Zm9yIGxpc3RlbmluZyBhbmQgZm9yIGNvbm5lY3RpbmcsIHRoZQ0KPiA+PiBkZXZpY2UgbmVlZHMg dG8gY2hvb3NlIGJldHdlZW4gIlZSLURlZmF1bHQiIGFuZCAiVlItTWdtdCIgKGFjdHVhbA0KPiA+ PiBuYW1lcywNCj4gPj4gZ3Vlc3MgdGhlIHZlbmRvci4pICBJdCBjb3VsZCBldmVuIGxpc3RlbiBp biBib3RoIFZSRnMsIHRvIGJlDQo+ID4+IG1hbmFnZWFibGUNCj4gPj4gaW5iYW5kIChub3JtYWwg b3BzIG1heWJlPykgYW5kIG91dCBvZiBiYW5kIChuZXR3b3JrIGluIGZsYW1lcz8pLg0KPiA+PiAN Cj4gPj4gRXZlbiB0aG91Z2ggdGhpcyB3YXMgcmFpc2VkIG9uIHRoZSBzZXJ2ZXIgY29uZmlnIG1v ZGVsLCB0aGlzIGlzIGENCj4gPj4gcmF0aGVyDQo+ID4+IGdlbmVyaWMgcHJvYmxlbS4gIEUuZy4g c3BlY2lmeWluZyBhIE5UUCBvciBTeXNsb2cgc2VydmVyIGhhcyB0aGUgc2FtZQ0KPiA+PiBpc3N1 ZS4gIChDYycgZnJvbSBuZXRjb25mIHRvIG5ldG1vZCBkdWUgdG8gdGhpcy4pDQo+ID4gDQo+ID4g SWYgSSB1bmRlcnN0YW5kIHRoaXMgY29ycmVjdGx5LCB0aGUgcHJvcG9zYWwgaXMgdG8gaW5jbHVk ZSBhIHJlZmVyZW5jZQ0KPiA+IHRvIGEgcm91dGluZy1pbnN0YW5jZSAocnQ6cm91dGluZy1pbnN0 YW5jZS1yZWYpIGluIGFsbCBjYXNlcyB3aGVyZSB3ZQ0KPiANCj4gSG1tLCBpdCBpcyBhY3R1YWxs eSBub3QgdGhhdCBzaW1wbGUuIEl0IGlzIHBvc3NpYmxlIHRvIGhhdmUgZGlmZmVyZW50IHR5cGVz IG9mDQo+IHJvdXRpbmcgaW5zdGFuY2VzIGRpc3Rpbmd1aXNoZWQgYnkgdGhlIOKAnHJ0OnR5cGXi gJ0gY2hpbGQuIFNvIGl0IGlzIG5vdCB0cnVlIHRoYXQNCj4gcm91dGluZy1pbnN0YW5jZSA9PSBW UkYgaW5zdGFuY2UuDQo+IA0KPiBUaGVyZWZvcmUsIHRoZSBjb3JyZWN0IGFwcHJvYWNoIGlzIElN TyB0aGlzOg0KPiANCj4gMS4gQSBtb2R1bGUgd2lsbCBiZSB3cml0dGVuIGRlZmluaW5nIHRoZSBW UkYgdHlwZSBvZiByb3V0aW5nIGluc3RhbmNlcyBhbmQNCj4gc3BlY2lmeWluZyB0aGUgc2VtYW50 aWNzIG9mIHRoaXMga2luZCBvZiB2aXJ0dWFsaXphdGlvbi4NCj4gDQo+IDIuIFdoZXJlIG5lY2Vz c2FyeSwgdnJmLWlkIGxlYWZzIHdpbGwgYmUgYWRkZWQgdG8gdGhlIGV4aXN0aW5nIG1vZHVsZSB2 aWENCj4gYXVnbWVudHMuDQo+IA0KPiBCZWZvcmUgdGhpcyBpcyBkb25lLCBhbHRlcm5hdGl2ZSAj MyBpbiBNYXJ0aW7igJlzIGxpc3QgKGkuZS4gZW5hYmxpbmcgc3RlcCAyDQo+IGFib3ZlKSBzZWVt cyB0byBiZSB0aGUgYmVzdCBvcHRpb24gYWZ0ZXIgYWxsLg0KDQpJIGZ1bGx5IGFncmVlIHdpdGgg dGhpcy4gIERlcGVuZGluZyBvbiB0aW1pbmcsIDIgYWJvdmUgY2FuIGJlIGRvbmUNCndpdGggYXVn bWVudGF0aW9uIG9yIGJ5IHJldmlzaW5nIHRoZSBleGlzdGluZyBtb2R1bGVzLg0KDQouLi4gYnV0 IHlvdSB3cml0ZSAiYSBtb2R1bGUgd2lsbCBiZSB3cml0dGVuIi4gIEl0IHdvbid0IHdyaXRlIGl0 c2VsZi4NCkhhcyBhbnlvbmUgdm9sdW50ZWVyZWQgdG8gd29yayBvbiB0aGlzPw0KDQoNCi9tYXJ0 aW4NCg== From nobody Thu Mar 6 15:03:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77C5A1A01AF; Thu, 6 Mar 2014 15:03:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.898 X-Spam-Level: X-Spam-Status: No, score=-0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GPQzvn0e8vIC; Thu, 6 Mar 2014 15:03:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6E3E81A00F1; Thu, 6 Mar 2014 15:03:21 -0800 (PST) Received: from [172.16.0.55] (80-46-118-65.static.dsl.as9105.com [80.46.118.65]) by mail.nic.cz (Postfix) with ESMTPSA id 0442E13F94C; Fri, 7 Mar 2014 00:03:11 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394146996; bh=0S6pIjYTgMfGBSnW3OMc2trG/7iiSsGb1SC4Ay33LDo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=niRC0v9w16Qfgl+ZBsDGb+pkWW6lq0Qru1ujIYltsSoTBNW1fVuSCtgfxwayBH4lF pKjw3XssN7Pr9eZdPH6qYllKmmYSnMfgJElDX8qbezo6U+vkeqOFBgmmCcHKr4/GIy ec/htl1ZBcECeDv0yuvhXa3rbQqUTrE177mU1WXU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: <20140306.211425.344710042.mbj@tail-f.com> Date: Thu, 6 Mar 2014 23:03:04 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wi9DORCekKoDP-RDkb30vRG__UQ Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Mar 2014 23:03:26 -0000 On 06 Mar 2014, at 20:14, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 05 Mar 2014, at 16:31, Martin Bjorklund wrote: >>=20 >>> Hi, >>>=20 >>> David Lamparter wrote: >>>> Hi, >>>>=20 >>>>=20 >>>> (this is the mail version of the somewhat garbled comment on the = mic) >>>>=20 >>>> The original question was, how the configured device chooses a = "VPN" >>>> for >>>> either incoming or outgoing connections. This referred to VRF >>>> instances. In particular, for the very simplest case where this >>>> matters, there are devices that have out of band management ports = and >>>> treat those as a VRF. So, both for listening and for connecting, = the >>>> device needs to choose between "VR-Default" and "VR-Mgmt" (actual >>>> names, >>>> guess the vendor.) It could even listen in both VRFs, to be >>>> manageable >>>> inband (normal ops maybe?) and out of band (network in flames?). >>>>=20 >>>> Even though this was raised on the server config model, this is a >>>> rather >>>> generic problem. E.g. specifying a NTP or Syslog server has the = same >>>> issue. (Cc' from netconf to netmod due to this.) >>>=20 >>> If I understand this correctly, the proposal is to include a = reference >>> to a routing-instance (rt:routing-instance-ref) in all cases where = we >>=20 >> Hmm, it is actually not that simple. It is possible to have different = types of >> routing instances distinguished by the =93rt:type=94 child. So it is = not true that >> routing-instance =3D=3D VRF instance. >>=20 >> Therefore, the correct approach is IMO this: >>=20 >> 1. A module will be written defining the VRF type of routing = instances and >> specifying the semantics of this kind of virtualization. >>=20 >> 2. Where necessary, vrf-id leafs will be added to the existing module = via >> augments. >>=20 >> Before this is done, alternative #3 in Martin=92s list (i.e. enabling = step 2 >> above) seems to be the best option after all. >=20 > I fully agree with this. Depending on timing, 2 above can be done > with augmentation or by revising the existing modules. >=20 > ... but you write "a module will be written". It won't write itself. > Has anyone volunteered to work on this? It should be a knowledgeable person who is interested in having the VRF = stuff implemented. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Fri Mar 7 01:32:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13A651A0164 for ; Fri, 7 Mar 2014 01:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1-aWY8Olpws for ; Fri, 7 Mar 2014 01:32:16 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 5374A1A0159 for ; Fri, 7 Mar 2014 01:32:16 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s279WAVL007034 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Fri, 7 Mar 2014 03:32:11 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s279W9Ub020187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 7 Mar 2014 10:32:09 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Fri, 7 Mar 2014 10:32:09 +0100 From: "Scharf, Michael (Michael)" To: "netconf@ietf.org" Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59ZrUKpGAgAEwpZA= Date: Fri, 7 Mar 2014 09:32:08 +0000 Message-ID: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140306.171321.298927830.mbj@tail-f.com> In-Reply-To: <20140306.171321.298927830.mbj@tail-f.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.41] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/FqUKZSvJ6COFmh5QpiPHCN72Ln0 Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 09:32:18 -0000 > > For RESTCONF, I think YANG-Patch SHOULD be supported. > > > > > > Why less than "MUST": > > > > 1. The PATCH operation is optional in HTTP. >=20 > Yes, in a "general-purpose server" (RFC 2616). In fact, only GET and > HEAD are mandatory in "general-purpose servers". But this is not a > general purpose server, and we decide which methods MUST be > implemented. I am new to this conversation. However, as far as I understood some comment= s yesterday in the ALTO sessions, there seems to be single suggestions that= RESTCONF, or parts of it, could be used in other working groups with diffe= rent use cases and requirements, such as ALTO. =20 Mandating an optional and complex HTTP method that is not supported by exis= ting running code (at least in ALTO) would certainly be an excellent reason= for such other WGs not to use RESTCONF at all. Michael From nobody Fri Mar 7 04:24:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 725D71A0218 for ; Fri, 7 Mar 2014 04:24:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AgDD2-QE4rZs for ; Fri, 7 Mar 2014 04:24:53 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 426301A01EC for ; Fri, 7 Mar 2014 04:24:53 -0800 (PST) Received: from mail54-co9-R.bigfish.com (10.236.132.226) by CO9EHSOBE035.bigfish.com (10.236.130.98) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 12:24:48 +0000 Received: from mail54-co9 (localhost [127.0.0.1]) by mail54-co9-R.bigfish.com (Postfix) with ESMTP id C44A1CC0362; Fri, 7 Mar 2014 12:24:48 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zz98dI9371I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail54-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(24454002)(377454003)(51704005)(199002)(189002)(50986001)(74662001)(47976001)(57306001)(82746002)(83322001)(15975445006)(74366001)(4396001)(87286001)(19580405001)(83716003)(94316002)(56816005)(81816001)(97186001)(74502001)(87936001)(92566001)(31966008)(88136002)(97336001)(83072002)(85852003)(89996001)(47736001)(49866001)(92726001)(94946001)(80976001)(65816001)(93136001)(81686001)(56776001)(85306002)(77156001)(93916002)(53806001)(76796001)(54316002)(76786001)(81342001)(36756003)(77982001)(81542001)(59766001)(86362001)(76482001)(95666003)(74876001)(62966002)(33656001)(74706001)(90146001)(47446002)(80022001)(46102001)(77096001)(95416001)(87266001)(2656002)(19580395003)(50226001)(51856001)(93516002)(79102001)(63696002)(66066001)(69226001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB779; H:BN1PR05MB424.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:FC32F5E4.A4DEDFDB.49CF6378.69EDE91.20269; PTR:InfoNoRecords; A:1; MX:1; L ANG:en; Received: from mail54-co9 (localhost.localdomain [127.0.0.1]) by mail54-co9 (MessageSwitch) id 1394195086394693_29613; Fri, 7 Mar 2014 12:24:46 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.244]) by mail54-co9.bigfish.com (Postfix) with ESMTP id 52375B000BE; Fri, 7 Mar 2014 12:24:46 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 12:24:46 +0000 Received: from CO2PR05MB779.namprd05.prod.outlook.com (10.141.226.154) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 12:24:45 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by CO2PR05MB779.namprd05.prod.outlook.com (10.141.226.154) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 7 Mar 2014 12:24:43 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.28]) with mapi id 15.00.0888.003; Fri, 7 Mar 2014 12:24:42 +0000 From: Dean Bogdanovic To: "Scharf, Michael (Michael)" Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59ZrUO1WAgAEiOwCAADA1AA== Date: Fri, 7 Mar 2014 12:24:41 +0000 Message-ID: <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> References: <20140306.171321.298927830.mbj@tail-f.com> <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> In-Reply-To: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.11] x-forefront-prvs: 014304E855 Content-Type: text/plain; charset="us-ascii" Content-ID: <3DB8EAF9567C4841BE18F144E77DE811@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wWY8C6EsK1vwyxTkT2ZFJwKLxsg Cc: "netconf@ietf.org" Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 12:24:55 -0000 Michael, Can you please clarify what would be the use case for ALTO to use RESTCONF?= PATCH method enable partial update , when the client just wants to change= one part of the resource state. Yes, you can achieve same functionality with GET of the state and then PUT = the entire thing back with the updated value. This is pretty heavy operatio= n. PATCH is lighter case. Dean On Mar 7, 2014, at 9:32 AM, "Scharf, Michael (Michael)" wrote: >>> For RESTCONF, I think YANG-Patch SHOULD be supported. >>>=20 >>>=20 >>> Why less than "MUST": >>>=20 >>> 1. The PATCH operation is optional in HTTP. >>=20 >> Yes, in a "general-purpose server" (RFC 2616). In fact, only GET and >> HEAD are mandatory in "general-purpose servers". But this is not a >> general purpose server, and we decide which methods MUST be >> implemented. >=20 > I am new to this conversation. However, as far as I understood some comme= nts yesterday in the ALTO sessions, there seems to be single suggestions th= at RESTCONF, or parts of it, could be used in other working groups with dif= ferent use cases and requirements, such as ALTO. >=20 > Mandating an optional and complex HTTP method that is not supported by ex= isting running code (at least in ALTO) would certainly be an excellent reas= on for such other WGs not to use RESTCONF at all. >=20 > Michael >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 >=20 From nobody Fri Mar 7 05:04:20 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 146691A01F5 for ; Fri, 7 Mar 2014 05:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yZJv90PFJkJa for ; Fri, 7 Mar 2014 05:04:18 -0800 (PST) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 58ECC1A00FC for ; Fri, 7 Mar 2014 05:04:17 -0800 (PST) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s27D4Ct4022496 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 7 Mar 2014 07:04:13 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s27D4BmZ030255 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 14:04:11 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 7 Mar 2014 14:04:11 +0100 From: "Scharf, Michael (Michael)" To: Dean Bogdanovic Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59ZrUKpGAgAEwpZCAACHNgIAAEXUg Date: Fri, 7 Mar 2014 13:04:10 +0000 Message-ID: <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <20140306.171321.298927830.mbj@tail-f.com> <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> In-Reply-To: <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.38] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3bRj4b5KW3Kzk8Tfr8UzAcnQNhY Cc: "netconf@ietf.org" Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 13:04:20 -0000 > Can you please clarify what would be the use case for ALTO to use > RESTCONF? Well, I currently try to figure out that question myself. I am new to RESTC= ONF, and obviously it has not been me who has suggested this. However, in ALTO yesterday I've raised the question on the mic whether REST= CONF is a protocol as simple as ALTO, and I've been told so. Mandating the = support of HTTP patch seems to contradict that statement. > PATCH method enable partial update , when the client just > wants to change one part of the resource state. ALTO doesn't change resource states. It reads network topology information = and allows certain kinds of query/ranking operations. In my current underst= anding, such use would not require HTTP patch. =20 > Yes, you can achieve same functionality with GET of the state and then > PUT the entire thing back with the updated value. This is pretty heavy > operation. PATCH is lighter case. ALTO only uses GET and POST (see draft-ietf-alto-protocol-27). Michael =20 > Dean > On Mar 7, 2014, at 9:32 AM, "Scharf, Michael (Michael)" > wrote: >=20 > >>> For RESTCONF, I think YANG-Patch SHOULD be supported. > >>> > >>> > >>> Why less than "MUST": > >>> > >>> 1. The PATCH operation is optional in HTTP. > >> > >> Yes, in a "general-purpose server" (RFC 2616). In fact, only GET > and > >> HEAD are mandatory in "general-purpose servers". But this is not a > >> general purpose server, and we decide which methods MUST be > >> implemented. > > > > I am new to this conversation. However, as far as I understood some > comments yesterday in the ALTO sessions, there seems to be single > suggestions that RESTCONF, or parts of it, could be used in other > working groups with different use cases and requirements, such as ALTO. > > > > Mandating an optional and complex HTTP method that is not supported > by existing running code (at least in ALTO) would certainly be an > excellent reason for such other WGs not to use RESTCONF at all. > > > > Michael > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > >=20 From nobody Fri Mar 7 08:57:17 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B1C01A02CE for ; Fri, 7 Mar 2014 08:57:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1B53vLXCe6Gp for ; Fri, 7 Mar 2014 08:57:14 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 1C0F31A02CD for ; Fri, 7 Mar 2014 08:57:14 -0800 (PST) Received: from mail159-co9-R.bigfish.com (10.236.132.249) by CO9EHSOBE014.bigfish.com (10.236.130.77) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 16:57:09 +0000 Received: from mail159-co9 (localhost [127.0.0.1]) by mail159-co9-R.bigfish.com (Postfix) with ESMTP id 4F8BE26027A; Fri, 7 Mar 2014 16:57:09 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail159-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(164054003)(199002)(189002)(83506001)(56816005)(69226001)(90146001)(86362001)(81342001)(81542001)(95666003)(74876001)(94946001)(93136001)(81816001)(2656002)(83072002)(85852003)(74706001)(81686001)(87266001)(74366001)(80976001)(87936001)(85306002)(92726001)(80022001)(77982001)(79102001)(63696002)(74662001)(65816001)(50986001)(47976001)(47736001)(54316002)(56776001)(76482001)(95416001)(4396001)(49866001)(1941001)(53806001)(54356001)(83322001)(46102001)(51856001)(74502001)(31966008)(97336001)(47446002)(92566001)(66066001)(93516002)(59766001)(97186001)(94316002)(76796001)(76786001)(77096001)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB425; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:2C44F255.4E2032B.F0C3338B.86E2C84C.2041C; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail159-co9 (localhost.localdomain [127.0.0.1]) by mail159-co9 (MessageSwitch) id 1394211427150824_19018; Fri, 7 Mar 2014 16:57:07 +0000 (UTC) Received: from CO9EHSMHS020.bigfish.com (unknown [10.236.132.226]) by mail159-co9.bigfish.com (Postfix) with ESMTP id 0FFA7C007C; Fri, 7 Mar 2014 16:56:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS020.bigfish.com (10.236.130.30) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 16:56:51 +0000 Received: from CO1PR05MB425.namprd05.prod.outlook.com (10.141.74.11) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 16:56:47 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB425.namprd05.prod.outlook.com (10.141.74.11) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 16:56:44 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 16:56:44 +0000 From: Kent Watsen To: ietfdbh , 'Juergen Schoenwaelder' , Dean Bogdanovic Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPN+VQXJRY3wt5xU21sJN7KFRgh5rUPQgAgAAEDQCAAAR4gIAABa0AgAAVgQCAAXvpgA== Date: Fri, 7 Mar 2014 16:56:43 +0000 Message-ID: References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> <20140306170000.GA34736@elstar.local> <038401cf3968$436be440$ca43acc0$@comcast.net> In-Reply-To: <038401cf3968$436be440$ca43acc0$@comcast.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 014304E855 Content-Type: text/plain; charset="us-ascii" Content-ID: <73553248F1C6994388C4FCD96B851CD6@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/dCQmxGvNzijSm5o80qIKrRlWJGg Cc: 'Randy Presuhn' , "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 16:57:16 -0000 So after consulting a number of folks, both in and out of the security area, we have the following: Regarding scope Opinions:=20 1. Take loading Configlets from anything other than a Configuration Server out of draft, since it's not a protocol and can be a vendor-specific option. Note, if we take it out, this entire discussion is mute. 2. Leave loading Configlets via physical presence in the draft, as it squarely addresses a common interest and specifies the draft's position on the matter. To some, since we're discussing on-boot behavior, if it's not specified, then it's implicitly not allowed. In fact, a statement to that effect is desired. My thoughts: Option #1 is a lot easier for us, but option #2 better serves the purpose, especially if willing to add a statement that anything not explicitly specified is disallowed. =20 Regarding signing: Opinions: 1. Require signature in all cases 2. Require signature for network-accessed Configlets and let vendors decide what is possible when via physical presence (e.g. SP- owned home equipment would require a signature, if said equipment supports physical-presence mechanism at all). Additionally, the Ability to use an unsigned Configlet for many devices (because they don't require a unique-identifier) resolves logistical deployment issues. My thoughts: My primary concern here is how easy it is on trusted administrators, as there is significant overhead involved in getting a Configlet signed. Please note that while the draft enables the signing role to be delegated to a 3rd-party, the delegation is unlikely to ever be to a specific customer (enterprise or SP), because that would enable the enterprise/SP to sign Configlets for devices that don't belong to them. Further, if we insist on a signature, then we would also need to insist on the device's unique-identifier being in the Configlet to thwart substitution attacks. This means that, for each device, trusted admins would have to go to the 3rd-party to get a Configlet signed, and they would have to insure that they loaded the right Configlet onto the right device. One thing we could do to improve the situation would be to allow a Configlet to contain a list of unique-identifiers (not just one), thus allowing one Configlet to be loaded by more than one device. Is it enough? FWIW, the only way I can imagine it being possible for a customer (enterprise/SP) to sign their own Configlets is if the customer receives customer-specific hardware that has been coded to trust a customer-specific trust-anchor, thus denying the ability for a Configlet signed by them to work on any other customer's equipment. Regarding encryption: (tangentially related) Opinions: 1. Encryption is undesirable, as inspection of the Configlet's contents is needed 2. Encryption is required, because content-inspection is undesirable. For instance, for home equipment, the SP doesn't want the end user to have any visibility into their network. My thoughts:=20 It is easy for the Configlet Signer to optionally encrypt a Confilglet using a device-specific public-key. Obviously this only works for Configlets destined for a single device, not containing more than one unique-identifier. I'm ok with this, is optional-encryption sufficient? To be clear: device MUST Support encryption, user can choose if they want to use it... Thanks, Kent From nobody Fri Mar 7 09:36:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D73051A02CE for ; Fri, 7 Mar 2014 09:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wdMIAm9FuBan for ; Fri, 7 Mar 2014 09:36:13 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe001.messaging.microsoft.com [216.32.181.181]) by ietfa.amsl.com (Postfix) with ESMTP id D84D71A01C2 for ; Fri, 7 Mar 2014 09:36:10 -0800 (PST) Received: from mail106-ch1-R.bigfish.com (10.43.68.245) by CH1EHSOBE001.bigfish.com (10.43.70.51) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 17:36:06 +0000 Received: from mail106-ch1 (localhost [127.0.0.1]) by mail106-ch1-R.bigfish.com (Postfix) with ESMTP id 26D064E037E; Fri, 7 Mar 2014 17:36:06 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail106-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(6009001)(428001)(164054003)(189002)(199002)(49866001)(4396001)(74662001)(47736001)(86362001)(76786001)(46102001)(93516002)(74876001)(77096001)(47446002)(2656002)(83322001)(54356001)(76796001)(56776001)(95416001)(94316002)(92566001)(74502001)(54316002)(76482001)(74706001)(36756003)(53806001)(47976001)(94946001)(97186001)(51856001)(81686001)(80976001)(97336001)(83506001)(81816001)(50986001)(85852003)(31966008)(87266001)(80022001)(85306002)(66066001)(90146001)(56816005)(95666003)(63696002)(79102001)(87936001)(83072002)(81542001)(92726001)(77982001)(65816001)(81342001)(74366001)(59766001)(93136001)(69226001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB709; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:EEB0F115.AC22C4D2.B0FE1D4B.86E4E6F9.2034E; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail106-ch1 (localhost.localdomain [127.0.0.1]) by mail106-ch1 (MessageSwitch) id 139421376578811_10343; Fri, 7 Mar 2014 17:36:05 +0000 (UTC) Received: from CH1EHSMHS041.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.237]) by mail106-ch1.bigfish.com (Postfix) with ESMTP id 0F5866005B; Fri, 7 Mar 2014 17:36:05 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS041.bigfish.com (10.43.69.250) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 17:36:04 +0000 Received: from BY2PR05MB709.namprd05.prod.outlook.com (10.141.222.142) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 17:36:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB709.namprd05.prod.outlook.com (10.141.222.142) with Microsoft SMTP Server (TLS) id 15.0.888.9; Fri, 7 Mar 2014 17:36:03 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 17:36:02 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , "Joe Clarke (jclarke)" , Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 Thread-Index: AQHPOKluHMSbakFCuUarhG99a5xYs5rSwkAAgAMj1IA= Date: Fri, 7 Mar 2014 17:36:01 +0000 Message-ID: References: <53177AA8.2000605@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 014304E855 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/H9ue3MB9TAgHzxh_lfZ7otw0_sg Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:36:15 -0000 > For this solution to be complete and interoperable, shouldn't we > define the DHCP option for configuration / configlets? Does this have to be defined in this draft, or can it be in a companion draft? Also, besides DHCP, is there anything else that needs to be scoped? Reinaldo, you mentioned using an Anycast address - do you mean for cases where the device is on the same subnet as a Configuration Server? - how would it work on the wire? > Also, for the same reason, shouldn't there be some mandatory URI > schemes (e.g. https/http)? OK, will add a MUST for https and http. > Why is this not a MUST? If I implement a configuration server, I'd > like to know where to put the configlets. Good point, this is under specified. I think it needs to be "device MUST first try the permutation of it using its fingerprint first and then MUST try the raw URI. Replying to Joe's comment, the raw URI is desirable for two reasons: 1) the DHCP-server may provide a device-specific URI and that URI doesn't have to be indexed by the device's public key (e.g. it might use serial-number) 2) the admin has a multi-device Configlet, the URI for which shouldn't be device-specific. > I don't think you should define a data model that is just copy & > pasted from ietf-system and ietf-netconf-server. Instead, I suggest > that the configlet simply is an XML file with initial configuration > for the device, matching whatever data models the device supports. > This allows vendor-specific config, but also other standard config. > In order to fully support the zerotouch procedure (with call-home), > ietf-netconf-server and ietf-system MUST be supported by the device. > (but I am not sure this is actually needed...) Don't we need a specific data-model for Configlet in order to carve out how unique identifier(s) are encoded? The draft has an error, it doesn't define unique identifiers are encoded - oops! Regarding the Configlet containing other data-models, this sounds good but I wonder about "merge" vs "replace"; currently the draft says that the device merges the Configlet into it's factory default configuration, but it seems that if a complete configuration were provided, it should replace what the device has. One way to resolve this would be to enable a Configlet to specify how it is to be applied (another reason to have a purpose-specific data-model)... Thanks, Kent From nobody Fri Mar 7 09:39:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCCF51A00AA; Fri, 7 Mar 2014 09:39:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.301 X-Spam-Level: X-Spam-Status: No, score=-2.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmcIVxTETTZc; Fri, 7 Mar 2014 09:39:54 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe002.messaging.microsoft.com [216.32.181.182]) by ietfa.amsl.com (Postfix) with ESMTP id 69EE61A0083; Fri, 7 Mar 2014 09:39:54 -0800 (PST) Received: from mail60-ch1-R.bigfish.com (10.43.68.235) by CH1EHSOBE013.bigfish.com (10.43.70.63) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 17:39:50 +0000 Received: from mail60-ch1 (localhost [127.0.0.1]) by mail60-ch1-R.bigfish.com (Postfix) with ESMTP id DDF4F407E1; Fri, 7 Mar 2014 17:39:49 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: 0 X-BigFish: VPS0(z579ehzda00hdc73hzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail60-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(46102001)(53806001)(77096001)(49866001)(81542001)(47736001)(36756003)(81342001)(47976001)(50986001)(4396001)(95416001)(93136001)(86362001)(94316002)(83072002)(93516002)(92566001)(558084003)(51856001)(74502001)(74662001)(76482001)(87266001)(65816001)(76796001)(56776001)(66066001)(47446002)(54316002)(54356001)(80022001)(59766001)(94946001)(79102001)(31966008)(85306002)(76786001)(2656002)(77982001)(63696002)(90146001)(56816005)(74706001)(95666003)(69226001)(83322001)(97336001)(85852003)(74366001)(80976001)(81686001)(92726001)(97186001)(81816001)(74876001)(87936001)(83506001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB776; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:DEEDC14C.63067EF.A8DDA3C1.C6EC907D.20090; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1 (MessageSwitch) id 139421398820375_28862; Fri, 7 Mar 2014 17:39:48 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.247]) by mail60-ch1.bigfish.com (Postfix) with ESMTP id EA9D12400FD; Fri, 7 Mar 2014 17:39:47 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 17:39:47 +0000 Received: from BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 17:39:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB776.namprd05.prod.outlook.com (10.141.224.154) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 17:39:43 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 17:39:43 +0000 From: Kent Watsen To: Ladislav Lhotka , =?iso-8859-1?Q?Martin_Bj=F6rklund?= Thread-Topic: [netmod] [Netconf] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections Thread-Index: AQHPOXi6TH1xB35f9UekZNtIqP0q55rUrYMAgAE3/AA= Date: Fri, 7 Mar 2014 17:39:42 +0000 Message-ID: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.mbj@tail-f.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 014304E855 Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/8n4_olFN0wCDIj3VVS2p9iFFcos Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:39:56 -0000 > It should be a knowledgeable person who is interested in having the VRF >stuff implemented. Not me, but I did verify with other routing experts that being able to do this is necessary... Any volunteers? K. From nobody Fri Mar 7 09:47:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EB601A00AA for ; Fri, 7 Mar 2014 09:47:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TxEONPV4YQ9n for ; Fri, 7 Mar 2014 09:47:36 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id AD3831A0083 for ; Fri, 7 Mar 2014 09:47:36 -0800 (PST) Received: from mail107-co9-R.bigfish.com (10.236.132.247) by CO9EHSOBE031.bigfish.com (10.236.130.94) with Microsoft SMTP Server id 14.1.225.22; Fri, 7 Mar 2014 17:47:32 +0000 Received: from mail107-co9 (localhost [127.0.0.1]) by mail107-co9-R.bigfish.com (Postfix) with ESMTP id 485593C0537; Fri, 7 Mar 2014 17:47:32 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -23 X-BigFish: VPS-23(zzbb2dI98dI9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL8275bh8275dh18c673h1de097h186068hz2fh109h2a8h839hbe3he5bhf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail107-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(428001)(189002)(199002)(24454002)(479174003)(377454003)(80976001)(15975445006)(90146001)(74662001)(31966008)(95666003)(77096001)(74366001)(16236675002)(81686001)(81816001)(85306002)(56816005)(83506001)(76786001)(76796001)(74502001)(74706001)(97336001)(97186001)(81342001)(81542001)(74876001)(47446002)(87936001)(93516002)(69226001)(87266001)(36756003)(2656002)(92566001)(80022001)(83072002)(46102001)(76482001)(56776001)(54316002)(86362001)(92726001)(53806001)(93136001)(54356001)(51856001)(94946001)(63696002)(66066001)(94316002)(65816001)(85852003)(77982001)(95416001)(79102001)(59766001)(47976001)(47736001)(49866001)(19580395003)(19580405001)(83322001)(50986001)(4396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB781; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:65D4C1D5.8D1A9109.4FD31C75.40F0D26D.203B6; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail107-co9 (localhost.localdomain [127.0.0.1]) by mail107-co9 (MessageSwitch) id 1394214450468894_8951; Fri, 7 Mar 2014 17:47:30 +0000 (UTC) Received: from CO9EHSMHS010.bigfish.com (unknown [10.236.132.229]) by mail107-co9.bigfish.com (Postfix) with ESMTP id 6DA3D720203; Fri, 7 Mar 2014 17:47:30 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS010.bigfish.com (10.236.130.20) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 7 Mar 2014 17:47:30 +0000 Received: from DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Fri, 7 Mar 2014 17:47:25 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by DM2PR05MB781.namprd05.prod.outlook.com (10.141.179.139) with Microsoft SMTP Server (TLS) id 15.0.893.10; Fri, 7 Mar 2014 17:47:23 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.210]) with mapi id 15.00.0893.001; Fri, 7 Mar 2014 17:47:22 +0000 From: Kent Watsen To: Jonathan Hansford , ian duncan , Joe Marcus Clarke Thread-Topic: [Netconf] Upgrade vs. downgrade Thread-Index: AQHPNwSOHWRjS9O94EyFPRLH23/EwJrPoQyAgAAU64CABjaUgA== Date: Fri, 7 Mar 2014 17:47:22 +0000 Message-ID: References: <5314B906.6090107@cisco.com> <5314CFE3.3030107@hansfords.net> In-Reply-To: <5314CFE3.3030107@hansfords.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.10] x-forefront-prvs: 014304E855 Content-Type: multipart/alternative; boundary="_000_CF3FB51061210kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/fgyp3y1-g6bw1iMvcwCA5f2BG_o Cc: "netconf@ietf.org" Subject: Re: [Netconf] Upgrade vs. downgrade X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 17:47:39 -0000 --_000_CF3FB51061210kwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The majority sentiment seems to be that the draft should not require images= to be greater than what the device is running. So no update to the text in the draft on this point. K. From: Jonathan Hansford > Date: Monday, March 3, 2014 6:54 PM To: ian duncan >, Joe Marcus Clarke > Cc: NetConf > Subject: Re: [Netconf] Upgrade vs. downgrade There may also be occasions where a few devices are moved from a system run= ning version n+1 to another running version n and it would be easier or eve= n necessary to downgrade the few than upgrade the many. Jonathan On 03/03/2014 17:39, ian duncan wrote: Hello -- Having taken to the mike to challenge Wes I offer the following. Believe I understand a desire to confirm one is NOT regressing to a more br= oken code image. What I'd wanted to question is whether the mechanism sugge= sted was suitable to achieve this goal, and in particular in a case where l= ittle to no correlation exists between the code running the initial ZTP fir= mware and the ultimate desired functional code image. Phrased as a question= , how can one presumptively infer from arbitrary version numbering embedded= that some code image has fewer issues--security related or otherwise? Thanks .. Ian On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clarke > wrote: A point was raised during the meeting that the ZeroTouch draft should allow= for an image _upgrade_ only (where new image has a version > old image). = There were counter points raised that as long as the image is signed, it sh= ouldn't matter the direction (up or down[grade]). I agree with the counter points. We have seen cases where a newer rev of c= ode (sometimes with newer features) includes new security bugs that can be = exploited when the older version of code is safe. To say we can only go up= doesn't protect the operator from a security vulnerability. Additionally, as was raised as a counter-point, operators may have a standa= rd image that they need for their environment (sometimes to have the device= work at all). This may be a down-revved image from what is shipped on the= device. I think we should allow for image moves in any direction as long as they ca= n be verified and validated as is pointed out in the draft currently. Joe _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf _______________________________________________ Netconf mailing list Netconf@ietf.orghttps://www.ietf.org/mailman/listi= nfo/netconf --_000_CF3FB51061210kwatsenjunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: <15E4B9699C56DF448B099DA8D862C4EE@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

The majority sentiment seems to be that the draft should not require i= mages to be greater than what the device is running.

So no update to the text in the draft on this point.   

K.


From: Jonathan Hansford <jonathan@hansfords.net>
Date: Monday, March 3, 2014 6:54 PM=
To: ian duncan <ian.hamish.duncan@gmail.com>, Joe Mar= cus Clarke <jclarke@cisco.com&g= t;
Cc: NetConf <netconf@ietf.org>
Subject: Re: [Netconf] Upgrade vs. = downgrade

There may also be occasions where= a few devices are moved from a system running version n+1 to another r= unning version n and it would be easier or even necessary to downgrade the = few than upgrade the many.

Jonathan

On 03/03/2014 17:39, ian duncan wrote:
Hello --

Having taken to the mike to challenge Wes I offer the following.

Believe I understand a desire to confirm one is NOT regressing to a mo= re broken code image. What I'd wanted to question is whether the mecha= nism suggested was suitable to achieve this goal, and in particular in a ca= se where little to no correlation exists between the code running the initial ZTP firmware and the ultimate desired= functional code image. Phrased as a question, how can one presumptively in= fer from arbitrary version numbering embedded that some code image has fewe= r issues--security related or otherwise?

Thanks .. Ian









On Mon, Mar 3, 2014 at 12:16 PM, Joe Marcus Clar= ke <jclarke@cisco.com> wrote:
A point was raised during the meeting that the ZeroTouch draft should allow= for an image _upgrade_ only (where new image has a version > old image)= .  There were counter points raised that as long as the image is signe= d, it shouldn't matter the direction (up or down[grade]).

I agree with the counter points.  We have seen cases where a newer rev= of code (sometimes with newer features) includes new security bugs that ca= n be exploited when the older version of code is safe.  To say we can = only go up doesn't protect the operator from a security vulnerability.

Additionally, as was raised as a counter-point, operators may have a standa= rd image that they need for their environment (sometimes to have the device= work at all).  This may be a down-revved image from what is shipped o= n the device.

I think we should allow for image moves in any direction as long as they ca= n be verified and validated as is pointed out in the draft currently.

Joe

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf= 



_______________________________________________
Netconf mailing list
Netc=
onf@ietf.orghttps://www.ietf.org/mailman/listinfo/netcon=
f

 --_000_CF3FB51061210kwatsenjunipernet_-- From nobody Fri Mar 7 10:02:21 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0F941A02BB for ; Fri, 7 Mar 2014 10:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YqAnjBu1lXv for ; Fri, 7 Mar 2014 10:02:18 -0800 (PST) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 3A28E1A0274 for ; Fri, 7 Mar 2014 10:02:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3585; q=dns/txt; s=iport; t=1394215334; x=1395424934; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=EnJkbKgmxxunzLW6mIc7415vmC6AxEnR+OyOaSCSYYo=; b=OyLYDjhSfuatwSYvr5SVR1ufqFzfgCIo8knFG3Bx/1uHJaqd3y4qfT9w ZOx71OD3D29muNBCaGZPxxeX7WpqOQKXoqo89rUOiKFGpn8nVHnNbu41r amu/rgugdlsDRPI9irZ5TuT0CxtTNTZrve2Uk7tgk4WYdvn70FeI35GEy g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMFANkIGlOtJXG8/2dsb2JhbABagwY7V8ElgRMWdIIlAQEBAwE6RAsCAQgOAwQBAQsUEDIdCAIEARIIE4dWCNAqF44qOIMkgRQElFeWF4Mtgis X-IronPort-AV: E=Sophos;i="4.97,609,1389744000"; d="scan'208";a="308798891" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-8.cisco.com with ESMTP; 07 Mar 2014 18:02:14 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s27I2DOG011211 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 7 Mar 2014 18:02:13 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.27]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Fri, 7 Mar 2014 12:02:13 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Joe Clarke (jclarke)" , Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 Thread-Index: AQHPOKluNQy0LmVRJUO31aQjk4+E65rSwkAAgAOIbID//6FDyQ== Date: Fri, 7 Mar 2014 18:02:12 +0000 Message-ID: <45A697A8FFD7CF48BCF2BE7E106F06040B832F88@xmb-rcd-x04.cisco.com> References: <53177AA8.2000605@cisco.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.116.43] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Xkof6VYq_UU8MRxMcturSSTjrrU Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:02:20 -0000 In the case of Anycast configuration server can be anywhere. It is just lik= e regular routing, but you have a special address (_not_ a private address)= .=0A= =0A= =0A= For those that want this draft to solve the reverse NAT problem DHCP is pro= bably not an option. Being behind a NAT means having a local DHCP server th= at is probably another administrative domain. ]And DHCP options are not rel= ayed from one domain to another, there is no standard that dictates what sh= ould be done. =0A= =0A= ________________________________________=0A= From: Kent Watsen [kwatsen@juniper.net]=0A= Sent: Friday, March 07, 2014 9:36 AM=0A= To: Reinaldo Penno (repenno); Joe Clarke (jclarke); Martin Bjorklund; netco= nf@ietf.org=0A= Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01=0A= =0A= > For this solution to be complete and interoperable, shouldn't we=0A= > define the DHCP option for configuration / configlets?=0A= =0A= Does this have to be defined in this draft, or can it be in a companion=0A= draft? Also, besides DHCP, is there anything else that needs to be scoped?= =0A= =0A= Reinaldo, you mentioned using an Anycast address - do you mean for cases=0A= where the device is on the same subnet as a Configuration Server? - how=0A= would it work on the wire?=0A= =0A= =0A= =0A= =0A= > Also, for the same reason, shouldn't there be some mandatory URI=0A= > schemes (e.g. https/http)?=0A= =0A= OK, will add a MUST for https and http.=0A= =0A= =0A= =0A= =0A= > Why is this not a MUST? If I implement a configuration server, I'd=0A= > like to know where to put the configlets.=0A= =0A= Good point, this is under specified. I think it needs to be "device=0A= MUST first try the permutation of it using its fingerprint first and=0A= then MUST try the raw URI.=0A= =0A= Replying to Joe's comment, the raw URI is desirable for two reasons:=0A= =0A= 1) the DHCP-server may provide a device-specific URI and that=0A= URI doesn't have to be indexed by the device's public key=0A= (e.g. it might use serial-number)=0A= =0A= 2) the admin has a multi-device Configlet, the URI for which=0A= shouldn't be device-specific.=0A= =0A= =0A= =0A= > I don't think you should define a data model that is just copy &=0A= > pasted from ietf-system and ietf-netconf-server. Instead, I suggest=0A= > that the configlet simply is an XML file with initial configuration=0A= > for the device, matching whatever data models the device supports.=0A= > This allows vendor-specific config, but also other standard config.=0A= > In order to fully support the zerotouch procedure (with call-home),=0A= > ietf-netconf-server and ietf-system MUST be supported by the device.=0A= > (but I am not sure this is actually needed...)=0A= =0A= =0A= =0A= Don't we need a specific data-model for Configlet in order to carve=0A= out how unique identifier(s) are encoded? The draft has an error,=0A= it doesn't define unique identifiers are encoded - oops!=0A= =0A= Regarding the Configlet containing other data-models, this sounds good=0A= but I wonder about "merge" vs "replace"; currently the draft says that=0A= the device merges the Configlet into it's factory default configuration,=0A= but it seems that if a complete configuration were provided, it should=0A= replace what the device has. One way to resolve this would be to enable=0A= a Configlet to specify how it is to be applied (another reason to have=0A= a purpose-specific data-model)...=0A= =0A= =0A= Thanks,=0A= Kent=0A= =0A= =0A= From nobody Fri Mar 7 10:50:56 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C1C11A00FE for ; Fri, 7 Mar 2014 10:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.848 X-Spam-Level: X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_29=0.6, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5fVE4L-QiIhh for ; Fri, 7 Mar 2014 10:50:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id D89371A006B for ; Fri, 7 Mar 2014 10:50:52 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id C15CD3943E8; Fri, 7 Mar 2014 19:50:47 +0100 (CET) Date: Fri, 07 Mar 2014 19:50:47 +0100 (CET) Message-Id: <20140307.195047.68386870.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <53177AA8.2000605@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HfFqqyLLJYNK_UDtgp3T2E_7Io4 Cc: netconf@ietf.org Subject: Re: [Netconf] comments on draft-kwatsen-netconf-zerotouch-01 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:50:55 -0000 Kent Watsen wrote: > > > For this solution to be complete and interoperable, shouldn't we > > define the DHCP option for configuration / configlets? > > Does this have to be defined in this draft, or can it be in a companion > draft? A separate document is fine with me. Then this document should reference the other one. > > I don't think you should define a data model that is just copy & > > pasted from ietf-system and ietf-netconf-server. Instead, I suggest > > that the configlet simply is an XML file with initial configuration > > for the device, matching whatever data models the device supports. > > This allows vendor-specific config, but also other standard config. > > In order to fully support the zerotouch procedure (with call-home), > > ietf-netconf-server and ietf-system MUST be supported by the device. > > (but I am not sure this is actually needed...) > > > > Don't we need a specific data-model for Configlet in order to carve > out how unique identifier(s) are encoded? I don't understand what you mean. Can you elaborate? > Regarding the Configlet containing other data-models, this sounds good > but I wonder about "merge" vs "replace"; currently the draft says that > the device merges the Configlet into it's factory default configuration, > but it seems that if a complete configuration were provided, it should > replace what the device has. One way to resolve this would be to enable > a Configlet to specify how it is to be applied (another reason to have > a purpose-specific data-model)... Well, this *could* be done in the XML file itself, e.g., by using the nc:operation attribute: ... But I think we could state that the config is merged, even if the file contains more than just a subset of system and netconf-server. /martin From nobody Fri Mar 7 11:20:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C9B1A01E4 for ; Fri, 7 Mar 2014 11:20:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 09MYSlW-j-qC for ; Fri, 7 Mar 2014 11:20:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id A2C1A1A01D6 for ; Fri, 7 Mar 2014 11:20:18 -0800 (PST) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 1E2C03943E8; Fri, 7 Mar 2014 20:20:13 +0100 (CET) Date: Fri, 07 Mar 2014 20:20:12 +0100 (CET) Message-Id: <20140307.202012.220855133.mbj@tail-f.com> To: michael.scharf@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Ga1EADmIPVbj2wNtS6rD0hhi5cE Cc: netconf@ietf.org Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 19:20:21 -0000 Hi, "Scharf, Michael (Michael)" wrote: > > Can you please clarify what would be the use case for ALTO to use > > RESTCONF? > > Well, I currently try to figure out that question myself. I am new to RESTCONF, > and obviously it has not been me who has suggested this. > > However, in ALTO yesterday I've raised the question on the mic whether RESTCONF > is a protocol as simple as ALTO, and I've been told so. Mandating the support > of HTTP patch seems to contradict that statement. Obviously, if the RESTCONF server only supports read-only data models, it doesn't need to support PUT or PATCH. This should be be clarified in the document. > > PATCH method enable partial update , when the client just > > wants to change one part of the resource state. > > ALTO doesn't change resource states. It reads network topology information and > allows certain kinds of query/ranking operations. In my current understanding, > such use would not require HTTP patch. Right. > > Yes, you can achieve same functionality with GET of the state and then > > PUT the entire thing back with the updated value. This is pretty heavy > > operation. PATCH is lighter case. > > ALTO only uses GET and POST (see draft-ietf-alto-protocol-27). Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the data model from the protocol, and "just" define a YANG module with the necessary data: module ietf-alto { ... container alto { container network-map { list netloc { ... } } container cost-map { ... } } } It should be noted that RESTCONF currently does not support a "query" interface like the "filtered"-thingie in ALTO. However, I believe such a mechanism should be addded to RESTCONF. /martin From nobody Fri Mar 7 16:58:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092331A018C for ; Fri, 7 Mar 2014 16:58:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.278 X-Spam-Level: X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjKEZrpojdkO for ; Fri, 7 Mar 2014 16:58:36 -0800 (PST) Received: from mail-qg0-f45.google.com (mail-qg0-f45.google.com [209.85.192.45]) by ietfa.amsl.com (Postfix) with ESMTP id 99CF21A0183 for ; Fri, 7 Mar 2014 16:58:36 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id j5so13708371qga.4 for ; Fri, 07 Mar 2014 16:58:32 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=dY2EA4fpYO2/SL+Uz07Jt8ZQhtULS1rBYSDk3ljYzaI=; b=VmH+SjRGA1FufhmziUWogwy4rihULq7nAkBO0+GsdbWU8WtEKt9J7ZlO5aAvHM6/6q gu852I/xZI3TnBdEUiuKOYav5CJDf5cxPPZCb//XvAlHDctW3sYdPb7yTEP/Gjiasx57 zEJZZ4QX0Pr2gVvCB+uZ34Q6qnbcjrIpjji1c7ut1hV+A0RTdCK15TPQtLWLPT+SWCHh f981MXJ07HoFWRDDSA/U/B1THAqhqnoIqWK7m9WCKjBZGavj5AGxUHBGy1QG0TM47MKg /Z3qyo5m7KjU0Kxc+3XWIlisXzWxauMUPlmEOaP5ViZexlVqsBr4rRllmk3khVlwWT2F hGqA== X-Gm-Message-State: ALoCoQl55kcW6qCr4fgQmDB30gyLx23hKk0+qaFqz8KI77LdzFqkzDo2NJJ3DbxzQuZ/gW8bAn+/ MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr23815398qge.91.1394240311984; Fri, 07 Mar 2014 16:58:31 -0800 (PST) Received: by 10.140.104.194 with HTTP; Fri, 7 Mar 2014 16:58:31 -0800 (PST) In-Reply-To: <20140307.202012.220855133.mbj@tail-f.com> References: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140307.202012.220855133.mbj@tail-f.com> Date: Fri, 7 Mar 2014 16:58:31 -0800 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a1134f2be871a8b04f40dde23 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_axnHwMe9VAhwNc8CSbx0mxJ5VI Cc: Netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 00:58:38 -0000 --001a1134f2be871a8b04f40dde23 Content-Type: text/plain; charset=ISO-8859-1 Hi, Maybe SHOULD instead of MUST is OK. I realized that confirmed-commit is totally optional to implement, and that has not stopped developers who want to support network rollback in the device. The market may favor devices with complete APIs over incomplete ones. Devices with severely broken or unusable editing capabilities should not stay around long. Small devices that need to reload an entire subtree (maybe even the whole config) with a PUT may only disrupt themselves, not the entire network. Andy On Fri, Mar 7, 2014 at 11:20 AM, Martin Bjorklund wrote: > Hi, > > "Scharf, Michael (Michael)" wrote: > > > Can you please clarify what would be the use case for ALTO to use > > > RESTCONF? > > > > Well, I currently try to figure out that question myself. I am new to > RESTCONF, > > and obviously it has not been me who has suggested this. > > > > However, in ALTO yesterday I've raised the question on the mic whether > RESTCONF > > is a protocol as simple as ALTO, and I've been told so. Mandating the > support > > of HTTP patch seems to contradict that statement. > > Obviously, if the RESTCONF server only supports read-only data models, > it doesn't need to support PUT or PATCH. This should be be clarified > in the document. > > > > PATCH method enable partial update , when the client just > > > wants to change one part of the resource state. > > > > ALTO doesn't change resource states. It reads network topology > information and > > allows certain kinds of query/ranking operations. In my current > understanding, > > such use would not require HTTP patch. > > Right. > > > > Yes, you can achieve same functionality with GET of the state and then > > > PUT the entire thing back with the updated value. This is pretty heavy > > > operation. PATCH is lighter case. > > > > ALTO only uses GET and POST (see draft-ietf-alto-protocol-27). > > Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the > data model from the protocol, and "just" define a YANG module with the > necessary data: > > module ietf-alto { > ... > container alto { > container network-map { > list netloc { > ... > } > } > container cost-map { > ... > } > } > } > > > It should be noted that RESTCONF currently does not support a "query" > interface like the "filtered"-thingie in ALTO. However, I believe > such a mechanism should be addded to RESTCONF. > > > > /martin > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1134f2be871a8b04f40dde23 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Maybe SHOULD instead of MUST is OK.=
I realized that confirmed-commit is totally optional to implemen= t,
and that has not stopped developers who want to support
network rollback in the device.

The market ma= y favor devices with complete APIs over incomplete ones.
Devices = with severely broken or unusable editing capabilities should not
stay around long. =A0Small devices that need to reload an entire subtree
(maybe even the whole config) with a PUT may only disrupt themselve= s,
not the entire network.

Andy



On Fri, Mar 7, 2014 at 11:20 AM, Martin Bjorklund <<= a href=3D"mailto:mbj@tail-f.com" target=3D"_blank">mbj@tail-f.com> wrote:
Hi,

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> wrote:
> > Can you please clarify what would be the use case for ALTO to use=
> > RESTCONF?
>
> Well, I currently try to figure out that question myself. I am new to = RESTCONF,
> and obviously it has not been me who has suggested this.
>
> However, in ALTO yesterday I've raised the question on the mic whe= ther RESTCONF
> is a protocol as simple as ALTO, and I've been told so. Mandating = the support
> of HTTP patch seems to contradict that statement.

Obviously, if the RESTCONF server only supports read-only data models,
it doesn't need to support PUT or PATCH. =A0This should be be clarified=
in the document.

> > =A0PATCH method enable partial update , when the client just
> > wants to change one part of the resource state.
>
> ALTO doesn't change resource states. It reads network topology inf= ormation and
> allows certain kinds of query/ranking operations. In my current unders= tanding,
> such use would not require HTTP patch.

Right.

> > Yes, you can achieve same functionality with GET of the state and= then
> > PUT the entire thing back with the updated value. This is pretty = heavy
> > operation. PATCH is lighter case.
>
> ALTO only uses GET and POST (see draft-ietf-alto-protocol-27).

Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the
data model from the protocol, and "just" define a YANG module wit= h the
necessary data:

=A0 module ietf-alto {
=A0 =A0 ...
=A0 =A0 container alto {
=A0 =A0 =A0 container network-map {
=A0 =A0 =A0 =A0 list netloc {
=A0 =A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }
=A0 =A0 =A0 container cost-map {
=A0 =A0 =A0 =A0 ...
=A0 =A0 =A0 }
=A0 =A0 }
=A0 }


It should be noted that RESTCONF currently does not support a "query&q= uot;
interface like the "filtered"-thingie in ALTO. =A0However, I beli= eve
such a mechanism should be addded to RESTCONF.



/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

--001a1134f2be871a8b04f40dde23-- From nobody Fri Mar 7 23:57:25 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A8521A027F; Fri, 7 Mar 2014 23:57:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.198 X-Spam-Level: X-Spam-Status: No, score=-1.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.547] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e0TIHyV7zyrR; Fri, 7 Mar 2014 23:57:22 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 6EF641A0225; Fri, 7 Mar 2014 23:57:22 -0800 (PST) Received: from [192.168.42.206] (37-48-34-84.tmcz.cz [37.48.34.84]) by mail.nic.cz (Postfix) with ESMTPSA id E4A7B13F9F4; Sat, 8 Mar 2014 08:57:16 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1394265437; bh=FTgw98P59pyc8hHP46jVwc6rONgcGDaVrgNd7gcYIaU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=beX2Jn51AYPNIXzqQW6+1HIXY6LsG8HraJNceJZdvcvi3JbIT47SRqgzKjDDbLYKD +WYM+baw9wLDk/PxOOkFyH2DNa4Ie7SPumHa1CiJc6+3+ur4NX5/w0Z8zyC+6dn3Ra AC5U43M3bO6d+p8ZKkPmRt8ydE7Y5a9bHPTC0ibU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) From: Ladislav Lhotka In-Reply-To: Date: Sat, 8 Mar 2014 08:57:15 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140303140039.GZ856433@jupiter.n2.diac24.net> <20140305.163154.391777655.mbj@tail-f.com> <48B5B401-32B6-4928-B917-1D32421B4244@nic.cz> <20140306.211425.344710042.mbj@tail-f.com> To: Kent Watsen X-Mailer: Apple Mail (2.1874) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IWqwVRjnu7kEv1fIMV_RNK4sawA Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] draft-kwatsen-netconf-server / VRF specification for listening ports & outgoing connections X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Mar 2014 07:57:23 -0000 On 07 Mar 2014, at 18:39, Kent Watsen wrote: >=20 >> It should be a knowledgeable person who is interested in having the = VRF >> stuff implemented. >=20 > Not me, but I did verify with other routing experts that being able to = do > this is necessary=85 >=20 > Any volunteers? I am prepared to help them integrate this work into the core routing = model. Lada >=20 >=20 > K. >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Mar 9 04:32:36 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E5EE1A01C9 for ; Sun, 9 Mar 2014 04:32:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UWxZqX93Pizj for ; Sun, 9 Mar 2014 04:32:32 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id CC38D1A017B for ; Sun, 9 Mar 2014 04:32:32 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s29BWQea009537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 06:32:27 -0500 (CDT) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s29BWPcp007215 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 12:32:25 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Sun, 9 Mar 2014 12:32:25 +0100 From: "Scharf, Michael (Michael)" To: Martin Bjorklund Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59ZrUKpGAgAEwpZCAACHNgIAAEXUggABiowCAArBNIA== Date: Sun, 9 Mar 2014 11:32:24 +0000 Message-ID: <655C07320163294895BBADA28372AF5D2135FD@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140307.202012.220855133.mbj@tail-f.com> In-Reply-To: <20140307.202012.220855133.mbj@tail-f.com> Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/TrIKABbfym3wGCZoT-MXxW9tcaQ Cc: "netconf@ietf.org" Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 11:32:34 -0000 > > However, in ALTO yesterday I've raised the question on the mic > whether RESTCONF > > is a protocol as simple as ALTO, and I've been told so. Mandating the > support > > of HTTP patch seems to contradict that statement. >=20 > Obviously, if the RESTCONF server only supports read-only data models, > it doesn't need to support PUT or PATCH. This should be be clarified > in the document. Yes, I think read-only access should be made simple, if non-configuration u= se of RESTCONF should become relevant. Michael From nobody Sun Mar 9 06:05:10 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EAB71A033A for ; Sun, 9 Mar 2014 06:05:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.899 X-Spam-Level: X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XmcOI3OkLLL1 for ; Sun, 9 Mar 2014 06:05:02 -0700 (PDT) Received: from hoemail2.alcatel.com (hoemail2.alcatel.com [192.160.6.149]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0451A0207 for ; Sun, 9 Mar 2014 06:05:01 -0700 (PDT) Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by hoemail2.alcatel.com (8.13.8/IER-o) with ESMTP id s29D4sZp025986 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Sun, 9 Mar 2014 08:04:55 -0500 (CDT) Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id s29D4qX9000685 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sun, 9 Mar 2014 14:04:52 +0100 Received: from FR712WXCHMBA15.zeu.alcatel-lucent.com ([169.254.7.146]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Sun, 9 Mar 2014 14:04:51 +0100 From: "Scharf, Michael (Michael)" To: Andy Bierman , Martin Bjorklund Thread-Topic: [Netconf] YANG Patch Optional or Mandatory Thread-Index: AQHPOVNlhs2pdNeiQoOvg0oaOcp59ZrUKpGAgAEwpZCAACHNgIAAEXUggABiowCAAF6GgIACaWZg Date: Sun, 9 Mar 2014 13:04:50 +0000 Message-ID: <655C07320163294895BBADA28372AF5D21385E@FR712WXCHMBA15.zeu.alcatel-lucent.com> References: <655C07320163294895BBADA28372AF5D212174@FR712WXCHMBA15.zeu.alcatel-lucent.com> <219D2BCB-0988-4E28-922F-98835088129F@juniper.net> <655C07320163294895BBADA28372AF5D212918@FR712WXCHMBA15.zeu.alcatel-lucent.com> <20140307.202012.220855133.mbj@tail-f.com> In-Reply-To: Accept-Language: de-DE, en-US Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: multipart/alternative; boundary="_000_655C07320163294895BBADA28372AF5D21385EFR712WXCHMBA15zeu_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NxdRc_HWTHpOxAYIyn7CceTB_6o Cc: Netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Mar 2014 13:05:08 -0000 --_000_655C07320163294895BBADA28372AF5D21385EFR712WXCHMBA15zeu_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Regarding the "network": In ALTO use cases, there can be HTTP proxies on th= e path between client and server, because they can be located in different = domains. I don't fully understand so far whether proxies could be an issue if we use= d (parts of) RESTCONF. Michael From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Saturday, March 08, 2014 1:59 AM To: Martin Bjorklund Cc: Scharf, Michael (Michael); Netconf Subject: Re: [Netconf] YANG Patch Optional or Mandatory Hi, Maybe SHOULD instead of MUST is OK. I realized that confirmed-commit is totally optional to implement, and that has not stopped developers who want to support network rollback in the device. The market may favor devices with complete APIs over incomplete ones. Devices with severely broken or unusable editing capabilities should not stay around long. Small devices that need to reload an entire subtree (maybe even the whole config) with a PUT may only disrupt themselves, not the entire network. Andy On Fri, Mar 7, 2014 at 11:20 AM, Martin Bjorklund > wrote: Hi, "Scharf, Michael (Michael)" > wrote: > > Can you please clarify what would be the use case for ALTO to use > > RESTCONF? > > Well, I currently try to figure out that question myself. I am new to RES= TCONF, > and obviously it has not been me who has suggested this. > > However, in ALTO yesterday I've raised the question on the mic whether RE= STCONF > is a protocol as simple as ALTO, and I've been told so. Mandating the sup= port > of HTTP patch seems to contradict that statement. Obviously, if the RESTCONF server only supports read-only data models, it doesn't need to support PUT or PATCH. This should be be clarified in the document. > > PATCH method enable partial update , when the client just > > wants to change one part of the resource state. > > ALTO doesn't change resource states. It reads network topology informatio= n and > allows certain kinds of query/ranking operations. In my current understan= ding, > such use would not require HTTP patch. Right. > > Yes, you can achieve same functionality with GET of the state and then > > PUT the entire thing back with the updated value. This is pretty heavy > > operation. PATCH is lighter case. > > ALTO only uses GET and POST (see draft-ietf-alto-protocol-27). Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the data model from the protocol, and "just" define a YANG module with the necessary data: module ietf-alto { ... container alto { container network-map { list netloc { ... } } container cost-map { ... } } } It should be noted that RESTCONF currently does not support a "query" interface like the "filtered"-thingie in ALTO. However, I believe such a mechanism should be addded to RESTCONF. /martin _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf --_000_655C07320163294895BBADA28372AF5D21385EFR712WXCHMBA15zeu_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Regarding = the “network”: In ALTO use cases, there can be HTTP proxies on = the path between client and server, because they can be located in differen= t domains.

 = ;

I don̵= 7;t fully understand so far whether proxies could be an issue if we used (p= arts of) RESTCONF.

 = ;

Michael

 = ;

 = ;

From: Andy Bie= rman [mailto:andy@yumaworks.com]
Sent: Saturday, March 08, 2014 1:59 AM
To: Martin Bjorklund
Cc: Scharf, Michael (Michael); Netconf
Subject: Re: [Netconf] YANG Patch Optional or Mandatory

 

Hi,

 

Maybe SHOULD instead of MUST is OK.

I realized that confirmed-commit is totally optional= to implement,

and that has not stopped developers who want to supp= ort

network rollback in the device.

 

The market may favor devices with complete APIs over= incomplete ones.

Devices with severely broken or unusable editing cap= abilities should not

stay around long.  Small devices that need to r= eload an entire subtree

(maybe even the whole config) with a PUT may only di= srupt themselves,

not the entire network.

 

Andy

 

 

On Fri, Mar 7, 2014 at 11:20 AM, Martin Bjorklund &l= t;mbj@tail-f.com>= ; wrote:

Hi,

"Scharf, Michael (Michael)" <michael.scharf@alcatel-lucent.com> wrote:
> > Can you please clarify what would be the use case for ALTO to use=
> > RESTCONF?
>
> Well, I currently try to figure out that question myself. I am new to = RESTCONF,
> and obviously it has not been me who has suggested this.
>
> However, in ALTO yesterday I've raised the question on the mic whether= RESTCONF
> is a protocol as simple as ALTO, and I've been told so. Mandating the = support
> of HTTP patch seems to contradict that statement.

Obviously, if the RESTCONF server only supports read-only data models,
it doesn't need to support PUT or PATCH.  This should be be clarified<= br> in the document.

> >  PATCH method enable partial update , when the client just > > wants to change one part of the resource state.
>
> ALTO doesn't change resource states. It reads network topology informa= tion and
> allows certain kinds of query/ranking operations. In my current unders= tanding,
> such use would not require HTTP patch.

Right.

> > Yes, you can achieve same functionality with GET of the state and= then
> > PUT the entire thing back with the updated value. This is pretty = heavy
> > operation. PATCH is lighter case.
>
> ALTO only uses GET and POST (see draft-ietf-alto-protocol-27).

Ok, so if ALTO wanted to use RESTCONF, it would have to decouple the
data model from the protocol, and "just" define a YANG module wit= h the
necessary data:

  module ietf-alto {
    ...
    container alto {
      container network-map {
        list netloc {
          ...
        }
      }
      container cost-map {
        ...
      }
    }
  }


It should be noted that RESTCONF currently does not support a "query&q= uot;
interface like the "filtered"-thingie in ALTO.  However, I b= elieve
such a mechanism should be addded to RESTCONF.



/martin

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf

 

--_000_655C07320163294895BBADA28372AF5D21385EFR712WXCHMBA15zeu_-- From nobody Mon Mar 10 14:32:47 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F28C41A04B0 for ; Mon, 10 Mar 2014 14:32:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQxEBgCjjMW1 for ; Mon, 10 Mar 2014 14:32:44 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 996931A0146 for ; Mon, 10 Mar 2014 14:32:44 -0700 (PDT) Received: from mail26-co9-R.bigfish.com (10.236.132.227) by CO9EHSOBE022.bigfish.com (10.236.130.85) with Microsoft SMTP Server id 14.1.225.22; Mon, 10 Mar 2014 21:32:39 +0000 Received: from mail26-co9 (localhost [127.0.0.1]) by mail26-co9-R.bigfish.com (Postfix) with ESMTP id EF554120101; Mon, 10 Mar 2014 21:32:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT002.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -4 X-BigFish: VPS-4(zz98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzc2hz8275ch1de098h1de097hz2fh109h2a8h839h944hd25he5bhf0ah1220h1288h12a5h12a9h12bdh137ah139eh13b6h1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h1155h) Received-SPF: pass (mail26-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=deanb@juniper.net; helo=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(164054003)(24454002)(189002)(199002)(377454003)(88136002)(2656002)(77156001)(77096001)(89996001)(36756003)(97336001)(74366001)(56816005)(76786001)(19580395003)(63696002)(83072002)(85852003)(1941001)(74706001)(74876001)(33656001)(95666003)(74502001)(90146001)(74662001)(31966008)(97186001)(80976001)(19580405001)(47446002)(85306002)(95416001)(81816001)(57306001)(80022001)(65816001)(92726001)(82746002)(81686001)(81542001)(46102001)(51856001)(53806001)(76482001)(54316002)(56776001)(47976001)(50986001)(50226001)(49866001)(47736001)(59766001)(77982001)(4396001)(92566001)(93136001)(81342001)(79102001)(83322001)(76796001)(66066001)(87936001)(62966002)(69226001)(93916002)(94316002)(87266001)(93516002)(94946001)(83716003)(86362001)(87286001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB427.namprd05.prod.outlook.com; CLIP:66.129.241.12; FPR:2C44F255.4E2032B.F0C3338B.86E2C84C.20465; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail26-co9 (localhost.localdomain [127.0.0.1]) by mail26-co9 (MessageSwitch) id 1394487156262138_31149; Mon, 10 Mar 2014 21:32:36 +0000 (UTC) Received: from CO9EHSMHS001.bigfish.com (unknown [10.236.132.248]) by mail26-co9.bigfish.com (Postfix) with ESMTP id 3A9621000C2; Mon, 10 Mar 2014 21:32:36 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS001.bigfish.com (10.236.130.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 10 Mar 2014 21:32:35 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.423.0; Mon, 10 Mar 2014 21:32:29 +0000 Received: from CO1PR05MB427.namprd05.prod.outlook.com (10.141.74.12) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.893.10; Mon, 10 Mar 2014 21:32:27 +0000 Received: from CO1PR05MB427.namprd05.prod.outlook.com ([169.254.14.3]) by CO1PR05MB427.namprd05.prod.outlook.com ([169.254.14.3]) with mapi id 15.00.0893.001; Mon, 10 Mar 2014 21:32:27 +0000 From: Dean Bogdanovic To: Kent Watsen Thread-Topic: [Netconf] Unsigned configlets and physical security Thread-Index: AQHPN+VQvD7LZsKAt0y8O27fc1V2vprUPQeAgAAEDgCAAAR1gIAABbAAgAAVgQCAAXvpgIAFBAcA Date: Mon, 10 Mar 2014 21:32:26 +0000 Message-ID: References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> <20140306170000.GA34736@elstar.local> <038401cf3968$436be440$ca43acc0$@comcast.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-originating-ip: [66.129.241.12] x-forefront-prvs: 014617085B Content-Type: text/plain; charset="us-ascii" Content-ID: <63C835C42FEC0E418135DBA8F09640B1@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/vYeTbuCk-d9cSHDIL2bTFLbDtAY Cc: Randy Presuhn , "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:32:47 -0000 Kent Please see inline On Mar 7, 2014, at 11:56 AM, Kent Watsen wrote: >=20 > So after consulting a number of folks, both in and out of the security > area, we have the following: >=20 >=20 > Regarding scope >=20 > Opinions:=20 >=20 > 1. Take loading Configlets from anything other than a Configuration > Server out of draft, since it's not a protocol and can be a > vendor-specific option. Note, if we take it out, this entire > discussion is mute. >=20 > 2. Leave loading Configlets via physical presence in the draft, as > it squarely addresses a common interest and specifies the draft's > position on the matter. To some, since we're discussing on-boot > behavior, if it's not specified, then it's implicitly not allowed. > In fact, a statement to that effect is desired. >=20 > My thoughts: >=20 > Option #1 is a lot easier for us, but option #2 better serves the > purpose, especially if willing to add a statement that anything > not explicitly specified is disallowed. idb>> I prefer the option #1, as it enables deployment according to local s= ecurity policies (some enterprises might have less stringent security polic= ies). Even worse is the statement that anything not explicitly specified is= disallowed. That prevents deployment, unless security policies would be up= dated. >=20 >=20 >=20 > Regarding signing: >=20 > Opinions: >=20 > 1. Require signature in all cases >=20 > 2. Require signature for network-accessed Configlets and let vendors > decide what is possible when via physical presence (e.g. SP- > owned home equipment would require a signature, if said equipment > supports physical-presence mechanism at all). Additionally, the > Ability to use an unsigned Configlet for many devices (because > they don't require a unique-identifier) resolves logistical > deployment issues. >=20 > My thoughts: >=20 > My primary concern here is how easy it is on trusted administrators, > as there is significant overhead involved in getting a Configlet > signed. Please note that while the draft enables the signing role > to be delegated to a 3rd-party, the delegation is unlikely to ever > be to a specific customer (enterprise or SP), because that would > enable the enterprise/SP to sign Configlets for devices that don't > belong to them. Further, if we insist on a signature, then we > would also need to insist on the device's unique-identifier being > in the Configlet to thwart substitution attacks. This means that, > for each device, trusted admins would have to go to the 3rd-party > to get a Configlet signed, and they would have to insure that they > loaded the right Configlet onto the right device. One thing we > could do to improve the situation would be to allow a Configlet to > contain a list of unique-identifiers (not just one), thus allowing > one Configlet to be loaded by more than one device. Is it enough? >=20 > FWIW, the only way I can imagine it being possible for a customer > (enterprise/SP) to sign their own Configlets is if the customer > receives customer-specific hardware that has been coded to trust > a customer-specific trust-anchor, thus denying the ability for a > Configlet signed by them to work on any other customer's equipment. idb>> In case my vote is decider, vote for option 2 >=20 >=20 >=20 >=20 >=20 > Regarding encryption: (tangentially related) >=20 > Opinions: >=20 > 1. Encryption is undesirable, as inspection of the Configlet's > contents is needed >=20 > 2. Encryption is required, because content-inspection is undesirable. > For instance, for home equipment, the SP doesn't want the end > user to have any visibility into their network. >=20 > My thoughts:=20 >=20 > It is easy for the Configlet Signer to optionally encrypt a > Confilglet using a device-specific public-key. Obviously this > only works for Configlets destined for a single device, not > containing more than one unique-identifier. I'm ok with this, > is optional-encryption sufficient? To be clear: device MUST > Support encryption, user can choose if they want to use it... >=20 >=20 >=20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 >=20 >=20 From nobody Mon Mar 10 14:58:33 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83C81A04F8 for ; Mon, 10 Mar 2014 14:58:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b2xJbLKtGFSZ for ; Mon, 10 Mar 2014 14:58:29 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id E04DE1A04F6 for ; Mon, 10 Mar 2014 14:58:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2992; q=dns/txt; s=iport; t=1394488703; x=1395698303; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=s5PnGLO2aggFGn2E0r/6FeaYHHYCxTwCar7qWv2onPc=; b=kLo8ETGmh/fNQVgK1jvntSmvV26yRQoIotto4pNyiF8qwhhYBX772wZj Gi7ia5MbfjPWUAlKqfdvxo8VMKS1C9BP5ck+Vm2J/m/UicnHJojJFY2jn xPYK60Zs5miUnm3NuyQaulDIZUFK558C5lcURs5Ji06tR6OsU5kTdkk5P 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhYFADA1HlOtJXHA/2dsb2JhbABagwbCV4EhFnSCJQEBAQMBOEABBQsLDgoJFg8JAwIBAgFFBgEMAQcBAYdtCM9dF45bB4Q4AQOYRYZMi2GDSSE X-IronPort-AV: E=Sophos;i="4.97,626,1389744000"; d="scan'208";a="309295169" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-2.cisco.com with ESMTP; 10 Mar 2014 21:58:15 +0000 Received: from [10.150.54.104] (dhcp-10-150-54-104.cisco.com [10.150.54.104]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s2ALwEWS024197; Mon, 10 Mar 2014 21:58:14 GMT Message-ID: <531E3576.3010802@cisco.com> Date: Mon, 10 Mar 2014 17:58:14 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , ietfdbh , "'Juergen Schoenwaelder'" , Dean Bogdanovic References: <12511760.1393963626021.JavaMail.root@elwamui-cypress.atl.sa.earthlink.net> <57DB3F56-0CD1-4155-8A48-59F9E56EBA3F@juniper.net> <5318A10E.4030309@cisco.com> <20140306170000.GA34736@elstar.local> <038401cf3968$436be440$ca43acc0$@comcast.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/L0VCwVirWxOg2K47xXnRs6JqvIE Cc: 'Randy Presuhn' , "netconf@ietf.org" Subject: Re: [Netconf] Unsigned configlets and physical security X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 21:58:31 -0000 On 3/7/14, 11:56 AM, Kent Watsen wrote: > > So after consulting a number of folks, both in and out of the security > area, we have the following: > > > Regarding scope > > Opinions: > > 1. Take loading Configlets from anything other than a Configuration > Server out of draft, since it's not a protocol and can be a > vendor-specific option. Note, if we take it out, this entire > discussion is mute. > > 2. Leave loading Configlets via physical presence in the draft, as > it squarely addresses a common interest and specifies the draft's > position on the matter. To some, since we're discussing on-boot > behavior, if it's not specified, then it's implicitly not allowed. > In fact, a statement to that effect is desired. > > My thoughts: > > Option #1 is a lot easier for us, but option #2 better serves the > purpose, especially if willing to add a statement that anything > not explicitly specified is disallowed. I think option 1 is safer, and vendors can be left up to their own decisions. > > > > Regarding signing: > > Opinions: > > 1. Require signature in all cases > > 2. Require signature for network-accessed Configlets and let vendors > decide what is possible when via physical presence (e.g. SP- > owned home equipment would require a signature, if said equipment > supports physical-presence mechanism at all). Additionally, the > Ability to use an unsigned Configlet for many devices (because > they don't require a unique-identifier) resolves logistical > deployment issues. I think we should mandate signing in all cases in the draft (which would be over the network). But if you had a number of configlets each named with the fingerprint, you could always load the right one. In this manner, you could have a number on the same disk and the device could pick the right one. > Regarding encryption: (tangentially related) > > Opinions: > > 1. Encryption is undesirable, as inspection of the Configlet's > contents is needed > > 2. Encryption is required, because content-inspection is undesirable. > For instance, for home equipment, the SP doesn't want the end > user to have any visibility into their network. > > My thoughts: > > It is easy for the Configlet Signer to optionally encrypt a > Confilglet using a device-specific public-key. Obviously this > only works for Configlets destined for a single device, not > containing more than one unique-identifier. I'm ok with this, > is optional-encryption sufficient? To be clear: device MUST > Support encryption, user can choose if they want to use it... I agree. I think encryption can be optional. However, in light of pervasive monitoring, will the security directorate accept this? Will encryption have to be made mandatory? Joe From nobody Mon Mar 17 06:42:13 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E6D11A040C for ; Mon, 17 Mar 2014 06:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iySLGApA6e3V for ; Mon, 17 Mar 2014 06:42:08 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C4F0C1A03F5 for ; Mon, 17 Mar 2014 06:42:07 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s2HDfwdM014831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 17 Mar 2014 14:41:58 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2HDfwpw032478 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 17 Mar 2014 14:41:58 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.196]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Mon, 17 Mar 2014 14:41:58 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: netconf Thread-Topic: Draft Minutes for the IETF 89 NETCONF Session Thread-Index: AQHPQeaqTmzO0oZHkEiWGXgu6oJxpg== Date: Mon, 17 Mar 2014 13:41:57 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.99] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F82C9236DEMUMBX005nsnintr_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5794 X-purgate-ID: 151667::1395063718-00003319-927470CA/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/X-uV9KPtVr1tLuddrhg9XwRpmtY Subject: [Netconf] Draft Minutes for the IETF 89 NETCONF Session X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 13:42:11 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F82C9236DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, below are the draft minutes of the NETCONF session in IETF 89. Pls send your comments to the co-chairs by March 28, 2014. http://www.ietf.org/proceedings/89/minutes/minutes-89-netconf Many thanks to the minute takers Lada Lhotka, Dan Romascanu and the Jabber scribe Benno Overeinder. Cheers, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F82C9236DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF WG,

 

below are the draft minutes of the NETC= ONF session in IETF 89.

Pls send your comments to the co-chairs= by March 28, 2014.<= /p>

 <= /p>

http://www.ietf.org/procee= dings/89/minutes/minutes-89-netconf

 <= /p>

Many thanks to the minute takers Lada L= hotka, Dan Romascanu and

the Jabber scribe Benno Overeinder.

 

Cheers,

Mehmet

 

 

 

--_000_E4DE949E6CE3E34993A2FF8AE79131F82C9236DEMUMBX005nsnintr_-- From nobody Mon Mar 17 09:51:48 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 08AEF1A006F for ; Mon, 17 Mar 2014 09:51:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vPpNY6LuKGXT for ; Mon, 17 Mar 2014 09:51:45 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 9033C1A0436 for ; Mon, 17 Mar 2014 09:51:45 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPal5-0004iV-4c for netconf@ietf.org; Mon, 17 Mar 2014 17:51:37 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-3.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WPal5-0007ff-24 for netconf@ietf.org; Mon, 17 Mar 2014 17:51:27 +0100 Message-ID: <5327280E.7000407@ripe.net> Date: Mon, 17 Mar 2014 17:51:26 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885eba06b42c9e432c5626401c5cfc7bd5d9 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hwNFEI4Nzx18XG0KS_SIv76D9YY Subject: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:51:47 -0000 Dear NETCONF participants, We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 The document acn be found at: http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 Pls review and send any comments (a comment aka: I read/reviewed it and believe it is ready for publication" is also good input) to the WG mailing lists not later than March 30th 2014 (any timezone). Any reports on implementation status or plans to implement are also very useful. Bert and Mehmet From nobody Mon Mar 17 09:53:57 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 40C6D1A043C for ; Mon, 17 Mar 2014 09:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LR5vVz9ONvk5 for ; Mon, 17 Mar 2014 09:53:53 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 27DBA1A0441 for ; Mon, 17 Mar 2014 09:53:53 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPan8-0000kl-RT for netconf@ietf.org; Mon, 17 Mar 2014 17:53:44 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=macintosh-3.fritz.box) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WPan8-0007r7-Ov for netconf@ietf.org; Mon, 17 Mar 2014 17:53:34 +0100 Message-ID: <5327288E.7060503@ripe.net> Date: Mon, 17 Mar 2014 17:53:34 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Netconf Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e767ed6882c70632c7042cfd6a05a4e2b Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/rjv3weCIeTnZDMrgEqTFHL13Tfk Subject: [Netconf] Action before April 1st 2014: WGLC for: draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 16:53:55 -0000 Dear NETCONF participants, We hereby issue a WG Last Call for draft-ietf-netconf-rfc5539bis-05 The document acn be found at: http://tools.ietf.org/html/draft-ietf-netconf-rfc5539bis-05 Pls review and send any comments (a comment aka: I read/reviewed it and believe it is ready for publication" is also good input) to the WG mailing lists not later than March 30th 2014 (any timezone). Any reports on implementation status or plans to implement are also very useful. Bert and Mehmet From nobody Mon Mar 17 10:11:58 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33FBC1A043A for ; Mon, 17 Mar 2014 10:11:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.048 X-Spam-Level: X-Spam-Status: No, score=-15.048 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NnRcLTjt6ner for ; Mon, 17 Mar 2014 10:11:49 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id D34921A0439 for ; Mon, 17 Mar 2014 10:11:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=583; q=dns/txt; s=iport; t=1395076302; x=1396285902; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=+E4reggFlHcghHCD9phgTHK7VbvKt7BlqEEaDIeuKKY=; b=YSIFuBNZ3F5/9pR33f/BLcoAXfBz9CM+ufrzZwpYZLV9MvCpvOMRZ+PA BCgPPn9CBKbrRMMWhxxIUFXjXsbz61JsHfuXi/13od8GsSXCOPCtTYFbm EkwgYoMcAnZmOI6j1RyxGNvfdUT5q95NOaPTs55qxEm5TIA6Tkz45Pxc6 U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFAAUsJ1OtJXG8/2dsb2JhbABZgwY7wlmBHBZ0giUBAQEEHRs2ChELDgoJFg8JAwIBAgFFBgEMCAEBh3UN0wEXjm+EOAEDmEaBMoUai2OBb4FaIQ X-IronPort-AV: E=Sophos;i="4.97,671,1389744000"; d="scan'208";a="310888787" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 17 Mar 2014 17:11:41 +0000 Received: from [10.150.54.24] (dhcp-10-150-54-24.cisco.com [10.150.54.24]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s2HHBfeE019093; Mon, 17 Mar 2014 17:11:41 GMT Message-ID: <53272CCD.3020203@cisco.com> Date: Mon, 17 Mar 2014 13:11:41 -0400 From: Joe Marcus Clarke Organization: Cisco Systems, Inc. User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bert Wijnen , Netconf References: <5327280E.7000407@ripe.net> In-Reply-To: <5327280E.7000407@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Gnfl_QsHVq_y2cVpzgs1hkNXtuQ Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 17:11:56 -0000 On 3/17/14, 12:51 PM, Bert Wijnen wrote: > Dear NETCONF participants, > > We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 > > The document acn be found at: > http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 > > Pls review and send any comments (a comment aka: I read/reviewed it > and believe it is ready for publication" is also good input) to > the WG mailing lists not later than March 30th 2014 (any timezone). I have read and reviewed it. The updated security considerations are good, and I would support publication. Joe From nobody Tue Mar 18 00:22:32 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55F21A0031 for ; Tue, 18 Mar 2014 00:22:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VOgwxPFPkc4W for ; Tue, 18 Mar 2014 00:22:29 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 203F51A001D for ; Tue, 18 Mar 2014 00:22:28 -0700 (PDT) Received: from localhost (138.162.241.83.in-addr.dgcsystems.net [83.241.162.138]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A41037C2FB; Tue, 18 Mar 2014 08:22:19 +0100 (CET) Date: Tue, 18 Mar 2014 08:22:18 +0100 (CET) Message-Id: <20140318.082218.579296055407207171.mbj@tail-f.com> To: bwijnen@ripe.net From: Martin Bjorklund In-Reply-To: <5327280E.7000407@ripe.net> References: <5327280E.7000407@ripe.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/M74EYWR4tY8BXbYfagrc-vZOENU Cc: netconf@ietf.org Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 07:22:31 -0000 Hi, I have reviewed this document, and my only issues are related to the generic wording in the title and some other places. See the mail thread started by Juergen: http://www.ietf.org/mail-archive/web/netconf/current/msg08711.html /martin Bert Wijnen wrote: > Dear NETCONF participants, > > We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 > > The document acn be found at: > http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 > > Pls review and send any comments (a comment aka: I read/reviewed it > and believe it is ready for publication" is also good input) to > the WG mailing lists not later than March 30th 2014 (any timezone). > > Any reports on implementation status or plans to implement are also > very useful. > > Bert and Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Mar 18 01:04:59 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 058971A0691 for ; Tue, 18 Mar 2014 01:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bI_66ndKeYdz for ; Tue, 18 Mar 2014 01:04:46 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 34CE71A066D for ; Tue, 18 Mar 2014 01:04:46 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPp0f-0006e5-3o; Tue, 18 Mar 2014 09:04:37 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest24.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WPp0f-00008w-09; Tue, 18 Mar 2014 09:04:29 +0100 Message-ID: <5327FE0C.3000201@ripe.net> Date: Tue, 18 Mar 2014 09:04:28 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Bjorklund References: <5327280E.7000407@ripe.net> <20140318.082218.579296055407207171.mbj@tail-f.com> In-Reply-To: <20140318.082218.579296055407207171.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885eb7fecc95088f01f7d36eb1e110541161 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/2b4lBasA6pjybjLeFPTDVqpGooo Cc: netconf@ietf.org Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 08:04:57 -0000 OK, so we had a suggestion earlier on to make the title "Reverse Secure Shell for NETCONF" Unless anyone objects (before April 1st) we (WG chairs) will instruct the editor/author to change the title to the above. Bert On 18/03/14 08:22, Martin Bjorklund wrote: > Hi, > > I have reviewed this document, and my only issues are related to the > generic wording in the title and some other places. See the mail > thread started by Juergen: > http://www.ietf.org/mail-archive/web/netconf/current/msg08711.html > > > > /martin > > > Bert Wijnen wrote: >> Dear NETCONF participants, >> >> We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 >> >> The document acn be found at: >> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 >> >> Pls review and send any comments (a comment aka: I read/reviewed it >> and believe it is ready for publication" is also good input) to >> the WG mailing lists not later than March 30th 2014 (any timezone). >> >> Any reports on implementation status or plans to implement are also >> very useful. >> >> Bert and Mehmet >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> From nobody Tue Mar 18 02:00:53 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4F21A0695 for ; Tue, 18 Mar 2014 02:00:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RlessuFBcN21 for ; Tue, 18 Mar 2014 02:00:50 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 6A2101A03BD for ; Tue, 18 Mar 2014 02:00:50 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPpst-0003tu-SF for netconf@ietf.org; Tue, 18 Mar 2014 10:00:42 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest24.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WPpst-0006Jh-OI for netconf@ietf.org; Tue, 18 Mar 2014 10:00:31 +0100 Message-ID: <53280B2F.4010203@bwijnen.net> Date: Tue, 18 Mar 2014 10:00:31 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Netconf References: <5327280E.7000407@ripe.net> In-Reply-To: <5327280E.7000407@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd4716e13d113414a54832c641fd8b1ced5 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/iK0Nyb7MHbzeFF4n7vKPnhb3al8 Subject: [Netconf] Action before April 1st 2014: Any IPR for draft-ietf-netconf-reverse-ssh-03? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:00:52 -0000 When we (WG chairs) submit the document to our AD, we must provide a document writeup. See: https://www.ietf.org/iesg/template/doc-writeup.html Point 7 wants us to check: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? So can the authors/editors please confirm explicitly? Also, if anyone else is aware of any IPR, please do file such a disclosure. Bert and Mehmet On 17/03/14 17:51, Bert Wijnen wrote: > Dear NETCONF participants, > > We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 > > The document acn be found at: > http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 > > Pls review and send any comments (a comment aka: I read/reviewed it > and believe it is ready for publication" is also good input) to > the WG mailing lists not later than March 30th 2014 (any timezone). > > Any reports on implementation status or plans to implement are also > very useful. > > Bert and Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Mar 18 02:02:02 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DCDA1A03BD for ; Tue, 18 Mar 2014 02:02:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id npRqKuKX_zIc for ; Tue, 18 Mar 2014 02:01:59 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id B4AB71A0695 for ; Tue, 18 Mar 2014 02:01:59 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WPptt-0006Di-SV for netconf@ietf.org; Tue, 18 Mar 2014 10:01:51 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest24.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WPptt-0006eD-NM; Tue, 18 Mar 2014 10:01:33 +0100 Message-ID: <53280B6D.6030708@bwijnen.net> Date: Tue, 18 Mar 2014 10:01:33 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Bert Wijnen , Netconf References: <5327288E.7060503@ripe.net> In-Reply-To: <5327288E.7060503@ripe.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd465fbcc21937b3962e81bd3d6690d7ece Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ulPihQWr8ed7Hs4Y-nnIV5tsKTs Subject: [Netconf] Action before April 1st 2014: any IPR for draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:02:01 -0000 When we (WG chairs) submit the document to our AD, we must provide a document writeup. See: https://www.ietf.org/iesg/template/doc-writeup.html Point 7 wants us to check: (7) Has each author confirmed that any and all appropriate IPR disclosures required for full conformance with the provisions of BCP 78 and BCP 79 have already been filed. If not, explain why? So can the authors/editors please confirm explicitly? Also, if anyone else is aware of any IPR, please do file such a disclosure. Bert and Mehmet From nobody Tue Mar 18 02:20:01 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36C6E1A06BF for ; Tue, 18 Mar 2014 02:20:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J9QE3toRas1y for ; Tue, 18 Mar 2014 02:19:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 1A2ED1A06B9 for ; Tue, 18 Mar 2014 02:19:58 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 5C164110C; Tue, 18 Mar 2014 10:19:49 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EnT254WgYa8i; Tue, 18 Mar 2014 10:19:48 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 18 Mar 2014 10:19:48 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB953219A4; Tue, 18 Mar 2014 10:19:48 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id GoTqwa2clUk6; Tue, 18 Mar 2014 10:19:48 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B4CCD219A3; Tue, 18 Mar 2014 10:19:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id CCF282BCD393; Tue, 18 Mar 2014 10:19:46 +0100 (CET) Date: Tue, 18 Mar 2014 10:19:46 +0100 From: Juergen Schoenwaelder To: "Bert Wijnen (IETF)" Message-ID: <20140318091946.GB2109@elstar.local> Mail-Followup-To: "Bert Wijnen (IETF)" , Bert Wijnen , Netconf References: <5327288E.7060503@ripe.net> <53280B6D.6030708@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53280B6D.6030708@bwijnen.net> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/hNSIKvmW932I1xP1XWcAfvPIGJI Cc: Bert Wijnen , Netconf Subject: Re: [Netconf] Action before April 1st 2014: any IPR for draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:20:00 -0000 On Tue, Mar 18, 2014 at 10:01:33AM +0100, Bert Wijnen (IETF) wrote: > When we (WG chairs) submit the document to our AD, we must provide a document writeup. > See: https://www.ietf.org/iesg/template/doc-writeup.html > Point 7 wants us to check: > > (7) Has each author confirmed that any and all appropriate IPR disclosures required > for full conformance with the provisions of BCP 78 and BCP 79 have already been > filed. If not, explain why? > > So can the authors/editors please confirm explicitly? I am not aware of any IPR related to this document. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 18 02:39:03 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989AD1A06CA for ; Tue, 18 Mar 2014 02:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tNGkE2hOeJ5G for ; Tue, 18 Mar 2014 02:39:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 9C0D31A06B1 for ; Tue, 18 Mar 2014 02:38:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 303E71091; Tue, 18 Mar 2014 10:38:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id wD2cPgk2JaZB; Tue, 18 Mar 2014 10:38:50 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 18 Mar 2014 10:38:50 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3DBAE219A4; Tue, 18 Mar 2014 10:38:50 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ocbs55MLdpcN; Tue, 18 Mar 2014 10:38:49 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 82901219A3; Tue, 18 Mar 2014 10:38:48 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A73F42BCD403; Tue, 18 Mar 2014 10:38:46 +0100 (CET) Date: Tue, 18 Mar 2014 10:38:45 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140318093843.GC2109@elstar.local> Mail-Followup-To: Martin Bjorklund , netconf@ietf.org References: <20140305.111228.304368597.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140305.111228.304368597.mbj@tail-f.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/wmz7WtzLvH2DTxC1mVPi0wQhsdc Cc: netconf@ietf.org Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 09:39:01 -0000 On Wed, Mar 05, 2014 at 11:12:28AM +0000, Martin Bjorklund wrote: > Hi, > > I have reviewed this document, and have just one comment. > > The last paragraph of section 2.4.1 says: > > If the NETCONF client has external information as to the expected > identity of the NETCONF server, the hostname check MAY be omitted. > > There are some MUSTs in the preceding paragraphs, and it is not clear > to me what "the hostname check" refers to. I agree that this needs to be clarified in particular for outgoing call-home connections and I am not sure this is an easy one to address. For a conventional NETCONF client, you typically specify the hostname of the NETCONF server and then you check whether the certificate presented by the server is valid and matches the hostname. For call home, this is getting tricky. The NETCONF server has local config that says connect to TCP endpoint X to reach the NETCONF client. The NETCONF client now starts the TLS and receives a certificate which likely asserts a hostname. While the TLS client can validate the certificate, the question remains how the client verifies it is really talking to the right server? Since it does not know the hostname, we have three options (at least): 1) The certificate must include the IP address used by the NETCONF server when it initiated the call home procedure. 2) The NETCONF client does a reverse lookup to obtain a hostname that is then checked against the certificate (but can we trust DNS? - likely not). 3) The NETCONF client has configured call home information that associates IP addresses of NETCONF servers calling home with either a hostname or likely even better with certificate fingerprints. This, of course, makes call home of yet unknown devices non-automatic. Note that the SSH call home mechanism has a similar problem to solve and I am not sure I understand what the solution is there either. There is some high-level text about host-keys and a recommendation that host-keys should be signed by a common key but I do not get from this what needs to be implemented. The server configuration I-D has a host-keys container but there is not much description here either: "An ordered listing of the SSH host keys the device should advertise to the application."; "The name of a host key the device should advertise during the SSH key exchange."; I do not know what the idea here is - establish the SSH and NETCONF session, then do a get-config to retrieve the keys and if the information does not match what I have used, drop the sessions? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 18 09:02:55 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEC761A0706 for ; Tue, 18 Mar 2014 09:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4Wfnfzj6MbWr for ; Tue, 18 Mar 2014 09:02:48 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe004.messaging.microsoft.com [213.199.154.207]) by ietfa.amsl.com (Postfix) with ESMTP id 3920C1A0701 for ; Tue, 18 Mar 2014 09:02:47 -0700 (PDT) Received: from mail109-am1-R.bigfish.com (10.3.201.227) by AM1EHSOBE010.bigfish.com (10.3.204.30) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 16:02:38 +0000 Received: from mail109-am1 (localhost [127.0.0.1]) by mail109-am1-R.bigfish.com (Postfix) with ESMTP id D23E93A01D7; Tue, 18 Mar 2014 16:02:38 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail109-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(164054003)(479174003)(51704005)(377454003)(24454002)(74366001)(31966008)(47446002)(74662001)(77096001)(92566001)(54356001)(76482001)(53806001)(51856001)(36756003)(56776001)(81342001)(74502001)(54316002)(76786001)(76796001)(81542001)(69226001)(95666003)(85852003)(92726001)(66066001)(79102001)(20776003)(59766001)(77982001)(97186001)(65816001)(46102001)(85306002)(80022001)(63696002)(50986001)(86362001)(93516002)(94946001)(83072002)(93136001)(94316002)(83506001)(19580395003)(74706001)(90146001)(19580405001)(56816005)(81816001)(80976001)(81686001)(15975445006)(95416001)(49866001)(74876001)(47976001)(83322001)(97336001)(47736001)(87266001)(87936001)(4396001)(15202345003)(2656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:ACD47934.8CF29313.F4503F7B.48E55A90.20293; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail109-am1 (localhost.localdomain [127.0.0.1]) by mail109-am1 (MessageSwitch) id 1395158556788888_8731; Tue, 18 Mar 2014 16:02:36 +0000 (UTC) Received: from AM1EHSMHS008.bigfish.com (unknown [10.3.201.247]) by mail109-am1.bigfish.com (Postfix) with ESMTP id BD68C240051; Tue, 18 Mar 2014 16:02:36 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS008.bigfish.com (10.3.207.108) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 16:02:35 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 16:02:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 16:02:27 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.205]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 16:02:26 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" , Netconf Thread-Topic: [Netconf] Action before April 1st 2014: Any IPR for draft-ietf-netconf-reverse-ssh-03? Thread-Index: AQHPQoiuPBolkLKpEU2Hl6Caat3f/prmvs2A Date: Tue, 18 Mar 2014 16:02:26 +0000 Message-ID: References: <5327280E.7000407@ripe.net> <53280B2F.4010203@bwijnen.net> In-Reply-To: <53280B2F.4010203@bwijnen.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0154C61618 Content-Type: text/plain; charset="us-ascii" Content-ID: <1840692B94C92F40A9448EC9E66F603A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/3I2aUJLPJNBKvJ4rNVRRfqIayUU Subject: Re: [Netconf] Action before April 1st 2014: Any IPR for draft-ietf-netconf-reverse-ssh-03? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 16:02:51 -0000 The only IPR related to this work I am aware of is described in the disclosure previously submitted by Juniper: https://datatracker.ietf.org/ipr/2170. A slide regarding this IPR was presented and discussed at IETF 88. Thanks, Kent On 3/18/14 5:00 AM, "Bert Wijnen (IETF)" wrote: >When we (WG chairs) submit the document to our AD, we must provide a >document writeup. >See: https://www.ietf.org/iesg/template/doc-writeup.html >Point 7 wants us to check: > > (7) Has each author confirmed that any and all appropriate IPR >disclosures required > for full conformance with the provisions of BCP 78 and BCP 79 have >already been > filed. If not, explain why? > >So can the authors/editors please confirm explicitly? > >Also, if anyone else is aware of any IPR, please do file such a >disclosure. > >Bert and Mehmet > >On 17/03/14 17:51, Bert Wijnen wrote: >> Dear NETCONF participants, >> >> We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 >> >> The document acn be found at: >> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 >> >> Pls review and send any comments (a comment aka: I read/reviewed it >> and believe it is ready for publication" is also good input) to >> the WG mailing lists not later than March 30th 2014 (any timezone). >> >> Any reports on implementation status or plans to implement are also >> very useful. >> >> Bert and Mehmet >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue Mar 18 10:18:50 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 172961A06F3 for ; Tue, 18 Mar 2014 10:18:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KyvpPDiaSp0h for ; Tue, 18 Mar 2014 10:18:44 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id B2F481A0727 for ; Tue, 18 Mar 2014 10:18:31 -0700 (PDT) Received: from mail19-tx2-R.bigfish.com (10.9.14.246) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 17:18:23 +0000 Received: from mail19-tx2 (localhost [127.0.0.1]) by mail19-tx2-R.bigfish.com (Postfix) with ESMTP id 069DD1400AD; Tue, 18 Mar 2014 17:18:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT005.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zzbb2dI98dI9371Iac6I1432I4015Ifb6Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail19-tx2: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT005.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(51704005)(24454002)(479174003)(164054003)(40224001)(377454003)(189002)(199002)(76482001)(54316002)(93136001)(83506001)(74502001)(47446002)(74662001)(74706001)(20776003)(65816001)(80022001)(81686001)(51856001)(95666003)(81542001)(86362001)(79102001)(4396001)(69226001)(63696002)(81816001)(83072002)(66066001)(85852003)(31966008)(59766001)(49866001)(47736001)(94316002)(77982001)(93516002)(90146001)(97336001)(56776001)(81342001)(94946001)(15975445006)(74876001)(19580395003)(46102001)(83322001)(80976001)(87266001)(2656002)(15202345003)(53806001)(92726001)(97186001)(87936001)(54356001)(95416001)(19580405001)(92566001)(36756003)(76786001)(85306002)(76796001)(77096001)(50986001)(74366001)(56816005)(47976001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:ECC4DDD9.AF3A930F.BFF31D8F.4CF6D9C1.20545; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail19-tx2 (localhost.localdomain [127.0.0.1]) by mail19-tx2 (MessageSwitch) id 1395163101183310_13127; Tue, 18 Mar 2014 17:18:21 +0000 (UTC) Received: from TX2EHSMHS025.bigfish.com (unknown [10.9.14.230]) by mail19-tx2.bigfish.com (Postfix) with ESMTP id 270B11C007B; Tue, 18 Mar 2014 17:18:21 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS025.bigfish.com (10.9.99.125) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 17:18:20 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 17:18:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 17:18:16 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.205]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 17:18:16 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Martin Bjorklund Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 Thread-Index: AQHPOGPi0lBZ6ooeOE+AzxE/IuduwJrmqu6AgAA9VwA= Date: Tue, 18 Mar 2014 17:18:15 +0000 Message-ID: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> In-Reply-To: <20140318093843.GC2109@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0154C61618 Content-Type: text/plain; charset="us-ascii" Content-ID: <221E0746D809B0428DC184E2C5E8B4E2@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ITMXWUMFYNOPYH395XZN5VrrTyE Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:18:49 -0000 On 3/18/14 5:38 AM, "Juergen Schoenwaelder" wrote: >On Wed, Mar 05, 2014 at 11:12:28AM +0000, Martin Bjorklund wrote: >> Hi, >>=20 >> I have reviewed this document, and have just one comment. >>=20 >> The last paragraph of section 2.4.1 says: >>=20 >> If the NETCONF client has external information as to the expected >> identity of the NETCONF server, the hostname check MAY be omitted. >>=20 >> There are some MUSTs in the preceding paragraphs, and it is not clear >> to me what "the hostname check" refers to. > >I agree that this needs to be clarified in particular for outgoing >call-home connections and I am not sure this is an easy one to >address. The lines quoted above were cut-n-pasted from HTTP Over TLS (RFC 2818) section 3.1 (server identity): http://tools.ietf.org/html/rfc2818#section-3.1. I raised this issue before, on the -03 version of this draft, but see no follow-ups in the archives: http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html >For a conventional NETCONF client, you typically specify the hostname >of the NETCONF server and then you check whether the certificate >presented by the server is valid and matches the hostname. > >For call home, this is getting tricky. The NETCONF server has local >config that says connect to TCP endpoint X to reach the NETCONF >client. The NETCONF client now starts the TLS and receives a >certificate which likely asserts a hostname. While the TLS client can >validate the certificate, the question remains how the client verifies >it is really talking to the right server? Since it does not know the >hostname, we have three options (at least): > >1) The certificate must include the IP address used by the NETCONF > server when it initiated the call home procedure. > >2) The NETCONF client does a reverse lookup to obtain a hostname that > is then checked against the certificate (but can we trust DNS? - > likely not). > >3) The NETCONF client has configured call home information that > associates IP addresses of NETCONF servers calling home with either > a hostname or likely even better with certificate fingerprints. > This, of course, makes call home of yet unknown devices > non-automatic. Ultimately, we want to apply the same reasoning presented in the Reverse SSH draft, section 5 (SSH Server Identification and Verification). As for terminology, please note that when the TLS draft refers to "hostname", it means the component identifying the server in a URL. Also, when the Reverse SSH draft refers to "Host Key", it is equivalent to the server certificate in TLS. So, the same rules apply: 1) it is possible for the NMS to identify the device solely via its source-IP, but only works in networks with static addresses. This strategy requires the NMS to have a store of trusted IP addresses. 2) it is possible for the NMS to identify the device via its certificate. Think "strcmp()". This could be either via comparing the entire certificate or a fingerprint of the certificate. But this strategy requires the NMS to have a store of trusted device certificates. 3) it is *recommended* for the NMS to identify the device via information contained inside the certificate - a unique identifier (e.g., serial number, FQDN, etc.). But this strategy requires the NMS to have a store of trusted unique identifiers. This approach is recommended because it works even the certificate changes so long as the identifier is the same. 4) Making #3 even better, it is further recommended the NMS validates the device's certificate via path-verification to a trusted CA (not explicitly as described in #2). This enables the NMS to have to trust just a single certificate (the CA's), not each device's... Makes sense? >Note that the SSH call home mechanism has a similar problem to solve >and I am not sure I understand what the solution is there either. >There is some high-level text about host-keys and a recommendation >that host-keys should be signed by a common key but I do not get from >this what needs to be implemented. The server configuration I-D has >a host-keys container but there is not much description here either: > > "An ordered listing of the SSH host keys the > device should advertise to the application."; > > "The name of a host key the device should > advertise during the SSH key exchange."; > >I do not know what the idea here is - establish the SSH and NETCONF >session, then do a get-config to retrieve the keys and if the >information does not match what I have used, drop the sessions? You are probably familiar with SSH host-keys like "id_rsa.pub" and "id_dsa.pub". When using OpenSSH, the sshd_config file can contain one of more "HostKey" entries, an ordered list. The ordering is important to the SSH protocol, not just the OpenSSH implementation. The configuration described in the netconf server configuration draft mentioned above maps directly onto this concept, enabling it to be configurable per NMS. Thanks, Kent From nobody Tue Mar 18 10:23:49 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67C151A072A for ; Tue, 18 Mar 2014 10:23:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id td7lxNraOz7G for ; Tue, 18 Mar 2014 10:23:40 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe004.messaging.microsoft.com [207.46.163.27]) by ietfa.amsl.com (Postfix) with ESMTP id 726301A0710 for ; Tue, 18 Mar 2014 10:23:32 -0700 (PDT) Received: from mail111-co9-R.bigfish.com (10.236.132.253) by CO9EHSOBE016.bigfish.com (10.236.130.79) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 17:23:23 +0000 Received: from mail111-co9 (localhost [127.0.0.1]) by mail111-co9-R.bigfish.com (Postfix) with ESMTP id D4F7D7401DB; Tue, 18 Mar 2014 17:23:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail111-co9: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(479174003)(377454003)(51704005)(164054003)(24454002)(74662001)(74502001)(56776001)(54356001)(69226001)(51856001)(74366001)(80022001)(66066001)(65816001)(47446002)(76482001)(81542001)(81342001)(53806001)(31966008)(63696002)(20776003)(74706001)(59766001)(77982001)(54316002)(97336001)(95666003)(97186001)(93136001)(94316002)(83506001)(56816005)(85306002)(74876001)(47736001)(80976001)(86362001)(15975445006)(90146001)(94946001)(50986001)(49866001)(83322001)(93516002)(87936001)(2656002)(85852003)(92566001)(92726001)(83072002)(19580405001)(19580395003)(81686001)(81816001)(36756003)(79102001)(87266001)(47976001)(76796001)(76786001)(4396001)(95416001)(15202345003)(77096001)(46102001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:BE96F50C.AC328ADB.3CDDAF43.84E25240.20276; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail111-co9 (localhost.localdomain [127.0.0.1]) by mail111-co9 (MessageSwitch) id 1395163401503467_21121; Tue, 18 Mar 2014 17:23:21 +0000 (UTC) Received: from CO9EHSMHS029.bigfish.com (unknown [10.236.132.230]) by mail111-co9.bigfish.com (Postfix) with ESMTP id 72D7AA00046; Tue, 18 Mar 2014 17:23:21 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS029.bigfish.com (10.236.130.39) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 17:23:21 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 17:23:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 17:23:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.205]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 17:23:17 +0000 From: Kent Watsen To: Bert Wijnen , Martin Bjorklund Thread-Topic: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 Thread-Index: AQHPQgEzVxJH/+8ly0qHq2lfY3grn5rmcZQAgAALyACAAFkVgA== Date: Tue, 18 Mar 2014 17:23:16 +0000 Message-ID: References: <5327280E.7000407@ripe.net> <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> In-Reply-To: <5327FE0C.3000201@ripe.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0154C61618 Content-Type: text/plain; charset="us-ascii" Content-ID: <43693989097B034886075EF92F13371A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/xcbUk5T10rK8z8VqeIL8bp1UYWA Cc: "netconf@ietf.org" Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:23:44 -0000 I will submit an updated draft with this title shortly. Question, both the reverse-SSH and reverse-TLS drafts have "Informative" references to the netconf-server configuration draft. Should these be "Normative" references instead? - if so, do we have to wait for that draft to reach Last-Call status? Thanks, Kent On 3/18/14 4:04 AM, "Bert Wijnen" wrote: >OK, so we had a suggestion earlier on to make the title > > "Reverse Secure Shell for NETCONF" > >Unless anyone objects (before April 1st) we (WG chairs) >will instruct the editor/author to change the title to >the above. > >Bert > >On 18/03/14 08:22, Martin Bjorklund wrote: >> Hi, >> >> I have reviewed this document, and my only issues are related to the >> generic wording in the title and some other places. See the mail >> thread started by Juergen: >> http://www.ietf.org/mail-archive/web/netconf/current/msg08711.html >> >> >> >> /martin >> >> >> Bert Wijnen wrote: >>> Dear NETCONF participants, >>> >>> We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 >>> >>> The document acn be found at: >>> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 >>> >>> Pls review and send any comments (a comment aka: I read/reviewed it >>> and believe it is ready for publication" is also good input) to >>> the WG mailing lists not later than March 30th 2014 (any timezone). >>> >>> Any reports on implementation status or plans to implement are also >>> very useful. >>> >>> Bert and Mehmet >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf > > From nobody Tue Mar 18 10:53:54 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E0C41A03F6 for ; Tue, 18 Mar 2014 10:53:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tJ7X3KWDvVcq for ; Tue, 18 Mar 2014 10:53:49 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D461A1A06EA for ; Tue, 18 Mar 2014 10:53:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 29EFD105D; Tue, 18 Mar 2014 18:53:40 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id JN10nnnCS683; Tue, 18 Mar 2014 18:53:38 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 18 Mar 2014 18:53:38 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 828AB219A5; Tue, 18 Mar 2014 18:53:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZQKHfJweTJqh; Tue, 18 Mar 2014 18:53:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9A23F219A4; Tue, 18 Mar 2014 18:53:36 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0B5C72BCEB72; Tue, 18 Mar 2014 18:53:34 +0100 (CET) Date: Tue, 18 Mar 2014 18:53:34 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140318175334.GA3700@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/IHtOGO9h2gFzX4DPB6sLWOJgK34 Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 17:53:52 -0000 On Tue, Mar 18, 2014 at 05:18:15PM +0000, Kent Watsen wrote: > > > On 3/18/14 5:38 AM, "Juergen Schoenwaelder" > wrote: > > >On Wed, Mar 05, 2014 at 11:12:28AM +0000, Martin Bjorklund wrote: > >> Hi, > >> > >> I have reviewed this document, and have just one comment. > >> > >> The last paragraph of section 2.4.1 says: > >> > >> If the NETCONF client has external information as to the expected > >> identity of the NETCONF server, the hostname check MAY be omitted. > >> > >> There are some MUSTs in the preceding paragraphs, and it is not clear > >> to me what "the hostname check" refers to. > > > >I agree that this needs to be clarified in particular for outgoing > >call-home connections and I am not sure this is an easy one to > >address. > > > The lines quoted above were cut-n-pasted from HTTP Over TLS (RFC 2818) > section 3.1 (server identity): > http://tools.ietf.org/html/rfc2818#section-3.1. I raised this issue > before, on the -03 version of this draft, but see no follow-ups in the > archives: > > http://www.ietf.org/mail-archive/web/netconf/current/msg08075.html > > > > > > >For a conventional NETCONF client, you typically specify the hostname > >of the NETCONF server and then you check whether the certificate > >presented by the server is valid and matches the hostname. > > > >For call home, this is getting tricky. The NETCONF server has local > >config that says connect to TCP endpoint X to reach the NETCONF > >client. The NETCONF client now starts the TLS and receives a > >certificate which likely asserts a hostname. While the TLS client can > >validate the certificate, the question remains how the client verifies > >it is really talking to the right server? Since it does not know the > >hostname, we have three options (at least): > > > >1) The certificate must include the IP address used by the NETCONF > > server when it initiated the call home procedure. > > > >2) The NETCONF client does a reverse lookup to obtain a hostname that > > is then checked against the certificate (but can we trust DNS? - > > likely not). > > > >3) The NETCONF client has configured call home information that > > associates IP addresses of NETCONF servers calling home with either > > a hostname or likely even better with certificate fingerprints. > > This, of course, makes call home of yet unknown devices > > non-automatic. > > > Ultimately, we want to apply the same reasoning presented in the Reverse > SSH draft, section 5 (SSH Server Identification and Verification). As for > terminology, please note that when the TLS draft refers to "hostname", it > means the component identifying the server in a URL. Also, when the > Reverse SSH draft refers to "Host Key", it is equivalent to the server > certificate in TLS. So, the same rules apply: > > 1) it is possible for the NMS to identify the device solely via its > source-IP, but only works in networks with static addresses. This > strategy requires the NMS to have a store of trusted IP addresses. > > 2) it is possible for the NMS to identify the device via its certificate. > Think "strcmp()". This could be either via comparing the entire > certificate or a fingerprint of the certificate. But this strategy > requires the NMS to have a store of trusted device certificates. > > 3) it is *recommended* for the NMS to identify the device via information > contained inside the certificate - a unique identifier (e.g., serial > number, FQDN, etc.). But this strategy requires the NMS to have a store > of trusted unique identifiers. This approach is recommended because it > works even the certificate changes so long as the identifier is the same. > > 4) Making #3 even better, it is further recommended the NMS validates the > device's certificate via path-verification to a trusted CA (not explicitly > as described in #2). This enables the NMS to have to trust just a single > certificate (the CA's), not each device's... > > > Makes sense? > No. First, there needs to be an interoperable procedure for a standard. Second, this is not about how to extract an identity or something like that but how to check that the identity presented is an expected identity, means it is trust worthy and not an attempt to fool the NETCONF client. > >Note that the SSH call home mechanism has a similar problem to solve > >and I am not sure I understand what the solution is there either. > >There is some high-level text about host-keys and a recommendation > >that host-keys should be signed by a common key but I do not get from > >this what needs to be implemented. The server configuration I-D has > >a host-keys container but there is not much description here either: > > > > "An ordered listing of the SSH host keys the > > device should advertise to the application."; > > > > "The name of a host key the device should > > advertise during the SSH key exchange."; > > > >I do not know what the idea here is - establish the SSH and NETCONF > >session, then do a get-config to retrieve the keys and if the > >information does not match what I have used, drop the sessions? > > > You are probably familiar with SSH host-keys like "id_rsa.pub" and > "id_dsa.pub". These typically are _not_ host keys. > When using OpenSSH, the sshd_config file can contain one of > more "HostKey" entries, an ordered list. The ordering is important to the > SSH protocol, not just the OpenSSH implementation. The configuration > described in the netconf server configuration draft mentioned above maps > directly onto this concept, enabling it to be configurable per NMS. If this is the thing you want to solve, this first of needs to be described clearly. But then I am not sure why this needs to be solved. My SSH servers all have keys of different types, e.g., HostKey /etc/ssh/ssh_host_rsa_key HostKey /etc/ssh/ssh_host_dsa_key and somehow clients manage to use the servers without me configuring things. Are we moving into general SSH server configuration territory? Should these details be handled by a generic SSH server configuration data model, I mean is this essential for every NETCONF over SSH call home implementation? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Tue Mar 18 13:38:00 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B178B1A04B7 for ; Tue, 18 Mar 2014 13:37:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32JsoiR623K9 for ; Tue, 18 Mar 2014 13:37:56 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 109B61A02FB for ; Tue, 18 Mar 2014 13:37:56 -0700 (PDT) Received: from localhost (s193-12-74-81.cust.tele2.se [193.12.74.81]) by mail.tail-f.com (Postfix) with ESMTPSA id 24D8539400D; Tue, 18 Mar 2014 21:37:47 +0100 (CET) Date: Tue, 18 Mar 2014 21:37:46 +0100 (CET) Message-Id: <20140318.213746.253308776.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/H2M7TyW_AzEwImk2u5MYRpTNsC8 Cc: bwijnen@ripe.net, netconf@ietf.org Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 20:37:57 -0000 Kent Watsen wrote: > > I will submit an updated draft with this title shortly. Please consider my email http://www.ietf.org/mail-archive/web/netconf/current/msg08743.html as well. I think the term "Reverse SSH" is used throughtout the document, and it might be a good idea to either be explicit and change this to "Reverse SSH for NETCONF", or at least explain in the terminology section that "Reverse SSH" means "... for NETCONF". /martin From nobody Tue Mar 18 14:05:16 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AFE891A0417 for ; Tue, 18 Mar 2014 14:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.254 X-Spam-Level: X-Spam-Status: No, score=-1.254 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_BL_SPAMCOP_NET=1.347, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR1oetXObmQB for ; Tue, 18 Mar 2014 14:05:10 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe005.messaging.microsoft.com [216.32.180.31]) by ietfa.amsl.com (Postfix) with ESMTP id 102C41A0427 for ; Tue, 18 Mar 2014 14:05:07 -0700 (PDT) Received: from mail61-va3-R.bigfish.com (10.7.14.238) by VA3EHSOBE001.bigfish.com (10.7.40.21) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 21:04:59 +0000 Received: from mail61-va3 (localhost [127.0.0.1]) by mail61-va3-R.bigfish.com (Postfix) with ESMTP id 57FC3400116; Tue, 18 Mar 2014 21:04:59 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT001.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -25 X-BigFish: VPS-25(z579ehzbb2dI98dI9371I148cI111aIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail61-va3: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(43784003)(479174003)(377454003)(52604005)(24454002)(74366001)(31966008)(47446002)(74662001)(92566001)(77096001)(54356001)(53806001)(36756003)(92726001)(51856001)(56776001)(81342001)(74502001)(54316002)(76786001)(76796001)(81542001)(69226001)(95666003)(85852003)(66066001)(79102001)(76482001)(20776003)(97186001)(80022001)(46102001)(63696002)(85306002)(50986001)(86362001)(93516002)(94946001)(83072002)(93136001)(94316002)(83506001)(19580395003)(74706001)(90146001)(19580405001)(56816005)(81816001)(80976001)(81686001)(95416001)(97336001)(49866001)(74876001)(47976001)(47736001)(77982001)(65816001)(59766001)(87266001)(87936001)(83322001)(4396001)(2656002); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:AF9ED989.143243D1.16C7B3A9.1EC093CD.20103; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail61-va3 (localhost.localdomain [127.0.0.1]) by mail61-va3 (MessageSwitch) id 1395176695644995_30959; Tue, 18 Mar 2014 21:04:55 +0000 (UTC) Received: from VA3EHSMHS023.bigfish.com (unknown [10.7.14.254]) by mail61-va3.bigfish.com (Postfix) with ESMTP id B07BC3C0063; Tue, 18 Mar 2014 21:04:54 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by VA3EHSMHS023.bigfish.com (10.7.99.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 21:04:40 +0000 Received: from CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 21:04:40 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB459.namprd05.prod.outlook.com (10.141.72.146) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 21:04:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.205]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 21:04:37 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 Thread-Index: AQHPQgEzVxJH/+8ly0qHq2lfY3grn5rmcZQAgAALyACAAFkVgIAAeWMA///EdIA= Date: Tue, 18 Mar 2014 21:04:36 +0000 Message-ID: References: <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> <20140318.213746.253308776.mbj@tail-f.com> In-Reply-To: <20140318.213746.253308776.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0154C61618 Content-Type: text/plain; charset="us-ascii" Content-ID: <690A320329E8E04C87B175B9F8552C7E@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/eausBrtM_VkRopjUge9HvZnsViI Cc: "bwijnen@ripe.net" , "netconf@ietf.org" Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 21:05:12 -0000 On 3/18/14 4:37 PM, "Martin Bjorklund" wrote: >Please consider my email >http://www.ietf.org/mail-archive/web/netconf/current/msg08743.html as >well. Will do, thanks for bringing focus to it again. >I think the term "Reverse SSH" is used throughtout the document, and >it might be a good idea to either be explicit and change this to >"Reverse SSH for NETCONF", or at least explain in the terminology >section that "Reverse SSH" means "... for NETCONF". OK, I'll check for consistency too. Thanks again, Kent From nobody Tue Mar 18 15:28:37 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2DE11A03F1 for ; Tue, 18 Mar 2014 15:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q75GcSqTh8HY for ; Tue, 18 Mar 2014 15:28:29 -0700 (PDT) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id 3A7981A0125 for ; Tue, 18 Mar 2014 15:28:29 -0700 (PDT) Received: from mail198-ch1-R.bigfish.com (10.43.68.252) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Tue, 18 Mar 2014 22:28:20 +0000 Received: from mail198-ch1 (localhost [127.0.0.1]) by mail198-ch1-R.bigfish.com (Postfix) with ESMTP id 9C10C12036C; Tue, 18 Mar 2014 22:28:20 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT003.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -1 X-BigFish: VPS-1(zz1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de097hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh25cch25f6h2605h262fh2668h1155h) Received-SPF: pass (mail198-ch1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(189002)(199002)(51704005)(2656002)(87266001)(83322001)(46102001)(19580395003)(80976001)(53806001)(77096001)(36756003)(76786001)(76796001)(85306002)(50986001)(47976001)(56816005)(74366001)(87936001)(97186001)(92726001)(54356001)(95416001)(92566001)(79102001)(51856001)(81542001)(86362001)(4396001)(56776001)(81816001)(63696002)(81686001)(95666003)(69226001)(76482001)(54316002)(93136001)(74706001)(80022001)(65816001)(20776003)(83506001)(74502001)(47446002)(74662001)(81342001)(94946001)(90146001)(97336001)(74876001)(59766001)(85852003)(31966008)(66066001)(83072002)(49866001)(94316002)(77982001)(93516002)(47736001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:AED7F55D.A73A5403.DEF3D48.44D6ECE1.2037E; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail198-ch1 (localhost.localdomain [127.0.0.1]) by mail198-ch1 (MessageSwitch) id 1395181698519027_6770; Tue, 18 Mar 2014 22:28:18 +0000 (UTC) Received: from CH1EHSMHS008.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.231]) by mail198-ch1.bigfish.com (Postfix) with ESMTP id 7985648006E; Tue, 18 Mar 2014 22:28:18 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS008.bigfish.com (10.43.70.8) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 18 Mar 2014 22:28:18 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.423.0; Tue, 18 Mar 2014 22:28:17 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) with Microsoft SMTP Server (TLS) id 15.0.898.11; Tue, 18 Mar 2014 22:28:14 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.205]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.73]) with mapi id 15.00.0898.005; Tue, 18 Mar 2014 22:28:14 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 Thread-Index: AQHPOGPi0lBZ6ooeOE+AzxE/IuduwJrmqu6AgAA9VwCAAEzpAIAACbOA Date: Tue, 18 Mar 2014 22:28:12 +0000 Message-ID: References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> In-Reply-To: <20140318175334.GA3700@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.11] x-forefront-prvs: 0154C61618 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/BaxYDVBIPfzeLug5NdGlJxy3vhw Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Mar 2014 22:28:32 -0000 >No. First, there needs to be an interoperable procedure for a >standard. Second, this is not about how to extract an identity or >something like that but how to check that the identity presented is an >expected identity, means it is trust worthy and not an attempt to fool >the NETCONF client. There is no foolery here, this is how it works. When using a TLS-client library, it undoubtedly provides a callback that will be executed for the app to state whether the server's certificate can be trusted. In addition to the certificate itself (and any intermediate certs that may also have been provided), the callback will likely also a handle to a "connection" object of some sort, from which the application can learn the peer's source IP address. So that's it, the app has an IP-address, a certificate (+intermediate certs), and its preconfigured state. >>You are probably familiar with SSH host-keys like "id_rsa.pub" and >> "id_dsa.pub". > >These typically are _not_ host keys. You're right, I meant ssh_host_rsa_key.pub and ssh_host_dsa_key.pub. >> When using OpenSSH, the sshd_config file can contain one of >> more "HostKey" entries, an ordered list. The ordering is important to >>the >> SSH protocol, not just the OpenSSH implementation. The configuration >> described in the netconf server configuration draft mentioned above maps >> directly onto this concept, enabling it to be configurable per NMS. > >If this is the thing you want to solve, this first of needs to be >described clearly. But then I am not sure why this needs to be solved. >My SSH servers all have keys of different types, e.g., > >HostKey /etc/ssh/ssh_host_rsa_key >HostKey /etc/ssh/ssh_host_dsa_key > >and somehow clients manage to use the servers without me configuring >things. Are we moving into general SSH server configuration territory? >Should these details be handled by a generic SSH server configuration >data model, I mean is this essential for every NETCONF over SSH call >home implementation? It is SSH-server configuration, yes, but not for the generic server listening on port 22 and also not for any generic configuration option. We just need enough to support the netconf-server config model draft (keep alive interval, keep alive count max, etc.). Being able to configure which SSH HostKeys are presented is equivalent to being able to configure which TLS server-certificate the device should present, if there is more than one, which is completely possible. Kent From nobody Wed Mar 19 00:20:42 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AF5D1A0674 for ; Wed, 19 Mar 2014 00:20:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FiBODHKv5kPf for ; Wed, 19 Mar 2014 00:20:31 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 948D91A0652 for ; Wed, 19 Mar 2014 00:20:31 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by koko.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WQAnU-0005sy-Ma; Wed, 19 Mar 2014 08:20:21 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-3.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WQAnU-00033X-IK; Wed, 19 Mar 2014 08:20:20 +0100 Message-ID: <53294535.6070402@ripe.net> Date: Wed, 19 Mar 2014 08:20:21 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , Martin Bjorklund References: <5327280E.7000407@ripe.net> <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e1dcae2f70c6f6c5dbaa2289eed366d97 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bz2n34XyzD5z7BmfTRGHPQ1ongg Cc: "netconf@ietf.org" Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:20:34 -0000 On 18/03/14 18:23, Kent Watsen wrote: > > I will submit an updated draft with this title shortly. > kent, please wait till we have WG Last Call finished and then you should do a revision that addresses all comments, not just this one. Process wise it is easier to do a compare between 2 revisions than between multiple versions. Thanks, Bert > Question, both the reverse-SSH and reverse-TLS drafts have "Informative" > references to the netconf-server configuration draft. Should these be > "Normative" references instead? - if so, do we have to wait for that > draft to reach Last-Call status? > > Thanks, > Kent > > > > On 3/18/14 4:04 AM, "Bert Wijnen" wrote: > >> OK, so we had a suggestion earlier on to make the title >> >> "Reverse Secure Shell for NETCONF" >> >> Unless anyone objects (before April 1st) we (WG chairs) >> will instruct the editor/author to change the title to >> the above. >> >> Bert >> >> On 18/03/14 08:22, Martin Bjorklund wrote: >>> Hi, >>> >>> I have reviewed this document, and my only issues are related to the >>> generic wording in the title and some other places. See the mail >>> thread started by Juergen: >>> http://www.ietf.org/mail-archive/web/netconf/current/msg08711.html >>> >>> >>> >>> /martin >>> >>> >>> Bert Wijnen wrote: >>>> Dear NETCONF participants, >>>> >>>> We hereby issue a WG Last Call for raft-ietf-netconf-reverse-ssh-03 >>>> >>>> The document acn be found at: >>>> http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 >>>> >>>> Pls review and send any comments (a comment aka: I read/reviewed it >>>> and believe it is ready for publication" is also good input) to >>>> the WG mailing lists not later than March 30th 2014 (any timezone). >>>> >>>> Any reports on implementation status or plans to implement are also >>>> very useful. >>>> >>>> Bert and Mehmet >>>> >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> > > From nobody Wed Mar 19 00:21:28 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30F601A066E for ; Wed, 19 Mar 2014 00:21:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVtTlNv89rgV for ; Wed, 19 Mar 2014 00:21:17 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id E7FDC1A0654 for ; Wed, 19 Mar 2014 00:21:15 -0700 (PDT) Received: from nene.ripe.net ([193.0.23.10]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WQAoD-0003yO-Dj; Wed, 19 Mar 2014 08:21:06 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-3.local) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WQAoD-0003G3-97; Wed, 19 Mar 2014 08:21:05 +0100 Message-ID: <53294562.6020102@ripe.net> Date: Wed, 19 Mar 2014 08:21:06 +0100 From: Bert Wijnen User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Martin Bjorklund , kwatsen@juniper.net References: <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> <20140318.213746.253308776.mbj@tail-f.com> In-Reply-To: <20140318.213746.253308776.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay domain -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 5ef2bffdfa2294c21c35da1b4f77885e0219dbc6d7b1c8cd30925b0bddb9bfe2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ou-kO07zEemtmFu1-CNZLaN7UO4 Cc: netconf@ietf.org Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 07:21:24 -0000 Makes sense in my view. Consistency is always good I think. Bert On 18/03/14 21:37, Martin Bjorklund wrote: > Kent Watsen wrote: >> >> I will submit an updated draft with this title shortly. > > Please consider my email > http://www.ietf.org/mail-archive/web/netconf/current/msg08743.html as > well. > > I think the term "Reverse SSH" is used throughtout the document, and > it might be a good idea to either be explicit and change this to > "Reverse SSH for NETCONF", or at least explain in the terminology > section that "Reverse SSH" means "... for NETCONF". > > > /martin > From nobody Wed Mar 19 01:39:19 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1ED0F1A04B4 for ; Wed, 19 Mar 2014 01:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vjh4NZYDyj73 for ; Wed, 19 Mar 2014 01:39:14 -0700 (PDT) Received: from kaka.ripe.net (kaka.ripe.net [IPv6:2001:67c:2e8:11::c100:1347]) by ietfa.amsl.com (Postfix) with ESMTP id 44E081A06C1 for ; Wed, 19 Mar 2014 01:39:13 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by kaka.ripe.net with esmtps (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1WQC1f-0003Ba-5G; Wed, 19 Mar 2014 09:39:04 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh-3.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WQC1e-0004Nr-VT; Wed, 19 Mar 2014 09:39:03 +0100 Message-ID: <532957A6.7040602@bwijnen.net> Date: Wed, 19 Mar 2014 09:39:02 +0100 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Kent Watsen , Bert Wijnen , Martin Bjorklund References: <5327280E.7000407@ripe.net> <20140318.082218.579296055407207171.mbj@tail-f.com> <5327FE0C.3000201@ripe.net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-RIPE-Spam-Level: -- X-RIPE-Spam-Report: Spam Total Points: -2.9 points pts rule name description ---- ---------------------- ------------------------------------ -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd45ee6f3ced6afdb3c6b24da5d8c3d4df2 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/WCiyRt8oZDaDbPgAbi5yNEdxZSk Cc: "netconf@ietf.org" Subject: Re: [Netconf] Action before April 1st 2014: WGLC for draft-ietf-netconf-reverse-ssh-03 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Mar 2014 08:39:16 -0000 On 18/03/14 18:23, Kent Watsen wrote: > Question, both the reverse-SSH and reverse-TLS drafts have "Informative" > references to the netconf-server configuration draft. Should these be > "Normative" references instead? - if so, do we have to wait for that > draft to reach Last-Call status? I would have to re-check if "does one need too understand the netconf-server" draft in order to understand these 2. Does one need to implement the netconf-server draft in order for reverse-XXX to ve able o work at all? If the answer is YES, then we probably have to wait. AT least publication as RFC will have to wait. THat will wait automatically at the RFC-Editor station. But we should be careful to make sure we then do not make incompatible changes to netconf-server draft that would require any changes to the reverse-XXX drafts. Bert From nobody Fri Mar 21 00:47:08 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 765FC1A0945 for ; Fri, 21 Mar 2014 00:47:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dEa9rUmwKTqT for ; Fri, 21 Mar 2014 00:47:02 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 575651A0515 for ; Fri, 21 Mar 2014 00:47:02 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B7082FE4; Fri, 21 Mar 2014 08:46:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id goallrjucLPd; Fri, 21 Mar 2014 08:46:51 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 21 Mar 2014 08:46:51 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id DA9C12002F; Fri, 21 Mar 2014 08:46:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qq9evdU4-341; Fri, 21 Mar 2014 08:46:51 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B80652002C; Fri, 21 Mar 2014 08:46:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A8AA92BD4B94; Fri, 21 Mar 2014 08:46:48 +0100 (CET) Date: Fri, 21 Mar 2014 08:46:47 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20140321074646.GA12080@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "netconf@ietf.org" References: <20140305.111228.304368597.mbj@tail-f.com> <20140318093843.GC2109@elstar.local> <20140318175334.GA3700@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/HzxKEaiKKciTN2gK6l-XHtjXzWg Cc: "netconf@ietf.org" Subject: Re: [Netconf] comment on draft-ietf-netconf-rfc5539bis-05 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 07:47:05 -0000 On Tue, Mar 18, 2014 at 10:28:12PM +0000, Kent Watsen wrote: > > > >No. First, there needs to be an interoperable procedure for a > >standard. Second, this is not about how to extract an identity or > >something like that but how to check that the identity presented is an > >expected identity, means it is trust worthy and not an attempt to fool > >the NETCONF client. > > There is no foolery here, this is how it works. When using a TLS-client > library, it undoubtedly provides a callback that will be executed for the > app to state whether the server's certificate can be trusted. In addition > to the certificate itself (and any intermediate certs that may also have > been provided), the callback will likely also a handle to a "connection" > object of some sort, from which the application can learn the peer's > source IP address. So that's it, the app has an IP-address, a certificate > (+intermediate certs), and its preconfigured state. So what is this preconfigured state? How is the decision been taken? All implementation specific? So I need to study the vendors handbooks to figure out how setup things? > >>You are probably familiar with SSH host-keys like "id_rsa.pub" and > >> "id_dsa.pub". > > > >These typically are _not_ host keys. > > You're right, I meant ssh_host_rsa_key.pub and ssh_host_dsa_key.pub. > > > > >> When using OpenSSH, the sshd_config file can contain one of > >> more "HostKey" entries, an ordered list. The ordering is important to > >>the > >> SSH protocol, not just the OpenSSH implementation. The configuration > >> described in the netconf server configuration draft mentioned above maps > >> directly onto this concept, enabling it to be configurable per NMS. > > > >If this is the thing you want to solve, this first of needs to be > >described clearly. But then I am not sure why this needs to be solved. > >My SSH servers all have keys of different types, e.g., > > > >HostKey /etc/ssh/ssh_host_rsa_key > >HostKey /etc/ssh/ssh_host_dsa_key > > > >and somehow clients manage to use the servers without me configuring > >things. Are we moving into general SSH server configuration territory? > >Should these details be handled by a generic SSH server configuration > >data model, I mean is this essential for every NETCONF over SSH call > >home implementation? > > It is SSH-server configuration, yes, but not for the generic server > listening on port 22 and also not for any generic configuration option. > We just need enough to support the netconf-server config model draft (keep > alive interval, keep alive count max, etc.). Being able to configure > which SSH HostKeys are presented is equivalent to being able to configure > which TLS server-certificate the device should present, if there is more > than one, which is completely possible. This is inconsistent. We have no configuration model for all these things for the regular case - why do we now go ahead and define some of this for the call home case? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Sun Mar 23 16:03:39 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CCB0A1A6F97; Sun, 23 Mar 2014 16:03:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPVlIV1JDKXK; Sun, 23 Mar 2014 16:03:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BC451A07F9; Sun, 23 Mar 2014 16:03:35 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140323230335.13746.40327.idtracker@ietfa.amsl.com> Date: Sun, 23 Mar 2014 16:03:35 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/PZF9U8JLM0hQTmtKdpkhtIe3YVQ Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-restconf-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:03:37 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : RESTCONF Protocol Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-ietf-netconf-restconf-00.txt Pages : 95 Date : 2014-03-22 Abstract: This document describes a REST-like protocol that provides a programmatic interface over HTTP for accessing data defined in YANG, using the datastores defined in NETCONF. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-restconf/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-restconf-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Sun Mar 23 16:04:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 768EB1A6F7E; Sun, 23 Mar 2014 16:04:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ohNSGsw24ksO; Sun, 23 Mar 2014 16:04:13 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E37031A7001; Sun, 23 Mar 2014 16:04:12 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140323230412.18024.97557.idtracker@ietfa.amsl.com> Date: Sun, 23 Mar 2014 16:04:12 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/ZaNxoPaWfE444ZyrN8dRIaRXL_w Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-yang-patch-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 23 Mar 2014 23:04:16 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration Working Group of the IETF. Title : YANG Patch Media Type Authors : Andy Bierman Martin Bjorklund Kent Watsen Rex Fernando Filename : draft-ietf-netconf-yang-patch-00.txt Pages : 33 Date : 2014-03-22 Abstract: This document describes a method for applying patches to NETCONF datastores using data defined with the YANG data modeling language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-yang-patch/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-yang-patch-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Mar 25 08:18:22 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF1DA1A0133 for ; Tue, 25 Mar 2014 08:18:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.788 X-Spam-Level: X-Spam-Status: No, score=0.788 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id orwp3eRvQXRN for ; Tue, 25 Mar 2014 08:18:00 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 17E881A00D9 for ; Tue, 25 Mar 2014 08:18:00 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA14596; Tue, 25 Mar 2014 11:17:58 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id LAA15291; Tue, 25 Mar 2014 11:17:57 -0400 (EDT) Date: Tue, 25 Mar 2014 11:17:57 -0400 (EDT) From: Alan Luchuk Message-Id: <201403251517.LAA15291@adminfs.snmp.com> To: netconf@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/yuqgpluUlwAX3BlviwHUD-z4E9Q Subject: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Mar 2014 15:18:03 -0000 Hello, Here are comments on draft-ietf-netconf-reverse-ssh-03.txt. I know of no serious technical issues with this draft. These comments mostly identify typos, comment on wording, or seek clarification. I hope the comments are helpful; do what seems appropriate with them. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ Typos ----- The first batch of these have incorrect capitalization of "SSH Server". I think "Server" should be "server" because in these specific cases, "server" is not part of a section title and is not a proper noun. Line 22: s/the SSH Server, in order for/the SSH server, in order for/ ^ ^ Line 151: s/the role of SSH Server is/the role of SSH server is/ ^ ^ Line 153: s/opened on the SSH Server/opened on the SSH server/ ^ ^ Line 213: s/the SSH Server protocol/the SSH server protocol/ ^ ^ Line 348: s/the SSH Server's host name/the SSH server's host name/ ^ ^ Line 264: s/the mangement element can verify/the management system can verify/ ^^ ^^^^^^^ ^^^ ^^^^^^ Line 289: s/the mangement system only/the management system only/ ^^ ^^^ Line 347: s/host keys in locally cached/host keys in a locally cached/ ^ Line 352: s/Man-in-th-/Man-in-the-/ ^^ ^^^ Section 2.1, Page 3, Second Paragraph: (wording) ------------------------------------------------- The second paragraph seems vague. Would something along the lines of the following text be clearer and/or more specific? The reason for this restriction is that the SSH protocol is designed to be initiated by a client connecting to a server. SSH is designed to resist a specific set of security threats in accordance with this usage. Because NETCONF requires that a client provide a username which the NETCONF server must authenticate before starting the NETCONF protocol, in addition to the security provided by SSH, NETCONF's use of reverse SSH is considered secure. Reverse SSH MUST NOT be used for purposes other than NETCONF because the general-purpose use of reverse SSH might have security vulnerabilities that require a thorough security analysis to mitigate. Section 4, Page 4: (wording) ----------------------------- The current text reads: o The NETCONF server initiates a TCP connection to the NETCONF client on the IANA-assigned Reverse SSH port YYYY. o The TCP connection is accepted and a TCP session is established. Because the server and client roles are swapped during the initial TCP connection, would the following text help clarify the role reversal? o The NETCONF server initiates a TCP connection to the NETCONF client which listens on the IANA-assigned Reverse SSH port YYYY. ^^^^^^^^^^^^^ o The NETCONF client accepts the TCP connection and a TCP session is established. Section 5, Page 5, First Paragraph: (wording) ---------------------------------------------- The current text reads: "When the management system accepts a new incoming connection, it needs to authenticate the remote peer. Ultimately, this entails identifying the peer and verifying its SSH host key. Due to Reverse SSH having the network element initiate the TCP connection," Because the server and client roles are swapped during the initial TCP connection, would the following text help clarify the role reversal? "When the management system (normally the NETCONF client) accepts ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ a new incoming connection, it must authenticate the remote peer. Ultimately, this entails identifying the peer and verifying its SSH host key. Due to Reverse SSH having the network element (normally the NETCONF ^^^^^^^^^^^^^^^^^^^^^ server) initiate the TCP connection," ^^^^^^^ Section 5, Page 6, First Paragraph: (clarification) ---------------------------------------------------- The current text reads: "However, configuring distinct host keys on the management system doesn't scale well, which is an important consideration to a network management system. A more scalable strategy is to have the network element's host key signed by a common trusted key, such as a certificate authority. Thus, the mangement system only needs to trust a single public key, which vouches for the authenticity of the various network element public keys." Please help me understand this. The way this paragraph is written, it is not clear to me why "signing each network element's host key with a common trusted key" scales better than "configuring distinct host keys on the management system". In either of these two situations, it seems like an administrator must do work for each network element. In one case, it is configuring host keys, in another, it is signing each network element's host key. If anything, it seems like signing a host key for each network element requires _more_ work for each network element, so it seems like this would scale less well. What am I missing here? Section 7, Page 7, Third Paragraph: (wording) ---------------------------------------------- In a few places in the third paragraph, and possibly in other places in the document, would changing "needs to" to lowercase "must", or lowercase "should", make the document a little more concise? Example: "Note that since the SSH server would have to be configured to know which IP address it needs to connect to," ^^^^^^^^ to: "Note that since the SSH server would have to be configured to know which IP address it should connect to," ^^^^^^ From nobody Wed Mar 26 10:34:23 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1153C1A01D1 for ; Wed, 26 Mar 2014 10:34:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.912 X-Spam-Level: X-Spam-Status: No, score=-1.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIpaxuIiT1HO for ; Wed, 26 Mar 2014 10:34:20 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 9E2AB1A01BB for ; Wed, 26 Mar 2014 10:34:19 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id NAA17015; Wed, 26 Mar 2014 13:34:16 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id NAA19801; Wed, 26 Mar 2014 13:34:14 -0400 (EDT) Date: Wed, 26 Mar 2014 13:34:14 -0400 (EDT) From: Alan Luchuk Message-Id: <201403261734.NAA19801@adminfs.snmp.com> To: netconf@ietf.org Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/AOewRcWBYSBEtpXQS3SOw0zZjYA Subject: [Netconf] Comments on draft-kwatsen-netconf-server-01.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 17:34:22 -0000 Hello, Here are comments on draft-kwatsen-netconf-server-01.txt. I did not find serious technical issues with this draft. The comments identify typos, wording, or clarifications. I hope these comments are helpful; do what seems appropriate with them. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------ Typos ----- Line 218: s/applications servers/application's servers/ ^ ^^ Line 295: s/transmitted as transpired/transmitted has transpired/ ^ Line 509: s/I-D.ietf-netconf-rfc5539bis/I-D.ietf-netmod-snmp-cfg/ Line 691: s/device iniates connections/device initiates connections/ ^^ ^^^^ Line 1138: s/a YANG modules to configure/a YANG module to configure/ ^ Section 2.5.1, Page 4, Paragraph 1: (wording) ---------------------------------------------- The term "northbound" is not defined. Section 2.5.3, Page 5, Paragraph 2: (wording) ---------------------------------------------- Part of the last sentence reads: strategy guides the device how to get connected to another server. ^^^^^^^^^^^^^ I suggest the following is slightly more concise: strategy guides the device how to connect to another server. ^^^^^^^ Page 15, description under the "container periodic" (wording) -------------------------------------------------------------- Part of the last sentence reads: server-to-application data, the data should be sent immediately, connecting to application first if not already."; I suggest the following is clearer: server-to-application data, the data should be sent immediately, connecting to application first if not already connected."; ^^^^^^^^^^ Page 15, type under the "leaf linger-secs": (Technical) -------------------------------------------------------- The linger-secs leaf is of type uint8. This allows a maximum connection hold time of 255 seconds, or a little over 4 minutes. Is this long enough, or should this be changed to a uint16? Page 20, "leaf user-name" and "leaf key": (Technical/Clarification) -------------------------------------------------------------------- The user-name leaf and the key leaf have a "mandatory true" substatement. Is this intended and correct? Will there be any undesired side effects of putting "mandatory true" in a grouping definition? I studied the RFC 6020 description of the leaf's mandatory statement, in RFC 6020 Section 7.6.5, to understand and resolve these questions. I was unable to come to a satisfactory conclusion. Page 25, Appendix B: (Nit) --------------------------- The same cert fingerprint is used in both entries in the list. I suggest changing one or the other fingerprint. Someone studying the current example to understand how the cert to name mapping works might be confused by the same fingerprint in two entries; they might not understand which NETCONF username would be returned. From nobody Thu Mar 27 09:02:40 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 174A21A032A for ; Thu, 27 Mar 2014 09:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xXGTfA5ckdAy for ; Thu, 27 Mar 2014 09:02:36 -0700 (PDT) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 3F0C31A067E for ; Thu, 27 Mar 2014 09:02:24 -0700 (PDT) Received: from mail92-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE019.bigfish.com (10.3.207.141) with Microsoft SMTP Server id 14.1.225.22; Thu, 27 Mar 2014 16:02:21 +0000 Received: from mail92-am1 (localhost [127.0.0.1]) by mail92-am1-R.bigfish.com (Postfix) with ESMTP id C9847C03A6; Thu, 27 Mar 2014 16:02:21 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.56.240.101; KIP:(null); UIP:(null); IPV:NLI; H:BL2PRD0510HT004.namprd05.prod.outlook.com; RD:none; EFVD:NLI X-SpamScore: -12 X-BigFish: VPS-12(zz103dK1dbaI1432I1418I14e3M111aIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch25f6h2605h262fh268bh1155h) Received-SPF: pass (mail92-am1: domain of juniper.net designates 157.56.240.101 as permitted sender) client-ip=157.56.240.101; envelope-from=kwatsen@juniper.net; helo=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(428001)(199002)(189002)(41574002)(51444003)(51704005)(43784003)(83322001)(80022001)(65816001)(87266001)(2656002)(80976001)(59766001)(56776001)(66066001)(54316002)(74706001)(85852003)(97336001)(74366001)(74876001)(81686001)(87936001)(79102001)(97186001)(63696002)(77982001)(20776003)(85306002)(54356001)(76482001)(51856001)(46102001)(95416001)(56816005)(92566001)(83072002)(47976001)(36756003)(92726001)(50986001)(4396001)(93136001)(69226001)(98676001)(74662001)(81342001)(47446002)(94316002)(81816001)(86362001)(83506001)(74502001)(81542001)(95666003)(53806001)(94946001)(47736001)(76796001)(76786001)(93516002)(31966008)(49866001)(90146001)(77096001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:DEECF056.ACF251A1.B2D7124B.5EE4F3F1.204F5; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail92-am1 (localhost.localdomain [127.0.0.1]) by mail92-am1 (MessageSwitch) id 1395936139105827_11446; Thu, 27 Mar 2014 16:02:19 +0000 (UTC) Received: from AM1EHSMHS001.bigfish.com (unknown [10.3.201.229]) by mail92-am1.bigfish.com (Postfix) with ESMTP id 144FB4800AE; Thu, 27 Mar 2014 16:02:19 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS001.bigfish.com (10.3.207.101) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 27 Mar 2014 16:02:18 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.423.0; Thu, 27 Mar 2014 16:02:09 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) with Microsoft SMTP Server (TLS) id 15.0.898.11; Thu, 27 Mar 2014 16:02:07 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.150]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.150]) with mapi id 15.00.0898.005; Thu, 27 Mar 2014 16:02:07 +0000 From: Kent Watsen To: Alan Luchuk , "netconf@ietf.org" Thread-Topic: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPSD2L8MBjFH7FsEGiHJ1NM7CgMpr02FYA Date: Thu, 27 Mar 2014 16:02:06 +0000 Message-ID: References: <201403251517.LAA15291@adminfs.snmp.com> In-Reply-To: <201403251517.LAA15291@adminfs.snmp.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.9.131030 x-originating-ip: [66.129.241.14] x-forefront-prvs: 01630974C0 Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RhNYGKhznuhmlk7kO5OjJZzKEuY Subject: Re: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 27 Mar 2014 16:02:38 -0000 Hi Alan, Awesome comments - thanks! I applied all fixes mentioned below to my working copy of what will be -04, so you'll have to wait until then to see the diff. The reason I'm not posting -04 now is because I'm still trying to work out an issue with Applicability Statement and with the port's name. Below are my detailed responses. Cheers, Kent >Typos >----- > I fixed all the issues you found. >Section 2.1, Page 3, Second Paragraph: (wording) >------------------------------------------------- > >The second paragraph seems vague. Would something along the lines of >the following text be clearer and/or more specific? I forwarded this comment to Steve Hanna, who wrote the Applicability Statement. At first I was just going to ask if he was OK with the proposed text, but then I started thinking that I didn't agree with it. That is, I think that the SSH protocol does require mutual authentication and that NETCONF's requirement that it be possible to derive a "username" from the transport doesn't change that. I'm still OK limiting Reverse SSH to just NETCONF, but I want the reason to be accurate. I'm now waiting for a response from Steve on this. >Section 4, Page 4: (wording) >----------------------------- > >The current text reads: > > o The NETCONF server initiates a TCP connection to the NETCONF > client on the IANA-assigned Reverse SSH port YYYY. > > o The TCP connection is accepted and a TCP session is established. I'm not sure about this change since these bullet-points are preceded by the line "From the NETCONF server's perspective:". The intent is to only explain the NETCONF-server's perspective, and to let the next section provide the client's perspective. Currently, neither section references the remote peer, so that its text remains squarely focused on its side of the connection. What do you think? >Section 5, Page 5, First Paragraph: (wording) >---------------------------------------------- > >The current text reads: > > "When the management system accepts a new incoming connection, it > needs to authenticate the remote peer. Ultimately, this entails > identifying the peer and verifying its SSH host key. > > Due to Reverse SSH having the network element initiate the TCP > connection," I changed the wording to be more clear, but did it another way, please let me know if you think it's OK! >Section 5, Page 6, First Paragraph: (clarification) >---------------------------------------------------- > >The current text reads: > > "However, configuring distinct host keys on the management system > doesn't scale well, which is an important consideration to a network > management system. A more scalable strategy is to have the network > element's host key signed by a common trusted key, such as a > certificate authority. Thus, the mangement system only needs to > trust a single public key, which vouches for the authenticity of the > various network element public keys." > >Please help me understand this. The way this paragraph is written, it >is not clear to me why "signing each network element's host key with a >common trusted key" scales better than "configuring distinct host keys >on the management system". > >In either of these two situations, it seems like an administrator must >do work for each network element. In one case, it is configuring host >keys, in another, it is signing each network element's host key. If >anything, it seems like signing a host key for each network element >requires _more_ work for each network element, so it seems like this >would scale less well. > >What am I missing here? Very good question. Of course it comes down to how the device's "entity certificates", as they are called, is distributed. In the best case, as described in the zero-touch draft, the device would ship from factory with a built-in entity-certificate, signed by a trust-chain to its vendor's well-known trust anchor. In this case, there is no additional effort needed, the management system only needs to trust the vendor's certificate for its well-known trust anchor. For cases where the device doesn't ship from factory with an entity-certificate, introducing PKI is still advantageous as it decouples the management-system from direct involvement, such that it could be outsourced to some 3rd-party. Makes sense? What update would you like to see in the draft? >Section 7, Page 7, Third Paragraph: (wording) >---------------------------------------------- > >In a few places in the third paragraph, and possibly in other places >in the document, would changing "needs to" to lowercase "must", or >lowercase "should", make the document a little more concise? Example: > > "Note that since the SSH server would have to be configured to know > which IP address it needs to connect to," > ^^^^^^^^ I changed "needs to" to "is to" for this cited location and another I found. Thanks again, Kent From nobody Fri Mar 28 08:42:38 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 730701A0639 for ; Fri, 28 Mar 2014 08:42:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.56 X-Spam-Level: X-Spam-Status: No, score=-1.56 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5qC1a-E_f1-u for ; Fri, 28 Mar 2014 08:42:34 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 044C11A063C for ; Fri, 28 Mar 2014 08:42:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9D035EB2 for ; Fri, 28 Mar 2014 16:42:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.220]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZFLRbOd3hI_N for ; Fri, 28 Mar 2014 16:42:30 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 28 Mar 2014 16:42:30 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B05782002F for ; Fri, 28 Mar 2014 16:42:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PLVEYeuzJRtd for ; Fri, 28 Mar 2014 16:42:29 +0100 (CET) Received: from exchange.jacobs-university.de (shubcas01.jacobs.jacobs-university.de [10.70.0.122]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by hermes.jacobs-university.de (Postfix) with ESMTPS id 49E082002C for ; Fri, 28 Mar 2014 16:42:29 +0100 (CET) Received: from SXCHMB01.jacobs.jacobs-university.de ([fe80::c1f:c30f:99ac:df0c]) by SHUBCAS01.jacobs.jacobs-university.de ([::1]) with mapi id 14.03.0174.001; Fri, 28 Mar 2014 16:42:28 +0100 From: "Bajpai, Vaibhav" To: "netconf@ietf.org" Thread-Topic: implementing: [draft-ietf-netconf-rfc5539bis-05] Thread-Index: AQHPSpxS2+uxN3ZV00+sg1mfK69AQw== Date: Fri, 28 Mar 2014 15:42:27 +0000 Message-ID: <988F9319-06F2-4843-AC8B-59CD85BB1E6A@jacobs-university.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.50.203.30] Content-Type: multipart/signed; boundary="Apple-Mail=_8AB63C2A-6370-46E8-876C-B100D441D86A"; protocol="application/pgp-signature"; micalg=pgp-sha512 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/4JJVGxXeEEs7XyIYIqKojcxtV38 Subject: [Netconf] implementing: [draft-ietf-netconf-rfc5539bis-05] X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Mar 2014 15:42:36 -0000 --Apple-Mail=_8AB63C2A-6370-46E8-876C-B100D441D86A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hello, We have implemented the NETCONF over TLS and the Call Home mechanism as described in the document [draft-ietf-netconf-rfc5539bis-05]. We used = netopeer [1] as our NETCONF server, and ncclient [2] as our NETCONF client. [1] https://code.google.com/p/netopeer [2] http://cnds.eecs.jacobs-university.de/software/ncclient What works: - ncclient can now interact with netopeer over TLS 6513. - ncclient can listen on TCP XXXX (IANA TLS port). A call-home from = netopeer reverses the roles, and a NETCONF client-server session is = established. Here are some implementation notes: - tested interaction over TLS v1.0 [python 2.x does not support TLS = v1.1/v1.2, TODO: need to port ncclient to python v3.4] - used stunnel v5.0 as a proxy to handle TLS interaction on the = server-side stunnel was patched to provide information for mapping cert to = username. - strict mutual authentication using stunnel [validate peer certificate against a trusted CA chain and check if cert is locally installed] - interaction works over both v4 and v6. Here is a list of issues that popped up while implementing [draft-ietf-netconf-rfc5539bis-05]. Issue #1 -------- - How to handle ssh host key verification when multiple hosts are behind = a NAT? - This is probably implementation specific. It depends how an SSH client stores hosts keys. We thought to share this issue along anyway. Issue #2 -------- - How to handle TLS certificate hostname verification when multiple = hosts are behind a NAT? - Similar to #1. The NMS should have some kind of = pre-defined knowledge, that the hostname is correct (expected for the certificate). = Maybe this can be mentioned more explicitely in the NETCONF over TLS text. Issue #3 -------- - What shall be the strictness of the TLS certificate mutual = verification? a) validate the peer certificate against a trusted CA chain. b) validate using a) and check if peer certificate is locally = installed. - We think it should be configurable, but it is _not_ covered by [ietf-netconf-server] data model. Should it be there? Issue #4 -------- - Do we need to document NETCONF client-side configuration for NETCONF = call home? - This is connected with #3 - do we need to configure how the = client should verify the server certificates? Or is validation of the = certificates completely out of scope (for both, server and client)? Issue #5 -------- - [Section 2.6]: "Implementations of the protocol specified in this = document MAY implement any TLS cipher suite that provides mutual authentication [RFC5246]. However, implementations MUST support TLS 1.2 [RFC5246] = and are REQUIRED to support the mandatory-to-implement cipher suite, which is TLS_RSA_WITH_AES_128_CBC_SHA. This document is assumed to apply to = future versions of TLS; in which case, the mandatory-to- implement cipher = suite for the implemented version MUST be supported." - The CIPHER suites for TLS v1.2 are mandated by [RFC 5246: Section = 9]. Do we need to mention them in this document? We think we don't. = Mandatory ciphers are specified by TLS specification and will probably change = in future versions of TLS. Issue #6 -------- - [Section 2.4]: "Implementations MAY optionally support TLS = certificate-based authentication [RFC5246]." a) Does the MAY hint towards allowing PSK-based TLS support? b) We searched a bit on PSK-based TLS support in open-source projects: - openssl supports PSK, also available in s_server - stunnel does not support PSK, likely patchable. - python does not support PSK (neither Python 2 nor Python 3) Issue #7 -------- - [Section 2.4.1]: "the NETCONF client MUST check its understanding of = the NETCONF server hostname against the server's identity" [...] "If the = NETCONF client has external information as to the expected identity of the = NETCONF server, the hostname check MAY be omitted." a) MAY vs MUST Issue #8 -------- - [Section 2.3]: "The NETCONF server MUST NOT process any NETCONF = messages received after the operation." This is mandated by NETCONF protocol specification. Would it be better = to just refer to RFC 6241? Issue #9 -------- - [Section 2.1.1]: Client to Server - [Section 2.1.2]: Server to Client The client and server reverse roles during a NETCONF CALL HOME. Would = it be better to explicitly prefix "NETCONF" in the section titles? Best Regards, Radek and Vaibhav --Apple-Mail=_8AB63C2A-6370-46E8-876C-B100D441D86A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="signature.asc" Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQEcBAEBCgAGBQJTNZhnAAoJEHR3XKwTWKOZeyYIAJc/fGnZbBzhKOo4rlgEwCOE Wzd7PyZ2ay7caESJryyCud6vDkW/tecOaoO0xl4Z7jGLHQfxq63o8jwljmiROGvN gPL6YcKLUIWd1CwyHAkC/4I5BukFZDTFDIHRQ16DlWEB2bDVZ3T6uexXeVRKS5rT s4VgKv3W1k6GTeGTeXMKSwBAk5UugdcgbeJ8oNwyj6dxxCzZ2Q1/xh/4h9nXx4DL qP/Qf/AlRc8Alg9gIz2ijxcKDEYzCtvKJYmw8NuP1cgGGVU9mKa9he5VTl/BgWKv 4xGxGUu0Tf++D2O90FP4QXtgXDfoxheqdpf3GJHgPSuPpQZt9uEFmucwuQNmVu0= =tMbM -----END PGP SIGNATURE----- --Apple-Mail=_8AB63C2A-6370-46E8-876C-B100D441D86A-- From nobody Mon Mar 31 08:37:34 2014 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D201A0A70 for ; Mon, 31 Mar 2014 08:37:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.013 X-Spam-Level: X-Spam-Status: No, score=-0.013 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I7zySuytkqLs for ; Mon, 31 Mar 2014 08:37:28 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 488011A0862 for ; Mon, 31 Mar 2014 08:37:28 -0700 (PDT) Received: from adminfs.snmp.com (adminfs.snmp.com [192.147.142.39]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id LAA13151; Mon, 31 Mar 2014 11:37:23 -0400 (EDT) Received: (from luchuk@localhost) by adminfs.snmp.com (8.9.3p2-20030922/snmpclient.mc-990525) id LAA20926; Mon, 31 Mar 2014 11:37:22 -0400 (EDT) Date: Mon, 31 Mar 2014 11:37:22 -0400 (EDT) From: Alan Luchuk Message-Id: <201403311537.LAA20926@adminfs.snmp.com> To: kwatsen@juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/UTMunK5Y6fT1B5sqYkTGRZoqnQg Cc: netconf@ietf.org Subject: Re: [Netconf] Comments on draft-ietf-netconf-reverse-ssh-03.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 15:37:31 -0000 Hi Kent, >Awesome comments - thanks! You're welcome! >>Section 2.1, Page 3, Second Paragraph: (wording) >>------------------------------------------------- >> >>The second paragraph seems vague. Would something along the lines of >>the following text be clearer and/or more specific? > >I forwarded this comment to Steve Hanna, who wrote the Applicability >Statement. At first I was just going to ask if he was OK with the >proposed text, but then I started thinking that I didn't agree with it. >That is, I think that the SSH protocol does require mutual authentication >and that NETCONF's requirement that it be possible to derive a "username" >from the transport doesn't change that. I'm still OK limiting Reverse SSH >to just NETCONF, but I want the reason to be accurate. I'm now waiting >for a response from Steve on this. The actual specification for Reverse SSH is not affected by the explanation, so I'm fine with however this is stated, including the original text. That said, a little more specific explanation might be more technically satisfying. > > >>Section 4, Page 4: (wording) >>----------------------------- >> >>The current text reads: >> >> o The NETCONF server initiates a TCP connection to the NETCONF >> client on the IANA-assigned Reverse SSH port YYYY. >> >> o The TCP connection is accepted and a TCP session is established. > > >I'm not sure about this change since these bullet-points are preceded by >the line "From the NETCONF server's perspective:". The intent is to only >explain the NETCONF-server's perspective, and to let the next section >provide the client's perspective. Currently, neither section references >the remote peer, so that its text remains squarely focused on its side of >the connection. What do you think? Good point. Keep the text you propose above. > >>Section 5, Page 5, First Paragraph: (wording) >>---------------------------------------------- >> >>The current text reads: >> >> "When the management system accepts a new incoming connection, it >> needs to authenticate the remote peer. Ultimately, this entails >> identifying the peer and verifying its SSH host key. >> >> Due to Reverse SSH having the network element initiate the TCP >> connection," > > >I changed the wording to be more clear, but did it another way, please let >me know if you think it's OK! Will do. >>Section 5, Page 6, First Paragraph: (clarification) >>---------------------------------------------------- >> >>The current text reads: >> >> "However, configuring distinct host keys on the management system >> doesn't scale well, which is an important consideration to a network >> management system. A more scalable strategy is to have the network >> element's host key signed by a common trusted key, such as a >> certificate authority. Thus, the mangement system only needs to >> trust a single public key, which vouches for the authenticity of the >> various network element public keys." >> >>Please help me understand this. The way this paragraph is written, it >>is not clear to me why "signing each network element's host key with a >>common trusted key" scales better than "configuring distinct host keys >>on the management system". >> >>In either of these two situations, it seems like an administrator must >>do work for each network element. In one case, it is configuring host >>keys, in another, it is signing each network element's host key. If >>anything, it seems like signing a host key for each network element >>requires _more_ work for each network element, so it seems like this >>would scale less well. >> >>What am I missing here? > > >Very good question. Of course it comes down to how the device's "entity >certificates", as they are called, is distributed. In the best case, as >described in the zero-touch draft, the device would ship from factory with >a built-in entity-certificate, signed by a trust-chain to its vendor's >well-known trust anchor. In this case, there is no additional effort >needed, the management system only needs to trust the vendor's certificate >for its well-known trust anchor. For cases where the device doesn't ship >from factory with an entity-certificate, introducing PKI is still >advantageous as it decouples the management-system from direct >involvement, such that it could be outsourced to some 3rd-party. Makes >sense? What update would you like to see in the draft? Thanks! That does clear it up, and it makes sense. Basically, the device manufacturer does more work so the management system adminstrator has less work. That's what I missed from the original text. How about something like: "However, configuring distinct host keys on the management system doesn't scale well, which is an important consideration to a network management system. A more scalable strategy for the management system is to have the network element's manufacturer sign the network element's host key with a common trusted key, such as a certificate authority. Then, when the network element is deployed, the management system only needs to trust a single public key, which vouches for the authenticity of the various network element host keys." This text tries to preserve as much of the original text as possible, although I'm not sure it is as clear as it could be. Regards, --Alan ------------------------------------------------------------------------------ Alan Luchuk SNMP Research, Inc. Voice: +1 865 573 1434 Senior Software Engineer 3001 Kimberlin Heights Road FAX: +1 865 573 9197 luchuk at snmp.com Knoxville, TN 37920-9716 http://www.snmp.com/ ------------------------------------------------------------------------------