From mehmet.ersue@nsn.com Sat Feb 1 03:28: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 264DB1A058E for ; Sat, 1 Feb 2014 03:28:01 -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 ALS-pqWhQ4KJ for ; Sat, 1 Feb 2014 03:27:59 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id EBEC61A058C for ; Sat, 1 Feb 2014 03:27:57 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s11BRqDe016241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Sat, 1 Feb 2014 12:27:53 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s11BRqBx024900 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 1 Feb 2014 12:27:52 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 1 Feb 2014 12:27:52 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Sat, 1 Feb 2014 12:27:52 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: NETCONF Session at IETF #89 Thread-Index: Ac8fQKPtTf0vy98MSLez3nmUOP1HJA== Date: Sat, 1 Feb 2014 11:27:51 +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.103] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F8273363DEMUMBX005nsnintr_" 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: 2563 X-purgate-ID: 151667::1391254073-00001A6F-CFF37738/0-0/0-0 Subject: [Netconf] 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: Sat, 01 Feb 2014 11:28:01 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F8273363DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The NETCONF session at IETF #89 will be on WEDNESDAY, March 5, 2014 at 1300-1500 Afternoon Session I Palace C OPS netconf Network Configuration WG and the NETMOD session is on MONDAY, March 3, 2014 at 1300-1500 Afternoon Session I Richmond/Chelsea/Tower OPS netmod NETCONF Data Modeli= ng Language WG Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F8273363DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The NETCONF session at IETF #89 will be
on WEDNESDAY, March 5, 2014
at 1300-1500  Afternoon Session I
Palace C         = OPS      netconf     &nbs= p;    Network Configuration WG
 
= and the NETMOD session is
on MONDAY, March 3, 2014
at 1300-1500  Afternoon Session I
Richmond/Chelsea/Tower   OPS = ;     netmod       &= nbsp;   NETCONF Data Modeling Language WG
 
Mehmet
 
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F8273363DEMUMBX005nsnintr_-- From ambika.tripathy@gmail.com Wed Feb 5 05:12: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 5760F1A011B for ; Wed, 5 Feb 2014 05:12:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 jZ-4AsD5JUEX for ; Wed, 5 Feb 2014 05:12:35 -0800 (PST) Received: from mail-pb0-x229.google.com (mail-pb0-x229.google.com [IPv6:2607:f8b0:400e:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id 463BF1A0112 for ; Wed, 5 Feb 2014 05:12:35 -0800 (PST) Received: by mail-pb0-f41.google.com with SMTP id up15so350299pbc.14 for ; Wed, 05 Feb 2014 05:12:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=ZY5b1F13UoHyzW1Ri4+elX7scNX0WzRznj6y8PDmykc=; b=enKycpnXMIOmNGiIN3V3Plr6SqyWxgfOE0dJ/cR2O0j9wexPLJW3jat1q9F6+ih00E mOkTLzZ/ptSSxSG0nKCUDW6EUjgtDVlWnX5/C+wTnNl84PVwrwzRHdjqPhGfZgQAQf8P SxLZw9v29NaxXN50c3RudoV6oCbjEkEWyLyPga1tjlThnkAwpPSDG9dSxQSskHlof/ja ksjzHVNSRVNBwqFAFVrVlzlVoet5tvAzbdC1ckyoPXW3BDHzAXB6BoGAanuV79VM3CCg e3youokciNlFUYtE9CKc+DQj/Sagn3XAbMickvK+qhUmfsGFhfLQ1VWjJl504wZ933TR eocw== MIME-Version: 1.0 X-Received: by 10.69.30.44 with SMTP id kb12mr1585824pbd.87.1391605953689; Wed, 05 Feb 2014 05:12:33 -0800 (PST) Received: by 10.68.131.197 with HTTP; Wed, 5 Feb 2014 05:12:33 -0800 (PST) Date: Wed, 5 Feb 2014 18:42:33 +0530 Message-ID: From: Ambika Tripathy To: ambtripa@cisco.com, Netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11367b4e897e2804f1a8823d Subject: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 13:12:36 -0000 --001a11367b4e897e2804f1a8823d Content-Type: text/plain; charset=ISO-8859-1 Hi, I am new to netconf. I have one fundamental question related to operation attribute update using netconf. (as i know will only update config data defied in a yang model.) Lets Say my model is: rw location-mgmt +-- rw locations [location-id] +-- rw location-id string +-- rw location-name string +-- rw state string +-- rw postal-code uint32 +-- ro temperature uint16 +-- ro humidity uint16 How can I update temperature and humidity attribute for the above model using a netconf client message? -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com --001a11367b4e897e2804f1a8823d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I am new to netconf. I have one=A0fundamental=A0question = related to operation attribute=A0update using netconf. (as i know <edit-= config> will only update config data defied in a yang model.)

Lets Say my model is:

rw location-mgmt
+-- rw locations [location-id]
=A0 =A0 +-- rw locati= on-id string
=A0 =A0= +-- rw location-name string
=A0 =A0 +-- rw state string
=A0 =A0 +-- rw postal-co= de uint32
=A0 =A0 +-= - ro=A0temperature uint16
=A0 =A0 +-- ro humidity uint16

=A0
How can I update temperature and humidity attribute = for the above model using a netconf client <RPC> message?=A0



= --
Ambika P= rasad Tripathy
Cell @+91 9437547730/8553070866<= /font>

--001a11367b4e897e2804f1a8823d-- From j.schoenwaelder@jacobs-university.de Wed Feb 5 05:27: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 DEC951A0112 for ; Wed, 5 Feb 2014 05:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 7r_f6UCsps4D for ; Wed, 5 Feb 2014 05:27:02 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 719301A0105 for ; Wed, 5 Feb 2014 05:27:02 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64B5F200D0; Wed, 5 Feb 2014 14:27:01 +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 5fOxR8v5ocxN; Wed, 5 Feb 2014 14:27:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D553A200C3; Wed, 5 Feb 2014 14:27:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 9CB9B2B1039E; Wed, 5 Feb 2014 14:26:57 +0100 (CET) Date: Wed, 5 Feb 2014 14:26:57 +0100 From: Juergen Schoenwaelder To: Ambika Tripathy Message-ID: <20140205132657.GB46160@elstar.local> Mail-Followup-To: Ambika Tripathy , ambtripa@cisco.com, Netconf@ietf.org 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) Cc: Netconf@ietf.org Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 13:27:05 -0000 On Wed, Feb 05, 2014 at 06:42:33PM +0530, Ambika Tripathy wrote: > Hi, > > I am new to netconf. I have one fundamental question related to operation > attribute update using netconf. (as i know will only update > config data defied in a yang model.) > > Lets Say my model is: > > rw location-mgmt > +-- rw locations [location-id] > +-- rw location-id string > +-- rw location-name string > +-- rw state string > +-- rw postal-code uint32 > +-- ro temperature uint16 > +-- ro humidity uint16 > > > How can I update temperature and humidity attribute for the above model > using a netconf client message? There is no standard way of doing this (yet). You have to roll your own RPC, which YANG luckily enables you to define. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ambika.tripathy@gmail.com Wed Feb 5 05:51: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 B90F91A0151 for ; Wed, 5 Feb 2014 05:51:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 PfSPyxOORd1S for ; Wed, 5 Feb 2014 05:51:14 -0800 (PST) Received: from mail-pd0-x22f.google.com (mail-pd0-x22f.google.com [IPv6:2607:f8b0:400e:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0F3131A0134 for ; Wed, 5 Feb 2014 05:51:14 -0800 (PST) Received: by mail-pd0-f175.google.com with SMTP id w10so377029pde.34 for ; Wed, 05 Feb 2014 05:51:13 -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 :content-type; bh=KU/TvHhgbAHqX9vNeKiDzZGmNuXfC6WX9P8xa6TEfyw=; b=MNtu04n0q8KbfuHJuEWwipzg8h3aeu6YjFbnEjV590HuLVli4jaf1MOR56/gc9TsDw 5VI54l3UCl52PISZJ1/Y4JjvaKVSj//Y/5tlC4/aIYXMQmonIdmyUiGW51X9CREpd2aV 1TAEAy6Md8w6f+xXlcyEg03S5TcvUMkgd/ng16uDt0SGSR9yxsugDazLH9l68N+ZJjxQ iTMhE8WNpmf5xzRNhdSbrooAh/lZJyo3yCRnFDMpccMVfzEE1fQ+OGkyML1uZxos4NrC ZJnffk02gz7bm84gQOGS5veFKw+TjUbTe0CT2uJdHtENjiKYiAeqvkHZ6fl1zblx3Kr0 Ku3A== MIME-Version: 1.0 X-Received: by 10.68.197.40 with SMTP id ir8mr1910942pbc.138.1391608273365; Wed, 05 Feb 2014 05:51:13 -0800 (PST) Received: by 10.68.131.197 with HTTP; Wed, 5 Feb 2014 05:51:13 -0800 (PST) In-Reply-To: <20140205132657.GB46160@elstar.local> References: <20140205132657.GB46160@elstar.local> Date: Wed, 5 Feb 2014 19:21:13 +0530 Message-ID: From: Ambika Tripathy To: Juergen Schoenwaelder , Ambika Tripathy , ambtripa@cisco.com, Netconf@ietf.org Content-Type: multipart/alternative; boundary=e89a8ff1c3e0ccf20504f1a90ca8 Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 13:51:15 -0000 --e89a8ff1c3e0ccf20504f1a90ca8 Content-Type: text/plain; charset=ISO-8859-1 Thanks Juergen, So, that mean i have to define one RPC in my yang model and implement that by my application. And pass temperature and humidity as two input parameter in that RPC to update it in YANG data store? Please conform. br, Ambika On Wed, Feb 5, 2014 at 6:56 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Feb 05, 2014 at 06:42:33PM +0530, Ambika Tripathy wrote: > > Hi, > > > > I am new to netconf. I have one fundamental question related to operation > > attribute update using netconf. (as i know will only update > > config data defied in a yang model.) > > > > Lets Say my model is: > > > > rw location-mgmt > > +-- rw locations [location-id] > > +-- rw location-id string > > +-- rw location-name string > > +-- rw state string > > +-- rw postal-code uint32 > > +-- ro temperature uint16 > > +-- ro humidity uint16 > > > > > > How can I update temperature and humidity attribute for the above model > > using a netconf client message? > > There is no standard way of doing this (yet). You have to roll your > own RPC, which YANG luckily enables you to define. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk --e89a8ff1c3e0ccf20504f1a90ca8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks Juergen,

So, that mean i have to= define one RPC in my yang model and implement that by my application. And = pass temperature and humidity as two input parameter in that RPC to update = it in YANG data store? Please conform.

br,
Ambika


On Wed, Feb 5, 2014 at 6:56 PM, Juer= gen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Wed, Feb 05, 2014 at 06= :42:33PM +0530, Ambika Tripathy wrote:
> Hi,
>
> I am new to netconf. I have one fundamental question related to operat= ion
> attribute update using netconf. (as i know <edit-config> will on= ly update
> config data defied in a yang model.)
>
> Lets Say my model is:
>
> rw location-mgmt
> +-- rw locations [location-id]
> =A0 =A0 +-- rw location-id string
> =A0 =A0 +-- rw location-name string
> =A0 =A0 +-- rw state string
> =A0 =A0 +-- rw postal-code uint32
> =A0 =A0 +-- ro temperature uint16
> =A0 =A0 +-- ro humidity uint16
>
>
> How can I update temperature and humidity attribute for the above mode= l
> using a netconf client <RPC> message?

There is no standard way of doing this (yet). You have to roll your own RPC, which YANG luckily enables you to define.

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



--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk
--e89a8ff1c3e0ccf20504f1a90ca8-- From lhotka@nic.cz Wed Feb 5 06:03: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 1E4561A0154 for ; Wed, 5 Feb 2014 06:03:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 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.535] 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 aqViisHz-GJX for ; Wed, 5 Feb 2014 06:03: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 0D2441A015B for ; Wed, 5 Feb 2014 06:03:45 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id AC89613F721; Wed, 5 Feb 2014 15:03:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391609024; bh=WwGszerLDciU0e9uUOIjUmoURnDNw0YuiKUJmUEYbuA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ouU3DhxdTopCAE/+kv+Suo1KEc9lW7NA4uW0ehQv4IHUjHt5+KTPhvfK91iihZKyp NQcv0tOau/OZpXt7bdBk42hSp8MlJHOZTfYF/Vg1cY5tYNCw0iXSxuxOv1Pwzwxiot voTrvFx1ovdhKR7w2kHToI/LyHD8tEZPEaSZgmn8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 5 Feb 2014 15:03:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <88FC320A-9C16-440D-B086-6AA705726741@nic.cz> References: <20140205132657.GB46160@elstar.local> To: Ambika Tripathy X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Cc: Netconf Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 14:03:50 -0000 On 05 Feb 2014, at 14:51, Ambika Tripathy = wrote: > Thanks Juergen, >=20 > So, that mean i have to define one RPC in my yang model and implement = that by my application. And pass temperature and humidity as two input = parameter in that RPC to update it in YANG data store? Please conform. Note that the =93ro=94 parameters are operational state, so generally = they are supposed to be updated by the device. In your case, the device = may have temperature and humidity sensors, so there is no reason for the = client to tinker with these values. Lada=20 >=20 > br, > Ambika >=20 >=20 > On Wed, Feb 5, 2014 at 6:56 PM, Juergen Schoenwaelder = wrote: > On Wed, Feb 05, 2014 at 06:42:33PM +0530, Ambika Tripathy wrote: > > Hi, > > > > I am new to netconf. I have one fundamental question related to = operation > > attribute update using netconf. (as i know will only = update > > config data defied in a yang model.) > > > > Lets Say my model is: > > > > rw location-mgmt > > +-- rw locations [location-id] > > +-- rw location-id string > > +-- rw location-name string > > +-- rw state string > > +-- rw postal-code uint32 > > +-- ro temperature uint16 > > +-- ro humidity uint16 > > > > > > How can I update temperature and humidity attribute for the above = model > > using a netconf client message? >=20 > There is no standard way of doing this (yet). You have to roll your > own RPC, which YANG luckily enables you to define. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 >=20 >=20 > --=20 > Ambika Prasad Tripathy > Cell @+91 9437547730/8553070866 > Alt email: ambika_tripathy@yahoo.com > ambika.tripathy@gmail.com > skype:ambika_nethawk > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From j.schoenwaelder@jacobs-university.de Wed Feb 5 06:05:26 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 1E58A1A014D for ; Wed, 5 Feb 2014 06:05:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.785 X-Spam-Level: X-Spam-Status: No, score=-2.785 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.535] 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 AONBtt4pDilD for ; Wed, 5 Feb 2014 06:05:25 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id C6EC51A0147 for ; Wed, 5 Feb 2014 06:05:24 -0800 (PST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C0B32013C; Wed, 5 Feb 2014 15:05:23 +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 mMpXv5lZuGfh; Wed, 5 Feb 2014 15:05: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 CCC0B2013B; Wed, 5 Feb 2014 15:05:21 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DBF332B105B0; Wed, 5 Feb 2014 15:05:19 +0100 (CET) Date: Wed, 5 Feb 2014 15:05:19 +0100 From: Juergen Schoenwaelder To: Ambika Tripathy Message-ID: <20140205140517.GB46555@elstar.local> Mail-Followup-To: Ambika Tripathy , ambtripa@cisco.com, Netconf@ietf.org References: <20140205132657.GB46160@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) Cc: Netconf@ietf.org Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 14:05:26 -0000 On Wed, Feb 05, 2014 at 07:21:13PM +0530, Ambika Tripathy wrote: > Thanks Juergen, > > So, that mean i have to define one RPC in my yang model and implement that > by my application. And pass temperature and humidity as two input parameter > in that RPC to update it in YANG data store? Please conform. > That is one way of doing this. You can also create something more generic but it is all up to you. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From lhotka@nic.cz Wed Feb 5 06:19: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 3DC951A017C for ; Wed, 5 Feb 2014 06:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.186 X-Spam-Level: X-Spam-Status: No, score=-1.186 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.535] 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 pZj8xNEtHkbc for ; Wed, 5 Feb 2014 06:19:21 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) by ietfa.amsl.com (Postfix) with ESMTP id 8520B1A015D for ; Wed, 5 Feb 2014 06:19:21 -0800 (PST) Received: from [172.29.2.202] (nat-5.bravonet.cz [77.48.224.5]) by mail.nic.cz (Postfix) with ESMTPSA id 744AE13F721 for ; Wed, 5 Feb 2014 15:19:20 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1391609960; bh=yD1W6uTKNhWms2/ShNfNMiWEtXXUdp9lEbeLeKul5B0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date: Content-Transfer-Encoding:Message-Id:References:To; b=e9Z2K5TjlxK4klUvYrAmFKebH4xSQ5G/nwTTjPjKH+zPf5QskwAlyhYxi+jKFdKg/ Bm+or271KdKu08mgHsM/RGkplvy+w5qeMCApcHPkY1ty8guqkX0iIFMRlXbwoWKrGk llC0Qx8jdIzFbquzaH148GhsmfQeJqAy89VEAoRc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 5 Feb 2014 15:19:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140205132657.GB46160@elstar.local> <88FC320A-9C16-440D-B086-6AA705726741@nic.cz> To: Netconf X-Mailer: Apple Mail (2.1827) X-Virus-Scanned: clamav-milter 0.97.8 at mail X-Virus-Status: Clean Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 14:19:23 -0000 On 05 Feb 2014, at 15:05, Ambika Tripathy = wrote: > Hi Lada, >=20 > That's true.. But i want to over-write the values of those variable by = outside box using netconf client. OK, then probably the best option is an RPC, as J=FCrgen suggested. = Alternatively, it=92s also sometimes possible to define a configuration = parameter that is coupled with the operational value somehow - it would = be up to the data model designer to specify the semantics. Lada >=20 > br, > Ambika >=20 >=20 > On Wed, Feb 5, 2014 at 7:33 PM, Ladislav Lhotka wrote: >=20 > On 05 Feb 2014, at 14:51, Ambika Tripathy = wrote: >=20 >> Thanks Juergen, >>=20 >> So, that mean i have to define one RPC in my yang model and implement = that by my application. And pass temperature and humidity as two input = parameter in that RPC to update it in YANG data store? Please conform. >=20 > Note that the =93ro=94 parameters are operational state, so generally = they are supposed to be updated by the device. In your case, the device = may have temperature and humidity sensors, so there is no reason for the = client to tinker with these values. >=20 > Lada >=20 >>=20 >> br, >> Ambika >>=20 >>=20 >> On Wed, Feb 5, 2014 at 6:56 PM, Juergen Schoenwaelder = wrote: >> On Wed, Feb 05, 2014 at 06:42:33PM +0530, Ambika Tripathy wrote: >>> Hi, >>>=20 >>> I am new to netconf. I have one fundamental question related to = operation >>> attribute update using netconf. (as i know will only = update >>> config data defied in a yang model.) >>>=20 >>> Lets Say my model is: >>>=20 >>> rw location-mgmt >>> +-- rw locations [location-id] >>> +-- rw location-id string >>> +-- rw location-name string >>> +-- rw state string >>> +-- rw postal-code uint32 >>> +-- ro temperature uint16 >>> +-- ro humidity uint16 >>>=20 >>>=20 >>> How can I update temperature and humidity attribute for the above = model >>> using a netconf client message? >>=20 >> There is no standard way of doing this (yet). You have to roll your >> own RPC, which YANG luckily enables you to define. >>=20 >> /js >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >>=20 >>=20 >>=20 >> -- >> Ambika Prasad Tripathy >> Cell @+91 9437547730/8553070866 >> Alt email: ambika_tripathy@yahoo.com >> ambika.tripathy@gmail.com >> skype:ambika_nethawk >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 >=20 >=20 >=20 > --=20 > Ambika Prasad Tripathy > Cell @+91 9437547730/8553070866 > Alt email: ambika_tripathy@yahoo.com > ambika.tripathy@gmail.com > skype:ambika_nethawk -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From andy@yumaworks.com Wed Feb 5 08:59: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 E7C9F1A019E for ; Wed, 5 Feb 2014 08: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 5XTGsTzskl-5 for ; Wed, 5 Feb 2014 08:59:54 -0800 (PST) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id EFCFF1A01CE for ; Wed, 5 Feb 2014 08:59:53 -0800 (PST) Received: by mail-qc0-f172.google.com with SMTP id c9so1083855qcz.31 for ; Wed, 05 Feb 2014 08:59:53 -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=Mrb6wdanDXMs/HY+PMm1ORBHEnzwELJen4YbRHzlJDY=; b=O5q8yIryvH8dnUY8LvNn/FUgl58pgBudfoiXbsfpr9WtB9aEz7qEArFeBl2geTjp3K DmvCsEzhRDEnhmJHrjazYf1MsT7UywH+liGDdFk1ETFYC0PONOayVHSPg5PsMh+tMK3n 1kiPvaxt8NEmu2SigYf/UdPiDtHaobaqcQmvg8mtAKtmh52KY+AVhRw1nSlrzT/XYwzA UQYwCarkYkbmNfZwDlc8K5fPEGf7OvtskM+oZ1UMSTxXYdCw5WAGrVz7yBC7KWQndDfm rlHiNn029P6en6Md3aLU4VH72RpLAfsoO7pjvt0BE4GlrKjcr2+sf6Ecp2WDvbqsViop 1YMA== X-Gm-Message-State: ALoCoQlzMaTPVFH+UdSjIQyc19gK1rg79gRnLeblkiPmZ+AHET/mmQvGZApfFgO7t0tpN/zCWkIj MIME-Version: 1.0 X-Received: by 10.224.46.130 with SMTP id j2mr4354887qaf.7.1391619592983; Wed, 05 Feb 2014 08:59:52 -0800 (PST) Received: by 10.140.48.75 with HTTP; Wed, 5 Feb 2014 08:59:52 -0800 (PST) In-Reply-To: References: <20140205132657.GB46160@elstar.local> Date: Wed, 5 Feb 2014 08:59:52 -0800 Message-ID: From: Andy Bierman To: Ambika Tripathy Content-Type: multipart/alternative; boundary=001a11c2a9ca80a8ae04f1abaf7e Cc: Netconf Subject: Re: [Netconf] Updating Operational data nodes using netconf 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 Feb 2014 16:59:56 -0000 --001a11c2a9ca80a8ae04f1abaf7e Content-Type: text/plain; charset=ISO-8859-1 Hi, Beyond the protocol mechanics of editing operational state, one has to wonder about the high-level network management model here. What does it actually mean for the client to tell the server to change the reading on its temperature gauge? It doesn't mean change the temperature of the device so the gauge accurately reflects the new desired value.\ That would be configuration. It doesn't mean just report this value and behave as if the temperature is the correct value. It seems to just mean "behave as if the temperature is the provided value", which seems like configuration to me. I think there is more to configuration than persistence. Editing operational state seems to just be configuration with a limited lifetime. Andy On Wed, Feb 5, 2014 at 5:51 AM, Ambika Tripathy wrote: > Thanks Juergen, > > So, that mean i have to define one RPC in my yang model and implement that > by my application. And pass temperature and humidity as two input parameter > in that RPC to update it in YANG data store? Please conform. > > br, > Ambika > > > On Wed, Feb 5, 2014 at 6:56 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Wed, Feb 05, 2014 at 06:42:33PM +0530, Ambika Tripathy wrote: >> > Hi, >> > >> > I am new to netconf. I have one fundamental question related to >> operation >> > attribute update using netconf. (as i know will only >> update >> > config data defied in a yang model.) >> > >> > Lets Say my model is: >> > >> > rw location-mgmt >> > +-- rw locations [location-id] >> > +-- rw location-id string >> > +-- rw location-name string >> > +-- rw state string >> > +-- rw postal-code uint32 >> > +-- ro temperature uint16 >> > +-- ro humidity uint16 >> > >> > >> > How can I update temperature and humidity attribute for the above model >> > using a netconf client message? >> >> There is no standard way of doing this (yet). You have to roll your >> own RPC, which YANG luckily enables you to define. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > > > -- > Ambika Prasad Tripathy > Cell @+91 9437547730/8553070866 > Alt email: ambika_tripathy@yahoo.com > ambika.tripathy@gmail.com > skype:ambika_nethawk > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c2a9ca80a8ae04f1abaf7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Beyond the protocol mechanics of ed= iting operational state,
one has to wonder about the high-level n= etwork management
model here.

What does = it actually mean for the client to tell the
server to change the reading on its temperature gauge?

<= /div>
It doesn't mean change the temperature of the device
so the gauge accurately reflects the new desired value.\
That w= ould be configuration.

It doesn't mean just report this value and behave a= s if the
temperature is the correct value.

It seems to just mean "behave as if the temperature is
the provided value", which seems like configuration to me.

I think there is = more to configuration than persistence.
Edi= ting operational state seems to just be configuration with
a limited lifetime.


Andy


= On Wed, Feb 5, 2014 at 5:51 AM, Ambika Tripathy <ambika.tripathy@g= mail.com> wrote:
Thanks Juergen,

So, that mean i have to define one RPC in my yang model and impleme= nt that by my application. And pass temperature and humidity as two input p= arameter in that RPC to update it in YANG data store? Please conform.

br,
Ambika


On Wed, Feb 5, 2014 at 6:56 PM, Juer= gen Schoenwaelder <j.schoenwaelder@jacobs-university.de= > wrote:
On Wed, Feb 05, 2014 at 06:42:33PM +053= 0, Ambika Tripathy wrote:
> Hi,
>
> I am new to netconf. I have one fundamental question related to operat= ion
> attribute update using netconf. (as i know <edit-config> will on= ly update
> config data defied in a yang model.)
>
> Lets Say my model is:
>
> rw location-mgmt
> +-- rw locations [location-id]
> =A0 =A0 +-- rw location-id string
> =A0 =A0 +-- rw location-name string
> =A0 =A0 +-- rw state string
> =A0 =A0 +-- rw postal-code uint32
> =A0 =A0 +-- ro temperature uint16
> =A0 =A0 +-- ro humidity uint16
>
>
> How can I update temperature and humidity attribute for the above mode= l
> using a netconf client <RPC> message?

There is no standard way of doing this (yet). You have to roll your own RPC, which YANG luckily enables you to define.

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



--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk

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


--001a11c2a9ca80a8ae04f1abaf7e-- From jclarke@cisco.com Wed Feb 5 09:19: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 7631A1A0152 for ; Wed, 5 Feb 2014 09:19:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.326 X-Spam-Level: X-Spam-Status: No, score=-7.326 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, T_DKIM_INVALID=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 YaS7V9uNL-P3 for ; Wed, 5 Feb 2014 09:19:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 6E7A81A015D for ; Wed, 5 Feb 2014 09:19:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9064; q=dns/txt; s=iport; t=1391620793; x=1392830393; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=MsKZt7Tyq4gtP1yGMO1FWn4imtQrdQMGhOC4j4BlhCA=; b=M7+E+Mjksg6SOwLfucBwcZQhbKYTr7/a3sbI5I7Hp3Qty6Gz9njjy9rD a4Ah7u/7Z2LOixV0vH16fIkFQt5RPsHUFOk9jVybX/qsieOLkEK7vFbrE t44RbIRG7NPHSwqYu0wHqTNW6zZQvEG/s9zb9eG1zlpWzjDKPuSnnoGhW k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFABpy8lKtJV2b/2dsb2JhbABZDoJ+OL5UT4EQFnSCJQEBAQMBAQEBNTYKDQQLEQQBAQEJFggHCQMCAQIBFRYJCQgGAQwGAgEBBRCHZAgNzy4XjiQBAVYGhDIBA4lJinmDaYEykG+Cbl0egSwEBRc X-IronPort-AV: E=Sophos;i="4.95,787,1384300800"; d="scan'208";a="302055911" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-7.cisco.com with ESMTP; 05 Feb 2014 17:19:52 +0000 Received: from prosciutto.local ([10.154.66.22]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s15HJpVE028487; Wed, 5 Feb 2014 17:19:52 GMT Message-ID: <52F272B7.6070706@cisco.com> Date: Wed, 05 Feb 2014 12:19:51 -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.2.0 MIME-Version: 1.0 To: Tal Mizrahi , Tal Mizrahi , "netconf@ietf.org" References: <20140102175630.Horde.7dNbR0WQjedx_Klc7ZQZng1@webmail.technion.ac.il> <52D57BD7.7060006@cisco.com> <74470498B659FA4687F0B0018C19A89C01D4390857BE@IL-MB01.marvell.com> <52DC6362.6060509@cisco.com> <74470498B659FA4687F0B0018C19A89C01D4391106DF@IL-MB01.marvell.com> In-Reply-To: <74470498B659FA4687F0B0018C19A89C01D4391106DF@IL-MB01.marvell.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-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 Feb 2014 17:19:57 -0000 On 1/23/14, 1:56 AM, Tal Mizrahi wrote: > Hi Joe, > > Thanks again for the comments. > >> I don't get this. If I schedule something to run in one hour, I have to wait an hour for the rpc-reply? That doesn't seem right. > > Okay, so this goes back to our comment that the current draft focuses on soft-real time scheduling (http://www.ietf.org/mail-archive/web/netconf/current/msg08549.html), but I should probably explain it a bit further. In this context there is an implicit assumption that RPCs are scheduled to a *near future* time. Here is an example (the numbers are just an example, so they do not necessarily represent a real-life scenario). Let's say we have a client and two servers, and let's say that every RPC the client sends (a normal RPC, not a scheduled one) is executed within 3 seconds with a probability .999, i.e., the client receives an rpc-reply within 3 seconds. The client can send a *scheduled* RPC to the two servers, with a that is 3 seconds into the future; consequently, each of the two servers performs the RPC exactly 3 seconds afterwards with a probability .999 (each). The client has to wait 3 seconds to get the rpc-reply, but that is not so bad, since in the non-sc h eduled RPC the client may need to wait 3 seconds anyway. And we should note that in this example each of the servers has a probability of .001 not to perform the RPC on time, which is why we are emphasizing that we have focused on addressing soft-real time scheduling. > > Indeed, the rpc-reply is received only after the RPC was scheduled, but we are assuming that the scheduling time is not too far into the future (which is one of the reasons this draft includes the ). > > I think the current draft is less targeted at far-future scheduling (e.g., an hour in your example). Our thoughts were that approaches such as draft-kwatsen-conditional-enablement are a better fit for far-future scheduling. However, if we come to the conclusion that we *do* need to address far-future scheduling, it is possible to add the following functionality (this is a tweak to something Andy suggested a couple of months ago): (i) When a server receives a scheduled RPC, it can send a notification to the client, indicating that the scheduled RPC was received and added to the server's schedule. The rpc-reply itself is sent after the RPC was executed at the scheduled time. (ii) The client can send a cancellation message if it does not receive a notification, or if it receives an rpc-error from one of the servers. > > So an open question here is whether we should add the 2 features above (notification, cancellation) that would enable far-future scheduling as well. Sorry for the delay. I've been traveling. This helps to clarify things for me, but if the draft remains for near-future scheduling, I think it needs some additional clarification within the draft. Plus, since the client can set the time window, should there be some kind of upward bound for that? In terms of far-future scheduling, I see value there, but the more I think on it, this might be better served on the client within some kind of config application. It can then use near-future scheduling to synchronize the actual deployment. Joe > > Regards, > Tal. > > > -----Original Message----- > From: Joe Marcus Clarke [mailto:jclarke@cisco.com] > Sent: Monday, January 20, 2014 1:45 AM > To: Tal Mizrahi; Tal Mizrahi; netconf@ietf.org > Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 > > On 1/19/14, 8:57 AM, Tal Mizrahi wrote: >> Hi Joe, >> >> Thanks for the comments. >> >>> However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC. How would I go about ensuring that an RPC completed (or not) at the scheduled time? >> >> If the client gets an rpc-reply with an element it knows the scheduled operation was performed successfully. >> If the client wants to know whether the RPC was performed *on time* it needs to include the element in the RPC (in addition to including the element), causing the server to include the element in the rpc-reply. This allows the client to receive feedback about the actual execution time of the RPC. This behavior is described in section 3.1 of the draft. > > I don't get this. If I schedule something to run in one hour, I have to wait an hour for the rpc-reply? That doesn't seem right. > > My understanding from the initial read was that I would get an rpc-reply right away to indicate the request was scheduled successfully. > >> >>> I think there should be a way to query the server's current time to make sure the client and server agree. >> >> One way to do this is to use the element; the client can send (any kind of) an RPC to the server which includes the element. Consequently, the server includes the in its rpc-reply. It should be noted that this method allows a *very* rough indication about whether the client and server are synchronized. >> However, I believe the correct way to inquire about whether the server is synchronized or not is at the clock synchronization protocol layer. For example, the NTP MIB (RFC 5907) includes a set of objects that allow you to check the current status of NTP, including the offset to the current reference time source. The PTP MIB (draft-ietf-tictoc-ptp-mib-05) also includes similar objects. >> [One may ask whether NTP and PTP have a YANG module for NETCONF, but >> that is a completely different story...:) ] > > In terms of this draft should there be some text that explain this as a potential concern with suggestions? > > Joe > >> >> Thanks, >> Tal Mizrahi. >> >> >> -----Original Message----- >> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Joe >> Marcus Clarke >> Sent: Tuesday, January 14, 2014 8:03 PM >> To: Tal Mizrahi; netconf@ietf.org >> Subject: Re: [Netconf] Updated draft-mm-netconf-time-capability-01 >> >> On 1/2/14, 10:56 AM, Tal Mizrahi wrote: >>> >>> Hi, >>> >>> We have posted an updated draft: >>> http://tools.ietf.org/html/draft-mm-netconf-time-capability-01 >>> >>> Thanks to all the people who reviewed and sent comments about draft 00. >>> Here is a summary of the changes compared to draft 00: >>> - We have added discussion about the scheduling tolerance: an upper >>> bound on how far into the future/past an RPC can be scheduled. >>> - The scheduled time now refers to the *start* time of the operation, >>> rather than to its completion. >>> - The time format has been changed to date-and-time. >> >> I read through the draft, Tal, and I have a few comments. >> >> Section 3.1: >> >> I think there should be a way to query the server's current time to make sure the client and server agree. This should be part of the overall dialogue between the two when scheduling will be done. Even though the client may be configured to use NTP, the server may not have had a chance to sync to its clock source. You talk about time sync, but I think this extra level of checking will assure that the server doesn't do something the client didn't expect. At the very least, the client may decide to abort the scheduled operation. >> >> This goes outside of the time tolerance you define in Section 3.5. I >> could, for example, say I have a 10 second tolerance in either >> direction of time 2015-10-21T04:29:00.235. The server gets a chance >> to execute at >> 2015-10-21T04:38:00.235 and does, but the actual time on the client is 2015-10-21T05:29:00.235. >> >> Section 3.4: >> >> You introduce time-interval here without really saying how it will be used. You do this later, but it seemed a bit disjointed to me. Maybe swap sections 3.4 and 3.5 and mention time-interval in the new section 3.4. >> >> Section 4.5 >> >> You define the element but you reference it as : >> >> OLD TEXT: >> >> ...operation. Every message MAY include the ... >> >> NEW TEXT: >> >> ...operation. Every message MAY include the ... >> >> NIT: I would swap the order of and as the former references the latter. >> >> Section 4.5.1: >> >> You have two leaf nodes with the name sched-max-past. They have two different descriptions. I think the first should be sched-max-future. >> >>> At this point, draft 01 is soft-real-time-oriented. We are interested >>> to hear feedback about whether there is an interest in the working >>> group to develop the hard real-time functionality as well. >> >> I think soft time is fine. However, the draft doesn't discuss how a client can retrieve the results of a scheduled RPC. How would I go about ensuring that an RPC completed (or not) at the scheduled time? >> >> Joe >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > From allepu.rajkumar@gmail.com Tue Feb 4 23:55: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 E033B1A00A3 for ; Tue, 4 Feb 2014 23:55:35 -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 3kfkjMqTL-5t for ; Tue, 4 Feb 2014 23:55:34 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 5E5641A0063 for ; Tue, 4 Feb 2014 23:55:34 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so43826pdj.3 for ; Tue, 04 Feb 2014 23:55:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:from:content-type:message-id:date:to :content-transfer-encoding:mime-version; bh=F883jKkxx07AEvVIkTb+0ItfLidfR5xliKIJ2JB1FN0=; b=GMGsAW2wPGUFgMzNfULXyMA5DXCtFAD+CsXPnJA8ntyoVbB33PmVIprDTBmKQgSa/2 5j/n90DDseDMdgrnog1/i6iH5IRHLEkzqmpf/ZJ3/Y9NKR/ovjYc3O4uh13W4wCFH/fv b8lM1asJfb5PSbY1AQ03ya+96x5GRvsYTqKCaWGQAhZLhu9Y5/lF4sp/YjKqy+ujFcii n7pR496v0b99t1RRUuWY2T3PengWM5kCV0ba91e4u0cOILDzwwCj+kWNp6+SSmW2eVwv DPgb+Vl1h6qGhn+zPUGNIn0BzTZD/wTvmhin2dWtJKeWDmQGYZy/0ILrFLzBiMg5cdgt O0rQ== X-Received: by 10.66.129.133 with SMTP id nw5mr116263pab.98.1391586933914; Tue, 04 Feb 2014 23:55:33 -0800 (PST) Received: from [100.70.213.29] ([106.220.115.90]) by mx.google.com with ESMTPSA id om6sm73694449pbc.43.2014.02.04.23.55.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 23:55:33 -0800 (PST) From: Allepu Rajkumar Content-Type: multipart/alternative; boundary=Apple-Mail-1-962891510 X-Mailer: iPhone Mail (8B117) Message-Id: <7EAAC73A-8041-41FA-9673-EA3F7FD5AA15@gmail.com> Date: Wed, 5 Feb 2014 13:24:34 +0530 To: "netconf@ietf.org" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (iPhone Mail 8B117) X-Mailman-Approved-At: Wed, 05 Feb 2014 11:12:41 -0800 Subject: [Netconf] About NETCONF RFC 4743 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 Feb 2014 08:24:06 -0000 --Apple-Mail-1-962891510 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Sir i'm doing my main project on netconf using SOAP, but im getting some pro= blem so please sir i heartly request you to send the source code and its doc= ument of netconf.I'm very interested in doing this project please help me si= r..=20 thank you sir. --=20 Sent from my iPhone= --Apple-Mail-1-962891510 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset=utf-8
Sir i'm doing my main project on netconf using SOAP, but im getting some problem so please sir i heartly request you to send the source code and its document of netconf.I'm very interested in doing this project please help me sir.. 
                                thank you sir.
-- 

Sent from my iPhone
--Apple-Mail-1-962891510-- From iesg-secretary@ietf.org Fri Feb 7 09:34: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 A09001AC7F0; Fri, 7 Feb 2014 09:34:08 -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 CZB_dPMwL_-3; Fri, 7 Feb 2014 09:34:03 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E82D71A03F1; Fri, 7 Feb 2014 09:34:02 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140207173402.25766.16150.idtracker@ietfa.amsl.com> Date: Fri, 07 Feb 2014 09:34:02 -0800 Cc: netconf WG Subject: [Netconf] WG Review: Network Configuration (netconf) 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: Fri, 07 Feb 2014 17:34:08 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF is undergoing rechartering. The IESG has not made any determination yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg at ietf.org) by 2014-02-17. Network Configuration (netconf) ------------------------------------------------ Current Status: Active WG Chairs: Bert Wijnen Mehmet Ersue Assigned Area Director: Benoit Claise Mailing list Address: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Charter: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on the secure transport (SSH is mandatory to implement while TLS is an optional transport) and uses an XML-based data representation. The NETCONF protocol is data modeling language independent, but YANG (RFC 6020) is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case. 3. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. 4. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate call home YANG module. 5. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data using the datastores defined in NETCONF. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft. RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). Milestones: Feb 2014 - Submit initial WG draft for call home YANG module as WG item Feb 2014 - Submit initial WG draft for zero touch configuration as WG item Feb 2014 - Submit initial WG drafts for RESTCONF and patch operation as WG items Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for NETCONF server configuration data model Apr 2014 - WGLC for zero touch configuration Apr 2014 - WGLC for call home YANG module Apr 2014 - WGLC for RFC5539bis May 2014 - Submit call home YANG module to AD/IESG for consideration as Proposed Standard May 2014 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard May 2014 - Submit Reverse SSH and and zero touch configuration to AD/IESG for consideration as Proposed Standard Jun 2014 - WGLC for RESTCONF and patch operation drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard From ambika.tripathy@gmail.com Wed Feb 12 07:53:09 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 B7B551A09A9 for ; Wed, 12 Feb 2014 07:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 uPCGU3VtuE5e for ; Wed, 12 Feb 2014 07:53:08 -0800 (PST) Received: from mail-pd0-x22c.google.com (mail-pd0-x22c.google.com [IPv6:2607:f8b0:400e:c02::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 2F5781A09B2 for ; Wed, 12 Feb 2014 07:53:08 -0800 (PST) Received: by mail-pd0-f172.google.com with SMTP id p10so9146388pdj.17 for ; Wed, 12 Feb 2014 07:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=tPsPwjVraj0JQJlEy3XZwl7iOYvw0Wcqpmtal15qwos=; b=jyovvX4htQZ/xF/k5c7TG81j0AvvqFTKySC7MxDz+VH1tRL4CJTa1jlXWCbXu2CyrH B9DB4ldQ/NejC2wqusGoMAtlUbaFr1sB2tkBT086Bje6EQPqPDKsPE6SDiehL92UD5bN EqB91Vw4EHSxta0oKH7xEVELRl6lYONuvwTe9t5wvugfPQ/B2XoLlPSoTkcvA0TSq6wi 9rICWuZcUC41KWMrRntQxcanDm4bF7/msYBxOrsjezrfNstoV6X++3r5dMTecNSEM9SL wuBaU/zwXJqvEHwDCBhuBLGr2PBU/kxAWliVvcmR7ZGOZSUSurVYMwe63KaG5eDSy5HS N4jQ== MIME-Version: 1.0 X-Received: by 10.69.30.44 with SMTP id kb12mr52315943pbd.87.1392220387417; Wed, 12 Feb 2014 07:53:07 -0800 (PST) Received: by 10.68.131.197 with HTTP; Wed, 12 Feb 2014 07:53:07 -0800 (PST) Date: Wed, 12 Feb 2014 21:23:07 +0530 Message-ID: From: Ambika Tripathy To: Netconf@ietf.org Content-Type: multipart/alternative; boundary=001a11367b4ea423db04f237916c Subject: [Netconf] Practical use of extension. 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, 12 Feb 2014 15:53:09 -0000 --001a11367b4ea423db04f237916c Content-Type: text/plain; charset=ISO-8859-1 Hi, I am going though YANG and Open DayLight implementation using YANG files in MD_SAL. I have one fundamental doubt to understand how extension is working. Could you please explain with some practical example using some yang datastore concepts, how to use extension keyword in YANG and its usages. Practically, I am referring http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its extension defined in mound module and use in Appendix A. -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawkI --001a11367b4ea423db04f237916c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I am going though YANG and Open Day= Light implementation using YANG files in MD_SAL.

I= have one fundamental doubt to understand how extension is working.

Could you please explain with some practical example using s= ome yang datastore concepts, how to use extension keyword in YANG and its u= sages.

Practically, I am referring=A0http://tools.ietf.o= rg/id/draft-clemm-netmod-mount-01.txt and its extension defined in moun= d module and use in=A0Appendix A.

--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawkI=A0
--001a11367b4ea423db04f237916c-- From j.schoenwaelder@jacobs-university.de Wed Feb 12 07:59: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 47A101A09C1 for ; Wed, 12 Feb 2014 07:59:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 ptKGHXfJq85x for ; Wed, 12 Feb 2014 07:59:26 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 9147F1A09B6 for ; Wed, 12 Feb 2014 07:59:26 -0800 (PST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6226B2007D; Wed, 12 Feb 2014 16:59:25 +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 b1OORuKlzS0W; Wed, 12 Feb 2014 16:59:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F02D920017; Wed, 12 Feb 2014 16:59:24 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3EFA12B45F49; Wed, 12 Feb 2014 16:59:23 +0100 (CET) Date: Wed, 12 Feb 2014 16:59:22 +0100 From: Juergen Schoenwaelder To: Ambika Tripathy Message-ID: <20140212155922.GB81507@elstar.local> Mail-Followup-To: Ambika Tripathy , Netconf@ietf.org 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) Cc: Netconf@ietf.org Subject: Re: [Netconf] Practical use of 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: Wed, 12 Feb 2014 15:59:28 -0000 On Wed, Feb 12, 2014 at 09:23:07PM +0530, Ambika Tripathy wrote: > Hi, > > I am going though YANG and Open DayLight implementation using YANG files in > MD_SAL. > > I have one fundamental doubt to understand how extension is working. > > Could you please explain with some practical example using some yang > datastore concepts, how to use extension keyword in YANG and its usages. I suggest to read RFC 6020 section 7.17. In a nutshell, the extension statement allows to add a new statement to the YANG language. > Practically, I am referring > http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its extension > defined in mound module and use in Appendix A. This may not be a good example to study. That document may be confusing the YANG extension statement (which adds keywords to the YANG reportoire) with runtime additions to a data store. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From ambika.tripathy@gmail.com Wed Feb 12 08:11: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 DF9F51A09AB for ; Wed, 12 Feb 2014 08:11:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.999 X-Spam-Level: X-Spam-Status: No, score=-0.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, FREEMAIL_REPLY=1, 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 dp-wdr3Hjann for ; Wed, 12 Feb 2014 08:11:09 -0800 (PST) Received: from mail-pa0-x22e.google.com (mail-pa0-x22e.google.com [IPv6:2607:f8b0:400e:c03::22e]) by ietfa.amsl.com (Postfix) with ESMTP id E9C8D1A087C for ; Wed, 12 Feb 2014 08:11:08 -0800 (PST) Received: by mail-pa0-f46.google.com with SMTP id rd3so9427217pab.33 for ; Wed, 12 Feb 2014 08:11:08 -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 :content-type; bh=Z2ANHkJHJQQ3ZXly1+HiCO91neGY+efpZdDIAff0AXE=; b=ljvFT2GIYhmdrvNE8PjBSGJpAyuFStWr96UPfz6Xj7QItcbRWFOrCoAMkgZPFb8S/9 ouqgwf2LFu04f7fZCy0UjTXDaer4F53WUHLFMt03L+NuB8Qk+CiC7gYdgT1bHjpykY+F iejxNPIecaQoWFYbmYfsX5q4AEHyZF0RAuR1zAJKSR6/axQacXGbyR7qM7Q8OEwYJGpl 3eecc8f0XmLyOLbM/b5RCWrkG1+SEe22U4AL4jMm594rs4MXJGZKri81wOrwlCREK+u6 c+cVw/Y8VHnam89vkjSRC3jiyq5QFEgN89WmX9ewWbGGDR+w8mgF8uL8alx5Hh/r8xhS n8vA== MIME-Version: 1.0 X-Received: by 10.66.144.102 with SMTP id sl6mr39727075pab.96.1392221468170; Wed, 12 Feb 2014 08:11:08 -0800 (PST) Received: by 10.68.131.197 with HTTP; Wed, 12 Feb 2014 08:11:08 -0800 (PST) In-Reply-To: <20140212155922.GB81507@elstar.local> References: <20140212155922.GB81507@elstar.local> Date: Wed, 12 Feb 2014 21:41:08 +0530 Message-ID: From: Ambika Tripathy To: Juergen Schoenwaelder , Ambika Tripathy , Netconf@ietf.org Content-Type: multipart/alternative; boundary=047d7b6da6e40f1da704f237d2be Subject: Re: [Netconf] Practical use of extension. 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, 12 Feb 2014 16:11:13 -0000 --047d7b6da6e40f1da704f237d2be Content-Type: text/plain; charset=ISO-8859-1 Hi Juergen, Thanks for your quick response. Section: 7.17, in page 98 of the rfc 6020 "The substatements of an extension are defined by the extension, using some mechanism outside the scope of this specification. " Which is more confusing. What does it mean and what is the practical use of it in a YANG datastore? do you have some other example. br, Ambika On Wed, Feb 12, 2014 at 9:29 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Feb 12, 2014 at 09:23:07PM +0530, Ambika Tripathy wrote: > > Hi, > > > > I am going though YANG and Open DayLight implementation using YANG files > in > > MD_SAL. > > > > I have one fundamental doubt to understand how extension is working. > > > > Could you please explain with some practical example using some yang > > datastore concepts, how to use extension keyword in YANG and its usages. > > I suggest to read RFC 6020 section 7.17. In a nutshell, the extension > statement allows to add a new statement to the YANG language. > > > Practically, I am referring > > http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its > extension > > defined in mound module and use in Appendix A. > > This may not be a good example to study. That document may be > confusing the YANG extension statement (which adds keywords to the > YANG reportoire) with runtime additions to a data store. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > -- Ambika Prasad Tripathy Cell @+91 9437547730/8553070866 Alt email: ambika_tripathy@yahoo.com ambika.tripathy@gmail.com skype:ambika_nethawk --047d7b6da6e40f1da704f237d2be Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Juergen,

Thanks for your quick respo= nse.

Section: 7.17, in page 98 of the rfc 6020 &qu= ot;The substatements of an e= xtension
   are defined by the extension, using some mechanism outsid=
e the scope=A0
=A0= =A0of this specification.=A0" Which is more confusing.

What does it mean and =A0what is the practical use of i= t in a YANG datastore? do you have some other example.

=
br,
Ambika




On Wed, Feb 12, 2014 at 9:29 PM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Feb 12, 2014 at 09:2= 3:07PM +0530, Ambika Tripathy wrote:
> Hi,
>
> I am going though YANG and Open DayLight implementation using YANG fil= es in
> MD_SAL.
>
> I have one fundamental doubt to understand how extension is working. >
> Could you please explain with some practical example using some yang > datastore concepts, how to use extension keyword in YANG and its usage= s.

I suggest to read RFC 6020 section 7.17. In a nutshell, the extension=
statement allows to add a new statement to the YANG language.

> Practically, I am referring
> http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its extension
> defined in mound module and use in Appendix A.

This may not be a good example to study. That document may be
confusing the YANG extension statement (which adds keywords to the
YANG reportoire) with runtime additions to a data store.

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



--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk
--047d7b6da6e40f1da704f237d2be-- From j.schoenwaelder@jacobs-university.de Wed Feb 12 08:14: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 D5B051A03B4 for ; Wed, 12 Feb 2014 08:14:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.798 X-Spam-Level: X-Spam-Status: No, score=-2.798 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.548] 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 GZ7O4s7WQxgM for ; Wed, 12 Feb 2014 08:14:55 -0800 (PST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by ietfa.amsl.com (Postfix) with ESMTP id 648121A09AC for ; Wed, 12 Feb 2014 08:14:40 -0800 (PST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 58C2720084; Wed, 12 Feb 2014 17:14:39 +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 OSvZHd1O9V9L; Wed, 12 Feb 2014 17:14:39 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DFE6020082; Wed, 12 Feb 2014 17:14:38 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id DFA402B46122; Wed, 12 Feb 2014 17:14:37 +0100 (CET) Date: Wed, 12 Feb 2014 17:14:37 +0100 From: Juergen Schoenwaelder To: Ambika Tripathy Message-ID: <20140212161437.GC81507@elstar.local> Mail-Followup-To: Ambika Tripathy , Netconf@ietf.org References: <20140212155922.GB81507@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) Cc: Netconf@ietf.org Subject: Re: [Netconf] Practical use of 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: Wed, 12 Feb 2014 16:14:58 -0000 On Wed, Feb 12, 2014 at 09:41:08PM +0530, Ambika Tripathy wrote: > Hi Juergen, > > Thanks for your quick response. > > Section: 7.17, in page 98 of the rfc 6020 "The substatements of an extension > > are defined by the extension, using some mechanism outside the scope > > of this specification. " Which is more confusing. > > What does it mean and what is the practical use of it in a YANG datastore? None. You declare a new keyword for the YANG data modeling language. There is no direct relationship to datastores. > do you have some other example. RFC 6536 defines extensions. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From andy@yumaworks.com Wed Feb 12 08:16: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 837781A09CE for ; Wed, 12 Feb 2014 08:16:23 -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 oejx4iX37UiZ for ; Wed, 12 Feb 2014 08:16:20 -0800 (PST) Received: from mail-qc0-f170.google.com (mail-qc0-f170.google.com [209.85.216.170]) by ietfa.amsl.com (Postfix) with ESMTP id 455B81A09AC for ; Wed, 12 Feb 2014 08:16:20 -0800 (PST) Received: by mail-qc0-f170.google.com with SMTP id e9so15983385qcy.1 for ; Wed, 12 Feb 2014 08:16:19 -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=UlccgZ5tsP+fMX2HjxgdfRkvdmdi2JOKPYiRk1awT6I=; b=GnDlRMWMIfiZ7q0MlTV8Bw38ewjhk+Uq+HqeNdeVbR8QnurED8brJrFs9r5iA4P2v1 nQTb2/wW0JBPyBPiL1yd0zKcJzzbhlsi/leLGkwXqXVFx8e3rOAiH8piBUZ2SFA8n6X8 nDb2deBhYXiSBHuLItI7E1gSLx8EyrrFto9e4vP2LZurpiqcJ4LNaikGCNBRtfKanwyi /A8a/zgkVw4Ld4lF+EsrIsLXv10iPCKGq9JdHU6ymW+EmxQ4VW4A6eSq0Pmzc1g2j0tl 1rCUhsLd+mbOZF6XBnjJLQnetjPBKf6vYuY97xmyMDLQQfKP20Qiv1kuiDsdruL5pflK PAfQ== X-Gm-Message-State: ALoCoQmovJmHOsTp4nps+UDMTMtXl58YQl8139eu+Xi+tlh5lcxyaaRJxv3vdMDP7fK96zs9MB2N MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr64449097qgx.18.1392221779044; Wed, 12 Feb 2014 08:16:19 -0800 (PST) Received: by 10.140.98.130 with HTTP; Wed, 12 Feb 2014 08:16:18 -0800 (PST) In-Reply-To: References: <20140212155922.GB81507@elstar.local> Date: Wed, 12 Feb 2014 08:16:18 -0800 Message-ID: From: Andy Bierman To: Ambika Tripathy Content-Type: multipart/alternative; boundary=001a11c0043496f09b04f237e478 Cc: Netconf Subject: Re: [Netconf] Practical use of extension. 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, 12 Feb 2014 16:16:23 -0000 --001a11c0043496f09b04f237e478 Content-Type: text/plain; charset=ISO-8859-1 Hi, Since these external statements are outside of the YANG language, there is no definition in YANG for the syntax and semantics of external statements. Extensions are very useful within tool implementations to tag YANG definitions with additional metadata, in order to automate various functionality. Andy On Wed, Feb 12, 2014 at 8:11 AM, Ambika Tripathy wrote: > Hi Juergen, > > Thanks for your quick response. > > Section: 7.17, in page 98 of the rfc 6020 "The substatements of an > extension > > are defined by the extension, using some mechanism outside the scope > > of this specification. " Which is more confusing. > > What does it mean and what is the practical use of it in a YANG > datastore? do you have some other example. > > br, > Ambika > > > > > On Wed, Feb 12, 2014 at 9:29 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> On Wed, Feb 12, 2014 at 09:23:07PM +0530, Ambika Tripathy wrote: >> > Hi, >> > >> > I am going though YANG and Open DayLight implementation using YANG >> files in >> > MD_SAL. >> > >> > I have one fundamental doubt to understand how extension is working. >> > >> > Could you please explain with some practical example using some yang >> > datastore concepts, how to use extension keyword in YANG and its usages. >> >> I suggest to read RFC 6020 section 7.17. In a nutshell, the extension >> statement allows to add a new statement to the YANG language. >> >> > Practically, I am referring >> > http://tools.ietf.org/id/draft-clemm-netmod-mount-01.txt and its >> extension >> > defined in mound module and use in Appendix A. >> >> This may not be a good example to study. That document may be >> confusing the YANG extension statement (which adds keywords to the >> YANG reportoire) with runtime additions to a data store. >> >> /js >> >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >> > > > > -- > Ambika Prasad Tripathy > Cell @+91 9437547730/8553070866 > Alt email: ambika_tripathy@yahoo.com > ambika.tripathy@gmail.com > skype:ambika_nethawk > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --001a11c0043496f09b04f237e478 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Since these external statements are= outside of the YANG language,
there is no definition in YANG for= the syntax and semantics of
external statements.

Extensions are very useful within tool implementations to tag YA= NG
definitions with additional metadata, in order to automate var= ious
functionality.


Andy<= /div>



On Wed, Feb 12, 2014 at 8:11 AM, Ambika Tripathy = <ambika.t= ripathy@gmail.com> wrote:
Hi Juergen,

<= div>Thanks for your quick response.

Section: 7.17,= in page 98 of the rfc 6020 "The substat= ements of an extension
   are define=
d by the extension, using some mechanism outside the scope=A0
=A0 =A0of this specification.=A0" Wh= ich is more confusing.

What does it mean and =A0what is the practical use of i= t in a YANG datastore? do you have some other example.

=
br,
Ambika




On Wed, Feb 12, 2014 at 9:29 PM, Juergen= Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Feb 12, 2014 at 09:23:07PM +053= 0, Ambika Tripathy wrote:
> Hi,
>
> I am going though YANG and Open DayLight implementation using YANG fil= es in
> MD_SAL.
>
> I have one fundamental doubt to understand how extension is working. >
> Could you please explain with some practical example using some yang > datastore concepts, how to use extension keyword in YANG and its usage= s.

I suggest to read RFC 6020 section 7.17. In a nutshell, the extension=
statement allows to add a new statement to the YANG language.
This may not be a good example to study. That document may be
confusing the YANG extension statement (which adds keywords to the
YANG reportoire) with runtime additions to a data store.

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



--
Ambika Prasad Tripathy
Cell @+91 9437547730/8553070866
skype:ambika_nethawk

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


--001a11c0043496f09b04f237e478-- From kwatsen@juniper.net Wed Feb 12 10:29: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 CA3481A066C for ; Wed, 12 Feb 2014 10:29:19 -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 PW2X6sVFbu2R for ; Wed, 12 Feb 2014 10:29:15 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe003.messaging.microsoft.com [216.32.180.186]) by ietfa.amsl.com (Postfix) with ESMTP id 8238D1A0602 for ; Wed, 12 Feb 2014 10:29:15 -0800 (PST) Received: from mail21-co1-R.bigfish.com (10.243.78.237) by CO1EHSOBE038.bigfish.com (10.243.66.103) with Microsoft SMTP Server id 14.1.225.22; Wed, 12 Feb 2014 18:29:14 +0000 Received: from mail21-co1 (localhost [127.0.0.1]) by mail21-co1-R.bigfish.com (Postfix) with ESMTP id 609325E02DF for ; Wed, 12 Feb 2014 18:29:14 +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: 0 X-BigFish: VPS0(zz4015Idbb0izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h177df4h17326ah8275bh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail21-co1: 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)(164054003)(199002)(189002)(80022001)(65816001)(87266001)(87936001)(77096001)(95666001)(92566001)(92726001)(56816005)(90146001)(31966008)(83072002)(85852003)(83506001)(15975445006)(36756003)(76176001)(76786001)(76796001)(81816001)(81686001)(66066001)(2656002)(85306002)(47446002)(19300405004)(74662001)(74502001)(93136001)(69226001)(95416001)(15395725003)(86362001)(94316002)(93516002)(15202345003)(74706001)(94946001)(81542001)(53806001)(46102001)(54356001)(51856001)(56776001)(54316002)(76482001)(4396001)(49866001)(47736001)(50986001)(47976001)(74876001)(81342001)(79102001)(59766001)(77982001)(74366001)(63696002)(80976001)(19580395003)(83322001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.10; FPR:6CE0501C.AE3256CB.62F90DBB.84A9D23F.20167; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail21-co1 (localhost.localdomain [127.0.0.1]) by mail21-co1 (MessageSwitch) id 1392229751217710_6190; Wed, 12 Feb 2014 18:29:11 +0000 (UTC) Received: from CO1EHSMHS031.bigfish.com (unknown [10.243.78.229]) by mail21-co1.bigfish.com (Postfix) with ESMTP id 244C850004A for ; Wed, 12 Feb 2014 18:29:11 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS031.bigfish.com (10.243.66.41) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 12 Feb 2014 18:29:11 +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.411.0; Wed, 12 Feb 2014 18:29:06 +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.873.15; Wed, 12 Feb 2014 18:29:04 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) with mapi id 15.00.0873.009; Wed, 12 Feb 2014 18:29:04 +0000 From: Kent Watsen To: NetConf Thread-Topic: multiple top-level nodes? Thread-Index: AQHPKCBOsZBo5weJfEeV6u2IYLwFiQ== Date: Wed, 12 Feb 2014 18:29:03 +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.10] x-forefront-prvs: 01208B1E18 Content-Type: text/plain; charset="us-ascii" Content-ID: <22B1C3D08E6EED40B070A5B2DD3E0A84@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% Subject: [Netconf] multiple top-level nodes? 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, 12 Feb 2014 18:29:20 -0000 Can with no filter return multiple top-level nodes? All the examples in RFC 6241 show just a single top-level node being returned. For instance: ... But is this possible? ... ... ... For reference, section 6.4.1 (No Filter) says: Leaving out the filter on the operation returns the entire data model. And the YANG module has: output { anyxml data { description "Copy of the source datastore subset that matched the filter criteria (if any). An empty data container indicates that the request did not produce any results."; } } So I don't see it disallowed, but it also seems counter-intuitive... Thoughts? Thanks, Kent From andy@yumaworks.com Wed Feb 12 10:44: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 4BAF21A066B for ; Wed, 12 Feb 2014 10:44:08 -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 HePvg7gdbhql for ; Wed, 12 Feb 2014 10:44:05 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 15FBB1A061E for ; Wed, 12 Feb 2014 10:44:04 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so14314131qaq.25 for ; Wed, 12 Feb 2014 10:44:04 -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=mAIVNrNhLTfBz8wLIjMvCpQCT9FiP2VS2xqLsnXy5LM=; b=b+Ryqt24OpjBA+zzkQD9qEnqKUFjzrznm6V94D9caP0GnCpdKUEQABii/0ntODSS4e jRp3GXsurEeUA8CGcKcZrSpk1hvIc/F5KJjVoe5a/mjH8NihfuTcPr8rbGHVDzFxZGA0 LIDNxBTkeH8PtpxK1gtgkOlWs1ERuwTEUsVzBM9erwgjBE+ajb0L+68OQlxXWD6RzMG3 6KEPvQVAIrGuj/8R8hsHN6nsTLE6G78/QzFQ3592hvmia8gfgyZiuvfSCgpnNlPbn2oy /1rUGA9S01I6UjhRf0K9FXmy4D1SrYuWxbPu4sAEqNgAAIyUmR10NdEu0O4IrNGuzBRP Gr+w== X-Gm-Message-State: ALoCoQmWsfc15qDD96p33FHmQyIwDNI2WXmRKbJzutMLplBBxfbEnVCps8LH59vuQDCxrjNEp45Y MIME-Version: 1.0 X-Received: by 10.140.85.179 with SMTP id n48mr65311874qgd.91.1392230643994; Wed, 12 Feb 2014 10:44:03 -0800 (PST) Received: by 10.140.98.130 with HTTP; Wed, 12 Feb 2014 10:44:03 -0800 (PST) In-Reply-To: References: Date: Wed, 12 Feb 2014 10:44:03 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a11c133defba0e004f239f41e Cc: NetConf Subject: Re: [Netconf] multiple top-level nodes? 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, 12 Feb 2014 18:44:08 -0000 --001a11c133defba0e004f239f41e Content-Type: text/plain; charset=ISO-8859-1 Hi, Yes. One reason the node exists in and replies is so it can contain multiple top-level data nodes, and still be a valid XML document, In the YANG mapping, the element is not added because the serves as the container. (Note that RESTCONF with XML encoding is still broken. The draft does not specify a container or an error yet.) The use of a named node makes mapping to YANG possible. Andy On Wed, Feb 12, 2014 at 10:29 AM, Kent Watsen wrote: > > Can with no filter return multiple top-level nodes? > > All the examples in RFC 6241 show just a single top-level node being > returned. For instance: > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > ... > > > > > > But is this possible? > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > ... > > > ... > > > ... > > > > > > > > > For reference, section 6.4.1 (No Filter) says: > > Leaving out the filter on the operation returns the entire data > model. > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > > And the YANG module has: > > output { > anyxml data { > description > "Copy of the source datastore subset that matched > the filter criteria (if any). An empty data container > indicates that the request did not produce any results."; > } > } > > > So I don't see it disallowed, but it also seems counter-intuitive... > > Thoughts? > > Thanks, > Kent > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11c133defba0e004f239f41e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

Yes.

One r= eason the <data> node exists in <get> and <get-config>
replies is so it can contain multiple top-level data nodes, and
still be a valid XML document, =A0In the YANG mapping, the <data>= ;
element is not added because the <rpc-reply> serves as th= e container.
(Note that RESTCONF with XML encoding is still broke= n. The draft
does not specify a container or an error yet.)

The use of a named node makes mapping to YANG possible.

Andy




On Wed, Feb 12, 2014 at 10:29 AM, Kent W= atsen <kwatsen@juniper.net> wrote:

Can <get-config> with no filter return multiple top-level nodes?

All the examples in RFC 6241 show just a single top-level node being
returned. =A0For instance:

=A0 =A0 =A0<rpc message-id=3D"101"
=A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=A0 =A0 =A0 =A0<get/>
=A0 =A0 =A0</rpc>

=A0 =A0 =A0<rpc-reply message-id=3D"101"
=A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=A0 =A0 =A0 =A0<data>
=A0 =A0 =A0 =A0 =A0<top xmlns=3D"http://example.com/schema/1.2/config&q= uot;>
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0</top>
=A0 =A0 =A0 =A0</data>
=A0 =A0 =A0</rpc-reply>


But is this possible?

=A0 =A0 =A0<rpc-reply message-id=3D"101"
=A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=A0 =A0 =A0 =A0<data>
=A0 =A0 =A0 =A0 =A0<top1 xmlns=3D"http://example.com/schema/1.2/config-1<= /a>">
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0</top1>
=A0 =A0 =A0 =A0 =A0<top2 xmlns=3D"http://example.com/schema/1.2/config-2<= /a>">
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0</top2>
=A0 =A0 =A0 =A0 =A0<top3 xmlns=3D"http://example.com/schema/1.2/config-3<= /a>">
=A0 =A0 =A0 =A0 =A0 =A0...
=A0 =A0 =A0 =A0 =A0</top3>


=A0 =A0 =A0 =A0</data>
=A0 =A0 =A0</rpc-reply>



For reference, section 6.4.1 (No Filter) says:

=A0 =A0Leaving out the filter on the <get> operation returns the enti= re data
=A0 =A0model.

=A0 =A0 =A0<rpc message-id=3D"101"
=A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=A0 =A0 =A0 =A0<get/>
=A0 =A0 =A0</rpc>

=A0 =A0 =A0<rpc-reply message-id=3D"101"
=A0 =A0 =A0 =A0 =A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0&q= uot;>
=A0 =A0 =A0 =A0<data>
=A0 =A0 =A0 =A0 =A0<!-- ... entire set of data returned ... -->
=A0 =A0 =A0 =A0</data>
=A0 =A0 =A0</rpc-reply>

And the YANG module has:

=A0 =A0 =A0 output {
=A0 =A0 =A0 =A0 anyxml data {
=A0 =A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 "Copy of the source datastore subset that matc= hed
=A0 =A0 =A0 =A0 =A0 =A0 =A0the filter criteria (if any). =A0An empty data c= ontainer
=A0 =A0 =A0 =A0 =A0 =A0 =A0indicates that the request did not produce any r= esults.";
=A0 =A0 =A0 =A0 }
=A0 =A0 =A0 }


So I don't see it disallowed, but it also seems counter-intuitive...
Thoughts?

Thanks,
Kent




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

--001a11c133defba0e004f239f41e-- From rohit.pobbathi@huawei.com Wed Feb 12 21:04:26 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 A1D701A00ED for ; Wed, 12 Feb 2014 21:04:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548, 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 ckJN9r0VB2sh for ; Wed, 12 Feb 2014 21:04:24 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id D5A6E1A00F8 for ; Wed, 12 Feb 2014 21:04:23 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBB43521; Thu, 13 Feb 2014 05:04:21 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 05:04:04 +0000 Received: from SZXEML455-HUB.china.huawei.com (10.82.67.198) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 13 Feb 2014 05:04:20 +0000 Received: from szxeml561-mbs.china.huawei.com ([169.254.6.169]) by SZXEML455-HUB.china.huawei.com ([10.82.67.198]) with mapi id 14.03.0158.001; Thu, 13 Feb 2014 13:04:13 +0800 From: Rohit pobbathi To: Kent Watsen , NetConf Thread-Topic: multiple top-level nodes? Thread-Index: AQHPKCBOsZBo5weJfEeV6u2IYLwFiZqyoQUw Date: Thu, 13 Feb 2014 05:04:12 +0000 Message-ID: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.com> References: In-Reply-To: Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.18.151.62] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Netconf] multiple top-level nodes? 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, 13 Feb 2014 05:04:26 -0000 Q2FuIDxnZXQtY29uZmlnPiB3aXRoIG5vIGZpbHRlciByZXR1cm4gbXVsdGlwbGUgdG9wLWxldmVs IG5vZGVzPw0KDQpJbiBteSBvcGluaW9uLCBZRVMuDQpObyBmaWx0ZXIgcXVlcnkgbXVzdCBiZSBj YXBhYmxlIHRvIHJldHVybiBlbnRpcmUgZGF0YSBtb2RlbC4NCkFuZCB0byByZXR1cm4gZW50aXJl IGRhdGEgbW9kZWwsIGl0IGlzIHJlcXVpcmVkIHRvIHByb3ZpZGUgbXVsdGlwbGUgdG9wLWxldmVs IG5vZGVzIGluIHJlcGx5Lg0KDQpSZ2RzLA0KUm9oaXQgUG9iYmF0aGkNCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0 Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KU2VudDogMjAxNMTqMtTCMTLI1SAyMzo1 OQ0KVG86IE5ldENvbmYNClN1YmplY3Q6IFtOZXRjb25mXSBtdWx0aXBsZSB0b3AtbGV2ZWwgbm9k ZXM/DQoNCg0KQ2FuIDxnZXQtY29uZmlnPiB3aXRoIG5vIGZpbHRlciByZXR1cm4gbXVsdGlwbGUg dG9wLWxldmVsIG5vZGVzPw0KDQpBbGwgdGhlIGV4YW1wbGVzIGluIFJGQyA2MjQxIHNob3cganVz dCBhIHNpbmdsZSB0b3AtbGV2ZWwgbm9kZSBiZWluZyByZXR1cm5lZC4gIEZvciBpbnN0YW5jZToN Cg0KICAgICA8cnBjIG1lc3NhZ2UtaWQ9IjEwMSINCiAgICAgICAgICB4bWxucz0idXJuOmlldGY6 cGFyYW1zOnhtbDpuczpuZXRjb25mOmJhc2U6MS4wIj4NCiAgICAgICA8Z2V0Lz4NCiAgICAgPC9y cGM+DQoNCiAgICAgPHJwYy1yZXBseSBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICAgeG1sbnM9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAgPGRhdGE+ DQogICAgICAgICA8dG9wIHhtbG5zPSJodHRwOi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25m aWciPg0KICAgICAgICAgICAuLi4NCiAgICAgICAgIDwvdG9wPg0KICAgICAgIDwvZGF0YT4NCiAg ICAgPC9ycGMtcmVwbHk+DQoNCg0KQnV0IGlzIHRoaXMgcG9zc2libGU/DQoNCiAgICAgPHJwYy1y ZXBseSBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICAgeG1sbnM9InVybjppZXRmOnBhcmFtczp4 bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAgPGRhdGE+DQogICAgICAgICA8dG9wMSB4 bWxucz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnLTEiPg0KICAgICAgICAg ICAuLi4NCiAgICAgICAgIDwvdG9wMT4NCiAgICAgICAgIDx0b3AyIHhtbG5zPSJodHRwOi8vZXhh bXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWctMiI+DQogICAgICAgICAgIC4uLg0KICAgICAgICAg PC90b3AyPg0KICAgICAgICAgPHRvcDMgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEv MS4yL2NvbmZpZy0zIj4NCiAgICAgICAgICAgLi4uDQogICAgICAgICA8L3RvcDM+DQoNCg0KICAg ICAgIDwvZGF0YT4NCiAgICAgPC9ycGMtcmVwbHk+DQoNCg0KDQpGb3IgcmVmZXJlbmNlLCBzZWN0 aW9uIDYuNC4xIChObyBGaWx0ZXIpIHNheXM6DQoNCiAgIExlYXZpbmcgb3V0IHRoZSBmaWx0ZXIg b24gdGhlIDxnZXQ+IG9wZXJhdGlvbiByZXR1cm5zIHRoZSBlbnRpcmUgZGF0YQ0KICAgbW9kZWwu DQoNCiAgICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQogICAgICAgICAgeG1sbnM9InVybjppZXRm OnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQogICAgICAgPGdldC8+DQogICAgIDwv cnBjPg0KDQogICAgIDxycGMtcmVwbHkgbWVzc2FnZS1pZD0iMTAxIg0KICAgICAgICAgIHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KICAgICAgIDxkYXRh Pg0KICAgICAgICAgPCEtLSAuLi4gZW50aXJlIHNldCBvZiBkYXRhIHJldHVybmVkIC4uLiAtLT4N CiAgICAgICA8L2RhdGE+DQogICAgIDwvcnBjLXJlcGx5Pg0KDQpBbmQgdGhlIFlBTkcgbW9kdWxl IGhhczoNCg0KICAgICAgb3V0cHV0IHsNCiAgICAgICAgYW55eG1sIGRhdGEgew0KICAgICAgICAg IGRlc2NyaXB0aW9uDQogICAgICAgICAgICAiQ29weSBvZiB0aGUgc291cmNlIGRhdGFzdG9yZSBz dWJzZXQgdGhhdCBtYXRjaGVkDQogICAgICAgICAgICAgdGhlIGZpbHRlciBjcml0ZXJpYSAoaWYg YW55KS4gIEFuIGVtcHR5IGRhdGEgY29udGFpbmVyDQogICAgICAgICAgICAgaW5kaWNhdGVzIHRo YXQgdGhlIHJlcXVlc3QgZGlkIG5vdCBwcm9kdWNlIGFueSByZXN1bHRzLiI7DQogICAgICAgIH0N CiAgICAgIH0NCg0KDQpTbyBJIGRvbid0IHNlZSBpdCBkaXNhbGxvd2VkLCBidXQgaXQgYWxzbyBz ZWVtcyBjb3VudGVyLWludHVpdGl2ZS4uLg0KDQpUaG91Z2h0cz8NCg0KVGhhbmtzLA0KS2VudA0K DQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K TmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0K From nobody Thu Feb 13 14:12: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 6B0171A040C for ; Thu, 13 Feb 2014 14:12:41 -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 qZBhAR-hiavy for ; Thu, 13 Feb 2014 14:12:38 -0800 (PST) Received: from mail-qa0-f49.google.com (mail-qa0-f49.google.com [209.85.216.49]) by ietfa.amsl.com (Postfix) with ESMTP id BB7741A0417 for ; Thu, 13 Feb 2014 14:12:38 -0800 (PST) Received: by mail-qa0-f49.google.com with SMTP id w8so16919392qac.36 for ; Thu, 13 Feb 2014 14:12:37 -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=gc5pE/bD0Ficv1Tbd3QF1o2Hvvj3y5fy1nSQS4SuT2M=; b=bhAmLYsrFN1cv3wK1CPhVGZXts0xFxCb2CKuiI2kvKP9dEUlA041eHBDNWl4wMfaDd a7y/Ox9CKGFXLLYNCnWfSCEMalWkLeTzpQ/9Ze1rYyoJtsSiotdZfBu8ccJWs37x7k5L C5vLuDe12HvMZDoeecdEVQEboNLbNQAIfopV6AncK7nHD9sTDyhiU+DzEldUWIbiI4HN vWbHk/O7awCcDwel5czbMkm/E6VUXJeHA5uvDvHT75TmvP0zQK35KrlG56ODGvbGg8cc 3yx775wUkIO/RWbibZZ0dnyxZ7cRa4sLCBjWlUBgTJtj1i4jEKJtn/abqlO0QrHAb66h hhzA== X-Gm-Message-State: ALoCoQkA4/uDZiG7X/FwVk4zdkbfkDPgtQg0TEvgSkM8DLcOJp/XpEQxU2ejjslmB0UtYOV9QXsr MIME-Version: 1.0 X-Received: by 10.140.27.179 with SMTP id 48mr6622565qgx.18.1392329557356; Thu, 13 Feb 2014 14:12:37 -0800 (PST) Received: by 10.140.98.130 with HTTP; Thu, 13 Feb 2014 14:12:37 -0800 (PST) In-Reply-To: <20140213221002.30492.91618.idtracker@ietfa.amsl.com> References: <20140213221002.30492.91618.idtracker@ietfa.amsl.com> Date: Thu, 13 Feb 2014 14:12:37 -0800 Message-ID: From: Andy Bierman To: Netconf Content-Type: multipart/alternative; boundary=001a11c00434ad4b8204f250fc1c Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LM1EPnkAzfq2978rI-n6xlBjK8s Subject: [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: Thu, 13 Feb 2014 22:12:41 -0000 --001a11c00434ad4b8204f250fc1c Content-Type: text/plain; charset=ISO-8859-1 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-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt --001a11c00434ad4b8204f250fc1c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

A new version of the RESTCONF draf= t has been posted.
There were only minor clarifications and bug-f= ixes 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-ne= tconf-restconf-04.txt
To: i-d-a= nnounce@ietf.org



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


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restconf-04= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 96
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0This document describes a REST-like protocol that provides a
=A0 =A0programmatic interface over HTTP for accessing data defined in YANG,=
=A0 =A0using 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@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

--001a11c00434ad4b8204f250fc1c-- From nobody Thu Feb 13 18:38: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 6C23F1A0073 for ; Thu, 13 Feb 2014 18:38:20 -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 D-zpJszuowCv for ; Thu, 13 Feb 2014 18:38:18 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6101A0051 for ; Thu, 13 Feb 2014 18:38:17 -0800 (PST) Received: from mail145-co9-R.bigfish.com (10.236.132.228) by CO9EHSOBE012.bigfish.com (10.236.130.75) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 02:38:16 +0000 Received: from mail145-co9 (localhost [127.0.0.1]) by mail145-co9-R.bigfish.com (Postfix) with ESMTP id 66C49480320 for ; Fri, 14 Feb 2014 02:38:16 +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: -26 X-BigFish: VPS-26(z579ehzbb2dI98dI9371I936eI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail145-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)(199002)(189002)(24454002)(479174003)(51704005)(377454003)(377424004)(164054003)(74502001)(74876001)(47446002)(85306002)(74662001)(31966008)(74706001)(86362001)(95416001)(66066001)(94316002)(65816001)(93136001)(94946001)(53806001)(93516002)(79102001)(59766001)(77982001)(85852003)(87266001)(83072002)(46102001)(56816005)(90146001)(76482001)(54356001)(95666001)(80022001)(92726001)(51856001)(76786001)(87936001)(56776001)(77096001)(81816001)(36756003)(81686001)(76796001)(81542001)(4396001)(74366001)(50986001)(47976001)(49866001)(47736001)(81342001)(92566001)(83506001)(80976001)(63696002)(54316002)(83322001)(19580395003)(69226001)(2656002)(19580405001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:2C39FD9D.29F067C3.55CD9F57.44E05410.2026A; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail145-co9 (localhost.localdomain [127.0.0.1]) by mail145-co9 (MessageSwitch) id 1392345495443121_23667; Fri, 14 Feb 2014 02:38:15 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.237]) by mail145-co9.bigfish.com (Postfix) with ESMTP id 5E264360047 for ; Fri, 14 Feb 2014 02:38:15 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 02:38:15 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 02:38:13 +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.873.15; Fri, 14 Feb 2014 02:38:11 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 02:38:11 +0000 From: Kent Watsen To: NetConf Thread-Topic: New Version Notification for draft-kwatsen-netconf-zerotouch-01.txt Thread-Index: AQHPKS0FOaRi3U3FtUOzF/A/Q9sTSpqztXyA Date: Fri, 14 Feb 2014 02:38:10 +0000 Message-ID: References: <20140214023223.10074.1230.idtracker@ietfa.amsl.com> In-Reply-To: <20140214023223.10074.1230.idtracker@ietfa.amsl.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: 01221E3973 Content-Type: text/plain; charset="us-ascii" Content-ID: <4AC549F0AA07F04B9495E217D59DA977@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/D3f0dqpj4dVvwFGpDrn5yZfP70k Subject: [Netconf] FW: New Version Notification for draft-kwatsen-netconf-zerotouch-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: Fri, 14 Feb 2014 02:38:20 -0000 For those interested in the zerotouch draft, Please note that this update is nearly a complete rewrite. The solution switched from using signed DNS records using DNSSEC to using signed YANG-defined XML files using XML Signature. This update took into a lot a feedback from both operators and vendors. Thanks, Kent On 2/13/14 9:32 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kwatsen-netconf-zerotouch-01.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-kwatsen-netconf-zerotouch >Revision: 01 >Title: Zero Touch Provisioning for NETCONF Call Home (ZeroTouch) >Document date: 2014-02-13 >Group: Individual Submission >Pages: 26 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kwatsen-netconf-zerotouch-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kwatsen-netconf-zerotouch/ >Htmlized: =20 >http://tools.ietf.org/html/draft-kwatsen-netconf-zerotouch-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-kwatsen-netconf-zerotouch-01 > >Abstract: > This draft presents a technique for how to establish a secure NETCONF > connection between a newly deployed networking device, configured > with just its factory default settings, and the new owner's Network > Management System (NMS). > > =20 > =20 > > >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 > > > From nobody Fri Feb 14 09:21:44 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 1E5681A02FC; Fri, 14 Feb 2014 09:21:43 -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 lWXZyDkS0ogn; Fri, 14 Feb 2014 09:21:41 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F181A02E8; Fri, 14 Feb 2014 09:21:41 -0800 (PST) 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.0.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140214172141.28273.79193.idtracker@ietfa.amsl.com> Date: Fri, 14 Feb 2014 09:21:41 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/_jTfVtmiU8PTh7aS2dN3H_kHn9w Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-reverse-ssh-03.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: Fri, 14 Feb 2014 17:21:43 -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 : Reverse Secure Shell (Reverse SSH) Author : Kent Watsen Filename : draft-ietf-netconf-reverse-ssh-03.txt Pages : 10 Date : 2014-02-14 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". The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-reverse-ssh-03 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 Fri Feb 14 11:24: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 6AF791A02D0 for ; Fri, 14 Feb 2014 11:24:45 -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 3MfmkhW2H_p3 for ; Fri, 14 Feb 2014 11:24:38 -0800 (PST) Received: from co1outboundpool.messaging.microsoft.com (co1ehsobe004.messaging.microsoft.com [216.32.180.187]) by ietfa.amsl.com (Postfix) with ESMTP id A4A4F1A0068 for ; Fri, 14 Feb 2014 11:24:33 -0800 (PST) Received: from mail86-co1-R.bigfish.com (10.243.78.244) by CO1EHSOBE041.bigfish.com (10.243.66.106) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 19:24:32 +0000 Received: from mail86-co1 (localhost [127.0.0.1]) by mail86-co1-R.bigfish.com (Postfix) with ESMTP id 006BE84046E for ; Fri, 14 Feb 2014 19:24: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: -26 X-BigFish: VPS-26(z579ehzbb2dI98dI9371I936eI1b0bI1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail86-co1: 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)(6009001)(377454003)(24454002)(377424004)(189002)(199002)(479174003)(51704005)(69234005)(90146001)(92726001)(85852003)(31966008)(56816005)(19580395003)(83506001)(94316002)(80976001)(77096001)(76796001)(81542001)(83072002)(86362001)(76786001)(74502001)(94946001)(19580405001)(47446002)(93136001)(95416001)(69226001)(81342001)(74662001)(74366001)(56776001)(93516002)(63696002)(85306002)(2656002)(92566001)(59766001)(87266001)(80022001)(66066001)(74876001)(79102001)(65816001)(54316002)(49866001)(87936001)(36756003)(74706001)(95666001)(77982001)(83322001)(51856001)(53806001)(81686001)(76482001)(54356001)(47976001)(50986001)(4396001)(81816001)(46102001)(47736001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:F0AFD3F.1DF62FC9.47CFB2CB.48E8D8D1.20255; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail86-co1 (localhost.localdomain [127.0.0.1]) by mail86-co1 (MessageSwitch) id 1392405869441004_13601; Fri, 14 Feb 2014 19:24:29 +0000 (UTC) Received: from CO1EHSMHS003.bigfish.com (unknown [10.243.78.240]) by mail86-co1.bigfish.com (Postfix) with ESMTP id 5D9086C004A for ; Fri, 14 Feb 2014 19:24:29 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by CO1EHSMHS003.bigfish.com (10.243.66.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 19:24:29 +0000 Received: from CO1PR05MB460.namprd05.prod.outlook.com (10.141.72.152) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 19:24:25 +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.873.15; Fri, 14 Feb 2014 19:24:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 19:24:22 +0000 From: Kent Watsen To: NetConf Thread-Topic: New Version Notification for draft-ietf-netconf-reverse-ssh-03.txt Thread-Index: AQHPKalHXUXxcXoDUUO4KTCQpUZtQpq0zZEA Date: Fri, 14 Feb 2014 19:24:22 +0000 Message-ID: References: <20140214172141.28273.67576.idtracker@ietfa.amsl.com> In-Reply-To: <20140214172141.28273.67576.idtracker@ietfa.amsl.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: 01221E3973 Content-Type: text/plain; charset="us-ascii" Content-ID: <4520380A7FD94D43829FA8AFBE5C24DE@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/Ijkw0n9zCF2uEVgJ7CnvVuUdigg Subject: [Netconf] FW: New Version Notification for 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: Fri, 14 Feb 2014 19:24:45 -0000 For those interested in Reverse SSH, FYI, this update primarily replaces the YANG module and example with a reference to draft-kwatsen-netconf-server, as agreed on in Vancouver. Cheers, Kent On 2/14/14 12:21 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-ietf-netconf-reverse-ssh-03.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-ietf-netconf-reverse-ssh >Revision: 03 >Title: Reverse Secure Shell (Reverse SSH) >Document date: 2014-02-14 >Group: netconf >Pages: 10 >URL: =20 >http://www.ietf.org/internet-drafts/draft-ietf-netconf-reverse-ssh-03.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-ietf-netconf-reverse-ssh/ >Htmlized: =20 >http://tools.ietf.org/html/draft-ietf-netconf-reverse-ssh-03 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netconf-reverse-ssh-03 > >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". > > =20 > =20 > > >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 > > > From nobody Fri Feb 14 11:26: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 B77CC1A0278 for ; Fri, 14 Feb 2014 11:26:38 -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 tJ9zCS_pqK0D for ; Fri, 14 Feb 2014 11:26:34 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 204271A02AF for ; Fri, 14 Feb 2014 11:26:34 -0800 (PST) Received: from mail45-ch1-R.bigfish.com (10.43.68.236) by CH1EHSOBE019.bigfish.com (10.43.70.76) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 19:26:32 +0000 Received: from mail45-ch1 (localhost [127.0.0.1]) by mail45-ch1-R.bigfish.com (Postfix) with ESMTP id 654A1C03EE for ; Fri, 14 Feb 2014 19:26:32 +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: -26 X-BigFish: VPS-26(zzbb2dI98dI9371I936eI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) 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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(51704005)(199002)(189002)(377424004)(479174003)(24454002)(164054003)(4396001)(50986001)(47976001)(47736001)(49866001)(63696002)(81342001)(56776001)(74706001)(53806001)(93516002)(86362001)(94316002)(54316002)(51856001)(74876001)(76482001)(94946001)(54356001)(81542001)(46102001)(19580395003)(19580405001)(79102001)(80976001)(77982001)(74366001)(59766001)(83322001)(87936001)(74662001)(92566001)(92726001)(31966008)(95666001)(80022001)(56816005)(83506001)(83072002)(65816001)(2656002)(87266001)(90146001)(85852003)(36756003)(15975445006)(74502001)(93136001)(77096001)(69226001)(15202345003)(95416001)(76786001)(81816001)(76796001)(66066001)(85306002)(47446002)(81686001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB458; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:B08FDBE.28F12FC3.5DC234B.80E019D1.20218; InfoNoRecordsA:1; MX:1; LANG:en; Received: from mail45-ch1 (localhost.localdomain [127.0.0.1]) by mail45-ch1 (MessageSwitch) id 1392405989564605_20904; Fri, 14 Feb 2014 19:26:29 +0000 (UTC) Received: from CH1EHSMHS016.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail45-ch1.bigfish.com (Postfix) with ESMTP id 7B744320047 for ; Fri, 14 Feb 2014 19:26:29 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS016.bigfish.com (10.43.70.16) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 19:26:29 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 19:26:28 +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.873.15; Fri, 14 Feb 2014 19:26:26 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.228]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 19:26:25 +0000 From: Kent Watsen To: NetConf Thread-Topic: New Version Notification for draft-kwatsen-netconf-server-01.txt Thread-Index: AQHPKazJkhNWwl7ZU02/euoBqOLhi5q0ziAA Date: Fri, 14 Feb 2014 19:26:25 +0000 Message-ID: References: <20140214174655.20443.70320.idtracker@ietfa.amsl.com> In-Reply-To: <20140214174655.20443.70320.idtracker@ietfa.amsl.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: 01221E3973 Content-Type: text/plain; charset="us-ascii" Content-ID: <3EFFE4F7BBD8EA49BB45756C3A0C4C81@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/GLS45u198ReCK0TIzxbCc8SeFDE Subject: [Netconf] FW: New Version Notification for 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: Fri, 14 Feb 2014 19:26:38 -0000 For those following the netconf-server draft, this is a minor update that simply restructures the YANG module slightly to enable more configuration to be order grouping statements. Thanks, Kent On 2/14/14 12:46 PM, "internet-drafts@ietf.org" wrote: > >A new version of I-D, draft-kwatsen-netconf-server-01.txt >has been successfully submitted by Kent Watsen and posted to the >IETF repository. > >Name: draft-kwatsen-netconf-server >Revision: 01 >Title: A YANG Data Model for NETCONF Server Configuration >Document date: 2014-02-14 >Group: Individual Submission >Pages: 26 >URL: =20 >http://www.ietf.org/internet-drafts/draft-kwatsen-netconf-server-01.txt >Status: =20 >https://datatracker.ietf.org/doc/draft-kwatsen-netconf-server/ >Htmlized: http://tools.ietf.org/html/draft-kwatsen-netconf-server-01 >Diff: =20 >http://www.ietf.org/rfcdiff?url2=3Ddraft-kwatsen-netconf-server-01 > >Abstract: > This draft defines a NETCONF server configuration data model. This > data model enables configuration of the NETCONF service itself, > including which transports it supports, what ports they listen on, > whether they support device-initiated connections, and associated > parameters. > > =20 > =20 > > >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 > > > From nobody Fri Feb 14 13:06: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 DAF051A03E6 for ; Fri, 14 Feb 2014 13:06:26 -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 077EGAerPSS9 for ; Fri, 14 Feb 2014 13:06:24 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 065D81A03CC for ; Fri, 14 Feb 2014 13:06:24 -0800 (PST) Received: from mail204-tx2-R.bigfish.com (10.9.14.232) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 21:06:22 +0000 Received: from mail204-tx2 (localhost [127.0.0.1]) by mail204-tx2-R.bigfish.com (Postfix) with ESMTP id 6B99DDC0388; Fri, 14 Feb 2014 21:06:22 +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: -25 X-BigFish: VPS-25(zzbb2dI98dI9371I542I1432I4015Idbb0izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL177df4h17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h945he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail204-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=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(189002)(199002)(51704005)(479174003)(164054003)(13464003)(24454002)(87936001)(81542001)(87266001)(2656002)(76786001)(15395725003)(74706001)(81342001)(19300405004)(76796001)(15202345003)(83072002)(69226001)(90146001)(74876001)(4396001)(92566001)(74366001)(36756003)(56816005)(92726001)(85852003)(95666001)(19580395003)(79102001)(95416001)(54316002)(19580405001)(56776001)(80976001)(80022001)(77982001)(59766001)(63696002)(65816001)(85306002)(54356001)(51856001)(53806001)(86362001)(76482001)(83506001)(15975445006)(93136001)(47736001)(94946001)(74662001)(31966008)(93516002)(77096001)(81816001)(49866001)(50986001)(47976001)(81686001)(46102001)(47446002)(66066001)(74502001)(94316002)(83322001); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:2CE1D194.AC22D6C2.61F5357B.8AADD1C9.202C9; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail204-tx2 (localhost.localdomain [127.0.0.1]) by mail204-tx2 (MessageSwitch) id 1392411980583091_17685; Fri, 14 Feb 2014 21:06:20 +0000 (UTC) Received: from TX2EHSMHS005.bigfish.com (unknown [10.9.14.242]) by mail204-tx2.bigfish.com (Postfix) with ESMTP id 8933720004C; Fri, 14 Feb 2014 21:06:20 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS005.bigfish.com (10.9.99.105) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 21:06:20 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Fri, 14 Feb 2014 21:06:15 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.0.873.15; Fri, 14 Feb 2014 21:06:14 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.51]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.51]) with mapi id 15.00.0873.009; Fri, 14 Feb 2014 21:06:14 +0000 From: Kent Watsen To: Rohit pobbathi , NetConf Thread-Topic: multiple top-level nodes? Thread-Index: AQHPKCBOsZBo5weJfEeV6u2IYLwFiZqyoQUwgAJMFgA= Date: Fri, 14 Feb 2014 21:06:13 +0000 Message-ID: References: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.com> In-Reply-To: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.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: 01221E3973 Content-Type: text/plain; charset="iso-2022-jp" Content-ID: <03559E28CF128F43B2825C3C419F90CA@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/Ai0O5-g3jGh1L-rLaNka27-vwOY Subject: Re: [Netconf] multiple top-level nodes? 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, 14 Feb 2014 21:06:27 -0000 Hi Andy, Rohit, Thanks for your replies, It's true that, in YANG, a module statement may have any number of container sub-statements --> a YANG module can define multiple top-level nodes. My question wasn't clear, but the example (below) shows each of the "top" nodes being in a different namespaces. Is this possible? I don't think it is because, with no filter, returns a configuration defined by just one YANG module, its default/native YANG module, and hence all the top-level nodes would be in the same namespace. Is that right? Thanks, Kent On 2/13/14 12:04 AM, "Rohit pobbathi" wrote: >Can with no filter return multiple top-level nodes? > >In my opinion, YES. >No filter query must be capable to return entire data model. >And to return entire data model, it is required to provide multiple >top-level nodes in reply. > >Rgds, >Rohit Pobbathi > >-----Original Message----- >From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen >Sent: 2014=1B$BG/=1B(B2=1B$B7n=1B(B12=1B$BF|=1B(B 23:59 >To: NetConf >Subject: [Netconf] multiple top-level nodes? > > >Can with no filter return multiple top-level nodes? > >All the examples in RFC 6241 show just a single top-level node being >returned. For instance: > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > ... > > > > > >But is this possible? > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > ... > > > ... > > > ... > > > > > > > > >For reference, section 6.4.1 (No Filter) says: > > Leaving out the filter on the operation returns the entire data > model. > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0"> > > > > > >And the YANG module has: > > output { > anyxml data { > description > "Copy of the source datastore subset that matched > the filter criteria (if any). An empty data container > indicates that the request did not produce any results."; > } > } > > >So I don't see it disallowed, but it also seems counter-intuitive... > >Thoughts? > >Thanks, >Kent > > > > >_______________________________________________ >Netconf mailing list >Netconf@ietf.org >https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Feb 14 13:21: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 52F041A02AF for ; Fri, 14 Feb 2014 13:21:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 T6vVanPuRNkn for ; Fri, 14 Feb 2014 13:21:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 37E2D1A0312 for ; Fri, 14 Feb 2014 13:21:41 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id E314B37C216; Fri, 14 Feb 2014 22:21:38 +0100 (CET) Date: Fri, 14 Feb 2014 22:21:38 +0100 (CET) Message-Id: <20140214.222138.118106053.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.com> 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/nYSrk8GuGMRmZL6JPf8S-n-MGhU Cc: netconf@ietf.org Subject: Re: [Netconf] multiple top-level nodes? 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, 14 Feb 2014 21:21:45 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gSGkgQW5keSwg Um9oaXQsDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgcmVwbGllcywNCj4gDQo+IEl0J3MgdHJ1ZSB0 aGF0LCBpbiBZQU5HLCBhIG1vZHVsZSBzdGF0ZW1lbnQgbWF5IGhhdmUgYW55IG51bWJlciBvZg0K PiBjb250YWluZXIgc3ViLXN0YXRlbWVudHMgLS0+IGEgWUFORyBtb2R1bGUgY2FuIGRlZmluZSBt dWx0aXBsZSB0b3AtbGV2ZWwNCj4gbm9kZXMuDQo+IA0KPiBNeSBxdWVzdGlvbiB3YXNuJ3QgY2xl YXIsIGJ1dCB0aGUgZXhhbXBsZSAoYmVsb3cpIHNob3dzIGVhY2ggb2YgdGhlICJ0b3AiDQo+IG5v ZGVzIGJlaW5nIGluIGEgZGlmZmVyZW50IG5hbWVzcGFjZXMuICBJcyB0aGlzIHBvc3NpYmxlPw0K DQpTdXJlLiAgSnVzdCBoYXZlIG11bHRpcGxlIFlBTkcgbW9kdWxlcywgZWFjaCB3aXRoIGl0cyBv d24gbmFtZXNwYWNlLA0KZWFjaCBkZWZpbmluZyBhIHRvcC1sZXZlbCBub2RlICJ0b3AiLg0KDQo+ IEkgZG9uJ3QgdGhpbmsgaXQgaXMgYmVjYXVzZSwgd2l0aCBubyBmaWx0ZXIsIDxnZXQtY29uZmln PiByZXR1cm5zIGENCj4gY29uZmlndXJhdGlvbiBkZWZpbmVkIGJ5IGp1c3Qgb25lIFlBTkcgbW9k dWxlDQoNCldpdGggbm8gZmlsdGVyLCA8Z2V0LWNvbmZpZz4gcmV0dXJucyBhbGwgbm9kZXMgZnJv bSBhbGwgWUFORyBtb2R1bGVzLg0KSWYgbm90LCBob3cgd291bGQgdGhlIHNlcnZlciBrbm93IF93 aGljaF8gWUFORyBtb2R1bGUgdG8gcmV0dXJuIChpZiBubw0KZmlsdGVyIGlzIHNwZWNpZmllZCk/ DQoNCj4gaXRzIGRlZmF1bHQvbmF0aXZlIFlBTkcNCj4gbW9kdWxlDQoNCkEgc2VydmVyIG9mdGVu ICh0eXBpY2FsbHkpIGltcGxlbWVudHMgbW9yZSB0aGFuIGEgc2luZ2xlIFlBTkcgbW9kdWxlLg0K DQooWWVzIEkga25vdyBKdW5vcyBoYXMgYSBzaW5nbGUgdG9wLWxldmVsIG5vZGU7IHRoaXMgd291 bGQgYmUNCnJlcHJlc2VudGVkIGluIGEgc2luZ2xlIFlBTkcgbW9kdWxlLi4uKQ0KDQoNCi9tYXJ0 aW4NCg0KDQo+ICwgYW5kIGhlbmNlIGFsbCB0aGUgdG9wLWxldmVsIG5vZGVzIHdvdWxkIGJlIGlu IHRoZSBzYW1lIG5hbWVzcGFjZS4NCj4gDQo+IElzIHRoYXQgcmlnaHQ/DQo+IA0KPiBUaGFua3Ms DQo+IEtlbnQNCj4gDQo+IA0KPiBPbiAyLzEzLzE0IDEyOjA0IEFNLCAiUm9oaXQgcG9iYmF0aGki IDxyb2hpdC5wb2JiYXRoaUBodWF3ZWkuY29tPiB3cm90ZToNCj4gDQo+ID5DYW4gPGdldC1jb25m aWc+IHdpdGggbm8gZmlsdGVyIHJldHVybiBtdWx0aXBsZSB0b3AtbGV2ZWwgbm9kZXM/DQo+ID4N Cj4gPkluIG15IG9waW5pb24sIFlFUy4NCj4gPk5vIGZpbHRlciBxdWVyeSBtdXN0IGJlIGNhcGFi bGUgdG8gcmV0dXJuIGVudGlyZSBkYXRhIG1vZGVsLg0KPiA+QW5kIHRvIHJldHVybiBlbnRpcmUg ZGF0YSBtb2RlbCwgaXQgaXMgcmVxdWlyZWQgdG8gcHJvdmlkZSBtdWx0aXBsZQ0KPiA+dG9wLWxl dmVsIG5vZGVzIGluIHJlcGx5Lg0KPiA+DQo+ID5SZ2RzLA0KPiA+Um9oaXQgUG9iYmF0aGkNCj4g Pg0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206IE5ldGNvbmYgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBLZW50IFdhdHNlbg0KPiA+ U2VudDogMjAxNOW5tDLmnIgxMuaXpSAyMzo1OQ0KPiA+VG86IE5ldENvbmYNCj4gPlN1YmplY3Q6 IFtOZXRjb25mXSBtdWx0aXBsZSB0b3AtbGV2ZWwgbm9kZXM/DQo+ID4NCj4gPg0KPiA+Q2FuIDxn ZXQtY29uZmlnPiB3aXRoIG5vIGZpbHRlciByZXR1cm4gbXVsdGlwbGUgdG9wLWxldmVsIG5vZGVz Pw0KPiA+DQo+ID5BbGwgdGhlIGV4YW1wbGVzIGluIFJGQyA2MjQxIHNob3cganVzdCBhIHNpbmds ZSB0b3AtbGV2ZWwgbm9kZSBiZWluZw0KPiA+cmV0dXJuZWQuICBGb3IgaW5zdGFuY2U6DQo+ID4N Cj4gPiAgICAgPHJwYyBtZXNzYWdlLWlkPSIxMDEiDQo+ID4gICAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpiYXNlOjEuMCI+DQo+ID4gICAgICAgPGdldC8+DQo+ ID4gICAgIDwvcnBjPg0KPiA+DQo+ID4gICAgIDxycGMtcmVwbHkgbWVzc2FnZS1pZD0iMTAxIg0K PiA+ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZTox LjAiPg0KPiA+ICAgICAgIDxkYXRhPg0KPiA+ICAgICAgICAgPHRvcCB4bWxucz0iaHR0cDovL2V4 YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnIj4NCj4gPiAgICAgICAgICAgLi4uDQo+ID4gICAg ICAgICA8L3RvcD4NCj4gPiAgICAgICA8L2RhdGE+DQo+ID4gICAgIDwvcnBjLXJlcGx5Pg0KPiA+ DQo+ID4NCj4gPkJ1dCBpcyB0aGlzIHBvc3NpYmxlPw0KPiA+DQo+ID4gICAgIDxycGMtcmVwbHkg bWVzc2FnZS1pZD0iMTAxIg0KPiA+ICAgICAgICAgIHhtbG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1s Om5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ICAgICAgIDxkYXRhPg0KPiA+ICAgICAgICAgPHRv cDEgeG1sbnM9Imh0dHA6Ly9leGFtcGxlLmNvbS9zY2hlbWEvMS4yL2NvbmZpZy0xIj4NCj4gPiAg ICAgICAgICAgLi4uDQo+ID4gICAgICAgICA8L3RvcDE+DQo+ID4gICAgICAgICA8dG9wMiB4bWxu cz0iaHR0cDovL2V4YW1wbGUuY29tL3NjaGVtYS8xLjIvY29uZmlnLTIiPg0KPiA+ICAgICAgICAg ICAuLi4NCj4gPiAgICAgICAgIDwvdG9wMj4NCj4gPiAgICAgICAgIDx0b3AzIHhtbG5zPSJodHRw Oi8vZXhhbXBsZS5jb20vc2NoZW1hLzEuMi9jb25maWctMyI+DQo+ID4gICAgICAgICAgIC4uLg0K PiA+ICAgICAgICAgPC90b3AzPg0KPiA+DQo+ID4NCj4gPiAgICAgICA8L2RhdGE+DQo+ID4gICAg IDwvcnBjLXJlcGx5Pg0KPiA+DQo+ID4NCj4gPg0KPiA+Rm9yIHJlZmVyZW5jZSwgc2VjdGlvbiA2 LjQuMSAoTm8gRmlsdGVyKSBzYXlzOg0KPiA+DQo+ID4gICBMZWF2aW5nIG91dCB0aGUgZmlsdGVy IG9uIHRoZSA8Z2V0PiBvcGVyYXRpb24gcmV0dXJucyB0aGUgZW50aXJlIGRhdGENCj4gPiAgIG1v ZGVsLg0KPiA+DQo+ID4gICAgIDxycGMgbWVzc2FnZS1pZD0iMTAxIg0KPiA+ICAgICAgICAgIHht bG5zPSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6YmFzZToxLjAiPg0KPiA+ICAgICAg IDxnZXQvPg0KPiA+ICAgICA8L3JwYz4NCj4gPg0KPiA+ICAgICA8cnBjLXJlcGx5IG1lc3NhZ2Ut aWQ9IjEwMSINCj4gPiAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRj b25mOmJhc2U6MS4wIj4NCj4gPiAgICAgICA8ZGF0YT4NCj4gPiAgICAgICAgIDwhLS0gLi4uIGVu dGlyZSBzZXQgb2YgZGF0YSByZXR1cm5lZCAuLi4gLS0+DQo+ID4gICAgICAgPC9kYXRhPg0KPiA+ ICAgICA8L3JwYy1yZXBseT4NCj4gPg0KPiA+QW5kIHRoZSBZQU5HIG1vZHVsZSBoYXM6DQo+ID4N Cj4gPiAgICAgIG91dHB1dCB7DQo+ID4gICAgICAgIGFueXhtbCBkYXRhIHsNCj4gPiAgICAgICAg ICBkZXNjcmlwdGlvbg0KPiA+ICAgICAgICAgICAgIkNvcHkgb2YgdGhlIHNvdXJjZSBkYXRhc3Rv cmUgc3Vic2V0IHRoYXQgbWF0Y2hlZA0KPiA+ICAgICAgICAgICAgIHRoZSBmaWx0ZXIgY3JpdGVy aWEgKGlmIGFueSkuICBBbiBlbXB0eSBkYXRhIGNvbnRhaW5lcg0KPiA+ICAgICAgICAgICAgIGlu ZGljYXRlcyB0aGF0IHRoZSByZXF1ZXN0IGRpZCBub3QgcHJvZHVjZSBhbnkgcmVzdWx0cy4iOw0K PiA+ICAgICAgICB9DQo+ID4gICAgICB9DQo+ID4NCj4gPg0KPiA+U28gSSBkb24ndCBzZWUgaXQg ZGlzYWxsb3dlZCwgYnV0IGl0IGFsc28gc2VlbXMgY291bnRlci1pbnR1aXRpdmUuLi4NCj4gPg0K PiA+VGhvdWdodHM/DQo+ID4NCj4gPlRoYW5rcywNCj4gPktlbnQNCj4gPg0KPiA+DQo+ID4NCj4g Pg0KPiA+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g Pk5ldGNvbmYgbWFpbGluZyBsaXN0DQo+ID5OZXRjb25mQGlldGYub3JnDQo+ID5odHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gDQo+IA0KPiBfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxpbmcg bGlzdA0KPiBOZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vbmV0Y29uZg0KPiANCg== From nobody Fri Feb 14 17:12: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 B601D1A002A for ; Fri, 14 Feb 2014 17:12:35 -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 sSaKwA-KSxIb for ; Fri, 14 Feb 2014 17:12:32 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe002.messaging.microsoft.com [207.46.163.25]) by ietfa.amsl.com (Postfix) with ESMTP id E56511A0021 for ; Fri, 14 Feb 2014 17:12:31 -0800 (PST) Received: from mail118-co9-R.bigfish.com (10.236.132.235) by CO9EHSOBE038.bigfish.com (10.236.130.101) with Microsoft SMTP Server id 14.1.225.22; Sat, 15 Feb 2014 01:12:30 +0000 Received: from mail118-co9 (localhost [127.0.0.1]) by mail118-co9-R.bigfish.com (Postfix) with ESMTP id 20FE4CC04BA; Sat, 15 Feb 2014 01:12:30 +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: -5 X-BigFish: VPS-5(zzbb2dI98dI9371I1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bhz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received-SPF: pass (mail118-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)(164054003)(24454002)(189002)(199002)(51704005)(377454003)(479174003)(63696002)(51856001)(53806001)(54356001)(85306002)(65816001)(54316002)(95416001)(80022001)(80976001)(56776001)(19580405001)(59766001)(77982001)(86362001)(74502001)(94316002)(46102001)(66066001)(47446002)(83322001)(77096001)(93516002)(74662001)(31966008)(47976001)(81686001)(81816001)(83506001)(76482001)(94946001)(47736001)(93136001)(49866001)(50986001)(83072002)(69226001)(76796001)(90146001)(92566001)(74366001)(4396001)(92726001)(74876001)(87266001)(81542001)(87936001)(76786001)(2656002)(81342001)(74706001)(85852003)(95666001)(79102001)(56816005)(36756003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB456.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:AFC4F58B.CC225113.82E0018B.44EDF0A1.201CB; InfoNoRecordsMX:1; A:1; LANG:en; Received: from mail118-co9 (localhost.localdomain [127.0.0.1]) by mail118-co9 (MessageSwitch) id 1392426748666363_24968; Sat, 15 Feb 2014 01:12:28 +0000 (UTC) Received: from CO9EHSMHS006.bigfish.com (unknown [10.236.132.232]) by mail118-co9.bigfish.com (Postfix) with ESMTP id 940A3C40068; Sat, 15 Feb 2014 01:12:28 +0000 (UTC) Received: from BL2PRD0510HT004.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; Sat, 15 Feb 2014 01:12:28 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Sat, 15 Feb 2014 01:12:27 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.0.873.15; Sat, 15 Feb 2014 01:12:23 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.51]) by BN1PR05MB456.namprd05.prod.outlook.com ([169.254.3.51]) with mapi id 15.00.0873.009; Sat, 15 Feb 2014 01:12:23 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] multiple top-level nodes? Thread-Index: AQHPKCBOsZBo5weJfEeV6u2IYLwFiZqyoQUwgAJMFgCAAFgiAP//7KMA Date: Sat, 15 Feb 2014 01:12:22 +0000 Message-ID: References: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.com> <20140214.222138.118106053.mbj@tail-f.com> In-Reply-To: <20140214.222138.118106053.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: 012349AD1C 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/KejGxrCMtNd93sHUIMi8ZN2oigg Cc: "netconf@ietf.org" Subject: Re: [Netconf] multiple top-level nodes? 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, 15 Feb 2014 01:12:36 -0000 On 2/14/14 4:21 PM, "Martin Bjorklund" wrote: >With no filter, returns all nodes from all YANG modules. >If not, how would the server know _which_ YANG module to return (if no >filter is specified)? Pulling all nodes from all modules could return lots of redundant data, as the server provides everything in its "native" configuration and parts-n-piences then again as to exports its data to a external format. I would think that the server would return just its "native" configuration and defer exporting to other formats until explicitly asked for it. >A server often (typically) implements more than a single YANG module. > >(Yes I know Junos has a single top-level node; this would be >represented in a single YANG module...) This surprises me. I thought the whole point of submodules was to enable the YANG for internal components to be assembled into a single top-level module having a single namespace. Why would a device not do this? Thanks, Kent From nobody Fri Feb 14 17:28: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 E9C2F1A0012 for ; Fri, 14 Feb 2014 17:28:38 -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 b3C7mdXXh9Sr for ; Fri, 14 Feb 2014 17:28:36 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id DE23A1A001A for ; Fri, 14 Feb 2014 17:28:34 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so19562625qaq.11 for ; Fri, 14 Feb 2014 17:28: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=e9Uc1VvHbP01UOgt8TpO6GL/Y73qYCCanjCkRyTjW7U=; b=VQHbrb93+GdBdlBNIp1v+i9TZMfVsymdy+EFJo8H1dgGZo1E8x+obCtAIhOACLTUhZ JY8papdtwvW3K6UXrmNXc07nGWbkYsxpQ5vBUT0giVLy26U9zsrEMYljulOKSf3YzC6P UIYfn7gPuzguIsS7TjrTO+C9Kayw6avdApGYNOHqjjNjTZV86dzARZ3m3kGHPM7uyV25 QkQs547hXmeoeH3BYsGIiQiFXncsza14KnuSqFeaeLcLNFUf0Np8eNWNSTViXVtQ2HZS O7XGk7AXobbIvL7XCn+RV3QA+VTaKETBCVC7/KkeG8RTkPQYOdNuiHO7nAP3FaF90pTU Y/FA== X-Gm-Message-State: ALoCoQkPQ8eV5IBuKaDOq6G2HK04i6v6MQKtShwPmGGaadn9ztNpGGaUuiyLMu/7OH1UWz9V2mHJ MIME-Version: 1.0 X-Received: by 10.140.48.172 with SMTP id o41mr17615035qga.16.1392427712669; Fri, 14 Feb 2014 17:28:32 -0800 (PST) Received: by 10.140.98.130 with HTTP; Fri, 14 Feb 2014 17:28:32 -0800 (PST) In-Reply-To: References: <2730B0D5F3302249A30EBF0DAE96D4CB04F09D1B@SZXEML561-MBS.china.huawei.com> <20140214.222138.118106053.mbj@tail-f.com> Date: Fri, 14 Feb 2014 17:28:32 -0800 Message-ID: From: Andy Bierman To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1135350030862d04f267d7dc Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/QeKSmhxKEVCFms60sN2Gzk88_AY Cc: "netconf@ietf.org" Subject: Re: [Netconf] multiple top-level nodes? 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, 15 Feb 2014 01:28:39 -0000 --001a1135350030862d04f267d7dc Content-Type: text/plain; charset=ISO-8859-1 On Fri, Feb 14, 2014 at 5:12 PM, Kent Watsen wrote: > > > On 2/14/14 4:21 PM, "Martin Bjorklund" wrote: > > >With no filter, returns all nodes from all YANG modules. > >If not, how would the server know _which_ YANG module to return (if no > >filter is specified)? > > Pulling all nodes from all modules could return lots of redundant data, as > the server provides everything in its "native" configuration and > parts-n-piences then again as to exports its data to a external format. I > would think that the server would return just its "native" configuration > and defer exporting to other formats until explicitly asked for it. > > There is no "native" encoding with NETCONF or YANG. There is only valid XML. The set of top-level YANG data nodes are the child nodes for the element returned for or . IMO this is straight-forward if you use YANG. If not then, the request still means "get everything" if no filter is present. > > >A server often (typically) implements more than a single YANG module. > > > >(Yes I know Junos has a single top-level node; this would be > >represented in a single YANG module...) > > > This surprises me. I thought the whole point of submodules was to enable > the YANG for internal components to be assembled into a single top-level > module having a single namespace. Why would a device not do this? > > You can use sub-modules within the 1 YANG module that represents the XML namespace for the data node . > > Thanks, > Kent > > Andy > > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1135350030862d04f267d7dc Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Feb 14, 2014 at 5:12 PM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:


On 2/14/14 4:21 PM, "Martin Bjorklund" <mbj@tail-f.com> wrote:

>With no filter, <get-config> returns all nodes from all YANG modu= les.
>If not, how would the server know _which_ YANG module to return (if no<= br> >filter is specified)?

Pulling all nodes from all modules could return lots of redundant data, as<= br> the server provides everything in its "native" configuration and<= br> parts-n-piences then again as to exports its data to a external format. =A0= I
would think that the server would return just its "native" config= uration
and defer exporting to other formats until explicitly asked for it.


There is no "native" encodin= g with NETCONF or YANG.
There is only valid XML. =A0The set of to= p-level YANG data nodes
are the child nodes for the <data> = element returned for <get>
or <get-config>. =A0IMO this is straight-forward if you use YANG= .
If not then, the request still means "get everything"= if no filter is present.

=A0

>A server often (typically) implements more than a single YANG module. >
>(Yes I know Junos has a single top-level node; this would be
>represented in a single YANG module...)


This surprises me. =A0I thought the whole point of submodules was to enable=
the YANG for internal components to be assembled into a single top-level module having a single namespace. =A0Why would a device not do this?



You can use sub-modules= within the 1 YANG module that represents
the XML namespace for t= he data node <top>.

=A0

Thanks,
Kent


Andy
=A0






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

--001a1135350030862d04f267d7dc-- From nobody Sun Feb 16 01:54: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 4FD0B1A03CC for ; Sun, 16 Feb 2014 01:54:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 yFovs0e266k7 for ; Sun, 16 Feb 2014 01:54:28 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 8B9E61A03C6 for ; Sun, 16 Feb 2014 01:54:28 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id 30E22240C1F1 for ; Sun, 16 Feb 2014 10:47:47 +0100 (CET) Date: Sun, 16 Feb 2014 10:47:46 +0100 (CET) Message-Id: <20140216.104746.335052742.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/fyPJjl2WckEButWJR8dIy_OGg1k Subject: [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: Sun, 16 Feb 2014 09:54:45 -0000 Hi, I have some high-level comments on this draft. I hope that this will become a WG document soon. o Section 2.5.1 starts to use the term "Application". This is a pretty overloaded term, and it is not defined in this document. "management application" "network manager" (used once in 6241) I think the only purpose this term serves, is to group a set of endpoints to call home to. o Section 2.5.2 talks about applications w/ multiple "servers". I'm not sure you mean "NETCONF client" either... o 2.5.5. IMO, the only way call home changes anything should be in setting up the transport. From there on, the responsibilities should be just as for normal connections. So I think the responsibility for keeping a connection alive, or closing it, should be on the NETCONF client. Hmm, now I realize that I don't understand what kind of keep alives you are talking about. Is this for the case that the transport provides a keep-alive feature? Or some (new) NETCONF keep-alice feature? o Data model structure Currently you have netconf +-- ssh | +-- call-home | +-- applications | +-- application +-- tls +-- call-home +-- applications +-- application Did you consider netconf +-- call-home +-- applications +-- application +-- ssh +-- tls This feels more natural to me. o You define two types of connections, "persistent" and "periodic". Here are some situations that I can think of, that I think should work with call-home: - the device starts up the first time - the device's ip address changed - the device has something to send - scheduled (e.g., once a day, preferrably during a time window at night) Note that in some use cases, call home will be used only to set up the initial connection (or if the ip address changes), but once that is done, the "management application" will initiate connections as normal. I am not sure any of these are handled by the current types. Also, what is the use case for a persistent connection? If the "management application" decides to close the session, why should the device reconnect immediately? /martin From nobody Tue Feb 18 16:31: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 CBB6D1A010A for ; Tue, 18 Feb 2014 16:31:33 -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 xmmwsA-QOr5f for ; Tue, 18 Feb 2014 16:31:31 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0A9B21A0013 for ; Tue, 18 Feb 2014 16:31:30 -0800 (PST) Received: from mail229-tx2-R.bigfish.com (10.9.14.240) by TX2EHSOBE013.bigfish.com (10.9.40.33) with Microsoft SMTP Server id 14.1.225.22; Wed, 19 Feb 2014 00:31:27 +0000 Received: from mail229-tx2 (localhost [127.0.0.1]) by mail229-tx2-R.bigfish.com (Postfix) with ESMTP id AED101C0118; Wed, 19 Feb 2014 00:31:27 +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: -3 X-BigFish: VPS-3(zz1432I4015I111aIzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail229-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(164054003)(189002)(199002)(43784003)(51704005)(80976001)(85306002)(47446002)(86362001)(49866001)(83506001)(87936001)(81542001)(31966008)(4396001)(36756003)(92726001)(74502001)(69226001)(81342001)(74662001)(74366001)(77982001)(46102001)(85852003)(51856001)(56816005)(90146001)(66066001)(92566001)(93136001)(80022001)(65816001)(79102001)(76796001)(59766001)(94316002)(63696002)(76482001)(77096001)(54316002)(76786001)(83322001)(47976001)(87266001)(93516002)(47736001)(50986001)(95666001)(83072002)(2656002)(54356001)(53806001)(95416001)(74706001)(56776001)(81816001)(94946001)(81686001)(74876001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.11; FPR:5EFFF2EA.A4F2D581.FFE22D7B.8CE8F141.20489; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail229-tx2 (localhost.localdomain [127.0.0.1]) by mail229-tx2 (MessageSwitch) id 1392769885807660_19556; Wed, 19 Feb 2014 00:31:25 +0000 (UTC) Received: from TX2EHSMHS010.bigfish.com (unknown [10.9.14.225]) by mail229-tx2.bigfish.com (Postfix) with ESMTP id A65E68E0052; Wed, 19 Feb 2014 00:31:25 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS010.bigfish.com (10.9.99.110) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 19 Feb 2014 00:31:25 +0000 Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Wed, 19 Feb 2014 00:31:24 +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.878.16; Wed, 19 Feb 2014 00:31:22 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.85]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.85]) with mapi id 15.00.0878.008; Wed, 19 Feb 2014 00:31:21 +0000 From: Kent Watsen To: Martin Bjorklund , "netconf@ietf.org" Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0ucc5p8aJ330OdaW2Ybc6v6pq7ahEA Date: Wed, 19 Feb 2014 00:31:20 +0000 Message-ID: References: <20140216.104746.335052742.mbj@tail-f.com> In-Reply-To: <20140216.104746.335052742.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: 012792EC17 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/_jphiIZUlbsaPi1tmKV-FpFIyBs 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: Wed, 19 Feb 2014 00:31:34 -0000 Hi Martin, Thank you for your comments. Below are my inlined responses. Thanks, Kent >o Section 2.5.1 starts to use the term "Application". This is a > pretty overloaded term, and it is not defined in this document. > > "management application" > "network manager" (used once in 6241) > > I think the only purpose this term serves, is to group a set of > endpoints to call home to. Are you recommending to replace "Application" with "Management Application" everywhere? One key thing to note is that the netconf-server YANG module has a list of "applications", which seems natural from a device configuration perspective... >o Section 2.5.2 talks about applications w/ multiple "servers". I'm > not sure you mean "NETCONF client" either... I am talking about the NETCONF client - that it could be composed of a cluster of systems (e.g., for HA reasons) and hence the device needs to have a list of call-home IP addresses for each configured "application", as it's called in the YANG module. From the NMS's POV, each system in its cluster is a "server", hence the term. Perhaps the term is not ideal, do you have a suggestion? >o 2.5.5. > > IMO, the only way call home changes anything should be in setting > up the transport. From there on, the responsibilities should be > just as for normal connections. So I think the responsibility for > keeping a connection alive, or closing it, should be on the NETCONF > client. > > Hmm, now I realize that I don't understand what kind of keep alives > you are talking about. Is this for the case that the transport > provides a keep-alive feature? Or some (new) NETCONF keep-alice > feature? Generally speaking, for persistent connections, keep-alives can be sent from either the connection-initiator or the connection-acceptor. A connection-initiator sends keep-alives so it can proactively initiate a reconnection. A connection-acceptor can send keep-alives too, but the most it can do is throw an alarm. In the case of normal-SSH, the NMS would be the connection-initiator. If the NMS chooses to have long-lived NETCONF sessions with devices, then the NMS (as the initiator) would send keep-alives. However, for reverse-SSH, the device is the initiator and so it is the device that needs to send the keep-alives. Makes sense? >o Data model structure > > Currently you have > > netconf > +-- ssh > | +-- call-home > | +-- applications > | +-- application > +-- tls > +-- call-home > +-- applications > +-- application > =20 > Did you consider > > netconf > +-- call-home > +-- applications > +-- application > +-- ssh > +-- tls > > This feels more natural to me. At first blush I'm inclined to agree, but I now want to see the whole module converted before committing to it.. >o You define two types of connections, "persistent" and "periodic". > > Here are some situations that I can think of, that I think should > work with call-home: > > - the device starts up the first time > - the device's ip address changed > - the device has something to send > - scheduled (e.g., once a day, preferrably during a time window > at night) > > Note that in some use cases, call home will be used only to set up > the initial connection (or if the ip address changes), but once > that is done, the "management application" will initiate > connections as normal. > > I am not sure any of these are handled by the current types. The term "periodic" is a bit imprecise - it should be "on-demand/periodic" or perhaps just "on-demand". In any case, the description in the current draft indicates that this setting means the device will connect-on-demand as well as periodically due to a reoccurring timeout expiration. Most of what you list falls into the "on-demand" case. The last item (scheduled) is questionable - at least I would think the NMS would prefer the device call-home periodically, even if it's just a no-op 99% of the time, as the NMS never knows if it might need to send something to the device sooner... > Also, what is the use case for a persistent connection? If the > "management application" decides to close the session, why should > the device reconnect immediately? It's not the management application closing the connection so much as maybe the machine it was running on crashed or the network broke. A device reconnection may be steered by a load-balancer to a "live" machine or, if another IP address, the connection may go to a "failover data-center" Thanks again, Kent From nobody Tue Feb 18 23:17: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 E2D931A0567 for ; Tue, 18 Feb 2014 23:17:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 cusJZTWX7DmB for ; Tue, 18 Feb 2014 23:17:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [109.74.15.94]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9711A0562 for ; Tue, 18 Feb 2014 23:17:35 -0800 (PST) Received: from localhost (unknown [193.12.32.88]) by mail.tail-f.com (Postfix) with ESMTPSA id C0A6437C234; Wed, 19 Feb 2014 08:17:30 +0100 (CET) Date: Wed, 19 Feb 2014 08:17:30 +0100 (CET) Message-Id: <20140219.081730.397755032.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: <20140216.104746.335052742.mbj@tail-f.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/_LyxT8Td01nd4l_JvtCzlOigo3s 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: Wed, 19 Feb 2014 07:17:38 -0000 Kent Watsen wrote: > > Hi Martin, > > Thank you for your comments. Below are my inlined responses. > > Thanks, > Kent > > > > >o Section 2.5.1 starts to use the term "Application". This is a > > pretty overloaded term, and it is not defined in this document. > > > > "management application" > > "network manager" (used once in 6241) > > > > I think the only purpose this term serves, is to group a set of > > endpoints to call home to. > > > Are you recommending to replace "Application" with "Management > Application" everywhere? "management application" is better than "application", but maybe there's some other better term. > One key thing to note is that the netconf-server YANG module has a list of > "applications", which seems natural from a device configuration > perspective... Yes. > >o Section 2.5.2 talks about applications w/ multiple "servers". I'm > > not sure you mean "NETCONF client" either... > > I am talking about the NETCONF client - that it could be composed of a > cluster of systems (e.g., for HA reasons) and hence the device needs to > have a list of call-home IP addresses for each configured "application", > as it's called in the YANG module. From the NMS's POV, each system in its > cluster is a "server", hence the term. Perhaps the term is not ideal, do > you have a suggestion? In the data model, maybe you can simply use "endpoint"; the management application has a set of endpoints that the NETCONF server can connect to. In the text maybe you can say that one logical management application is made up of a set of management application instances. > >o 2.5.5. > > > > IMO, the only way call home changes anything should be in setting > > up the transport. From there on, the responsibilities should be > > just as for normal connections. So I think the responsibility for > > keeping a connection alive, or closing it, should be on the NETCONF > > client. > > > > Hmm, now I realize that I don't understand what kind of keep alives > > you are talking about. Is this for the case that the transport > > provides a keep-alive feature? Or some (new) NETCONF keep-alice > > feature? > > > Generally speaking, for persistent connections, keep-alives can be sent > from either the connection-initiator or the connection-acceptor. A > connection-initiator sends keep-alives so it can proactively initiate a > reconnection. A connection-acceptor can send keep-alives too, but the > most it can do is throw an alarm. > > In the case of normal-SSH, the NMS would be the connection-initiator. If > the NMS chooses to have long-lived NETCONF sessions with devices, then the > NMS (as the initiator) would send keep-alives. However, for reverse-SSH, > the device is the initiator and so it is the device that needs to send the > keep-alives. Makes sense? 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? > >o You define two types of connections, "persistent" and "periodic". > > > > Here are some situations that I can think of, that I think should > > work with call-home: > > > > - the device starts up the first time > > - the device's ip address changed > > - the device has something to send > > - scheduled (e.g., once a day, preferrably during a time window > > at night) > > > > Note that in some use cases, call home will be used only to set up > > the initial connection (or if the ip address changes), but once > > that is done, the "management application" will initiate > > connections as normal. > > > > I am not sure any of these are handled by the current types. > > > The term "periodic" is a bit imprecise - it should be "on-demand/periodic" > or perhaps just "on-demand". In any case, the description in the current > draft indicates that this setting means the device will connect-on-demand > as well as periodically due to a reoccurring timeout expiration. I didn't the the "ondemand" part. > Most of what you list falls into the "on-demand" case. The last item > (scheduled) is questionable - at least I would think the NMS would prefer > the device call-home periodically, even if it's just a no-op 99% of the > time, as the NMS never knows if it might need to send something to the > device sooner... It all depends on the type and scale of the network... > > Also, what is the use case for a persistent connection? If the > > "management application" decides to close the session, why should > > the device reconnect immediately? > > It's not the management application closing the connection so much as > maybe the machine it was running on crashed or the network broke. A > device reconnection may be steered by a load-balancer to a "live" machine > or, if another IP address, the connection may go to a "failover > data-center" Ok, but then what happens if the management application properly closes the connection? /martin From nobody Fri Feb 21 09:26: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 4B5A31A0217; Fri, 21 Feb 2014 09:26:10 -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 lKNy3pAJ5gQt; Fri, 21 Feb 2014 09:26:07 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 83D031A0487; Fri, 21 Feb 2014 09:26:06 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.0.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140221172606.1843.68000.idtracker@ietfa.amsl.com> Date: Fri, 21 Feb 2014 09:26:06 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/LRtNYGKWRwkx0o2oEL1_XVMc_v8 Cc: netconf WG Subject: [Netconf] WG Action: Rechartered Network Configuration (netconf) 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: Fri, 21 Feb 2014 17:26:10 -0000 The Network Configuration (netconf) working group in the Operations and Management Area of the IETF has been rechartered. For additional information please contact the Area Directors or the WG Chairs. Network Configuration (netconf) ------------------------------------------------ Current Status: Active WG Chairs: Bert Wijnen Mehmet Ersue Assigned Area Director: Benoit Claise Mailing list Address: netconf@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/netconf Archive: http://www.ietf.org/mail-archive/web/netconf/ Charter: Configuration of networks of devices has become a critical requirement for operators in today's highly interconnected networks. Large and small operators alike have developed their own mechanisms or have used vendor specific mechanisms to transfer configuration data to and from a device and to examine device state information which may impact the configuration. Each of these mechanisms may be different in various aspects, such as session establishment, user authentication, configuration data exchange, and error responses. The NETCONF protocol (RFC 6241) provides mechanisms to install, manipulate, and delete the configuration of network devices. NETCONF is based on the secure transport (SSH is mandatory to implement while TLS is an optional transport) and uses an XML-based data representation. The NETCONF protocol is data modeling language independent, but YANG (RFC 6020) is the recommended NETCONF modeling language, which introduces advanced language features for configuration management. Based on the implementation, deployment experience and interoperability testing, the WG aims to produce a NETCONF status report in a later stage. The result may be clarifications for RFC6241 and RFC6242 and addressing any reported errata. In the current phase of NETCONF's incremental development the workgroup will focus on following items: 1. Develop the call home mechanism for the mandatory SSH binding (Reverse SSH) providing a server-initiated session establishment. 2. Develop a zero touch configuration document (a technique to establish a secure network management relationship between a newly delivered network device configured with just its factory default settings, and the Network Management System), specific to the NETCONF use case. 3. Advance NETCONF over TLS to be in-line with NETCONF 1.1 (i.e., update RFC 5539) and add the call home mechanism to provide a server-initiated session establishment. 4. Combine the server configuration data models from Reverse SSH and RFC5539bis drafts in a separate call home YANG module. 5. Develop RESTCONF, a protocol based on NETCONF in terms of capabilities, but over HTTP and with some REST characteristics, for accessing YANG data using the datastores defined in NETCONF. An "ordered edit list" approach is needed (the YANG patch) to provide client developers with a simpler edit request format that can be more efficient and also allow more precise client control of the transaction procedure than existing mechanisms. The YANG patch operation, based on the HTTP PATCH method, will be prepared in a separate draft. RESTCONF should not deviate from the NETCONF capabilities unless proper justification is provided and documented. The RESTCONF work will consider requirements suggested by the other working groups (for example I2RS). Milestones: Feb 2014 - Submit initial WG draft for call home YANG module as WG item Feb 2014 - Submit initial WG draft for zero touch configuration as WG item Feb 2014 - Submit initial WG drafts for RESTCONF and patch operation as WG items Apr 2014 - WGLC for Reverse SSH Apr 2014 - WGLC for NETCONF server configuration data model Apr 2014 - WGLC for zero touch configuration Apr 2014 - WGLC for call home YANG module Apr 2014 - WGLC for RFC5539bis May 2014 - Submit call home YANG module to AD/IESG for consideration as Proposed Standard May 2014 - Submit zero touch configuration to AD/IESG for consideration as Proposed Standard May 2014 - Submit RFC5539bis to AD/IESG for consideration as Proposed Standard May 2014 - Submit Reverse SSH to AD/IESG for consideration as Proposed Standard Jun 2014 - WGLC for RESTCONF and patch operation drafts Aug 2014 - Submit RESTCONF to AD/IESG for consideration as Proposed Standard From nobody Mon Feb 24 03:00: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 0FB501A06BD for ; Mon, 24 Feb 2014 03:00:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.184 X-Spam-Level: ** X-Spam-Status: No, score=2.184 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_SE=0.35, HOST_MISMATCH_NET=0.311, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, 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 rCBq7gMGOVir for ; Mon, 24 Feb 2014 03:00:00 -0800 (PST) Received: from sessmg20.mgmt.ericsson.se (sessmg20.ericsson.net [193.180.251.50]) by ietfa.amsl.com (Postfix) with ESMTP id 7A7011A003B for ; Mon, 24 Feb 2014 02:59:59 -0800 (PST) X-AuditID: c1b4fb32-b7f4c8e0000012f5-6c-530b262e4700 Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg20.mgmt.ericsson.se (Symantec Mail Security) with SMTP id CD.7B.04853.E262B035; Mon, 24 Feb 2014 11:59:58 +0100 (CET) Received: from [159.107.197.144] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.83) with Microsoft SMTP Server id 14.2.347.0; Mon, 24 Feb 2014 11:59:57 +0100 Message-ID: <530B262D.1050609@ericsson.com> Date: Mon, 24 Feb 2014 11:59:57 +0100 From: Balazs Lengyel 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@ietf.org" Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrGJMWRmVeSWpSXmKPExsUyM+Jvja6eGnewQfNLEYupm26zOjB6LFny kymAMYrLJiU1J7MstUjfLoEr49PDpIKlXBWTjxQ3MM7h6GLk5JAQMJE41tnABGGLSVy4t56t i5GLQ0jgBKPE5xuzoZy1jBJXp3YDORwcvALaEu0L80AaWARUJdZ13mcDsdkEjCSm9p9nAbFF BaIkfl5ZwA5i8woISpyc+QQsLiKgKdE46wMriC0soCUx6/ZFsMXMAroSF/5PYYGw5SW2v53D DGILCWhIPLzwl3UCI98sJKNmIWmZhaRlASPzKkbJ4tTi4tx0IwO93PTcEr3Uoszk4uL8PL3i 1E2MwLA6uOW30Q7Gk3vsDzFKc7AoifNeZ60JEhJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDY lCh47G71jij3em7Lj+8F5p1PdekRSZNuTXK4zHD0RdDchQvsMuKu3Z5z9fDGIC0JPoXMPVkf VEX+1R/uKTCa3rjWbX5T7b4PLz6/PPN2u/zJjS2sct629zn4dJ2MsiLOLLjzwlH255rbQplr D+xUCvbMZJjz7GJq55uMuafq/J3OyVf/W+2sxFKckWioxVxUnAgAgPtkTfkBAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-Yp9Gey8T8qSnnyNTsNIy8T4yiM Subject: [Netconf] Netconf/YANG Interop test details 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, 24 Feb 2014 11:00:01 -0000 Hello All,
Around IETF 85 there was a Netconf Interop test organized.
http://www.internetsociety.org/articles/successful-netconf-interoperability-testing-announced-ietf-85
We, Ericsson did not participate at the time, however we are getting interested in interop testing. Where can I get some details about the testing? What data models were used? What test cases were run? Was it automated or fully manual testing? Was the full test report prepared? Where do I find it? Was any further Interop testing done since then?
Any details would be interesting?
regards Balazs
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
System Manager
ECN: 831 7320                        Tel: +36-1-437-7320
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Mon Feb 24 05:06: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 6EA621A0640 for ; Mon, 24 Feb 2014 05:06:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.603 X-Spam-Level: X-Spam-Status: No, score=0.603 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 0wJvlgeQ1E6u for ; Mon, 24 Feb 2014 05:06:12 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 910B81A00B9 for ; Mon, 24 Feb 2014 05:06:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id C2026F9F; Mon, 24 Feb 2014 14:06:11 +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 N6B7ge_ms-Pi; Mon, 24 Feb 2014 14:06:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) by atlas3.jacobs-university.de (Postfix) with ESMTP; Mon, 24 Feb 2014 14:06:10 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AA9E20026; Mon, 24 Feb 2014 14:06:10 +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 dRrIC-UgnvXQ; Mon, 24 Feb 2014 14:06:10 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C806620015; Mon, 24 Feb 2014 14:06:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D88A52B74E0B; Mon, 24 Feb 2014 14:06:08 +0100 (CET) Date: Mon, 24 Feb 2014 14:06:08 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Message-ID: <20140224130608.GA417@elstar.local> Mail-Followup-To: Balazs Lengyel , "netconf@ietf.org" References: <530B262D.1050609@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <530B262D.1050609@ericsson.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/YzsG1sNEFc90QuJKKIgw8-x3JHY Cc: "netconf@ietf.org" Subject: Re: [Netconf] Netconf/YANG Interop test details 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, 24 Feb 2014 13:06:14 -0000 On Mon, Feb 24, 2014 at 11:59:57AM +0100, Balazs Lengyel wrote: > Hello All, > Around IETF 85 there was a Netconf Interop test organized. > [1]http://www.internetsociety.org/articles/successful-netconf-interoperability-testing-announced-ietf-85 > We, Ericsson did not participate at the time, however we are getting > interested in interop testing. Where can I get some details about the > testing? What data models were used? What test cases were run? Was it > automated or fully manual testing? People brought to the interop meeting whatever they had. Some had collections of test cases, some were testing more ad-hoc. Sometimes test cases were modified to work with whatever data models were available. As such, the testing was mostly manual. > Was the full test report prepared? Where do I find it? There is not a full test report and it surely would not be public since such testing events take place under an NDA. Bert Wijnen produced a highlevel writeup for the IETF Journal, which you might know: http://www.internetsociety.org/articles/successful-netconf-interoperability-testing-announced-ietf-85 /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 Feb 24 05:38:26 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 78DA81A086D for ; Mon, 24 Feb 2014 05:38:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.5 X-Spam-Level: X-Spam-Status: No, score=-0.5 tagged_above=-999 required=5 tests=[BAYES_05=-0.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 vV93bX-fnZxV for ; Mon, 24 Feb 2014 05:38:19 -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 5FC591A086E for ; Mon, 24 Feb 2014 05:38:19 -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 1WHvjU-0007q2-IH; Mon, 24 Feb 2014 14:38:18 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=Macintosh.local) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WHvjU-0008F2-Cx; Mon, 24 Feb 2014 14:38:08 +0100 Message-ID: <530B4B3C.3080708@bwijnen.net> Date: Mon, 24 Feb 2014 14:38:04 +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: Balazs Lengyel , "netconf@ietf.org" References: <530B262D.1050609@ericsson.com> <20140224130608.GA417@elstar.local> In-Reply-To: <20140224130608.GA417@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: 86ab03e524994f79ca2c75a176445dd47088b4fa92834a4df01f79c082a4a0b4 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/sLELlsOtz2Ttcdx8ky_l4ajxX5A Subject: Re: [Netconf] Netconf/YANG Interop test details 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, 24 Feb 2014 13:38:24 -0000 See at bottom On 24/02/14 14:06, Juergen Schoenwaelder wrote: > On Mon, Feb 24, 2014 at 11:59:57AM +0100, Balazs Lengyel wrote: >> Hello All, >> Around IETF 85 there was a Netconf Interop test organized. >> [1]http://www.internetsociety.org/articles/successful-netconf-interoperability-testing-announced-ietf-85 >> We, Ericsson did not participate at the time, however we are getting >> interested in interop testing. Where can I get some details about the >> testing? What data models were used? What test cases were run? Was it >> automated or fully manual testing? > > People brought to the interop meeting whatever they had. Some had > collections of test cases, some were testing more ad-hoc. Sometimes > test cases were modified to work with whatever data models were > available. As such, the testing was mostly manual. > >> Was the full test report prepared? Where do I find it? > > There is not a full test report and it surely would not be public > since such testing events take place under an NDA. Bert Wijnen > produced a highlevel writeup for the IETF Journal, which you might > know: > > http://www.internetsociety.org/articles/successful-netconf-interoperability-testing-announced-ietf-85 > Thanks for posting that link Juergen. We also presented the results summary at the NETCONF session at that IETF, See: http://www.ietf.org/proceedings/85/slides/slides-85-netconf-3.pdf Bert > /js > From nobody Mon Feb 24 08: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 477C51A018C for ; Mon, 24 Feb 2014 08:21:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jqZCrnqg9fUy for ; Mon, 24 Feb 2014 08:21:15 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe006.messaging.microsoft.com [213.199.154.209]) by ietfa.amsl.com (Postfix) with ESMTP id 4BE7A1A0112 for ; Mon, 24 Feb 2014 08:21:15 -0800 (PST) Received: from mail67-am1-R.bigfish.com (10.3.201.246) by AM1EHSOBE021.bigfish.com (10.3.207.143) with Microsoft SMTP Server id 14.1.225.22; Mon, 24 Feb 2014 16:21:13 +0000 Received: from mail67-am1 (localhost [127.0.0.1]) by mail67-am1-R.bigfish.com (Postfix) with ESMTP id E516D1E03A8; Mon, 24 Feb 2014 16:21:13 +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: -2 X-BigFish: VPS-2(zz98dI9371Ic85fhzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh18c673h1de097hz2fh109h2a8h839hbe3hd25he5bhf0ah1288h12a5h12bdh137ah139eh1441h1504h1537h162dh1631h1662h1758h1898h18e1h1946h19b5h19ceh1ad9h1b0ah1bceh224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1e23h1fe8h1ff5h2052h20b3h20f0h2218h2216h226dh22d0h24afh2327h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail67-am1: 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)(199002)(189002)(24454002)(377454003)(66066001)(62966002)(76482001)(50226001)(94946001)(53806001)(69226001)(92726001)(93136001)(81542001)(93916002)(47976001)(80022001)(89996001)(80976001)(46102001)(93516002)(54316002)(19580405001)(83322001)(65816001)(86362001)(56776001)(51856001)(94316002)(63696002)(49866001)(85852003)(76786001)(33656001)(83072002)(76796001)(92566001)(77096001)(74366001)(36756003)(90146001)(87286001)(87936001)(77156001)(56816005)(83716003)(87266001)(85306002)(74876001)(2656002)(74706001)(82746002)(88136002)(47736001)(4396001)(50986001)(59766001)(57306001)(95416001)(81342001)(77982001)(81816001)(81686001)(79102001)(16236675002)(74502001)(74662001)(47446002)(31966008)(95666003); DIR:OUT; SFP:1101; SCL:1; SRVR:BN1PR05MB456; H:BN1PR05MB424.namprd05.prod.outlook.com; CLIP:193.110.55.18; FPR:CEE6E325.AFC2E7E5.3DE2A365.4E20AD43.20178; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail67-am1 (localhost.localdomain [127.0.0.1]) by mail67-am1 (MessageSwitch) id 1393258871969167_22085; Mon, 24 Feb 2014 16:21:11 +0000 (UTC) Received: from AM1EHSMHS002.bigfish.com (unknown [10.3.201.247]) by mail67-am1.bigfish.com (Postfix) with ESMTP id E57F1E006D; Mon, 24 Feb 2014 16:21:11 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS002.bigfish.com (10.3.207.102) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Feb 2014 16:21:10 +0000 Received: from BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 24 Feb 2014 16:21:07 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB456.namprd05.prod.outlook.com (10.141.59.26) with Microsoft SMTP Server (TLS) id 15.0.883.10; Mon, 24 Feb 2014 16:21:06 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.245]) with mapi id 15.00.0883.010; Mon, 24 Feb 2014 16:21:06 +0000 From: Dean Bogdanovic To: Martin Bjorklund Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0t1SbKw4IGxUS3TOG4H5JDBpq7vdcAgABxewCACHOGgA== Date: Mon, 24 Feb 2014 16:21:05 +0000 Message-ID: <9285BE1A-181A-43CB-8E1A-DB1F564FA42A@juniper.net> References: <20140216.104746.335052742.mbj@tail-f.com> <20140219.081730.397755032.mbj@tail-f.com> In-Reply-To: <20140219.081730.397755032.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: [193.110.55.18] x-forefront-prvs: 0132C558ED Content-Type: multipart/alternative; boundary="_000_9285BE1A181A43CB8E1ADB1F564FA42Ajunipernet_" 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/66_j2v0St8ODeniZLZykxcJQVvw 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, 24 Feb 2014 16:21:22 -0000 --_000_9285BE1A181A43CB8E1ADB1F564FA42Ajunipernet_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 ar= e two config options ServerAliveInterval and ClientAliveInterval It sends (or doesn't send if disabled) periodically null packets. If you en= able it on the server, it will do it for all clients. So you could use SSH for keep alive, but it would be good to be precise whi= ch keep alive are to be used. Dean --_000_9285BE1A181A43CB8E1ADB1F564FA42Ajunipernet_ Content-Type: text/html; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable
On Feb 19, 2014, at 2:17 AM, Martin Bjorklund <mbj@tail-f.com> 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. The= re are two config options
ServerAliveInterval
and 
ClientAliveInterval

It sends (or doesn't send if disabled) periodically null packets. If y= ou enable it on the server, it will do it for all clients. 

So you could use SSH for keep alive, but it would be good to be precis= e which keep alive are to be used.

Dean


--_000_9285BE1A181A43CB8E1ADB1F564FA42Ajunipernet_-- From nobody Mon Feb 24 10:49: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 6B2C01A02BF for ; Mon, 24 Feb 2014 10:49:54 -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 WdRc54sMI3FY for ; Mon, 24 Feb 2014 10:49:52 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe006.messaging.microsoft.com [216.32.181.186]) by ietfa.amsl.com (Postfix) with ESMTP id 7751A1A02AE for ; Mon, 24 Feb 2014 10:49:46 -0800 (PST) Received: from mail64-ch1-R.bigfish.com (10.43.68.241) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Mon, 24 Feb 2014 18:49:45 +0000 Received: from mail64-ch1 (localhost [127.0.0.1]) by mail64-ch1-R.bigfish.com (Postfix) with ESMTP id 93D392001BA; Mon, 24 Feb 2014 18:49:45 +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: -3 X-BigFish: VPS-3(zz1432I111aI1447Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received-SPF: pass (mail64-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=BL2PRD0510HT001.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(51704005)(199002)(189002)(43784003)(51914003)(90146001)(56816005)(79102001)(83072002)(85852003)(4396001)(50986001)(47736001)(47976001)(77982001)(59766001)(49866001)(31966008)(74662001)(47446002)(93136001)(81542001)(93516002)(53806001)(86362001)(54356001)(51856001)(95416001)(46102001)(94946001)(94316002)(36756003)(92726001)(92566001)(54316002)(95666003)(69226001)(81342001)(76482001)(76786001)(76796001)(77096001)(83322001)(56776001)(74366001)(85306002)(66066001)(65816001)(80022001)(81816001)(81686001)(87936001)(83506001)(87266001)(74502001)(2656002)(63696002)(74876001)(80976001)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB711; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:7494F03D.9F205403.3CD6AB48.8CD7DA69.20150; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail64-ch1 (localhost.localdomain [127.0.0.1]) by mail64-ch1 (MessageSwitch) id 1393267783426687_16664; Mon, 24 Feb 2014 18:49:43 +0000 (UTC) Received: from CH1EHSMHS003.bigfish.com (snatpool3.int.messaging.microsoft.com [10.43.68.225]) by mail64-ch1.bigfish.com (Postfix) with ESMTP id 58F801A006F; Mon, 24 Feb 2014 18:49:43 +0000 (UTC) Received: from BL2PRD0510HT001.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS003.bigfish.com (10.43.70.3) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 24 Feb 2014 18:49:41 +0000 Received: from BY2PR05MB711.namprd05.prod.outlook.com (10.141.222.149) by BL2PRD0510HT001.namprd05.prod.outlook.com (10.255.100.36) with Microsoft SMTP Server (TLS) id 14.16.411.0; Mon, 24 Feb 2014 18:49:38 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB711.namprd05.prod.outlook.com (10.141.222.149) with Microsoft SMTP Server (TLS) id 15.0.883.10; Mon, 24 Feb 2014 18:49:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Mon, 24 Feb 2014 18:49:35 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] comments on draft-kwatsen-netconf-server-00 Thread-Index: AQHPKv0ucc5p8aJ330OdaW2Ybc6v6pq7ahEAgAkOewA= Date: Mon, 24 Feb 2014 18:49:35 +0000 Message-ID: References: <20140216.104746.335052742.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.13] x-forefront-prvs: 0132C558ED Content-Type: text/plain; charset="us-ascii" Content-ID: <5BFD94BB1D95DE429B5F27CED53BA758@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/gi98y3rC-grqwGI-lA5UricQR_g 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, 24 Feb 2014 18:49:54 -0000 Hi Martin, >>o Data model structure >> >> Did you consider >> >> netconf >> +-- call-home >> +-- applications >> +-- application >> +-- ssh >> +-- tls >> >> This feels more natural to me. A more complete view if the current tree is this: +--rw netconf +--rw ssh {ssh}? | +--rw listen {inbound-ssh}? | | ... | +--rw call-home {outbound-ssh}? | +--rw applications | +--rw application* [name] | ... +--rw tls {tls}? +--rw listen {inbound-tls}? | ... +--rw call-home {outbound-tls}? | +--rw applications | +--rw application* [name] | ... +--rw cert-maps {tls-map-certificates}? | ... +--rw psk-maps {tls-map-pre-shared-keys}? ... Reworking it to your suggestion, it looks like this: +--rw netconf +--rw listen | +-- rw ssh {inbound-ssh}? | | ... | +-- rw tls {inbound-tls}? | ... +--rw call-home | +--rw applications | +--rw application* [name] | +--rw ssh {outbound-ssh}? | +--rw tls {outbound-tls}? +--rw tls {tls}? +--rw cert-maps {tls-map-certificates}? | ... +--rw psk-maps {tls-map-pre-shared-keys}? ... I agree that this seems more natural - thanks for the suggestion! Now I need to updated the YANG module, but I'm glad to stabilize the config sooner rather than later... Thanks again, Kent From nobody Tue Feb 25 03:31:44 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 359141A000A for ; Tue, 25 Feb 2014 03:31:43 -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 q18pjlYx5GDP for ; Tue, 25 Feb 2014 03:31:40 -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 7CDFF1A000E for ; Tue, 25 Feb 2014 03:31:40 -0800 (PST) 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 1WIGEZ-00010c-VE for netconf@ietf.org; Tue, 25 Feb 2014 12:31:39 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest54.guestnet.ripe.net) by nene.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WIGEZ-0005yX-Rg for netconf@ietf.org; Tue, 25 Feb 2014 12:31:35 +0100 Message-ID: <530C7F17.1000500@bwijnen.net> Date: Tue, 25 Feb 2014 12:31:35 +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: <52DD39AC.5070303@cisco.com> In-Reply-To: <52DD39AC.5070303@cisco.com> X-Forwarded-Message-Id: <52DD39AC.5070303@cisco.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 -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-RIPE-Signature: 86ab03e524994f79ca2c75a176445dd464c1d293abfa83b795048a271a6e2644 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/-5WTXledK3jyl7qVqIYtUcLxjd4 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, 25 Feb 2014 11:31:43 -0000 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-port-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) > . > From nobody Tue Feb 25 07:41: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 139E11A0719 for ; Tue, 25 Feb 2014 07:41:59 -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 zBK5W2eWep9T for ; Tue, 25 Feb 2014 07:41:57 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe003.messaging.microsoft.com [213.199.154.206]) by ietfa.amsl.com (Postfix) with ESMTP id 965EE1A0713 for ; Tue, 25 Feb 2014 07:41:56 -0800 (PST) Received: from mail14-am1-R.bigfish.com (10.3.201.229) by AM1EHSOBE003.bigfish.com (10.3.204.23) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 15:41:55 +0000 Received: from mail14-am1 (localhost [127.0.0.1]) by mail14-am1-R.bigfish.com (Postfix) with ESMTP id 357973400B6; Tue, 25 Feb 2014 15:41:55 +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(zzbb2dI98dI9371I542I1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz8275ch1de098h1033IL17326ah8275bh8275dh1de097h186068hz2fh109h2a8h839h944he5bhf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) 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)(51704005)(377454003)(189002)(479174003)(13464003)(24454002)(199002)(81686001)(63696002)(76786001)(76796001)(15202345003)(79102001)(81816001)(51856001)(77096001)(92566001)(74366001)(15975445006)(77982001)(74706001)(74876001)(83072002)(85852003)(95666003)(36756003)(56816005)(90146001)(66066001)(92726001)(65816001)(80022001)(74662001)(95416001)(94946001)(85306002)(83506001)(86362001)(94316002)(69226001)(87266001)(19580405001)(19580395003)(76482001)(83322001)(54316002)(56776001)(59766001)(93136001)(74502001)(31966008)(93516002)(54356001)(53806001)(46102001)(80976001)(47446002)(50986001)(47976001)(47736001)(87936001)(81342001)(2656002)(81542001)(4396001)(49866001); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB770; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:CC19C135.8CE29186.CED7BD43.4EE8E179.2042F; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail14-am1 (localhost.localdomain [127.0.0.1]) by mail14-am1 (MessageSwitch) id 1393342911788034_31070; Tue, 25 Feb 2014 15:41:51 +0000 (UTC) Received: from AM1EHSMHS003.bigfish.com (unknown [10.3.201.245]) by mail14-am1.bigfish.com (Postfix) with ESMTP id 8691C200E6; Tue, 25 Feb 2014 15:41:51 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS003.bigfish.com (10.3.207.103) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 15:41:47 +0000 Received: from BLUPR05MB770.namprd05.prod.outlook.com (10.141.209.25) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 15:41:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB770.namprd05.prod.outlook.com (10.141.209.25) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 15:41:45 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 15:41:44 +0000 From: Kent Watsen To: "Bert Wijnen (IETF)" , netconf Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPFfAuSnx7mHcrKEuFWBsKlVApO5rGDmaA///yGgA= Date: Tue, 25 Feb 2014 15:41:43 +0000 Message-ID: References: <52DD39AC.5070303@cisco.com> <530C7F17.1000500@bwijnen.net> In-Reply-To: <530C7F17.1000500@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.13] x-forefront-prvs: 01334458E5 Content-Type: text/plain; charset="us-ascii" Content-ID: <09675CE0389E5B46805FD612E6F4ACFE@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/NlFyNxObbZopi1mRC0FUIaXPkYk 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, 25 Feb 2014 15:41:59 -0000 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 >> >>>=20 >>>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 > > From nobody Tue Feb 25 07:48: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 1840A1A07B2 for ; Tue, 25 Feb 2014 07:48:40 -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 ZHhua3wQhAtW for ; Tue, 25 Feb 2014 07:48:37 -0800 (PST) Received: from koko.ripe.net (koko.ripe.net [193.0.19.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB8E1A07C2 for ; Tue, 25 Feb 2014 07:48:37 -0800 (PST) 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 1WIKEw-00052J-Lq; Tue, 25 Feb 2014 16:48:35 +0100 Received: from kitten.ipv6.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest54.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1WIKEw-0000yZ-Hz; Tue, 25 Feb 2014 16:48:14 +0100 Message-ID: <530CBB3B.90804@bwijnen.net> Date: Tue, 25 Feb 2014 16:48:11 +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 , 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-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: 86ab03e524994f79ca2c75a176445dd429cd230e442373e93bdd0a7ae749c956 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1zaxa6gHzZV_-EwE3GqDGvcYs0E 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, 25 Feb 2014 15:48:40 -0000 On 25/02/14 16:41, 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. > I think that is fine. It was/is the principle that we CAN ask for a port number if we have consecensus that that is what we want. Bert > 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 >> >> > > > From nobody Tue Feb 25 09:06: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 7537A1A081D for ; Tue, 25 Feb 2014 09:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.448 X-Spam-Level: X-Spam-Status: No, score=-14.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 y6pViYUcPpRN for ; Tue, 25 Feb 2014 09:06:30 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id A6D5B1A0818 for ; Tue, 25 Feb 2014 09:06:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5914; q=dns/txt; s=iport; t=1393347987; x=1394557587; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=cML1IDYSTtd+5pFQjUR4EszhlouvHV+9ZjbmVmI8u+4=; b=gV+9SfP/xfAI/mC8AcBtiZla00iBZK3Ygu0xs8u8DyXyazd7YZd3M+UD hhX8B3oMEZJP5kfbFiaU3D8Na1JesnFXFOSRkaB7HuPX6fXlSqv+74KY7 YPxFoLdOnYvnZzfunRmdZm2dHHQNogUr8Xxg1ZyM4/GnvU730f49USsRf M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANHMDFOtJV2Z/2dsb2JhbABZgwY7V8ECT4EYFnSCJQEBAQQBAQEkRAMXBgEIEQMBAgFVCx0IAgQBEgkSh2oNxwIXjhMBARw1BQaEMgSJEI8kkieDLYFxOQ X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="306491512" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 25 Feb 2014 17:06:26 +0000 Received: from xhc-aln-x15.cisco.com (xhc-aln-x15.cisco.com [173.36.12.89]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s1PH6P7f002569 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 17:06:26 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x15.cisco.com ([173.36.12.89]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 11:06:25 -0600 From: "Reinaldo Penno (repenno)" To: "Bert Wijnen (IETF)" , Kent Watsen , netconf Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AA== Date: Tue, 25 Feb 2014 17:06:25 +0000 Message-ID: In-Reply-To: <530CBB3B.90804@bwijnen.net> 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.76.86] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <3A3C786BDF01254C85E761FDBEC92148@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/5r-aqaFyXd2Xi-2SWKrkEmH8zEw 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, 25 Feb 2014 17:06:39 -0000 I have some comments on this draft. Since the draft proposes a =B3cold=B2 reverse connection I was expecting so= me discussion on the traversal of middleboxes. Given folks that have been deploying NMS implicitly take for granted that connections are always inside->out, with the exception of SNMP traps, such a draft should assume some pitfalls and suggest ways around them. In the case of SNMP for example, the =B3solution=B2 is firewalls/NATs that implement SNMP ALG, but even then, a first inside->outside connection is expected. Some points to consider: - The NMS IP address downloaded from config server can not be behind a firewall unless there is some pinhole or traversal method the device can use - If NMS is behind a NAT, the IP:port should be the outside and stable. - In the worst case maybe configuration server (which theoretically could be reached by both parties) could d server as a relay. - If a NAT exists between NMS and device, one can not assume registered ports will be available. Therefore config server needs to be able to send port information. - Device should be prepared to check with configuration server is external port has changed due to state being removed on the NAT. Thanks, -RP On 2/25/14, 7:48 AM, "Bert Wijnen (IETF)" wrote: > > >On 25/02/14 16:41, 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. >> >I think that is fine. >It was/is the principle that we CAN ask for a port number if we have >consecensus >that that is what we want. > >Bert > >> 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: >>>=20 >>>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 >>>> >>>>> >>>>>=20 >>>>>http://www.iana.org/assignments/service-names-port-numbers/service-nam >>>>>es >>>>> -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 Tue Feb 25 10:44: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 83BC51A01A8 for ; Tue, 25 Feb 2014 10:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.497 X-Spam-Level: X-Spam-Status: No, score=-1.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_24=0.6, 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 QTeCGl7VtJLN for ; Tue, 25 Feb 2014 10:44:50 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id 4130A1A00F2 for ; Tue, 25 Feb 2014 10:44:49 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 3AAC3F82; Tue, 25 Feb 2014 19:44:48 +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 Iov8AuSt-JNg; Tue, 25 Feb 2014 19:44:45 +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, 25 Feb 2014 19:44:45 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB2AA20026; Tue, 25 Feb 2014 19:44:45 +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 VGgavhuxTHki; Tue, 25 Feb 2014 19:44:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7F4E820015; Tue, 25 Feb 2014 19:44:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 279DA2B7A59E; Tue, 25 Feb 2014 19:44:43 +0100 (CET) Date: Tue, 25 Feb 2014 19:44:42 +0100 From: Juergen Schoenwaelder To: "Reinaldo Penno (repenno)" Message-ID: <20140225184442.GB4469@elstar.local> Mail-Followup-To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , Kent Watsen , netconf References: <530CBB3B.90804@bwijnen.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/mEXsWkAdXutQMtV_uSNHPVzuOIM 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 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, 25 Feb 2014 18:44:53 -0000 Hi, I am somewhat confused. NETCONF so far assumes that the device can be contacted by opening a TCP connection from the NMS to the device. In case the NMS is behind a NAT, this works just fine. The call home work was started to deal with situations where the device is behind a NAT while the NMS is not. This is the problem we are solving. The case of both the device behind a NAT and the NMS behind a NAT is somewhat esoteric - does someone deploying networks really expect that this would work? Are you saying this problem needs to be solved based on real deployment experience where this happens? (I would assume in such a setup pretty much everything stops working.) /js On Tue, Feb 25, 2014 at 05:06:25PM +0000, Reinaldo Penno (repenno) wrote: > I have some comments on this draft. > > Since the draft proposes a ³cold² reverse connection I was expecting some > discussion on the traversal of middleboxes. Given folks that have been > deploying NMS implicitly take for granted that connections are always > inside->out, with the exception of SNMP traps, such a draft should assume > some pitfalls and suggest ways around them. In the case of SNMP for > example, the ³solution² is firewalls/NATs that implement SNMP ALG, but > even then, a first inside->outside connection is expected. > > Some points to consider: > > - The NMS IP address downloaded from config server can not be behind a > firewall unless there is some pinhole or traversal method the device can > use > - If NMS is behind a NAT, the IP:port should be the outside and stable. > - In the worst case maybe configuration server (which theoretically could > be reached by both parties) could d server as a relay. > - If a NAT exists between NMS and device, one can not assume registered > ports will be available. Therefore config server needs to be able to send > port information. > - Device should be prepared to check with configuration server is external > port has changed due to state being removed on the NAT. > > Thanks, > > -RP > > > On 2/25/14, 7:48 AM, "Bert Wijnen (IETF)" wrote: > > > > > > >On 25/02/14 16:41, 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. > >> > >I think that is fine. > >It was/is the principle that we CAN ask for a port number if we have > >consecensus > >that that is what we want. > > > >Bert > > > >> 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-nam > >>>>>es > >>>>> -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 > > _______________________________________________ > 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 Tue Feb 25 11:12: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 A4D161A045D for ; Tue, 25 Feb 2014 11:12:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.448 X-Spam-Level: X-Spam-Status: No, score=-14.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_24=0.6, 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 P3ENp1EptL6X for ; Tue, 25 Feb 2014 11:12:04 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0B71A0293 for ; Tue, 25 Feb 2014 11:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11220; q=dns/txt; s=iport; t=1393355520; x=1394565120; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=lVDgxItJk1pc1qI+VnC0NtZ/bsjWwaNsdmT9DjDaGzY=; b=G/kLDERvaGeYjOsFoqjjVAKXyWjXwCb1FSCnNsrANjmVBElFY3SId6Db bGsSe4MW+qr92BwgSlj69OUFvJcrOfmOLi6F4Vet/AgD4IGMG60ra4b2U yaG+djDFW9l7wc3vlnuaGUoyutyx3SBvCsafP9ftMRbpsGUw/Lr+QISzM k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhkFAJnqDFOtJXG8/2dsb2JhbABWA4MGO1eDA71+TxiBARZ0giUBAQEEAQEBJA03AwsMAgQBCA4CAQMBAgEEKAQZDAsdCAIEDgUJEodqDYp2m3cGoSIXBIEfjFwBARwNCwsQBwYLgliBTwSYNpIogy2BcTk X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="306421902" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-7.cisco.com with ESMTP; 25 Feb 2014 19:12:00 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PJBqdv021500 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 19:11:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 13:11:52 -0600 From: "Reinaldo Penno (repenno)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AIAAoZQA//+BeAA= Date: Tue, 25 Feb 2014 19:11:51 +0000 Message-ID: In-Reply-To: <20140225184442.GB4469@elstar.local> 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.74.73] Content-Type: text/plain; charset="euc-kr" Content-ID: <97E5E4040E122345B4464FB6783594E3@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/KgKcAD-3cHEdEW0uOSwPIFqlFYo 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: Tue, 25 Feb 2014 19:12:10 -0000 DQoNCk9uIDIvMjUvMTQsIDEwOjQ0IEFNLCAiSnVlcmdlbiBTY2hvZW53YWVsZGVyIg0KPGouc2No b2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQoNCj5IaSwNCj4NCj5JIGFt IHNvbWV3aGF0IGNvbmZ1c2VkLiBORVRDT05GIHNvIGZhciBhc3N1bWVzIHRoYXQgdGhlIGRldmlj ZSBjYW4gYmUNCj5jb250YWN0ZWQgYnkgb3BlbmluZyBhIFRDUCBjb25uZWN0aW9uIGZyb20gdGhl IE5NUyB0byB0aGUgZGV2aWNlLiBJbg0KPmNhc2UgdGhlIE5NUyBpcyBiZWhpbmQgYSBOQVQsIHRo aXMgd29ya3MganVzdCBmaW5lLg0KPlRoZSBjYWxsIGhvbWUgd29yaw0KPndhcyBzdGFydGVkIHRv IGRlYWwgd2l0aCBzaXR1YXRpb25zIHdoZXJlIHRoZSBkZXZpY2UgaXMgYmVoaW5kIGEgTkFUDQoN CkkgdGhpbmsgdGhlIHRlcm0gobBiZWhpbmShsSBpcyBjb25mdXNpbmcuIEmhr20gYXNzdW1pbmcg ZGV2aWNlIChyb3V0ZXIsDQpzd2l0Y2gsIGV0YykgaXMgaW4gdGhlIHB1YmxpYyBuZXR3b3JrIChv dXRzaWRlIHRoZSBOQVQpIGFuZCBOTVMgaXMgaW4gdGhlDQpwcml2YXRlIG5ldHdvcmsuIE5NUyBj YW4gb3BlbiBjb25uZWN0aW9ucyB0byBhbnkgZGV2aWNlIHdpdGhvdXQgcHJvYmxlbXMNCmJ1dCBy ZXZlcnNlIGNvbm5lY3Rpb25zIGFyZSBub3JtYWxseSBub3QgYWxsb3dlZC4NCg0KPndoaWxlIHRo ZSBOTVMgaXMgbm90LiBUaGlzIGlzIHRoZSBwcm9ibGVtIHdlIGFyZSBzb2x2aW5nLg0KDQpJZiB0 aGVyZSBpcyBhIE5BVCBpbiBiZXR3ZWVuLCB0aGUgZGV2aWNlIG91dHNpZGUgdGhlIE5BVCBub3Jt YWxseSB3b3VsZA0Kbm90IGJlIGFibGUgdG8gY29ubmVjdCB0byB0aGUgZGV2aWNlIGluc2lkZSB0 aGUgTkFUIChpbiB0aGUgcHJpdmF0ZQ0KbmV0d29yaykuIA0KDQoNCj4NCj5UaGUgY2FzZSBvZiBi b3RoIHRoZSBkZXZpY2UgYmVoaW5kIGEgTkFUIGFuZCB0aGUgTk1TIGJlaGluZCBhIE5BVCBpcw0K PnNvbWV3aGF0IGVzb3RlcmljIC0gZG9lcyBzb21lb25lIGRlcGxveWluZyBuZXR3b3JrcyByZWFs bHkgZXhwZWN0IHRoYXQNCj50aGlzIHdvdWxkIHdvcms/IEFyZSB5b3Ugc2F5aW5nIHRoaXMgcHJv YmxlbSBuZWVkcyB0byBiZSBzb2x2ZWQgYmFzZWQNCj5vbiByZWFsIGRlcGxveW1lbnQgZXhwZXJp ZW5jZSB3aGVyZSB0aGlzIGhhcHBlbnM/IChJIHdvdWxkIGFzc3VtZSBpbg0KPnN1Y2ggYSBzZXR1 cCBwcmV0dHkgbXVjaCBldmVyeXRoaW5nIHN0b3BzIHdvcmtpbmcuKQ0KDQo+DQo+L2pzDQo+DQo+ T24gVHVlLCBGZWIgMjUsIDIwMTQgYXQgMDU6MDY6MjVQTSArMDAwMCwgUmVpbmFsZG8gUGVubm8g KHJlcGVubm8pIHdyb3RlOg0KPj4gSSBoYXZlIHNvbWUgY29tbWVudHMgb24gdGhpcyBkcmFmdC4N Cj4+IA0KPj4gU2luY2UgdGhlIGRyYWZ0IHByb3Bvc2VzIGEgqfhjb2xkqfcgcmV2ZXJzZSBjb25u ZWN0aW9uIEkgd2FzIGV4cGVjdGluZw0KPj5zb21lDQo+PiBkaXNjdXNzaW9uIG9uIHRoZSB0cmF2 ZXJzYWwgb2YgbWlkZGxlYm94ZXMuIEdpdmVuIGZvbGtzIHRoYXQgaGF2ZSBiZWVuDQo+PiBkZXBs b3lpbmcgTk1TIGltcGxpY2l0bHkgdGFrZSBmb3IgZ3JhbnRlZCB0aGF0IGNvbm5lY3Rpb25zIGFy ZSBhbHdheXMNCj4+IGluc2lkZS0+b3V0LCB3aXRoIHRoZSBleGNlcHRpb24gb2YgU05NUCB0cmFw cywgc3VjaCBhIGRyYWZ0IHNob3VsZA0KPj5hc3N1bWUNCj4+IHNvbWUgcGl0ZmFsbHMgYW5kIHN1 Z2dlc3Qgd2F5cyBhcm91bmQgdGhlbS4gSW4gdGhlIGNhc2Ugb2YgU05NUCBmb3INCj4+IGV4YW1w bGUsIHRoZSCp+HNvbHV0aW9uqfcgaXMgZmlyZXdhbGxzL05BVHMgdGhhdCBpbXBsZW1lbnQgU05N UCBBTEcsIGJ1dA0KPj4gZXZlbiB0aGVuLCBhIGZpcnN0IGluc2lkZS0+b3V0c2lkZSBjb25uZWN0 aW9uIGlzIGV4cGVjdGVkLg0KPj4gDQo+PiBTb21lIHBvaW50cyB0byBjb25zaWRlcjoNCj4+IA0K Pj4gLSBUaGUgTk1TIElQIGFkZHJlc3MgZG93bmxvYWRlZCBmcm9tIGNvbmZpZyBzZXJ2ZXIgY2Fu IG5vdCBiZSBiZWhpbmQgYQ0KPj4gZmlyZXdhbGwgdW5sZXNzIHRoZXJlIGlzIHNvbWUgcGluaG9s ZSBvciB0cmF2ZXJzYWwgbWV0aG9kIHRoZSBkZXZpY2UgY2FuDQo+PiB1c2UNCj4+IC0gSWYgTk1T IGlzIGJlaGluZCBhIE5BVCwgdGhlIElQOnBvcnQgc2hvdWxkIGJlIHRoZSBvdXRzaWRlIGFuZCBz dGFibGUuDQo+PiAtIEluIHRoZSB3b3JzdCBjYXNlIG1heWJlIGNvbmZpZ3VyYXRpb24gc2VydmVy ICh3aGljaCB0aGVvcmV0aWNhbGx5DQo+PmNvdWxkDQo+PiBiZSByZWFjaGVkIGJ5IGJvdGggcGFy dGllcykgY291bGQgZCBzZXJ2ZXIgYXMgYSByZWxheS4NCj4+IC0gSWYgYSBOQVQgZXhpc3RzIGJl dHdlZW4gTk1TIGFuZCBkZXZpY2UsIG9uZSBjYW4gbm90IGFzc3VtZSByZWdpc3RlcmVkDQo+PiBw b3J0cyB3aWxsIGJlIGF2YWlsYWJsZS4gIFRoZXJlZm9yZSBjb25maWcgc2VydmVyIG5lZWRzIHRv IGJlIGFibGUgdG8NCj4+c2VuZA0KPj4gcG9ydCBpbmZvcm1hdGlvbi4NCj4+IC0gRGV2aWNlIHNo b3VsZCBiZSBwcmVwYXJlZCB0byBjaGVjayB3aXRoIGNvbmZpZ3VyYXRpb24gc2VydmVyIGlzDQo+ PmV4dGVybmFsDQo+PiBwb3J0IGhhcyBjaGFuZ2VkIGR1ZSB0byBzdGF0ZSBiZWluZyByZW1vdmVk IG9uIHRoZSBOQVQuDQo+PiANCj4+IFRoYW5rcywNCj4+IA0KPj4gLVJQDQo+PiANCj4+IA0KPj4g T24gMi8yNS8xNCwgNzo0OCBBTSwgIkJlcnQgV2lqbmVuIChJRVRGKSIgPGJlcnRpZXRmQGJ3aWpu ZW4ubmV0PiB3cm90ZToNCj4+IA0KPj4gPg0KPj4gPg0KPj4gPk9uIDI1LzAyLzE0IDE2OjQxLCBL ZW50IFdhdHNlbiB3cm90ZToNCj4+ID4+DQo+PiA+PiBJIGJlbGlldmUgdGhhdCBpcyB0aGUgY2Fz ZSBhcyB3ZWxsLCBidXQgbm90ZSB0aGF0IHdlIG5lZWQgdHdvIHBvcnQNCj4+ID4+IGFzc2lnbm1l bnRzIC0gb25lIGZvciByZXZlcnNlLVNTSCBhbmQgYW5vdGhlciBmb3IgcmV2ZXJzZS1UTFMuDQo+ PiA+Pg0KPj4gPkkgdGhpbmsgdGhhdCBpcyBmaW5lLg0KPj4gPkl0IHdhcy9pcyB0aGUgcHJpbmNp cGxlIHRoYXQgd2UgQ0FOIGFzayBmb3IgYSBwb3J0IG51bWJlciBpZiB3ZSBoYXZlDQo+PiA+Y29u c2VjZW5zdXMNCj4+ID50aGF0IHRoYXQgaXMgd2hhdCB3ZSB3YW50Lg0KPj4gPg0KPj4gPkJlcnQN Cj4+ID4NCj4+ID4+IENoZWVycyENCj4+ID4+IEtlbnQNCj4+ID4+DQo+PiA+Pg0KPj4gPj4NCj4+ ID4+IE9uIDIvMjUvMTQgNjozMSBBTSwgIkJlcnQgV2lqbmVuIChJRVRGKSIgPGJlcnRpZXRmQGJ3 aWpuZW4ubmV0Pg0KPj53cm90ZToNCj4+ID4+DQo+PiA+Pj4gTkVUQ09ORiBXRyBwYXJ0aWNpcGFu dHMsDQo+PiA+Pj4NCj4+ID4+PiB0aGVyZSBoYXMgYmVlbiBxdWl0ZSBzb21lIGRpc2N1c3Npb24g YWJvdXQgdGhpcyB0b3BpYyBvbiBvdXIgbWFpbGluZw0KPj4gPj4+bGlzdC4NCj4+ID4+PiBXZSAo V0cgY2hhaXJzKSBoYXZlIGFza2VkIG91ciBBRCAoQmVub2l0KSB0byBmb2xsb3cgdXAgaW4gdGhl IElFU0cuDQo+PiA+Pj4NCj4+ID4+PiBPdXIgY3VycmVudCB1bmRlcnN0YW5kaW5nIGlzIHRoYXQg aWYgb3VyIFdHIGhhcyBjb25zZW5zdXMgb24gYXNraW5nDQo+PmZvcg0KPj4gPj4+IGEgbmV3IHBv cnQsIHRoZW4gd2UgY2FuIGRvIHNvIGFuZCB3ZSBzaG91bGQgZ2V0IG9uZS4NCj4+ID4+Pg0KPj4g Pj4+IFdlIChXRyBjaGFpcnMpIGJlbGl2ZSB3ZSBoYXZlIChhdCBsZWFzdCByb3VnaCkgY29uc2Vu c3VzIG9uIHRoaXMNCj4+bWF0dGVyDQo+PiA+Pj4gYW5kIHNvIHdlIHdpbGwgYXNrIGZvciBhIG5l dyBwb3J0Lg0KPj4gPj4+DQo+PiA+Pj4gQmVydCBhbmQgTWVobWV0DQo+PiA+Pj4NCj4+ID4+Pg0K Pj4gPj4+IC0tLS0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0tLS0NCj4+ID4+PiBTdWJqZWN0 OiBSZTogTkVUQ09ORiBjYWxsIGhvbWUgYW5kIG5ldyBwb3J0IGFzc2lnbm1lbnQNCj4+ID4+PiBS ZXNlbnQtVG86IGJlcnRpZXRmQGJ3aWpuZW4ubmV0LCBtZWhtZXQuZXJzdWVAbnNuLmNvbSwsDQo+ PiA+Pj4gYmNsYWlzZUBjaXNjby5jb20sIGpvZWxqYUBib2d1cy5jb20sIGpqYWVnZ2xpQHp5bmdh LmNvbQ0KPj4gPj4+IERhdGU6IE1vbiwgMjAgSmFuIDIwMTQgMTU6NTg6NTIgKzAxMDANCj4+ID4+ PiBGcm9tOiBCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT4NCj4+ID4+PiBDQzogSm9l IFRvdWNoIDx0b3VjaEBpc2kuZWR1PiwNCj4+Im5ldGNvbmYtY2hhaXJzQHRvb2xzLmlldGYub3Jn Ig0KPj4gPj4+IDxuZXRjb25mLWNoYWlyc0B0b29scy5pZXRmLm9yZz4sICAgICAgICAiUm9tYXNj YW51LCBEYW4gKERhbikiDQo+PiA+Pj4gPGRyb21hc2NhQGF2YXlhLmNvbT4sICAgICAgICBMZW1v biBUZWQgPHRlZC5sZW1vbkBub21pbnVtLmNvbT4sDQo+PiA+Pj4gIm9wcy1hZHNAdG9vbHMuaWV0 Zi5vcmciIDxvcHMtYWRzQHRvb2xzLmlldGYub3JnPiwNCj4+ID4+PiBLZW50IFdhdHNlbiA8a3dh dHNlbkBqdW5pcGVyLm5ldD4NCj4+ID4+Pg0KPj4gPj4+IERlYXIgYWxsLA0KPj4gPj4+DQo+PiA+ Pj4gV2UgZGlzY3Vzc2VkIHRoZSBpc3N1ZSBvZiBwb3RlbnRpYWxseSBhbGxvY2F0aW5nIGEgbmV3 IHBvcnQgZm9yIHRoZQ0KPj4gPj4+IE5FVENPTkYgY2FsbCBob21lIGR1cmluZyBvdXIgaW5mb3Jt YWwgdGVsZWNoYXQgbGFzdCB3ZWVrLg0KPj4gPj4+IFBlcnNvbmFsbHksIEkgd2FudGVkIGEgY29u ZmlybWF0aW9uIG9uIHRoZSBwcm9jZWR1cmUuDQo+PiA+Pj4gTWF0ZXJpYWw6DQo+PiA+Pj4gDQo+ PiANCj4+Pj4+aHR0cDovL3d3dy5pYW5hLm9yZy9hc3NpZ25tZW50cy9zZXJ2aWNlLW5hbWVzLXBv cnQtbnVtYmVycy9zZXJ2aWNlLW5hbQ0KPj4+Pj5lcw0KPj4gPj4+LXANCj4+ID4+PiBvcnQtbnVt YmVycy54aHRtbA0KPj4gPj4+IGFuDQo+PiA+Pj4gICAgICBSRkMgNjMzNQ0KPj4gPj4+DQo+PiA+ Pj4gQm90dG9tIGxpbmU6IFRoZSByZXZpZXcgb2YgdGhlIHBvcnQgYXNzaWdubWVudCB2aWEgSUVU RiBzdGFuZGFyZHMNCj4+ID4+PiAoY29uc2Vuc3VzIGJhc2VkKSBkb2VzIG5vdCBnbyB0byB0aGUg cG9ydCByZXZpZXcNCj4+ID4+Pg0KPj4gPj4+IFRoZXJlIGlzIHN0cm9uZyBjb25zZW5zdXMgdG8g YWxsb2NhdGUgdGhpcyBwb3J0IGluIHRoZSBORVRDT05GIFdHLg0KPj4gPj4+IC0gaHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy84OC9taW51dGVzL21pbnV0ZXMtODgtbmV0Y29uZg0KPj4g Pj4+ICAgIDMwIGluIGZhdm9yLCAwIGFnYWluc3QNCj4+ID4+PiAtIGRvdWJsZWNoZWNrZWQgb24g dGhlIG1haWxpbmcgbGlzdA0KPj4gPj4+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZl L3dlYi9uZXRjb25mL2N1cnJlbnQvbXNnMDg0NDUuaHRtbA0KPj4gPj4+DQo+PiA+Pj4gU28gd2Un cmUgZ29vZCBoZXJlLCBsZXQncyBwcm9jZWVkIHdpdGggdGhlIG5ldyBwb3J0IGRlc2lnbg0KPj4g Pj4+DQo+PiA+Pj4gUmVnYXJkcywgQmVub2l0DQo+PiA+Pj4NCj4+ID4+Pj4gSGksIEJlbm9pdCwN Cj4+ID4+Pj4NCj4+ID4+Pj4gT24gMTEvNC8yMDEzIDEwOjMwIEFNLCBCZW5vaXQgQ2xhaXNlIHdy b3RlOg0KPj4gPj4+Pj4gSGkgSm9lLA0KPj4gPj4+Pj4NCj4+ID4+Pj4+IFJlZ2FyZGluZyB0aGUg Ik5FVENPTkYgY2FsbCBob21lIGFuZCBuZXcgcG9ydCBhc3NpZ25tZW50Ig0KPj5kaXNjdXNzaW9u DQo+PiA+Pj4+Pm9uDQo+PiA+Pj4+PiB0aGUgTkVUQ09ORiBtYWlsZXIsIEknbSB3b25kZXJpbmcg aWYgeW91ciBjb21tZW50cyBhcmUgbWFkZSBhcyB0aGUNCj4+ID4+Pj4+cG9ydA0KPj4gPj4+Pj4g ZXhwZXJ0IHJldmlld2VyIG9yIGFzIGEgY29udHJpYnV0b3IuDQo+PiA+Pj4+DQo+PiA+Pj4+IFRo ZSBwb3J0cyByZXZpZXcgdGVhbSBkb2Vzbid0IHBhcnRpY2lwYXRlIGluIHRoYXQgcm9sZSBvbiB0 aGVzZQ0KPj4gPj4+PiBkaXNjdXNzaW9ucyBvbiB0aGUgbGlzdHM7IHdlIHJldmlldyByZXF1ZXN0 cyBhbmQgcmVwb3J0IGRpcmVjdGx5IHRvDQo+PiA+Pj4+IElBTkEuIFNvIEknbSBzcGVha2luZyBh cyBhIGNvbnRyaWJ1dG9yLCBidXQgaXQncyB3aXRoIHRoZSBwb3J0cw0KPj5yZXZpZXcNCj4+ID4+ Pj4gaW4gdGhlIGJhY2sgb2YgbXkgbWluZC4NCj4+ID4+Pj4NCj4+ID4+Pj4+IEluIHRoZSBORVRD T05GIFdHLCB0aGVyZSBpcyBzdHJvbmcgY29uc2Vuc3VzIHRoYXQgdGhlIG5ldyBwb3J0IGlzDQo+ PnRoZQ0KPj4gPj4+Pj4gcHJlZmVycmVkIHdheS4gV2UgY2hlY2tlZCB0aGF0IHRvZGF5OiBieSBh IHNob3cgb2YgaGFuZCwgZXZlcnlib2R5DQo+PiA+Pj4+PiB3YW50ZWQgYSBuZXcgcG9ydC4NCj4+ ID4+Pj4NCj4+ID4+Pj4gRXZlcnlvbmUgYWx3YXlzIGRvZXMuDQo+PiA+Pj4+DQo+PiA+Pj4+PiBJ IHdhbnQgdG8gdW5kZXJzdGFuZCBpZiB0aGVyZSBpcyBhIG1ham9yIGZsYXcgaW4gcmVxdWVzdGlu ZyB0aGlzDQo+PiA+Pj4+PnBvcnQuDQo+PiA+Pj4+DQo+PiA+Pj4+IFRoZXJlJ3Mgb2Z0ZW4gYSBj YXNlIHdoZXJlIHRoZSBpbmRpdmlkdWFsIHJlcXVlc3QgbWFrZXMgc2Vuc2UsIGJ1dA0KPj5pbg0K Pj4gPj4+PiB0aGUgYnJvYWRlciBjb250ZXh0IG9mICJ0cmFnZWR5IG9mIHRoZSBjb21tb25zIiBp dCBkb2Vzbid0LiBUaGF0J3MNCj4+bXkNCj4+ID4+Pj4gaW1wcmVzc2lvbiBoZXJlLiBUaGVyZSBz aG91bGQgYmUgb3RoZXIgd2F5cyB0byBhY2NvbXBsaXNoIHRoaXMgLQ0KPj50aGUNCj4+ID4+Pj4g U1lOIGF0dGVtcHQgSSByZWNlbnRseSBzYXcgbG9va2VkIGxpa2UgYSBnb29kIGFsdGVybmF0aXZl IHRoYXQNCj4+d291bGQNCj4+ID4+Pj4gc2NhbGUgdG8gb3RoZXIgYXNzaWdubWVudHMsIGUuZy4N Cj4+ID4+Pj4NCj4+ID4+Pj4+IE5vdGU6IEkgY29udGFjdGVkIGl0IHlvdSBkaXJlY3RseSwgYmVj YXVzZSBJJ20gbm90IHN1cmUgaG93IHRvDQo+PnJlYWNoDQo+PiA+Pj4+PiBhbGwNCj4+ID4+Pj4+ IHRoZSBleHBlcnQgcmV2aWV3ZXJzIGF0IHRoZSBzYW1lIHRpbWUuDQo+PiA+Pj4+DQo+PiA+Pj4+ IFRoZXJlJ3Mgbm8gb2ZmaWNpYWwgd2F5IHRvIGRvIHRoYXQuIFdlIHJlc3BvbmQgdG8gcmVxdWVz dHMgZm9yDQo+PnJldmlld3MNCj4+ID4+Pj4gZnJvbSBJQU5BLCBhbmQgcmVwb3J0IGJhY2sgdG8g SUFOQSBkaXJlY3RseS4gVGhlcmUncyBubyAib2ZmaWNpYWwiDQo+PiA+Pj4+IHJvbGUgZm9yIHVz IGluIHRoZSBJRVRGIGRpcmVjdGx5Lg0KPj4gPj4+Pg0KPj4gPj4+PiBKb2UNCj4+ID4+Pj4NCj4+ ID4+Pj4+DQo+PiA+Pj4+PiANCj4+IA0KPj4+Pj4+Pmh0dHA6Ly93d3cuaWFuYS5vcmcvYXNzaWdu bWVudHMvc2VydmljZS1uYW1lcy1wb3J0LW51bWJlcnMvc2VydmljZS1uDQo+Pj4+Pj4+YW0NCj4+ ID4+Pj4+ZXMNCj4+ID4+Pj4+IC1wb3J0LW51bWJlcnMueGh0bWwNCj4+ID4+Pj4+DQo+PiA+Pj4+ PiBpcyBub3QgZXhwbGljaXQNCj4+ID4+Pj4+DQo+PiA+Pj4+PiBSZWdhcmRzLCBCZW5vaXQgKE9Q UyBBRCkNCj4+ID4+Pj4gLg0KPj4gPj4+Pg0KPj4gPj4+DQo+PiA+Pj4NCj4+ID4+Pg0KPj4gPj4+ DQo+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+ID4+PiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPj4gPj4+IE5ldGNvbmZAaWV0Zi5vcmcNCj4+ ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4+ID4+ Pg0KPj4gPj4+DQo+PiA+Pg0KPj4gPj4NCj4+ID4+DQo+PiA+DQo+PiA+X19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ID5OZXRjb25mIG1haWxpbmcgbGlz dA0KPj4gPk5ldGNvbmZAaWV0Zi5vcmcNCj4+ID5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL25ldGNvbmYNCj4+IA0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4+IE5ldGNvbmYgbWFpbGluZyBsaXN0DQo+PiBOZXRjb25mQGll dGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYN Cj4NCj4tLSANCj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJz aXR5IEJyZW1lbiBnR21iSA0KPlBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVz IFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJtYW55DQo+RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMg ICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+DQoNCg== From nobody Tue Feb 25 11:27: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 A7DDB1A021D for ; Tue, 25 Feb 2014 11:27:29 -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 ry4Sx5vq5aQA for ; Tue, 25 Feb 2014 11:27:22 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id D3EB51A01DB for ; Tue, 25 Feb 2014 11:27:15 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EE0E0F71; Tue, 25 Feb 2014 20:27: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 iy7hSczWVaSu; Tue, 25 Feb 2014 20:27:12 +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, 25 Feb 2014 20:27:12 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 943F220027; Tue, 25 Feb 2014 20:27:12 +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 LGcuROvgfTef; Tue, 25 Feb 2014 20:27: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 1008E20015; Tue, 25 Feb 2014 20:27:12 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C0D472B7A829; Tue, 25 Feb 2014 20:27:10 +0100 (CET) Date: Tue, 25 Feb 2014 20:27:10 +0100 From: Juergen Schoenwaelder To: "Reinaldo Penno (repenno)" Message-ID: <20140225192710.GE4469@elstar.local> Mail-Followup-To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , Kent Watsen , netconf References: <20140225184442.GB4469@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/43u1QBqGG25Bb95sosXu3jC6QxQ 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 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, 25 Feb 2014 19:27:30 -0000 On Tue, Feb 25, 2014 at 07:11:51PM +0000, Reinaldo Penno (repenno) wrote: > > > On 2/25/14, 10:44 AM, "Juergen Schoenwaelder" > wrote: > > >Hi, > > > >I am somewhat confused. NETCONF so far assumes that the device can be > >contacted by opening a TCP connection from the NMS to the device. In > >case the NMS is behind a NAT, this works just fine. > >The call home work > >was started to deal with situations where the device is behind a NAT > > I think the term “behind†is confusing. I’m assuming device (router, > switch, etc) is in the public network (outside the NAT) and NMS is in the > private network. NMS can open connections to any device without problems > but reverse connections are normally not allowed. In this case, standard NETCONF transports just work fine and you do not need the call-home mechanism. The call-home work is solving a different problem (where the device is in a private network and hence the NMS can't connect to the device). See for example section 2.1 of draft-ietf-netconf-rfc5539bis-05.txt for a more detailed explanation. /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 Feb 25 11:41:09 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 B68B51A0246 for ; Tue, 25 Feb 2014 11:41:01 -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 JNGtvvcmLIiZ for ; Tue, 25 Feb 2014 11:40:56 -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 89E781A0254 for ; Tue, 25 Feb 2014 11:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2156; q=dns/txt; s=iport; t=1393357252; x=1394566852; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=1CZdN0uo5xwhQbmHtdHH8v5RBYY9dn4D7DbGddCVtcU=; b=gcTscp7ohWtXsOIVQULW4VsXKohC+7/YJsUqmzgY1vXW3voSTF/BJD3v ov3NIlxl7dAS0H0uBugtR4caFQBO3271iL6Ddg0QWbs8FASvpekmbiWYl mUNnEvQC+y6HpaCkv3l14xJ8n9sZPNtiB4a0XzX8eZOiciPEjvnYs7OAe I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhQFAE3xDFOtJV2a/2dsb2JhbABWA4MGO1fBUIEZFnSCJQEBAQR5DgQBCA4CCEkXJQIEDgWIBQ3IIBcEjhkNFhAHEYQnBIkRjyWBMpB2gy2CKg X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="23101693" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by alln-iport-1.cisco.com with ESMTP; 25 Feb 2014 19:40:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1PJeqP2002038 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 19:40:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 13:40:51 -0600 From: "Reinaldo Penno (repenno)" To: Juergen Schoenwaelder Thread-Topic: [Netconf] NETCONF call home and new port assignment Thread-Index: AQHPMh0sIMAEhPViDUCrzWQVqmFe/JrGgIWAgAABzoD//4++AIAAoZQA//+BeACAAIplAP//fbMA Date: Tue, 25 Feb 2014 19:40:51 +0000 Message-ID: In-Reply-To: <20140225192710.GE4469@elstar.local> 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.74.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <626BE07E03F31F45B1D5967D2EBF0B94@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/RV2khLlpBWEX19k307Eai034CxQ 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: Tue, 25 Feb 2014 19:41:02 -0000 On 2/25/14, 11:27 AM, "Juergen Schoenwaelder" wrote: >On Tue, Feb 25, 2014 at 07:11:51PM +0000, Reinaldo Penno (repenno) wrote: >>=20 >>=20 >> On 2/25/14, 10:44 AM, "Juergen Schoenwaelder" >> wrote: >>=20 >> >Hi, >> > >> >I am somewhat confused. NETCONF so far assumes that the device can be >> >contacted by opening a TCP connection from the NMS to the device. In >> >case the NMS is behind a NAT, this works just fine. >> >The call home work >> >was started to deal with situations where the device is behind a NAT >>=20 >> I think the term =B3behind=B2 is confusing. I=B9m assuming device (route= r, >> switch, etc) is in the public network (outside the NAT) and NMS is in >>the >> private network. NMS can open connections to any device without problems >> but reverse connections are normally not allowed. > >In this case, standard NETCONF transports just work fine and you do >not need the call-home mechanism. 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. A new device is installed on the network, all it needs is to download a configuration file from a server and then connect to NMS (Netconf client). Netconf client does not need to be configured with IP address of every new device that comes in the network. My expectation seems to match those of the draft which goes into the benefits of such mechanism and problems it solves. > >The call-home work is solving a different problem (where the device is >in a private network and hence the NMS can't connect to the device). >See for example section 2.1 of draft-ietf-netconf-rfc5539bis-05.txt >for a more detailed explanation. > >/js=20 > >--=20 >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 Feb 25 11:41: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 6266C1A063A for ; Tue, 25 Feb 2014 11:41:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.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, 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 UaG_RF2OLSkT for ; Tue, 25 Feb 2014 11:41:20 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id AA9241A029D for ; Tue, 25 Feb 2014 11:41:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8652; q=dns/txt; s=iport; t=1393357280; x=1394566880; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YuVy88e6CFKeNH2M+5I8v//cQQ+YFANEhKT6Umgly7k=; b=ld0emeWnBjVC+BqzfNEGVYIIYX14Q7Skf4/WCbkX7Vv6qmXq7OZ6S8Y+ Zc+rhhlQt1OSx7POPk+Qrdn7aboJ8koE/abWYJNlszfXg67I6hgi/b15p Add7fn6lE+EV8drHqA1ZPFH8cV6p2NRt/ZlzLVod4c+qPjL2+WGpkVdyi Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYGABfxDFOtJV2c/2dsb2JhbABZgkREOE8GtHiIU4EaFgF0g30BAQEEAQEBaxsCAQgRAwECKAcnCxQJCAIEARIJh3sIBb91F44mWw0KAQaEMASYFoEwiy2FN4MrgXE5 X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208,217";a="303404739" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-9.cisco.com with ESMTP; 25 Feb 2014 19:41:19 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PJfJPD010456 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 19:41:19 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.164]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 13:41:19 -0600 From: "Yi Yang (yiya)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt Thread-Index: AQHPKQi5zZ45kU1tA0aXCN7Ijz5y8JrGgcwA Date: Tue, 25 Feb 2014 19:41:18 +0000 Message-ID: References: <20140213221002.30492.91618.idtracker@ietfa.amsl.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: [64.102.95.112] Content-Type: multipart/alternative; boundary="_000_CF325957225DDyiyaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/qCUB57tGzdaJs6O7lkRQlGV6EJ8 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, 25 Feb 2014 19:41:25 -0000 --_000_CF325957225DDyiyaciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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? Yi 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_CF325957225DDyiyaciscocom_ Content-Type: text/html; charset="us-ascii" Content-ID: <3CFDD0E433B19042889D1B5BB65E3171@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
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?

Yi



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@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_CF325957225DDyiyaciscocom_-- From nobody Tue Feb 25 12:27: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 134E91A0763 for ; Tue, 25 Feb 2014 12:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_24=0.6, 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 wvPADMmDwkf4 for ; Tue, 25 Feb 2014 12:27:08 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe005.messaging.microsoft.com [216.32.181.185]) by ietfa.amsl.com (Postfix) with ESMTP id 336031A0789 for ; Tue, 25 Feb 2014 12:27:07 -0800 (PST) Received: from mail3-ch1-R.bigfish.com (10.43.68.246) by CH1EHSOBE021.bigfish.com (10.43.70.78) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 20:27:05 +0000 Received: from mail3-ch1 (localhost [127.0.0.1]) by mail3-ch1-R.bigfish.com (Postfix) with ESMTP id 136212000BD; Tue, 25 Feb 2014 20:27:05 +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: -5 X-BigFish: VPS-5(z579ehzbb2dI98dI9371Ic89bh1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail3-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=BL2PRD0510HT004.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(377454003)(24454002)(189002)(199002)(479174003)(164054003)(51704005)(85306002)(83506001)(87266001)(2656002)(87936001)(95416001)(69226001)(81342001)(81542001)(66066001)(80022001)(76482001)(54356001)(53806001)(77982001)(59766001)(4396001)(63696002)(47446002)(49866001)(47976001)(50986001)(74502001)(31966008)(74662001)(47736001)(65816001)(46102001)(54316002)(56776001)(51856001)(19580395003)(19580405001)(83322001)(80976001)(83072002)(85852003)(79102001)(56816005)(92566001)(90146001)(81686001)(74366001)(36756003)(93136001)(94946001)(81816001)(92726001)(93516002)(86362001)(94316002)(76796001)(76786001)(77096001)(95666003)(74876001)(76176001)(74706001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB782; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:AEF4DE29.98CAED8B.41D13D7B.46E1D660.203B2; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail3-ch1 (localhost.localdomain [127.0.0.1]) by mail3-ch1 (MessageSwitch) id 1393360024171994_19704; Tue, 25 Feb 2014 20:27:04 +0000 (UTC) Received: from CH1EHSMHS013.bigfish.com (snatpool1.int.messaging.microsoft.com [10.43.68.245]) by mail3-ch1.bigfish.com (Postfix) with ESMTP id 1C9EE1E0054; Tue, 25 Feb 2014 20:27:04 +0000 (UTC) Received: from BL2PRD0510HT004.namprd05.prod.outlook.com (157.56.240.101) by CH1EHSMHS013.bigfish.com (10.43.70.13) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 20:27:00 +0000 Received: from DM2PR05MB782.namprd05.prod.outlook.com (10.141.179.142) by BL2PRD0510HT004.namprd05.prod.outlook.com (10.255.100.39) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 20:26:51 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by DM2PR05MB782.namprd05.prod.outlook.com (10.141.179.142) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 20:26:49 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 20:26:48 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEg== Date: Tue, 25 Feb 2014 20:26:47 +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.13] x-forefront-prvs: 01334458E5 Content-Type: text/plain; charset="euc-kr" Content-ID: <09BCD84D04BC4E468827D379ED1941DC@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 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/0hW1j9mIvYw_LR0qGyAva5b_qsc Subject: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:27:10 -0000 W3N1YmplY3QgbGluZSBjaGFuZ2VkXQ0KDQoNCk9uIDIvMjUvMTQgMTI6MDYgUE0sICJSZWluYWxk byBQZW5ubyAocmVwZW5ubykiIDxyZXBlbm5vQGNpc2NvLmNvbT4gd3JvdGU6DQoNCj5JIGhhdmUg c29tZSBjb21tZW50cyBvbiB0aGlzIGRyYWZ0Lg0KPg0KPlNpbmNlIHRoZSBkcmFmdCBwcm9wb3Nl cyBhIKn4Y29sZKn3IHJldmVyc2UgY29ubmVjdGlvbiBJIHdhcyBleHBlY3Rpbmcgc29tZQ0KPmRp c2N1c3Npb24gb24gdGhlIHRyYXZlcnNhbCBvZiBtaWRkbGVib3hlcy4gR2l2ZW4gZm9sa3MgdGhh dCBoYXZlIGJlZW4NCj5kZXBsb3lpbmcgTk1TIGltcGxpY2l0bHkgdGFrZSBmb3IgZ3JhbnRlZCB0 aGF0IGNvbm5lY3Rpb25zIGFyZSBhbHdheXMNCj5pbnNpZGUtPm91dCwgd2l0aCB0aGUgZXhjZXB0 aW9uIG9mIFNOTVAgdHJhcHMsIHN1Y2ggYSBkcmFmdCBzaG91bGQgYXNzdW1lDQo+c29tZSBwaXRm YWxscyBhbmQgc3VnZ2VzdCB3YXlzIGFyb3VuZCB0aGVtLiBJbiB0aGUgY2FzZSBvZiBTTk1QIGZv cg0KPmV4YW1wbGUsIHRoZSCp+HNvbHV0aW9uqfcgaXMgZmlyZXdhbGxzL05BVHMgdGhhdCBpbXBs ZW1lbnQgU05NUCBBTEcsIGJ1dA0KPmV2ZW4gdGhlbiwgYSBmaXJzdCBpbnNpZGUtPm91dHNpZGUg Y29ubmVjdGlvbiBpcyBleHBlY3RlZC4NCg0KDQpOb3cgSSdtIGNvbmZ1c2VkLCBieSBpbnNpZGUt Pm91dHNpZGUgeW91IG1lYW4gTk1TLT5kZXZpY2UsIHJpZ2h0PyAgLSB0aGlzDQp3b3VsZCBiZSwg Zm9yIGluc3RhbmNlLCBhbiBTUCBtYW5hZ2luZyBJbnRlcm5ldCByb3V0ZXJzLCB5ZXM/ICAgSWYg c28sDQp0aGVuIEkgdW5kZXJzdGFuZCB0aGF0IHN0YXRpYyBhZGRyZXNzaW5nIGlzIHRoZSBub3Jt LCBidXQgYXV0b21hdGljDQpkZXBsb3ltZW50ICh6ZXJvdG91Y2gpIGlzIHN0aWxsIHVzZWZ1bCBm b3IgaW5pdGlhbCBkaXNjb3ZlcnksIGF0IHdoaWNoDQpwb2ludCB0aGUgZGV2aWNlIHdvdWxkIGxp a2VseSBoYXZlIGl0cyBjYWxsLWhvbWUgY29uZmlndXJhdGlvbiByZW1vdmVkIGFuZA0KY29uZmln dXJhdGlvbiBlbmFibGluZyB0aGUgTk1TIHRvIGxvZ2luIGFkZGVkLiAgSW4gZWl0aGVyIGNhc2Us IGl0J3MgZmFpcg0KdG8gc2F5IHRoYXQgaXQncyBpbXBsaWNpdCBpbiB0aGUgc29sdXRpb24gdGhh dCB0aGUgTk1TIGlzIHJlYWNoYWJsZSB1c2luZw0KVENQLiAgSXQgd29uJ3QgZG8gaWYgdGhlIE5N UyBpcyBiZWhpbmQgYSBOQVQuLi4NCg0KDQoNCj5Tb21lIHBvaW50cyB0byBjb25zaWRlcjoNCj4N Cj4tIFRoZSBOTVMgSVAgYWRkcmVzcyBkb3dubG9hZGVkIGZyb20gY29uZmlnIHNlcnZlciBjYW4g bm90IGJlIGJlaGluZCBhDQo+ZmlyZXdhbGwgdW5sZXNzIHRoZXJlIGlzIHNvbWUgcGluaG9sZSBv ciB0cmF2ZXJzYWwgbWV0aG9kIHRoZSBkZXZpY2UgY2FuDQo+VXNlDQoNClRydWUsIGl0IGlzIHJl cXVpcmVkIHRoZSBkZXZpY2UgYmUgYWJsZSB0byBUQ1AgdG8gdGhlIE5NUydzIElQIGFkZHJlc3Mg YW5kDQpwb3J0Lg0KDQoNCj4tIElmIE5NUyBpcyBiZWhpbmQgYSBOQVQsIHRoZSBJUDpwb3J0IHNo b3VsZCBiZSB0aGUgb3V0c2lkZSBhbmQgc3RhYmxlLg0KDQpTdXJlLg0KDQoNCj4tIEluIHRoZSB3 b3JzdCBjYXNlIG1heWJlIGNvbmZpZ3VyYXRpb24gc2VydmVyICh3aGljaCB0aGVvcmV0aWNhbGx5 IGNvdWxkDQo+YmUgcmVhY2hlZCBieSBib3RoIHBhcnRpZXMpIGNvdWxkIGQgc2VydmVyIGFzIGEg cmVsYXkuDQoNCkknbSBub3QgZm9sbG93aW5nIHRoZSBuZWVkIGZvciBtaWRkbGUtYm94ZXMgLSBh dCBsZWFzdCBub3QgaW4gdGhlIHNvbHV0aW9uDQpkZWZpbmVkIGJ5IElFVEYuICBJZiBhIHBhcnRp Y3VsYXIgZGVwbG95bWVudCBuZWVkcyBtaWRkbGUgYm94ZXMsIHRoZW4gaXQNCmNhbiBzZXQgdGhl bSB1cCBhbmQgaGF2ZSB0aGUgZGV2aWNlcyB6ZXJvdG91Y2ggdG8gaXQgaW5zdGVhZCBvZiB0byB0 aGUNCmFjdHVhbCBOTVMgLSBkb2VzIHRoYXQgbWFrZSBzZW5zZT8NCg0KDQo+LSBJZiBhIE5BVCBl eGlzdHMgYmV0d2VlbiBOTVMgYW5kIGRldmljZSwgb25lIGNhbiBub3QgYXNzdW1lIHJlZ2lzdGVy ZWQNCj5wb3J0cyB3aWxsIGJlIGF2YWlsYWJsZS4gIFRoZXJlZm9yZSBjb25maWcgc2VydmVyIG5l ZWRzIHRvIGJlIGFibGUgdG8gc2VuZA0KPnBvcnQgaW5mb3JtYXRpb24uDQoNClRoaXMgaXMgYWxy ZWFkeSB0aGUgY2FzZSwgcG9ydHMgY2FuIGJlIHNwZWNpZmllZCBpbiB0aGUgWmVyb1RvdWNoDQpD b25maWdsZXQuDQoNCg0KPi0gRGV2aWNlIHNob3VsZCBiZSBwcmVwYXJlZCB0byBjaGVjayB3aXRo IGNvbmZpZ3VyYXRpb24gc2VydmVyIGlzIGV4dGVybmFsDQo+cG9ydCBoYXMgY2hhbmdlZCBkdWUg dG8gc3RhdGUgYmVpbmcgcmVtb3ZlZCBvbiB0aGUgTkFULg0KDQpUaGUgc29sdXRpb24gaXMgZm9y IHRoZSBkZXZpY2UgdG8gY2hlY2sgd2l0aCB0aGUgY29uZmlndXJhdGlvbiBzZXJ2ZXINCipldmVy eSogdGltZSBpdCBib290cyBmb3IgYSBkZWZhdWx0IGZhY3RvcnkgY29uZmlndXJhdGlvbi4gIElu IG9yZGVyIGZvcg0KdGhlIGRldmljZSB0byByZWNlaXZlIGEgbmV3IHZhbHVlLCB0aGUgY29uZmln dXJhdGlvbiBzZXJ2ZXIgbmVlZHMgdG8gYmUNCnVwZGF0ZWQgZmlyc3QgYW5kIHRoZW4gdGhlIGRl dmljZSByZWJvb3RlZCBhZ2Fpbi4NCg0KDQpUaGFua3MsDQpLZW50DQoNCg== From nobody Tue Feb 25 12:28: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 193B51A0763 for ; Tue, 25 Feb 2014 12:28:07 -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 OXVPCS1zFXsN for ; Tue, 25 Feb 2014 12:28:03 -0800 (PST) Received: from mail-qc0-f171.google.com (mail-qc0-f171.google.com [209.85.216.171]) by ietfa.amsl.com (Postfix) with ESMTP id 5BF9D1A074B for ; Tue, 25 Feb 2014 12:28:03 -0800 (PST) Received: by mail-qc0-f171.google.com with SMTP id x3so1236878qcv.30 for ; Tue, 25 Feb 2014 12:28:02 -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=HtfUX3N5pcUZxZgKIusY3tFr4pgA8twr0eL+syzk+M4=; b=md0LCG09dzaRmbD0bebSLMxbfknLEHFeZNZJIR9spJCFXuuVw9ywXecEk3FMS+v9Ne 3IWfmAHopDH3JqXpNJ4vfM7bE2aEQoRsJooIs/yK9XRUr9aV67nEs9cbo9AIE7U7uzcY nS6ap38spQsmTq5AvgUuYM7iuPR2vIu0uuAXXa78Up2jBTPyg+HKOld2gyetpRQGclec RmppSBYmVeo9L7yvY8dkPY6egKcEDpqYydlmxmqvoMI9wZ462R3XnHaSkh01LqFGO1B4 Qi7gn7IjC82+7bBIIDCcoCiOiuz49ehG8/GHNwnKrU4ENkL79znE+AadxRe8xvUwE/gf cibA== X-Gm-Message-State: ALoCoQnUcnn3j923FSgTGAN0COgV+pUkUnF5cmOx24Gfh+tNcy7tZWaK1oN/47XrqI6XThYM6rxx MIME-Version: 1.0 X-Received: by 10.224.79.19 with SMTP id n19mr2648222qak.99.1393360082217; Tue, 25 Feb 2014 12:28:02 -0800 (PST) Received: by 10.140.104.194 with HTTP; Tue, 25 Feb 2014 12:28:02 -0800 (PST) In-Reply-To: References: <20140213221002.30492.91618.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 12:28:02 -0800 Message-ID: From: Andy Bierman To: "Yi Yang (yiya)" Content-Type: multipart/alternative; boundary=047d7bdc8040bec5e604f340ec1f Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bEbk8dn_p7iT0KAG0OWwdir1NZs 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, 25 Feb 2014 20:28:07 -0000 --047d7bdc8040bec5e604f340ec1f Content-Type: text/plain; charset=ISO-8859-1 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 > > --047d7bdc8040bec5e604f340ec1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



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.= =A0In other words, it indicates a hierarchy.=A0

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 what we are = doing
by putting the key values in the URL.

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


Yi

Andy
=A0



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.


=A0 =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : RESTCONF Protocol
=A0 =A0 =A0 =A0 Authors =A0 =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Martin Bjorklund
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Kent Watsen
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Rex Fernando
=A0 =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-bierman-netconf-restconf-04= .txt
=A0 =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 96
=A0 =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2014-02-13

Abstract:
=A0 =A0This document describes a REST-like protocol that provides a
=A0 =A0programmatic interface over HTTP for accessing data defined in YANG,=
=A0 =A0using 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

--047d7bdc8040bec5e604f340ec1f-- From nobody Tue Feb 25 12:32: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 158DB1A01EA for ; Tue, 25 Feb 2014 12:32: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 KCwTBgF1R98f for ; Tue, 25 Feb 2014 12:32:45 -0800 (PST) Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) by ietfa.amsl.com (Postfix) with ESMTP id C3F741A02A9 for ; Tue, 25 Feb 2014 12:32:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=682; q=dns/txt; s=iport; t=1393360365; x=1394569965; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=Hu+FYNdaIM5zZlgKTK9t20NvciOV13cOy2Zit5PMrFk=; b=Rjo21PMnQxr7Wvfy/9id3KSFn0+atEorES6F1v7TQFABigLRCd1oij6B uhrAJCH5/ovFkXtg7DGuGaQDGI7caQuj6BrsPreiqllT1TWxK8o+vGg76 4PRxW77QpKak3fEQFMu2xB4xHfgzWA8UhHDLT6eM8ixFlDNtE2tr+Sw6X o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhIFAFL9DFOtJXHA/2dsb2JhbABZgwaBEsFQgRoWdIIsgQsBCA5qJQIEARIbh2rINxeOV4Q4AQOJEYs6g2uSKIMtgio X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="23125549" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-7.cisco.com with ESMTP; 25 Feb 2014 20:32:44 +0000 Received: from xhc-rcd-x10.cisco.com (xhc-rcd-x10.cisco.com [173.37.183.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKWihG002532 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 20:32:44 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x10.cisco.com ([173.37.183.84]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 14:32:44 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA Date: Tue, 25 Feb 2014 20:32:43 +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.74.73] Content-Type: text/plain; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/smvG-cV1jzfotzO_gBvBEkYo2Os Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:32:50 -0000 Wouldn=B9t that shave some of the value of zero touch? It would be good to insert a clause recommending device re-checks with config server in case it can not establish connection to NMS. On 2/25/14, 12:26 PM, "Kent Watsen" wrote: >>- Device should be prepared to check with configuration server is >>external >>port has changed due to state being removed on the NAT. > >The solution is for the device to check with the configuration server >*every* time it boots for a default factory configuration. In order for >the device to receive a new value, the configuration server needs to be >updated first and then the device rebooted again. > From nobody Tue Feb 25 12:33: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 DDA581A07C1 for ; Tue, 25 Feb 2014 12:33:37 -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 q4PUqUXrcbD9 for ; Tue, 25 Feb 2014 12:33:32 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe003.messaging.microsoft.com [65.55.88.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5DDF91A02C3 for ; Tue, 25 Feb 2014 12:33:32 -0800 (PST) Received: from mail144-tx2-R.bigfish.com (10.9.14.238) by TX2EHSOBE014.bigfish.com (10.9.40.34) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 20:33:31 +0000 Received: from mail144-tx2 (localhost [127.0.0.1]) by mail144-tx2-R.bigfish.com (Postfix) with ESMTP id 032FA1402B8; Tue, 25 Feb 2014 20:33:31 +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(z579ehzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h946he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail144-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)(199002)(189002)(81542001)(93136001)(81342001)(81816001)(63696002)(79102001)(86362001)(93516002)(92726001)(66066001)(83322001)(81686001)(80022001)(80976001)(83506001)(59766001)(50986001)(47976001)(76176001)(94316002)(36756003)(76786001)(76796001)(47736001)(49866001)(77096001)(4396001)(46102001)(54356001)(53806001)(51856001)(54316002)(56776001)(76482001)(87266001)(69226001)(31966008)(47446002)(74502001)(74662001)(56816005)(74366001)(87936001)(83072002)(90146001)(2656002)(74876001)(94946001)(74706001)(95416001)(95666003)(92566001)(65816001)(77982001)(85306002)(85852003); DIR:OUT; SFP:1101; SCL:1; SRVR:BY2PR05MB773; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:BCAAD875.A4144719.D0E73340.56C0F34B.20149; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail144-tx2 (localhost.localdomain [127.0.0.1]) by mail144-tx2 (MessageSwitch) id 1393360409561388_23186; Tue, 25 Feb 2014 20:33:29 +0000 (UTC) Received: from TX2EHSMHS020.bigfish.com (unknown [10.9.14.254]) by mail144-tx2.bigfish.com (Postfix) with ESMTP id 6DE3D2C0064; Tue, 25 Feb 2014 20:33:29 +0000 (UTC) Received: from BL2PRD0510HT005.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS020.bigfish.com (10.9.99.120) with Microsoft SMTP Server (TLS) id 14.1.225.23; Tue, 25 Feb 2014 20:33:29 +0000 Received: from BY2PR05MB773.namprd05.prod.outlook.com (10.141.224.140) by BL2PRD0510HT005.namprd05.prod.outlook.com (10.255.100.40) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 20:33:27 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BY2PR05MB773.namprd05.prod.outlook.com (10.141.224.140) with Microsoft SMTP Server (TLS) id 15.0.888.9; Tue, 25 Feb 2014 20:33:25 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 20:33:25 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , Juergen Schoenwaelder Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmjULPdNEnoLdEq1+39DEgWiEg== Date: Tue, 25 Feb 2014 20:33:24 +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.13] x-forefront-prvs: 01334458E5 Content-Type: text/plain; charset="Windows-1252" Content-ID: <9AE2B7A2B5CD44438A85D7A9FB209CE6@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/Pqlo56vyGMrIs69PVRr18RfwEss Cc: netconf Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:33:38 -0000 >I think the term =B3behind=B2 is confusing. I=B9m assuming device (router, >switch, etc) is in the public network (outside the NAT) and NMS is in the >private network. NMS can open connections to any device without problems >but reverse connections are normally not allowed. Heh, I was expected this=8A OK, consider this diagram: NMS --- GW-1 -------- Internet --------- GW-2 --- device >From the NMS's POV, the device is "behind" GW-2 >From the device's POV, the NMS is "behind" GW-1 What you are describing is GW-1 being a NAT, potentially blocking access to the NMS's real IP/port, in which case the device would NOT be able to "call home" K. From nobody Tue Feb 25 12:35: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 8F2351A0778 for ; Tue, 25 Feb 2014 12:35:53 -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 AfXhghiVSqvk for ; Tue, 25 Feb 2014 12:35:48 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 0A4D61A0131 for ; Tue, 25 Feb 2014 12:35:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12378; q=dns/txt; s=iport; t=1393360547; x=1394570147; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BFpI9bs0E5jTGJSMuQMKj3Dsne2sT8qHKP0YB+4SIcc=; b=XaDzngwIgAbMhctX2HZUHW4s+X8JkTOukNtX2cW0pQ6mHhnRNCy+8Dqa P+ZlreCNq4tO3EelL3jWl5KSJBE7EbmBhlwGC7fONcaMJ93MGEopmH/Oa m9vLr0mL/coJrapuTcKP3oempC1HOkA2UOs5JwzPae9C4SifyHKW0R76C s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AssGADT+DFOtJV2Y/2dsb2JhbABZgkJEO1EGuHeIWYEaFnSCJQEBAQQBAQFrCxACAQgRAwECKAcnCxQJCAIEDgUJh3wIBcgmF41kWw0EBgEGA4QvBJg2gTKLMoVEgy2BcTk X-IronPort-AV: E=Sophos; i="4.97,541,1389744000"; d="scan'208,217"; a="23129231" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-4.cisco.com with ESMTP; 25 Feb 2014 20:35:46 +0000 Received: from xhc-aln-x09.cisco.com (xhc-aln-x09.cisco.com [173.36.12.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKZkkR021051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 20:35:46 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.164]) by xhc-aln-x09.cisco.com ([173.36.12.83]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 14:35:46 -0600 From: "Yi Yang (yiya)" To: Andy Bierman Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt Thread-Index: AQHPKQi5zZ45kU1tA0aXCN7Ijz5y8JrGgcwAgABg4AD//65VAA== Date: Tue, 25 Feb 2014 20:35:45 +0000 Message-ID: References: <20140213221002.30492.91618.idtracker@ietfa.amsl.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: [64.102.95.112] Content-Type: multipart/alternative; boundary="_000_CF32678B22637yiyaciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/B47lSkfZbUexATgVoJhVHqTGyus 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, 25 Feb 2014 20:35:54 -0000 --_000_CF32678B22637yiyaciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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. Yi 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_CF32678B22637yiyaciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
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.

Yi

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_CF32678B22637yiyaciscocom_-- From nobody Tue Feb 25 12:38: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 97E441A07D1 for ; Tue, 25 Feb 2014 12:38: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 RyJZSCzgK9aE for ; Tue, 25 Feb 2014 12:38:31 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 401EA1A07C1 for ; Tue, 25 Feb 2014 12:38:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1258; q=dns/txt; s=iport; t=1393360708; x=1394570308; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=VttkrqPctxoSitj37udAqk1OCDByyy9DNrlJlXlIMcg=; b=NTVLHWjuIpOrVTo3XTr0EX982t2aMyga9ykVeCm5xSM6e7tZqJMgQ4s1 lldAI5HTeEW5ySmVyeSeVKhnTGfpG9n7mnGVjNSzpwy5aVqzn88J+j641 +0gtK8/pt8Sm+7NWylq0NGZ/Ps0klTBh/gF6FE1Yf05iz96d0Ir+qdEwq 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFADT+DFOtJXHA/2dsb2JhbABZgwaBEoMDvk0YgQIWdIIsIxFFEgEIDgwCJgIEMBUQAgQBDQWIBachoRIXgSmNJweCb4FJAQOYNpIogy2CKg X-IronPort-AV: E=Sophos;i="4.97,541,1389744000"; d="scan'208";a="23130227" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-8.cisco.com with ESMTP; 25 Feb 2014 20:38:25 +0000 Received: from xhc-aln-x10.cisco.com (xhc-aln-x10.cisco.com [173.36.12.84]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKcP8v011063 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 20:38:25 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x10.cisco.com ([173.36.12.84]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 14:38:25 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , Juergen Schoenwaelder Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmjULPdNEnoLdEq1+39DEgWiEprGTLUA Date: Tue, 25 Feb 2014 20:38: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.74.73] Content-Type: text/plain; charset="utf-8" Content-ID: <794D6A3255A9414B972C20454D46BBDB@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/NgYfMosX5BY5L1vpdVWHsqkvkAw Cc: netconf Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:38:32 -0000 UmlnaHQsIHRoZSBOQVQgKG9yIEZpcmV3YWxsKSBjb3VsZCBiZSBhY3R1YWxseSBlbWJlZGRlZCBp biBHVy0xLiBJ4oCZdmUNCmZhY2VkIHRoaXMgcXVpdGUgYSBmZXcgdGltZXMgaW4gdGhlIGNvbnRl eHQgb2YgU05NUC4NCg0KT24gMi8yNS8xNCwgMTI6MzMgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRz ZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQo+DQo+DQo+DQo+PkkgdGhpbmsgdGhlIHRlcm0gwrNi ZWhpbmTCsiBpcyBjb25mdXNpbmcuIEnCuW0gYXNzdW1pbmcgZGV2aWNlIChyb3V0ZXIsDQo+PnN3 aXRjaCwgZXRjKSBpcyBpbiB0aGUgcHVibGljIG5ldHdvcmsgKG91dHNpZGUgdGhlIE5BVCkgYW5k IE5NUyBpcyBpbiB0aGUNCj4+cHJpdmF0ZSBuZXR3b3JrLiBOTVMgY2FuIG9wZW4gY29ubmVjdGlv bnMgdG8gYW55IGRldmljZSB3aXRob3V0IHByb2JsZW1zDQo+PmJ1dCByZXZlcnNlIGNvbm5lY3Rp b25zIGFyZSBub3JtYWxseSBub3QgYWxsb3dlZC4NCj4NCj4NCj5IZWgsIEkgd2FzIGV4cGVjdGVk IHRoaXPFoA0KPg0KPk9LLCBjb25zaWRlciB0aGlzIGRpYWdyYW06DQo+DQo+DQo+ICAgICAgIE5N UyAtLS0gR1ctMSAtLS0tLS0tLSBJbnRlcm5ldCAtLS0tLS0tLS0gR1ctMiAtLS0gZGV2aWNlDQo+ DQo+RnJvbSB0aGUgTk1TJ3MgUE9WLCB0aGUgZGV2aWNlIGlzICJiZWhpbmQiIEdXLTINCj5Gcm9t IHRoZSBkZXZpY2UncyBQT1YsIHRoZSBOTVMgaXMgImJlaGluZCIgR1ctMQ0KPg0KPg0KPldoYXQg eW91IGFyZSBkZXNjcmliaW5nIGlzIEdXLTEgYmVpbmcgYSBOQVQsIHBvdGVudGlhbGx5IGJsb2Nr aW5nIGFjY2Vzcw0KPnRvIHRoZSBOTVMncyByZWFsIElQL3BvcnQsIGluIHdoaWNoIGNhc2UgdGhl IGRldmljZSB3b3VsZCBOT1QgYmUgYWJsZSB0bw0KPiJjYWxsIGhvbWUiDQo+DQo+DQo+Sy4NCj4N Cj4NCg0K From nobody Tue Feb 25 12:41: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 2E9A81A07D6 for ; Tue, 25 Feb 2014 12:41:43 -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 Lg1gIIFbhDbM for ; Tue, 25 Feb 2014 12:41:40 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 08C411A018C for ; Tue, 25 Feb 2014 12:41:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=555; q=dns/txt; s=iport; t=1393360901; x=1394570501; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=g1koIJTj1kTF4iLoaDKGbenUSWqH8CsbPP7Zk21/R9U=; b=bWarU7jWDSqDCTI0uzB6S6c3MRc7RupOX9WU6CbqEwhyq9fpaqrsdkZ+ oOPvb6PAaHAk93bN0kcUChlK9ITR8F8B6Mdp+fezL3L8fVTMPUn44KLtC NjLInCl5mIYeMRkrdyknY83W4Cyu8vB0vCXEehcYo09QuHXkW2fu0kGY1 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAFL/DFOtJV2a/2dsb2JhbABZgwiBDb1LgRsWAXSEBDpRAQgOKEIlAgQBEhuHacAIF48ZhDYBA5gWkhSDK4Iq X-IronPort-AV: E=Sophos;i="4.97,863,1389744000"; d="scan'208";a="303421698" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-9.cisco.com with ESMTP; 25 Feb 2014 20:41:40 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKfcw4014412 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 20:41:39 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 14:41:38 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGTZ2A Date: Tue, 25 Feb 2014 20:41:38 +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.74.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <873F90EF17C7F4409564BB9742FE5FEC@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/s06MJb7AvZtXTJuc8MNempbKkEc Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:41:43 -0000 Yes, but it would require manual configuration on possibly several middleboxes.=20 On 2/25/14, 12:26 PM, "Kent Watsen" wrote: >>- In the worst case maybe configuration server (which theoretically could >>be reached by both parties) could d server as a relay. > >I'm not following the need for middle-boxes - at least not in the solution >defined by IETF. If a particular deployment needs middle boxes, then it >can set them up and have the devices zerotouch to it instead of to the >actual NMS - does that make sense? From nobody Tue Feb 25 12:44:07 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 74D431A07E2 for ; Tue, 25 Feb 2014 12:44:04 -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 cwR1AkCy3atV for ; Tue, 25 Feb 2014 12:43:58 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 243F51A07D4 for ; Tue, 25 Feb 2014 12:43:57 -0800 (PST) Received: from mail87-co9-R.bigfish.com (10.236.132.232) by CO9EHSOBE037.bigfish.com (10.236.130.100) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 20:43:56 +0000 Received: from mail87-co9 (localhost [127.0.0.1]) by mail87-co9-R.bigfish.com (Postfix) with ESMTP id 15041C01BA; Tue, 25 Feb 2014 20:43:56 +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: -6 X-BigFish: VPS-6(z579ehzbb2dI98dI9371Ic89bh1dbaI1432I4015Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h8275bh1de097hz2fh109h2a8h839h942he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail87-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)(377454003)(51704005)(164054003)(479174003)(24454002)(189002)(199002)(36756003)(86362001)(92726001)(92566001)(47446002)(74662001)(95416001)(94946001)(31966008)(74502001)(94316002)(54356001)(53806001)(74706001)(76482001)(54316002)(19580405001)(83322001)(2656002)(19580395003)(95666003)(83072002)(81686001)(83506001)(87266001)(80976001)(79102001)(51856001)(85852003)(77982001)(46102001)(59766001)(50986001)(49866001)(47736001)(47976001)(81342001)(65816001)(66066001)(80022001)(69226001)(74876001)(63696002)(77096001)(81816001)(87936001)(74366001)(85306002)(81542001)(76786001)(76796001)(56776001)(56816005)(93136001)(90146001)(93516002)(4396001); DIR:OUT; SFP:1101; SCL:1; SRVR:DM2PR05MB719; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:6E34F1A6.AC326DE8.31F02247.6C74D3F0.20225; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received: from mail87-co9 (localhost.localdomain [127.0.0.1]) by mail87-co9 (MessageSwitch) id 1393361034661114_5650; Tue, 25 Feb 2014 20:43:54 +0000 (UTC) Received: from CO9EHSMHS014.bigfish.com (unknown [10.236.132.243]) by mail87-co9.bigfish.com (Postfix) with ESMTP id 939BC180057; Tue, 25 Feb 2014 20:43:54 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by CO9EHSMHS014.bigfish.com (10.236.130.24) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 20:43:48 +0000 Received: from DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 20:43:46 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by DM2PR05MB719.namprd05.prod.outlook.com (10.141.177.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 20:43:44 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 20:43:43 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oA= Date: Tue, 25 Feb 2014 20:43:43 +0000 Message-ID: References: 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.13] x-forefront-prvs: 01334458E5 Content-Type: text/plain; charset="euc-kr" Content-ID: <25C206284889BF40A701DA40AA70DFA8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 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/Pb_kqgLs4COr1HAp515YoAFFAZw Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:44:04 -0000 DQoNCk9uIDIvMjUvMTQgMzozMiBQTSwgIlJlaW5hbGRvIFBlbm5vIChyZXBlbm5vKSIgPHJlcGVu bm9AY2lzY28uY29tPiB3cm90ZToNCg0KPldvdWxkbqn2dCB0aGF0IHNoYXZlIHNvbWUgb2YgdGhl IHZhbHVlIG9mIHplcm8gdG91Y2g/DQo+DQo+SXQgd291bGQgYmUgZ29vZCB0byBpbnNlcnQgYSBj bGF1c2UgcmVjb21tZW5kaW5nIGRldmljZSByZS1jaGVja3Mgd2l0aA0KPmNvbmZpZyBzZXJ2ZXIg aW4gY2FzZSBpdCBjYW4gbm90IGVzdGFibGlzaCBjb25uZWN0aW9uIHRvIE5NUy4NCg0KQWgsIHlv dSdyZSB0YWxraW5nIGFib3V0IHRoZSBjYXNlIHdoZXJlIHRoZSBkZXZpY2Ugd2FzIGFibGUgdG8g ZmluZCBhbmQNCmxvYWQgYSBDb25maWdsZXQsIGJ1dCBpdCBjb250YWluZWQgZmF1bHR5IHZhbHVl cy4gIFlvdSBoYXZlIGEgcG9pbnQsDQpjbGVhcmx5IHRoZSBkZXZpY2Ugc2hvdWxkIGhhdmUgc29t ZSByZWNvdXJzZSBmb3IgdGhpcyBjYXNlLi4uDQoNCk5vcm1hbGx5LCBhIGRldmljZSB1bmFibGUg dG8gZmluZCBhIENvbmZpZ2xldCB3b3VsZCB1bHRpbWF0ZWx5IGRvIGEgbm9ybWFsDQpib290LCBh cyBpdCdzIG1vc3QgbGlrZWx5IGFuIGFkbWluIGlzIHdhaXRpbmcgdG8gbG9nIGludG8gaXQuICBJ biB0aGlzDQpjYXNlLCB0aGUgZGV2aWNlIGhhcyB0cmlnZ2VyIGxvZ2ljIGhhdCBzaG91bGQgZXNz ZW50aWFsbHkgdGVsbHMgaXQgdG8gcnVuDQpoZWFkbGVzcywgc28gZm9yZXZlciBjaGVja2luZyBm b3IgYW4gdXBkYXRlZCBDb25maWdsZXQgbWF5IGJlIGFwcHJvcHJpYXRlLg0KIA0KDQpJIGRvbid0 IGtub3csICJmb3JldmVyIiBsb29waW5nIGRvZXNuJ3Qgc291bmQgcmlnaHQuICBBbmQgd2FpdGlu ZyBldmVuIGENCmZldyBtaW51dGVzIGlzIHVubGlrZWx5IHRvIHByb2R1Y2UgYSBuZXcgQ29uZmln bGV0LCBnaXZlbiB0aGF0IGl0J3MgYW4NCmF1dG9tYXRlZCBzeXN0ZW0gYW5kIHRoZSBOTVMgd2ls bCBoYXZlIG5vIGFsZXJ0IGZvciBhIGRldmljZSBmYWlsaW5nIHRvDQpjb25uZWN0LCBhbmQgaGVu Y2UgaXQncyB1bmxpa2VseSB0aGUgQ29uZmlnbGV0IHdpbGwgZ2V0IGZpeGVkIHNvIHF1aWNrbHku DQoNCldoYXQgZG8geW91IHRoaW5rPw0KDQpUaGFua3MsDQpLZW50DQoNCg0K From nobody Tue Feb 25 12:46: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 A0A691A0054 for ; Tue, 25 Feb 2014 12:45: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 2gQfV9C_9tXU for ; Tue, 25 Feb 2014 12:45:51 -0800 (PST) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) by ietfa.amsl.com (Postfix) with ESMTP id AB5EC1A07F1 for ; Tue, 25 Feb 2014 12:45:51 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 60B1BF9C; Tue, 25 Feb 2014 21:45: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 El3IfQoxE3ws; Tue, 25 Feb 2014 21:45:48 +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, 25 Feb 2014 21:45:48 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88AFE20026; Tue, 25 Feb 2014 21:45:48 +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 rWXjy3pdvAFu; Tue, 25 Feb 2014 21:45: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 1672320015; Tue, 25 Feb 2014 21:45:47 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BDBC62B7AAD1; Tue, 25 Feb 2014 21:45:45 +0100 (CET) Date: Tue, 25 Feb 2014 21:45:45 +0100 From: Juergen Schoenwaelder To: "Reinaldo Penno (repenno)" Message-ID: <20140225204545.GA4847@elstar.local> Mail-Followup-To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , Kent Watsen , netconf References: <20140225192710.GE4469@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/1jIKo5NJkPbhyG7NsAZw3RvrNMw 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 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, 25 Feb 2014 20:45:59 -0000 On Tue, Feb 25, 2014 at 07:40:51PM +0000, Reinaldo Penno (repenno) wrote: > > > On 2/25/14, 11:27 AM, "Juergen Schoenwaelder" > wrote: > > >On Tue, Feb 25, 2014 at 07:11:51PM +0000, Reinaldo Penno (repenno) wrote: > >> > >> > >> On 2/25/14, 10:44 AM, "Juergen Schoenwaelder" > >> wrote: > >> > >> >Hi, > >> > > >> >I am somewhat confused. NETCONF so far assumes that the device can be > >> >contacted by opening a TCP connection from the NMS to the device. In > >> >case the NMS is behind a NAT, this works just fine. > >> >The call home work > >> >was started to deal with situations where the device is behind a NAT > >> > >> I think the term ³behind² is confusing. I¹m assuming device (router, > >> switch, etc) is in the public network (outside the NAT) and NMS is in > >>the > >> private network. NMS can open connections to any device without problems > >> but reverse connections are normally not allowed. > > > >In this case, standard NETCONF transports just work fine and you do > >not need the call-home mechanism. > > 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. > > A new device is installed on the network, all it needs is to download a > configuration file from a server and then connect to NMS (Netconf client). > Netconf client does not need to be configured with IP address of every new > device that comes in the network. > > My expectation seems to match those of the draft which goes into the > benefits of such mechanism and problems it solves. Sorry, the subject line did not make it clear which I-D you are referring to. One of the motivations for call home is to enable management of devices that can be reached in the normal way because they are behind a NAT (assuming you will figure out what behind means in this context). /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 Feb 25 12:51: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 029221A0817 for ; Tue, 25 Feb 2014 12:51:21 -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 4QLQyhfRfV3L for ; Tue, 25 Feb 2014 12:51:13 -0800 (PST) Received: from mail-qc0-f177.google.com (mail-qc0-f177.google.com [209.85.216.177]) by ietfa.amsl.com (Postfix) with ESMTP id 8760C1A0810 for ; Tue, 25 Feb 2014 12:51:11 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id m20so2955258qcx.22 for ; Tue, 25 Feb 2014 12:51:10 -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=2sTSwslOqe/qk04QqU+NcPFimwzCH8m3pf/G1QswAeI=; b=I93xF4Gyp/ES0keMe05pM5IEbrDAGgGDINesVos+glxys3bMegvFMvJDyqXXdMpbBI 40JhNkThxBMi7v7iHaiISpV73E0F1RRJ34yHu0+VWzCzJ/jPD4J5rzGe/QgX2R8Lljc7 QKM32ASRjlzExdEkUzJXXspZX6S7IEzp2wv0RQ5qYgnReAW4ZYN0uHC3Fk2sMFvtYrsg qa7tbjpkQvdekMHRykvDL5N0NctedWNDXSgHmUJyg2015lcRUECmSrUINimA/OzlO5AW /R4h1XL3lYcMPcJ8HmgyYbGnR6JjslJfpXQRrdZoqL1LSU8x9bBVSuLEaEEkgKuztxON spAQ== X-Gm-Message-State: ALoCoQmDmNaRuBI8wA+Dz+V/5CxUHAiqPYQLY2DHBAp3agaeIOzgKk64at6NmmQEDgJ1gf+Jclvr MIME-Version: 1.0 X-Received: by 10.224.19.199 with SMTP id c7mr3105197qab.78.1393361470406; Tue, 25 Feb 2014 12:51:10 -0800 (PST) Received: by 10.140.104.194 with HTTP; Tue, 25 Feb 2014 12:51:10 -0800 (PST) In-Reply-To: References: <20140213221002.30492.91618.idtracker@ietfa.amsl.com> Date: Tue, 25 Feb 2014 12:51:10 -0800 Message-ID: From: Andy Bierman To: "Yi Yang (yiya)" Content-Type: multipart/alternative; boundary=001a11c2b3ca7cd75f04f3413f16 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/U6Q8Ua7maYxM3_-b3qiGAQT6p-s 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, 25 Feb 2014 20:51:21 -0000 --001a11c2b3ca7cd75f04f3413f16 Content-Type: text/plain; charset=ISO-8859-1 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 >> >> > --001a11c2b3ca7cd75f04f3413f16 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



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

--001a11c2b3ca7cd75f04f3413f16-- From nobody Tue Feb 25 12:53:09 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 0C0591A07EA for ; Tue, 25 Feb 2014 12:53:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, 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 DT5i7Zlk6Hup for ; Tue, 25 Feb 2014 12:52:56 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) by ietfa.amsl.com (Postfix) with ESMTP id 639821A0810 for ; Tue, 25 Feb 2014 12:52:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2780; q=dns/txt; s=iport; t=1393361575; x=1394571175; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=hyuHe8Y17pSQPjF0hGwJtQuqmuYE3ifTMdHxQU0rY30=; b=YFIn4Cu+bBDuO53tioYd+hk81l232pYtnYfSJ+BSMYoUW6jePI4rqUC5 SeWJaI2kYb9fQxkLUCxvspcW+XTO5niwKxRemeXK7pNS1mojv9NHdeghH +IvUuBDh2egZAaiCZpOP6t3h4odqhKez879jg9Zj2s5Jn0p3YHHtndlyj s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8FALgBDVOtJXHA/2dsb2JhbABZgwY7V4I5Sr5NGIECFnSCJQEBAQQMKFcBBgIOCgQoBDAlAgQBEogFiyObdwahFReBI4x6OoJpgU8BA5g2kiiDLYIq X-IronPort-AV: E=Sophos;i="4.97,542,1389744000"; d="scan'208";a="23134024" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-4.cisco.com with ESMTP; 25 Feb 2014 20:52:55 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PKqtAB028078 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 20:52:55 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 14:52:54 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAA== Date: Tue, 25 Feb 2014 20:52:54 +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.74.73] Content-Type: text/plain; charset="euc-kr" Content-ID: <4FD87460DAC43E4686548CA5DED5104D@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6bbfZWmKi4oEJZi7OLvIfIO-iIA Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 20:53:03 -0000 DQoNCk9uIDIvMjUvMTQsIDEyOjQzIFBNLCAiS2VudCBXYXRzZW4iIDxrd2F0c2VuQGp1bmlwZXIu bmV0PiB3cm90ZToNCg0KPg0KPg0KPk9uIDIvMjUvMTQgMzozMiBQTSwgIlJlaW5hbGRvIFBlbm5v IChyZXBlbm5vKSIgPHJlcGVubm9AY2lzY28uY29tPiB3cm90ZToNCj4NCj4+V291bGRuqfZ0IHRo YXQgc2hhdmUgc29tZSBvZiB0aGUgdmFsdWUgb2YgemVybyB0b3VjaD8NCj4+DQo+Pkl0IHdvdWxk IGJlIGdvb2QgdG8gaW5zZXJ0IGEgY2xhdXNlIHJlY29tbWVuZGluZyBkZXZpY2UgcmUtY2hlY2tz IHdpdGgNCj4+Y29uZmlnIHNlcnZlciBpbiBjYXNlIGl0IGNhbiBub3QgZXN0YWJsaXNoIGNvbm5l Y3Rpb24gdG8gTk1TLg0KPg0KPkFoLCB5b3UncmUgdGFsa2luZyBhYm91dCB0aGUgY2FzZSB3aGVy ZSB0aGUgZGV2aWNlIHdhcyBhYmxlIHRvIGZpbmQgYW5kDQo+bG9hZCBhIENvbmZpZ2xldCwgYnV0 IGl0IGNvbnRhaW5lZCBmYXVsdHkgdmFsdWVzLiAgWW91IGhhdmUgYSBwb2ludCwNCj5jbGVhcmx5 IHRoZSBkZXZpY2Ugc2hvdWxkIGhhdmUgc29tZSByZWNvdXJzZSBmb3IgdGhpcyBjYXNlLi4uDQoN Cg0KT3IgaWYgdGhlIGNvbm5lY3Rpb24gaXMgbm90IHBlcm1hbmVudCwgaXQgbWlnaHQgdHJ5IHRv IGNvbm5lY3QgYWdhaW4gYWZ0ZXINCnNvbWUgdGltZSBhbmQgZm9yIHNvbWUgcmVhc29uIGl0IGNh biBub3QuDQoNCj4NCj5Ob3JtYWxseSwgYSBkZXZpY2UgdW5hYmxlIHRvIGZpbmQgYSBDb25maWds ZXQgd291bGQgdWx0aW1hdGVseSBkbyBhIG5vcm1hbA0KPmJvb3QsIGFzIGl0J3MgbW9zdCBsaWtl bHkgYW4gYWRtaW4gaXMgd2FpdGluZyB0byBsb2cgaW50byBpdC4gIEluIHRoaXMNCj5jYXNlLCB0 aGUgZGV2aWNlIGhhcyB0cmlnZ2VyIGxvZ2ljIGhhdCBzaG91bGQgZXNzZW50aWFsbHkgdGVsbHMg aXQgdG8gcnVuDQo+aGVhZGxlc3MsIHNvIGZvcmV2ZXIgY2hlY2tpbmcgZm9yIGFuIHVwZGF0ZWQg Q29uZmlnbGV0IG1heSBiZSBhcHByb3ByaWF0ZS4NCg0KDQpTb21lIHN1Z2dlc3Rpb25zIChub3Qg bXV0dWFsbHkgZXhjbHVzaXZlKToNCg0KLSBHaXZlbiBkZXZpY2UgaGFzIGNyZWRlbnRpYWxzIHRv IGRvd25sb2FkIGEgY29uZmlnbGV0IG1heWJlIGl0IHNob3VsZCBiZQ0KYWJsZSB0byChsHBvc3Sh sSBzb21ldGhpbmcgYXMgd2VsbDogobBJoa9tIGRldmljZSBBQkMgYW5kIGNhbiBub3QgY29ubmVj dCB0bw0KTk1TobEgKHNlZSBiZWxvdyBhYm91dCByZWxheSkuDQoNCi0gQ29ubmVjdGlvbiB0byBj b25maWdsZXQgaXMgSFRUUCAob3Igc29tZSBvdGhlciBwcm90b2NvbCB0aGF0IGFsbG93cw0Kbm90 aWZpY2F0aW9ucykgYW5kIHNlcnZlciBjb3VsZCBzZW5kIGEgbm90aWZpY2F0aW9uIHdoZW4gc29t ZXRoaW5nIGNoYW5nZXMuDQoNCi0gQW5kIHRoZSB0aGUgbGVhc3QgY29tbW9uIGRlbm9taW5hdG9y IGlzIHRvIHBlcmZvcm0gcGVyaW9kaWMgKG9yDQpleHBvbmVudGlhbCBiYWNrIG9mZiBjaGVja3Mp IHVudGlsIHNvbWUgY2VpbGluZy4NCg0KDQo+IA0KPg0KPkkgZG9uJ3Qga25vdywgImZvcmV2ZXIi IGxvb3BpbmcgZG9lc24ndCBzb3VuZCByaWdodC4gIEFuZCB3YWl0aW5nIGV2ZW4gYQ0KPmZldyBt aW51dGVzIGlzIHVubGlrZWx5IHRvIHByb2R1Y2UgYSBuZXcgQ29uZmlnbGV0LCBnaXZlbiB0aGF0 IGl0J3MgYW4NCj5hdXRvbWF0ZWQgc3lzdGVtIGFuZCB0aGUgTk1TIHdpbGwgaGF2ZSBubyBhbGVy dCBmb3IgYSBkZXZpY2UgZmFpbGluZyB0bw0KPmNvbm5lY3QsIGFuZCBoZW5jZSBpdCdzIHVubGlr ZWx5IHRoZSBDb25maWdsZXQgd2lsbCBnZXQgZml4ZWQgc28gcXVpY2tseS4NCg0KSWYgY29uZmln bGV0IHNlcnZlciBpcyByZWFjaGFibGUgYnkgYm90aCBwYXJ0aWVzLCB0aGVuIGl0IGNvdWxkIHJl bGF5DQptZXNzYWdlcyBmcm9tIG9uZSB0byB0aGUgb3RoZXIuDQoNCk90aGVyd2lzZSwgY2hlY2tp bmcgdW50aWwgYSBjb25maWd1cmVkIG1heGltdW0gbGV2ZWwuDQoNCj4NCj5XaGF0IGRvIHlvdSB0 aGluaz8NCj4NCj5UaGFua3MsDQo+S2VudA0KPg0KPg0KDQo= From nobody Tue Feb 25 13:10: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 66EFD1A0293 for ; Tue, 25 Feb 2014 13:10:32 -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 voDa4emsE47E for ; Tue, 25 Feb 2014 13:10:27 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe004.messaging.microsoft.com [65.55.88.14]) by ietfa.amsl.com (Postfix) with ESMTP id BF23D1A0290 for ; Tue, 25 Feb 2014 13:10:24 -0800 (PST) Received: from mail101-tx2-R.bigfish.com (10.9.14.252) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 21:10:23 +0000 Received: from mail101-tx2 (localhost [127.0.0.1]) by mail101-tx2-R.bigfish.com (Postfix) with ESMTP id 9A8AF4A0165; Tue, 25 Feb 2014 21:10:23 +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: 0 X-BigFish: VPS0(z579ehzzz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail101-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=BL2PRD0510HT003.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(6009001)(199002)(189002)(81542001)(36756003)(92726001)(81342001)(93516002)(90146001)(47736001)(54316002)(54356001)(56816005)(47976001)(50986001)(49866001)(93136001)(69226001)(76786001)(74366001)(74706001)(81816001)(59766001)(56776001)(77982001)(86362001)(4396001)(81686001)(76482001)(65816001)(80022001)(74502001)(66066001)(63696002)(2656002)(87266001)(31966008)(47446002)(74662001)(83072002)(92566001)(51856001)(83506001)(95416001)(46102001)(77096001)(85852003)(53806001)(76796001)(74876001)(85306002)(94316002)(79102001)(87936001)(83322001)(94946001)(80976001)(95666003); DIR:OUT; SFP:1101; SCL:1; SRVR:BLUPR05MB706; H:CO1PR05MB458.namprd05.prod.outlook.com; CLIP:66.129.241.13; FPR:BEFEF015.9F12E515.70F19DEF.86F4FB59.202B7; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Received: from mail101-tx2 (localhost.localdomain [127.0.0.1]) by mail101-tx2 (MessageSwitch) id 1393362621357663_16354; Tue, 25 Feb 2014 21:10:21 +0000 (UTC) Received: from TX2EHSMHS036.bigfish.com (unknown [10.9.14.239]) by mail101-tx2.bigfish.com (Postfix) with ESMTP id 506DA801E2; Tue, 25 Feb 2014 21:10:21 +0000 (UTC) Received: from BL2PRD0510HT003.namprd05.prod.outlook.com (157.56.240.101) by TX2EHSMHS036.bigfish.com (10.9.99.136) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 21:10:20 +0000 Received: from BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) by BL2PRD0510HT003.namprd05.prod.outlook.com (10.255.100.38) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 21:10:19 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by BLUPR05MB706.namprd05.prod.outlook.com (10.141.207.13) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 21:10:18 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 21:10:17 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAP//0pcA Date: Tue, 25 Feb 2014 21:10:16 +0000 Message-ID: References: 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.13] x-forefront-prvs: 01334458E5 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/j0g-2TlO7sfsYuJjvS3j8sx0G6k Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 21:10:32 -0000 >Or if the connection is not permanent, it might try to connect again after >some time and for some reason it can not. Since you said "connect again", it's not ZeroTouch, but it is still Call-Home, the configuration for which is described in draft-kwatsen-netconf-server. As you can see, for high-availablilty, it enables a list of server IP/port values to be specified. >- Given device has credentials to download a configlet maybe it should be >able to =B3post=B2 something as well: =B3I=B9m device ABC and can not conn= ect to >NMS=B2 (see below about relay). Well, the device has a private key that could be used to sign a message it POSTs back to the Configuration Server, which could authenticate the message before writing it - seems possible, but would need to be added to the draft. >- Connection to configlet is HTTP (or some other protocol that allows >notifications) and server could send a notification when something >changes. I didn't follow this - who is send what and how? >- And the the least common denominator is to perform periodic (or >exponential back off checks) until some ceiling. Well, this is what I was getting at before, a ceiling of 5 minutes probably isn't enough, while any longer may be too much... >If configlet server is reachable by both parties, then it could relay >messages from one to the other. While it's true that the device can connect to it, it's not (currently) the case that the NMS is. The draft says that the Configuration Server's admin-facing interface is unspecified, thus there's no standard for a NMS to use. K. From nobody Tue Feb 25 13:29: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 2C47C1A079D for ; Tue, 25 Feb 2014 13:28:58 -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 OX2Oj6QFDboh for ; Tue, 25 Feb 2014 13:28:53 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) by ietfa.amsl.com (Postfix) with ESMTP id 066E01A076C for ; Tue, 25 Feb 2014 13:28:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16478; q=dns/txt; s=iport; t=1393363732; x=1394573332; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=Wn+fdco6ITmFMeN09NW8qf10tNqxl+ogDZUKEn0J/nQ=; b=e2qBbmvLwFS4KWhsGP63Nk6j7FFX+bpe1kKpyTSpTBIwZ3ItRaW/1KUP YxAVc5mvGBNnVNUZJTFowe1GcIMovgNUkJUqhnfdQcO6OYXzHYvUxN5N3 9YVQSLaNqvQWhHTfmQy2rFRsNM30TXuY/EPGsyGivmm8kgFN/a69hTMZv E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAPgJDVOtJXG//2dsb2JhbABZgkJEO1EGuHeIWYEaFnSCJQEBAQQBAQFrCxIBCBEDAQIoLgsUCQgCBAENBQmHfAgFyC0XjWRbDQQGAQYDhC8EmDaBMosyhUSDLYFxOQ X-IronPort-AV: E=Sophos; i="4.97,542,1389744000"; d="scan'208,217"; a="23132010" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by alln-iport-3.cisco.com with ESMTP; 25 Feb 2014 21:28:51 +0000 Received: from xhc-aln-x01.cisco.com (xhc-aln-x01.cisco.com [173.36.12.75]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1PLSprs031496 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 21:28:51 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-aln-x01.cisco.com ([173.36.12.75]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 15:28:51 -0600 From: "Alberto Gonzalez Prieto (albertgo)" To: Andy Bierman , "Yi Yang (yiya)" Thread-Topic: [Netconf] Fwd: I-D Action: draft-bierman-netconf-restconf-04.txt Thread-Index: AQHPKQi55ZiVQzOCGEa56F+k4ZHu9JrG1Z4AgAANDgCAAAIogIAABE8A//+EZoA= Date: Tue, 25 Feb 2014 21:28:50 +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.127] Content-Type: multipart/alternative; boundary="_000_CF3244CD4D352albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/kQf51C4CUqrJTgZ5MsQuFCwzYbw 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, 25 Feb 2014 21:28:58 -0000 --_000_CF3244CD4D352albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_CF3244CD4D352albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
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>
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_CF3244CD4D352albertgociscocom_-- From nobody Tue Feb 25 13:36: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 B22D41A0763 for ; Tue, 25 Feb 2014 13:35:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.598 X-Spam-Level: X-Spam-Status: No, score=-7.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_CHARSET_FARAWAY=2.45, 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 kgV7abjKRE2i for ; Tue, 25 Feb 2014 13:35:54 -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 2BE931A02BC for ; Tue, 25 Feb 2014 13:35:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3540; q=dns/txt; s=iport; t=1393364153; x=1394573753; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=xI8iY+l0pia5YpOY2+kUA2y1XynCGdki3cLdjAUUUTo=; b=Th7+uSR3kVN7ypXMpoAWxto5mTIPNIsBoHHTbxIBbpaKGJVmf82l9Urp JtS8ANVlGemEc3/rm8OdRgYk4tIQLf+ahMECEfAg57qVJIFzgObiQpDU/ S1L63dgrS+PrWR2jmOd9wAz05m3JyKt+vbq9NuVWFjoOLrLNLYb0NmR9h s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao4FAFYMDVOtJXHA/2dsb2JhbABZgwY7V4I5Sr5NGIECFnSCLAwoVwEGAg4OKAQwJQIEARIbh2qLJpt3BqEWF4EjjHo6gmmBTwEDmDaSKIMtgWgHOw X-IronPort-AV: E=Sophos;i="4.97,542,1389744000"; d="scan'208";a="23136308" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-1.cisco.com with ESMTP; 25 Feb 2014 21:35:48 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PLZlfC007756 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 21:35:47 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 15:35:47 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAP//0pcAgAA5YwA= Date: Tue, 25 Feb 2014 21:35:47 +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.74.73] Content-Type: text/plain; charset="euc-kr" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/9coSzzhnwcnrRkugc8UU2uTOI-8 Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 21:35:58 -0000 DQoNCk9uIDIvMjUvMTQsIDE6MTAgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5u ZXQ+IHdyb3RlOg0KDQo+DQo+DQo+DQo+Pk9yIGlmIHRoZSBjb25uZWN0aW9uIGlzIG5vdCBwZXJt YW5lbnQsIGl0IG1pZ2h0IHRyeSB0byBjb25uZWN0IGFnYWluDQo+PmFmdGVyDQo+PnNvbWUgdGlt ZSBhbmQgZm9yIHNvbWUgcmVhc29uIGl0IGNhbiBub3QuDQo+DQo+DQo+U2luY2UgeW91IHNhaWQg ImNvbm5lY3QgYWdhaW4iLCBpdCdzIG5vdCBaZXJvVG91Y2gsDQoNCg0KVGhlIGRlZmluaXRpb24g b2YgobBaZXJvVG91Y2ihsSBpcyBub3QgY2xlYXIuIFRoaXMgaXMgYSB0ZXJtIEkgdXN1YWxseQ0K YXNzb2NpYXRlIHdpdGggQm9uam91ciB3aGVyZSB0aGVyZSBpcyBmdWxsIGRlY2VudHJhbGl6YXRp b24gKG1ETlMpIGFuZA0KYnVpbHQtaW4gZmFpbHVyZSByZWNvdmVyeS4gSW4gdGhpcyBjYXNlIG9u ZSBjb3VsZCBhcmd1ZSB0aGlzIHNvbHV0aW9uIGlzDQpub3QgWmVyb3VUb3VjaC4gDQoNCg0KVGhl cmUgaXQgc2VlbXMgdG8gbWUgdGhpcyBzb2x1dGlvbiBzaG91bGQgYXNzdW1lIGZhaWx1cmVzL2No YW5nZXMgYW5kDQpwcm92aWRlIHByb3RlY3Rpb24gZnJvbSBpdCBpbiB0aGUgcHJvdG9jb2wgaW5z dGVhZCBvZiBqdXN0IGFzc3VtaW5nIHlvdQ0KaGF2ZSBtb3JlIG9mIHRoZSBzYW1lLg0KDQoNCj5i dXQgaXQgaXMgc3RpbGwNCj5DYWxsLUhvbWUsIHRoZSBjb25maWd1cmF0aW9uIGZvciB3aGljaCBp cyBkZXNjcmliZWQgaW4NCj5kcmFmdC1rd2F0c2VuLW5ldGNvbmYtc2VydmVyLiAgQXMgeW91IGNh biBzZWUsIGZvciBoaWdoLWF2YWlsYWJsaWx0eSwgaXQNCj5lbmFibGVzIGEgbGlzdCBvZiBzZXJ2 ZXIgSVAvcG9ydCB2YWx1ZXMgdG8gYmUgc3BlY2lmaWVkLg0KDQpTZWUgZGlzY3Vzc2lvbiBhYm92 ZS4gIENhbiB3ZSBwcm92aWRlIG5hbWVzIGluc3RlYWQgb2YgYWRkcmVzc2VzPw0KDQo+DQo+DQo+ Pi0gR2l2ZW4gZGV2aWNlIGhhcyBjcmVkZW50aWFscyB0byBkb3dubG9hZCBhIGNvbmZpZ2xldCBt YXliZSBpdCBzaG91bGQgYmUNCj4+YWJsZSB0byCp+HBvc3Sp9yBzb21ldGhpbmcgYXMgd2VsbDog qfhJqfZtIGRldmljZSBBQkMgYW5kIGNhbiBub3QgY29ubmVjdCB0bw0KPj5OTVOp9yAoc2VlIGJl bG93IGFib3V0IHJlbGF5KS4NCj4NCj5XZWxsLCB0aGUgZGV2aWNlIGhhcyBhIHByaXZhdGUga2V5 IHRoYXQgY291bGQgYmUgdXNlZCB0byBzaWduIGEgbWVzc2FnZSBpdA0KPlBPU1RzIGJhY2sgdG8g dGhlIENvbmZpZ3VyYXRpb24gU2VydmVyLCB3aGljaCBjb3VsZCBhdXRoZW50aWNhdGUgdGhlDQo+ bWVzc2FnZSBiZWZvcmUgd3JpdGluZyBpdCAtIHNlZW1zIHBvc3NpYmxlLCBidXQgd291bGQgbmVl ZCB0byBiZSBhZGRlZCB0bw0KPnRoZSBkcmFmdC4NCj4NCj4NCj4+LSBDb25uZWN0aW9uIHRvIGNv bmZpZ2xldCBpcyBIVFRQIChvciBzb21lIG90aGVyIHByb3RvY29sIHRoYXQgYWxsb3dzDQo+Pm5v dGlmaWNhdGlvbnMpIGFuZCBzZXJ2ZXIgY291bGQgc2VuZCBhIG5vdGlmaWNhdGlvbiB3aGVuIHNv bWV0aGluZw0KPj5jaGFuZ2VzLg0KPg0KPkkgZGlkbid0IGZvbGxvdyB0aGlzIC0gd2hvIGlzIHNl bmQgd2hhdCBhbmQgaG93Pw0KDQoNCkNvbmZpZ2xldCBzZXJ2ZXIgaXMgYSBIVFRQIHNlcnZlciwg ZGV2aWNlIGlzIEhUVFAgY2xpZW50LiBIVFRQIHNlcnZlciBzZW5kDQpzZXJ2ZXItc2lkZSBub3Rp ZmljYXRpb24gdG8gY2xpZW50IHdoZW4gY29uZmlnbGV0IGNoYW5nZXMuDQoNCj4NCj4NCj4+LSBB bmQgdGhlIHRoZSBsZWFzdCBjb21tb24gZGVub21pbmF0b3IgaXMgdG8gcGVyZm9ybSBwZXJpb2Rp YyAob3INCj4+ZXhwb25lbnRpYWwgYmFjayBvZmYgY2hlY2tzKSB1bnRpbCBzb21lIGNlaWxpbmcu DQo+DQo+V2VsbCwgdGhpcyBpcyB3aGF0IEkgd2FzIGdldHRpbmcgYXQgYmVmb3JlLCBhIGNlaWxp bmcgb2YgNSBtaW51dGVzDQo+cHJvYmFibHkgaXNuJ3QgZW5vdWdoLCB3aGlsZSBhbnkgbG9uZ2Vy IG1heSBiZSB0b28gbXVjaC4uLg0KDQoNCldlbGwsIGluIHRoZSBmaXJzdCAxIG1pbnV0ZSBvciBz byBUQ1Agd2lsbCByZXRyeSBvbiBpdHMgb3duIHVudGlsIGl0IGdpdmVzDQp1cC4NCg0KQWZ0ZXIg dGhhdCBpZiBjbGllbnQgcmV0cmllcyBldmVyeSBOICgyLTUpIG1pbnV0ZXMgSSB3b3VsZCBub3Qg YmUNCmNvbmNlcm5lZCB3aXRoIGFueSBzY2FsYWJpbGl0eSBpc3N1ZXMuDQoNCj4NCj4NCj4+SWYg Y29uZmlnbGV0IHNlcnZlciBpcyByZWFjaGFibGUgYnkgYm90aCBwYXJ0aWVzLCB0aGVuIGl0IGNv dWxkIHJlbGF5DQo+Pm1lc3NhZ2VzIGZyb20gb25lIHRvIHRoZSBvdGhlci4NCj4NCj5XaGlsZSBp dCdzIHRydWUgdGhhdCB0aGUgZGV2aWNlIGNhbiBjb25uZWN0IHRvIGl0LCBpdCdzIG5vdCAoY3Vy cmVudGx5KQ0KPnRoZSBjYXNlIHRoYXQgdGhlIE5NUyBpcy4gIFRoZSBkcmFmdCBzYXlzIHRoYXQg dGhlIENvbmZpZ3VyYXRpb24gU2VydmVyJ3MNCj5hZG1pbi1mYWNpbmcgaW50ZXJmYWNlIGlzIHVu c3BlY2lmaWVkLCB0aHVzIHRoZXJlJ3Mgbm8gc3RhbmRhcmQgZm9yIGEgTk1TDQo+dG8gdXNlLg0K Pg0KPg0KPksuDQo+DQo+DQoNCg== From nobody Tue Feb 25 13:41: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 B9A5A1A02C0 for ; Tue, 25 Feb 2014 13:40:57 -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 yzoSy742-RAG for ; Tue, 25 Feb 2014 13:40:53 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id 3D0C21A024A for ; Tue, 25 Feb 2014 13:40:52 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so1092759qab.40 for ; Tue, 25 Feb 2014 13:40:51 -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=Igs+hCEnFyCVkhWg13hhLqfnpuUjK+1N1govSCZetZY=; b=E6lORcwpyAcNQsOTFNYbzoDhGoZ4x7D0yJWQtXPfIf+mXA9WijmeimwL0mEFlVfl91 sZWQ5CMEwXXuUjnVC4OiiS4iPZD6QHj/O6Q7A2YxmeHK4NnCv2PEjLnU8tc9f2Q+eDG8 K4s1xNeTOcPZDzjT1PxaPIDEiKjyf2n2qfHHQA/C7xtOJO85ktMqzLvcE7q2GYrmnqp+ 7hQvFIeQZ0pvPTKONBffPLeFhpAVRuLCltCZ2qRwjREfwIyEBMtyA6GUBRewpr3YQSNj deTfm5Tp/Cfy4BsOcawcPiHu+JpzB2NdjZnY+6dO6GkSqxfQg/RyZyXLIDTV1oIp89gp DuWw== X-Gm-Message-State: ALoCoQmfVOLw/LzaCP792xlqCPje6WMkz12AG20RDG/Yf1tASTt94JLmnaPK2cTz/LyR3W/TA5aj MIME-Version: 1.0 X-Received: by 10.140.104.103 with SMTP id z94mr2808072qge.91.1393364451030; Tue, 25 Feb 2014 13:40:51 -0800 (PST) Received: by 10.140.104.194 with HTTP; Tue, 25 Feb 2014 13:40:50 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 13:40:50 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a1134f2be25caf804f341f132 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/O_aRNvbEpQ6Ese3SVasLPX_qKTg 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, 25 Feb 2014 21:40:57 -0000 --001a1134f2be25caf804f341f132 Content-Type: text/plain; charset=ISO-8859-1 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 >>> >>> >> > --001a1134f2be25caf804f341f132 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

This URI syntax maps to the path co= mponent, defined in RFC 3986, sec. 3.3.
Paragraph 5 suggest the s= emi-colon or comma reserved characters to delimit
parameters. &nb= sp;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 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

--001a1134f2be25caf804f341f132-- From nobody Tue Feb 25 13:50:52 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 2973F1A06E8 for ; Tue, 25 Feb 2014 13:50:50 -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 toge6_-Nlfmn for ; Tue, 25 Feb 2014 13:50:42 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe002.messaging.microsoft.com [213.199.154.205]) by ietfa.amsl.com (Postfix) with ESMTP id 7694D1A0257 for ; Tue, 25 Feb 2014 13:50:42 -0800 (PST) Received: from mail6-am1-R.bigfish.com (10.3.201.239) by AM1EHSOBE026.bigfish.com (10.3.207.148) with Microsoft SMTP Server id 14.1.225.22; Tue, 25 Feb 2014 21:50:40 +0000 Received: from mail6-am1 (localhost [127.0.0.1]) by mail6-am1-R.bigfish.com (Postfix) with ESMTP id E0F92460442; Tue, 25 Feb 2014 21:50:40 +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: -1 X-BigFish: VPS-1(z579ehz1432Izz1f42h2148h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzzz2fh109h2a8h839h947he5bhf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h209eh2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25cch1155h) Received-SPF: pass (mail6-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=BL2PRD0510HT002.namprd05.prod.outlook.com ; .outlook.com ; X-Forefront-Antispam-Report-Untrusted: SFV:NSPM; SFS:(10009001)(979002)(6009001)(51704005)(189002)(199002)(36756003)(86362001)(47446002)(92726001)(92566001)(95416001)(31966008)(94946001)(74662001)(74502001)(87936001)(50986001)(53806001)(54356001)(54316002)(76482001)(2656002)(83322001)(83072002)(95666003)(80976001)(74366001)(87266001)(51856001)(81686001)(85852003)(85306002)(94316002)(81816001)(59766001)(77982001)(79102001)(47736001)(47976001)(49866001)(81342001)(65816001)(66066001)(80022001)(69226001)(77096001)(83506001)(63696002)(81542001)(74706001)(74876001)(46102001)(56776001)(56816005)(76796001)(90146001)(76786001)(93136001)(4396001)(93516002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1101; SCL:1; SRVR:CO2PR05MB778; H:CO1PR05MB458.namprd05.prod Received: from mail6-am1 (localhost.localdomain [127.0.0.1]) by mail6-am1 (MessageSwitch) id 1393365038611983_25092; Tue, 25 Feb 2014 21:50:38 +0000 (UTC) Received: from AM1EHSMHS006.bigfish.com (unknown [10.3.201.236]) by mail6-am1.bigfish.com (Postfix) with ESMTP id 875F93200C2; Tue, 25 Feb 2014 21:50:38 +0000 (UTC) Received: from BL2PRD0510HT002.namprd05.prod.outlook.com (157.56.240.101) by AM1EHSMHS006.bigfish.com (10.3.207.106) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 25 Feb 2014 21:50:38 +0000 Received: from CO2PR05MB778.namprd05.prod.outlook.com (10.141.226.151) by BL2PRD0510HT002.namprd05.prod.outlook.com (10.255.100.37) with Microsoft SMTP Server (TLS) id 14.16.411.0; Tue, 25 Feb 2014 21:50:33 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com (10.141.72.140) by CO2PR05MB778.namprd05.prod.outlook.com (10.141.226.151) with Microsoft SMTP Server (TLS) id 15.0.883.10; Tue, 25 Feb 2014 21:50:31 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.11]) with mapi id 15.00.0883.010; Tue, 25 Feb 2014 21:50:31 +0000 From: Kent Watsen To: "Reinaldo Penno (repenno)" , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAP//0pcAgAA5YwD//9HcgA== Date: Tue, 25 Feb 2014 21:50:31 +0000 Message-ID: References: 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.13] x-forefront-prvs: 01334458E5 Content-Type: text/plain; charset="iso-8859-1" Content-ID: <4E5B08397C2A1D4B917C2C3D9595CCD9@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/L7x8erOshULz51mjUnJ8tsUDQRA Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 21:50:50 -0000 >The definition of =B3ZeroTouch=B2 is not clear. This is a term I usually >associate with Bonjour where there is full decentralization (mDNS) and >built-in failure recovery. In this case one could argue this solution is >not ZerouTouch. Formally, we're talking about "NETCONF Zero Touch". >There it seems to me this solution should assume failures/changes and >provide protection from it in the protocol instead of just assuming you >have more of the same. Suggestions welcomed! >See discussion above. Can we provide names instead of addresses? Yes, of course, any URI is supported. >Configlet server is a HTTP server, device is HTTP client. HTTP server send >server-side notification to client when configlet changes. Excellent, it's clear now. But it's questionable value over the device polling the server. Besides, how would it work for non-HTTP based Configuration servers? (FTP, SCP, etc.) >Well, in the first 1 minute or so TCP will retry on its own until it gives >up. > >After that if client retries every N (2-5) minutes I would not be >concerned with any scalability issues. Not a scalability issue for me, it's a "what's the right thing" to do issue. =20 Maybe this needs to be configurable? Do you have a suggestion for text to add to the draft? K. From nobody Tue Feb 25 14:07: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 EF81A1A07B3 for ; Tue, 25 Feb 2014 14:07:15 -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 WNWXwJlNzoef for ; Tue, 25 Feb 2014 14:07:12 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id 1DD621A0298 for ; Tue, 25 Feb 2014 14:07:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=589; q=dns/txt; s=iport; t=1393366031; x=1394575631; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=qtu35WzrFwVE6BpPIrgGx1m/XgSgk0EIVMtMR+vD//0=; b=Q0tGw5h6S8tIxOEsXDQ3hIkk2kpJs/TcpYb+P+JiSDjihhIU6YMRrOQi oc6bzxTXfIupo8ifp0FAlyA3DUU7H/6ghVSc9mc2Vh51LCy3ExX5dbX0S cMkcwR4pFUNm7uO5Y7uvdDS5AYlzZbpD+QttgFLRXvuje1DMdg0XtVHWS o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAFETDVOtJXHA/2dsb2JhbABZgwY7V8FQgRoWdIIsOlEBCA4oQiUCBAESiAXIQxeOV4Q4AQOYNpIogy2CKg X-IronPort-AV: E=Sophos;i="4.97,542,1389744000"; d="scan'208";a="23153371" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-8.cisco.com with ESMTP; 25 Feb 2014 22:07:10 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1PM7A1C009824 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 22:07:10 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 16:07:10 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAP//0pcAgAA5YwD//9HcgAAG3TOA Date: Tue, 25 Feb 2014 22:07:10 +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.74.73] Content-Type: text/plain; charset="us-ascii" Content-ID: <4BAF338D553BB144B40F211FC807D0CB@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/EVnk91Bu03JM2kBcaF5fbfGaYTA Subject: Re: [Netconf] zerotouch discussion (was: 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, 25 Feb 2014 22:07:16 -0000 I guess it would not work. It is a choice of which protocol to use. If HTTP is used you get this capability (possibly even through RESTconf), other protocols are outside the scope. On 2/25/14, 1:50 PM, "Kent Watsen" wrote: >>Configlet server is a HTTP server, device is HTTP client. HTTP server >>send >>server-side notification to client when configlet changes. > > >Excellent, it's clear now. But it's questionable value over the device >polling the server. Besides, how would it work for non-HTTP based >Configuration servers? (FTP, SCP, etc.) From nobody Tue Feb 25 15: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 5B5E71A033A for ; Tue, 25 Feb 2014 15:00:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.047 X-Spam-Level: X-Spam-Status: No, score=-15.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, 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 BR-7heNIcA2O for ; Tue, 25 Feb 2014 15:00:51 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 79E401A00C2 for ; Tue, 25 Feb 2014 15:00:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19982; q=dns/txt; s=iport; t=1393369251; x=1394578851; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=w7pkD1aKn3PsiNLJUWEAn/6FoIJHCrz41/hraLnXZTQ=; b=EARUku4DWiHKHIt2u/scl7J2OmZ0jf8RpXQpQb5QdSYG00JhjhPfnaoY eJWWC5XdtDe1j7YdIoQHK53YyrLMMRrbK029MtSPlJvc9OJ5xOeuf3Zbq qAvF9EZ//guXTwt1AJO3C43oWgliRhg1g4KbeNlteGU9OxKSaQFhe+JpX E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGAMsfDVOtJXG8/2dsb2JhbABZgkJEO1EGuDeIWYEVFnSCJQEBAQQBAQFrCxIBCBEDAQIoLgsUCQgCBA4FCYd8CAXISReNZFsNBAYBBgOELwSYNoEyizKFRIMtgXE5 X-IronPort-AV: E=Sophos;i="4.97,543,1389744000"; d="scan'208,217";a="306452115" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-2.cisco.com with ESMTP; 25 Feb 2014 23:00:50 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id s1PN0oHK001497 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 23:00:50 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 17:00:49 -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//kDcA Date: Tue, 25 Feb 2014 23:00:49 +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.127] Content-Type: multipart/alternative; boundary="_000_CF3260254D486albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/Jva2euFwzyph0jFV-qkI_nnHTdY 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, 25 Feb 2014 23:00:57 -0000 --_000_CF3260254D486albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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 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_CF3260254D486albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <37B66496E35F23498080CC650ADDA6A4@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
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

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_CF3260254D486albertgociscocom_-- From nobody Tue Feb 25 15:15: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 852C61A033A for ; Tue, 25 Feb 2014 15:15:36 -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 wvBHwqRz_HIK for ; Tue, 25 Feb 2014 15:15:29 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0362B1A079E for ; Tue, 25 Feb 2014 15:15:28 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so1292479qae.13 for ; Tue, 25 Feb 2014 15:15:27 -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=JAYAU8yg7lzKJa8SPVTOheqYJyGJ4j8SLihQKipEkMo=; b=LAQfgPmH0H/0w7nl2pLcWPXq6lLuH5UYQb+Ys6lL3OReH/e3TSlbpMA8vr0r7R3YJq UJQYKYQVPNvRHmGIjSfosYbVa6J+rp9TP2RYgJ/nNcTGoL2yNgynbiBtBb9JMg45WSQn f6mtf745UosSHXTHo6ACeSldK5Ho1ZXWGgenR2+yrOnUHQOz20fFL9qtxkOXYafCrtEB kXlUBpMt4ZAzem26MfoD4CVQ3rBdcNjrZJ5bF+QPx9zScRhJ3D3kD43PcupNgIHU+X6W UGLo5l4BOQleJI/gM4eDEUzneLRcvsQ8IvAsXWzAxk6ZoN79Ngryx1KoH5Ito3CgbbKY 9ljQ== X-Gm-Message-State: ALoCoQlhRJx7CRKQZWV4K7KH8P7xHuxrZ56IcIFau8wjXkQuoqBcvfoHviKOheE6mO/8xyY+mDDP MIME-Version: 1.0 X-Received: by 10.229.139.199 with SMTP id f7mr6168071qcu.2.1393370127827; Tue, 25 Feb 2014 15:15:27 -0800 (PST) Received: by 10.140.104.194 with HTTP; Tue, 25 Feb 2014 15:15:27 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 15:15:27 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c3e45482cc1d04f343434e Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/jfBNQbejA2Ii4RGwQzc6meFKWRs 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, 25 Feb 2014 23:15:37 -0000 --001a11c3e45482cc1d04f343434e Content-Type: text/plain; charset=ISO-8859-1 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 >>>> >>>> >>> >> > --001a11c3e45482cc1d04f343434e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



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 gu= ess:

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


Actually I meant:

  container top {
     = list list1 {
       key "key1 key2 key3&= quot;;
       ...
       list list2 {
      &nbs= p;   key "key4 key5";
        =   ...
          leaf X { type strin= g; }
       }
     }=
  }

 /top/list1=3Dkey1val,key= 2val,key3val3/list2=3Dkey4val,key5val/X

The key names are redundant because they are in the YAN= G 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

--001a11c3e45482cc1d04f343434e-- From nobody Tue Feb 25 15:26: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 BAEE71A07E2 for ; Tue, 25 Feb 2014 15:26:43 -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 P3yHoE6NzSsh for ; Tue, 25 Feb 2014 15:26:37 -0800 (PST) Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id CF6501A07D2 for ; Tue, 25 Feb 2014 15:26:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24613; q=dns/txt; s=iport; t=1393370784; x=1394580384; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=TIT7CJOyX9RTdn9XTPdZN3s8trLV5wA0Z1F4d12/I58=; b=RU6rA3ftxnsdCyzS53XjKybPUt2QT8Mj0PWSgtA55C0A8OfK0Hm9kms7 R60Rpwjyio+GD5zA2JV/9HUdRRjwbjbwLy9pF0LUZaxy3trb05igsCuI5 dd759guC4ameXNI7lwmqFCUA9VY9oeKa3OAkvgvmUlV0+dx8ms7FH4Lpi I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsoGABMmDVOtJV2b/2dsb2JhbABZgkJEO1EGuCeIWYEUFnSCJQEBAQQBAQFrCxIBCBEDAQIhBy4LFAkIAgQOBQmHfAgFyEYXjWRbDQQGAQYDhC8EmDaBMosyhUSDLYFxOQ X-IronPort-AV: E=Sophos; i="4.97,543,1389744000"; d="scan'208,217"; a="23162943" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP; 25 Feb 2014 23:26:23 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s1PNQNYo029316 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 23:26:23 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.212]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 17:26:23 -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//3zsAA== Date: Tue, 25 Feb 2014 23:26:22 +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.127] Content-Type: multipart/alternative; boundary="_000_CF3264DF4D4B7albertgociscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/bT1R8cQLo7ukehm0p4JqIONzPZM 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, 25 Feb 2014 23:26:44 -0000 --_000_CF3264DF4D4B7albertgociscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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_CF3264DF4D4B7albertgociscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable
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_CF3264DF4D4B7albertgociscocom_-- From nobody Tue Feb 25 15:57: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 8F83F1A031D for ; Tue, 25 Feb 2014 15:57:45 -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 jz8Hj6jOblet for ; Tue, 25 Feb 2014 15:57:38 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 3AC1F1A0311 for ; Tue, 25 Feb 2014 15:57:38 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id r5so240523qcx.35 for ; Tue, 25 Feb 2014 15:57:37 -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=+/BulvRKjWd1BYOx7tbU+mxSFuRPRtPxYtvtaIAUzTA=; b=NTmczOES/zCjG/WwGbdDbyTeoUP1sABxTOp+ksP02hfkQKedvG2ecQ+IsqQdskCSg9 Xl+lXL+CN4R6UcTG38486rGyBiyRd6rRMe4GfQ8BKjNM7BdVO0QqRjxILNty+A6WC/Bl 8u4Xu7Yx2HcxgnhUYom3OaW5Avs8pdn176Ku4ViisuGVRL4gvIv4l+1cVO7+wZEeXgzd k3dDBByfn+r4a2ktTJXEt7pQ3hfBtlzBSp1Cg70dbtWmLz6CYqPin5gSJLSt7Gsqqyvv 0xVWqC+TvIqnJYSvcszKoHet8Vs7JLABGDokjGcUMvYelxV/P4nPoh8FSfiIZ6Z8Zzph d/Pg== X-Gm-Message-State: ALoCoQk7tVWVG1KaOUTmImfHxEYUytEFKy1XlNjpi+fn359/d13lm+uKvQxoSgffkYqpxRQRCG3I MIME-Version: 1.0 X-Received: by 10.224.66.8 with SMTP id l8mr4253195qai.16.1393372657086; Tue, 25 Feb 2014 15:57:37 -0800 (PST) Received: by 10.140.104.194 with HTTP; Tue, 25 Feb 2014 15:57:36 -0800 (PST) In-Reply-To: References: Date: Tue, 25 Feb 2014 15:57:36 -0800 Message-ID: From: Andy Bierman To: "Alberto Gonzalez Prieto (albertgo)" Content-Type: multipart/alternative; boundary=001a11c2c27a441f2804f343dafb Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/zvdCnKGEIgrxXoCdcRg1IjWd1aw 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, 25 Feb 2014 23:57:45 -0000 --001a11c2c27a441f2804f343dafb Content-Type: text/plain; charset=ISO-8859-1 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 >>>>> >>>>> >>>> >>> >> > --001a11c2c27a441f2804f343dafb Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi, 

What I proposed can be generi= cally 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, A= lberto Gonzalez Prieto (albertgo) <albertgo@cisco.com> wrot= e:
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

--001a11c2c27a441f2804f343dafb-- From nobody Wed Feb 26 10:49:26 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 639911A074A for ; Wed, 26 Feb 2014 10:49:17 -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 UPaAwDt7JODh for ; Wed, 26 Feb 2014 10:49:14 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 5BA111A0712 for ; Wed, 26 Feb 2014 10:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=519; q=dns/txt; s=iport; t=1393440553; x=1394650153; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=NEQDLDRVDjyVx++Y8aNHhnVS49GnbpWhFHDsFr42nbw=; b=C7eRsK5bxELKyT35MZrhyGhpJFJeJt0ptBHb81X/QN8LDIfDeUJrlwEE Tbnd9cqJkAP+ho9LoQhFCsDrMwuorf2rN3WDCqmG1INKdpP4jDBesbXKv YQK1iP7lJabj3Kfheums7YuBI+Rdp+XCzTVFZRHR7tQK69lhWpyeBa5tW M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFANk2DlOtJV2c/2dsb2JhbABagwaBEsBxgRoWdIIuOlEBCA4oQiUCBAESh3nJPReOW4Q3AQOYNpIogy2CKg X-IronPort-AV: E=Sophos;i="4.97,549,1389744000"; d="scan'208";a="306521613" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-1.cisco.com with ESMTP; 26 Feb 2014 18:48:52 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s1QImqt4029325 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 18:48:52 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.99]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 12:48:51 -0600 From: "Reinaldo Penno (repenno)" To: Kent Watsen , "Bert Wijnen (IETF)" , netconf Thread-Topic: zerotouch discussion (was: NETCONF call home and new port assignment) Thread-Index: AQHPMmfoLPdNEnoLdEq1+39DEgWiEprGSyAA///Q0oCAADTSAP//0pcAgAA5YwD//9HcgAAyOfiA Date: Wed, 26 Feb 2014 18:48:51 +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.124.23] Content-Type: text/plain; charset="us-ascii" Content-ID: <223505EDCC4C054393EA7C723C37460E@emea.cisco.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/6n3J3N2ceECGMJOXhiqmiO7ut7k Subject: Re: [Netconf] zerotouch discussion (was: 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: Wed, 26 Feb 2014 18:49:17 -0000 I am compiling my test suggestions and will send shortly. On 2/25/14, 1:50 PM, "Kent Watsen" wrote: >>Well, in the first 1 minute or so TCP will retry on its own until it >>gives >>up. >> >>After that if client retries every N (2-5) minutes I would not be >>concerned with any scalability issues. > > >Not a scalability issue for me, it's a "what's the right thing" to do >issue. =20 >Maybe this needs to be configurable? Do you have a suggestion for text to >add to the draft? From nobody Wed Feb 26 11:57: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 3C7CC1A0723 for ; Wed, 26 Feb 2014 11:57:23 -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 rbskgeGa1kf9 for ; Wed, 26 Feb 2014 11:57:21 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB7A1A0700 for ; Wed, 26 Feb 2014 11:57:20 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1QJvHTP025068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 26 Feb 2014 20:57:17 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1QJvH7G003614 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 26 Feb 2014 20:57:17 +0100 Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC001.nsn-intra.net (10.159.42.32) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 26 Feb 2014 20:57:16 +0100 Received: from DEMUMBX005.nsn-intra.net ([169.254.5.200]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Wed, 26 Feb 2014 20:57:16 +0100 From: "Ersue, Mehmet (NSN - DE/Munich)" To: "netconf@ietf.org" Thread-Topic: Agenda for the IETF 89 NETCONF Session Thread-Index: Ac8zLPJsgta67Gt3TwGztGlvUiszrw== Date: Wed, 26 Feb 2014 19:57:16 +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.119] Content-Type: multipart/alternative; boundary="_000_E4DE949E6CE3E34993A2FF8AE79131F82957D1DEMUMBX005nsnintr_" 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: 1854 X-purgate-ID: 151667::1393444637-00005322-12AB5707/0-0/0-0 Archived-At: http://mailarchive.ietf.org/arch/msg/netconf/XUPFgLftw-8vVO1y9GPfjM18EnM Subject: [Netconf] Agenda 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: Wed, 26 Feb 2014 19:57:23 -0000 --_000_E4DE949E6CE3E34993A2FF8AE79131F82957D1DEMUMBX005nsnintr_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear NETCONF WG, please find below the agenda for the NETCONF session in IETF #89: http://www.ietf.org/proceedings/89/agenda/agenda-89-netconf Please send your comments to the co-chairs. Regards, Mehmet --_000_E4DE949E6CE3E34993A2FF8AE79131F82957D1DEMUMBX005nsnintr_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Dear NETCONF WG,
 
please find below the agenda for the NETCONF s= ession in IETF #89:
 
Please send your comments to the co-chairs.
 
Regards,
Mehmet
 
 
 
 --_000_E4DE949E6CE3E34993A2FF8AE79131F82957D1DEMUMBX005nsnintr_--