From nobody Mon Sep 1 09:23:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 764AE1A0319; Mon, 1 Sep 2014 09:23:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 spf7EMpIliHF; Mon, 1 Sep 2014 09:23:32 -0700 (PDT) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2521A02DF; Mon, 1 Sep 2014 09:23:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1619; q=dns/txt; s=iport; t=1409588612; x=1410798212; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=HJodYw8JdwC68ueLFgpTnoCc2mkp/K5U8Wj6z1+sT8c=; b=TXV6ERGEqGDkL2jI9Qpj6SzK+Z0jxHvEHOXHP0k+wRZY4qrMob+UMqRv kj4kzQKIeUJjBauZZ3Z8iof8Cs2z96NRjKkdze6IASRngF2DphPAkwWbl f2s2cSG2lDiVm8AZXFcUc3wQaQttKD6ZLZuKt6eHcHOu+onTGZBzBepm4 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqEEAMacBFStJssW/2dsb2JhbABZ1AkBgSt3hAMBAQEDATIBBUAGCwsYCRYPCQMCAQIBRQYBDAgBARaIIAi5cAEXjnlbhEwBBJxchzeNZ4NjO4J+AQEB X-IronPort-AV: E=Sophos;i="5.04,443,1406592000"; d="scan'208";a="157278220" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP; 01 Sep 2014 16:23:28 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s81GNRuE023083; Mon, 1 Sep 2014 16:23:27 GMT Message-ID: <54049D7F.1010307@cisco.com> Date: Mon, 01 Sep 2014 18:23:27 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: "Joel M. Halpern" , i2rs@ietf.org, netmod@ietf.org References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> In-Reply-To: <20140901050331.GA70583@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pLiaHP0NkmLRtyOJVjfRAbVUBWw Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 16:23:33 -0000 Joel, On top of what Jürgen wrote, we stressed the need for such a requirement document to both I2RS chairs during the last IETF meeting. The good news is that some of the requirements were mentioned on the microphone during the Sunday YANG editing session and/or the NETMOD meeting (my memory fails me). Regards, Benoit > On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: >> Juergen, >> While I understand the request, I presume that such a request can >> not be met as a working group agreement in the time frame suggested. >> WHile I hope that some of the folks who have been involved in proposing >> the use of YANG for I2RS will write such a draft, I can not see how we >> could even get tot eh point of WG adoption of such a draft, much less WG >> rough consensus on the content, in the time frame you outline. >> Of course, I am not one of the chairs or ADs, but it seems pretty >> clear cut to me. > Joel, > > all I need is reasonably agreed upon input. Note that this request for > input is not coming out of the blue, at least not for those I2RS folks > who have been at the NETMOD meeting in Toronto. > > As NETMOD chair, I do have a target date to deliver YANG 1.1 and I > take that milestone serious. My motivation to delay this by N months > waiting for I2RS to get their input submitted is very small. I recall > that there were presentations about "what is missing" bach in London, > that is March 2014. The regular submission period for YANG 1.1 issues > was 2014-02-23 until 2014-05-07. The interim meeting is mid September. > > /js > From nobody Mon Sep 1 10:17:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 406D11A04BC for ; Mon, 1 Sep 2014 10:17:25 -0700 (PDT) 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=unavailable 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 jL1eSX7xLHkO for ; Mon, 1 Sep 2014 10:17:21 -0700 (PDT) Received: from mail-qc0-f174.google.com (mail-qc0-f174.google.com [209.85.216.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9576B1A04AB for ; Mon, 1 Sep 2014 10:17:15 -0700 (PDT) Received: by mail-qc0-f174.google.com with SMTP id i17so5593157qcy.19 for ; Mon, 01 Sep 2014 10:17:14 -0700 (PDT) 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=jJ/6Mfa+/YfPIrHqJuCG/KgY35aqrj9hGXQPcuW0xPY=; b=RDs7FU0Sqog/DI+aAJg9MS2taVV0a2oIfmxRE1VogvSgPj53ZTP69DGfNiC7soqbxe R2D8y/HtIiBKkg3ndlvtYeTLd6vlNUlpVCLrUC9iq3XGWu/nSzy+9e8hwbdLFQKyj9U6 D5qX+mB2S7B1yP1GMIV0YAGW52jmhhhtiZ1TXYH8TwEXSwdeBvjY5efoHpfQXbLV1mNm OKMamJD7AF1R/o06R18lxeat6Vf/3ZlcDa7tgt2sPha7YZpH+0+9/kKP/CI0RhEhOCxD gS4sIO5G3HY+kskYl5yDOc21EawP/M4ocne0L+wRecQx013oSuNlPBi8JZnHMyYTMfpF QvpA== X-Gm-Message-State: ALoCoQkoPH4oYh48Xai+gTdd1sbcOSykiAsL4Uhqix3R8V9DlsvAZBDs6182U0kKGJyGeZUxuZDN MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr47229635qcl.14.1409591834381; Mon, 01 Sep 2014 10:17:14 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 1 Sep 2014 10:17:14 -0700 (PDT) In-Reply-To: <54049D7F.1010307@cisco.com> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> Date: Mon, 1 Sep 2014 10:17:14 -0700 Message-ID: From: Andy Bierman To: Benoit Claise Content-Type: multipart/alternative; boundary=001a1134525691270b0502042cb9 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Bd--OTSHfSwfvvAT3IOfOpI4V-A Cc: "i2rs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 17:17:27 -0000 --001a1134525691270b0502042cb9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise wrote: > Joel, > > On top of what J=FCrgen wrote, we stressed the need for such a requiremen= t > document to both I2RS chairs during the last IETF meeting. > The good news is that some of the requirements were mentioned on the > microphone during the Sunday YANG editing session and/or the NETMOD meeti= ng > (my memory fails me). > > Regards, Benoit > > On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: >> >>> Juergen, >>> While I understand the request, I presume that such a request can >>> not be met as a working group agreement in the time frame suggested. >>> WHile I hope that some of the folks who have been involved in proposing >>> the use of YANG for I2RS will write such a draft, I can not see how we >>> could even get tot eh point of WG adoption of such a draft, much less W= G >>> rough consensus on the content, in the time frame you outline. >>> Of course, I am not one of the chairs or ADs, but it seems pretty >>> clear cut to me. >>> >> I agree with Joel that the I2RS does not have consensus on the details. The slides I presented in London and subsequent discussions suggest this solution: 1) define YANG extension to identify I2RS data so typedefs, etc. can be shared in config and state data models 2) define an I2RS datastore 3) define or extend a protocol to manage the I2RS datastore Let's say there is a new datastore added to the RESTCONF architecture for I2RS. Explain how this datastore works. It seems to have the same validation rules as YANG running config rules. The only difference seems to be that the I2RS datastore is not NV-saved (or NV-loaded at boot-time) like the running datastore. YANG 1.1 has some cleanup work planned to make the text less NETCONF-specific. I don't think there is much datastore and NV-store specific text that would need to change. Andy Joel, >> >> all I need is reasonably agreed upon input. Note that this request for >> input is not coming out of the blue, at least not for those I2RS folks >> who have been at the NETMOD meeting in Toronto. >> >> As NETMOD chair, I do have a target date to deliver YANG 1.1 and I >> take that milestone serious. My motivation to delay this by N months >> waiting for I2RS to get their input submitted is very small. I recall >> that there were presentations about "what is missing" bach in London, >> that is March 2014. The regular submission period for YANG 1.1 issues >> was 2014-02-23 until 2014-05-07. The interim meeting is mid September. >> >> /js >> >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1134525691270b0502042cb9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 1, 2014 at 9:23 AM, Benoit Claise <= ;bclaise@cisco.com> wrote:
Joel,

On top of what J=FCrgen wrote, we stressed the need for such a requirement = document to both I2RS chairs during the last IETF meeting.
The good news is that some of the requirements were mentioned on the microp= hone during the Sunday YANG editing session and/or the NETMOD meeting (my m= emory fails me).

Regards, Benoit

On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote:
Juergen,
=A0 =A0 =A0While I understand the request, I presume that such a request ca= n
not be met as a working group agreement in the time frame suggested.
WHile I hope that some of the folks who have been involved in proposing
the use of YANG for I2RS will write such a draft, I can not see how we
could even get tot eh point of WG adoption of such a draft, much less WG rough consensus on the content, in the time frame you outline.
=A0 =A0 =A0Of course, I am not one of the chairs or ADs, but it seems prett= y
clear cut to me.

<= div>I agree with Joel that the I2RS does not have consensus on the details.=

=A0 =A01) define YANG extension to identify I2RS data s= o typedefs, etc. can be shared
=A0 =A0 =A0 =A0in config and state= data models
=A0 =A02) define an I2RS datastore
=A0 =A0= 3) define or extend a protocol to manage the I2RS datastore

Let's say there is a new datastore added to the RES= TCONF architecture for I2RS.
Explain how this datastore works. = =A0It seems to have the same validation rules
as YANG running con= fig rules. =A0The only difference seems to be that the I2RS datastore
is not NV-saved (or NV-loaded at boot-time) like the running datastore= .

YANG 1.1 has some cleanup work planned to make t= he text less NETCONF-specific.
I don't think there is much da= tastore and NV-store specific text that would need to change.


Andy


=


Joel,

all I need is reasonably agreed upon input. Note that this request for
input is not coming out of the blue, at least not for those I2RS folks
who have been at the NETMOD meeting in Toronto.

As NETMOD chair, I do have a target date to deliver YANG 1.1 and I
take that milestone serious. My motivation to delay this by N months
waiting for I2RS to get their input submitted is very small. I recall
that there were presentations about "what is missing" bach in Lon= don,
that is March 2014. The regular submission period for YANG 1.1 issues
was 2014-02-23 until 2014-05-07. The interim meeting is mid September.

/js


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

--001a1134525691270b0502042cb9-- From nobody Mon Sep 1 14:25:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F0751A08BE for ; Mon, 1 Sep 2014 14:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 o0SJQdlA1lUK for ; Mon, 1 Sep 2014 14:25:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C24C1A08A7 for ; Mon, 1 Sep 2014 14:25:53 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 55467136E; Mon, 1 Sep 2014 23:25:52 +0200 (CEST) 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 bJ4cKmA6xum8; Mon, 1 Sep 2014 23:25:47 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Sep 2014 23:25:51 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EE16720035; Mon, 1 Sep 2014 23:25:50 +0200 (CEST) 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 gLRH28_BS_jm; Mon, 1 Sep 2014 23:25:50 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5F5AF20033; Mon, 1 Sep 2014 23:25:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4BBFF2E569F3; Mon, 1 Sep 2014 23:25:49 +0200 (CEST) Date: Mon, 1 Sep 2014 23:25:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140901212549.GC74917@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/hUGcStp8d86CQN77UnIaEX8Z3IE Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 21:25:56 -0000 On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: > > On 28 Aug 2014, at 17:32, Andy Bierman wrote: > > > Agreed -- if mixed mode XML and entities were allowed, then encoding > > the XML as a string would be best. > > > > OK, so would a string be better than an object? Something like this: > > An XML element that is an instance of a YANG anyxml data node is translated to a name/value pair where the value is a JSON string. The XML-JSON mapping of this string is not defined by this document. That is, the content of the XML instance may appear unchanged in this string value, or it may be processed in any way that’s appropriate for a given application. In the latter case, the definition of the anyxml data node SHOULD contain a description specifying the mapping of the XML content to JSON and vice versa. > Lada, I think we are talking about an _encoding_ not about _transformations_. The purpose of an encoding is to transfer data from A with B without making any modifications. Why do you insist that implementations can make arbitrary _transformation_? What does "appropriate for a given application" mean? How does the server know what an application needs and is it not far better to let the applications do whatever they want to be doing instead of outsourcing some of the work to the NC/RC server? I think I prefer this to be clearly defined and interoperable. /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 Sep 1 14:50:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD3D1A0AE2 for ; Mon, 1 Sep 2014 14:50:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 AqW3Ba1YHdkl for ; Mon, 1 Sep 2014 14:50:27 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AC4F1A0AD9 for ; Mon, 1 Sep 2014 14:50:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6AE731329; Mon, 1 Sep 2014 23:50:25 +0200 (CEST) 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 KjxDATL-R1Bo; Mon, 1 Sep 2014 23:50:20 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Sep 2014 23:50:24 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 83E1D20035; Mon, 1 Sep 2014 23:50:24 +0200 (CEST) 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 W6PhLLdoAOya; Mon, 1 Sep 2014 23:50:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0C25720033; Mon, 1 Sep 2014 23:50:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id EE42B2E56A7F; Mon, 1 Sep 2014 23:50:21 +0200 (CEST) Date: Mon, 1 Sep 2014 23:50:21 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140901215021.GD74917@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Cozb44qKdNPt1AShB67lznkVY6A Cc: netmod@ietf.org Subject: Re: [netmod] I-JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 21:50:29 -0000 On Wed, Aug 27, 2014 at 03:30:19PM +0200, Ladislav Lhotka wrote: > Hi, > > I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of > JSON that guarantees maximum interoperability for protocols that use > JSON in their messages, no matter what JSON encoders/decoders are used > in protocol implementations. This is exactly what e.g. RESTCONF needs, > so it would be useful to make JSON defined in the yang-json document > I-JSON compliant. > > A far as I can tell, these are the problematic parts: > > Encoding and Characters > ======================= > > - I-JSON requires UTF-8 encoding. Yang-json should do the same, which > may need recoding on the sender side. NETCONF also requires UTF-8 (2nd paragraph in section 3 of RFC 6241). > - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and > other types inherit XML character set which excludes surrogates but > not all noncharacters (for example, #xFDDO is allowed). The only > robust solution I can see is to ban noncharacters in YANG 1.1 - > yang-json cannot do it unilaterally. Hm. Feels somewhat bad to change YANG because a new encoding has some problems. I am not enough an expert in character sets to know what would be the 'right' thing to do. > Numbers > ======= > > - I-JSON messages SHOULD NOT include numbers which express greater > magnitude or precision than an IEEE 754 double precision number. This > affects YANG int64, uint64 and decimal64 types. Proposal: encode > values of these types as strings. Yep. I see no alternative. > Binary Data > =========== > > - In I-JSON, it is RECOMMENDED that this data be encoded in a string > value in base64url. YANG's binary type requires base64. I raised this > issue twice in the JSON WG mailing list > (http://www.ietf.org/mail-archive/web/json/current/msg03129.html, > http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody > offered any arguments why base64url should be better than base64 for > encoding field values, but I also found no support for changing the > current text. So the only option seems to be not to follow this I-JSON > recommendation (and provide reasoning). Carsten Bormann was strongly advocating base64url but he did not provide any clear reasons. Since we do not intend to send JSON as part of URLs, I think we are fine with using base64. It would be good to keep a list of open issues. Also add to it the encoding of unions and the handling of anyxml. Do we need a specific virtual interim meeting to close these open issues? I would like to get this document complete and into WG last call... /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 Sep 2 01:56:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EED3F1A0193 for ; Tue, 2 Sep 2014 01:56:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wJMM5lNQy6oo for ; Tue, 2 Sep 2014 01:56:06 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F92F1A0141 for ; Tue, 2 Sep 2014 01:56:05 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 39BC854060A; Tue, 2 Sep 2014 10:56:03 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoeJFSBBExHT; Tue, 2 Sep 2014 10:55:58 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id E8DCC540185; Tue, 2 Sep 2014 10:55:57 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140901212549.GC74917@elstar.local> References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 02 Sep 2014 10:55:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4Sbyr4zSabX8flPyTEuD_FI0C5o Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 08:56:09 -0000 Juergen Schoenwaelder writes: > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: >>=20 >> On 28 Aug 2014, at 17:32, Andy Bierman wrote: >>=20 >> > Agreed -- if mixed mode XML and entities were allowed, then encoding >> > the XML as a string would be best. >> >=20 >>=20 >> OK, so would a string be better than an object? Something like this: >>=20 >> An XML element that is an instance of a YANG anyxml data node is transla= ted to a name/value pair where the value is a JSON string. The XML-JSON map= ping of this string is not defined by this document. That is, the content o= f the XML instance may appear unchanged in this string value, or it may be = processed in any way that=E2=80=99s appropriate for a given application. In= the latter case, the definition of the anyxml data node SHOULD contain a d= escription specifying the mapping of the XML content to JSON and vice versa= .=20 >>=20 > > Lada, > > I think we are talking about an _encoding_ not about > _transformations_. The purpose of an encoding is to transfer data > from A with B without making any modifications. Why do you insist that > implementations can make arbitrary _transformation_? What does > "appropriate for a given application" mean? How does the server know > what an application needs and is it not far better to let the > applications do whatever they want to be doing instead of outsourcing > some of the work to the NC/RC server? I think I prefer this to be > clearly defined and interoperable. I am just saying that the encoding of the anyxml data *may* be different in JSON and XML. One reason could be that the XML content may not be valid without the "outer" XML context (NS-prefix mapping). I don't get why it should be an interoperability problem. Maybe a better term than "application-specific" is "anyxml-data-node-specific". In fact, I treated "anyxml" more like "anydata", and I also assume that XML needn't be the default and ever-present encoding. If a server uses anyxml f= or configuring a banner page with markup, and supports only JSON, I really see no reason why the content should be XML, which is what anyxml requires. Lada > > /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 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Sep 2 02:20:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 469711A01DD for ; Tue, 2 Sep 2014 02:20:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMhwJqyrCRB2 for ; Tue, 2 Sep 2014 02:20:02 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A208D1A01DC for ; Tue, 2 Sep 2014 02:20:01 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 171E454060A; Tue, 2 Sep 2014 11:20:00 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5KB+FdQAivi2; Tue, 2 Sep 2014 11:19:55 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C2373540336; Tue, 2 Sep 2014 11:19:55 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140901215021.GD74917@elstar.local> References: <20140901215021.GD74917@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 02 Sep 2014 11:19:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OxWEfL3XZFEzdduTPKqYhCjxlag Cc: netmod@ietf.org Subject: Re: [netmod] I-JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Sep 2014 09:20:07 -0000 Juergen Schoenwaelder writes: > On Wed, Aug 27, 2014 at 03:30:19PM +0200, Ladislav Lhotka wrote: >> Hi, >> >> I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of >> JSON that guarantees maximum interoperability for protocols that use >> JSON in their messages, no matter what JSON encoders/decoders are used >> in protocol implementations. This is exactly what e.g. RESTCONF needs, >> so it would be useful to make JSON defined in the yang-json document >> I-JSON compliant. >> >> A far as I can tell, these are the problematic parts: >> >> Encoding and Characters >> ======================= >> >> - I-JSON requires UTF-8 encoding. Yang-json should do the same, which >> may need recoding on the sender side. > > NETCONF also requires UTF-8 (2nd paragraph in section 3 of RFC 6241). So does RESTCONF, but we are talking about data without referring to a particular protocol. XML defines a way for specifying character encoding but JSON doesn't. If the intention is that UTF-8 be always used even in XML, then YANG spec should probably say so. > >> - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and >> other types inherit XML character set which excludes surrogates but >> not all noncharacters (for example, #xFDDO is allowed). The only >> robust solution I can see is to ban noncharacters in YANG 1.1 - >> yang-json cannot do it unilaterally. > > Hm. Feels somewhat bad to change YANG because a new encoding has some > problems. I am not enough an expert in character sets to know what > would be the 'right' thing to do. Neither am I but my understanding is that it is more of an omission on the XML side. If interoperability is our primary interest, I think noncharacters should be banned in XML, too. > >> Numbers >> ======= >> >> - I-JSON messages SHOULD NOT include numbers which express greater >> magnitude or precision than an IEEE 754 double precision number. This >> affects YANG int64, uint64 and decimal64 types. Proposal: encode >> values of these types as strings. > > Yep. I see no alternative. > >> Binary Data >> =========== >> >> - In I-JSON, it is RECOMMENDED that this data be encoded in a string >> value in base64url. YANG's binary type requires base64. I raised this >> issue twice in the JSON WG mailing list >> (http://www.ietf.org/mail-archive/web/json/current/msg03129.html, >> http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody >> offered any arguments why base64url should be better than base64 for >> encoding field values, but I also found no support for changing the >> current text. So the only option seems to be not to follow this I-JSON >> recommendation (and provide reasoning). > > Carsten Bormann was strongly advocating base64url but he did not > provide any clear reasons. Since we do not intend to send JSON as > part of URLs, I think we are fine with using base64. Right, but if our goal is to be able to say that JSON encoding of YANG-based instances is I-JSON, then I don't know whether we can do so if we ignore RECOMMENDED encoding just for legacy reasons. > > It would be good to keep a list of open issues. Also add to it the > encoding of unions and the handling of anyxml. Do we need a specific > virtual interim meeting to close these open issues? I would like to > get this document complete and into WG last call... I hope we can decide the open issues in the mailing list, that's why I opened them there. BTW, speaking about virtual interims, I will be travelling again tomorrow afternoon, but I hope I will miss only first twenty minutes or so. Lada > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Sep 2 23:23:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 127311A7015 for ; Tue, 2 Sep 2014 23:23:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 IZugyZe9EEJ2 for ; Tue, 2 Sep 2014 23:23:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F9B1A6FE2 for ; Tue, 2 Sep 2014 23:23:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8557D1439; Wed, 3 Sep 2014 08:23:51 +0200 (CEST) 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 ACM3__utwC4r; Wed, 3 Sep 2014 08:23:40 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 08:23:50 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id B170020035; Wed, 3 Sep 2014 08:23:50 +0200 (CEST) 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 AlpKub3lAfkS; Wed, 3 Sep 2014 08:23:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4E2B220033; Wed, 3 Sep 2014 08:23:49 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3D9902E5806F; Wed, 3 Sep 2014 08:23:49 +0200 (CEST) Date: Wed, 3 Sep 2014 08:23:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140903062349.GC79257@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iGgw3nlgg9jEtyPDi9KUhbQDizg Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:23:55 -0000 On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: > >> > >> On 28 Aug 2014, at 17:32, Andy Bierman wrote: > >> > >> > Agreed -- if mixed mode XML and entities were allowed, then encoding > >> > the XML as a string would be best. > >> > > >> > >> OK, so would a string be better than an object? Something like this: > >> > >> An XML element that is an instance of a YANG anyxml data node is translated to a name/value pair where the value is a JSON string. The XML-JSON mapping of this string is not defined by this document. That is, the content of the XML instance may appear unchanged in this string value, or it may be processed in any way that’s appropriate for a given application. In the latter case, the definition of the anyxml data node SHOULD contain a description specifying the mapping of the XML content to JSON and vice versa. > >> > > > > Lada, > > > > I think we are talking about an _encoding_ not about > > _transformations_. The purpose of an encoding is to transfer data > > from A with B without making any modifications. Why do you insist that > > implementations can make arbitrary _transformation_? What does > > "appropriate for a given application" mean? How does the server know > > what an application needs and is it not far better to let the > > applications do whatever they want to be doing instead of outsourcing > > some of the work to the NC/RC server? I think I prefer this to be > > clearly defined and interoperable. > > I am just saying that the encoding of the anyxml data *may* be different > in JSON and XML. One reason could be that the XML content may not be > valid without the "outer" XML context (NS-prefix mapping). I don't get > why it should be an interoperability problem. Maybe a better term than > "application-specific" is "anyxml-data-node-specific". > > In fact, I treated "anyxml" more like "anydata", and I also assume that XML > needn't be the default and ever-present encoding. If a server uses anyxml for > configuring a banner page with markup, and supports only JSON, I really > see no reason why the content should be XML, which is what anyxml > requires. > As technical contributor, I fundamentally disagree. If I have leaf banner { type anyxml; description "An XHTML banner to show to the user." } then the client should get the banner in the same form (XHTML) regardless how the protocol messages are encoded. It is not the job of an _encoding_ to try to do _transformations_ in the hope the client finds them useful. /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 Sep 2 23:44:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092931A7018 for ; Tue, 2 Sep 2014 23:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 ei5aROKOd0y5 for ; Tue, 2 Sep 2014 23:44:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19A531A001A for ; Tue, 2 Sep 2014 23:44:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D63571442; Wed, 3 Sep 2014 08:44:50 +0200 (CEST) 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 II-z5kwU70I9; Wed, 3 Sep 2014 08:44:39 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 08:44:49 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD8B320033; Wed, 3 Sep 2014 08:44:49 +0200 (CEST) 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 naX6z9qDqTTV; Wed, 3 Sep 2014 08:44:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 64A7620038; Wed, 3 Sep 2014 08:44:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2A8CC2E580B4; Wed, 3 Sep 2014 08:44:48 +0200 (CEST) Date: Wed, 3 Sep 2014 08:44:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140903064448.GD79257@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140901215021.GD74917@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/g5VD6SIS1fuF2ssPJXdMcExw2JA Cc: netmod@ietf.org Subject: Re: [netmod] I-JSON X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:44:54 -0000 On Tue, Sep 02, 2014 at 11:19:55AM +0200, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: > > > On Wed, Aug 27, 2014 at 03:30:19PM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> I-JSON spec (draft-ietf-json-i-json-03) defines a restricted profile of > >> JSON that guarantees maximum interoperability for protocols that use > >> JSON in their messages, no matter what JSON encoders/decoders are used > >> in protocol implementations. This is exactly what e.g. RESTCONF needs, > >> so it would be useful to make JSON defined in the yang-json document > >> I-JSON compliant. > >> > >> A far as I can tell, these are the problematic parts: > >> > >> Encoding and Characters > >> ======================= > >> > >> - I-JSON requires UTF-8 encoding. Yang-json should do the same, which > >> may need recoding on the sender side. > > > > NETCONF also requires UTF-8 (2nd paragraph in section 3 of RFC 6241). > > So does RESTCONF, but we are talking about data without referring to > a particular protocol. XML defines a way for specifying character > encoding but JSON doesn't. If the intention is that UTF-8 be always used > even in XML, then YANG spec should probably say so. YANG has a type system. RFC 6020 says what YANG strings are (in terms of the character set, not its encoding) and may other types are restricted by nature. The only type where things may be unclear is anyxml. RFC 6241 section 3 says that all NETCONF must be encoded in UTF-8. As such, even anyxml must be encoded in UTF-8 when used with NETCONF. I think the JSON I-D can easily require the same. > >> - I-JSON forbids Unicode surrogates or noncharacters. YANG "string" and > >> other types inherit XML character set which excludes surrogates but > >> not all noncharacters (for example, #xFDDO is allowed). The only > >> robust solution I can see is to ban noncharacters in YANG 1.1 - > >> yang-json cannot do it unilaterally. > > > > Hm. Feels somewhat bad to change YANG because a new encoding has some > > problems. I am not enough an expert in character sets to know what > > would be the 'right' thing to do. > > Neither am I but my understanding is that it is more of an omission on > the XML side. If interoperability is our primary interest, I think > noncharacters should be banned in XML, too. So you are suggesting to change section 9.4. of RFC 6020 to exclude noncharacters. Which other types do you think are affected? I think the other types do not have an issue. I assume you also suggest that the anyxml statement gets text added that the XML character set is restricted to a subset of what XML allows? > >> Binary Data > >> =========== > >> > >> - In I-JSON, it is RECOMMENDED that this data be encoded in a string > >> value in base64url. YANG's binary type requires base64. I raised this > >> issue twice in the JSON WG mailing list > >> (http://www.ietf.org/mail-archive/web/json/current/msg03129.html, > >> http://www.ietf.org/mail-archive/web/json/current/msg03192.html). Nobody > >> offered any arguments why base64url should be better than base64 for > >> encoding field values, but I also found no support for changing the > >> current text. So the only option seems to be not to follow this I-JSON > >> recommendation (and provide reasoning). > > > > Carsten Bormann was strongly advocating base64url but he did not > > provide any clear reasons. Since we do not intend to send JSON as > > part of URLs, I think we are fine with using base64. > > Right, but if our goal is to be able to say that JSON encoding of > YANG-based instances is I-JSON, then I don't know whether we can do so > if we ignore RECOMMENDED encoding just for legacy reasons. RFC 2119: 3. SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in particular circumstances to ignore a particular item, but the full implications must be understood and carefully weighed before choosing a different course. I think this may be defendable. We likely should have a section discussing I-JSON compliance and explain the reasoning where we depart from the recommendations. /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 Sep 2 23:48:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3451A7D83 for ; Tue, 2 Sep 2014 23:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.918 X-Spam-Level: X-Spam-Status: No, score=-1.918 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 Gj9nzDLcK0Db for ; Tue, 2 Sep 2014 23:47:58 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 557B11A70E1 for ; Tue, 2 Sep 2014 23:47:50 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A66CC1237; Wed, 3 Sep 2014 08:47:49 +0200 (CEST) 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 LYGuD5RCVkFE; Wed, 3 Sep 2014 08:47:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 08:47:48 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B60E220035; Wed, 3 Sep 2014 08:47:48 +0200 (CEST) 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 Ur42c_LZvQ8U; Wed, 3 Sep 2014 08:47:47 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1329420033; Wed, 3 Sep 2014 08:47:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 02DB32E580F0; Wed, 3 Sep 2014 08:47:46 +0200 (CEST) Date: Wed, 3 Sep 2014 08:47:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" Message-ID: <20140903064746.GA79440@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20140903062349.GC79257@elstar.local> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ll4AjlP7TNw3q_MgxPjG8zPyZA4 Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 06:48:00 -0000 On Wed, Sep 03, 2014 at 08:23:49AM +0200, Juergen Schoenwaelder wrote: > On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote: > > Juergen Schoenwaelder writes: > > > > > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: > > >> > > >> On 28 Aug 2014, at 17:32, Andy Bierman wrote: > > >> > > >> > Agreed -- if mixed mode XML and entities were allowed, then encoding > > >> > the XML as a string would be best. > > >> > > > >> > > >> OK, so would a string be better than an object? Something like this: > > >> > > >> An XML element that is an instance of a YANG anyxml data node is translated to a name/value pair where the value is a JSON string. The XML-JSON mapping of this string is not defined by this document. That is, the content of the XML instance may appear unchanged in this string value, or it may be processed in any way that’s appropriate for a given application. In the latter case, the definition of the anyxml data node SHOULD contain a description specifying the mapping of the XML content to JSON and vice versa. > > >> > > > > > > Lada, > > > > > > I think we are talking about an _encoding_ not about > > > _transformations_. The purpose of an encoding is to transfer data > > > from A with B without making any modifications. Why do you insist that > > > implementations can make arbitrary _transformation_? What does > > > "appropriate for a given application" mean? How does the server know > > > what an application needs and is it not far better to let the > > > applications do whatever they want to be doing instead of outsourcing > > > some of the work to the NC/RC server? I think I prefer this to be > > > clearly defined and interoperable. > > > > I am just saying that the encoding of the anyxml data *may* be different > > in JSON and XML. One reason could be that the XML content may not be > > valid without the "outer" XML context (NS-prefix mapping). I don't get > > why it should be an interoperability problem. Maybe a better term than > > "application-specific" is "anyxml-data-node-specific". > > > > In fact, I treated "anyxml" more like "anydata", and I also assume that XML > > needn't be the default and ever-present encoding. If a server uses anyxml for > > configuring a banner page with markup, and supports only JSON, I really > > see no reason why the content should be XML, which is what anyxml > > requires. > > > > As technical contributor, I fundamentally disagree. If I have > > leaf banner { > type anyxml; > description > "An XHTML banner to show to the user." > } > > then the client should get the banner in the same form (XHTML) > regardless how the protocol messages are encoded. It is not the job of > an _encoding_ to try to do _transformations_ in the hope the client > finds them useful. > Sorry, anyxml is not a type and hence the correct example would be: anyxml banner { type anyxml; description "An XHTML banner to show to the user."; } /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 01:26:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 111B51A0251 for ; Wed, 3 Sep 2014 01:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.019 X-Spam-Level: X-Spam-Status: No, score=-1.019 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668] 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 Jlf8C8t3WZPV for ; Wed, 3 Sep 2014 01:26:19 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3885B1A00F1 for ; Wed, 3 Sep 2014 01:26:18 -0700 (PDT) Received: from [IPv6:2001:1488:fffe:6:58f3:6d1c:ae0c:db1] (unknown [IPv6:2001:1488:fffe:6:58f3:6d1c:ae0c:db1]) by mail.nic.cz (Postfix) with ESMTPSA id 0F37013F786; Wed, 3 Sep 2014 10:26:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409732776; bh=GEcsgtj+W3HYIJaM9+A7u+vOKo+sLwwT6yAUAZJh7Jg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=s6he3EzRVbidTaUd2/hQB0T7IIB1k+3fpyIg5qvfLnAUo5Vx6x/m1LkZFopbUDQC5 N/p193oi0XuqkPMSHUHbuZd44Q3x21zkmMebg/XUPdNy1QK1XFwgdTXQ5xG7foVC0m 0ezKSTAZAQE3LJmDxMBcV9C6SinswqfXMtLpUPXU= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140903062349.GC79257@elstar.local> Date: Wed, 3 Sep 2014 10:26:13 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1603DD35-37E2-4F49-A75E-36E25174726B@nic.cz> References: <20140828074829.GA61114@elstar.local> <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wU8lbNhqG0tWzJ-ttOEu0TbRdfQ Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:26:21 -0000 On 03 Sep 2014, at 08:23, Juergen Schoenwaelder = wrote: > On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote: >> Juergen Schoenwaelder writes: >>=20 >>> On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> On 28 Aug 2014, at 17:32, Andy Bierman wrote: >>>>=20 >>>>> Agreed -- if mixed mode XML and entities were allowed, then = encoding >>>>> the XML as a string would be best. >>>>>=20 >>>>=20 >>>> OK, so would a string be better than an object? Something like = this: >>>>=20 >>>> An XML element that is an instance of a YANG anyxml data node is = translated to a name/value pair where the value is a JSON string. The = XML-JSON mapping of this string is not defined by this document. That = is, the content of the XML instance may appear unchanged in this string = value, or it may be processed in any way that=92s appropriate for a = given application. In the latter case, the definition of the anyxml data = node SHOULD contain a description specifying the mapping of the XML = content to JSON and vice versa.=20 >>>>=20 >>>=20 >>> Lada, >>>=20 >>> I think we are talking about an _encoding_ not about >>> _transformations_. The purpose of an encoding is to transfer data >>> from A with B without making any modifications. Why do you insist = that >>> implementations can make arbitrary _transformation_? What does >>> "appropriate for a given application" mean? How does the server know >>> what an application needs and is it not far better to let the >>> applications do whatever they want to be doing instead of = outsourcing >>> some of the work to the NC/RC server? I think I prefer this to be >>> clearly defined and interoperable. >>=20 >> I am just saying that the encoding of the anyxml data *may* be = different >> in JSON and XML. One reason could be that the XML content may not be >> valid without the "outer" XML context (NS-prefix mapping). I don't = get >> why it should be an interoperability problem. Maybe a better term = than >> "application-specific" is "anyxml-data-node-specific". >>=20 >> In fact, I treated "anyxml" more like "anydata", and I also assume = that XML >> needn't be the default and ever-present encoding. If a server uses = anyxml for >> configuring a banner page with markup, and supports only JSON, I = really >> see no reason why the content should be XML, which is what anyxml >> requires. >>=20 >=20 > As technical contributor, I fundamentally disagree. If I have >=20 > leaf banner { > type anyxml; > description > "An XHTML banner to show to the user." > } >=20 > then the client should get the banner in the same form (XHTML) > regardless how the protocol messages are encoded. It is not the job of > an _encoding_ to try to do _transformations_ in the hope the client > finds them useful. But it is the job of the *data model* to specify the form and meaning of = the anyxml content. In your (corrected) example, the description of the = =93banner=94 anyxml node says the content has to be XHTML, and then = XHTML should indeed appear in both XML and JSON. However, if the = description prescribes XHTML for XML and Markdown for JSON, then this = could/should be understood by both the server and client. A client that uses JSON could configure the banner page using Markdown, = and another client that uses XML will retrieve the banner as XHTML. I = don=92t know what=92s wrong with it. The data modeller is free to decide = what makes sense and whether it is feasible for server implementations = to offer/accept encoding-specific forms of the same information. To be able to move forward, could you propose your text for sec. 3.3.10? Lada >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 3 01:54:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5897B1A0117 for ; Wed, 3 Sep 2014 01:54:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 B5nnZZxWj4X1 for ; Wed, 3 Sep 2014 01:54:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B1D31A00FB for ; Wed, 3 Sep 2014 01:54:24 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 53EBF12FC; Wed, 3 Sep 2014 10:54:23 +0200 (CEST) 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 UhR51pem6Nx5; Wed, 3 Sep 2014 10:54:11 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 10:54:22 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8B0B520035; Wed, 3 Sep 2014 10:54:22 +0200 (CEST) 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 R1TsV_QSPd_1; Wed, 3 Sep 2014 10:54:21 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 635BF20033; Wed, 3 Sep 2014 10:54:20 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 42C6A2E583F5; Wed, 3 Sep 2014 10:54:20 +0200 (CEST) Date: Wed, 3 Sep 2014 10:54:20 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140903085420.GB79742@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> <1603DD35-37E2-4F49-A75E-36E25174726B@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1603DD35-37E2-4F49-A75E-36E25174726B@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Hou9gxMiAgdQwU5Pn1YWhbeoYGo Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:54:26 -0000 On Wed, Sep 03, 2014 at 10:26:13AM +0200, Ladislav Lhotka wrote: > > But it is the job of the *data model* to specify the form and > meaning of the anyxml content. In your (corrected) example, the > description of the “banner†anyxml node says the content has to be > XHTML, and then XHTML should indeed appear in both XML and > JSON. However, if the description prescribes XHTML for XML and > Markdown for JSON, then this could/should be understood by both the > server and client. A data model where the content depends on the protocol encoding is a gross layer violation and IMHO broken. That said, if you want an object that can be either XHTML or MD, then anyxml is the wrong construction for this union. > A client that uses JSON could configure the banner page using > Markdown, and another client that uses XML will retrieve the banner > as XHTML. I don’t know what’s wrong with it. The data modeller is > free to decide what makes sense and whether it is feasible for > server implementations to offer/accept encoding-specific forms of > the same information. The server is expected to translate MD to XHTML? Anyway, you are making a layer violation here - there is the data model and there is an encoding on the wire. The encoding needs to be transparent. > To be able to move forward, could you propose your text for > sec. 3.3.10? I believe there are two issues here. First there needs to be an agreement what exactly anyxml is and which constraints actually appy. This is related to Y34 and should be resolved in YANG 1.1. If the answer here is that anyxml is defacto a subset of XML that matches NETCONF protocol constraints and we only have elements and no mixed content, no PIs etc, then the solution to 3.3.10 is likely what I understand Andy implemented, namely that anyxml elements translate into JSON objects but without having information of the underlying data model (e.g. no distinction between numbers and strings). [ And I would be happy if such a data model ignorant translation would generally be allowed, but this is a different topic. ] Before writing text, I think we should see whether we can reach agreement since the debate is not about the details of the solution but the general approach to take. /js PS: Even if we conclude that mixed content or PIs may appear in anyxml, -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 01:58:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B34711A0100; Wed, 3 Sep 2014 01:58:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 YMcX0vc_xsUe; Wed, 3 Sep 2014 01:58:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC0081A00FB; Wed, 3 Sep 2014 01:58:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 7A36F123D; Wed, 3 Sep 2014 10:58:19 +0200 (CEST) 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 tmjzZxt7dirV; Wed, 3 Sep 2014 10:58:07 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 10:58:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6C5C320035; Wed, 3 Sep 2014 10:58:18 +0200 (CEST) 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 S5SFagbtDywx; Wed, 3 Sep 2014 10:58:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0699C20033; Wed, 3 Sep 2014 10:58:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CA0172E5849B; Wed, 3 Sep 2014 10:58:15 +0200 (CEST) Date: Wed, 3 Sep 2014 10:58:14 +0200 From: Juergen Schoenwaelder To: proceedings@ietf.org Message-ID: <20140903085814.GA79838@elstar.local> Mail-Followup-To: proceedings@ietf.org, netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="OgqxwSJOaUobr8KG" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3VDG3FI79NbIampRkNiKpTn-qXs Cc: netmod@ietf.org Subject: [netmod] minutes of the NETMOD virtual interim meeting on 2014-08-27 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 08:58:22 -0000 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached please find the minutes of the NETMOD virtual interim meeting that took place on 2014-08-27. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --OgqxwSJOaUobr8KG Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-08-27-minutes.txt" o============================================================= NETCONF Data Modeling Language WG (netmod) 4th YANG 1.1 Virtual Interim Wednesday, August 27th, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - AB = Andy Bierman - LL = Lada Lotka - PO = Peyman Owladi - DR = David Reid - KW = Kent Watsen - MB = Martin Bjorklund * Y44: add a mechanism to parameterize error-message AB: We really want full blown XPATH in error messages? MB: If you already have an XPATH engine, why not? JS: What is you get a nodeset? MB: This is the string rendering of the nodeset. AB: What is the context for the XPATH evaluation? MB: The same as for a must expression evaluation. AB: But this can be in an RPC input. MB: Yes. AB: An alternative is to pass additional information to the NMS and then the error message would a format string and the NMS would plug data into the format string. AB: What if curly braces show up elsewhere? JS: Would we need a mechanism to escape the braces? AB: Sounds this could be done by the NMS. KW: It can be complex to identify which interface caused a problem. AB: The error-path has the details in machine readable format. AB: We only needs this for must expressions really. AB: We used $() to enclose XPATH expressions and we found that easier. KW: The issue how to identify the expression, not stuff inside the expression. AB: This is not lightweight to do. KW: Can a server simply return the string if it does not want to do XPATH evaluation? MB: RFC 6020 section 7.5.4.1 says that the error-message (if present) is to be used. What if both error-message and x-error-message exist? MB: If we drop Y44, can an implementation still generate a better error message. AB: Right now, this is a MUST. MB: I would like to allow 'better' error messages. AB: What about using other fields in the error-info? PO: What about rendering an extended error message into error-info? Proposal: Move to the issue to dead and leave RFC 6020 section 7.5.4.1 unchanged. Extended error messages can be supported by a YANG extension and shipped in . * Y47: bit name too restrictive MB: Enum names are not restricted. JS: Enum names are very different from bit names but some of this is inherent. MB: Is this worth fixing? Having to support two rules for YANG 1.0 and YANG 1.1 is having costs. MB: If we were to restart, we likely would restrict enum names and relax bit names and make them the same. Too hard to do in YANG 1.0 Proposal: Move to dead as it is not worth fixing it. Or more precisely, a proper fix would make the restrictions for enum names and bit names the same and that won't be backwards compatible. * Y49: clarify nested submodule behavior MB: I prefer solution Y49-02. PO: What is the aim of a submodule? Is it hiding? MB: No, it is not hiding. PO: OK, so it is organization and readability. AB: Agree, this is not about hiding things. But, submodules have different scopes. MB: But from the XML perspective, it is one namespace. AB: I could go with Y49-02. If there is no include statement in the main module, it is not exported. MB: I would even say this is an error. MB: Other alternative: everything is exported (would be a 3rd solution). AB: Currently, if you split a submodule into smaller pieces, this ripples through. Action: - MB to write up Y49-03. * Y55: clarify type in union AB: We could say unions are always strings in JSON. MB: If you send 1 as number over JSON, can it still be considered a string? Proposal: Adopt Y55-01. --OgqxwSJOaUobr8KG-- From nobody Wed Sep 3 04:11:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B241A02D9 for ; Wed, 3 Sep 2014 04:11:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 ZnaBX5MRVMpo for ; Wed, 3 Sep 2014 04:11:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC1B71A0068 for ; Wed, 3 Sep 2014 04:11:32 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 83AC61A78 for ; Wed, 3 Sep 2014 13:11:31 +0200 (CEST) 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 T3fq-G8tQbBd for ; Wed, 3 Sep 2014 13:11:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 3 Sep 2014 13:11:30 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 509D920036 for ; Wed, 3 Sep 2014 13:11:30 +0200 (CEST) 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 rY-9UlPNDCQq; Wed, 3 Sep 2014 13:11:29 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id BF75820035; Wed, 3 Sep 2014 13:11:28 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5B122E58717; Wed, 3 Sep 2014 13:11:27 +0200 (CEST) Date: Wed, 3 Sep 2014 13:11:27 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140903111127.GA79883@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L7gfKYw1qy7p26NngXFMf1NbNP8 Subject: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 11:11:36 -0000 Hi, we managed to go over all issues except those issues that we will be disussing during the face-to-face interim meeting. This email provides a summary of where we are with the issues not marked DEAD. I am also including actions that need to be carried out. If you disagree with any of the following proposed resolutions, please speak up as soon as possible but no later than September 16 (so that we have the input before the face-to-face interim meeting starts). If you want to raise a concern, please start a threat with the issue identifier in the subject line. * OPEN :Y01: allow boolean if-feature 2014-06-11 meeting proposal: adopt Y01-01. * OPEN :Y02: allow must in input, output, and notification 2014-06-11 meeting proposal: adopt Y02-01. * OPEN :Y03: allow if-feature in refine 2014-06-11 meeting proposal: adopt Y03-01. * OPEN :Y04: accessible tree in xpath in notifs and rpc 2014-06-11 meeting proposal: adopt Y04-02. * OPEN :Y05: unprefixed path in top-level typedef 2014-06-11 meeting action: MB to write down solution Y05-03 and once done we get back to this issue. * OPEN :Y06: escaped characters in double quoted strings 2014-06-11 meeting proposal: adopt Y06-02. * OPEN :Y07: do not allow when or if-feature on keys 2014-07-02 meeting proposal: adopt Y07-01 with a clarification about the condition * OPEN :Y09: introduce optional keys <> 2014-07-02 meeting action: MB to write up a solution proposal and once done we get back to this issue. * OPEN :Y10: allow restrictions on enumerations 2014-07-02 meeting action: LL to write down another syntax proposal and MB to expand Y10-01. * OPEN :Y11: allow if-feature on enums 2014-07-02 meeting proposal: Adopt Y11-01 with the extension to allow if-feature also for bits and identities. * OPEN :Y12: initialized-by system 2014-07-02 meeting proposal: Adopt Y12-01 but think about a better syntax. Applies to leaf and leaf-lists. MB to create concrete text. * OPEN :Y13: allow multiple inheritance for identities 2014-07-02 meeting action: LL to write a more complete example and once done we get back to this issue. * OPEN :Y14: clarify the string value for identities when used in must/when 2014-07-02 meeting proposal: adopt Y14-01. * OPEN :Y16: module advertisement optimization 2014-07-02 meeting action: MB to look at the details whether Y16-02 can be made to work. * OPEN :Y18: fix "when" expression context node problem 2014-07-02 meeting action: LL to write up an example in which situations Y18-01 is problematic. * OPEN :Y20: new set of built-in XPath functions 2014-07-09 meeting proposal: MB to copy the functions he proposed to RFC 6020bis as a starting point and then we review and discuss changes. * OPEN :Y23: support negative patterns as string restrictions 2014-07-09 meeting proposal: adopt Y23-02. * OPEN :Y25: make enum numbering purely informative and optional 2014-07-09 meeting proposal: adopt Y25-01. * OPEN :Y26: allow mandatory nodes in augment 2014-07-09 meeting action: There is agreement that the current text is overly restrictive. The proposal is to add general guiding rules that backwards compatibility needs to be maintained. Lets see whether someone can write more concrete rules when mandatory nodes in augment are allowed. * OPEN :Y27: allow mandatory nodes in an updated module 2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to check what the feature issue is about, possible action to add guidelines how to go from current to deprecated to obsolete in RFC 6087bis. * OPEN :Y28: support default values in leaf-lists 2014-07-09 meeting action: AB will look at the necessary text and what it means to modify leaf-list values. Perhaps there is a need to have a different keyword since the behavior is rather different here. * OPEN :Y29: allow choice as a short-hand case 2014-07-09 meeting proposal: adopt Y29-01 * OPEN :Y30: allow leafref in union 2014-07-21 meeting proposal: adopt Y30-01, clarify existence constraints and impact on union member selection, see 2014-07-09 meeting minutes. Followup on Lada's issue concerning unions as keys. * OPEN :Y31: allow require-instance in leafref 2014-07-21 meeting proposal: adopt Y31-01. * OPEN :Y34: remove/deprecate/replace the 'anyxml' statement 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out a concrete proposal. * OPEN :Y35: allow empty in union 2014-07-21 meeting proposal: adopt Y35-01. * OPEN :Y41: clarification of "must" in NP-container 2014-07-21 meeting proposal: Clarify that for validation purposes, NP containers always exist. * OPEN :Y42: a better model for configuration versus state data is needed postponed to the face-to-face interim meeting * OPEN :Y44: add a mechanism to parameterize error-message 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. * OPEN :Y45: better conformance mechanism postponed to the face-to-face interim meeting * OPEN :Y47: bit name too restrictive 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. * OPEN :Y49: clarify nested submodule behavior 2014-08-27 meeting action: MB to writeup solution proposal Y49-03. * OPEN :Y54: remove the advertisement of conformance information in NETCONF hello postponed to the face-to-face interim meeting * NEW :Y55: clarify type in union 2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 04:36:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC3CD1A8A43 for ; Wed, 3 Sep 2014 04:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.678 X-Spam-Level: X-Spam-Status: No, score=-3.678 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkwnPclSa_9n for ; Wed, 3 Sep 2014 04:35:56 -0700 (PDT) Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A92E1A8A3A for ; Wed, 3 Sep 2014 04:35:55 -0700 (PDT) Received: by mail-qg0-f46.google.com with SMTP id a108so852633qge.19 for ; Wed, 03 Sep 2014 04:35:55 -0700 (PDT) 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=dsQNjpi6azRk52xTDe+fxzpcS799CwUk+ICxVemywl8=; b=iFnps95Km/CFwpEQUmXR3kNHH8uyBoQMlICfTR3sU/+VsGuiQD4REMlQb2Rndzuz8+ e3gqV9c2RqDfLuEjBybjQL7A37RJOigwdai8SDsoaZXmkcM93IAaCvbQhjHCghwvhUxZ mEvLbjTNhaEkzXutWwUNv+ZtGijHLx4Mv+ZiUhGGvFHpEgH+GwGYBA5uO2mME105+OnV cGr+YDJeSZNl0b7gNr0K26jOPJ5rxtPRC32zilG1l4aBoaiePBOgqmo9mlIv0oaPunGH T1ClOCb8at1uyLQzDnOJtos3qrO4Sa2wbyT5T5YCJFUhT3yHY+kt91BkjWOA4TgEHJtu QhBQ== X-Gm-Message-State: ALoCoQkBsMx12fMQwrySOC+QYZ/gmwxdHC/cCF4mV3IhXy+U3L1B0Pi9DVFEp9cDQQIkhqPvz8DB MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr65189360qcl.14.1409744155115; Wed, 03 Sep 2014 04:35:55 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Wed, 3 Sep 2014 04:35:55 -0700 (PDT) In-Reply-To: <20140903064746.GA79440@elstar.local> References: <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> <20140903064746.GA79440@elstar.local> Date: Wed, 3 Sep 2014 04:35:55 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , =?ISO-8859-1?Q?Martin_Bj=F6rklund?= , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11345256971f46050227a38d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nzGLchnUPBJyN6V045Toob_2CMo Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 11:35:59 -0000 --001a11345256971f46050227a38d Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 2, 2014 at 11:47 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Sep 03, 2014 at 08:23:49AM +0200, Juergen Schoenwaelder wrote: > > On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote: > > > Juergen Schoenwaelder writes: > > > > > > > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: > > > >> > > > >> On 28 Aug 2014, at 17:32, Andy Bierman wrote: > > > >> > > > >> > Agreed -- if mixed mode XML and entities were allowed, then > encoding > > > >> > the XML as a string would be best. > > > >> > > > > >> > > > >> OK, so would a string be better than an object? Something like this: > > > >> > > > >> An XML element that is an instance of a YANG anyxml data node is > translated to a name/value pair where the value is a JSON string. The > XML-JSON mapping of this string is not defined by this document. That is, > the content of the XML instance may appear unchanged in this string value, > or it may be processed in any way that's appropriate for a given > application. In the latter case, the definition of the anyxml data node > SHOULD contain a description specifying the mapping of the XML content to > JSON and vice versa. > > > >> > > > > > > > > Lada, > > > > > > > > I think we are talking about an _encoding_ not about > > > > _transformations_. The purpose of an encoding is to transfer data > > > > from A with B without making any modifications. Why do you insist > that > > > > implementations can make arbitrary _transformation_? What does > > > > "appropriate for a given application" mean? How does the server know > > > > what an application needs and is it not far better to let the > > > > applications do whatever they want to be doing instead of outsourcing > > > > some of the work to the NC/RC server? I think I prefer this to be > > > > clearly defined and interoperable. > > > > > > I am just saying that the encoding of the anyxml data *may* be > different > > > in JSON and XML. One reason could be that the XML content may not be > > > valid without the "outer" XML context (NS-prefix mapping). I don't get > > > why it should be an interoperability problem. Maybe a better term than > > > "application-specific" is "anyxml-data-node-specific". > > > > > > In fact, I treated "anyxml" more like "anydata", and I also assume > that XML > > > needn't be the default and ever-present encoding. If a server uses > anyxml for > > > configuring a banner page with markup, and supports only JSON, I really > > > see no reason why the content should be XML, which is what anyxml > > > requires. > > > > > > > As technical contributor, I fundamentally disagree. If I have > > > > leaf banner { > > type anyxml; > > description > > "An XHTML banner to show to the user." > > } > > > > then the client should get the banner in the same form (XHTML) > > regardless how the protocol messages are encoded. It is not the job of > > an _encoding_ to try to do _transformations_ in the hope the client > > finds them useful. > > > > Sorry, anyxml is not a type and hence the correct example would be: > > anyxml banner { > type anyxml; > description > "An XHTML banner to show to the user."; > } > 1) anyxml does not have any YANG type at all: > anyxml banner { > description > "An XHTML banner to show to the user."; > } > It seems odd to me to debate proper YANG typing for something that, by definition, has no YANG type. It isn't YANG! It's a hole in the YANG schema where data that has no syntax and no semantics can be stored. (IMO, a really bad idea for data modeling). 2) No NETCONF implementation supports mixed mode XML. There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 o Filtering of mixed content is not supported. The intent was to disallow mixed mode in all operations, not just subtree filtering. 3) IMO the IETF spends too much time on broken text, worrying about the letter of the law when there is little to no operational value to be gained. Most implementors have never even tried to send mixed mode XML to their server, and don't even know what will happen. Obviously if customers were using this, the implementors would know exactly whether this worked or not. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a11345256971f46050227a38d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Tue, Sep 2, 2014 at 11:47 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Sep 03, 2014 at 08:23:49AM +0200, Juergen Schoenwa= elder wrote:
> On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote:
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> >
> > > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wr= ote:
> > >>
> > >> On 28 Aug 2014, at 17:32, Andy Bierman <andy@yumaworks.com> wrote:
> > >>
> > >> > Agreed -- if mixed mode XML and entities were allow= ed, then encoding
> > >> > the XML as a string would be best.
> > >> >
> > >>
> > >> OK, so would a string be better than an object? Somethin= g like this:
> > >>
> > >> An XML element that is an instance of a YANG anyxml data= node is translated to a name/value pair where the value is a JSON string. = The XML-JSON mapping of this string is not defined by this document. That i= s, the content of the XML instance may appear unchanged in this string valu= e, or it may be processed in any way that’s appropriate for a given a= pplication. In the latter case, the definition of the anyxml data node SHOU= LD contain a description specifying the mapping of the XML content to JSON = and vice versa.
> > >>
> > >
> > > Lada,
> > >
> > > I think we are talking about an _encoding_ not about
> > > _transformations_.  The purpose of an encoding is to tr= ansfer data
> > > from A with B without making any modifications. Why do you i= nsist that
> > > implementations can make arbitrary _transformation_? What do= es
> > > "appropriate for a given application" mean? How do= es the server know
> > > what an application needs and is it not far better to let th= e
> > > applications do whatever they want to be doing instead of ou= tsourcing
> > > some of the work to the NC/RC server? I think I prefer this = to be
> > > clearly defined and interoperable.
> >
> > I am just saying that the encoding of the anyxml data *may* be di= fferent
> > in JSON and XML. One reason could be that the XML content may not= be
> > valid without the "outer" XML context (NS-prefix mappin= g).  I don't get
> > why it should be an interoperability problem. Maybe a better term= than
> > "application-specific" is "anyxml-data-node-specif= ic".
> >
> > In fact, I treated "anyxml" more like "anydata&quo= t;, and I also assume that XML
> > needn't be the default and ever-present encoding. If a server= uses anyxml for
> > configuring a banner page with markup, and supports only JSON, I = really
> > see no reason why the content should be XML, which is what anyxml=
> > requires.
> >
>
> As technical contributor, I fundamentally disagree. If I have
>
>    leaf banner {
>      type anyxml;
>      description
>        "An XHTML banner to show to the user.&= quot;
>    }
>
> then the client should get the banner in the same form (XHTML)
> regardless how the protocol messages are encoded. It is not the job of=
> an _encoding_ to try to do _transformations_ in the hope the client > finds them useful.
>

Sorry, anyxml is not a type and hence the correct example would be:
 
    anyxml banner {
      type anyxml;
      description
        "An XHTML banner to show to the user."= ;;
    }

1) anyxml does not have= any YANG type at all:
 
anyxml banner {
      description
     =   "An XHTML banner to show to the user.";
    = }

It seems odd to me to debate pr= oper YANG typing for
something that, by definition, has no YANG t= ype.
It isn't YANG!  It's a hole in the YANG schema where
data that has no syntax and no semantics can be stored.
(IM= O, a really bad idea for data modeling).

2) No NET= CONF implementation supports mixed mode XML.
There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5

  o  Filtering of mixed content is not supported.

The intent was to disallow mixed mode in all operations, not
j= ust subtree filtering.

3) IMO the IETF spends too = much time on broken text, worrying about
the letter of the law wh= en there is little to no operational value to
be gained. Most implementors have never even tried to send mixed mode<= /div>
XML to their server, and don't even know what will happen. &n= bsp;Obviously
if customers were using this, the implementors woul= d know exactly
whether this worked or not.


&n= bsp;  

/js

Andy
 =

--
Juergen Schoenwaelder           Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 287= 59 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacob= s-university.de/>

--001a11345256971f46050227a38d-- From nobody Wed Sep 3 05:13:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D74E1A0102 for ; Wed, 3 Sep 2014 05:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.319 X-Spam-Level: X-Spam-Status: No, score=-3.319 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_I_LETTER=-2, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, RP_MATCHES_RCVD=-0.668] 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 0sp2DUjTPVve for ; Wed, 3 Sep 2014 05:12:59 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C2611A00F0 for ; Wed, 3 Sep 2014 05:12:58 -0700 (PDT) Received: from [192.168.42.28] (cst-prg-117-18.cust.vodafone.cz [46.135.117.18]) by mail.nic.cz (Postfix) with ESMTPSA id 4C4911412AF; Wed, 3 Sep 2014 14:12:55 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1409746376; bh=1xiqzqGs6IIAZ9ecNxk4Ch4R8Mumuk2zO3lu90d5+XM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=InLju2v7rPdMxtjKnhlGvQWLsPVY3772HTklzsxSW7D924Ji1H9/mpU6R2PbWnsVQ xax/qrdGcsXoPgsd+vSS/xmGIysZfxtM9hK+q96d/N56/umA0VrqHIwyJm/HQarem4 YR6ho/5ah2ou6x/tMFy4f9/9vZgLgxX7aOVlrgAs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 3 Sep 2014 14:12:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140828.124839.716000072014037611.mbj@tail-f.com> <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> <20140903064746.GA79440@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4ju7Ix9hdD3LK7N7PfCTmMV5bz0 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:13:03 -0000 On 03 Sep 2014, at 13:35, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Sep 2, 2014 at 11:47 PM, Juergen Schoenwaelder = wrote: > On Wed, Sep 03, 2014 at 08:23:49AM +0200, Juergen Schoenwaelder wrote: > > On Tue, Sep 02, 2014 at 10:55:56AM +0200, Ladislav Lhotka wrote: > > > Juergen Schoenwaelder = writes: > > > > > > > On Fri, Aug 29, 2014 at 11:31:01AM +0200, Ladislav Lhotka wrote: > > > >> > > > >> On 28 Aug 2014, at 17:32, Andy Bierman = wrote: > > > >> > > > >> > Agreed -- if mixed mode XML and entities were allowed, then = encoding > > > >> > the XML as a string would be best. > > > >> > > > > >> > > > >> OK, so would a string be better than an object? Something like = this: > > > >> > > > >> An XML element that is an instance of a YANG anyxml data node = is translated to a name/value pair where the value is a JSON string. The = XML-JSON mapping of this string is not defined by this document. That = is, the content of the XML instance may appear unchanged in this string = value, or it may be processed in any way that=92s appropriate for a = given application. In the latter case, the definition of the anyxml data = node SHOULD contain a description specifying the mapping of the XML = content to JSON and vice versa. > > > >> > > > > > > > > Lada, > > > > > > > > I think we are talking about an _encoding_ not about > > > > _transformations_. The purpose of an encoding is to transfer = data > > > > from A with B without making any modifications. Why do you = insist that > > > > implementations can make arbitrary _transformation_? What does > > > > "appropriate for a given application" mean? How does the server = know > > > > what an application needs and is it not far better to let the > > > > applications do whatever they want to be doing instead of = outsourcing > > > > some of the work to the NC/RC server? I think I prefer this to = be > > > > clearly defined and interoperable. > > > > > > I am just saying that the encoding of the anyxml data *may* be = different > > > in JSON and XML. One reason could be that the XML content may not = be > > > valid without the "outer" XML context (NS-prefix mapping). I = don't get > > > why it should be an interoperability problem. Maybe a better term = than > > > "application-specific" is "anyxml-data-node-specific". > > > > > > In fact, I treated "anyxml" more like "anydata", and I also assume = that XML > > > needn't be the default and ever-present encoding. If a server uses = anyxml for > > > configuring a banner page with markup, and supports only JSON, I = really > > > see no reason why the content should be XML, which is what anyxml > > > requires. > > > > > > > As technical contributor, I fundamentally disagree. If I have > > > > leaf banner { > > type anyxml; > > description > > "An XHTML banner to show to the user." > > } > > > > then the client should get the banner in the same form (XHTML) > > regardless how the protocol messages are encoded. It is not the job = of > > an _encoding_ to try to do _transformations_ in the hope the client > > finds them useful. > > >=20 > Sorry, anyxml is not a type and hence the correct example would be: > =20 > anyxml banner { > type anyxml; > description > "An XHTML banner to show to the user."; > } >=20 > 1) anyxml does not have any YANG type at all: > =20 > anyxml banner { > description > "An XHTML banner to show to the user."; > } >=20 > It seems odd to me to debate proper YANG typing for > something that, by definition, has no YANG type. > It isn't YANG! It's a hole in the YANG schema where > data that has no syntax and no semantics can be stored. > (IMO, a really bad idea for data modeling). I fully agree. My original idea for section 7.3.3 in yang-json was = similar: An instance of anyxml data node is translated to a name/value pair in = JSON, where =93name=94 is the name of the anyxml data node. Any = statement about the =93value=94 part is outside the scope of this = document. I still think it is the easiest and best solution. I also think anyxml is largely unnecessary and string or binary leafs = could be easily used instead. Lada >=20 > 2) No NETCONF implementation supports mixed mode XML. > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 >=20 > o Filtering of mixed content is not supported. >=20 > The intent was to disallow mixed mode in all operations, not > just subtree filtering. >=20 > 3) IMO the IETF spends too much time on broken text, worrying about > the letter of the law when there is little to no operational value to > be gained. Most implementors have never even tried to send mixed mode > XML to their server, and don't even know what will happen. Obviously > if customers were using this, the implementors would know exactly > whether this worked or not. >=20 >=20 > =20 >=20 > /js >=20 > Andy > =20 >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 3 05:15:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82D371A0102 for ; Wed, 3 Sep 2014 05:15:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 2GMc6NXMVBGj for ; Wed, 3 Sep 2014 05:15:44 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11E031A00F0 for ; Wed, 3 Sep 2014 05:15:44 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A41C61401; Wed, 3 Sep 2014 14:15:42 +0200 (CEST) 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 GEw_O56zQ8K4; Wed, 3 Sep 2014 14:15:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 14:15:42 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0181120038; Wed, 3 Sep 2014 14:15:42 +0200 (CEST) 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 J8G3DJMPdEQl; Wed, 3 Sep 2014 14:15:41 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00BAA20035; Wed, 3 Sep 2014 14:15:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 277042E58C33; Wed, 3 Sep 2014 14:15:39 +0200 (CEST) Date: Wed, 3 Sep 2014 14:15:39 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140903121539.GD80206@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Martin =?iso-8859-1?Q?Bj=F6rklund?= , "netmod@ietf.org" References: <20140828120536.GB61647@elstar.local> <20140828152246.GB62093@elstar.local> <20140901212549.GC74917@elstar.local> <20140903062349.GC79257@elstar.local> <20140903064746.GA79440@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7vB8MvsszLeWUxYSyynkIcQR7v0 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:15:45 -0000 On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: > 2) No NETCONF implementation supports mixed mode XML. > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 > > o Filtering of mixed content is not supported. > > > The intent was to disallow mixed mode in all operations, not > just subtree filtering. > > 3) IMO the IETF spends too much time on broken text, worrying about > the letter of the law when there is little to no operational value to > be gained. Most implementors have never even tried to send mixed mode > XML to their server, and don't even know what will happen. Obviously > if customers were using this, the implementors would know exactly > whether this worked or not. If we conclude that anyxml already today is what anydata is supposed to be, then we should align the definition of anyxml in RFC602bis with the reality and move forward (and update the resolution of Y34 - I think you have an action on this one anyway). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 05:26:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5C4D1A701A for ; Wed, 3 Sep 2014 05:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, 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 n_FmapoZ5tEs for ; Wed, 3 Sep 2014 05:26:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 505AC1A0144 for ; Wed, 3 Sep 2014 05:26:52 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 232D91280098; Wed, 3 Sep 2014 14:26:51 +0200 (CEST) Date: Wed, 03 Sep 2014 14:26:51 +0200 (CEST) Message-Id: <20140903.142651.75125438713641072.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140903121539.GD80206@elstar.local> References: <20140903064746.GA79440@elstar.local> <20140903121539.GD80206@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wRovmgM4uqDefmw0eTEhd3Wu9BI Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:26:54 -0000 Juergen Schoenwaelder wrote: > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: > > > 2) No NETCONF implementation supports mixed mode XML. > > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 > > > > o Filtering of mixed content is not supported. > > > > > > The intent was to disallow mixed mode in all operations, not > > just subtree filtering. > > > > 3) IMO the IETF spends too much time on broken text, worrying about > > the letter of the law when there is little to no operational value to > > be gained. Most implementors have never even tried to send mixed mode > > XML to their server, and don't even know what will happen. Obviously > > if customers were using this, the implementors would know exactly > > whether this worked or not. > > If we conclude that anyxml already today is what anydata is supposed > to be If we do that, what does that mean for NETCONF? RFC 6241 uses 'anyxml' to describe content etc. If we make this change, it seems to indicate that NETCONF cannot relly be used with any other modelling languages than YANG. Maybe this is ok. /martin From nobody Wed Sep 3 05:55:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F1431A02AC for ; Wed, 3 Sep 2014 05:55:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.218 X-Spam-Level: X-Spam-Status: No, score=-4.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 EExxpeHr2iK5 for ; Wed, 3 Sep 2014 05:55:16 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54AEE1A0255 for ; Wed, 3 Sep 2014 05:55:16 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 144801DBB; Wed, 3 Sep 2014 14:55:15 +0200 (CEST) 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 ixv4lO3KBm9u; Wed, 3 Sep 2014 14:55:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 3 Sep 2014 14:55:14 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 487BB20036; Wed, 3 Sep 2014 14:55:14 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Rou0kBzsk0X3; Wed, 3 Sep 2014 14:55:13 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 233A420033; Wed, 3 Sep 2014 14:55:13 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 034492E58DE0; Wed, 3 Sep 2014 14:55:12 +0200 (CEST) Date: Wed, 3 Sep 2014 14:55:12 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140903125512.GF80206@elstar.local> Mail-Followup-To: Martin Bjorklund , andy@yumaworks.com, lhotka@nic.cz, netmod@ietf.org References: <20140903064746.GA79440@elstar.local> <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140903.142651.75125438713641072.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Let92CE67dn7vaetPqyvbUl2E-k Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:55:18 -0000 On Wed, Sep 03, 2014 at 02:26:51PM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: > > > > > 2) No NETCONF implementation supports mixed mode XML. > > > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 > > > > > > o Filtering of mixed content is not supported. > > > > > > > > > The intent was to disallow mixed mode in all operations, not > > > just subtree filtering. > > > > > > 3) IMO the IETF spends too much time on broken text, worrying about > > > the letter of the law when there is little to no operational value to > > > be gained. Most implementors have never even tried to send mixed mode > > > XML to their server, and don't even know what will happen. Obviously > > > if customers were using this, the implementors would know exactly > > > whether this worked or not. > > > > If we conclude that anyxml already today is what anydata is supposed > > to be > > If we do that, what does that mean for NETCONF? RFC 6241 uses > 'anyxml' to describe content etc. If we make this > change, it seems to indicate that NETCONF cannot relly be used with > any other modelling languages than YANG. Maybe this is ok. > Either Andy is correct that this is what all implementations do, namely restrict content to things that can be defined in YANG (note that my wording is different from your wording) or Andy's claim is not correct. The 'all' quantifier makes this difficult to evaluate. However, we can do a specific concensus call if necessary to settle explicitly this one point. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 3 05:59:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 890041A028A for ; Wed, 3 Sep 2014 05:59:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.569 X-Spam-Level: X-Spam-Status: No, score=-4.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, RP_MATCHES_RCVD=-0.668, 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 SMHe4lL05ynY for ; Wed, 3 Sep 2014 05:59:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 516B01A0144 for ; Wed, 3 Sep 2014 05:59:09 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 6DC7B1280098; Wed, 3 Sep 2014 14:59:08 +0200 (CEST) Date: Wed, 03 Sep 2014 14:59:08 +0200 (CEST) Message-Id: <20140903.145908.2112909954639851720.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140903125512.GF80206@elstar.local> References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oA2qUyVDNm8Q5a_T84bs0TBX7FM Cc: netmod@ietf.org Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 12:59:12 -0000 Juergen Schoenwaelder wrote: > On Wed, Sep 03, 2014 at 02:26:51PM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: > > > > > > > 2) No NETCONF implementation supports mixed mode XML. > > > > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 > > > > > > > > o Filtering of mixed content is not supported. > > > > > > > > > > > > The intent was to disallow mixed mode in all operations, not > > > > just subtree filtering. > > > > > > > > 3) IMO the IETF spends too much time on broken text, worrying about > > > > the letter of the law when there is little to no operational value to > > > > be gained. Most implementors have never even tried to send mixed mode > > > > XML to their server, and don't even know what will happen. Obviously > > > > if customers were using this, the implementors would know exactly > > > > whether this worked or not. > > > > > > If we conclude that anyxml already today is what anydata is supposed > > > to be > > > > If we do that, what does that mean for NETCONF? RFC 6241 uses > > 'anyxml' to describe content etc. If we make this > > change, it seems to indicate that NETCONF cannot relly be used with > > any other modelling languages than YANG. Maybe this is ok. > > > > Either Andy is correct that this is what all implementations do, > namely restrict content to things that can be defined in YANG (note > that my wording is different from your wording) Right; I started to write that, but then I was thinking that we have to define 'anyxml' as data modelled with YANG, since otherwise the JSON mapping won't work. /martin From nobody Wed Sep 3 10:27:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C6E31A005C for ; Wed, 3 Sep 2014 10:27:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.378 X-Spam-Level: X-Spam-Status: No, score=-3.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, GB_I_LETTER=-2, HTML_MESSAGE=0.001, J_CHICKENPOX_34=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 xzmmnET6lmkm for ; Wed, 3 Sep 2014 10:27:24 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7AD71A0114 for ; Wed, 3 Sep 2014 10:27:23 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id i50so8484400qgf.24 for ; Wed, 03 Sep 2014 10:27:21 -0700 (PDT) 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=YQHA+CgdColZutDAAk+esRfl4zg58uqPWAbXJDBA/5w=; b=AduMTP9BaUffsriP5yJhqTcsXaOhOQeOUzOexQsIIUo8r1o8V1wIPJO/K8w5C8o4p3 S+XMSJ+S8yA429hPtRz9HQDIIzXHN4Ep6eof68NDYI+4+zA+qxfUGJCyAP6w9iX0E52G NUapImFF7DLXPU7Bvwkyy/osyxcBVFgisNwsSqCaQx9+1jICRtAZehSEuXblogbnRSUf BaIzRHcmm45wlQcYmFKXjR3uTc6nnzHbSPHnUFc5WWlKSWvkdAX1fLwHqOnMC4OZJ9Ib /YhgcksG8K1PW3e3Owmyhp7SACgB20NTw/FVQ/uICQ0WnknikKFoyXYcRq6VadSD54uv b0nQ== X-Gm-Message-State: ALoCoQlaJOtOBhVOo7deKg4yv/wlk1nptRqAjtcKj+Nm4gUA4l+EMR6QEdbIQxQ+Bd1uTrrbxR33 MIME-Version: 1.0 X-Received: by 10.140.98.147 with SMTP id o19mr52011047qge.21.1409765240861; Wed, 03 Sep 2014 10:27:20 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Wed, 3 Sep 2014 10:27:20 -0700 (PDT) In-Reply-To: <20140903.145908.2112909954639851720.mbj@tail-f.com> References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> Date: Wed, 3 Sep 2014 10:27:20 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113a923c66741d05022c8cb2 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_fsaO-iSb_pj5-tRijfH1sTZOq4 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Sep 2014 17:27:26 -0000 --001a113a923c66741d05022c8cb2 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 3, 2014 at 5:59 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Wed, Sep 03, 2014 at 02:26:51PM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: > > > > > > > > > 2) No NETCONF implementation supports mixed mode XML. > > > > > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 > > > > > > > > > > o Filtering of mixed content is not supported. > > > > > > > > > > > > > > > The intent was to disallow mixed mode in all operations, not > > > > > just subtree filtering. > > > > > > > > > > 3) IMO the IETF spends too much time on broken text, worrying about > > > > > the letter of the law when there is little to no operational value > to > > > > > be gained. Most implementors have never even tried to send mixed > mode > > > > > XML to their server, and don't even know what will happen. > Obviously > > > > > if customers were using this, the implementors would know exactly > > > > > whether this worked or not. > > > > > > > > If we conclude that anyxml already today is what anydata is supposed > > > > to be > > > > > > If we do that, what does that mean for NETCONF? RFC 6241 uses > > > 'anyxml' to describe content etc. If we make this > > > change, it seems to indicate that NETCONF cannot relly be used with > > > any other modelling languages than YANG. Maybe this is ok. > > > > > > > Either Andy is correct that this is what all implementations do, > > namely restrict content to things that can be defined in YANG (note > > that my wording is different from your wording) > > Right; I started to write that, but then I was thinking that we have > to define 'anyxml' as data modelled with YANG, since otherwise the > JSON mapping won't work. > > Here is the extension Yuma has been using since 2008 to deal with the most common use-case: extension root { description "Used within a container definition to indicate it is really a root container for a conceptual NETCONF database, instead of just an empty container. This is needed for yuma to correctly process any RPC method that contains a 'config' parameter."; It is used in several protocol operations like /edit-config/input/config or /get-config/output/data. container data { ncx:root; } A plain parser will not know that "ncx:root" means the child nodes are expected to be to-level YANG data nodes., so it should have probably been designed to use anyxml: anyxml data { ncx:root; } I would like to add a new solution proposal for Y34: Solution Y34-04: * Consider a new statement called "root" that provides the ncx:root semantics. There may be restrictions on its use (i.e., may not be full data-def-stmt) root config { description "Container of top-level YANG data nodes representing the configuration"; } * For YANG 1.0 backward compatibility, allow anyxml to be used, except implementations MAY restrict the XML so it is not considered interoperable. * YANG Doctors will review each use of anyxml when YANG 1.1 is adopted, and avoid its use if possible (e.g., root should be used instead) (Does that mean anyxml SHOULD NOT be used -- deprecated?) * Do not add a replacement statement for anyxml (anydata) to YANG 1.1 Andy > > /martin > > > > > --001a113a923c66741d05022c8cb2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Wed, Sep 3, 2014 at 5:59 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:=
> On Wed, Sep 03, 2014 at 02:26:51PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote= :
> > >
> > > > 2) No NETCONF implementation supports mixed mode XML. > > > > There is only 1 mention of mixed mode XML in RFC 6241 i= n 6.2.5
> > > >
> > > >=A0 =A0o=A0 Filtering of mixed content is not supported.=
> > > >
> > > >
> > > > The intent was to disallow mixed mode in all operations= , not
> > > > just subtree filtering.
> > > >
> > > > 3) IMO the IETF spends too much time on broken text, wo= rrying about
> > > > the letter of the law when there is little to no operat= ional value to
> > > > be gained. Most implementors have never even tried to s= end mixed mode
> > > > XML to their server, and don't even know what will = happen.=A0 Obviously
> > > > if customers were using this, the implementors would kn= ow exactly
> > > > whether this worked or not.
> > >
> > > If we conclude that anyxml already today is what anydata is = supposed
> > > to be
> >
> > If we do that, what does that mean for NETCONF?=A0 RFC 6241 uses<= br> > > 'anyxml' to describe <edit-config> content etc.=A0 = If we make this
> > change, it seems to indicate that NETCONF cannot relly be used wi= th
> > any other modelling languages than YANG.=A0 Maybe this is ok.
> >
>
> Either Andy is correct that this is what all implementations do,
> namely restrict content to things that can be defined in YANG (note > that my wording is different from your wording)

Right; I started to write that, but then I was thinking that we have
to define 'anyxml' as data modelled with YANG, since otherwise the<= br> JSON mapping won't work.



Here is the extension Yuma has been using s= ince 2008 to deal with the
most common use-case:

   extension root {
      description
        "Used within a containe=
r definition to indicate it is
       really a root container for a conceptual NETCONF database,
       instead of just an empty container.  This is needed
       for yuma to correctly process any RPC method
       that contains a 'config' parameter.";

It is us= ed in several protocol operations like /edit-config/input/config or
/get-config/output/data.

=A0 =A0 container data= {
=A0 =A0 =A0 =A0 ncx:root;
=A0 =A0 =A0}

<= div>A plain parser will not know that "ncx:root" means the child = nodes are
expected to be to-level YANG data nodes., so it should = have probably
been designed to use anyxml:

=A0 =A0anyxml da= ta {
=A0 =A0 =A0 =A0ncx:root;
=A0 =A0}

I would like to add a new solution proposal for Y34:
Solution Y34-04:

* Consider a new statement called= "root" that provides the ncx:root semantics.
=A0 =A0Th= ere may be restrictions on its use (i.e., may not be full data-def-stmt)

=A0 =A0root config {
=A0 =A0 =A0 description = "Container of top-level YANG data nodes representing the configuration= ";
=A0 =A0}

* For YANG 1.0 backward= compatibility, allow anyxml to be used,
=A0 =A0except implementations MAY restrict the XML so it is not consid= ered interoperable.

=A0* YANG Doctors will review = each use of anyxml when YANG 1.1 is adopted,
=A0 =A0 and avoid it= s use if possible (e.g., root should be used instead)
=A0 =A0(Does that mean anyxml SHOULD NOT be used -- deprecated?)
=

=A0* Do not add a replacement statement for anyxml (any= data) to YANG 1.1


Andy

=A0=A0
=A0

/martin





--001a113a923c66741d05022c8cb2-- From nobody Wed Sep 3 17:01:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B3581A8771; Wed, 3 Sep 2014 17:01:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102 X-Spam-Level: X-Spam-Status: No, score=-102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 BExp1s7PStnd; Wed, 3 Sep 2014 17:00:52 -0700 (PDT) Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FDD31A8774; Wed, 3 Sep 2014 17:00:51 -0700 (PDT) X-AuditID: c6180641-f79916d00000623a-d6-54075420e4cd Received: from EUSAAHC004.ericsson.se (Unknown_Domain [147.117.188.84]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id B9.4A.25146.02457045; Wed, 3 Sep 2014 19:47:12 +0200 (CEST) Received: from EUSAAMB103.ericsson.se ([147.117.188.120]) by EUSAAHC004.ericsson.se ([147.117.188.84]) with mapi id 14.03.0174.001; Wed, 3 Sep 2014 20:00:48 -0400 From: Gregory Mirsky To: "Tissa Senevirathne (tsenevir)" , "'draft-tissa-netmod-oam@tools.ietf.org'" Thread-Topic: draft-tissa-netmod-oam Thread-Index: Ac+tKouGZjiF/7GjRZGwGunQsgwS9AVplJ1wAT/fSeA= Date: Thu, 4 Sep 2014 00:00:47 +0000 Message-ID: <7347100B5761DC41A166AC17F22DF1121B82A71B@eusaamb103.ericsson.se> References: <7347100B5761DC41A166AC17F22DF1121B82567E@eusaamb103.ericsson.se> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [147.117.188.10] Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKIsWRmVeSWpSXmKPExsUyuXRPiK5CCHuIwZnPphZ7t71ktXj87RC7 xa2lK1kt5l9sZLV4Ol/S4vOfbYwWxy/8ZrSYt+sDk0X3j6dsDpweU35vZPVYsuQnk8eXy5/Z ApijuGxSUnMyy1KL9O0SuDI2N35iLFg9k6ni+6JNTA2MbZ8Yuxg5OSQETCT+v5rFBGGLSVy4 t56ti5GLQ0jgKKPE5kvrWCCcZYwSB3bMYAOpYhMwknixsYcdJCEi0M8o8X7eHbAqZoFGJonv 19+zglQJC6hIPD9wFqxDREBVYn/jf2YI20ri69K1YPtYgGpe/rkIVs8r4CuxZM9OJoh1Exgl Pk3pBDuQEyjR3PuKBcRmBDrw+6k1YM3MAuISt57MhzpcAKj5PDOELSrx8vE/VghbSWLS0nOs EPX5Et/mr2GGWCYocXLmE5YJjKKzkIyahaRsFpIyiLiOxILdn9ggbG2JZQtfM8PYZw48ZkIW X8DIvoqRo7Q4tSw33chwEyMwXo9JsDnuYFzwyfIQowAHoxIP7wJWthAh1sSy4srcQ4zSHCxK 4rya1fOChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTCqXGqU6FRI+tmWLxsSXHN667dHG45/ 9eFZlH50qa/4yZkP54qqVa1yWmghkj9rxn+xvszlHfcuJ9oeqDyjtWIyJ7uI2gKXAxz35i46 d3zD9CfTtqukPRT43fr/ytGwAIFHljZcDd+8BYVur89YnGbL5cO/vuJKiM/hikdePHdsnygz eDX/+q6kxFKckWioxVxUnAgAY9KYUbgCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/y0aEugl62d-Os9akudogdSUH4Yc Cc: "l2vpn@ietf.org" , "mpls@ietf.org" , "spring@ietf.org" , "time@ietf.org" , "'netmod@ietf.org'" , "nvo3@ietf.org" , "rtg-bfd@ietf.org" Subject: Re: [netmod] draft-tissa-netmod-oam X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 00:01:04 -0000 --_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Tissa, thank you for detailed and informative response. Information about OAM work= at TRILL WG is very interesting as I haven't been following it in much det= ails. I'd note that applicability of the model developed at TRILL WG to MPL= S OAM is not clear to me. I think that it would be helpful to discuss relev= ance of the TRILL's OAM model at MPLS and MPLS technology related WGs befor= e presenting it as the model that encompasses MPLS. Similarly, I think, for= the IP. Perhaps, for the time, we can refer to the model as TRILL OAM. Mor= e notes in-lined and tagged GIM>>. Regards, Greg From: Tissa Senevirathne (tsenevir) [mailto:tsenevir@cisco.com] Sent: Thursday, August 28, 2014 8:24 AM To: Gregory Mirsky; 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@= ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org Subject: RE: draft-tissa-netmod-oam Greg Before answering the specific questions below, would like explain few aspe= cts related to the extended CFM model used here. CFM originally was design= ed exclusively for Ethernet. As part of the TRILL OAM work we decoupled CFM= model from Ethernet based addressing and made it addressing independent. T= hat is the CFM model that is referred here. CFM defines a complete fault model that include fault domains, Test point, = Layering etc. Strict definition of such is needed to develop a complete OAM= solution regardless of the underline technology. CFM does a fantastic job = in accomplishing that and AFIK there is no other model. We are leveraging t= hat model. The word generic OAM is utilized here to indicate that the model can be app= lied regardless of the underlying technology. YANG model is not a one-one copy of CFM YANG defined in MEF. Rather it is d= efined with address independent and extensibility in mind. With the above in mind, specific answers in-line: From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky Sent: Sunday, August 24, 2014 10:15 PM To: 'draft-tissa-netmod-oam@tools.ietf.org' Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; 'netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@iet= f.org Subject: draft-tissa-netmod-oam Dear Authors, et.al, please kindly consider my comments and questions to this document: * Introduction o "... it is a reasonable choice to develop the unified OAM framework ba= sed on those (CFM) concepts." I agree that for packet switching connection-= oriented networks that are based on G.800 architecture CFM, but more so Y.1= 731, provides shared concepts. I think that the same cannot be said for con= nectionless packet switching networks. Thus extending CFM model onto arbitr= ary networks without consideration whether these are connection-oriented or= connectionless is very questionable approach, IMO; [Answer] As stated above it is the OAM Model that is leveraged here. Regard= less of connection oriented or not the model on Fault domains, Test points = etc is valid. In theory connection oriented can be broken in to connection establishment = and data forwarding. With that in mind, one can define Fault domain and tes= t points. Followed by definition of the Fault identifications tools accordi= ngly. Do you have a preferred OAM tool for fault verification/isolation and loss= and performance monitoring for connection oriented connectuons ?. If so wo= uld like to review and map to the model. GIM>> I don't have "favorite tool" but would point that in connectionless n= etwork one cannot define Mis-connection defect and thus OAM models for con= nectionless and connection-oriented networks would be different. o "...CFM, it is a reasonable choice to develop the unified OAM framework= based on those concepts" IP OAM is not based on Ethernet Service OAM model= or principles but, IMO, OAM of overlay networks more closer resemble IP OA= M as these networks are connectionless in their architecture; [Answer] Please see the answer above and extended CFM model. It is the mod= el that is presented here, regardless of the connectioness, OAM tools need= fault domains and fault boundaries. Addidtionally as stated in the explana= tion above, there is nothing Ethernet in CFM, once the addressing is decoup= led. o "The YANG model presented in this document is the base model and suppor= ts IP Ping and Traceroute." If only these and similar OAM tools, e.g. LSP p= ing, Loopback/Linktrace, are in scope of the document, then, I believe, the= title may say something like "YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect". Referring to ping/traceroute as "ge= neric OAM" comes as stretch too far; [Answer] I think there is a miss understanding this model is not limited to= Ping and Trace route. Ping and traceroute are only examples to get the wor= k stared and discussion going. As we go along other tools will be mapped to= the model. GIM>> LSP Ping does more that ICMP or CFM's Loopback and Linktrace as it ve= rifies correlation between control and data planes. Had that functionality = been removed by TRILL OAM from "extended CFM model"? o "...initiate a performance monitoring session can do so in the same ma= nner regardless of the underlying protocol or technology" I'd point to work= of LMAP WG on informational model of performance measurements in large-sca= le access networks, work of ITU-T's SG15, MEF. Perhaps sentence can be stop= ped after "... or a Traceroute". [Answer] I did not fully understand your point. o "In this document we define the YANG model for Generic OAM" Can you pro= vide definition or reference to the definition of the "Generic OAM"? It is = challenging to validate informational model of something that not been suff= iciently defined. [Answer] As explained earlier terminology generic OAM is used to indicate = that the presented OAM model can be applied independent of the underlying t= echnology. In section 1, we have stated the following: "..In this document,= we take the [8021Q] CFM model and extend it to a technology independent fr= amework and build the corresponding YANG model accordingly. The YANG model = presented in this document is the base model and supports IP Ping and Trace= route. The generic OAM YANG model is designed such that it can be extended = to cover various technologies. Technology dependent nodes and RPC commands = are defined in technology specific YANG models, which use and extend the ba= se model defined here. .... " GIM>> Had other WGs agreed that the proposed by TRILL WG OAM model is repre= sentative of their technologies? If not, then what "Generic" is there? * Section 3 o "This allows users to traverse between OAM of different technologies at= ease through a uniform API set." Usually relationships between OAM layers = referred and viewed as OAM interworking. There are several examples of IETF= addressing aspects of OAM interworking. I think that interworking includes= not only scenarios of nested OAM layers but peering layers and thus is bro= ader than introduced in the document "nested OAM". [Answer] Can you please provide some example here, I am not quite clear. Guessing from the word peering, if we are referring to cascaded sections of= different technologies such as IP Cloud, MPLS cloud and another IP cloud. = Then the model presented here is the answer. You can have an end end OAM se= ssion at a higher MD-Level. Each of the clouds below can have separate OAM = at a lower MD-Level. These can be utilized for fault isolation. o Figure 1 depicts OAM of both connection-oriented and connectionless net= works. What you see common, generic in respective OAM of these networks? [Answer] Please see the answers above. * Section 4 o "In IP, the MA can be per IP Subnet ..." As there's no definition of MA= in IP, is this the definition or one of examples. Can MA in IP network be = other than per IP Subnet? [Answer] It is ".. can be", so it meant to be an example and other possibil= ities are not ruled out and model does not assume any such limitation. o "Under each MA, there can be two or more MEPs (Maintenance End Points)"= Firstly, since you adopt MA-centric terminology, MEP stands for Maintenanc= e Association End Point. Secondly, in some OAM models Down and Up MEP being= distinguished. Would your model consider that? As there's no definition of= MEP for several networks you've listed, e.g. IP, how the YANG model will a= bstract something that is not defined? And thirdly, how and where MIPs are = located in IP OAM? [Answer] Yes model accept both UP/Down. One cannot say for IP there is no MEP. MEP is a functional abstraction of a= test point that generate and respond to OAM messages. In that regard IP de= vices today have an implicit MEP at the CPU. The model allow to provide mor= e semantics to the MEP and allow to create UP/Down per interface or other s= cope, hence providing more granularity in fault isolation/verification and = monitoring. GIM>> Is IP MEP being defined as being in control plane/CPU? What if it is = in NPU, i.e. data plane? If on CPU, then what differentiates Up MEP from Do= wn MEP from POV of packets it transmits and receives? And how MIP functions= in IP based on TRILL OAM model? Is it, as in Ethernet OAM, constructed of = two MHFs? Thank you for your consideration of my notes and looking forward to the int= eresting discussion. Thank you for spending time to review and comment. We are updating the next= version with comments received so far and specifically during IETF in Cana= da. We are more than happy enhance where applicable or need more clarity. Regards, Greg --_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Tissa,

thank you for detailed= and informative response. Information about OAM work at TRILL WG is very i= nteresting as I haven’t been following it in much details. I’d = note that applicability of the model developed at TRILL WG to MPLS OAM is not clear to me. I think that it would be helpful = to discuss relevance of the TRILL’s OAM model at MPLS and MPLS techno= logy related WGs before presenting it as the model that encompasses MPLS. S= imilarly, I think, for the IP. Perhaps, for the time, we can refer to the model as TRILL OAM. More notes in-lined = and tagged GIM>>.

 

   &nbs= p;            Regard= s,

   &nbs= p;            &= nbsp;           &nbs= p;   Greg

 

From: Tissa Se= nevirathne (tsenevir) [mailto:tsenevir@cisco.com]
Sent: Thursday, August 28, 2014 8:24 AM
To: Gregory Mirsky; 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; time@ietf.org; '= netmod@ietf.org'; nvo3@ietf.org; rtg-bfd@ietf.org
Subject: RE: draft-tissa-netmod-oam

 

Greg=

 

Before answering the s= pecific questions below,  would like explain few aspects related to th= e extended CFM model used here. CFM  originally was designed exclusive= ly for Ethernet. As part of the TRILL OAM work we decoupled CFM model from Ethernet based addressing and made it addressi= ng independent. That is the CFM model that is referred here.

 

CFM defines a complete= fault model that include fault domains, Test point, Layering etc. Strict d= efinition of such is needed to develop a complete OAM solution regardless o= f the underline technology. CFM does a fantastic job in accomplishing that and AFIK there is no other model. We= are leveraging that model.

 

The word generic OAM i= s utilized here to indicate that the model can be applied regardless of the= underlying technology.

 

YANG model is not a on= e-one copy of CFM YANG defined in MEF. Rather it is defined with address in= dependent and extensibility in mind.

 

With the above in mind= , specific answers in-line:

 

From: L2vpn [<= a href=3D"mailto:l2vpn-bounces@ietf.org">mailto:l2vpn-bounces@ietf.org] On Behalf Of Gregory Mirsky
Sent: Sunday, August 24, 2014 10:15 PM
To: 'draft-tissa-netmod-oam@tools.ietf.org'
Cc: l2vpn@ietf.org; mpls@ietf.org; spring@ietf.org; = time@ietf.org; 'netmod@ietf.org'; nvo3= @ietf.org; rtg-bfd@ietf.org
Subject: draft-tissa-netmod-oam

 

Dear Authors, et.al,

please kindly consider my comments and questions to = this document:

·         Introduction

o    “… it is a reasonable choi= ce to develop the unified OAM framework based on those (CFM) concepts.̶= 1; I agree that for packet switching connection-oriented networks that are = based on G.800 architecture CFM, but more so Y.1731, provides shared concepts. I think that the same cannot be said for connectionless p= acket switching networks. Thus extending CFM model onto arbitrary networks = without consideration whether these are connection-oriented or connectionle= ss is very questionable approach, IMO;

 

 

[Answer] As stated abo= ve it is the OAM Model that is leveraged here. Regardless of connection ori= ented or not the model on Fault domains, Test points etc is valid.

 

In theory connection o= riented can be broken in to connection establishment and data forwarding. W= ith that in mind, one can define Fault domain and test points. Followed by = definition of the Fault identifications tools accordingly.

 

Do you have a preferre= d OAM tool  for fault verification/isolation and loss and performance = monitoring for connection oriented connectuons ?. If so would like to revie= w and map to the model.

 

GIM>> I don̵= 7;t have “favorite tool” but would point that in connectionless= network one cannot define Mis-connection defect and thus OAM models for &n= bsp;connectionless and connection-oriented networks would be different.

 

o   “…CFM, it is a reasonable choice= to develop the unified OAM framework based on those concepts” IP OAM= is not based on Ethernet Service OAM model or principles but, IMO, OAM of = overlay networks more closer resemble IP OAM as these networks are connectionless in their architecture;

 

[Answer]  Please = see the answer above and extended CFM model. It is the model that is presen= ted here, regardless of the connectioness,  OAM tools need fault domai= ns and fault boundaries. Addidtionally as stated in the explanation above, there is nothing Ethernet in CFM, once the addre= ssing is decoupled.

 

o   “The YANG model presented in this docu= ment is the base model and supports IP Ping and Traceroute.” If only = these and similar OAM tools, e.g. LSP ping, Loopback/Linktrace, are in scop= e of the document, then, I believe, the title may say something like “YANG model of on-demand OAM tool to detect a= nd localize Loss of Continuity defect”. Referring to ping/traceroute = as “generic OAM” comes as stretch too far;

 

[Answer] I think there= is a miss understanding this model is not limited to Ping and Trace route.= Ping and traceroute are only examples to get the work stared and discussio= n going. As we go along other tools will be mapped to the model.

 

GIM>> LSP Ping d= oes more that ICMP or CFM’s Loopback and Linktrace as it verifies cor= relation between control and data planes. Had that functionality been remov= ed by TRILL OAM from “extended CFM model”?

 

o    “…initiate a performance m= onitoring session can do so in the same manner regardless of the underlying= protocol or technology” I’d point to work of LMAP WG on inform= ational model of performance measurements in large-scale access networks, work of ITU-T’s SG15, MEF. Perhaps sentence can be stopped= after “… or a Traceroute”.

[Answer] I did not ful= ly understand your point.

 

o   “In this document we define the YANG m= odel for Generic OAM” Can you provide definition or reference to the = definition of the “Generic OAM”? It is challenging to validate = informational model of something that not been sufficiently defined.

 

[Answer]  As expl= ained earlier terminology generic OAM is used to indicate that the presente= d OAM model can be applied independent of the underlying technology. In sec= tion 1, we have stated the following: “..In this document, we take the [8021Q] CFM model and extend it to a technology= independent framework and build the corresponding YANG model accordingly. = The YANG model presented in this document is the base model and supports IP= Ping and Traceroute. The generic OAM YANG model is designed such that it can be extended to cover various t= echnologies. Technology dependent nodes and RPC commands are defined in tec= hnology specific YANG models, which use and extend the base model defined h= ere. …. “

 

GIM>> Had other = WGs agreed that the proposed by TRILL WG OAM model is representative of the= ir technologies? If not, then what “Generic” is there?

 

·         Section 3

o   “This allows users to traverse between= OAM of different technologies at ease through a uniform API set.” Us= ually relationships between OAM layers referred and viewed as OAM interwork= ing. There are several examples of IETF addressing aspects of OAM interworking. I think that interworking includes not only s= cenarios of nested OAM layers but peering layers and thus is broader than i= ntroduced in the document “nested OAM”.

[Answer]  Can you= please provide some example here, I am not quite clear.<= /p>

 

Guessing from the word= peering, if we are referring to cascaded sections of different technologie= s such as IP Cloud, MPLS cloud and another IP cloud. Then the model present= ed here is the answer. You can have an end end OAM session at a higher MD-Level. Each of the clouds below can = have separate OAM at a lower MD-Level. These can be utilized for fault isol= ation.

 

o   Figure 1 depicts OAM of both connection-orie= nted and connectionless networks. What you see common, generic in respectiv= e OAM of these networks?

 

[Answer] Please see th= e answers above.

 

·         Section 4

o   “In IP, the MA can be per IP Subnet &#= 8230;” As there’s no definition of MA in IP, is this the defini= tion or one of examples. Can MA in IP network be other than per IP Subnet?<= o:p>

[Answer] It is “= .. can be”, so it meant to be an example and other possibilities are = not ruled out and model does not assume any such limitation.

 

o   “Under each MA, there can be two or mo= re MEPs (Maintenance End Points)” Firstly, since you adopt MA-centric= terminology, MEP stands for Maintenance Association End Point. Secondly, i= n some OAM models Down and Up MEP being distinguished. Would your model consider that? As there’s no definition of MEP for = several networks you’ve listed, e.g. IP, how the YANG model will abst= ract something that is not defined? And thirdly, how and where MIPs are loc= ated in IP OAM?

 

[Answer] Yes model acc= ept both UP/Down.

 

One cannot say for IP = there is no MEP. MEP is a functional abstraction of a test point that gener= ate and respond to OAM messages. In that regard IP devices today have an im= plicit MEP at the CPU. The model allow to provide more semantics to the MEP and allow to create UP/Down per inter= face or other scope, hence providing more granularity in fault isolation/ve= rification and monitoring.

 

GIM>> Is IP MEP = being defined as being in control plane/CPU? What if it is in NPU, i.e. dat= a plane? If on CPU, then what differentiates Up MEP from Down MEP from POV = of packets it transmits and receives? And how MIP functions in IP based on TRILL OAM model? Is it, as in Ethernet OA= M, constructed of two MHFs?

 

Thank you for your consideration of my notes and loo= king forward to the interesting discussion.

 

Thank you for spending= time to review and comment. We are updating the next version with comments= received so far and specifically during IETF in Canada. We are more than h= appy enhance where applicable or need more clarity.

 

Regards,

    =     Greg

--_000_7347100B5761DC41A166AC17F22DF1121B82A71Beusaamb103erics_-- From nobody Thu Sep 4 00:37:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B86841A6EE8 for ; Thu, 4 Sep 2014 00:37:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 WQOsLyc_UO21 for ; Thu, 4 Sep 2014 00:37:43 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95A371A6EE1 for ; Thu, 4 Sep 2014 00:37:43 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0E43C1411 for ; Thu, 4 Sep 2014 09:37:42 +0200 (CEST) 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 aGeSprFcmVS4 for ; Thu, 4 Sep 2014 09:37:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 4 Sep 2014 09:37:40 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8A28120035 for ; Thu, 4 Sep 2014 09:37:40 +0200 (CEST) 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 3f0oAPZ_vMPE; Thu, 4 Sep 2014 09:37:38 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AC4520033; Thu, 4 Sep 2014 09:37:38 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4B1CC2E59AC2; Thu, 4 Sep 2014 09:37:36 +0200 (CEST) Date: Thu, 4 Sep 2014 09:37:36 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140904073736.GA82703@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="CE+1k2dSO48ffgeK" Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LDeoz-KGSgf07f0JpR4NBRun2s8 Subject: [netmod] draft minutes of the NETMOD 2014-09-03 virtual interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:37:46 -0000 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, attached are the draft minutes of yesterday's virtual interim meeting. Please let me know if something needs fixing by the beginning of next week so that I can send the final version to the secretariat. You can also find all the virtual interim meeting minutes next to the YANG 1.1 issue list in the NETMOD WG subversion repository: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/ /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --CE+1k2dSO48ffgeK Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="netmod-2014-09-03-minutes.txt" ============================================================= NETCONF Data Modeling Language WG (netmod) 4th YANG 1.1 Virtual Interim Wednesday, September 3rd, 2014, 16:00-18:00 CEST Minutes Juergen Schoenwaelder ============================================================= * Participants - JS = Juergen Schoenwaelder - MB = Martin Bjorklund - PO = Peyman Owladi - DR = David Reid - BC = Benoit Claise - AB = Andy Bierman - LL = Ladislav Lhotka - MJ = Mahesh Jethanandani * Y09 introduce optional keys PO: Why is at least one key element required? PO: What if in an xpath expression suddenly evaluates to a node set rather than a single node? MB: We need to extend the instance-identifier syntax to be able to express that a certain key element is absent. PO: Right now, an instance-identifier is valid xpath, we should not diverge from it. JS: If you allow to add an optional key while revising a YANG module, does this not potentially affect other modules? Does this at the end require import by revision everywhere? JS: The concern is breaking the contract when adding an optional key, but this is likely the most interesting use case. MB: Yes, this may be problematic. Perhaps we should not allow to change the key statement, i.e., optional keys can't be added later on. JS: You can have optional keys today by designing special 'null' values for optional key elements. MB: The primary use case is not necessarily YANG module updates. The workarounds you mention as possible today but they are clumsy. AB: Does this proposal affect error-path? MB: No, error-path is already an xpath expression. As long as instance-identifier remain a subset of xpath, this will work. Proposal: adopt Y09-02 but do not allow leafs to be added to a key in a module update and the instance-identifier syntax needs to be extended to express that certain key elements have no value. * Y34 remove/deprecate/replace the 'anyxml' statement LL: Why do we need anydata at all? MB: There are use cases for anyxml although rare. JS: Example: Kent's configlets. MB: Example: Definition of edit-config. AB: I have something we call a docroot, something that holds a top-level YANG node. JS: What is the difference between docroot and the proposed anydata? AB: The docroot is anydata restricted to top-level YANG nodes. MB: Since NETCONF is defined using anyxml, changing anyxml is changing the protocol. LL: Leave anyxml as it is. LL: But this is hard for JSON. MB: That is the reason why I propose to add anydata, which may be easier to deal with. AB: The reason implementations do not support mixed mode or PIs is to avoid passing raw data to callbacks and hence everything is restricted to a few types in the implementations I am familiar with. AB: I support anyxml but make it clear that it is non-interoperable. LL: Yes, and I propose to leave it completely open how anyxml is represented in JSON. MB: If we keep anyxml and mark it as should not be used, do we even have to translate anyxml into JSON? MB: If we have anydata, why can't you follow the usual JSON rules? AB: It seems to work for us, except every value is JSON encoded as a string. LL: You need to know the difference between a list and a container. AB: My implementation hands the tree to the application. AB: We only use docroot in RPC definitions and everything else is theoretical and of no practical use. MB: There is one other use case: A list say containing the last N notifications. It is still not anyxml but anydata. LL: We could have simpler rules for anydata that work like generic XML to JSON translators. MB: What about namespaces? I think we need them. LL: I am not sure we need them. AB: So how do the many online XML to JSON translators work? LL: They use arbitrary solutions for things like namespaces. MB: The translator needs all the data models. I personally think this is fine. JS: For ncclient, the interface to the lower layer is typeless and it is a significant change to make it type aware etc. AB: Our server will convert things as needed and basically ignore the JSON type. LL: I started with what is the most natural representation. Otherwise, what is the value of JSON? AB: For me, the value is that JSON is more compact data encoding. I do not care about having type information in the encoding. Our code has no interest to reject data just because the JSON type was wrong. Making JSON types authoritative seems backwards. LL: What about making it legal to allow sending integers as strings? JS: If I am allowed to send strings, the world changes for me. MB: This also solves the problem of dealing with numbers in unions. MB: In edit-config, it is not just XML elements but also attributes. JS: So we have to keep anyxml for these rare corner cases (typically the definition of RPCs). But we should have big warnings about the usage of anyxml in data models and instead introduce anydata. MB: Even if we allow encoding of values as strings and require that the receiver be able to translate to the proper YANG type, we still have the namespace problem. LL: What is the problem with normal data? MB: You need the mapping URI to YANG module name. JS: A URI is not something ugly. In fact, you use the YANG namespace statement to define the namespace. LL: URIs tend to be longer than module names and they can contain more 'interesting' characters. JS: But the URI character set is restricted. LL: A URI can contain colons so the separate colon cannot be used. JS: Yes, we need to pick a different delimiter. Some use {}name. I do not care much which character is used. JS: I am concerned that using two different identifiers to identify what is essentially the same namespace adds complexity for no real value. Even operationally, when people are confronted with JSON and XML snippets, they are exposed to different identifiers for the same thing. I do not see how that makes things simpler. Proposal: Keep anyxml and add text that usage of anyxml in regular data models is generally not interoperable and that anyxml should only be used in certain special cases (e.g., the definition of NETCONF RPCs). Add an anydata statement that is restricted to data that can be defined using YANG. For the JSON mapping, allow string encoding and require the receivers are expected to do type conversions in case the JSON type does not match the YANG type instead of treating a JSON type mismatch as an error. For anydata, the JSON encoding should be well defined. No agreement has been reached yet on the handling of namespaces, that is whether module names or URIs should be used. --CE+1k2dSO48ffgeK-- From nobody Thu Sep 4 00:40:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5D031A6EF9 for ; Thu, 4 Sep 2014 00:40:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 KVrbOi02yTvU for ; Thu, 4 Sep 2014 00:40:00 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C46D1A6EE1 for ; Thu, 4 Sep 2014 00:40:00 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 20CB71424 for ; Thu, 4 Sep 2014 09:39:59 +0200 (CEST) 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 BB_O6Th9uS02 for ; Thu, 4 Sep 2014 09:39:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 4 Sep 2014 09:39:58 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8FBC320035 for ; Thu, 4 Sep 2014 09:39:58 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Hn4Rpw_XmxAt; Thu, 4 Sep 2014 09:39:58 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0FF020033; Thu, 4 Sep 2014 09:39:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AF7E42E59B08; Thu, 4 Sep 2014 09:39:57 +0200 (CEST) Date: Thu, 4 Sep 2014 09:39:57 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140904073957.GA82728@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pv13IXQ-RQAm-WeDWtV3LzLsHtc Subject: [netmod] virtual interim meeting on 2014-09-10 canceled X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:40:02 -0000 Hi, we will not have a virtual interim meeting next week since there is a NETCONF virtual interim meeting next week and we have the face-to-face meeting coming up the following week on September 17-18. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 4 00:50:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EC2F1A6F26 for ; Thu, 4 Sep 2014 00:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.169 X-Spam-Level: X-Spam-Status: No, score=-15.169 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.668, 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 u3_rUEAW3wQg for ; Thu, 4 Sep 2014 00:50:24 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 603DA1A6EF7 for ; Thu, 4 Sep 2014 00:50:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7064; q=dns/txt; s=iport; t=1409817023; x=1411026623; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=PuUJA0q3E8Hc3ieXyL4mgHPbUBRz3tCRvsGV9Y4T108=; b=lkKTWTWWaD6bvNvEjq0NsCq6AxiTnGl4utvUdXKeap7JjGioUAdzFrmy jqn74ug0J979jzwTD5vPqAOXYJxcAAPLLFPlPOiw0nOtS/cTUVk6PhAXS 9qzx0xXAOcTShIPd9470aD6s0EyHS6ybRKIal2DeNRXygDbehISo7tDkd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqIEAMEYCFStJssW/2dsb2JhbABZg2DIcYdMAYEed4QEAQEDATIBBS8RBgsLIRYECwkDAgECAUUTCAEBF4gfCA2+NgEXjQqBYREBV4RMAQSVboEFhXmHOY1pghuBSDsvAQEBgQUHFwaBIwEBAQ X-IronPort-AV: E=Sophos;i="5.04,464,1406592000"; d="scan'208";a="160738697" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 04 Sep 2014 07:50:21 +0000 Received: from [10.60.67.85] (ams-bclaise-8914.cisco.com [10.60.67.85]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s847oLrC026079 for ; Thu, 4 Sep 2014 07:50:21 GMT Message-ID: <540819BB.6030906@cisco.com> Date: Thu, 04 Sep 2014 09:50:19 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140903111127.GA79883@elstar.local> In-Reply-To: <20140903111127.GA79883@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4dfd00_P17IFT6CFijNni7gNQos Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:50:26 -0000 Jürgen, WG, I like the way the interim meetings are run. This brings speed to the process. Thanks. However, let me repeat a statement I made a few times. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (or whatever support), must also document the rational for selecting a specific solution. Something like: solution 1 was rejected because of reason 1, 2, and 3 the issue could be addressed with both solutions 1 and 2 current implementations don't use the feature this way solution 2 is easier from an implementation point of view because ... in conclusion, solution 2 is plebiscited by the WG What's the reasoning ? We don't want to redo the discussions over and over. Following RFC 7282, how can we say to a new participant in the WG: "We hear you. This argument was discussed, and the consensus was ... Do you have another argument in favor of a different solution? Basically, have we overlooked anything?" Without some documentation, this is not possible. Regards, Benoit > Hi, > > we managed to go over all issues except those issues that we will be > disussing during the face-to-face interim meeting. This email provides > a summary of where we are with the issues not marked DEAD. I am also > including actions that need to be carried out. > > If you disagree with any of the following proposed resolutions, please > speak up as soon as possible but no later than September 16 (so that > we have the input before the face-to-face interim meeting starts). If > you want to raise a concern, please start a threat with the issue > identifier in the subject line. > > * OPEN :Y01: allow boolean if-feature > > 2014-06-11 meeting proposal: adopt Y01-01. > > * OPEN :Y02: allow must in input, output, and notification > > 2014-06-11 meeting proposal: adopt Y02-01. > > * OPEN :Y03: allow if-feature in refine > > 2014-06-11 meeting proposal: adopt Y03-01. > > * OPEN :Y04: accessible tree in xpath in notifs and rpc > > 2014-06-11 meeting proposal: adopt Y04-02. > > * OPEN :Y05: unprefixed path in top-level typedef > > 2014-06-11 meeting action: MB to write down solution Y05-03 and once > done we get back to this issue. > > * OPEN :Y06: escaped characters in double quoted strings > > 2014-06-11 meeting proposal: adopt Y06-02. > > * OPEN :Y07: do not allow when or if-feature on keys > > 2014-07-02 meeting proposal: adopt Y07-01 with a clarification about > the condition > > * OPEN :Y09: introduce optional keys <> > > 2014-07-02 meeting action: MB to write up a solution proposal and > once done we get back to this issue. > > * OPEN :Y10: allow restrictions on enumerations > > 2014-07-02 meeting action: LL to write down another syntax proposal > and MB to expand Y10-01. > > * OPEN :Y11: allow if-feature on enums > > 2014-07-02 meeting proposal: Adopt Y11-01 with the extension to > allow if-feature also for bits and identities. > > * OPEN :Y12: initialized-by system > > 2014-07-02 meeting proposal: Adopt Y12-01 but think about a better > syntax. Applies to leaf and leaf-lists. MB to create concrete text. > > * OPEN :Y13: allow multiple inheritance for identities > > 2014-07-02 meeting action: LL to write a more complete example and > once done we get back to this issue. > > * OPEN :Y14: clarify the string value for identities when used in must/when > > 2014-07-02 meeting proposal: adopt Y14-01. > > * OPEN :Y16: module advertisement optimization > > 2014-07-02 meeting action: MB to look at the details whether Y16-02 > can be made to work. > > * OPEN :Y18: fix "when" expression context node problem > > 2014-07-02 meeting action: LL to write up an example in which > situations Y18-01 is problematic. > > * OPEN :Y20: new set of built-in XPath functions > > 2014-07-09 meeting proposal: MB to copy the functions he proposed to > RFC 6020bis as a starting point and then we review and discuss > changes. > > * OPEN :Y23: support negative patterns as string restrictions > > 2014-07-09 meeting proposal: adopt Y23-02. > > * OPEN :Y25: make enum numbering purely informative and optional > > 2014-07-09 meeting proposal: adopt Y25-01. > > * OPEN :Y26: allow mandatory nodes in augment > > 2014-07-09 meeting action: There is agreement that the current text > is overly restrictive. The proposal is to add general guiding rules > that backwards compatibility needs to be maintained. Lets see > whether someone can write more concrete rules when mandatory nodes > in augment are allowed. > > * OPEN :Y27: allow mandatory nodes in an updated module > > 2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to > check what the feature issue is about, possible action to add > guidelines how to go from current to deprecated to obsolete in RFC > 6087bis. > > * OPEN :Y28: support default values in leaf-lists > > 2014-07-09 meeting action: AB will look at the necessary text and > what it means to modify leaf-list values. Perhaps there is a need to > have a different keyword since the behavior is rather different > here. > > * OPEN :Y29: allow choice as a short-hand case > > 2014-07-09 meeting proposal: adopt Y29-01 > > * OPEN :Y30: allow leafref in union > > 2014-07-21 meeting proposal: adopt Y30-01, clarify existence > constraints and impact on union member selection, see 2014-07-09 > meeting minutes. Followup on Lada's issue concerning unions as keys. > > * OPEN :Y31: allow require-instance in leafref > > 2014-07-21 meeting proposal: adopt Y31-01. > > * OPEN :Y34: remove/deprecate/replace the 'anyxml' statement > > 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > a concrete proposal. > > * OPEN :Y35: allow empty in union > > 2014-07-21 meeting proposal: adopt Y35-01. > > * OPEN :Y41: clarification of "must" in NP-container > > 2014-07-21 meeting proposal: Clarify that for validation purposes, > NP containers always exist. > > * OPEN :Y42: a better model for configuration versus state data is needed > > postponed to the face-to-face interim meeting > > * OPEN :Y44: add a mechanism to parameterize error-message > > 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. > > * OPEN :Y45: better conformance mechanism > > postponed to the face-to-face interim meeting > > * OPEN :Y47: bit name too restrictive > > 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. > > * OPEN :Y49: clarify nested submodule behavior > > 2014-08-27 meeting action: MB to writeup solution proposal Y49-03. > > * OPEN :Y54: remove the advertisement of conformance information in NETCONF hello > > postponed to the face-to-face interim meeting > > * NEW :Y55: clarify type in union > > 2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01. > > /js > From nobody Thu Sep 4 00:55:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41CB31A6F3A for ; Thu, 4 Sep 2014 00:55:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 QZDw9Pm2A8ek for ; Thu, 4 Sep 2014 00:55:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D2BBC1A6F30 for ; Thu, 4 Sep 2014 00:55:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9EA1B1302 for ; Thu, 4 Sep 2014 09:55:37 +0200 (CEST) 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 3n5BK37JiitW for ; Thu, 4 Sep 2014 09:55:21 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 4 Sep 2014 09:55:37 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 03C0820035 for ; Thu, 4 Sep 2014 09:55:37 +0200 (CEST) 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 uiczg6J-JJVw; Thu, 4 Sep 2014 09:55:36 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10CE820033; Thu, 4 Sep 2014 09:55:35 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id F25372E59B72; Thu, 4 Sep 2014 09:55:34 +0200 (CEST) Date: Thu, 4 Sep 2014 09:55:34 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140904075534.GA82785@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ioijWlbdQRnTu-7xXzL_bcM_Ly8 Subject: [netmod] face-to-face interim meeting attendee list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 07:55:40 -0000 Hi, I am compiling the list of face-to-face interim meeting attendees. This is what I have right now (essentially taken from the Doodle poll). Please send me your updates. For access to the building, I need an accurate attendee list. - Juergen Schoenwaelder - Lada Lhotka - Andy Bierman - Martin Bjoerklund - Mahesh Jethanandani - Benoti Claise - Balazs Lengyel - Kent Watsen - Dan Romascanu (remote) - Peter Van Horne - Dean Bogdanovic - Susan Hares - Jeffrey Haas /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 4 01:02:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 738031A6F6F for ; Thu, 4 Sep 2014 01:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 3JzdsKLA4Pgc for ; Thu, 4 Sep 2014 01:02:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09D81A6F81 for ; Thu, 4 Sep 2014 01:02:30 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id ABA932067; Thu, 4 Sep 2014 10:02:29 +0200 (CEST) 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 pVsfBI3V7XCQ; Thu, 4 Sep 2014 10:02:12 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Sep 2014 10:02:28 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0DB7B20036; Thu, 4 Sep 2014 10:02:28 +0200 (CEST) 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 vtiYicoqPNr0; Thu, 4 Sep 2014 10:02:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6F43C20033; Thu, 4 Sep 2014 10:02:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 4C13E2E59BA9; Thu, 4 Sep 2014 10:02:25 +0200 (CEST) Date: Thu, 4 Sep 2014 10:02:25 +0200 From: Juergen Schoenwaelder To: Benoit Claise Message-ID: <20140904080225.GB82785@elstar.local> Mail-Followup-To: Benoit Claise , netmod@ietf.org References: <20140903111127.GA79883@elstar.local> <540819BB.6030906@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <540819BB.6030906@cisco.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/w_bOhxLc893H9NOVzdZG41OlXF4 Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 08:02:35 -0000 Benoit, I believe sufficient details are recorded in the minutes. Please take a look at the minutes and let me know if I am wrong. I am already spending _significant_ amount of time on issue tracking, taking notes, editing of minutes, seeking confirmation for every step on the mailing list, handling the other process requirements (meeting allocations, minute submission to the secretariat, etc) and I am reaching a limit. If even more documentation is required, I can't do it anymore alone. /js On Thu, Sep 04, 2014 at 09:50:19AM +0200, Benoit Claise wrote: > Jürgen, WG, > > I like the way the interim meetings are run. This brings speed to the > process. Thanks. > > However, let me repeat a statement I made a few times. > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (or > whatever support), must also document the rational for selecting a > specific solution. > Something like: > solution 1 was rejected because of reason 1, 2, and 3 > the issue could be addressed with both solutions 1 and 2 > current implementations don't use the feature this way > solution 2 is easier from an implementation point of view because ... > in conclusion, solution 2 is plebiscited by the WG > > What's the reasoning ? > We don't want to redo the discussions over and over. > Following RFC 7282, how can we say to a new participant in the WG: "We > hear you. This argument was discussed, and the consensus was ... Do you > have another argument in favor of a different solution? Basically, have > we overlooked anything?" > Without some documentation, this is not possible. > > Regards, Benoit > > > >Hi, > > > >we managed to go over all issues except those issues that we will be > >disussing during the face-to-face interim meeting. This email provides > >a summary of where we are with the issues not marked DEAD. I am also > >including actions that need to be carried out. > > > >If you disagree with any of the following proposed resolutions, please > >speak up as soon as possible but no later than September 16 (so that > >we have the input before the face-to-face interim meeting starts). If > >you want to raise a concern, please start a threat with the issue > >identifier in the subject line. > > > >* OPEN :Y01: allow boolean if-feature > > > > 2014-06-11 meeting proposal: adopt Y01-01. > > > >* OPEN :Y02: allow must in input, output, and notification > > > > 2014-06-11 meeting proposal: adopt Y02-01. > > > >* OPEN :Y03: allow if-feature in refine > > > > 2014-06-11 meeting proposal: adopt Y03-01. > > > >* OPEN :Y04: accessible tree in xpath in notifs and rpc > > > > 2014-06-11 meeting proposal: adopt Y04-02. > > > >* OPEN :Y05: unprefixed path in top-level typedef > > > > 2014-06-11 meeting action: MB to write down solution Y05-03 and once > > done we get back to this issue. > > > >* OPEN :Y06: escaped characters in double quoted strings > > > > 2014-06-11 meeting proposal: adopt Y06-02. > > > >* OPEN :Y07: do not allow when or if-feature on keys > > > > 2014-07-02 meeting proposal: adopt Y07-01 with a clarification about > > the condition > > > >* OPEN :Y09: introduce optional keys <> > > > > 2014-07-02 meeting action: MB to write up a solution proposal and > > once done we get back to this issue. > > > >* OPEN :Y10: allow restrictions on enumerations > > > > 2014-07-02 meeting action: LL to write down another syntax proposal > > and MB to expand Y10-01. > > > >* OPEN :Y11: allow if-feature on enums > > > > 2014-07-02 meeting proposal: Adopt Y11-01 with the extension to > > allow if-feature also for bits and identities. > > > >* OPEN :Y12: initialized-by system > > > > 2014-07-02 meeting proposal: Adopt Y12-01 but think about a better > > syntax. Applies to leaf and leaf-lists. MB to create concrete text. > > > >* OPEN :Y13: allow multiple inheritance for identities > > > > 2014-07-02 meeting action: LL to write a more complete example and > > once done we get back to this issue. > > > >* OPEN :Y14: clarify the string value for identities when used in must/when > > > > 2014-07-02 meeting proposal: adopt Y14-01. > > > >* OPEN :Y16: module advertisement optimization > > > > 2014-07-02 meeting action: MB to look at the details whether Y16-02 > > can be made to work. > > > >* OPEN :Y18: fix "when" expression context node problem > > > > 2014-07-02 meeting action: LL to write up an example in which > > situations Y18-01 is problematic. > > > >* OPEN :Y20: new set of built-in XPath functions > > > > 2014-07-09 meeting proposal: MB to copy the functions he proposed to > > RFC 6020bis as a starting point and then we review and discuss > > changes. > > > >* OPEN :Y23: support negative patterns as string restrictions > > > > 2014-07-09 meeting proposal: adopt Y23-02. > > > >* OPEN :Y25: make enum numbering purely informative and optional > > > > 2014-07-09 meeting proposal: adopt Y25-01. > > > >* OPEN :Y26: allow mandatory nodes in augment > > > > 2014-07-09 meeting action: There is agreement that the current text > > is overly restrictive. The proposal is to add general guiding rules > > that backwards compatibility needs to be maintained. Lets see > > whether someone can write more concrete rules when mandatory nodes > > in augment are allowed. > > > >* OPEN :Y27: allow mandatory nodes in an updated module > > > > 2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to > > check what the feature issue is about, possible action to add > > guidelines how to go from current to deprecated to obsolete in RFC > > 6087bis. > > > >* OPEN :Y28: support default values in leaf-lists > > > > 2014-07-09 meeting action: AB will look at the necessary text and > > what it means to modify leaf-list values. Perhaps there is a need to > > have a different keyword since the behavior is rather different > > here. > > > >* OPEN :Y29: allow choice as a short-hand case > > > > 2014-07-09 meeting proposal: adopt Y29-01 > > > >* OPEN :Y30: allow leafref in union > > > > 2014-07-21 meeting proposal: adopt Y30-01, clarify existence > > constraints and impact on union member selection, see 2014-07-09 > > meeting minutes. Followup on Lada's issue concerning unions as keys. > > > >* OPEN :Y31: allow require-instance in leafref > > > > 2014-07-21 meeting proposal: adopt Y31-01. > > > >* OPEN :Y34: remove/deprecate/replace the 'anyxml' statement > > > > 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out > > a concrete proposal. > > > >* OPEN :Y35: allow empty in union > > > > 2014-07-21 meeting proposal: adopt Y35-01. > > > >* OPEN :Y41: clarification of "must" in NP-container > > > > 2014-07-21 meeting proposal: Clarify that for validation purposes, > > NP containers always exist. > > > >* OPEN :Y42: a better model for configuration versus state data is needed > > > > postponed to the face-to-face interim meeting > > > >* OPEN :Y44: add a mechanism to parameterize error-message > > > > 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. > > > >* OPEN :Y45: better conformance mechanism > > > > postponed to the face-to-face interim meeting > > > >* OPEN :Y47: bit name too restrictive > > > > 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. > > > >* OPEN :Y49: clarify nested submodule behavior > > > > 2014-08-27 meeting action: MB to writeup solution proposal Y49-03. > > > >* OPEN :Y54: remove the advertisement of conformance information in > >NETCONF hello > > > > postponed to the face-to-face interim meeting > > > >* NEW :Y55: clarify type in union > > > > 2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01. > > > >/js > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 4 01:27:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1A321A6F8C for ; Thu, 4 Sep 2014 01:27:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.3 X-Spam-Level: X-Spam-Status: No, score=-3.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_LETTER=-2, J_CHICKENPOX_34=0.6] 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 36z69-IwjiFm for ; Thu, 4 Sep 2014 01:26:58 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 06EC41A0089 for ; Thu, 4 Sep 2014 01:26:57 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2EBB1540466; Thu, 4 Sep 2014 10:26:56 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qa78FcI0HNi0; Thu, 4 Sep 2014 10:26:52 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 09217540081; Thu, 4 Sep 2014 10:26:50 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman , Martin Bjorklund In-Reply-To: References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 04 Sep 2014 10:26:49 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/84DeUr8DEJR5NdLaswr3jo1OaPw Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 08:27:00 -0000 Hi, I think there are actually two different cases: 1. Container for data that eventually have to conform to a YANG data model, but this data model is not known in advance. 2. Location in the schema tree where another (known) schema is to be grafted. I understand your root extension is #1, and this is probably what's needed when defining RPCs that may contain data snippets conforming to any data model. #2 is analogical to externalRef in RELAX NG. The use case I had was a module describing network topology - nodes, links etc. I wanted to be able to include with each node also its configuration described by our standard modules. Currently the only option is to have the node configurations in separate files and refer to them from the topology. I think #2 is also closer to what Kent's configlets need. Lada Andy Bierman writes: > On Wed, Sep 3, 2014 at 5:59 AM, Martin Bjorklund wrote: > >> Juergen Schoenwaelder wrote: >> > On Wed, Sep 03, 2014 at 02:26:51PM +0200, Martin Bjorklund wrote: >> > > Juergen Schoenwaelder wrote: >> > > > On Wed, Sep 03, 2014 at 04:35:55AM -0700, Andy Bierman wrote: >> > > > >> > > > > 2) No NETCONF implementation supports mixed mode XML. >> > > > > There is only 1 mention of mixed mode XML in RFC 6241 in 6.2.5 >> > > > > >> > > > > o Filtering of mixed content is not supported. >> > > > > >> > > > > >> > > > > The intent was to disallow mixed mode in all operations, not >> > > > > just subtree filtering. >> > > > > >> > > > > 3) IMO the IETF spends too much time on broken text, worrying about >> > > > > the letter of the law when there is little to no operational value >> to >> > > > > be gained. Most implementors have never even tried to send mixed >> mode >> > > > > XML to their server, and don't even know what will happen. >> Obviously >> > > > > if customers were using this, the implementors would know exactly >> > > > > whether this worked or not. >> > > > >> > > > If we conclude that anyxml already today is what anydata is supposed >> > > > to be >> > > >> > > If we do that, what does that mean for NETCONF? RFC 6241 uses >> > > 'anyxml' to describe content etc. If we make this >> > > change, it seems to indicate that NETCONF cannot relly be used with >> > > any other modelling languages than YANG. Maybe this is ok. >> > > >> > >> > Either Andy is correct that this is what all implementations do, >> > namely restrict content to things that can be defined in YANG (note >> > that my wording is different from your wording) >> >> Right; I started to write that, but then I was thinking that we have >> to define 'anyxml' as data modelled with YANG, since otherwise the >> JSON mapping won't work. >> >> > > Here is the extension Yuma has been using since 2008 to deal with the > most common use-case: > > extension root { > description > "Used within a container definition to indicate it is > really a root container for a conceptual NETCONF database, > instead of just an empty container. This is needed > for yuma to correctly process any RPC method > that contains a 'config' parameter."; > > > > It is used in several protocol operations like /edit-config/input/config or > /get-config/output/data. > > container data { > ncx:root; > } > > A plain parser will not know that "ncx:root" means the child nodes are > expected to be to-level YANG data nodes., so it should have probably > been designed to use anyxml: > > anyxml data { > ncx:root; > } > > I would like to add a new solution proposal for Y34: > > Solution Y34-04: > > * Consider a new statement called "root" that provides the ncx:root > semantics. > There may be restrictions on its use (i.e., may not be full > data-def-stmt) > > root config { > description "Container of top-level YANG data nodes representing the > configuration"; > } > > * For YANG 1.0 backward compatibility, allow anyxml to be used, > except implementations MAY restrict the XML so it is not considered > interoperable. > > * YANG Doctors will review each use of anyxml when YANG 1.1 is adopted, > and avoid its use if possible (e.g., root should be used instead) > (Does that mean anyxml SHOULD NOT be used -- deprecated?) > > * Do not add a replacement statement for anyxml (anydata) to YANG 1.1 > > > Andy > > > > > >> >> /martin >> >> >> >> >> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 4 02:36:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B00221A0117 for ; Thu, 4 Sep 2014 02:36:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.897 X-Spam-Level: X-Spam-Status: No, score=0.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.793] 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 ZLajYS8oseqr for ; Thu, 4 Sep 2014 02:36:44 -0700 (PDT) Received: from rock.dronejett.com (unknown [192.157.32.20]) by ietfa.amsl.com (Postfix) with ESMTP id EFE3F1A00BB for ; Thu, 4 Sep 2014 02:36:43 -0700 (PDT) Received: from [172.16.10.138] (pool-108-18-144-195.washdc.fios.verizon.net [108.18.144.195]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by rock.dronejett.com (Postfix) with ESMTPSA id 8C212E04; Thu, 4 Sep 2014 05:36:33 -0400 (EDT) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: David Bannister In-Reply-To: <20140904080225.GB82785@elstar.local> Date: Thu, 4 Sep 2014 05:36:32 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <6365A318-3D69-4808-8195-0909252F09EA@mojo.net> References: <20140903111127.GA79883@elstar.local> <540819BB.6030906@cisco.com> <20140904080225.GB82785@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4Wb5N49-itFdog8A-6q4Bvhdb28 Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 09:36:45 -0000 Juergen, I may be able to help if you would like to discuss off list. On Sep 4, 2014, at 4:02 AM, Juergen Schoenwaelder = wrote: > Benoit, >=20 > I believe sufficient details are recorded in the minutes. Please take > a look at the minutes and let me know if I am wrong. >=20 > I am already spending _significant_ amount of time on issue tracking, > taking notes, editing of minutes, seeking confirmation for every step > on the mailing list, handling the other process requirements (meeting > allocations, minute submission to the secretariat, etc) and I am > reaching a limit. If even more documentation is required, I can't do > it anymore alone. >=20 > /js >=20 > On Thu, Sep 04, 2014 at 09:50:19AM +0200, Benoit Claise wrote: >> J=FCrgen, WG, >>=20 >> I like the way the interim meetings are run. This brings speed to the=20= >> process. Thanks. >>=20 >> However, let me repeat a statement I made a few times. >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (or=20 >> whatever support), must also document the rational for selecting a=20 >> specific solution. >> Something like: >> solution 1 was rejected because of reason 1, 2, and 3 >> the issue could be addressed with both solutions 1 and 2 >> current implementations don't use the feature this way >> solution 2 is easier from an implementation point of view because = ... >> in conclusion, solution 2 is plebiscited by the WG >>=20 >> What's the reasoning ? >> We don't want to redo the discussions over and over. >> Following RFC 7282, how can we say to a new participant in the WG: = "We=20 >> hear you. This argument was discussed, and the consensus was ... Do = you=20 >> have another argument in favor of a different solution? Basically, = have=20 >> we overlooked anything?" >> Without some documentation, this is not possible. >>=20 >> Regards, Benoit >>=20 >>=20 >>> Hi, >>>=20 >>> we managed to go over all issues except those issues that we will be >>> disussing during the face-to-face interim meeting. This email = provides >>> a summary of where we are with the issues not marked DEAD. I am = also >>> including actions that need to be carried out. >>>=20 >>> If you disagree with any of the following proposed resolutions, = please >>> speak up as soon as possible but no later than September 16 (so that >>> we have the input before the face-to-face interim meeting starts). = If >>> you want to raise a concern, please start a threat with the issue >>> identifier in the subject line. >>>=20 >>> * OPEN :Y01: allow boolean if-feature >>>=20 >>> 2014-06-11 meeting proposal: adopt Y01-01. >>>=20 >>> * OPEN :Y02: allow must in input, output, and notification >>>=20 >>> 2014-06-11 meeting proposal: adopt Y02-01. >>>=20 >>> * OPEN :Y03: allow if-feature in refine >>>=20 >>> 2014-06-11 meeting proposal: adopt Y03-01. >>>=20 >>> * OPEN :Y04: accessible tree in xpath in notifs and rpc >>>=20 >>> 2014-06-11 meeting proposal: adopt Y04-02. >>>=20 >>> * OPEN :Y05: unprefixed path in top-level typedef >>>=20 >>> 2014-06-11 meeting action: MB to write down solution Y05-03 and = once >>> done we get back to this issue. >>>=20 >>> * OPEN :Y06: escaped characters in double quoted strings >>>=20 >>> 2014-06-11 meeting proposal: adopt Y06-02. >>>=20 >>> * OPEN :Y07: do not allow when or if-feature on keys >>>=20 >>> 2014-07-02 meeting proposal: adopt Y07-01 with a clarification = about >>> the condition >>>=20 >>> * OPEN :Y09: introduce optional keys <> >>>=20 >>> 2014-07-02 meeting action: MB to write up a solution proposal = and >>> once done we get back to this issue. >>>=20 >>> * OPEN :Y10: allow restrictions on enumerations >>>=20 >>> 2014-07-02 meeting action: LL to write down another syntax proposal >>> and MB to expand Y10-01. >>>=20 >>> * OPEN :Y11: allow if-feature on enums >>>=20 >>> 2014-07-02 meeting proposal: Adopt Y11-01 with the extension to >>> allow if-feature also for bits and identities. >>>=20 >>> * OPEN :Y12: initialized-by system >>>=20 >>> 2014-07-02 meeting proposal: Adopt Y12-01 but think about a better >>> syntax. Applies to leaf and leaf-lists. MB to create concrete text. >>>=20 >>> * OPEN :Y13: allow multiple inheritance for identities >>>=20 >>> 2014-07-02 meeting action: LL to write a more complete example and >>> once done we get back to this issue. >>>=20 >>> * OPEN :Y14: clarify the string value for identities when used in = must/when >>>=20 >>> 2014-07-02 meeting proposal: adopt Y14-01. >>>=20 >>> * OPEN :Y16: module advertisement optimization >>>=20 >>> 2014-07-02 meeting action: MB to look at the details whether Y16-02 >>> can be made to work. >>>=20 >>> * OPEN :Y18: fix "when" expression context node problem >>>=20 >>> 2014-07-02 meeting action: LL to write up an example in which >>> situations Y18-01 is problematic. >>>=20 >>> * OPEN :Y20: new set of built-in XPath functions >>>=20 >>> 2014-07-09 meeting proposal: MB to copy the functions he proposed = to >>> RFC 6020bis as a starting point and then we review and discuss >>> changes. >>>=20 >>> * OPEN :Y23: support negative patterns as string restrictions >>>=20 >>> 2014-07-09 meeting proposal: adopt Y23-02. >>>=20 >>> * OPEN :Y25: make enum numbering purely informative and optional >>>=20 >>> 2014-07-09 meeting proposal: adopt Y25-01. >>>=20 >>> * OPEN :Y26: allow mandatory nodes in augment >>>=20 >>> 2014-07-09 meeting action: There is agreement that the current text >>> is overly restrictive. The proposal is to add general guiding rules >>> that backwards compatibility needs to be maintained. Lets see >>> whether someone can write more concrete rules when mandatory nodes >>> in augment are allowed. >>>=20 >>> * OPEN :Y27: allow mandatory nodes in an updated module >>>=20 >>> 2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to >>> check what the feature issue is about, possible action to add >>> guidelines how to go from current to deprecated to obsolete in RFC >>> 6087bis. >>>=20 >>> * OPEN :Y28: support default values in leaf-lists >>>=20 >>> 2014-07-09 meeting action: AB will look at the necessary text and >>> what it means to modify leaf-list values. Perhaps there is a need = to >>> have a different keyword since the behavior is rather different >>> here. >>>=20 >>> * OPEN :Y29: allow choice as a short-hand case >>>=20 >>> 2014-07-09 meeting proposal: adopt Y29-01 >>>=20 >>> * OPEN :Y30: allow leafref in union >>>=20 >>> 2014-07-21 meeting proposal: adopt Y30-01, clarify existence >>> constraints and impact on union member selection, see 2014-07-09 >>> meeting minutes. Followup on Lada's issue concerning unions as = keys. >>>=20 >>> * OPEN :Y31: allow require-instance in leafref >>>=20 >>> 2014-07-21 meeting proposal: adopt Y31-01. >>>=20 >>> * OPEN :Y34: remove/deprecate/replace the 'anyxml' statement >>>=20 >>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work = out >>> a concrete proposal. >>>=20 >>> * OPEN :Y35: allow empty in union >>>=20 >>> 2014-07-21 meeting proposal: adopt Y35-01. >>>=20 >>> * OPEN :Y41: clarification of "must" in NP-container >>>=20 >>> 2014-07-21 meeting proposal: Clarify that for validation purposes, >>> NP containers always exist. >>>=20 >>> * OPEN :Y42: a better model for configuration versus state data is = needed >>>=20 >>> postponed to the face-to-face interim meeting >>>=20 >>> * OPEN :Y44: add a mechanism to parameterize error-message >>>=20 >>> 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. >>>=20 >>> * OPEN :Y45: better conformance mechanism >>>=20 >>> postponed to the face-to-face interim meeting >>>=20 >>> * OPEN :Y47: bit name too restrictive >>>=20 >>> 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. >>>=20 >>> * OPEN :Y49: clarify nested submodule behavior >>>=20 >>> 2014-08-27 meeting action: MB to writeup solution proposal Y49-03. >>>=20 >>> * OPEN :Y54: remove the advertisement of conformance information in=20= >>> NETCONF hello >>>=20 >>> postponed to the face-to-face interim meeting >>>=20 >>> * NEW :Y55: clarify type in union >>>=20 >>> 2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01. >>>=20 >>> /js >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Thu Sep 4 07:17:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 587B31A88EC for ; Thu, 4 Sep 2014 07:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.13 X-Spam-Level: X-Spam-Status: No, score=0.13 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 TSlbuupt7ky6 for ; Thu, 4 Sep 2014 07:17:17 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id C76F31A88CB for ; Thu, 4 Sep 2014 07:17:06 -0700 (PDT) Received: from rhopteron.snmp.com (IDENT:U2FsdGVkX19nna+SOZ62sHvvNyT0Ws8cs0bNE7kD3K8@rhopteron.snmp.com [192.147.142.25]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id KAA01501 for ; Thu, 4 Sep 2014 10:17:05 -0400 (EDT) Received: from rhopteron.snmp.com (IDENT:U2FsdGVkX18YuP0+E+n19aSs7z+4mj6bvCS+EQ1X4+c@rhopteron.snmp.com [127.0.0.1] (may be forged)) by rhopteron.snmp.com (8.13.1/8.13.1) with ESMTP id s84EH59T009628 for ; Thu, 4 Sep 2014 10:17:05 -0400 Message-Id: <201409041417.s84EH59T009628@rhopteron.snmp.com> To: netmod@ietf.org From: David Reid In-reply-to: Your message of Thu, 07 Aug 2014 20:07:57 +0200. <20140807.200757.441533667.mbj@tail-f.com> Date: Thu, 04 Sep 2014 10:17:05 -0400 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SQXs50ncVv5mXnzANgXG7mlpN28 Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 14:17:19 -0000 > Here is a proposal for how to introduce optional keys. Adding optional keys seems like a pretty major new feature for a .1 release. Most of the other issues are fixes or clarifications. Is the benefit worth the cost? -David Reid From nobody Thu Sep 4 08:22:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E665F1A88D0; Thu, 4 Sep 2014 08:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.636 X-Spam-Level: X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_14=0.6, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 o4V7GfgMtLtD; Thu, 4 Sep 2014 08:22:19 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id E03B21A87B8; Thu, 4 Sep 2014 08:22:19 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AE4D8C2A8; Thu, 4 Sep 2014 11:22:19 -0400 (EDT) Date: Thu, 4 Sep 2014 11:22:19 -0400 From: Jeffrey Haas To: Benoit Claise Message-ID: <20140904152219.GO7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <54049D7F.1010307@cisco.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1cOpvLl6OTPVN0T0oZwf8LkjJnE Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:22:21 -0000 Benoit and Juergen, My apologies for delay in responding to this mail. I've had a few unexpected items that have distracted me from IETF work the last several days. I will be chatting with Dean B. who had volunteered to help draft this document today. While we have previously discussed a number of items in terms of requirements and gaps, the request was that we provide a formal list of the requirements against netmod and netconf. I hope to have the result of that discussion this afternoon. -- Jeff On Mon, Sep 01, 2014 at 06:23:27PM +0200, Benoit Claise wrote: > Joel, > > On top of what J?rgen wrote, we stressed the need for such a > requirement document to both I2RS chairs during the last IETF > meeting. > The good news is that some of the requirements were mentioned on the > microphone during the Sunday YANG editing session and/or the NETMOD > meeting (my memory fails me). > > Regards, Benoit > > >On Sun, Aug 31, 2014 at 09:58:57PM -0400, Joel M. Halpern wrote: > >>Juergen, > >> While I understand the request, I presume that such a request can > >>not be met as a working group agreement in the time frame suggested. > >>WHile I hope that some of the folks who have been involved in proposing > >>the use of YANG for I2RS will write such a draft, I can not see how we > >>could even get tot eh point of WG adoption of such a draft, much less WG > >>rough consensus on the content, in the time frame you outline. > >> Of course, I am not one of the chairs or ADs, but it seems pretty > >>clear cut to me. > >Joel, > > > >all I need is reasonably agreed upon input. Note that this request for > >input is not coming out of the blue, at least not for those I2RS folks > >who have been at the NETMOD meeting in Toronto. > > > >As NETMOD chair, I do have a target date to deliver YANG 1.1 and I > >take that milestone serious. My motivation to delay this by N months > >waiting for I2RS to get their input submitted is very small. I recall > >that there were presentations about "what is missing" bach in London, > >that is March 2014. The regular submission period for YANG 1.1 issues > >was 2014-02-23 until 2014-05-07. The interim meeting is mid September. > > > >/js > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 4 08:26:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 306461A88F1; Thu, 4 Sep 2014 08:26:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.236 X-Spam-Level: X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.668, SPF_HELO_PASS=-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 ra1MlYCXizPI; Thu, 4 Sep 2014 08:26:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 353BD1A0364; Thu, 4 Sep 2014 08:26:18 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id ECE3CC2A8; Thu, 4 Sep 2014 11:26:17 -0400 (EDT) Date: Thu, 4 Sep 2014 11:26:17 -0400 From: Jeffrey Haas To: Andy Bierman Message-ID: <20140904152617.GP7736@pfrc> References: <20140829064207.GA63316@elstar.local> <5403D2E1.6090502@joelhalpern.com> <20140901050331.GA70583@elstar.local> <54049D7F.1010307@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qKYhbgz6RKx0Pj6O5BZuwObjfvY Cc: "i2rs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 15:26:21 -0000 On Mon, Sep 01, 2014 at 10:17:14AM -0700, Andy Bierman wrote: > I agree with Joel that the I2RS does not have consensus on the details. I think we continue to have consensus but not in enough detail to declare victory. Below, you identify much of what we've previously discussed: > The slides I presented in London and subsequent discussions suggest this > solution: > > 1) define YANG extension to identify I2RS data so typedefs, etc. can be > shared > in config and state data models And how this was to be different than ephemeral data, if at all. > 2) define an I2RS datastore I suspect we have consensus on this. > 3) define or extend a protocol to manage the I2RS datastore > > Let's say there is a new datastore added to the RESTCONF architecture for > I2RS. > Explain how this datastore works. It seems to have the same validation > rules > as YANG running config rules. The only difference seems to be that the > I2RS datastore > is not NV-saved (or NV-loaded at boot-time) like the running datastore. Exactly. > YANG 1.1 has some cleanup work planned to make the text less > NETCONF-specific. > I don't think there is much datastore and NV-store specific text that would > need to change. Mostly the ability to tag things emphemeral. More on that in a later message. -- Jeff From nobody Thu Sep 4 12:22:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 882F51A02F7 for ; Thu, 4 Sep 2014 12:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.67 X-Spam-Level: X-Spam-Status: No, score=-0.67 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RP_MATCHES_RCVD=-0.668, 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 SEJdUKzQYERI for ; Thu, 4 Sep 2014 12:21:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id F25851A02BB for ; Thu, 4 Sep 2014 12:21:58 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 0AB061280972; Thu, 4 Sep 2014 21:21:53 +0200 (CEST) Date: Thu, 04 Sep 2014 21:21:52 +0200 (CEST) Message-Id: <20140904.212152.222792193.mbj@tail-f.com> To: reid@snmp.com From: Martin Bjorklund In-Reply-To: <201409041417.s84EH59T009628@rhopteron.snmp.com> References: <20140807.200757.441533667.mbj@tail-f.com> <201409041417.s84EH59T009628@rhopteron.snmp.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/Y6ibVxJADDYYy3E7AWntl4GYqxg Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 19:22:00 -0000 David Reid wrote: > > Here is a proposal for how to introduce optional keys. > > Adding optional keys seems like a pretty major new feature for > a .1 release. Most of the other issues are fixes or clarifications. > Is the benefit worth the cost? I don't think the cost is that high. With YANG 1.0, people are forced to use awkward workarounds, and/or vendor-specific extensions to support a use case that seems to be natural in many circumstances. Thus, I think it is better to support this natively. (Incidentally, just today I got a question from someone involved in the broadband forum work why YANG doesn't support optional keys). /martin From nobody Thu Sep 4 13:38:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EA571A00F0 for ; Thu, 4 Sep 2014 13:38:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 mE3oTXl1INYC for ; Thu, 4 Sep 2014 13:38:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 878E61A0086 for ; Thu, 4 Sep 2014 13:38:23 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E528322B2; Thu, 4 Sep 2014 22:38:21 +0200 (CEST) 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 94VoRsvijCq0; Thu, 4 Sep 2014 22:38:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 4 Sep 2014 22:38:21 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4874C20035; Thu, 4 Sep 2014 22:38:21 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vRZoh9WMJCK9; Thu, 4 Sep 2014 22:38:20 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4618920033; Thu, 4 Sep 2014 22:38:19 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 765292E5A862; Thu, 4 Sep 2014 22:38:18 +0200 (CEST) Date: Thu, 4 Sep 2014 22:38:18 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140904203818.GD84465@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <20140807.200757.441533667.mbj@tail-f.com> <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140904.212152.222792193.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Pte_k1VyL8sfF4SmiA0vai6mDxs Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 20:38:25 -0000 On Thu, Sep 04, 2014 at 09:21:52PM +0200, Martin Bjorklund wrote: > David Reid wrote: > > > Here is a proposal for how to introduce optional keys. > > > > Adding optional keys seems like a pretty major new feature for > > a .1 release. Most of the other issues are fixes or clarifications. > > Is the benefit worth the cost? > > I don't think the cost is that high. With YANG 1.0, people are forced > to use awkward workarounds, and/or vendor-specific extensions to > support a use case that seems to be natural in many circumstances. > Thus, I think it is better to support this natively. (Incidentally, > just today I got a question from someone involved in the broadband > forum work why YANG doesn't support optional keys). Martin, can you detail how will instance-identifier look like that deal with optional keys? I assume this is the biggest change Y09 would cause, no? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 4 13:40:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395591A0086 for ; Thu, 4 Sep 2014 13:40:53 -0700 (PDT) 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 yBohRWFkI3IY for ; Thu, 4 Sep 2014 13:40:51 -0700 (PDT) Received: from mail-qg0-f51.google.com (mail-qg0-f51.google.com [209.85.192.51]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A27B51A0080 for ; Thu, 4 Sep 2014 13:40:51 -0700 (PDT) Received: by mail-qg0-f51.google.com with SMTP id i50so10838986qgf.10 for ; Thu, 04 Sep 2014 13:40:50 -0700 (PDT) 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=P9GZZqH7nb3PhnQ8TnDiZRG0KnGjRf0E2kahMqUaf1k=; b=PbSXb5l0JeADJS8yD0fh0tf3qnAMdiUfC4NNgmdekU4fPloTTbN8Gjq5OTmSD3Va7b GnyN+ZC01UoMAZo/SJy09zqTf2MJyQUoh1A2dDvHfeQHTl1LTVp4yJkn4fph32DaD4qh c3QydSwlnBrAOFsOvuRAP8e3Abs7E7AR6SVmYNLf5k/aVfrXhBZiFYbkYabZYuvbmD4R kHI718RnCzBweLOqjJuhICx7R1OrB+G1MZ7D3SQDRVGg7otpyQGfCl6H6nCCSbOh36SJ m5nbJZiTx6nutes6GVGIKmDtsPWEyCdNtedKOjv++JINpFi2GRdX79AGMw85umKBDQjE 9JOg== X-Gm-Message-State: ALoCoQkaPW2M8G+swf2hjXUbABM3rafn+jFHbHJClzh5LqcKuljgOHJ1dpVcRsbrpMfWxbUV7/Zp MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr10876924qah.99.1409863250538; Thu, 04 Sep 2014 13:40:50 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 4 Sep 2014 13:40:50 -0700 (PDT) In-Reply-To: <20140904.212152.222792193.mbj@tail-f.com> References: <20140807.200757.441533667.mbj@tail-f.com> <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.mbj@tail-f.com> Date: Thu, 4 Sep 2014 13:40:50 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c3d8d43b80280502435e70 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ic8XVzP2tdqE8Es1LdaPxvysToM Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Sep 2014 20:40:53 -0000 --001a11c3d8d43b80280502435e70 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund wrote: > David Reid wrote: > > > Here is a proposal for how to introduce optional keys. > > > > Adding optional keys seems like a pretty major new feature for > > a .1 release. Most of the other issues are fixes or clarifications. > > Is the benefit worth the cost? > > I don't think the cost is that high. With YANG 1.0, people are forced > to use awkward workarounds, and/or vendor-specific extensions to > support a use case that seems to be natural in many circumstances. > Thus, I think it is better to support this natively. (Incidentally, > just today I got a question from someone involved in the broadband > forum work why YANG doesn't support optional keys). > > I think the implementation impact is significant, but the feature could be useful. The protocol complexity increase is worse that the compiler. What about adding optional keys to an existing entry? IMO this cannot be supported with either RESTCONF or NETCONF. The request will be seen by the server as a create, merge, or replace on a new resource instance. Even if the protocols supported that, multiple clients adding/deleting key leafs to the same entry at once seems complicated to get right. IMO, a client has to delete an entry and add it back in order to change its instance-identifier value. > /martin > Andy --001a11c3d8d43b80280502435e70 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund <mbj@tail-f.com= > wrote:
David Reid <reid@snmp.com> wrote:
> > Here is a proposal for how to introduce optional keys.
>
> Adding optional keys seems like a pretty major new feature for
> a .1 release. Most of the other issues are fixes or clarifications. > Is the benefit worth the cost?

I don't think the cost is that high.=A0 With YANG 1.0, people are force= d
to use awkward workarounds, and/or vendor-specific extensions to
support a use case that seems to be natural in many circumstances.
Thus, I think it is better to support this natively.=A0 (Incidentally,
just today I got a question from someone involved in the broadband
forum work why YANG doesn't support optional keys).



I think the implementat= ion impact is significant, but the feature could be useful.
The p= rotocol complexity increase is worse that the compiler.
What abou= t adding optional keys to an existing entry?
IMO this cannot be supported with either RESTCONF or NETCONF.
The request will be seen by the server as a create, merge, or replace on<= /div>
a new resource instance.

Even if the pro= tocols supported that, multiple clients adding/deleting key leafs to
the same entry at once seems complicated to get right.
IMO, = a client has to delete an entry and add it back in order to change its
instance-identifier value.



/martin

Andy
=A0
<= /div>
--001a11c3d8d43b80280502435e70-- From nobody Fri Sep 5 00:16:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 702A91A0493 for ; Fri, 5 Sep 2014 00:16:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 V4dHj-m4Ctp0 for ; Fri, 5 Sep 2014 00:16:46 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5AB061A048F for ; Fri, 5 Sep 2014 00:16:46 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 1E38C128046B; Fri, 5 Sep 2014 09:16:45 +0200 (CEST) Date: Fri, 05 Sep 2014 09:16:45 +0200 (CEST) Message-Id: <20140905.091645.2102743941647507448.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140904203818.GD84465@elstar.local> References: <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.mbj@tail-f.com> <20140904203818.GD84465@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/HzW2eqBZcWzsjmbCN4FVxGON1tY Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 07:16:48 -0000 Juergen Schoenwaelder wrote: > On Thu, Sep 04, 2014 at 09:21:52PM +0200, Martin Bjorklund wrote: > > David Reid wrote: > > > > Here is a proposal for how to introduce optional keys. > > > > > > Adding optional keys seems like a pretty major new feature for > > > a .1 release. Most of the other issues are fixes or clarifications. > > > Is the benefit worth the cost? > > > > I don't think the cost is that high. With YANG 1.0, people are forced > > to use awkward workarounds, and/or vendor-specific extensions to > > support a use case that seems to be natural in many circumstances. > > Thus, I think it is better to support this natively. (Incidentally, > > just today I got a question from someone involved in the broadband > > forum work why YANG doesn't support optional keys). > > Martin, > > can you detail how will instance-identifier look like that deal with > optional keys? I assume this is the biggest change Y09 would cause, > no? We talked about two options, easiest to examplify with this data model: list foo { key "a b"; leaf a { type string; mandatory true; } leaf b { type string; mandatory false; } and these instances: 1 1 2 Option A: /foo[a=1] /foo[a=1][b=1] Option B: /foo[a=1][not b] /foo[a=1][b=1] Both these options are still valid XPath expressions. Option A has the advantage of having the same syntax as before, but the disadvantage that if the instance identifier is used in an XPath filter in e.g., NETCONF, the example of "/foo[a=1]" will return both instances in this example. Option B has the advantage that if used as an XPath filter, it will return the exact instance and nothing more, but has the drawback of not being syntactically the same as before. I don't think this will pose a problem to a server; if it implements YANG 1.1 with any data model that has optional keys, it will have to support this new syntax. For an old client it might pose a problem if it interprets the i-i:s it receives from a 1.1 server that has such instances. /martin From nobody Fri Sep 5 00:17:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45E171A046A for ; Fri, 5 Sep 2014 00:17:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, 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 5SLwbW975tPD for ; Fri, 5 Sep 2014 00:17:16 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B1D061A049F for ; Fri, 5 Sep 2014 00:17:01 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 9CDC4128046B; Fri, 5 Sep 2014 09:16:59 +0200 (CEST) Date: Fri, 05 Sep 2014 09:16:59 +0200 (CEST) Message-Id: <20140905.091659.1743452151034350545.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.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/netmod/MbmZA1QDQqWqE_EI7DeJUB28gQ0 Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 07:17:25 -0000 Andy Bierman wrote: > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund wrote: > > > David Reid wrote: > > > > Here is a proposal for how to introduce optional keys. > > > > > > Adding optional keys seems like a pretty major new feature for > > > a .1 release. Most of the other issues are fixes or clarifications. > > > Is the benefit worth the cost? > > > > I don't think the cost is that high. With YANG 1.0, people are forced > > to use awkward workarounds, and/or vendor-specific extensions to > > support a use case that seems to be natural in many circumstances. > > Thus, I think it is better to support this natively. (Incidentally, > > just today I got a question from someone involved in the broadband > > forum work why YANG doesn't support optional keys). > > > > > > I think the implementation impact is significant, but the feature could be > useful. > The protocol complexity increase is worse that the compiler. > What about adding optional keys to an existing entry? > IMO this cannot be supported with either RESTCONF or NETCONF. > The request will be seen by the server as a create, merge, or replace on > a new resource instance. Right, and I think this is ok. In general it would be nice with a 'rename' operation in the protocols, but that is a different issue. /martin From nobody Fri Sep 5 13:49:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D1C4E1A0273 for ; Fri, 5 Sep 2014 13:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.218 X-Spam-Level: X-Spam-Status: No, score=-2.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.668] 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 ZkoFZWE6kqbt for ; Fri, 5 Sep 2014 13:49:37 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C10E1A004B for ; Fri, 5 Sep 2014 13:49:37 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B9DF32261; Fri, 5 Sep 2014 22:49:35 +0200 (CEST) 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 k9sOMAIejAds; Fri, 5 Sep 2014 22:49:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 5 Sep 2014 22:49:34 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC37F20036; Fri, 5 Sep 2014 22:49:34 +0200 (CEST) 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 MIcgEEEKHF4a; Fri, 5 Sep 2014 22:49:33 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1051720035; Fri, 5 Sep 2014 22:49:32 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E5E752E5BC4A; Fri, 5 Sep 2014 22:49:31 +0200 (CEST) Date: Fri, 5 Sep 2014 22:49:31 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140905204931.GB88590@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.mbj@tail-f.com> <20140904203818.GD84465@elstar.local> <20140905.091645.2102743941647507448.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140905.091645.2102743941647507448.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/T8iDr1JOHvCJUmYlV2OhJkrRX5c Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 20:49:41 -0000 On Fri, Sep 05, 2014 at 09:16:45AM +0200, Martin Bjorklund wrote: [...] > Option A: > > /foo[a=1] > /foo[a=1][b=1] > > Option B: > > /foo[a=1][not b] > /foo[a=1][b=1] > > Both these options are still valid XPath expressions. [...] > I don't think this will pose a problem to a server; if it implements > YANG 1.1 with any data model that has optional keys, it will have to > support this new syntax. > The instance-identifier is a type that has been used by other modules. For example, ietf-netconf-monitoring has a leaf-list locked-node of type instance-identifier. So how do I know whether a certain server implements the old syntax of instance-identifier or the new one? The node-instance-identifier module introduces a type node-instance-identifier which is derived from xpath (so that is fine) but the description refers to YANG instance identifiers: A node-instance-identifier value is an unrestricted YANG instance-identifier expression. All the same rules as an instance-identifier apply except predicates for keys are optional. If a key predicate is missing, then the node-instance-identifier represents all possible server instances for that key. Well, this does not seem really harmful but still, can you tell whether a certain NACM implementation will accept syntax option B? So is this really something we should do in 1.1 or something to put on the candidate list of a future YANG 2.0 version? > For an old client it might pose a problem if it interprets the i-i:s it > receives from a 1.1 server that has such instances. I assume it is quite possible that there are clients that do parse instance-identifiers. /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 Fri Sep 5 14:08:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365391A005C for ; Fri, 5 Sep 2014 14:08:18 -0700 (PDT) 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 Uiob0JfiNd6L for ; Fri, 5 Sep 2014 14:08:15 -0700 (PDT) Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 140421A006D for ; Fri, 5 Sep 2014 14:08:13 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id z60so12697980qgd.11 for ; Fri, 05 Sep 2014 14:08:12 -0700 (PDT) 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=cZQREBcCJnUueyNxR2sl41q9tJEnR/GxKb4eo0tIwho=; b=ZZ7B6wBLiCml0XS4sF9ulhBVAoDoTC8EcEoySQmzz0geY9VGsF2HEfnMPyBhi/E/Sm srOafSHbrKtifazTIx+HiBiutuHMQE8o3OQAez5pKVFa6xjXGKReW+C6y4QtcI1Q1XHq qS46zWr/kMj6uqZy6mJGWbm5dSWZVKjpRR7rGNgGwC2e5ezwX3vS1GorT0+vEUGXHs2m WXqTKWj8SVggnxVnnB3ZynAhQSXo4H2xL8oLUUKst9+wttLKmMy/ST1WLhPz9s1ZU5zI lDYeXW4ik/cHiFhB1sxusK1OMUIowYNl2JjZqG4uEhgrGl86oxJLBLVkW2VoBycdkZmz szyQ== X-Gm-Message-State: ALoCoQmlXH2jPLgLvYJ8rHw5zrWbcpAjay4IGrbc1eOn5puKam9f60rBZK1GcTq0OK15yx6t24Y4 MIME-Version: 1.0 X-Received: by 10.140.40.179 with SMTP id x48mr5777530qgx.36.1409951292085; Fri, 05 Sep 2014 14:08:12 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Fri, 5 Sep 2014 14:08:11 -0700 (PDT) In-Reply-To: <20140905204931.GB88590@elstar.local> References: <201409041417.s84EH59T009628@rhopteron.snmp.com> <20140904.212152.222792193.mbj@tail-f.com> <20140904203818.GD84465@elstar.local> <20140905.091645.2102743941647507448.mbj@tail-f.com> <20140905204931.GB88590@elstar.local> Date: Fri, 5 Sep 2014 14:08:11 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Martin Bjorklund , David Reid , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c12da2eac8da050257dd7e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EnXpc-rGFVWZmAqW9zPLaqcyeR0 Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Sep 2014 21:08:18 -0000 --001a11c12da2eac8da050257dd7e Content-Type: text/plain; charset=ISO-8859-1 On Fri, Sep 5, 2014 at 1:49 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Fri, Sep 05, 2014 at 09:16:45AM +0200, Martin Bjorklund wrote: > > [...] > > > Option A: > > > > /foo[a=1] > > /foo[a=1][b=1] > > > > Option B: > > > > /foo[a=1][not b] > > /foo[a=1][b=1] > > > > Both these options are still valid XPath expressions. > > [...] > > > I don't think this will pose a problem to a server; if it implements > > YANG 1.1 with any data model that has optional keys, it will have to > > support this new syntax. > > > > The instance-identifier is a type that has been used by other > modules. For example, ietf-netconf-monitoring has a leaf-list > locked-node of type instance-identifier. So how do I know whether a > certain server implements the old syntax of instance-identifier or the > new one? The node-instance-identifier module introduces a type > node-instance-identifier which is derived from xpath (so that is fine) > but the description refers to YANG instance identifiers: > > A node-instance-identifier value is an > unrestricted YANG instance-identifier expression. > All the same rules as an instance-identifier apply > except predicates for keys are optional. If a key > predicate is missing, then the node-instance-identifier > represents all possible server instances for that key. > > Well, this does not seem really harmful but still, can you tell > whether a certain NACM implementation will accept syntax option B? > NACM implementations will reject (b) because it is not a valid schema-instance-identifier. But they will treat option (a) (missing key) as a match on all instances with that value. > So is this really something we should do in 1.1 or something to put on > the candidate list of a future YANG 2.0 version? > IMO it would be OK to defer this feature until YANG 2.0. There is a simple workaround, which is to define a value for the optional key that means "not used", This is usually possible. > > For an old client it might pose a problem if it interprets the i-i:s it > > receives from a 1.1 server that has such instances. > > It will not be accepted if the tool implements the RFC correctly. I think it will break old clients, which violates 1 of our main design goals. I assume it is quite possible that there are clients that do parse > instance-identifiers. > yes -- implemented according to the RFC. The value is checked to see that only the correct predicates are present. > > /js > Andy --001a11c12da2eac8da050257dd7e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Fri, Sep 5, 2014 at 1:49 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Sep 05, 2014 at 09:16:45AM +0200, Martin = Bjorklund wrote:

[...]

> Option A:
>
>=A0 =A0/foo[a=3D1]
>=A0 =A0/foo[a=3D1][b=3D1]
>
> Option B:
>
>=A0 =A0/foo[a=3D1][not b]
>=A0 =A0/foo[a=3D1][b=3D1]
>
> Both these options are still valid XPath expressions.

[...]

> I don't think this will pose a problem to a server; if it implemen= ts
> YANG 1.1 with any data model that has optional keys, it will have to > support this new syntax.
>

The instance-identifier is a type that has been used by other
modules. For example, ietf-netconf-monitoring has a leaf-list
locked-node of type instance-identifier. So how do I know whether a
certain server implements the old syntax of instance-identifier or the
new one? The node-instance-identifier module introduces a type
node-instance-identifier which is derived from xpath (so that is fine)
but the description refers to YANG instance identifiers:

=A0 =A0 =A0 =A0A node-instance-identifier value is an
=A0 =A0 =A0 =A0unrestricted YANG instance-identifier expression.
=A0 =A0 =A0 =A0All the same rules as an instance-identifier apply
=A0 =A0 =A0 =A0except predicates for keys are optional.=A0 If a key
=A0 =A0 =A0 =A0predicate is missing, then the node-instance-identifier
=A0 =A0 =A0 =A0represents all possible server instances for that key.

Well, this does not seem really harmful but still, can you tell
whether a certain NACM implementation will accept syntax option B?

NACM implementations will reject (b) because it= is not a valid schema-instance-identifier.
But they will treat o= ption (a) (missing key) as a match on all instances with that value.
<= div>

So is this really something we should do in 1.1 or something to put on
the candidate list of a future YANG 2.0 version?

<= /div>
IMO it would be OK to defer this feature until YANG 2.0.
There is a simple workaround, which is to define a value for the optional= key
that means "not used", =A0This is usually possible= .


> For an old client it might pose a problem if it interprets the i-i:s i= t
> receives from a 1.1 server that has such instances.


It will not be accepted if the tool im= plements the RFC correctly.
I think it will break old clients, wh= ich violates 1 of our main design goals.

I assume it is quite possible that there are clients that do parse
instance-identifiers.

yes -- implemente= d according to the RFC. The value is checked to
see that only the= correct predicates are present.


=A0

/js

Andy


--001a11c12da2eac8da050257dd7e-- From nobody Mon Sep 8 01:43:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 819871A06B6 for ; Mon, 8 Sep 2014 01:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 mHcFSKNuIH0w for ; Mon, 8 Sep 2014 01:43:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5B7E51A016E for ; Mon, 8 Sep 2014 01:43:44 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id ECA2E1280098; Mon, 8 Sep 2014 10:43:42 +0200 (CEST) Date: Mon, 08 Sep 2014 10:43:42 +0200 (CEST) Message-Id: <20140908.104342.1714381070585686406.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140905204931.GB88590@elstar.local> References: <20140904203818.GD84465@elstar.local> <20140905.091645.2102743941647507448.mbj@tail-f.com> <20140905204931.GB88590@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ypliS7OkF-o8BUgrSau7iQOGsx8 Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 08:43:45 -0000 Juergen Schoenwaelder wrote: > On Fri, Sep 05, 2014 at 09:16:45AM +0200, Martin Bjorklund wrote: > > [...] > > > Option A: > > > > /foo[a=1] > > /foo[a=1][b=1] > > > > Option B: > > > > /foo[a=1][not b] > > /foo[a=1][b=1] > > > > Both these options are still valid XPath expressions. > > [...] > > > I don't think this will pose a problem to a server; if it implements > > YANG 1.1 with any data model that has optional keys, it will have to > > support this new syntax. > > > > The instance-identifier is a type that has been used by other > modules. For example, ietf-netconf-monitoring has a leaf-list > locked-node of type instance-identifier. So how do I know whether a > certain server implements the old syntax of instance-identifier or the > new one? ietf-netconf-monitoring is a YANG 1.0 module, so until it is revised and updated to YANG 1.1 it will only support the old syntax. > The node-instance-identifier module introduces a type > node-instance-identifier which is derived from xpath (so that is fine) > but the description refers to YANG instance identifiers: > > A node-instance-identifier value is an > unrestricted YANG instance-identifier expression. > All the same rules as an instance-identifier apply > except predicates for keys are optional. If a key > predicate is missing, then the node-instance-identifier > represents all possible server instances for that key. > > Well, this does not seem really harmful but still, can you tell > whether a certain NACM implementation will accept syntax option B? Same as above. > So is this really something we should do in 1.1 or something to put on > the candidate list of a future YANG 2.0 version? I don't think it would be easier or better to do this in YANG 2.0. This is essentially an update of an existing type, and the update rules of YANG modules allow this (ok, this isn't a YANG module that is being updated, but similar). If we don't think that we can make these kind of changes in this case, can we *ever* allow an update of any type? > > For an old client it might pose a problem if it interprets the i-i:s it > > receives from a 1.1 server that has such instances. > > I assume it is quite possible that there are clients that do parse > instance-identifiers. /martin From nobody Mon Sep 8 04:29:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21E0B1A8725 for ; Mon, 8 Sep 2014 04:29:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 CHXAOiipF7p5 for ; Mon, 8 Sep 2014 04:28:57 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 082171A8724 for ; Mon, 8 Sep 2014 04:28:57 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 568081401; Mon, 8 Sep 2014 13:28:54 +0200 (CEST) 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 bUJW2Od7M0Hy; Mon, 8 Sep 2014 13:28:52 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Sep 2014 13:28:53 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C3C7020036; Mon, 8 Sep 2014 13:28:53 +0200 (CEST) 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 e0DLsgI7M_NU; Mon, 8 Sep 2014 13:28:53 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD0C820035; Mon, 8 Sep 2014 13:28:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E594D2E5D9B3; Mon, 8 Sep 2014 13:28:50 +0200 (CEST) Date: Mon, 8 Sep 2014 13:28:50 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140908112850.GA94181@elstar.local> Mail-Followup-To: Martin Bjorklund , reid@snmp.com, netmod@ietf.org References: <20140904203818.GD84465@elstar.local> <20140905.091645.2102743941647507448.mbj@tail-f.com> <20140905204931.GB88590@elstar.local> <20140908.104342.1714381070585686406.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140908.104342.1714381070585686406.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wy_pNn--xtzhYpF4kQeFRd3niC0 Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 11:29:01 -0000 On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > > So is this really something we should do in 1.1 or something to put on > > the candidate list of a future YANG 2.0 version? > > I don't think it would be easier or better to do this in YANG 2.0. > > This is essentially an update of an existing type, and the update > rules of YANG modules allow this (ok, this isn't a YANG module that is > being updated, but similar). If we don't think that we can make these > kind of changes in this case, can we *ever* allow an update of any > type? I am not that sure the update rules cover this. Can you point to the relevant text? The question at the end of the day is whether the market will expect that a fundamental type changes in a 1.1 release. /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 Sep 8 04:32:08 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B1AE1A872A for ; Mon, 8 Sep 2014 04:32:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 rqIpiQvU4od4 for ; Mon, 8 Sep 2014 04:32:04 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 2813F1A872C for ; Mon, 8 Sep 2014 04:32:04 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id E21E31280098; Mon, 8 Sep 2014 13:32:02 +0200 (CEST) Date: Mon, 08 Sep 2014 13:32:02 +0200 (CEST) Message-Id: <20140908.133202.651929766605641807.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140908112850.GA94181@elstar.local> References: <20140905204931.GB88590@elstar.local> <20140908.104342.1714381070585686406.mbj@tail-f.com> <20140908112850.GA94181@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9iSa1AYufe6jgNi9VuY0CktIdzg Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 11:32:07 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > > > So is this really something we should do in 1.1 or something to put on > > > the candidate list of a future YANG 2.0 version? > > > > I don't think it would be easier or better to do this in YANG 2.0. > > > > This is essentially an update of an existing type, and the update > > rules of YANG modules allow this (ok, this isn't a YANG module that is > > being updated, but similar). If we don't think that we can make these > > kind of changes in this case, can we *ever* allow an update of any > > type? > > I am not that sure the update rules cover this. Can you point to the > relevant text? The question at the end of the day is whether the > market will expect that a fundamental type changes in a 1.1 release. Section 10 has this: o A "range", "length", or "pattern" statement may expand the allowed value space. In this case, we're expanding the value space of an existing type. /martin From nobody Mon Sep 8 06:18:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C5E81A87CC for ; Mon, 8 Sep 2014 06:18:37 -0700 (PDT) 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 IrIZ137gaoQO for ; Mon, 8 Sep 2014 06:18:35 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BA4D1A87CB for ; Mon, 8 Sep 2014 06:18:35 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id i17so15659470qcy.12 for ; Mon, 08 Sep 2014 06:18:34 -0700 (PDT) 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=O2tTkuOaC5b3Qx2E8cfbePi901z+W8IBwvS5BI3PQ4s=; b=IMS5g3k09trrvVmQ6KWHBMaQX2MBJ6y5IRJpI+2uP5LGx+lcXKD/74ku+iVmeIwcBe SqZ6RodnWJLam8kn7wnjLYtCKJb6i4ZHVRRlGFDGtadkrthBmYslrQQF02AO3pNjMf1R 3dlBZKzLFv1d5dEOJFvdGznhlJUZyqqje8Nr+4GKXcGT0kRg74SrXFdKKHMpQmyovxyt v8IgId5XZ7hLISNbDy7Hh9fSEX+/nJznQmk0UD8YDiqBwX1Zhj2u66yDYsCOkQuiaV6z QAvKrMZQK5Zt8MkFuDdqja8q74TjLB1r47BjJG51iR+8omNKaXDsHmtgem58XyIoYPoi AGZg== X-Gm-Message-State: ALoCoQnIk9Aui26JiFQlQYu4l3/5IWT1TZ8TvbOkPomhN6F4xMSob2bAZ2vqYqm0cNlPR37dFu+V MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr39385192qgl.90.1410182314427; Mon, 08 Sep 2014 06:18:34 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 06:18:34 -0700 (PDT) In-Reply-To: <20140908.133202.651929766605641807.mbj@tail-f.com> References: <20140905204931.GB88590@elstar.local> <20140908.104342.1714381070585686406.mbj@tail-f.com> <20140908112850.GA94181@elstar.local> <20140908.133202.651929766605641807.mbj@tail-f.com> Date: Mon, 8 Sep 2014 06:18:34 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11c13986ebad7605028da70b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/dJ_7_zgFmHWVZhUTeoQGjSrGBx4 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:18:37 -0000 --001a11c13986ebad7605028da70b Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 8, 2014 at 4:32 AM, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > > > > So is this really something we should do in 1.1 or something to put > on > > > > the candidate list of a future YANG 2.0 version? > > > > > > I don't think it would be easier or better to do this in YANG 2.0. > > > > > > This is essentially an update of an existing type, and the update > > > rules of YANG modules allow this (ok, this isn't a YANG module that is > > > being updated, but similar). If we don't think that we can make these > > > kind of changes in this case, can we *ever* allow an update of any > > > type? > > > > I am not that sure the update rules cover this. Can you point to the > > relevant text? The question at the end of the day is whether the > > market will expect that a fundamental type changes in a 1.1 release. > > Section 10 has this: > > o A "range", "length", or "pattern" statement may expand the allowed > value space. > > > In this case, we're expanding the value space of an existing type. > There are type sub-statements. IMO this change breaks implementations of the instance-identifier base type. NACM does not support the new syntax. It doesn't make sense to have some objects use 1 type of instance-identifier and other objects use a different type. The field is also not specific to 1 module. This new feature breaks existing implementations. It should be rejected unless it is 100% backward compatible with any possible use of an instance-identifier leaf in YANG 1.0. > > /martin > Andy > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c13986ebad7605028da70b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 8, 2014 at 4:32 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Juergen Schoenwaelder &= lt;j.schoenwaelder@= jacobs-university.de> wrote:
> On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> >
> > > So is this really something we should do in 1.1 or something= to put on
> > > the candidate list of a future YANG 2.0 version?
> >
> > I don't think it would be easier or better to do this in YANG= 2.0.
> >
> > This is essentially an update of an existing type, and the update=
> > rules of YANG modules allow this (ok, this isn't a YANG modul= e that is
> > being updated, but similar).=A0 If we don't think that we can= make these
> > kind of changes in this case, can we *ever* allow an update of an= y
> > type?
>
> I am not that sure the update rules cover this. Can you point to the > relevant text? The question at the end of the day is whether the
> market will expect that a fundamental type changes in a 1.1 release.
Section 10 has this:

=A0 =A0o=A0 A "range", "length", or "pattern"= statement may expand the allowed
=A0 =A0 =A0 value space.


In this case, we're expanding the value space of an existing type.
<= /blockquote>

There are type sub-statements.
IM= O this change breaks implementations of the instance-identifier base type.<= /div>
NACM does not support the new syntax. It doesn't make sense t= o have
some objects use 1 type of instance-identifier and other o= bjects use a different type.
The <error-path> field is also= not specific to 1 module. This new feature breaks
existing imple= mentations. =A0It should be rejected unless it is 100% backward
c= ompatible with any possible use of an instance-identifier leaf in YANG 1.0.=



/martin

Andy
=A0

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

--001a11c13986ebad7605028da70b-- From nobody Mon Sep 8 06:36:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B3351A87DF for ; Mon, 8 Sep 2014 06:36:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 IOPG8s85CSAj for ; Mon, 8 Sep 2014 06:36:51 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AE7341A87DE for ; Mon, 8 Sep 2014 06:36:51 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id D9A8E1280008; Mon, 8 Sep 2014 15:36:47 +0200 (CEST) Date: Mon, 08 Sep 2014 15:36:47 +0200 (CEST) Message-Id: <20140908.153647.548460559679820252.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20140908112850.GA94181@elstar.local> <20140908.133202.651929766605641807.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/netmod/NEaDauq44N6KkBk2rIxxilz4eac Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 13:36:53 -0000 Andy Bierman wrote: > On Mon, Sep 8, 2014 at 4:32 AM, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > > > > > So is this really something we should do in 1.1 or something to put > > on > > > > > the candidate list of a future YANG 2.0 version? > > > > > > > > I don't think it would be easier or better to do this in YANG 2.0. > > > > > > > > This is essentially an update of an existing type, and the update > > > > rules of YANG modules allow this (ok, this isn't a YANG module that is > > > > being updated, but similar). If we don't think that we can make these > > > > kind of changes in this case, can we *ever* allow an update of any > > > > type? > > > > > > I am not that sure the update rules cover this. Can you point to the > > > relevant text? The question at the end of the day is whether the > > > market will expect that a fundamental type changes in a 1.1 release. > > > > Section 10 has this: > > > > o A "range", "length", or "pattern" statement may expand the allowed > > value space. > > > > > > In this case, we're expanding the value space of an existing type. > > > > There are type sub-statements. How is the fact that it is a base type different from the same situation for a derived type? > IMO this change breaks implementations of the instance-identifier base type. > NACM does not support the new syntax. It doesn't make sense to have > some objects use 1 type of instance-identifier and other objects use a > different type. > The field is also not specific to 1 module. No, error-path is not an instance-identifier, it is an XPath expression. > This new feature > breaks > existing implementations. It should be rejected unless it is 100% backward > compatible with any possible use of an instance-identifier leaf in YANG 1.0. My point is that if we believe that this is a problem now for this particular type, why do we think that it is ok to extend the value space for a derived type? /martin From nobody Mon Sep 8 08:03:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6221A8864 for ; Mon, 8 Sep 2014 08:03:35 -0700 (PDT) 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 yejhCDPaZUQI for ; Mon, 8 Sep 2014 08:03:30 -0700 (PDT) Received: from mail-qa0-f45.google.com (mail-qa0-f45.google.com [209.85.216.45]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FF6C1A8861 for ; Mon, 8 Sep 2014 08:03:27 -0700 (PDT) Received: by mail-qa0-f45.google.com with SMTP id v10so2391294qac.18 for ; Mon, 08 Sep 2014 08:03:26 -0700 (PDT) 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=TmL+q7u9zoI3vNzXDNitvFr73X7wIWFlF975SNbb6IA=; b=YWkSZZ2mvRpf2aD+DBtaEpffmr3BMECAG6BQx+NZc4dt0I8Qyl3ECFaEuI2DIvpdvd awN1Ei2gS7BMz7sziAvR3TfUILwpZG3KGFNkRCIt8ALAmar7WuHEmmYaWlA+2Wy7DzuG iex8oDt//uONKvAWY+Y8P9Xics30DoF3OFhtATHX0UnzsggE3ReOplGNU5C2yhMByNnz Ng9l5gHjTE6rsMeM1UCBSWk9tGrdLiVWNPc4BfsSvIhb7wFIpfbla9UA8s6JM8WIiDch YKM5Zs4IkObcr5JaXXlKf6QjALwWfjhuT6KqAQbDtrqi5lTwFgG1PEJO6Tm8fxFR6Gld pC+g== X-Gm-Message-State: ALoCoQlvrHHxTNP+tTW+Q6ALolSHNUfuhOsokt3OTmyoa2cQQyF0Dr/xTcB1Vme0PRJBa613btLh MIME-Version: 1.0 X-Received: by 10.140.98.7 with SMTP id n7mr40910002qge.83.1410188606628; Mon, 08 Sep 2014 08:03:26 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Mon, 8 Sep 2014 08:03:26 -0700 (PDT) In-Reply-To: <20140908.153647.548460559679820252.mbj@tail-f.com> References: <20140908112850.GA94181@elstar.local> <20140908.133202.651929766605641807.mbj@tail-f.com> <20140908.153647.548460559679820252.mbj@tail-f.com> Date: Mon, 8 Sep 2014 08:03:26 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113ac3c6f71c8005028f1e0e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/sK06Vu4LnPX3odUOQwJSVDu9QDg Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 15:03:38 -0000 --001a113ac3c6f71c8005028f1e0e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 8, 2014 at 6:36 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Mon, Sep 8, 2014 at 4:32 AM, Martin Bjorklund wrote: > > > > > Juergen Schoenwaelder wrote: > > > > On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: > > > > > Juergen Schoenwaelder > wrote: > > > > > > > > > > > So is this really something we should do in 1.1 or something to > put > > > on > > > > > > the candidate list of a future YANG 2.0 version? > > > > > > > > > > I don't think it would be easier or better to do this in YANG 2.0. > > > > > > > > > > This is essentially an update of an existing type, and the update > > > > > rules of YANG modules allow this (ok, this isn't a YANG module > that is > > > > > being updated, but similar). If we don't think that we can make > these > > > > > kind of changes in this case, can we *ever* allow an update of any > > > > > type? > > > > > > > > I am not that sure the update rules cover this. Can you point to the > > > > relevant text? The question at the end of the day is whether the > > > > market will expect that a fundamental type changes in a 1.1 release. > > > > > > Section 10 has this: > > > > > > o A "range", "length", or "pattern" statement may expand the > allowed > > > value space. > > > > > > > > > In this case, we're expanding the value space of an existing type. > > > > > > > There are type sub-statements. > > How is the fact that it is a base type different from the same > situation for a derived type? > The only allowed restriction for an instance-identifier is the "require-instance" sub-statement. (9.13.1) I don't see how "range", "length", or "pattern" have anything to do with instance-identifier. > > > IMO this change breaks implementations of the instance-identifier base > type. > > NACM does not support the new syntax. It doesn't make sense to have > > some objects use 1 type of instance-identifier and other objects use a > > different type. > > The field is also not specific to 1 module. > > No, error-path is not an instance-identifier, it is an XPath expression. > > It is s node-instance-identifier which has specific rules about what predicates are allowed. The proposed [not foo] syntax is not allowed by this derived type. > This new feature > > breaks > > existing implementations. It should be rejected unless it is 100% > backward > > compatible with any possible use of an instance-identifier leaf in YANG > 1.0. > > My point is that if we believe that this is a problem now for this > particular type, why do we think that it is ok to extend the value > space for a derived type? > > The instance-identifier has specific rules that are not followed by this proposal. Changing a base type in a way that breaks existing tools is not acceptable, according to our own guidelines for YANG 1.1. IMO this is not a problem, this is a new feature. > > /martin > Andy --001a113ac3c6f71c8005028f1e0e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable



On Mon, Sep 8, 2014 at 6:36 AM, Martin Bjorklund = <mbj@tail-f.com&= gt; wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Mon, Sep 8, 2014 at 4:32 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> > > On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund w= rote:
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wro= te:
> > > >
> > > > > So is this really something we should do in 1.1 or= something to put
> > on
> > > > > the candidate list of a future YANG 2.0 version? > > > >
> > > > I don't think it would be easier or better to do th= is in YANG 2.0.
> > > >
> > > > This is essentially an update of an existing type, and = the update
> > > > rules of YANG modules allow this (ok, this isn't a = YANG module that is
> > > > being updated, but similar).=A0 If we don't think t= hat we can make these
> > > > kind of changes in this case, can we *ever* allow an up= date of any
> > > > type?
> > >
> > > I am not that sure the update rules cover this. Can you poin= t to the
> > > relevant text? The question at the end of the day is whether= the
> > > market will expect that a fundamental type changes in a 1.1 = release.
> >
> > Section 10 has this:
> >
> >=A0 =A0 o=A0 A "range", "length", or "pat= tern" statement may expand the allowed
> >=A0 =A0 =A0 =A0value space.
> >
> >
> > In this case, we're expanding the value space of an existing = type.
> >
>
> There are type sub-statements.

How is the fact that it is a base type different from the same
situation for a derived type?


The only allowed restriction for an instance-identifier is the "= require-instance"
sub-statement. (9.13.1) =A0I don't see= how "range", "length", or
"pattern"= ; have anything to do with instance-identifier.

= =A0

> IMO this change breaks implementations of the instance-identifier base= type.
> NACM does not support the new syntax. It doesn't make sense to hav= e
> some objects use 1 type of instance-identifier and other objects use a=
> different type.
> The <error-path> field is also not specific to 1 module.

No, error-path is not an instance-identifier, it is an XPath expression.

It is s node-instance-identifier which= has specific rules about what predicates
are allowed. =A0The pro= posed [not foo] syntax is not allowed by this derived type.

<= /div>


> This new feature
> breaks
> existing implementations.=A0 It should be rejected unless it is 100% b= ackward
> compatible with any possible use of an instance-identifier leaf in YAN= G 1.0.

My point is that if we believe that this is a problem now for this
particular type, why do we think that it is ok to extend the value
space for a derived type?


The instance-identifier has specific rules that are = not followed by this proposal.
Changing a base type in a way that= breaks existing tools is not acceptable,
according to our own gu= idelines for YANG 1.1.

IMO this is not a problem, = this is a new feature.
=A0

/martin

Andy<= /div>

--001a113ac3c6f71c8005028f1e0e-- From nobody Mon Sep 8 09:12:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A8C01A88A9 for ; Mon, 8 Sep 2014 09:12:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_40=-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 qoePuXuukVqS for ; Mon, 8 Sep 2014 09:12:48 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2B971A0537 for ; Mon, 8 Sep 2014 09:12:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4D1B9540149; Mon, 8 Sep 2014 18:12:45 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ynOpUaSmpu-T; Mon, 8 Sep 2014 18:12:40 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 53171540081; Mon, 8 Sep 2014 18:12:40 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140903111127.GA79883@elstar.local> References: <20140903111127.GA79883@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 08 Sep 2014 18:12:39 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kzzsJTyMQLMzUXc7rY4lIgSRu_Y Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 16:12:50 -0000 Hi, Juergen Schoenwaelder writes: > * OPEN :Y13: allow multiple inheritance for identities > > 2014-07-02 meeting action: LL to write a more complete example and > once done we get back to this issue. I addressed this open action and updated the issue description: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-13 Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 8 12:26:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF7681A0326 for ; Mon, 8 Sep 2014 12:26:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T5lkc_0UJesc for ; Mon, 8 Sep 2014 12:26:55 -0700 (PDT) Received: from mx0b-000f0801.pphosted.com (mx0b-000f0801.pphosted.com [IPv6:2620:100:9005:71::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08F4E1A02D4 for ; Mon, 8 Sep 2014 12:26:54 -0700 (PDT) Received: from pps.filterd (m0048192 [127.0.0.1]) by mx0b-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s88ITHxU013073; Mon, 8 Sep 2014 12:26:54 -0700 Received: from brmwp-exchub02.corp.brocade.com ([208.47.132.227]) by mx0b-000f0801.pphosted.com with ESMTP id 1p98x1af61-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 08 Sep 2014 12:26:54 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.186.49) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 8 Sep 2014 13:26:52 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.90]) by brm-excashub-1.corp.brocade.com ([172.16.186.74]) with mapi; Mon, 8 Sep 2014 13:26:52 -0600 From: Kiran Agrahara Sreenivasa To: Juergen Schoenwaelder , "netmod@ietf.org" Date: Mon, 8 Sep 2014 13:26:51 -0600 Thread-Topic: [netmod] face-to-face interim meeting attendee list Thread-Index: Ac/IFaIXEmdlFbEIQkC/2Oa5a7jkZADhSDOg Message-ID: References: <20140904075534.GA82785@elstar.local> In-Reply-To: <20140904075534.GA82785@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.27, 0.0.0000 definitions=2014-09-08_04:2014-09-08,2014-09-08,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409080153 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_CGAVN96F9F_rre3aSlPSpoTfnE Subject: Re: [netmod] face-to-face interim meeting attendee list X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 19:26:56 -0000 Hi Juergen I'll be attending remotely too. Please send me the meeting details. Thanks Kiran -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Thursday, September 04, 2014 2:56 AM To: netmod@ietf.org Subject: [netmod] face-to-face interim meeting attendee list Hi, I am compiling the list of face-to-face interim meeting attendees. This is what I have right now (essentially taken from the Doodle poll). Please send me your updates. For access to the building, I need an accurate attendee list. - Juergen Schoenwaelder - Lada Lhotka - Andy Bierman - Martin Bjoerklund - Mahesh Jethanandani - Benoti Claise - Balazs Lengyel - Kent Watsen - Dan Romascanu (remote) - Peter Van Horne - Dean Bogdanovic - Susan Hares - Jeffrey Haas /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Sep 8 14:20:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 383001A038E for ; Mon, 8 Sep 2014 14:20:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 4q2HteA8OmQS for ; Mon, 8 Sep 2014 14:20:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93DC31A0354 for ; Mon, 8 Sep 2014 14:20:40 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0F533123D; Mon, 8 Sep 2014 23:20:39 +0200 (CEST) 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 hTsQpqzEoQ8R; Mon, 8 Sep 2014 23:20:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 8 Sep 2014 23:20:38 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6387120036; Mon, 8 Sep 2014 23:20:38 +0200 (CEST) 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 amWZdneXvP8l; Mon, 8 Sep 2014 23:20:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B27A220035; Mon, 8 Sep 2014 23:20:36 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A1B4C2E5E411; Mon, 8 Sep 2014 23:20:35 +0200 (CEST) Date: Mon, 8 Sep 2014 23:20:34 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140908212033.GA95667@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140903111127.GA79883@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5QU9yTtGbYEv4ciaTKGHquvI_VQ Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Sep 2014 21:20:43 -0000 On Mon, Sep 08, 2014 at 06:12:39PM +0200, Ladislav Lhotka wrote: > Hi, > > Juergen Schoenwaelder writes: > > * OPEN :Y13: allow multiple inheritance for identities > > > > 2014-07-02 meeting action: LL to write a more complete example and > > once done we get back to this issue. > > I addressed this open action and updated the issue description: > > https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-13 > Thanks. What are the update rules for this? Can I add/remove base statements? What does it mean to have a default value CC-BY-SA (which has two bases) for a leaf whos type has been restricted to a single base? I find the example not very intuitive - CC-BY-SA means AND (both conditions need to be satisfied) and not OR. Are the proposed semantics that N bases are forming an AND or an OR? /js PS: Perhaps the example should have been added to solution Y13-01 instead of the description of the issue. As it is, it looks like the description already limits things to a particular solution. It would make more sense if the description would explain (a) what the problem is we are solving and (b) why this is useful to have in 1.1. -- 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 Sep 9 02:55:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C8DB1A030A for ; Tue, 9 Sep 2014 02:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oW8-Z41hs8cp for ; Tue, 9 Sep 2014 02:55:30 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7ED21A0AE9 for ; Tue, 9 Sep 2014 02:55:28 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1A622540659; Tue, 9 Sep 2014 11:55:26 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TYVV8GzGBCN7; Tue, 9 Sep 2014 11:55:21 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 8EC5C540030; Tue, 9 Sep 2014 11:55:21 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder In-Reply-To: <20140908212033.GA95667@elstar.local> References: <20140903111127.GA79883@elstar.local> <20140908212033.GA95667@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Tue, 09 Sep 2014 11:55:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ad5QrXmg2PK2XSext_XyJ29eAZQ Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 09:55:32 -0000 Juergen Schoenwaelder writes: > On Mon, Sep 08, 2014 at 06:12:39PM +0200, Ladislav Lhotka wrote: >> Hi, >> >> Juergen Schoenwaelder writes: >> > * OPEN :Y13: allow multiple inheritance for identities >> > >> > 2014-07-02 meeting action: LL to write a more complete example and >> > once done we get back to this issue. >> >> I addressed this open action and updated the issue description: >> >> https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-13 >> > > Thanks. > > What are the update rules for this? Can I add/remove base statements? This has to be discussed, my take is that they could be - added but not removed in identity definition, - removed in identityref, unless it is the last base statement, but not added. > What does it mean to have a default value CC-BY-SA (which has two > bases) for a leaf whos type has been restricted to a single base? I Its value can be any identity whose base (or one of the bases) is "share-alike", or any identity derived from it. In the example, the other value "CC-BY-NC-SA" is also acceptable. > find the example not very intuitive - CC-BY-SA means AND (both > conditions need to be satisfied) and not OR. Are the proposed > semantics that N bases are forming an AND or an OR? AND. > > /js > > PS: Perhaps the example should have been added to solution Y13-01 > instead of the description of the issue. As it is, it looks like > the description already limits things to a particular solution. It > would make more sense if the description would explain (a) what > the problem is we are solving and (b) why this is useful to have > in 1.1. Done, I also expanded the solution text to answer your questions above. Thanks, Lada > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Sep 9 07:11:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EDB121A06F7 for ; Tue, 9 Sep 2014 07:11:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7dcGzLAnvrZC for ; Tue, 9 Sep 2014 07:11:29 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCEF91A6FAB for ; Tue, 9 Sep 2014 07:09:57 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-10-540f0a33ff8c Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id D6.3E.21334.33A0F045; Tue, 9 Sep 2014 16:09:55 +0200 (CEST) Received: from [159.107.197.75] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.174.1; Tue, 9 Sep 2014 16:09:55 +0200 Message-ID: <540F0A32.5060307@ericsson.com> Date: Tue, 9 Sep 2014 16:09:54 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Bjorklund , References: <20140905204931.GB88590@elstar.local> <20140908.104342.1714381070585686406.mbj@tail-f.com> <20140908112850.GA94181@elstar.local> <20140908.133202.651929766605641807.mbj@tail-f.com> In-Reply-To: <20140908.133202.651929766605641807.mbj@tail-f.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUyM+Jvja4xF3+IwacOE4urG38yWnR3P2O3 mH+xkdWB2WPJkp9MHhsOeHps/LWYJYA5issmJTUnsyy1SN8ugSujd+ZRloLnAhXHJ7UyNTD2 83YxcnJICJhIrJ3Vyw5hi0lcuLeerYuRi0NI4CijxPdLzewQzmpGiTmr5rCBVPEKaEv8P9fO CGKzCKhItExtYgax2QSMJKb2n2cBsUUFoiTuXOpnhagXlDg58wlYXETAV+Ll1mtg25gFRCXW X7zE1MXIwSEsYCjx74o+xK4DjBKdd6czgdRwCjhIzD/9iBWi3lbiwpzrLBC2vMT2t3PA9goJ aEg8vPCXdQKj4Cwk62YhaZmFpGUBI/MqRtHi1OLi3HQjY73Uoszk4uL8PL281JJNjMAQPrjl t+4OxtWvHQ8xCnAwKvHwKsTzhQixJpYVV+YeYpTmYFES5110bl6wkEB6YklqdmpqQWpRfFFp TmrxIUYmDk6pBkbeQ/xbvzjESCvc/Ogo1pD9WXUdixPH6/IH1/ecLvMKWJx7/9yHratZj+h8 ahWdp3wl++FX0YK69d6MBgsvaU79yXK2b8t253u7XG20Nt89UC1h9VXA7ll3W/lP4W6LN4Kn 99q73i02b1goohi45Uf0JJ2Dxhc2n+zxWhzIq7yiULP7R9PTv9VKLMUZiYZazEXFiQDl8456 QgIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/n0GSGsQG29YF2qHC7q_zvnQL-PU Cc: netmod@ietf.org Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 14:11:40 -0000 Hello Martin, If instance identifier was just a string it would be OK to extend its value space, but i-i has a rather strict connection to other leafs/lists/containers in the model and a fixed internal structure. These rules would be changed beside expanding the value space. IMHO applications might be parsing the i-i following the yang 1.0 rules; i-is that can point to anything, not just to specific models. So this would mean that if you want to implement any yang 1.1 model you need to upgrade these applications e.g. NACM too. regards Balazs On 2014-09-08 13:32, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Mon, Sep 08, 2014 at 10:43:42AM +0200, Martin Bjorklund wrote: >>> Juergen Schoenwaelder wrote: >>> >>>> So is this really something we should do in 1.1 or something to put on >>>> the candidate list of a future YANG 2.0 version? >>> I don't think it would be easier or better to do this in YANG 2.0. >>> >>> This is essentially an update of an existing type, and the update >>> rules of YANG modules allow this (ok, this isn't a YANG module that is >>> being updated, but similar). If we don't think that we can make these >>> kind of changes in this case, can we *ever* allow an update of any >>> type? >> I am not that sure the update rules cover this. Can you point to the >> relevant text? The question at the end of the day is whether the >> market will expect that a fundamental type changes in a 1.1 release. > Section 10 has this: > > o A "range", "length", or "pattern" statement may expand the allowed > value space. > > > In this case, we're expanding the value space of an existing type. > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Tue Sep 9 12:39:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C0EA81A020B for ; Tue, 9 Sep 2014 12:39:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 wiXOgZvr9o23 for ; Tue, 9 Sep 2014 12:39:50 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BC9A1A01CA for ; Tue, 9 Sep 2014 12:39:50 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 4A47427C9E15A for ; Tue, 9 Sep 2014 19:39:46 +0000 (GMT) Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s89JdnqW019520 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 9 Sep 2014 15:39:49 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.02.0247.003; Tue, 9 Sep 2014 15:39:49 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: YANG 1.1 Y12 (initialized-by-system) Thread-Index: Ac/MY97+sqNJWhnwQHW0OUsseK+t2Q== Date: Tue, 9 Sep 2014 19:39:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.16] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C940D1DUS70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/tijXDtZ-mO5RmXU0XtjBl6yXXJA Subject: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 19:39:55 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C940D1DUS70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I see in the issues list that initialized-by-system is intended to be appli= cable to leafs and leaf-lists. Can someone give an example of how that might look for a leaf-list ? Is i= t just to indicate that there may be a system initialized member of the lea= f-list ? Was there any previous discussion about having the initialized-by-system co= ncept somehow applying to lists (i.e. indicating that the system might init= ialize some list instances/entries) ? For example -> the network element = (server) may automatically add an interface called "system" or a user calle= d "admin" during startup. The initialized-by-system could perhaps be ind= icated at the list level to at least indicate that there may be system init= ialized list entries (i.e. to prompt the client to to see them= ). I'm also interested in the note that says "A similar issue: passwd of type = crypt-hash.". I'd like to see what the intended use case is behind that s= entence (I'm hoping it might help me with an issue we have that sounds simi= lar). Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5C940D1DUS70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I see in the issues list that initialized-by-system is intended to be = applicable to leafs and leaf-lists.
 
Can someone give an example of how that might look for a leaf-list ?&n= bsp;  Is it just to indicate that there may be a system initialized me= mber of the leaf-list ?
 
Was there any previous discussion about having the initialized-by-syst= em concept somehow applying to lists (i.e. indicating that the system might= initialize some list instances/entries) ?   For example -> th= e network element (server) may automatically add an interface called “system” or a user called “admin&= #8221; during startup.    The initialized-by-system could pe= rhaps be indicated at the list level to at least indicate that there may be= system initialized list entries (i.e. to prompt the client to <get-conf= ig> to see them).
 
I’m also interested in the note that says “A similar issue= : passwd of type crypt-hash.”.   I’d like to see what= the intended use case is behind that sentence (I’m hoping it might h= elp me with an issue we have that sounds similar).
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5C940D1DUS70TWXCHMBA11z_-- From nobody Tue Sep 9 13:40:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59AD21A0164 for ; Tue, 9 Sep 2014 13:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 Xgm21Uq9X317 for ; Tue, 9 Sep 2014 13:40:09 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id A99501A0149 for ; Tue, 9 Sep 2014 13:40:09 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 493841280008; Tue, 9 Sep 2014 22:40:06 +0200 (CEST) Date: Tue, 09 Sep 2014 22:40:05 +0200 (CEST) Message-Id: <20140909.224005.02423221.mbj@tail-f.com> To: jason.sterne@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/ORtS_3R3qKw_4Lgy3XeLfaYcxfQ Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Sep 2014 20:40:11 -0000 Hi, "Sterne, Jason (Jason)" wrote: > Hi all, > > I see in the issues list that initialized-by-system is intended to be > applicable to leafs and leaf-lists. > > Can someone give an example of how that might look for a leaf-list ? Is it > just to indicate that there may be a system initialized member of the leaf-list > ? Right; when the parent node is created, the system initializes one or more members of the leaf-list. > Was there any previous discussion about having the initialized-by-system > concept somehow applying to lists (i.e. indicating that the system might > initialize some list instances/entries)? IIRC everyone agreed that this was not needed. Unclear use cases, and unclear how it would work. > For example -> the network element > (server) may automatically add an interface called "system" or a user called > "admin" during startup. This is already possible today. Most systems come with some kind of factory default config. When a client connects the very first time, it cannot assume that the config is empty. > The initialized-by-system could perhaps be indicated > at the list level to at least indicate that there may be system initialized > list entries (i.e. to prompt the client to to see them). > > I'm also interested in the note that says "A similar issue: passwd of type > crypt-hash.". I'd like to see what the intended use case is behind that > sentence (I'm hoping it might help me with an issue we have that sounds > similar). If a clear-text value is written to a node of type crypt-hash, the server calculates the hash and stores the hash value instead of the clear text value. This is not the same as initialized-by system, but similar. /martin From nobody Tue Sep 9 22:28:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3DAB1A04B0 for ; Tue, 9 Sep 2014 22:28:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 3BCHLsib2_WQ for ; Tue, 9 Sep 2014 22:28:16 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2F651A03F2 for ; Tue, 9 Sep 2014 22:28:15 -0700 (PDT) Received: from [192.168.42.191] (cst-prg-70-9.cust.vodafone.cz [46.135.70.9]) by mail.nic.cz (Postfix) with ESMTPSA id 013A013FBD3; Wed, 10 Sep 2014 07:28:07 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410326893; bh=4Te8+w1GmmEDxNUIHlzo2ZHcd3XLihj45dlvrgoG7nA=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=UvVFsmEHhw8XOvYUIGILoFP7UpxOnKURC2nquvy2yxfs8giPs3tCow6VDOzk469/L zAqZd0JErFf//cDPrK32DVrBzbdRwoBxQb4vC7icT8pQGrMJpM/qyHILtgPXngElC0 nJQrsd/py9aP54ywskGFKdyQf6c3CQnbVWrmqtJ4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140909.224005.02423221.mbj@tail-f.com> Date: Wed, 10 Sep 2014 07:26:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <7A8B3D60-A627-45A5-ABE4-6444F1655828@nic.cz> References: <20140909.224005.02423221.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X5ohRjZQ6kpjs3mJSHUjGHJ6F1E Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 05:28:18 -0000 On 09 Sep 2014, at 22:40, Martin Bjorklund wrote: > Hi, >=20 > "Sterne, Jason (Jason)" wrote: >> Hi all, >>=20 >> I see in the issues list that initialized-by-system is intended to be >> applicable to leafs and leaf-lists. >>=20 >> Can someone give an example of how that might look for a leaf-list ? = Is it >> just to indicate that there may be a system initialized member of the = leaf-list >> ? >=20 > Right; when the parent node is created, the system initializes one or > more members of the leaf-list. >=20 >=20 >> Was there any previous discussion about having the = initialized-by-system >> concept somehow applying to lists (i.e. indicating that the system = might >> initialize some list instances/entries)? >=20 > IIRC everyone agreed that this was not needed. Unclear use cases, and > unclear how it would work. >=20 >> For example -> the network element >> (server) may automatically add an interface called "system" or a user = called >> "admin" during startup. >=20 > This is already possible today. Most systems come with some kind of > factory default config. When a client connects the very first time, > it cannot assume that the config is empty. I think the first part is more about system-controlled interfaces (see = RFC 7223, sec. 1.1) - that is, the =93system=94 interface would be = initialized in operational state but won=92t initially appear in = configuration. Lada >=20 >> The initialized-by-system could perhaps be indicated >> at the list level to at least indicate that there may be system = initialized >> list entries (i.e. to prompt the client to to see them). >>=20 >> I'm also interested in the note that says "A similar issue: passwd of = type >> crypt-hash.". I'd like to see what the intended use case is behind = that >> sentence (I'm hoping it might help me with an issue we have that = sounds >> similar). >=20 > If a clear-text value is written to a node of type crypt-hash, the > server calculates the hash and stores the hash value instead of the > clear text value. This is not the same as initialized-by system, but > similar. >=20 >=20 > /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 10 01:02:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60EE51A067C for ; Wed, 10 Sep 2014 01:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hjGipqY0nFlq for ; Wed, 10 Sep 2014 01:02:48 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBD281A0679 for ; Wed, 10 Sep 2014 01:02:47 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-c4-541005a5059a Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 19.81.21432.5A500145; Wed, 10 Sep 2014 10:02:45 +0200 (CEST) Received: from [159.107.197.75] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.3.174.1; Wed, 10 Sep 2014 10:02:45 +0200 Message-ID: <541005A4.50209@ericsson.com> Date: Wed, 10 Sep 2014 10:02:44 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Martin Bjorklund , References: <20140909.224005.02423221.mbj@tail-f.com> In-Reply-To: <20140909.224005.02423221.mbj@tail-f.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM+Jvje5SVoEQg+/LrSyeLdjMaNHd/Yzd Yv7FRlYHZo/WZ3tZPZYs+cnksfHXYpYA5igum5TUnMyy1CJ9uwSujOOzV7AXLOSsaDs6k7GB sZ+9i5GTQ0LAROLNm/8sELaYxIV769m6GLk4hASOMkq0NZ9nh3DWMEpcWPeHEaSKV0BTYnHf EzYQm0VAVeL1xTlg3WwCRhJT+8+D2aICURJ3LvWzQtQLSpyc+QQozsEhIuAh8bTTBCTMLCAq sf7iJSYQW1jASqLh0XdWiF1tjBKrnx1nBklwCphJPPn7nAWiwVbiwpzrULa8xPa3c8BqhAQ0 JB5e+Ms6gVFwFpJ1s5C0zELSsoCReRWjaHFqcVJuupGRXmpRZnJxcX6eXl5qySZGYBAf3PLb YAfjy+eOhxgFOBiVeHgXbOAPEWJNLCuuzD3EKM3BoiTOu/DcvGAhgfTEktTs1NSC1KL4otKc 1OJDjEwcnFINjHKS88zVV0++EvhxhZhmyjIbQ1G7Q5VXHri62V3/VdT/1XdSxOS1f9znCCY/ UrvC4D+TSyFlbhSbVuy8hyLJs0qspUR1IwWLO/dYHDi2+2rwwq4PEUf7LuTFMzQfbz3Ys/3O lfZF6/Perffv3dHyu9RhckO7cSbb6ZfXdq96slPynUFt2hm7k0osxRmJhlrMRcWJAOwqe5ZD AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/f-ulDF2YcvrrNaDDX8sUvtOn_X8 Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 08:02:49 -0000 Hello, IMHO initialized by system would be just as useful for lists as well. In Ericsson a big number of lists (managed objects) are created by the system. It is usually forbidden to remove these system created lists, but sometimes allowed. We also have such items under user created lists: if the user creates the upper level list, then the system will automatically create the lower level ones. E.g. HW can be detected by the system and the relevant list-entries created, while some leafs for the HW will be user settable. Why doesn't this apply to candidate? regards Balazs On 2014-09-09 22:40, Martin Bjorklund wrote: >> Was there any previous discussion about having the initialized-by-system >> concept somehow applying to lists (i.e. indicating that the system might >> initialize some list instances/entries)? > IIRC everyone agreed that this was not needed. Unclear use cases, and > unclear how it would work. > > /martin -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Wed Sep 10 01:32:43 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8003F1A0694 for ; Wed, 10 Sep 2014 01:32:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 8tNSVJcRp0T7 for ; Wed, 10 Sep 2014 01:32:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A714E1A01F2 for ; Wed, 10 Sep 2014 01:32:40 -0700 (PDT) Received: from ladislavs-air-2.labs.office.nic.cz (unknown [172.20.6.99]) by mail.nic.cz (Postfix) with ESMTPSA id D96BF13FBD3; Wed, 10 Sep 2014 10:32:36 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410337957; bh=5IzpbnR3OIKeGutIz8Q7EwLGG7upfOUJG7i/vmQHwpk=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=lgFNgZEkOhF/SVMSRBkI3Z0uEWIiiHxr9/lT9ws9awoQgMU+rZ8WdgW2DUpJeMe47 g5uQV1ltll/foYOKOOvBtnP/u1yZXGRtZjgb9a5I/a4Yr1R9W1in2411TrwSDZqsxZ YlawS/TmLD+VbUN8oD5dcVyw+AFAODy4iHPwJK0o= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <541005A4.50209@ericsson.com> Date: Wed, 10 Sep 2014 10:32:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <9D8CC12B-E4CE-4A4E-9830-D7B372FF7F47@nic.cz> References: <20140909.224005.02423221.mbj@tail-f.com> <541005A4.50209@ericsson.com> To: Balazs Lengyel X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kZVbOYGSRGvqwj610AZB_PKwufI Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 08:32:42 -0000 On 10 Sep 2014, at 10:02, Balazs Lengyel = wrote: > Hello, > IMHO initialized by system would be just as useful for lists as well. >=20 > In Ericsson a big number of lists (managed objects) are created by the = system. It is usually forbidden to remove these system created lists, = but sometimes allowed. If it is forbidden, then it really looks like system-controlled list = entries: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15#section-4.1 I think that letting the system (perhaps on behalf of other protocols = like DHCP or HNCP) write to NETCONF datastores should not be considered = normal. What if the datastore is locked when the write is supposed to = happen? That=92s also why I think we need to develop the concept of a separate = operational datastore. The system could write there anytime without = interfering with NETCONF datastores. > We also have such items under user created lists: if the user creates = the upper level list, then the system will automatically create the = lower level ones. > E.g. HW can be detected by the system and the relevant list-entries = created, while some leafs for the HW will be user settable. All this is covered by system-controlled list entries. >=20 > Why doesn't this apply to candidate? Actually, yes. If the system writes something only into running, then = the client who happens to be editing candidate may not be able to = perform commit anymore due to restricted access to the system-written = data. Lada > regards Balazs >=20 >=20 > On 2014-09-09 22:40, Martin Bjorklund wrote: >>> Was there any previous discussion about having the = initialized-by-system >>> concept somehow applying to lists (i.e. indicating that the system = might >>> initialize some list instances/entries)? >> IIRC everyone agreed that this was not needed. Unclear use cases, = and >> unclear how it would work. >>=20 >> /martin >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 10 02:21:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E1531A06C2 for ; Wed, 10 Sep 2014 02:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 9O5XyMR_l6ti for ; Wed, 10 Sep 2014 02:21:09 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5061A06C1 for ; Wed, 10 Sep 2014 02:21:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12012; q=dns/txt; s=iport; t=1410340870; x=1411550470; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=bS+3wGIO04Xi/ioFEcrfxBGrPqY/6oGu2vPOv0xGxQI=; b=cODxjqy8PQw3rqRWmLCYe+inZuRdOx+Puulyp42ieUL6dC1YXdnlKD6k axd4SD4zFh4jjOa7SEYm4m6eSxYoxEAbj9Q4MHkDbs1Z0B4q+co2M6zqP 4gOEWP0vQiopcm3uoluJK4wigHADDsuP3+gE7ABLBCDLH+RfjHwMqTqLe U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Am8FALMWEFStJssW/2dsb2JhbABZg2BXgnyFW8FXh0oBgSF4hAMBAQEEI1UBEAsRAwECAQkWCAMCAgkDAgECAQ8lCQgGDQEFAgEBBYglAxENqByOWA2GOQEXjSCBSxEBPxEHBoJzgVMFlXGEcoIQgV+FYocyhjuDYzsvAYEOgUABAQE X-IronPort-AV: E=Sophos;i="5.04,497,1406592000"; d="scan'208,217";a="172810334" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 10 Sep 2014 09:21:07 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id s8A9L6j1007252; Wed, 10 Sep 2014 09:21:06 GMT Message-ID: <54101802.5060507@cisco.com> Date: Wed, 10 Sep 2014 11:21:06 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Chris Lonvick , "Lange, Jeffrey K (GE Energy Management)" References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020004050500020909000007" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/PTSKaGPKxoW52yL4le2fWOPBpJ0 Cc: "rgerhards@hq.adiscon.com" , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 09:21:14 -0000 This is a multi-part message in MIME format. --------------020004050500020909000007 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Dear all, As I understand, the conclusion from this email thread is that the syslog YANG model must support the options for RFC 5424, RFC 5425, and RFC 5426 Regards, Benoit > Hi, > The very brief background: > - the syslog WG was chartered under the Security Area to secure the > protocol > - the BEEP work never took off so we rechartered and found that we > needed to make changes to the protocol itself > - in making the changes, Rainer Gerhards proposed structured data and > the WG liked that > - 5424 makes use of structured data but there are few implementations > that strictly adhere to the changes made to the packet header > > On the other hand, everyone likes structured data and I've seen it > used in many places. As far as I know, there have been no efforts to > standardize structured data but people are using it in many places > because it is very versatile and efficient, and it gets the job done. :-) > > I've been working (off and on and hopefully more 'on' soon) on an ID > that explains how non-standardized messages have been conveyed in > IETF-documented protocols. It will need a couple of more revisions > before it's ready for consideration for publication but you may get > some ideas from it. > https://datatracker.ietf.org/doc/draft-lonvick-private-tax/?include_text=1 > > Best regards, > Chris > > > On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy > Management) > > wrote: > > Benoit, > We (GE MDS) support 5424/5425/5426 structured messages on our > products (with vendor specific structured-data). > > -Jeff Lange > > > > From: Benoit Claise >> > Date: Wednesday, July 30, 2014 at 11:21 AM > To: Jeffrey Haas >> > Cc: "lonvick@gmail.com > >" >>, Kiran Agrahara Sreenivasa > >>, "netmod@ietf.org > >" >>, "rgerhards@hq.adiscon.com > >" >> > Subject: Re: [netmod] Syslog YANG Model Presentation > > Jeff, > > Thanks. > So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 > configuration in the YANG model, right? > You use only vendor specific STRUCTURED-DATA? Because I don't see > many in the IANA > registry, > and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA > registration. > > If my memory serves me well (I copied a couple of old timers), the > STRUCTURED-DATA goal was to standardize the syslog message content > in the industry, but that did not happen. > > Regards, Benoit > > Benoit, > > On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: > > > PS: I think you should also refer to the standards-track version of > SYSLOG (RFC 5424) in the references and perhaps filters should > also be able to operate on structured content. > > > Is RFC 5424 actually deployed? > > > Juniper has supported it for years. > > -- Jeff > . > > > > --------------020004050500020909000007 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Dear all,

As I understand, the conclusion from this email thread is that the syslog YANG model must support the options for RFC 5424, RFC 5425, and RFC 5426

Regards, Benoit
Hi,
The very brief background:
- the syslog WG was chartered under the Security Area to secure the protocol
- the BEEP work never took off so we rechartered and found that we needed to make changes to the protocol itself
- in making the changes, Rainer Gerhards proposed structured data and the WG liked that
- 5424 makes use of structured data but there are few implementations that strictly adhere to the changes made to the packet header

On the other hand, everyone likes structured data and I've seen it used in many places.  As far as I know, there have been no efforts to standardize structured data but people are using it in many places because it is very versatile and efficient, and it gets the job done.  :-)

I've been working (off and on and hopefully more 'on' soon) on an ID that explains how non-standardized messages have been conveyed in IETF-documented protocols.  It will need a couple of more revisions before it's ready for consideration for publication but you may get some ideas from it.

Best regards,
Chris


On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) <jeffrey.K.lange@ge.com> wrote:
Benoit,
  We (GE MDS) support 5424/5425/5426 structured messages on our products (with vendor specific structured-data).

-Jeff Lange



From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Date: Wednesday, July 30, 2014 at 11:21 AM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: "lonvick@gmail.com<mailto:lonvick@gmail.com>" <lonvick@gmail.com<mailto:lonvick@gmail.com>>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com<mailto:kkoushik@Brocade.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>>, "rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>" <rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>>
Subject: Re: [netmod] Syslog YANG Model Presentation

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many in the IANA registry<http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen.

Regards, Benoit

Benoit,

On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:


PS: I think you should also refer to the standards-track version of
    SYSLOG (RFC 5424) in the references and perhaps filters should
    also be able to operate on structured content.


Is RFC 5424 actually deployed?


Juniper has supported it for years.

-- Jeff
.





--------------020004050500020909000007-- From nobody Wed Sep 10 02:53:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FEBE1A06D3 for ; Wed, 10 Sep 2014 02:53:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 d0id67tPhST6 for ; Wed, 10 Sep 2014 02:52:58 -0700 (PDT) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E84241A06D7 for ; Wed, 10 Sep 2014 02:52:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8893; q=dns/txt; s=iport; t=1410342778; x=1411552378; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=n7fHNIquK7sd42oFFzOe2UneCQNkklMYyHZgaZf2GrM=; b=ETfgagARy3GhLIW/AGX6EHzdF5Z69B7rNChvKETZEumba8txOL+xIzs2 YOhVx8oZIkIEFuSymHS0qDEpGnjpmcSfoiS8qUkyN3A22+1IT101BjH6t ZpqqtC/dE1nkWPWnZYbj7zJeu7jTuJiSRLcfhuP/xeRqGjDVA7wXFW+Uq U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsQEANceEFStJssW/2dsb2JhbABZg2BXyiMKhnlTAYEieIQEAQEEAQEBLwEFLwcKEQsYCRYECwkDAgECARUwEwYCAQEXiCcNvUcBF40KgWELBgFXhEwBBJVxgQaFfIdBjW2CG4FIOy8BAQGBBAEHFwaBIwEBAQ X-IronPort-AV: E=Sophos;i="5.04,497,1406592000"; d="scan'208";a="172182978" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP; 10 Sep 2014 09:52:54 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8A9qsGD025723 for ; Wed, 10 Sep 2014 09:52:54 GMT Message-ID: <54101F76.1090504@cisco.com> Date: Wed, 10 Sep 2014 11:52:54 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: netmod@ietf.org References: <20140903111127.GA79883@elstar.local> <540819BB.6030906@cisco.com> <20140904080225.GB82785@elstar.local> In-Reply-To: <20140904080225.GB82785@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/X1E5xNNoJ9MVDGciB9cUYzovv2E Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 09:53:00 -0000 Hi Jürgen, > Benoit, > > I believe sufficient details are recorded in the minutes. Please take > a look at the minutes and let me know if I am wrong. > > I am already spending _significant_ amount of time on issue tracking, > taking notes, editing of minutes, seeking confirmation for every step > on the mailing list, handling the other process requirements (meeting > allocations, minute submission to the secretariat, etc) and I am > reaching a limit. If even more documentation is required, I can't do > it anymore alone. You work is very much appreciated. Believe me. And I can see how much time you dedicate to NETMOD. Thanks. However, it's not because you are the chair that you have to do everything yourself. What I had in mind is some sort of collaborative effort. For example, different people inserted their issue at http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html. Those people could be responsible to update and document their respective issuess. For example, during the webex calls, writing meeting minutes with a tool such as etherpad, so that everybody could collaborate on writing those minutes. Regards, Benoit > > /js > > On Thu, Sep 04, 2014 at 09:50:19AM +0200, Benoit Claise wrote: >> Jürgen, WG, >> >> I like the way the interim meetings are run. This brings speed to the >> process. Thanks. >> >> However, let me repeat a statement I made a few times. >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html (or >> whatever support), must also document the rational for selecting a >> specific solution. >> Something like: >> solution 1 was rejected because of reason 1, 2, and 3 >> the issue could be addressed with both solutions 1 and 2 >> current implementations don't use the feature this way >> solution 2 is easier from an implementation point of view because ... >> in conclusion, solution 2 is plebiscited by the WG >> >> What's the reasoning ? >> We don't want to redo the discussions over and over. >> Following RFC 7282, how can we say to a new participant in the WG: "We >> hear you. This argument was discussed, and the consensus was ... Do you >> have another argument in favor of a different solution? Basically, have >> we overlooked anything?" >> Without some documentation, this is not possible. >> >> Regards, Benoit >> >> >>> Hi, >>> >>> we managed to go over all issues except those issues that we will be >>> disussing during the face-to-face interim meeting. This email provides >>> a summary of where we are with the issues not marked DEAD. I am also >>> including actions that need to be carried out. >>> >>> If you disagree with any of the following proposed resolutions, please >>> speak up as soon as possible but no later than September 16 (so that >>> we have the input before the face-to-face interim meeting starts). If >>> you want to raise a concern, please start a threat with the issue >>> identifier in the subject line. >>> >>> * OPEN :Y01: allow boolean if-feature >>> >>> 2014-06-11 meeting proposal: adopt Y01-01. >>> >>> * OPEN :Y02: allow must in input, output, and notification >>> >>> 2014-06-11 meeting proposal: adopt Y02-01. >>> >>> * OPEN :Y03: allow if-feature in refine >>> >>> 2014-06-11 meeting proposal: adopt Y03-01. >>> >>> * OPEN :Y04: accessible tree in xpath in notifs and rpc >>> >>> 2014-06-11 meeting proposal: adopt Y04-02. >>> >>> * OPEN :Y05: unprefixed path in top-level typedef >>> >>> 2014-06-11 meeting action: MB to write down solution Y05-03 and once >>> done we get back to this issue. >>> >>> * OPEN :Y06: escaped characters in double quoted strings >>> >>> 2014-06-11 meeting proposal: adopt Y06-02. >>> >>> * OPEN :Y07: do not allow when or if-feature on keys >>> >>> 2014-07-02 meeting proposal: adopt Y07-01 with a clarification about >>> the condition >>> >>> * OPEN :Y09: introduce optional keys <> >>> >>> 2014-07-02 meeting action: MB to write up a solution proposal and >>> once done we get back to this issue. >>> >>> * OPEN :Y10: allow restrictions on enumerations >>> >>> 2014-07-02 meeting action: LL to write down another syntax proposal >>> and MB to expand Y10-01. >>> >>> * OPEN :Y11: allow if-feature on enums >>> >>> 2014-07-02 meeting proposal: Adopt Y11-01 with the extension to >>> allow if-feature also for bits and identities. >>> >>> * OPEN :Y12: initialized-by system >>> >>> 2014-07-02 meeting proposal: Adopt Y12-01 but think about a better >>> syntax. Applies to leaf and leaf-lists. MB to create concrete text. >>> >>> * OPEN :Y13: allow multiple inheritance for identities >>> >>> 2014-07-02 meeting action: LL to write a more complete example and >>> once done we get back to this issue. >>> >>> * OPEN :Y14: clarify the string value for identities when used in must/when >>> >>> 2014-07-02 meeting proposal: adopt Y14-01. >>> >>> * OPEN :Y16: module advertisement optimization >>> >>> 2014-07-02 meeting action: MB to look at the details whether Y16-02 >>> can be made to work. >>> >>> * OPEN :Y18: fix "when" expression context node problem >>> >>> 2014-07-02 meeting action: LL to write up an example in which >>> situations Y18-01 is problematic. >>> >>> * OPEN :Y20: new set of built-in XPath functions >>> >>> 2014-07-09 meeting proposal: MB to copy the functions he proposed to >>> RFC 6020bis as a starting point and then we review and discuss >>> changes. >>> >>> * OPEN :Y23: support negative patterns as string restrictions >>> >>> 2014-07-09 meeting proposal: adopt Y23-02. >>> >>> * OPEN :Y25: make enum numbering purely informative and optional >>> >>> 2014-07-09 meeting proposal: adopt Y25-01. >>> >>> * OPEN :Y26: allow mandatory nodes in augment >>> >>> 2014-07-09 meeting action: There is agreement that the current text >>> is overly restrictive. The proposal is to add general guiding rules >>> that backwards compatibility needs to be maintained. Lets see >>> whether someone can write more concrete rules when mandatory nodes >>> in augment are allowed. >>> >>> * OPEN :Y27: allow mandatory nodes in an updated module >>> >>> 2014-07-09 meeting proposal: close Y27 by moving it to DEAD. AB to >>> check what the feature issue is about, possible action to add >>> guidelines how to go from current to deprecated to obsolete in RFC >>> 6087bis. >>> >>> * OPEN :Y28: support default values in leaf-lists >>> >>> 2014-07-09 meeting action: AB will look at the necessary text and >>> what it means to modify leaf-list values. Perhaps there is a need to >>> have a different keyword since the behavior is rather different >>> here. >>> >>> * OPEN :Y29: allow choice as a short-hand case >>> >>> 2014-07-09 meeting proposal: adopt Y29-01 >>> >>> * OPEN :Y30: allow leafref in union >>> >>> 2014-07-21 meeting proposal: adopt Y30-01, clarify existence >>> constraints and impact on union member selection, see 2014-07-09 >>> meeting minutes. Followup on Lada's issue concerning unions as keys. >>> >>> * OPEN :Y31: allow require-instance in leafref >>> >>> 2014-07-21 meeting proposal: adopt Y31-01. >>> >>> * OPEN :Y34: remove/deprecate/replace the 'anyxml' statement >>> >>> 2014-07-21 meeting proposal and action: adopt Y34-02, AB to work out >>> a concrete proposal. >>> >>> * OPEN :Y35: allow empty in union >>> >>> 2014-07-21 meeting proposal: adopt Y35-01. >>> >>> * OPEN :Y41: clarification of "must" in NP-container >>> >>> 2014-07-21 meeting proposal: Clarify that for validation purposes, >>> NP containers always exist. >>> >>> * OPEN :Y42: a better model for configuration versus state data is needed >>> >>> postponed to the face-to-face interim meeting >>> >>> * OPEN :Y44: add a mechanism to parameterize error-message >>> >>> 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. >>> >>> * OPEN :Y45: better conformance mechanism >>> >>> postponed to the face-to-face interim meeting >>> >>> * OPEN :Y47: bit name too restrictive >>> >>> 2014-08-27 meeting proposal: close Y44 by moving it to DEAD. >>> >>> * OPEN :Y49: clarify nested submodule behavior >>> >>> 2014-08-27 meeting action: MB to writeup solution proposal Y49-03. >>> >>> * OPEN :Y54: remove the advertisement of conformance information in >>> NETCONF hello >>> >>> postponed to the face-to-face interim meeting >>> >>> * NEW :Y55: clarify type in union >>> >>> 2014-08-27 meeting proposal: OPEN Y55 and adopt Y55-01. >>> >>> /js >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Sep 10 03:06:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09D181A06E6 for ; Wed, 10 Sep 2014 03:06:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 JhbqLWPiFdnh for ; Wed, 10 Sep 2014 03:06:49 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 692531A06DA for ; Wed, 10 Sep 2014 03:06:49 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 2E6741280402; Wed, 10 Sep 2014 12:06:48 +0200 (CEST) Date: Wed, 10 Sep 2014 12:06:48 +0200 (CEST) Message-Id: <20140910.120648.786697533378668566.mbj@tail-f.com> To: bclaise@cisco.com From: Martin Bjorklund In-Reply-To: <54101F76.1090504@cisco.com> References: <540819BB.6030906@cisco.com> <20140904080225.GB82785@elstar.local> <54101F76.1090504@cisco.com> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/h24B06RUrnqm6-1vEs4h5Oqn-u0 Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 10:06:51 -0000 Benoit Claise wrote: > Hi J=FCrgen, > > Benoit, > > > > I believe sufficient details are recorded in the minutes. Please ta= ke > > a look at the minutes and let me know if I am wrong. > > > > I am already spending _significant_ amount of time on issue trackin= g, > > taking notes, editing of minutes, seeking confirmation for every st= ep > > on the mailing list, handling the other process requirements (meeti= ng > > allocations, minute submission to the secretariat, etc) and I am > > reaching a limit. If even more documentation is required, I can't d= o > > it anymore alone. > You work is very much appreciated. Believe me. And I can see how much= > time you dedicate to NETMOD. Thanks. > = > However, it's not because you are the chair that you have to do > everything yourself. > What I had in mind is some sort of collaborative effort. > For example, different people inserted their issue at > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html. Those > people could be responsible to update and document their respective > issuess. I feel kind of responsible for this list, and my plan has been to update the issues with the resolution and relevant discussion. This is still my plan ;) I view this as part of the editorial task of making sure we cover everything in the document itself. /martin From nobody Wed Sep 10 03:31:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFBD1A0709 for ; Wed, 10 Sep 2014 03:31:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 1Ljr__jYW6ev for ; Wed, 10 Sep 2014 03:31:30 -0700 (PDT) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C6611A0678 for ; Wed, 10 Sep 2014 03:31:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1428; q=dns/txt; s=iport; t=1410345090; x=1411554690; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=dV+vL3wXVtbCnvvm4VBXhGQgITxd/q7fkeuXXaR/5eI=; b=MCfx9J8YN9AtVn23+SWxWR24ezeEAPb/94AQUc6aqbYOpJJh2gks+o7T V0Iuovy7dpa631SoHZTajJXietglQlX/vXI2Ke2VD5Gk1dT+2qgYXKzZb ZMlM2B2g6wEaPTFXJdMK1wvDulpWFwtNzXun91me4nHx9895WPOgKXIWV A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsIEAMMnEFStJssW/2dsb2JhbABZg2BXyi6HTAGBIniEBAEBBDIBBTYKARALDgoJFgQLCQMCAQIBRQYNAQUCAQGIPg29RAEXjQqBbFcHhEwBBI8shkWHAodBjW2CG4FIOy8BAQGBBIFIAQEB X-IronPort-AV: E=Sophos;i="5.04,498,1406592000"; d="scan'208";a="168136404" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP; 10 Sep 2014 10:31:27 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id s8AAVRNe012153; Wed, 10 Sep 2014 10:31:27 GMT Message-ID: <5410287E.4060002@cisco.com> Date: Wed, 10 Sep 2014 12:31:26 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Martin Bjorklund References: <540819BB.6030906@cisco.com> <20140904080225.GB82785@elstar.local> <54101F76.1090504@cisco.com> <20140910.120648.786697533378668566.mbj@tail-f.com> In-Reply-To: <20140910.120648.786697533378668566.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DHGkuf-YNczOutyBtZSbqHhr-9U Cc: netmod@ietf.org Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Sep 2014 10:31:32 -0000 Thank you Martin. Regards, Benoit > Benoit Claise wrote: >> Hi Jürgen, >>> Benoit, >>> >>> I believe sufficient details are recorded in the minutes. Please take >>> a look at the minutes and let me know if I am wrong. >>> >>> I am already spending _significant_ amount of time on issue tracking, >>> taking notes, editing of minutes, seeking confirmation for every step >>> on the mailing list, handling the other process requirements (meeting >>> allocations, minute submission to the secretariat, etc) and I am >>> reaching a limit. If even more documentation is required, I can't do >>> it anymore alone. >> You work is very much appreciated. Believe me. And I can see how much >> time you dedicate to NETMOD. Thanks. >> >> However, it's not because you are the chair that you have to do >> everything yourself. >> What I had in mind is some sort of collaborative effort. >> For example, different people inserted their issue at >> http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html. Those >> people could be responsible to update and document their respective >> issuess. > I feel kind of responsible for this list, and my plan has been to > update the issues with the resolution and relevant discussion. This > is still my plan ;) I view this as part of the editorial task of > making sure we cover everything in the document itself. > > > /martin > . > From nobody Wed Sep 10 17:54:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12EFD1A01A5 for ; Wed, 10 Sep 2014 17:54:24 -0700 (PDT) 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 vwRNgdDhY-zP for ; Wed, 10 Sep 2014 17:54:20 -0700 (PDT) Received: from mail-qg0-x22a.google.com (mail-qg0-x22a.google.com [IPv6:2607:f8b0:400d:c04::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3CE591A01C3 for ; Wed, 10 Sep 2014 17:54:20 -0700 (PDT) Received: by mail-qg0-f42.google.com with SMTP id q107so10204469qgd.15 for ; Wed, 10 Sep 2014 17:54:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=kDHGfQplUYlI/amRd/f1fwWV9DqlpqnivqyqvIWTL7A=; b=hgB5fWxqTF7aFwzcdr7Zc97rg07gDdErkoWCyJRrWyRAfd6uikeLNBPi0VRxvUd0TZ zwzur5Zj9qVEg5mivkxGStuplfJ7VVzqLIiSMvvI3yiz7tnERFh/hGlfaIRE60ayZ8hW 5cuXNWB9eZzZe6xxkg+yYOTBHKeCN6XH78ROCRtP7WEFRRSywQnGa3p3Yp4j95/LceOI Y1tQvda/Ytzy6Lt0WWEryH6piaq3PdO1z/ZDpJwBg2Hi/sPphCQqwhUNEsM4BBuh4aVZ L7JMWTIxGZN5meT0XMmiFUKpXr383ljbQQfEdZDdP8Rf4/iJ/QvKDxhnYmtUTUI9brd8 cKpA== MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr33686599qam.88.1410396859412; Wed, 10 Sep 2014 17:54:19 -0700 (PDT) Received: by 10.229.171.9 with HTTP; Wed, 10 Sep 2014 17:54:19 -0700 (PDT) In-Reply-To: <54101802.5060507@cisco.com> References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> <54101802.5060507@cisco.com> Date: Wed, 10 Sep 2014 17:54:19 -0700 Message-ID: From: Chris Lonvick To: Benoit Claise Content-Type: multipart/alternative; boundary=001a11c2bbc0cc36f50502bf9be1 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zf3-vUl-2GbIPgFMPiSyM269CBA Cc: "rgerhards@hq.adiscon.com" , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 00:54:24 -0000 --001a11c2bbc0cc36f50502bf9be1 Content-Type: text/plain; charset=UTF-8 Hi Benoit and all, I'm not exactly sure what you're asking. I agree with Rainer that the ID is well written. I am not subscribed to the mailing list and have not been following the discussions so please take my comments with a grain of salt. :-) If you're asking if draft-wildes-netmod-syslog-model needs to be expanded to include the available options resulting from the IETF work on syslog (which is more than 5424, 5425, and 5426), then I would say that it does not. It looks to me (I'm not overly familiar with Yang) that what is described in the ID is equivalent to what can be defined in a current syslog.conf configuration. IMHO, that should be good enough at this time to publish the document as an informational RFC (as it's classified now). If you're asking if a potential draft-ietf-netmod-syslog-model (standards track) should be more thorough to include the available options resulting from the IETF work on syslog, then I'll give a definite "maybe". :-) There doesn't appear to be anything in draft-wildes... that conflicts with the syslog HEADER in 5424; therefore, it should just work. The Structured-Data is used in the PAYLOAD and that can't be configured. What would be missing in the configuration is the specification of the transport. You mention 5425 and 5426, but there are others: 5425 - TLS (recommended) 5426 - UDP (not so much recommended but greatly in use) 6012 - DTLS 6587 - TCP (the IESG said to NOT use this, but it is in use :-) If the document were to be expanded, it would need to include some very complex rules. For example: - Facilities 4 and 10 with severities (0-6) send to sec-logger.example.com via 5425 - Facility 2 with severities (0-3) send to mail-logger.example.com via 5426 - All Facilities with severities (0-2) send to central-logger.example.com via 6012 As far as I know, the specification of the transport cannot currently be configured in generic syslog.conf configurations. I believe that the implementations that are using something other than UDP are doing it on a "one off" basis. So, IMHO, trying to force that into a standards track document shouldn't be done at this time. If you _are_ looking for draft-ietf-netmod-syslog-model, I would suggest using draft-wildes... and add something about assuming that the selection of a transport is implementation specific at this time, and that a future revision of the model may include the option to specify the transport(s). And just since I'm going on and on (and on...), the syslog WG did not complete a MIB on syslog. If anyone is interested, we left off here: http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 Just a nit to the authors, the last sentence of page 3 reads: Optional features are used to specified fields that are not present in all vendor configurations. Perhaps s/specified/specify (but honestly I think that the sentence needs to be rewritten). And, if I'm totally off base on what you're asking, then please disregard. :-) Best regards, Chris On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise wrote: > Dear all, > > As I understand, the conclusion from this email thread is that the syslog > YANG model must support the options for RFC 5424, RFC 5425, and RFC 5426 > > Regards, Benoit > > Hi, > The very brief background: > - the syslog WG was chartered under the Security Area to secure the > protocol > - the BEEP work never took off so we rechartered and found that we needed > to make changes to the protocol itself > - in making the changes, Rainer Gerhards proposed structured data and the > WG liked that > - 5424 makes use of structured data but there are few implementations that > strictly adhere to the changes made to the packet header > > On the other hand, everyone likes structured data and I've seen it used > in many places. As far as I know, there have been no efforts to > standardize structured data but people are using it in many places because > it is very versatile and efficient, and it gets the job done. :-) > > I've been working (off and on and hopefully more 'on' soon) on an ID > that explains how non-standardized messages have been conveyed in > IETF-documented protocols. It will need a couple of more revisions before > it's ready for consideration for publication but you may get some ideas > from it. > > https://datatracker.ietf.org/doc/draft-lonvick-private-tax/?include_text=1 > > Best regards, > Chris > > > On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) < > jeffrey.K.lange@ge.com> wrote: > >> Benoit, >> We (GE MDS) support 5424/5425/5426 structured messages on our products >> (with vendor specific structured-data). >> >> -Jeff Lange >> >> >> >> From: Benoit Claise > >> Date: Wednesday, July 30, 2014 at 11:21 AM >> To: Jeffrey Haas > >> Cc: "lonvick@gmail.com" > >, Kiran Agrahara Sreenivasa < >> kkoushik@Brocade.com>, "netmod@ietf.org >> " >, " >> rgerhards@hq.adiscon.com" < >> rgerhards@hq.adiscon.com> >> Subject: Re: [netmod] Syslog YANG Model Presentation >> >> Jeff, >> >> Thanks. >> So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 >> configuration in the YANG model, right? >> You use only vendor specific STRUCTURED-DATA? Because I don't see many in >> the IANA registry< >> http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, >> and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA >> registration. >> >> If my memory serves me well (I copied a couple of old timers), the >> STRUCTURED-DATA goal was to standardize the syslog message content in the >> industry, but that did not happen. >> >> Regards, Benoit >> >> Benoit, >> >> On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: >> >> >> PS: I think you should also refer to the standards-track version of >> SYSLOG (RFC 5424) in the references and perhaps filters should >> also be able to operate on structured content. >> >> >> Is RFC 5424 actually deployed? >> >> >> Juniper has supported it for years. >> >> -- Jeff >> . >> >> >> >> > > --001a11c2bbc0cc36f50502bf9be1 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Benoit and all,

I'm not exactly = sure what you're asking. =C2=A0I agree with Rainer that the ID is well = written.

I am not subscribed to the mailing list a= nd have not been following the discussions so please take my comments with = a grain of salt. =C2=A0:-)

If you're asking if= =C2=A0draft-wildes-netmod-syslog-model needs to be expanded to include the = available options resulting from the IETF work on syslog (which is more tha= n 5424, 5425, and 5426), then I would say that it does not. =C2=A0It looks = to me (I'm not overly familiar with Yang) that what is described in the= ID is equivalent to what can be defined in a current syslog.conf configura= tion. =C2=A0IMHO, that should be good enough at this time to publish the do= cument as an informational RFC (as it's classified now).

=
If you're asking if a potential draft-ietf-netmod-syslog-mod= el (standards track) should be more thorough to include the available optio= ns resulting from the IETF work on syslog, then I'll give a definite &q= uot;maybe". =C2=A0:-) =C2=A0There doesn't appear to be anything in= draft-wildes... that conflicts with the syslog HEADER in 5424; therefore, = it should just work. =C2=A0The Structured-Data is used in the PAYLOAD and t= hat can't be configured. =C2=A0What would be missing in the configurati= on is the specification of the transport. =C2=A0You mention 5425 and 5426, = but there are others:
5425 - TLS (recommended)
5426 - U= DP (not so much recommended but greatly in use)
6012 - DTLS
=
6587 - TCP (the IESG said to NOT use this, but it is in use :-)
<= div>If the document were to be expanded, it would need to include some very= complex rules. =C2=A0For example:
=C2=A0- Facilities 4 and 10 wi= th severities (0-6) send to sec-l= ogger.example.com via 5425
=C2=A0- Facility 2 with severities= (0-3) send to mail-logger.examp= le.com via 5426
=C2=A0- All Facilities with severities (0-2) = send to central-logger.exampl= e.com via 6012
As far as I know, the specification of the tra= nsport cannot currently be configured in generic syslog.conf configurations= . =C2=A0I believe that the implementations that are using something other t= han UDP are doing it on a "one off" basis. =C2=A0So, IMHO, trying= to force that into a standards track document shouldn't be done at thi= s time.

If you _are_ looking for draft-ietf-netmod= -syslog-model, I would suggest using draft-wildes... and add something abou= t assuming that the selection of a transport is implementation specific at = this time, and that a future revision of the model may include the option t= o specify the transport(s).

And just since I'm= going on and on (and on...), the syslog WG did not complete a MIB on syslo= g. =C2=A0If anyone is interested, we left off here:

Just a nit to the authors, the last sentence of page 3 reads:
<= pre>Optional features are used to specified fields that are not present in= =20 all vendor configurations.
Perhaps s/specified/specify (but honestly I think that=
 the sentence needs to be rewritten).

And, if I'm totally off base =
on what you're asking, then please disregard. =C2=A0:-)

Best regards,= 
Chris

On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise <bclaise@cisco.com>= ; wrote:
=20 =20 =20
Dear all,

As I understand, the conclusion from this email thread is that the syslog YANG model must support the options for RFC 5424, RFC 5425, and RFC 5426

Regards, Benoit
=20
Hi,
The very brief background:
- the syslog WG was chartered under the Security Area to secure the protocol
- the BEEP work never took off so we rechartered and found that we needed to make changes to the protocol itself
- in making the changes, Rainer Gerhards proposed structured data and the WG liked that
- 5424 makes use of structured data but there are few implementations that strictly adhere to the changes made to the packet header

On the other hand, everyone likes structured data and I've seen it used in many places. =C2=A0As far as I know, there have been no efforts to standardize structured data but people are using it in many places because it is very versatile and efficient, and it gets the job done. =C2=A0:-)

I've been working (off and on and hopefully more 'on&#= 39; soon) on an ID that explains how non-standardized messages have been conveyed in IETF-documented protocols. =C2=A0It will need a coupl= e of more revisions before it's ready for consideration for publication but you may get some ideas from it.

Best regards,
Chris


On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) <<= a href=3D"mailto:jeffrey.K.lange@ge.com" target=3D"_blank">jeffrey.K.lange@= ge.com> wrote:
Benoit,
=C2=A0 We (GE MDS) support 5424/5425/5426 structured messages on our products (with vendor specific structured-data).

-Jeff Lange



From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Date: Wednesday, July 30, 2014 at 11:21 AM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: "lonvick@gmail.com<mailto:lonvick@gmail.com>" <lo= nvick@gmail.com<mailto:lonvick@gmail.com>>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com<mailto:kkoushik@Brocade.com>>, "ne= tmod@ietf.org<mailto:netmod@ietf.org>" <netm= od@ietf.org<mailto:netmod@ietf.org>>, "rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>" <rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>>
Subject: Re: [netmod] Syslog YANG Model Presentation

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many in the IANA registry<http://www.iana.org/assignments/syslog-param= eters/syslog-parameters.xhtml#syslog-parameters-4>, and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen.

Regards, Benoit

Benoit,

On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:


PS: I think you should also refer to the standards-track version of
=C2=A0 =C2=A0 SYSLOG (RFC 5424) in the references and perhaps filters should
=C2=A0 =C2=A0 also be able to operate on structured content.<= br>

Is RFC 5424 actually deployed?


Juniper has supported it for years.

-- Jeff
.






--001a11c2bbc0cc36f50502bf9be1-- From nobody Thu Sep 11 00:57:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 939F71A8754 for ; Thu, 11 Sep 2014 00:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.602 X-Spam-Level: X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_34=0.6, RP_MATCHES_RCVD=-1.652] 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 fcq0jXzZjZq7 for ; Thu, 11 Sep 2014 00:57:28 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6B6B31A0645 for ; Thu, 11 Sep 2014 00:57:28 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0CC27120F; Thu, 11 Sep 2014 09:57:27 +0200 (CEST) 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 XBQSj_8TMzW2; Thu, 11 Sep 2014 09:57:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 11 Sep 2014 09:57:21 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C072B2003F; Thu, 11 Sep 2014 09:56:08 +0200 (CEST) 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 pgI_ofev-F-w; Thu, 11 Sep 2014 09:56:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7841020036; Thu, 11 Sep 2014 09:56:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 90D002E61E31; Thu, 11 Sep 2014 09:56:05 +0200 (CEST) Date: Thu, 11 Sep 2014 09:56:04 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140911075604.GA2241@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , Ladislav Lhotka , "netmod@ietf.org" References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IY80o0RzsV_M6NX8VYBTAbQtb10 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 07:57:30 -0000 On Wed, Sep 03, 2014 at 10:27:20AM -0700, Andy Bierman wrote: > Solution Y34-04: > > * Consider a new statement called "root" that provides the ncx:root > semantics. > There may be restrictions on its use (i.e., may not be full > data-def-stmt) > > root config { > description "Container of top-level YANG data nodes representing the > configuration"; > } > > * For YANG 1.0 backward compatibility, allow anyxml to be used, > except implementations MAY restrict the XML so it is not considered > interoperable. > > * YANG Doctors will review each use of anyxml when YANG 1.1 is adopted, > and avoid its use if possible (e.g., root should be used instead) > (Does that mean anyxml SHOULD NOT be used -- deprecated?) > > * Do not add a replacement statement for anyxml (anydata) to YANG 1.1 This sounds like Solution Y34-02 with the additional restriction that the nodes inside the container need to be a top-level YANG data nodes representing configuration. Why is this additional restriction needed / helpful? /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 11 01:20:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A10A1A872E for ; Thu, 11 Sep 2014 01:20:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.378 X-Spam-Level: X-Spam-Status: No, score=-1.378 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_34=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j7VNtwQj5xzZ for ; Thu, 11 Sep 2014 01:20:43 -0700 (PDT) Received: from mail-qg0-f43.google.com (mail-qg0-f43.google.com [209.85.192.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C1271A0698 for ; Thu, 11 Sep 2014 01:20:42 -0700 (PDT) Received: by mail-qg0-f43.google.com with SMTP id a108so8606032qge.2 for ; Thu, 11 Sep 2014 01:20:42 -0700 (PDT) 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=VU4/cGBcBhC9fIk/dDOncBTqZ8fMsrzwjo5dkQPE7GA=; b=ckUNUv92zNYXEaGB2VBe7KcKKz7eGMcQ4L+Do1JlWR8W7zz98F4OaL/TM3LUdXit5+ x/eLsoGZnSktvub2siz6jT48vz8GymbG/TJLflnNHoElKI/CD85vmgAhEFaM8RB6LUrR t/4kwppy5+ZBSlBIyvtyGYY3w925l1AM2ENSLWCUbbxfksPzTP0/OQrg+aI0WdKE0B/L ce+SNB25IvN0Ey0DRtcLu31D9VssjfgxN7VQtREf8ZIlyYmWIC7E66n95GDlWOT7Yyw0 YHFubf8ao6m7obsMKQn/V44EpnzbgLFegPokLdUP++XAzCrSnqakuJ2euqtDsIcoMcFv 2h1w== X-Gm-Message-State: ALoCoQmHDPIGnFWbzeM2wwVW5wIPi3HVVh8MxTQvHjWMLlwYI5Ikpxi35x1d+FWJuq57RfQdHOUJ MIME-Version: 1.0 X-Received: by 10.140.98.102 with SMTP id n93mr7140619qge.83.1410423642046; Thu, 11 Sep 2014 01:20:42 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 01:20:41 -0700 (PDT) In-Reply-To: <20140911075604.GA2241@elstar.local> References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> <20140911075604.GA2241@elstar.local> Date: Thu, 11 Sep 2014 01:20:41 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113aae0a2b05940502c5d82d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/t-0emk2LRk2X8WmhYxU5ZUfrT94 Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 08:20:44 -0000 --001a113aae0a2b05940502c5d82d Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 12:56 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Sep 03, 2014 at 10:27:20AM -0700, Andy Bierman wrote: > > > Solution Y34-04: > > > > * Consider a new statement called "root" that provides the ncx:root > > semantics. > > There may be restrictions on its use (i.e., may not be full > > data-def-stmt) > > > > root config { > > description "Container of top-level YANG data nodes representing > the > > configuration"; > > } > > > > * For YANG 1.0 backward compatibility, allow anyxml to be used, > > except implementations MAY restrict the XML so it is not considered > > interoperable. > > > > * YANG Doctors will review each use of anyxml when YANG 1.1 is adopted, > > and avoid its use if possible (e.g., root should be used instead) > > (Does that mean anyxml SHOULD NOT be used -- deprecated?) > > > > * Do not add a replacement statement for anyxml (anydata) to YANG 1.1 > > This sounds like Solution Y34-02 with the additional restriction that > the nodes inside the container need to be a top-level YANG data nodes > representing configuration. Why is this additional restriction needed > / helpful? > This restriction matches the usage of the and containers as the root of an edit or retrieval. This use-case does not have any holes in the schema tree. There are no nodes of unknown syntax and semantics allowed. IMO we are not doing anything useful wrt/ anyxml so we should just ignore it and move on. It will continue to be used and abused by implementations, with limited interoperability. Some vendors do not even support it at all. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > --001a113aae0a2b05940502c5d82d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 12:56 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Sep 03, 2014 at 10:27:20AM -0700, Andy Bier= man wrote:

> Solution Y34-04:
>
> * Consider a new statement called "root" that provides the n= cx:root
> semantics.
>=A0 =A0 There may be restrictions on its use (i.e., may not be full
> data-def-stmt)
>
>=A0 =A0 root config {
>=A0 =A0 =A0 =A0description "Container of top-level YANG data nodes= representing the
> configuration";
>=A0 =A0 }
>
> * For YANG 1.0 backward compatibility, allow anyxml to be used,
>=A0 =A0 except implementations MAY restrict the XML so it is not consid= ered
> interoperable.
>
>=A0 * YANG Doctors will review each use of anyxml when YANG 1.1 is adop= ted,
>=A0 =A0 =A0and avoid its use if possible (e.g., root should be used ins= tead)
>=A0 =A0 (Does that mean anyxml SHOULD NOT be used -- deprecated?)
>
>=A0 * Do not add a replacement statement for anyxml (anydata) to YANG 1= .1

This sounds like Solution Y34-02 with the additional restriction that
the nodes inside the container need to be a top-level YANG data nodes
representing configuration. Why is this additional restriction needed
/ helpful?

This restriction matches the= usage of the <config> and <data> containers
as the r= oot of an edit or retrieval. =A0This use-case does not have any
h= oles in the schema tree. =A0 There are no nodes of unknown syntax
and semantics allowed.

IMO we are not doing anyth= ing useful wrt/ anyxml so we should
just ignore it and move on. = =A0It will continue to be used and abused
by implementations, wit= h limited interoperability. =A0Some vendors
do not even support i= t at all.


/js

Andy
=A0

--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

--001a113aae0a2b05940502c5d82d-- From nobody Thu Sep 11 05:11:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38DCF1A06F2 for ; Thu, 11 Sep 2014 05:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13HLIgb4w7wY for ; Thu, 11 Sep 2014 05:11:04 -0700 (PDT) Received: from epost.nunatak.no (epost.nunatak.no [193.200.93.202]) by ietfa.amsl.com (Postfix) with ESMTP id 807301A0860 for ; Thu, 11 Sep 2014 05:10:56 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.nunatak.no (Postfix) with ESMTP id 4A6563ED811D; Thu, 11 Sep 2014 14:13:29 +0200 (CEST) X-Virus-Scanned: amavisd-new at nunatak.no Received: from epost.nunatak.no ([127.0.0.1]) by localhost (epost.nunatak.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iwlzt-IMbCl0; Thu, 11 Sep 2014 14:13:24 +0200 (CEST) Received: from [192.168.209.127] (unknown [192.168.209.127]) by epost.nunatak.no (Postfix) with ESMTPSA id 192CE3EC8017; Thu, 11 Sep 2014 14:13:21 +0200 (CEST) Message-ID: <54119140.8080003@transpacket.com> Date: Thu, 11 Sep 2014 14:10:40 +0200 From: Vladimir Vassilev User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman , "netmod@ietf.org" References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> <20140911075604.GA2241@elstar.local> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/TRwkvFsFhb5QtoX05l3aaunsFYs Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:11:07 -0000 Hello, On 09/11/2014 10:20 AM, Andy Bierman wrote: > This restriction matches the usage of the and containers > as the root of an edit or retrieval. This use-case does not have any > holes in the schema tree. There are no nodes of unknown syntax > and semantics allowed. > There is one more use-case of anyxml that is not caused by holes in the schema tree. Modelling of a recursive tree in YANG is currently not possible due to the following sentence is RFC6020 7.11. The grouping Statement - "A grouping MUST NOT reference itself, neither directly nor indirectly through a chain of other groupings." A simple model of an OID tree illustrates the problem (check the "case oid-container" part). In that case one has to use anyxml since the deterministic option of using recursive grouping is illegal YANG. There are certain advantages using such recursive models. Is there reason for not removing the "A grouping MUST NOT reference itself..." requirement and thus removing one more unnecessary use-case for anyxml in YANG models? module oids { namespace "http://transpacket.com/ns/oids"; prefix "oids"; description "OID resolver module."; revision 2012-11-01 { description "Initial revision"; } typedef type-enumeration { type enumeration { enum ASN_INTEGER; enum ASN_OCTET_STR; enum ASN_COUNTER; enum ASN_COUNTER64; enum ASN_GAUGE; enum ASN_OID; } } grouping oids-grouping { list oid { key num; leaf num { type uint16; description "oid num"; } container contents { choice leaf-container { case oid-leaf { leaf type { type type-enumeration; } leaf value { type string; description "String value"; } } case oid-container { //container oids { // uses oids-grouping; //} anyxml oids; } } } } } container oids { config false; description "Top-level container for all oid database objects."; uses oids-grouping; } } Vladimir From nobody Thu Sep 11 05:14:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD0381A6F58 for ; Thu, 11 Sep 2014 05:14:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 nR7zvIhd-z-i for ; Thu, 11 Sep 2014 05:14:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5EC5A1A6F51 for ; Thu, 11 Sep 2014 05:14:25 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 452BB1280401; Thu, 11 Sep 2014 14:14:24 +0200 (CEST) Date: Thu, 11 Sep 2014 14:14:24 +0200 (CEST) Message-Id: <20140911.141424.1774159467797949262.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140903111127.GA79883@elstar.local> References: <20140903111127.GA79883@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Nh0cotT9eWuX8UHMZ8fVTr7nNdI Cc: netmod@ietf.org Subject: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:14:36 -0000 Hi, Juergen Schoenwaelder wrote: > If you disagree with any of the following proposed resolutions, please > speak up as soon as possible but no later than September 16 (so that > we have the input before the face-to-face interim meeting starts). If > you want to raise a concern, please start a threat with the issue > identifier in the subject line. I couldn't find any reasoning behind the proposal to adopt Y23-02 in the minutes. I prefer the syntax in Y23-01: exclude-pattern '[xX][mM][lL].*'; The current "pattern" statement is defined as: It is used to restrict the built-in type "string", or types derived from "string", to values that match the pattern. With Y23-01, this doesn't change. However, with the syntax proposed in Y23-02: pattern '[xX][mM][lL].*' { filter exclude; } the meaning of 'pattern' changes depending on the value of the substatement "filter". Also I think the word "filter" is not very descriptive. Filtering sounds like a process, but the type restriction statement defines the value space of the type. /martin From nobody Thu Sep 11 05:21:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D50131A0860 for ; Thu, 11 Sep 2014 05:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 kDIUx43D847t for ; Thu, 11 Sep 2014 05:21:22 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F1E541A0709 for ; Thu, 11 Sep 2014 05:21:14 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 03A75140A60 for ; Thu, 11 Sep 2014 14:21:11 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410438072; bh=77U9F7HBgpWycMgWdd2bK89kDvqHn3nBSeyjhwO3WTY=; h=From:Content-Type:Content-Transfer-Encoding:Subject:Date: References:To:Message-Id:Mime-Version; b=v9EEMUGYOatCY/UUp/oOZSQR5mdwyB0GZXy4XVsRNuvPlHFS8SjB4plg19/sINnUS gNbpMiE3y+W4iiTQTzkM9SXUjskuNSuutoDnOTNCCuzgVDaOqNwn74VX6bB3ucrDAz 957v0zxCp7x7kRxOQNb3S+e7GT4K/ZJlwq6+tDl4= From: Ladislav Lhotka Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Sep 2014 14:21:09 +0200 References: <20140911120337.26309.17065.idtracker@ietfa.amsl.com> To: NETMOD Working Group Message-Id: <8460893C-ADF6-472A-913F-E6A29313F0EB@nic.cz> Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nTKAyJzepMtxdxntFo7UJRDQarQ Subject: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-metadata-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:21:26 -0000 Hi, this draft tries to cover all aspects of defining and using metadata = annotations with YANG-based data, including their encoding in both XML = and JSON. Consequently, I plan to remove the section on metadata = encoding from draft-ietf-netmod-yang-json. Lada Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-lhotka-netmod-yang-metadata-00.txt > Date: 11 Sep 2014 14:03:37 GMT+2 > To: Ladislav Lhotka , "Ladislav Lhotka" >=20 >=20 > A new version of I-D, draft-lhotka-netmod-yang-metadata-00.txt > has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository. >=20 > Name: draft-lhotka-netmod-yang-metadata > Revision: 00 > Title: Defining and Using Metadata with YANG > Document date: 2014-09-11 > Group: Individual Submission > Pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-metadata-00.t= xt > Status: = https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-metadata/ > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 >=20 >=20 > Abstract: > This document defines a YANG extension statement that allows for > defining metadata annotions in YANG modules. The document also > specifies the encoding of annotations and rules for annotating > instances of YANG data nodes. >=20 >=20 >=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. >=20 > The IETF Secretariat >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 05:26:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF741A06F2 for ; Thu, 11 Sep 2014 05:26:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 PfCIUJZZd66j for ; Thu, 11 Sep 2014 05:26:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1CE881A6F14 for ; Thu, 11 Sep 2014 05:26:31 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 601D51280401; Thu, 11 Sep 2014 14:26:30 +0200 (CEST) Date: Thu, 11 Sep 2014 14:26:30 +0200 (CEST) Message-Id: <20140911.142630.516036691759545534.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140903111127.GA79883@elstar.local> References: <20140903111127.GA79883@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/M3WceeJ3oCMc2OccOscgwHj9m6k Cc: netmod@ietf.org Subject: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:26:35 -0000 Hi, Juergen Schoenwaelder wrote: > If you disagree with any of the following proposed resolutions, please > speak up as soon as possible but no later than September 16 (so that > we have the input before the face-to-face interim meeting starts). If > you want to raise a concern, please start a threat with the issue > identifier in the subject line. > * OPEN :Y25: make enum numbering purely informative and optional > > 2014-07-09 meeting proposal: adopt Y25-01. I strongly object to this proposal. This proposal doesn't fix a bug, but it removes an explicit feature of YANG 1.0. It is clear from RFC 6020 that the value isn't used in NETCONF, but it clearly states that the value is "carried as a convenience to implementors". If this is removed, current implementations that rely on this value no longer work. (Making it optional is also weird - as a data model designer, when should I use the value statement and what does it mean?) Also, if we do this, we should do the same for "position" in a "bits" type. The position is also not used by NETCONF, but carried as a convenience to implementors. (Note that the original issue that opened this discussion resulted in errata 3871, which is applied in draft-ietf-netmod-rfc6020bis-00) /martin From nobody Thu Sep 11 05:48:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9942B1A6F9E for ; Thu, 11 Sep 2014 05:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wXgQwv7Q2Yb9 for ; Thu, 11 Sep 2014 05:48:46 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A3431A0052 for ; Thu, 11 Sep 2014 05:48:46 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 46DCA540704; Thu, 11 Sep 2014 14:48:44 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bvCcEA3e10Xk; Thu, 11 Sep 2014 14:48:36 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id C11905403AA; Thu, 11 Sep 2014 14:48:35 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20140911.141424.1774159467797949262.mbj@tail-f.com> References: <20140903111127.GA79883@elstar.local> <20140911.141424.1774159467797949262.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 11 Sep 2014 14:48:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XCtmnVW4F5hOhxHZ2YkNh-MTO5k Cc: netmod@ietf.org Subject: Re: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 12:48:48 -0000 Martin Bjorklund writes: > Hi, > > Juergen Schoenwaelder wrote: >> If you disagree with any of the following proposed resolutions, please >> speak up as soon as possible but no later than September 16 (so that >> we have the input before the face-to-face interim meeting starts). If >> you want to raise a concern, please start a threat with the issue >> identifier in the subject line. > > I couldn't find any reasoning behind the proposal to adopt Y23-02 in > the minutes. > > I prefer the syntax in Y23-01: > > exclude-pattern '[xX][mM][lL].*'; > > > The current "pattern" statement is defined as: > > It is used to restrict the built-in type "string", or types derived > from "string", to values that match the pattern. > > With Y23-01, this doesn't change. > > However, with the syntax proposed in Y23-02: > > pattern '[xX][mM][lL].*' { > filter exclude; > } > > the meaning of 'pattern' changes depending on the value of the > substatement "filter". > > > Also I think the word "filter" is not very descriptive. Filtering > sounds like a process, but the type restriction statement defines the > value space of the type. I agree and also prefer Y23-01. Lada > > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 06:30:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64F331A00AE for ; Thu, 11 Sep 2014 06:30:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eOD3kQhp86A1 for ; Thu, 11 Sep 2014 06:30:16 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 955491A004E for ; Thu, 11 Sep 2014 06:30:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 95354540704; Thu, 11 Sep 2014 15:30:14 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FNvkOx1Vq40i; Thu, 11 Sep 2014 15:30:09 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 94337540396; Thu, 11 Sep 2014 15:30:09 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de In-Reply-To: <20140911.142630.516036691759545534.mbj@tail-f.com> References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 11 Sep 2014 15:30:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SbbEjeTtAgTGboGYeaNnhoLI-wE Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 13:30:19 -0000 Martin Bjorklund writes: > Hi, > > Juergen Schoenwaelder wrote: >> If you disagree with any of the following proposed resolutions, please >> speak up as soon as possible but no later than September 16 (so that >> we have the input before the face-to-face interim meeting starts). If >> you want to raise a concern, please start a threat with the issue >> identifier in the subject line. > >> * OPEN :Y25: make enum numbering purely informative and optional >> >> 2014-07-09 meeting proposal: adopt Y25-01. > > I strongly object to this proposal. This proposal doesn't fix a bug, I does fix a bug, which is mentioned in the description: an auto-numbered enumeration is difficult to update, e.g. by adding an enum somewhere in the middle, or changing the order of enums. > but it removes an explicit feature of YANG 1.0. It is clear from RFC > 6020 that the value isn't used in NETCONF, but it clearly states that > the value is "carried as a convenience to implementors". If this is > removed, current implementations that rely on this value no longer > work. (Making it optional is also weird - as a data model designer, > when should I use the value statement and what does it mean?) I am wondering what this "convenience" really is. An implementation may just use enum names and no numbers, and if it uses a mapping of enum names to numbers, than this mapping is totally local, and another implementation may use a different mapping with no impact on interoperability whatsoever. It just needs some elementary care whenever an implementation is being upgraded to a new version of an enumeration. It clearly makes YANG easier to use for readers and writers, and means tiny complications for implementors - and I think this is the correct order of priorities that we agreed upon. Your last question (when to use values if they are optional) is answered in solution Y25-01. > > Also, if we do this, we should do the same for "position" in a "bits" > type. The position is also not used by NETCONF, but carried as a > convenience to implementors. Yes. Lada > > (Note that the original issue that opened this discussion resulted in > errata 3871, which is applied in draft-ietf-netmod-rfc6020bis-00) > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 06:57:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 395D51A005E for ; Thu, 11 Sep 2014 06:57:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lSd-2gE-QENe for ; Thu, 11 Sep 2014 06:57:29 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE9971A6F2D for ; Thu, 11 Sep 2014 06:57:07 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4407B540704; Thu, 11 Sep 2014 15:57:06 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w1zG9q3PBsUy; Thu, 11 Sep 2014 15:57:02 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 5C8AA540396; Thu, 11 Sep 2014 15:57:02 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140903111127.GA79883@elstar.local> References: <20140903111127.GA79883@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 11 Sep 2014 15:56:59 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JH-4ltNRfLBIvDk5yIsRarARpUU Subject: [netmod] issue Y10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 13:57:31 -0000 Juergen Schoenwaelder writes: > > 2014-07-02 meeting action: LL to write down another syntax proposal > and MB to expand Y10-01. I don't remember exactly what idea I had regarding syntax but I think it had to do with: - the ability to specify ranges - the possibility of excluding specified enums So maybe instead of the "subset" statement as proposed in Y10-02, we could allow a sequence of "include" and "exclude" statements. For example: include "Mercury .. Mars, Uranus .. Pluto"; or, equivalently, exclude "Jupiter, Saturn"; Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 07:20:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6D3A1A00A3 for ; Thu, 11 Sep 2014 07:20:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TRZAwBl6y10 for ; Thu, 11 Sep 2014 07:20:17 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E708B1A0028 for ; Thu, 11 Sep 2014 07:20:16 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 1F332540704; Thu, 11 Sep 2014 16:20:15 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Get0K3CY0wZj; Thu, 11 Sep 2014 16:20:08 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id AFA2B540396; Thu, 11 Sep 2014 16:20:07 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140903111127.GA79883@elstar.local> References: <20140903111127.GA79883@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Thu, 11 Sep 2014 16:20:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/japZBoUwvmf30_TIdhtRFVyGab4 Subject: Re: [netmod] yang 1.1 status summary - consensus call on the first round of interim meeting proposals X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:20:18 -0000 Juergen Schoenwaelder writes: > * OPEN :Y18: fix "when" expression context node problem > > 2014-07-02 meeting action: LL to write up an example in which > situations Y18-01 is problematic. I added this example already on July 3 (SVN revision 48). Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 07:35:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 697951A6F58 for ; Thu, 11 Sep 2014 07:35:32 -0700 (PDT) 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 JVEllT43zL-P for ; Thu, 11 Sep 2014 07:35:29 -0700 (PDT) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8359A1A00C3 for ; Thu, 11 Sep 2014 07:35:29 -0700 (PDT) Received: by mail-qc0-f176.google.com with SMTP id x3so8176596qcv.21 for ; Thu, 11 Sep 2014 07:35:25 -0700 (PDT) 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=xif9hNY1ZtI0fkHbg7AAQQQAa/7/3qv0+5OH2be88uI=; b=PFpWM2J/Bk4rGlIpY57fwby1lYZoy4sTVnffHCQsLCbb4sCMAsyCSTDDBD/AXM9pQW hp1UYV/BOupkP6I3H2VahpEMgaFfI8sKmD5nsilfRFDxcnX3pV4GuXC1wDfKdMKBiDDV 64Fl4H5r/1NZIsSW/QSwIr93a3oUZrJvE7BgFqRR2b+uLrLJb2bZsspA0R6uG/9CeWIe HPD0KwjHFCfLnVmOrzzVWcRDjK1ESwz++TtecLDRX0IdzNBgKLSD496at7Tj4WOKdACw NM9E4P4zxdHgoZjMihdmYBxdLeSuWbNWz9OZN2V4aqYIlskuTjBbRMv9wCqhcexkRAEe NLnQ== X-Gm-Message-State: ALoCoQnCabXyHU/wlNCOGEyBsFfNp9Ksln0jGmcKBAXpxuUyo6H3QC0gWk9b+3XKXKhpGk67r4hF MIME-Version: 1.0 X-Received: by 10.229.236.8 with SMTP id ki8mr2219840qcb.12.1410446125442; Thu, 11 Sep 2014 07:35:25 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 07:35:25 -0700 (PDT) In-Reply-To: <54119140.8080003@transpacket.com> References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> <20140911075604.GA2241@elstar.local> <54119140.8080003@transpacket.com> Date: Thu, 11 Sep 2014 07:35:25 -0700 Message-ID: From: Andy Bierman To: Vladimir Vassilev Content-Type: multipart/alternative; boundary=001a1134b1624852a30502cb1461 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FN8U_ZBJIQ30Iji9pGIHRGhCvAQ Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:35:32 -0000 --001a1134b1624852a30502cb1461 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 5:10 AM, Vladimir Vassilev wrote: > Hello, > > On 09/11/2014 10:20 AM, Andy Bierman wrote: > > This restriction matches the usage of the and containers > > as the root of an edit or retrieval. This use-case does not have any > > holes in the schema tree. There are no nodes of unknown syntax > > and semantics allowed. > > > > There is one more use-case of anyxml that is not caused by holes in the > schema tree. Modelling of a recursive tree in YANG is currently not > possible due to the following sentence is RFC6020 7.11. The grouping > Statement - "A grouping MUST NOT reference itself, neither directly nor > indirectly through a chain of other groupings." > > A simple model of an OID tree illustrates the problem (check the "case > oid-container" part). In that case one has to use anyxml since the > deterministic option of using recursive grouping is illegal YANG. There are > certain advantages using such recursive models. Is there reason for not > removing the "A grouping MUST NOT reference itself..." requirement and thus > removing one more unnecessary use-case for anyxml in YANG models? > > Recursive groupings would not work in YANG like they do in real languages because the "uses" is automatically expanded. It needs to be manually instantiated by the client or server at run-time, not automatically expanded at compile-time. At this point, YANG might as well provide abstract and concrete classes, instead of a crude hack like anyxml. But thanks for demonstrating my point, which is that you are not using anyxml to comply with its interoperable semantics. You are creating restrictions on the content that are not conveyed to the client. A "standard client" should be able to send any valid XML in an edit, and that will be accepted as "anyxml". How many people are using anyxml as it is defined, not hacking it to provide a missing feature in YANG? Andy > module oids { > > namespace "http://transpacket.com/ns/oids"; > > prefix "oids"; > > description > "OID resolver module."; > > revision 2012-11-01 { > description > "Initial revision"; > } > > typedef type-enumeration { > type enumeration { > enum ASN_INTEGER; > enum ASN_OCTET_STR; > enum ASN_COUNTER; > enum ASN_COUNTER64; > enum ASN_GAUGE; > enum ASN_OID; > } > } > grouping oids-grouping { > > list oid { > key num; > leaf num { > type uint16; > description "oid num"; > } > container contents { > choice leaf-container { > case oid-leaf { > leaf type { > type type-enumeration; > } > leaf value { > type string; > description "String value"; > } > } > case oid-container { > //container oids { > // uses oids-grouping; > //} > anyxml oids; > } > } > } > } > } > > container oids { > config false; > > description > "Top-level container for all oid database objects."; > > uses oids-grouping; > } > } > > > Vladimir > > --001a1134b1624852a30502cb1461 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 5:10 AM, Vladimir Vassilev &l= t;vladimir@tr= anspacket.com> wrote:
Hello= ,

On 09/11/2014 10:20 AM, Andy Bierman wrote:
> This restriction matches the usage of the <config> and <data&= gt; containers
> as the root of an edit or retrieval.=A0 This use-case does not have an= y
> holes in the schema tree.=A0 =A0There are no nodes of unknown syntax > and semantics allowed.
>

There is one more use-case of anyxml that is not caused by holes in the sch= ema tree. Modelling of a recursive tree in YANG is currently not possible d= ue to the following sentence is RFC6020 7.11. The grouping Statement -=A0 &= quot;A grouping MUST NOT reference itself, neither directly nor indirectly = through a chain of other groupings."

A simple model of an OID tree illustrates the problem (check the "case= oid-container" part). In that case one has to use anyxml since the de= terministic option of using recursive grouping is illegal YANG. There are c= ertain advantages using such recursive models. Is there reason for not remo= ving the "A grouping MUST NOT reference itself..." requirement an= d thus removing one more unnecessary use-case for anyxml in YANG models?

Recursive groupings would not work in = YANG like they do in real languages
because the "uses" = is automatically expanded. =A0It needs to be manually
instantiate= d by the client or server at run-time, not automatically expanded
at compile-time. At this point, YANG might as well provide abstract and co= ncrete classes,
instead of a crude hack like anyxml.
But thanks for demonstrating my point, which is that you are n= ot using anyxml
to comply with its interoperable semantics. You a= re creating restrictions on
the content that are not conveyed to = the client.

A "standard client" should b= e able to send any valid XML in an edit,
and that will be accepte= d as "anyxml". =A0How many people are using anyxml
as i= t is defined, not hacking it to provide a missing feature in YANG?


Andy






module oids {

=A0 =A0 namespace "http://transpacket.com/ns/oids";

=A0 =A0 prefix "oids";

=A0 =A0 description
=A0 =A0 =A0 =A0 "OID resolver module.";

=A0 =A0 revision 2012-11-01 {
=A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 =A0 "Initial revision";
=A0 =A0 }

=A0 =A0 typedef type-enumeration {
=A0 =A0 =A0 type enumeration {
=A0 =A0 =A0 =A0 enum ASN_INTEGER;
=A0 =A0 =A0 =A0 enum ASN_OCTET_STR;
=A0 =A0 =A0 =A0 enum ASN_COUNTER;
=A0 =A0 =A0 =A0 enum ASN_COUNTER64;
=A0 =A0 =A0 =A0 enum ASN_GAUGE;
=A0 =A0 =A0 =A0 enum ASN_OID;
=A0 =A0 =A0 }
=A0 =A0 }
=A0 =A0 grouping oids-grouping {

=A0 =A0 =A0 =A0 list oid {
=A0 =A0 =A0 =A0 =A0 =A0 key num;
=A0 =A0 =A0 =A0 =A0 =A0 leaf num {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type uint16;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description "oid num";
=A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 container contents {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 choice leaf-container {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case oid-leaf {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf type {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type type-enumerati= on;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 leaf value {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 type string;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 description "S= tring value";
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 case oid-container {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //container oids {
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //=A0 =A0 uses oids-groupin= g;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 //}
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 anyxml oids;
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 =A0 =A0 }
=A0 =A0 =A0 =A0 }
=A0 =A0 }

=A0 =A0 container oids {
=A0 =A0 =A0 =A0 config false;

=A0 =A0 =A0 =A0 description
=A0 =A0 =A0 =A0 =A0 "Top-level container for all oid database objects.= ";

=A0 =A0 =A0 =A0 uses oids-grouping;
=A0 =A0 }
}


Vladimir


--001a1134b1624852a30502cb1461-- From nobody Thu Sep 11 07:38:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424DE1A02DD for ; Thu, 11 Sep 2014 07:38:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 baLlmCdhQBdY for ; Thu, 11 Sep 2014 07:38:32 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 280691A6F71 for ; Thu, 11 Sep 2014 07:38:32 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id F15941280401; Thu, 11 Sep 2014 16:38:30 +0200 (CEST) Date: Thu, 11 Sep 2014 16:38:29 +0200 (CEST) Message-Id: <20140911.163829.491743135.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/n0PQlS94fIzdFUjinQWY5BiRmGo Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:38:36 -0000 Ladislav Lhotka wrote: > Martin Bjorklund writes: > > > Hi, > > > > Juergen Schoenwaelder wrote: > >> If you disagree with any of the following proposed resolutions, please > >> speak up as soon as possible but no later than September 16 (so that > >> we have the input before the face-to-face interim meeting starts). If > >> you want to raise a concern, please start a threat with the issue > >> identifier in the subject line. > > > >> * OPEN :Y25: make enum numbering purely informative and optional > >> > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > I strongly object to this proposal. This proposal doesn't fix a bug, > > I does fix a bug, which is mentioned in the description: an > auto-numbered enumeration is difficult to update, e.g. by adding an enum > somewhere in the middle, or changing the order of enums. I don't agree that this is a bug. Maybe it is difficult in some cases (but not in the normal case imo), but not a bug. This feature works as initially intended when we did YANG 1.0. /martin From nobody Thu Sep 11 07:54:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B9BC1A00C3 for ; Thu, 11 Sep 2014 07:54:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 jd8ZJvAEATAz for ; Thu, 11 Sep 2014 07:54:31 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66DE71A00BB for ; Thu, 11 Sep 2014 07:54:31 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id E460A13F7D0; Thu, 11 Sep 2014 16:54:27 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410447268; bh=nulSRBNaZdTl9s8rQC9k1jtaMkwUiCXTJFClOA6a9yM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=rK+vOZtLsE7FHe+kyI9pKCEC/0iSkmRaAfNTkue59RPYKmaUvSALx9lN0fSoXhObh bdV/o/gTemnIUE4sBT0E2CUbWQvWLyvmXahOHsZKEelSLXn/XYBInV+0bsQ9/mDM7j wWwJM3eB/mkXhAa3fWk5DojRVYQvn+NDVQNmhqyo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140911.163829.491743135.mbj@tail-f.com> Date: Thu, 11 Sep 2014 16:54:23 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <1AC8CDE2-0A9F-4904-B7E3-46B2ABC1F065@nic.cz> References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/d7P0KRVT-Lwd9yr5AZwi57c27JA Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 14:54:33 -0000 On 11 Sep 2014, at 16:38, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >> Martin Bjorklund writes: >>=20 >>> Hi, >>>=20 >>> Juergen Schoenwaelder wrote: >>>> If you disagree with any of the following proposed resolutions, = please >>>> speak up as soon as possible but no later than September 16 (so = that >>>> we have the input before the face-to-face interim meeting starts). = If >>>> you want to raise a concern, please start a threat with the issue >>>> identifier in the subject line. >>>=20 >>>> * OPEN :Y25: make enum numbering purely informative and optional >>>>=20 >>>> 2014-07-09 meeting proposal: adopt Y25-01. >>>=20 >>> I strongly object to this proposal. This proposal doesn't fix a = bug, >>=20 >> I does fix a bug, which is mentioned in the description: an >> auto-numbered enumeration is difficult to update, e.g. by adding an = enum >> somewhere in the middle, or changing the order of enums. >=20 > I don't agree that this is a bug. Maybe it is difficult in some cases > (but not in the normal case imo), but not a bug. This feature works > as initially intended when we did YANG 1.0. IMO, an unnecessary CLR that makes life harder is a bug. Take the database of country codes (ISO 3166) as an example. It is = alphabetically sorted, so you don=92t want to be limited just to = appending new codes at the end. And adding bogus numeric values to all = enums is a sheer nuisance that would make the module twice as long. Lada=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 08:26:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B9CE1A03FE for ; Thu, 11 Sep 2014 08:26:25 -0700 (PDT) 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 fFY73RaWCHNd for ; Thu, 11 Sep 2014 08:26:22 -0700 (PDT) Received: from mail-qa0-f43.google.com (mail-qa0-f43.google.com [209.85.216.43]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 702971A86DF for ; Thu, 11 Sep 2014 08:26:22 -0700 (PDT) Received: by mail-qa0-f43.google.com with SMTP id cm18so19216440qab.16 for ; Thu, 11 Sep 2014 08:26:21 -0700 (PDT) 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=1e0RLWk2kF5T6mALC7tnh7OluXpMDlg7OuiDrJ110B0=; b=h3esEf9dtoLfsVaSEzXtT70HIneHVCRvHxqSvFMbyb8GnR6yVLW560MuUoeTUZcLl0 c08vk+BGbG+Jsa3lo0SzmpmeKvNzf4JJmZCcxLQD5Km+w+TghHjVUNMC3/U1Nhrt2qJl aB7v7U9s82yuKUeDhqeltpvg9uiInDf3oxjgDm/w5kP1uaYXM2vgoF+raz+ONrwaL/xX 4IBQ3wON0xFqJOfNs6Ph2TCjBxxDanXFAERN14CCPX5oDRq62lYQLJkwdLE1khrB67Bn du+1CEp1wgNOJXYzFZ3EpRbLoRCw42ak79x7Mr/d7X5201tzx+oxb+yhSAiHJDeKwurI wpbA== X-Gm-Message-State: ALoCoQlXnu5bx3KC20tmuKSnYjKFFw/6UaGVCgr6zHcKXTaHoDhiGYT1IuL6NBppIOG64HLP7qHX MIME-Version: 1.0 X-Received: by 10.229.84.133 with SMTP id j5mr2688178qcl.14.1410449179387; Thu, 11 Sep 2014 08:26:19 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 08:26:19 -0700 (PDT) In-Reply-To: <20140911.163829.491743135.mbj@tail-f.com> References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> Date: Thu, 11 Sep 2014 08:26:19 -0700 Message-ID: From: Andy Bierman To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113452564fcb9b0502cbca0f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ATvi-s9XDGzwKQxOoXB0L1tDQTY Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 15:26:25 -0000 --001a113452564fcb9b0502cbca0f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > Juergen Schoenwaelder wrote: > > >> If you disagree with any of the following proposed resolutions, please > > >> speak up as soon as possible but no later than September 16 (so that > > >> we have the input before the face-to-face interim meeting starts). If > > >> you want to raise a concern, please start a threat with the issue > > >> identifier in the subject line. > > > > > >> * OPEN :Y25: make enum numbering purely informative and optional > > >> > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > I strongly object to this proposal. This proposal doesn't fix a bug, > > > > I does fix a bug, which is mentioned in the description: an > > auto-numbered enumeration is difficult to update, e.g. by adding an enum > > somewhere in the middle, or changing the order of enums. > > I don't agree that this is a bug. Maybe it is difficult in some cases > (but not in the normal case imo), but not a bug. This feature works > as initially intended when we did YANG 1.0. > > +1 The normal usage mode is manual editing of the YANG file, not auto-generated from another data structure by some tool. The sec. 10 update rules are designed to protect old clients from disruptive changes in the API contract. A new revision of the contract cannot void provisions in previous revisions. Call them all CLRs if you want, but they are based on decades of experience breaking old clients, so ignore this section with caution. ;-) It seems clear to me that removing the auto-numbering would be taking away a YANG 1.0 feature, even though it is not used in the protocol. If vendors are complaining that they are using this feature, then that seems more important than removing a CLR to support auto-generated enums and bits. > /martin > Andy > > --001a113452564fcb9b0502cbca0f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
> Martin Bjorklund <mbj@tail-f.com<= /a>> writes:
>
> > Hi,
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> >> If you disagree with any of the following proposed resolution= s, please
> >> speak up as soon as possible but no later than September 16 (= so that
> >> we have the input before the face-to-face interim meeting sta= rts). If
> >> you want to raise a concern, please start a threat with the i= ssue
> >> identifier in the subject line.
> >
> >> * OPEN :Y25: make enum numbering purely informative and optio= nal
> >>
> >>=A0 =A02014-07-09 meeting proposal: adopt Y25-01.
> >
> > I strongly object to this proposal.=A0 This proposal doesn't = fix a bug,
>
> I does fix a bug, which is mentioned in the description: an
> auto-numbered enumeration is difficult to update, e.g. by adding an en= um
> somewhere in the middle, or changing the order of enums.

I don't agree that this is a bug.=A0 Maybe it is difficult in some case= s
(but not in the normal case imo), but not a bug.=A0 This feature works
as initially intended when we did YANG 1.0.



+1

=
The normal usage mode is manual editing of the YANG file, not auto-gen= erated
from another data structure by some tool.

The sec. 10 update rules are designed to protect old clients from = disruptive
changes in the API contract. =A0A new revision of the = contract cannot void
provisions in previous revisions. =A0 Call t= hem all CLRs if you want, but they
are based on decades of ex= perience breaking old clients, so ignore this
section with cautio= n. ;-)

It seems clear to me that removing the auto= -numbering would be taking
away a YANG 1.0 feature, even though i= t is not used in the protocol.
If vendors are complaining that th= ey are using this feature, then that
seems more important than re= moving a CLR to support auto-generated
enums and bits.
=


/martin

Andy
=A0

--001a113452564fcb9b0502cbca0f-- From nobody Thu Sep 11 09:33:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 568A41A8994 for ; Thu, 11 Sep 2014 09:33:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 DHkfsZwx8YHR for ; Thu, 11 Sep 2014 09:33:39 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6467F1A8853 for ; Thu, 11 Sep 2014 09:33:38 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 0914213F7D0; Thu, 11 Sep 2014 18:33:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410453216; bh=J2gzp4bNR0mqfnwRCu3RcYioUd/6sw3bUWhbi6RXRkg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=K2mIfJrz/LMJM4viOwvYboPaEHhRn22B+xfEG13eSkfCCCk0tBACaoKBqZyMpg/LO wKylquIsSj14OH2yaLmdLqRw/SRe2zRjsGj2CYRoHMFjXwiAHkuY7c1rbCGS1g+k5l vIpJn5xnuRhJfwcMD1gMJ3ll7CMRIWRf15zbJ6qc= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Sep 2014 18:33:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Pn6T2SzINQvQYNF_JQuKfUDNbuw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:33:42 -0000 On 11 Sep 2014, at 17:26, Andy Bierman wrote: >=20 >=20 > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > Martin Bjorklund writes: > > > > > Hi, > > > > > > Juergen Schoenwaelder = wrote: > > >> If you disagree with any of the following proposed resolutions, = please > > >> speak up as soon as possible but no later than September 16 (so = that > > >> we have the input before the face-to-face interim meeting = starts). If > > >> you want to raise a concern, please start a threat with the issue > > >> identifier in the subject line. > > > > > >> * OPEN :Y25: make enum numbering purely informative and optional > > >> > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > I strongly object to this proposal. This proposal doesn't fix a = bug, > > > > I does fix a bug, which is mentioned in the description: an > > auto-numbered enumeration is difficult to update, e.g. by adding an = enum > > somewhere in the middle, or changing the order of enums. >=20 > I don't agree that this is a bug. Maybe it is difficult in some cases > (but not in the normal case imo), but not a bug. This feature works > as initially intended when we did YANG 1.0. >=20 >=20 >=20 > +1 >=20 > The normal usage mode is manual editing of the YANG file, not = auto-generated > from another data structure by some tool. I don=92t understand. These enumeration rules are more of a problem for = manual editing - think about a maintainer of the country code = enumeration. If I remember correctly, this discussion started in connection to the = timezone database, and Martin's proposed solution was to write an = auto-numbering script. >=20 > The sec. 10 update rules are designed to protect old clients from = disruptive > changes in the API contract. A new revision of the contract cannot = void > provisions in previous revisions. Call them all CLRs if you want, = but they > are based on decades of experience breaking old clients, so ignore = this > section with caution. ;-) This has nothing to do with the data model contract because the numbers = are never exchanged between the server and client.=20 >=20 > It seems clear to me that removing the auto-numbering would be taking > away a YANG 1.0 feature, even though it is not used in the protocol. > If vendors are complaining that they are using this feature, then that > seems more important than removing a CLR to support auto-generated > enums and bits. >=20 Who are these vendors and why do they need this CLR? Lada=20 >=20 >=20 > /martin >=20 > Andy -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 09:59:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984AC1A6FDC for ; Thu, 11 Sep 2014 09:59:01 -0700 (PDT) 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 SsmvrBXTEv2c for ; Thu, 11 Sep 2014 09:58:58 -0700 (PDT) Received: from mail-qa0-f44.google.com (mail-qa0-f44.google.com [209.85.216.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AE0961A8788 for ; Thu, 11 Sep 2014 09:58:57 -0700 (PDT) Received: by mail-qa0-f44.google.com with SMTP id w8so1304896qac.3 for ; Thu, 11 Sep 2014 09:58:56 -0700 (PDT) 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=5dfDXu1Nj2qlkDdWcR2eSb9vO2n3QxmJ3hdj9xuyIkQ=; b=MlTGRfOcBJFMU0HAgQb8TYkiUgdX7mKnnOfOeEuQU5x1TfezesEghBb2x4bOmCbyTF xwoGAgc2QsStstVCEeyWFv+5CBng7HzdIj0K4VN6J33SCJfl6F2vaQaMvu4Rp6YbsIc9 4CwjLMLtRBWx052IPPRRX66FoFlHIk1bRN+gCDeS1dv4VeJRqZYT9AwB7Lm3lfrz1TNL RmZaRchgB29QHFkk6m7em3CYdqovtbbg5R59xVhCXEiIZOQUS2ttXAqiTrZEDoVWIr1f W2BomgmfWOhce7JE7OyuXjkq4E3S4knvWpclw6OPen7/uxf4Mi7UkSNsJo37ECJZ4PIY 7JsA== X-Gm-Message-State: ALoCoQmWF/zCq+GUGdTZYHw2kBYR9VQhm1ICEQE8Ea411TcBFh7QXnbaZWxE1jnwmlYRTLQiNJUM MIME-Version: 1.0 X-Received: by 10.229.212.66 with SMTP id gr2mr3413261qcb.27.1410454735937; Thu, 11 Sep 2014 09:58:55 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 09:58:55 -0700 (PDT) In-Reply-To: References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> Date: Thu, 11 Sep 2014 09:58:55 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11339b58820bc90502cd151f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0X2tbMoJMYuSumzGNRXjxzw7quE Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 16:59:01 -0000 --001a11339b58820bc90502cd151f Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka wrote: > > On 11 Sep 2014, at 17:26, Andy Bierman wrote: > > > > > > > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund > wrote: > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Hi, > > > > > > > > Juergen Schoenwaelder wrote: > > > >> If you disagree with any of the following proposed resolutions, > please > > > >> speak up as soon as possible but no later than September 16 (so that > > > >> we have the input before the face-to-face interim meeting starts). > If > > > >> you want to raise a concern, please start a threat with the issue > > > >> identifier in the subject line. > > > > > > > >> * OPEN :Y25: make enum numbering purely informative and optional > > > >> > > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > > > I strongly object to this proposal. This proposal doesn't fix a bug, > > > > > > I does fix a bug, which is mentioned in the description: an > > > auto-numbered enumeration is difficult to update, e.g. by adding an > enum > > > somewhere in the middle, or changing the order of enums. > > > > I don't agree that this is a bug. Maybe it is difficult in some cases > > (but not in the normal case imo), but not a bug. This feature works > > as initially intended when we did YANG 1.0. > > > > > > > > +1 > > > > The normal usage mode is manual editing of the YANG file, not > auto-generated > > from another data structure by some tool. > > I don't understand. These enumeration rules are more of a problem for > manual editing - think about a maintainer of the country code enumeration. > > This is a rare exception, not even close to a normal use of enumerations. For 98% of the cases, there is a small list of manually maintained values and adding a new value so it does not renumber other values is not hard at all. > If I remember correctly, this discussion started in connection to the > timezone database, and Martin's proposed solution was to write an > auto-numbering script. > > A script could generate values instead of auto-numbering them. It could check for the highest used value to create a new enum with a previously unused value. Acript should not use auto-numbering. > > > The sec. 10 update rules are designed to protect old clients from > disruptive > > changes in the API contract. A new revision of the contract cannot void > > provisions in previous revisions. Call them all CLRs if you want, but > they > > are based on decades of experience breaking old clients, so ignore this > > section with caution. ;-) > > This has nothing to do with the data model contract because the numbers > are never exchanged between the server and client. > > I think it does because this information is available for implementations to use, and the rules for changing these values is very clear. They can currently be utilized as static codepoints within implementations, even if auto-numbering is used. > > > It seems clear to me that removing the auto-numbering would be taking > > away a YANG 1.0 feature, even though it is not used in the protocol. > > If vendors are complaining that they are using this feature, then that > > seems more important than removing a CLR to support auto-generated > > enums and bits. > > > > Who are these vendors and why do they need this CLR? > Maybe Martin can say which tail-f customers use this confd feature. Somebody just asked me yesterday why there is no AGENTX for NETCONF. When will NETCONF have standardized sub-agents? Maybe this will not remain an implementation detail forever. Maybe RESTCONF for CoAP will use "YANG OIDs" and other numbers-replacing-strings. When it comes to JSON, you seem to think YANG needs to be defined independently of a protocol, but when it comes to this feature, YANG is not supposed to be protocol-independent. The stable auto-numbering is a YANG feature, not a protocol feature. > Lada > > Andy > > > > > > /martin > > > > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11339b58820bc90502cd151f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

On 11 Sep 2014, at 17:26, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> Ladislav Lhotka <lhotka@nic.cz= > wrote:
> > Martin Bjorklund <mbj@tail-f= .com> writes:
> >
> > > Hi,
> > >
> > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote: > > >> If you disagree with any of the following proposed resol= utions, please
> > >> speak up as soon as possible but no later than September= 16 (so that
> > >> we have the input before the face-to-face interim meetin= g starts). If
> > >> you want to raise a concern, please start a threat with = the issue
> > >> identifier in the subject line.
> > >
> > >> * OPEN :Y25: make enum numbering purely informative and = optional
> > >>
> > >>   2014-07-09 meeting proposal: adopt Y25-01. > > >
> > > I strongly object to this proposal.  This proposal does= n't fix a bug,
> >
> > I does fix a bug, which is mentioned in the description: an
> > auto-numbered enumeration is difficult to update, e.g. by adding = an enum
> > somewhere in the middle, or changing the order of enums.
>
> I don't agree that this is a bug.  Maybe it is difficult in s= ome cases
> (but not in the normal case imo), but not a bug.  This feature wo= rks
> as initially intended when we did YANG 1.0.
>
>
>
> +1
>
> The normal usage mode is manual editing of the YANG file, not auto-gen= erated
> from another data structure by some tool.

I don’t understand. These enumeration rules are more of a problem for= manual editing - think about a maintainer of the country code enumeration.=


This is a rare exception, not even clo= se to a normal use of enumerations.
For 98% of the cases, there i= s a small list of manually maintained values and
adding a new val= ue so it does not renumber other values is not hard at all.

<= /div>
 
If I remember correctly, this discussion started in connection to the timez= one database, and Martin's proposed solution was to write an auto-numbe= ring script.


A script could generate values instead= of auto-numbering them.
It could check for the highest used valu= e to create a new enum
with  a previously unused value. Acri= pt should not use auto-numbering.


>
> The sec. 10 update rules are designed to protect old clients from disr= uptive
> changes in the API contract.  A new revision of the contract cann= ot void
> provisions in previous revisions.   Call them all CLRs if yo= u want, but they
> are based on decades of experience breaking old clients, so ignore thi= s
> section with caution. ;-)

This has nothing to do with the data model contract because the numbers are= never exchanged between the server and client.


I think it does because this informati= on is available for implementations to use,
and the rules for cha= nging these values is very clear.  They can currently
be uti= lized as static codepoints within implementations, even if auto-numbering
is used.


>
> It seems clear to me that removing the auto-numbering would be taking<= br> > away a YANG 1.0 feature, even though it is not used in the protocol. > If vendors are complaining that they are using this feature, then that=
> seems more important than removing a CLR to support auto-generated
> enums and bits.
>

Who are these vendors and why do they need this CLR?
<= br>

Maybe Martin can say which tail-f customers us= e this confd feature.

Somebody just asked me yeste= rday why there is no AGENTX for NETCONF.
When will NETCONF have s= tandardized sub-agents?  Maybe this will not
remain an imple= mentation detail forever. Maybe RESTCONF for CoAP
will use "= YANG OIDs" and other numbers-replacing-strings.

When it comes to JSON, you seem to think YANG needs to be defined indepe= ndently of a protocol,
but when it comes to this feature, YANG is= not supposed to be protocol-independent.
The stable auto-numberi= ng is a YANG feature, not a protocol feature.


=

Lada



Andy

 
>
>
> /martin
>
> Andy

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11339b58820bc90502cd151f-- From nobody Thu Sep 11 10:26:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46D3A1A898A for ; Thu, 11 Sep 2014 10:25:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 bkri03LO4nUM for ; Thu, 11 Sep 2014 10:25:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 706681A6F85 for ; Thu, 11 Sep 2014 10:24:25 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id B17EF13F7D0; Thu, 11 Sep 2014 19:24:23 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410456263; bh=jii+/p04rKBAPNKILX8cI6OGcm+fR3sZo0LI4BaZWMQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=c38T1vqN2SILjhzJlwqqp6MVB/G86bDstamPwebRSmClIJKOHNaKM57taION0tvjX 60uKXV4XzEU6Amve64Y9T7T39knsCi+cFkERbiPkzGNH0tQWwGXGi2aPwnJFHLuAFh 4MMwdFrsRq+9uGae7jqQEu5AC/pzaCNPuMlWj5xg= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Thu, 11 Sep 2014 19:24:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A2ACFB7-7E45-4BDA-B1B0-C0D6709ED6AA@nic.cz> References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/04RY-g7VUqu4KOGDI6xLVjUvs7M Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 17:25:55 -0000 On 11 Sep 2014, at 18:58, Andy Bierman wrote: >=20 >=20 > On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka = wrote: >=20 > On 11 Sep 2014, at 17:26, Andy Bierman wrote: >=20 > > > > > > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund = wrote: > > Ladislav Lhotka wrote: > > > Martin Bjorklund writes: > > > > > > > Hi, > > > > > > > > Juergen Schoenwaelder = wrote: > > > >> If you disagree with any of the following proposed resolutions, = please > > > >> speak up as soon as possible but no later than September 16 (so = that > > > >> we have the input before the face-to-face interim meeting = starts). If > > > >> you want to raise a concern, please start a threat with the = issue > > > >> identifier in the subject line. > > > > > > > >> * OPEN :Y25: make enum numbering purely informative and = optional > > > >> > > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > > > I strongly object to this proposal. This proposal doesn't fix a = bug, > > > > > > I does fix a bug, which is mentioned in the description: an > > > auto-numbered enumeration is difficult to update, e.g. by adding = an enum > > > somewhere in the middle, or changing the order of enums. > > > > I don't agree that this is a bug. Maybe it is difficult in some = cases > > (but not in the normal case imo), but not a bug. This feature works > > as initially intended when we did YANG 1.0. > > > > > > > > +1 > > > > The normal usage mode is manual editing of the YANG file, not = auto-generated > > from another data structure by some tool. >=20 > I don=92t understand. These enumeration rules are more of a problem = for manual editing - think about a maintainer of the country code = enumeration. >=20 >=20 > This is a rare exception, not even close to a normal use of = enumerations. > For 98% of the cases, there is a small list of manually maintained = values and > adding a new value so it does not renumber other values is not hard at = all. In this case, what prevents you from keeping a consistent private = numbering even if the CLR doesn=92t exist in YANG? The point is that it = doesn=92t matter if another implementation uses a different numbering = scheme. It is also trivial to handle new enums that are added in the = middle - you just assign next available number so that old numbers are = intact. Lada >=20 > =20 > If I remember correctly, this discussion started in connection to the = timezone database, and Martin's proposed solution was to write an = auto-numbering script. >=20 >=20 > A script could generate values instead of auto-numbering them. > It could check for the highest used value to create a new enum > with a previously unused value. Acript should not use auto-numbering. >=20 >=20 > > > > The sec. 10 update rules are designed to protect old clients from = disruptive > > changes in the API contract. A new revision of the contract cannot = void > > provisions in previous revisions. Call them all CLRs if you want, = but they > > are based on decades of experience breaking old clients, so ignore = this > > section with caution. ;-) >=20 > This has nothing to do with the data model contract because the = numbers are never exchanged between the server and client. >=20 >=20 > I think it does because this information is available for = implementations to use, > and the rules for changing these values is very clear. They can = currently > be utilized as static codepoints within implementations, even if = auto-numbering > is used. >=20 >=20 > > > > It seems clear to me that removing the auto-numbering would be = taking > > away a YANG 1.0 feature, even though it is not used in the protocol. > > If vendors are complaining that they are using this feature, then = that > > seems more important than removing a CLR to support auto-generated > > enums and bits. > > >=20 > Who are these vendors and why do they need this CLR? >=20 >=20 > Maybe Martin can say which tail-f customers use this confd feature. >=20 > Somebody just asked me yesterday why there is no AGENTX for NETCONF. > When will NETCONF have standardized sub-agents? Maybe this will not > remain an implementation detail forever. Maybe RESTCONF for CoAP > will use "YANG OIDs" and other numbers-replacing-strings. >=20 > When it comes to JSON, you seem to think YANG needs to be defined = independently of a protocol, > but when it comes to this feature, YANG is not supposed to be = protocol-independent. > The stable auto-numbering is a YANG feature, not a protocol feature. >=20 >=20 >=20 > Lada >=20 >=20 >=20 > Andy >=20 > =20 > > > > > > /martin > > > > Andy >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 11:00:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0491A8A20 for ; Thu, 11 Sep 2014 11:00:05 -0700 (PDT) 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 W5V3IdwMcdhm for ; Thu, 11 Sep 2014 11:00:01 -0700 (PDT) Received: from mail-qa0-f42.google.com (mail-qa0-f42.google.com [209.85.216.42]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B3D71A8A23 for ; Thu, 11 Sep 2014 10:58:32 -0700 (PDT) Received: by mail-qa0-f42.google.com with SMTP id j7so694729qaq.29 for ; Thu, 11 Sep 2014 10:58:26 -0700 (PDT) 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=ZkUTajaafD292tDBeNLfysH3Qds0UQQXxWEyxY3b39w=; b=JJ7FqcaRxm62PkBDzZE+MSTBg88wT8seGkrlan9TtDWoDOlgz36NlbHO848uKVJiJr YnAerWDeZnjl4mdoF0LR3uA/oIkXSMK9j3Zg7Nm4rxNA9ETSDQLkSzTq/vThzT3CI3VN erThXqoGRwGvnm2uyz6VNKZ9BrRsuA9vg6vaLfo62E0k4Yk+SkkWa2wqsfrHeKfDxVZr 33LOvuNprBAi6iypXg5InD9pgA5JH+2vR/EW665xcDkkT7q+lu2h0WP2h48q83NGMtmI bUJWlH1N2dzC73iV7tZoOaW0KbbDmxAhkADHQvPhD9S4C93yXDghjxziVYkpuXn7R2B0 EHUA== X-Gm-Message-State: ALoCoQmuES0jW44GaAifbRURScTjp+ApVRS8Q4I3jmYRaJZD1V/oSPemdxgix9uOdKzGBVOkglm8 MIME-Version: 1.0 X-Received: by 10.224.88.137 with SMTP id a9mr4109337qam.88.1410458306727; Thu, 11 Sep 2014 10:58:26 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 10:58:26 -0700 (PDT) In-Reply-To: <8A2ACFB7-7E45-4BDA-B1B0-C0D6709ED6AA@nic.cz> References: <20140903111127.GA79883@elstar.local> <20140911.142630.516036691759545534.mbj@tail-f.com> <20140911.163829.491743135.mbj@tail-f.com> <8A2ACFB7-7E45-4BDA-B1B0-C0D6709ED6AA@nic.cz> Date: Thu, 11 Sep 2014 10:58:26 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c2bbc057ea630502cdeaf3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nQUlNm0IUroJCpSBfT2oPAq3-vI Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:00:06 -0000 --001a11c2bbc057ea630502cdeaf3 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 10:24 AM, Ladislav Lhotka wrote: > > On 11 Sep 2014, at 18:58, Andy Bierman wrote: > > > > > > > On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka wrote: > > > > On 11 Sep 2014, at 17:26, Andy Bierman wrote: > > > > > > > > > > > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund > wrote: > > > Ladislav Lhotka wrote: > > > > Martin Bjorklund writes: > > > > > > > > > Hi, > > > > > > > > > > Juergen Schoenwaelder > wrote: > > > > >> If you disagree with any of the following proposed resolutions, > please > > > > >> speak up as soon as possible but no later than September 16 (so > that > > > > >> we have the input before the face-to-face interim meeting > starts). If > > > > >> you want to raise a concern, please start a threat with the issue > > > > >> identifier in the subject line. > > > > > > > > > >> * OPEN :Y25: make enum numbering purely informative and optional > > > > >> > > > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > > > > > I strongly object to this proposal. This proposal doesn't fix a > bug, > > > > > > > > I does fix a bug, which is mentioned in the description: an > > > > auto-numbered enumeration is difficult to update, e.g. by adding an > enum > > > > somewhere in the middle, or changing the order of enums. > > > > > > I don't agree that this is a bug. Maybe it is difficult in some cases > > > (but not in the normal case imo), but not a bug. This feature works > > > as initially intended when we did YANG 1.0. > > > > > > > > > > > > +1 > > > > > > The normal usage mode is manual editing of the YANG file, not > auto-generated > > > from another data structure by some tool. > > > > I don't understand. These enumeration rules are more of a problem for > manual editing - think about a maintainer of the country code enumeration. > > > > > > This is a rare exception, not even close to a normal use of enumerations. > > For 98% of the cases, there is a small list of manually maintained > values and > > adding a new value so it does not renumber other values is not hard at > all. > > In this case, what prevents you from keeping a consistent private > numbering even if the CLR doesn't exist in YANG? The point is that it > doesn't matter if another implementation uses a different numbering scheme. > It is also trivial to handle new enums that are added in the middle - you > just assign next available number so that old numbers are intact. > > That's fair question. The answer may not be what we want to hear, but what is the point of making "value" and "position" first-class YANG statements when we treat them like vendor extensions? They are in the language to "help" implementations in unspecified ways? Perhaps they were misguided from the start. They certainly confuse people who know SNMP and assume it works the same way (or else why bother showing me this info in the public contract?) What if there was a different CLR that said a tool MUST convert YANG 1.0 module auto-numbering to explicit numbering when parsed by a YANG 1.1 tool? In other words a YANG 1.0 module is assigned value or position numbers based on the current rules, but if "yang-version 1.1" is in the module, then YANG 1.1 implementations are free to assign any number they want (including none). I don't know how to express this in RFC text yet, but I think it preserves YANG 1.0 behavior for YANG 1.0 modules, and only removes stable auto-numbering across all implementations from YANG 1.1. New modules must use explicit numbering or the vendor can add a YANG extension to assign values that are not numbered. Lada > > Andy > > > > > > If I remember correctly, this discussion started in connection to the > timezone database, and Martin's proposed solution was to write an > auto-numbering script. > > > > > > A script could generate values instead of auto-numbering them. > > It could check for the highest used value to create a new enum > > with a previously unused value. Acript should not use auto-numbering. > > > > > > > > > > The sec. 10 update rules are designed to protect old clients from > disruptive > > > changes in the API contract. A new revision of the contract cannot > void > > > provisions in previous revisions. Call them all CLRs if you want, > but they > > > are based on decades of experience breaking old clients, so ignore this > > > section with caution. ;-) > > > > This has nothing to do with the data model contract because the numbers > are never exchanged between the server and client. > > > > > > I think it does because this information is available for > implementations to use, > > and the rules for changing these values is very clear. They can > currently > > be utilized as static codepoints within implementations, even if > auto-numbering > > is used. > > > > > > > > > > It seems clear to me that removing the auto-numbering would be taking > > > away a YANG 1.0 feature, even though it is not used in the protocol. > > > If vendors are complaining that they are using this feature, then that > > > seems more important than removing a CLR to support auto-generated > > > enums and bits. > > > > > > > Who are these vendors and why do they need this CLR? > > > > > > Maybe Martin can say which tail-f customers use this confd feature. > > > > Somebody just asked me yesterday why there is no AGENTX for NETCONF. > > When will NETCONF have standardized sub-agents? Maybe this will not > > remain an implementation detail forever. Maybe RESTCONF for CoAP > > will use "YANG OIDs" and other numbers-replacing-strings. > > > > When it comes to JSON, you seem to think YANG needs to be defined > independently of a protocol, > > but when it comes to this feature, YANG is not supposed to be > protocol-independent. > > The stable auto-numbering is a YANG feature, not a protocol feature. > > > > > > > > Lada > > > > > > > > Andy > > > > > > > > > > > > > /martin > > > > > > Andy > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c2bbc057ea630502cdeaf3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 10:24 AM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

On 11 Sep 2014, at 18:58, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> On 11 Sep 2014, at 17:26, Andy Bierman <andy@yumaworks.com> wrote:
>
> >
> >
> > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> > Ladislav Lhotka <lhotka@nic.c= z> wrote:
> > > Martin Bjorklund <mbj@t= ail-f.com> writes:
> > >
> > > > Hi,
> > > >
> > > > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wro= te:
> > > >> If you disagree with any of the following proposed = resolutions, please
> > > >> speak up as soon as possible but no later than Sept= ember 16 (so that
> > > >> we have the input before the face-to-face interim m= eeting starts). If
> > > >> you want to raise a concern, please start a threat = with the issue
> > > >> identifier in the subject line.
> > > >
> > > >> * OPEN :Y25: make enum numbering purely informative= and optional
> > > >>
> > > >>   2014-07-09 meeting proposal: adopt Y25-= 01.
> > > >
> > > > I strongly object to this proposal.  This proposal= doesn't fix a bug,
> > >
> > > I does fix a bug, which is mentioned in the description: an<= br> > > > auto-numbered enumeration is difficult to update, e.g. by ad= ding an enum
> > > somewhere in the middle, or changing the order of enums.
> >
> > I don't agree that this is a bug.  Maybe it is difficult= in some cases
> > (but not in the normal case imo), but not a bug.  This featu= re works
> > as initially intended when we did YANG 1.0.
> >
> >
> >
> > +1
> >
> > The normal usage mode is manual editing of the YANG file, not aut= o-generated
> > from another data structure by some tool.
>
> I don’t understand. These enumeration rules are more of a proble= m for manual editing - think about a maintainer of the country code enumera= tion.
>
>
> This is a rare exception, not even close to a normal use of enumeratio= ns.
> For 98% of the cases, there is a small list of manually maintained val= ues and
> adding a new value so it does not renumber other values is not hard at= all.

In this case, what prevents you from keeping a consistent private numbering= even if the CLR doesn’t exist in YANG? The point is that it doesn&rs= quo;t matter if another implementation uses a different numbering scheme. I= t is also trivial to handle new enums that are added in the middle - you ju= st assign next available number so that old numbers are intact.


That's fair question. The answer m= ay not be what we want to hear, but what is the point of
making &= quot;value" and "position" first-class YANG statements when = we treat them like
vendor extensions?  They are in the langu= age to "help" implementations in unspecified ways?
Perh= aps they were misguided from the start.  They certainly confuse people= who know SNMP
and assume it works the same way (or else why both= er showing me this info in the public contract?)

W= hat if there was a different CLR that said a tool MUST convert YANG 1.0 mod= ule
auto-numbering to explicit numbering when parsed by a YANG 1.= 1 tool?
In other words a YANG 1.0 module is assigned value or pos= ition numbers based on the current
rules, but if "yang-versi= on 1.1" is in the module, then YANG 1.1 implementations are free to
assign any number they want (including none).

<= div>I don't know how to express this in RFC text yet, but I think it pr= eserves YANG 1.0
behavior for YANG 1.0 modules, and only removes = stable auto-numbering across
all implementations from YANG 1.1. &= nbsp;New modules must use explicit numbering
or the vendor can ad= d a YANG extension to assign values that are not numbered.



Lada


Andy
 
>
>
> If I remember correctly, this discussion started in connection to the = timezone database, and Martin's proposed solution was to write an auto-= numbering script.
>
>
> A script could generate values instead of auto-numbering them.
> It could check for the highest used value to create a new enum
> with  a previously unused value. Acript should not use auto-numbe= ring.
>
>
> >
> > The sec. 10 update rules are designed to protect old clients from= disruptive
> > changes in the API contract.  A new revision of the contract= cannot void
> > provisions in previous revisions.   Call them all CLRs = if you want, but they
> > are based on decades of experience breaking old clients, so ignor= e this
> > section with caution. ;-)
>
> This has nothing to do with the data model contract because the number= s are never exchanged between the server and client.
>
>
> I think it does because this information is available for implementati= ons to use,
> and the rules for changing these values is very clear.  They can = currently
> be utilized as static codepoints within implementations, even if auto-= numbering
> is used.
>
>
> >
> > It seems clear to me that removing the auto-numbering would be ta= king
> > away a YANG 1.0 feature, even though it is not used in the protoc= ol.
> > If vendors are complaining that they are using this feature, then= that
> > seems more important than removing a CLR to support auto-generate= d
> > enums and bits.
> >
>
> Who are these vendors and why do they need this CLR?
>
>
> Maybe Martin can say which tail-f customers use this confd feature. >
> Somebody just asked me yesterday why there is no AGENTX for NETCONF. > When will NETCONF have standardized sub-agents?  Maybe this will = not
> remain an implementation detail forever. Maybe RESTCONF for CoAP
> will use "YANG OIDs" and other numbers-replacing-strings. >
> When it comes to JSON, you seem to think YANG needs to be defined inde= pendently of a protocol,
> but when it comes to this feature, YANG is not supposed to be protocol= -independent.
> The stable auto-numbering is a YANG feature, not a protocol feature. >
>
>
> Lada
>
>
>
> Andy
>
>
> >
> >
> > /martin
> >
> > Andy
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c2bbc057ea630502cdeaf3-- From nobody Thu Sep 11 11:29:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6752F1A2130 for ; Thu, 11 Sep 2014 11:29:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 LEgPrtqjdiVZ for ; Thu, 11 Sep 2014 11:29:24 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 240D41A6EE6 for ; Thu, 11 Sep 2014 11:29:24 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 0F5C81280401; Thu, 11 Sep 2014 20:29:23 +0200 (CEST) Date: Thu, 11 Sep 2014 20:29:22 +0200 (CEST) Message-Id: <20140911.202922.121311912.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <8A2ACFB7-7E45-4BDA-B1B0-C0D6709ED6AA@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/rA8mBhx1VSq425Q3oc_oK6KgsVw Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:29:26 -0000 Andy Bierman wrote: > On Thu, Sep 11, 2014 at 10:24 AM, Ladislav Lhotka wrote: > > > > > On 11 Sep 2014, at 18:58, Andy Bierman wrote: > > > > > > > > > > > On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka wrote: > > > > > > On 11 Sep 2014, at 17:26, Andy Bierman wrote: > > > > > > > > > > > > > > > On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund > > wrote: > > > > Ladislav Lhotka wrote: > > > > > Martin Bjorklund writes: > > > > > > > > > > > Hi, > > > > > > > > > > > > Juergen Schoenwaelder > > wrote: > > > > > >> If you disagree with any of the following proposed resolutions, > > please > > > > > >> speak up as soon as possible but no later than September 16 (so > > that > > > > > >> we have the input before the face-to-face interim meeting > > starts). If > > > > > >> you want to raise a concern, please start a threat with the issue > > > > > >> identifier in the subject line. > > > > > > > > > > > >> * OPEN :Y25: make enum numbering purely informative and optional > > > > > >> > > > > > >> 2014-07-09 meeting proposal: adopt Y25-01. > > > > > > > > > > > > I strongly object to this proposal. This proposal doesn't fix a > > bug, > > > > > > > > > > I does fix a bug, which is mentioned in the description: an > > > > > auto-numbered enumeration is difficult to update, e.g. by adding an > > enum > > > > > somewhere in the middle, or changing the order of enums. > > > > > > > > I don't agree that this is a bug. Maybe it is difficult in some cases > > > > (but not in the normal case imo), but not a bug. This feature works > > > > as initially intended when we did YANG 1.0. > > > > > > > > > > > > > > > > +1 > > > > > > > > The normal usage mode is manual editing of the YANG file, not > > auto-generated > > > > from another data structure by some tool. > > > > > > I don't understand. These enumeration rules are more of a problem for > > manual editing - think about a maintainer of the country code enumeration. > > > > > > > > > This is a rare exception, not even close to a normal use of enumerations. > > > For 98% of the cases, there is a small list of manually maintained > > values and > > > adding a new value so it does not renumber other values is not hard at > > all. > > > > In this case, what prevents you from keeping a consistent private > > numbering even if the CLR doesn't exist in YANG? The point is that it > > doesn't matter if another implementation uses a different numbering scheme. > > It is also trivial to handle new enums that are added in the middle - you > > just assign next available number so that old numbers are intact. > > > > > That's fair question. The answer may not be what we want to hear, but what > is the point of > making "value" and "position" first-class YANG statements when we treat > them like > vendor extensions? They are in the language to "help" implementations in > unspecified ways? > Perhaps they were misguided from the start. Perhaps. But I still don't think we should remove features from YANG 1.0 that works they way they were designed to work. Also, as you said, maybe some other protocol mapping use them. /martin From nobody Thu Sep 11 11:45:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABF91A001D for ; Thu, 11 Sep 2014 11:45:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 3eLmjq4aK-l5 for ; Thu, 11 Sep 2014 11:44:59 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id DD5A11A0015 for ; Thu, 11 Sep 2014 11:44:58 -0700 (PDT) Received: from localhost (unknown [193.13.112.215]) by mail.tail-f.com (Postfix) with ESMTPSA id 8D17A1280401; Thu, 11 Sep 2014 20:44:55 +0200 (CEST) Date: Thu, 11 Sep 2014 20:44:55 +0200 (CEST) Message-Id: <20140911.204455.383704477.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/8_ds3UkggcS3o-jSbhz6YrCG04Q Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:45:01 -0000 Andy Bierman wrote: > On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka wrote: > > > > > On 11 Sep 2014, at 17:26, Andy Bierman wrote: > > > > > It seems clear to me that removing the auto-numbering would be taking > > > away a YANG 1.0 feature, even though it is not used in the protocol. > > > If vendors are complaining that they are using this feature, then that > > > seems more important than removing a CLR to support auto-generated > > > enums and bits. > > > > > > > Who are these vendors and why do they need this CLR? > > > > > Maybe Martin can say which tail-f customers use this confd feature. In a sense all of them. Could it be done differently? Sure, but since this fetaure is there we use it. (we had a different solution before yang, but the current one is better). Having both a numeric value and a symbolic identifier for an enum is not really a new idea... It is not a co-incident that the enum values work like in C (almost ;). /martin From nobody Thu Sep 11 11:52:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E5661A0032 for ; Thu, 11 Sep 2014 11:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 Zbp9x5E0HHws for ; Thu, 11 Sep 2014 11:52:04 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95BBF1A003A for ; Thu, 11 Sep 2014 11:52:00 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 17F6013F7D0; Thu, 11 Sep 2014 20:51:59 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410461519; bh=KnhZv5JcBMZnXMX1pvCsepFEYBe9+8mv3c3Ri1lhYbo=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CW1r3Jor5OWVn58pBqeRrUlIXtapaMKgrxOddx/ESopatnrSlzZg81vxA8E47HT7w iNImEp3tCrI01yeAHq6pJ42iijmUxjNXQhAzDLLIWp9XoJfd504JPjsqcIDodvzNDg oKPkgxSuAGc0l+izPtsn8TLVVUD9AVCuTJ2qyuWA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140911.202922.121311912.mbj@tail-f.com> Date: Thu, 11 Sep 2014 20:51:57 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <09BA9D47-10FD-4DC0-94B2-5A276A7E8C7D@nic.cz> References: <8A2ACFB7-7E45-4BDA-B1B0-C0D6709ED6AA@nic.cz> <20140911.202922.121311912.mbj@tail-f.com> To: =?iso-8859-1?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IzpBTWNYokrSrVclJ-j_CsUJI70 Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 18:52:06 -0000 On 11 Sep 2014, at 20:29, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Sep 11, 2014 at 10:24 AM, Ladislav Lhotka = wrote: >>=20 >>>=20 >>> On 11 Sep 2014, at 18:58, Andy Bierman wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka = wrote: >>>>=20 >>>> On 11 Sep 2014, at 17:26, Andy Bierman wrote: >>>>=20 >>>>>=20 >>>>>=20 >>>>> On Thu, Sep 11, 2014 at 7:38 AM, Martin Bjorklund >>> wrote: >>>>> Ladislav Lhotka wrote: >>>>>> Martin Bjorklund writes: >>>>>>=20 >>>>>>> Hi, >>>>>>>=20 >>>>>>> Juergen Schoenwaelder >>> wrote: >>>>>>>> If you disagree with any of the following proposed resolutions, >>> please >>>>>>>> speak up as soon as possible but no later than September 16 (so >>> that >>>>>>>> we have the input before the face-to-face interim meeting >>> starts). If >>>>>>>> you want to raise a concern, please start a threat with the = issue >>>>>>>> identifier in the subject line. >>>>>>>=20 >>>>>>>> * OPEN :Y25: make enum numbering purely informative and = optional >>>>>>>>=20 >>>>>>>> 2014-07-09 meeting proposal: adopt Y25-01. >>>>>>>=20 >>>>>>> I strongly object to this proposal. This proposal doesn't fix a >>> bug, >>>>>>=20 >>>>>> I does fix a bug, which is mentioned in the description: an >>>>>> auto-numbered enumeration is difficult to update, e.g. by adding = an >>> enum >>>>>> somewhere in the middle, or changing the order of enums. >>>>>=20 >>>>> I don't agree that this is a bug. Maybe it is difficult in some = cases >>>>> (but not in the normal case imo), but not a bug. This feature = works >>>>> as initially intended when we did YANG 1.0. >>>>>=20 >>>>>=20 >>>>>=20 >>>>> +1 >>>>>=20 >>>>> The normal usage mode is manual editing of the YANG file, not >>> auto-generated >>>>> from another data structure by some tool. >>>>=20 >>>> I don't understand. These enumeration rules are more of a problem = for >>> manual editing - think about a maintainer of the country code = enumeration. >>>>=20 >>>>=20 >>>> This is a rare exception, not even close to a normal use of = enumerations. >>>> For 98% of the cases, there is a small list of manually maintained >>> values and >>>> adding a new value so it does not renumber other values is not hard = at >>> all. >>>=20 >>> In this case, what prevents you from keeping a consistent private >>> numbering even if the CLR doesn't exist in YANG? The point is that = it >>> doesn't matter if another implementation uses a different numbering = scheme. >>> It is also trivial to handle new enums that are added in the middle = - you >>> just assign next available number so that old numbers are intact. >>>=20 >>>=20 >> That's fair question. The answer may not be what we want to hear, but = what >> is the point of >> making "value" and "position" first-class YANG statements when we = treat >> them like >> vendor extensions? They are in the language to "help" = implementations in >> unspecified ways? >> Perhaps they were misguided from the start. >=20 > Perhaps. But I still don't think we should remove features from YANG > 1.0 that works they way they were designed to work. Along the same lines you could reject Y09 because it removes a feature = that works the way it was designed, namely mandatory presence of all = keys. Lada >=20 > Also, as you said, maybe some other protocol mapping use them. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 12:22:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB01A008B for ; Thu, 11 Sep 2014 12:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 jY83kAW1RuLG for ; Thu, 11 Sep 2014 12:22:40 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9912B1A00BF for ; Thu, 11 Sep 2014 12:22:03 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 965CD13F7D0; Thu, 11 Sep 2014 21:22:00 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410463320; bh=zYod9ADL0+rcNE4f0Nf0Mdejhxp+1C0QYHACixx1hPc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=kqT9vGXi57KV/lbqzKYuTQaXo/QiuvX+q8lAc9E1dVzXXF/GX7DG2Brp52vcxEtrn NeeauNKWf9fZB6wxm4HXekClKGQ4yqsJpYyHMmZuOanx9qHKrbvLYnKjOA+9T5FN06 S2mWuL3O83js2v/j3UiF4T4ZxUcTJq64v+vJU4os= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140911.204455.383704477.mbj@tail-f.com> Date: Thu, 11 Sep 2014 21:21:59 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140911.204455.383704477.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bXI8O3jLtsIO3FiYe4FKUFePyn8 Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 19:22:43 -0000 On 11 Sep 2014, at 20:44, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka = wrote: >>=20 >>>=20 >>> On 11 Sep 2014, at 17:26, Andy Bierman wrote: >>>=20 >>>> It seems clear to me that removing the auto-numbering would be = taking >>>> away a YANG 1.0 feature, even though it is not used in the = protocol. >>>> If vendors are complaining that they are using this feature, then = that >>>> seems more important than removing a CLR to support auto-generated >>>> enums and bits. >>>>=20 >>>=20 >>> Who are these vendors and why do they need this CLR? >>>=20 >>=20 >>=20 >> Maybe Martin can say which tail-f customers use this confd feature. >=20 > In a sense all of them. Could it be done differently? Sure, but > since this fetaure is there we use it. (we had a different solution > before yang, but the current one is better). Not being a confd user I have no idea what features and solutions you = are talking about. Do you generate C header files from enumerations? I think it is hard to deny that removing the CLR would streamline and = improve the spec, and make enumerations more usable. I am not personally = convinced about the =93convenience to implementors=94 but in any case it = is not supposed to be the highest priority. >=20 > Having both a numeric value and a symbolic identifier for an enum is > not really a new idea... It is not a co-incident that the enum > values work like in C (almost ;). YANG is not a programming language. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 11 12:49:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DDE21A00E5 for ; Thu, 11 Sep 2014 12:49:10 -0700 (PDT) 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 7zvMaMbns0F5 for ; Thu, 11 Sep 2014 12:49:05 -0700 (PDT) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 81B9B1A00AA for ; Thu, 11 Sep 2014 12:49:05 -0700 (PDT) Received: by mail-qc0-f173.google.com with SMTP id w7so21644914qcr.4 for ; Thu, 11 Sep 2014 12:49:00 -0700 (PDT) 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=pW6QSSWYUUnYBSeOH004GADQRkKNjw3xCF+1HQGIevU=; b=I4VxrfCTBTPvaxbM7ltXEpDmrHDQz/zUSIEEjI4y+5LBSY7p5tHaRLdpWZUjmGFq4K WN3evWIh5VcgsH27EDLpQQamlj85inOHRir8uRgvfg7CwE1guXcmujDSlU///ZYybzpd +vjhQ8IyP+tzWaonvYn+fPRXayC1AFii29GhTDK70Gbs4bgqCPWRZ0xMNmzTRyS9XSxi qGFCqCrFoSmUu3lbSRAh2MQYVCRxB5RaFUw4cPQ9Ymn8HRclVKxsoi7zx4NVmfXAaKLt u59f611CJKiFYZRSXtMbBJobYfRVlDhKYtvFCpPqV1fRYKQ5Ld+USYpqIXxTdKtAyI2U 5JCA== X-Gm-Message-State: ALoCoQn68r/sX/ijRvzyG4bS3wwEhc7muzGU/M/tfrmkiieLOiJNPN9C7SNxVN2VqxlAXym7Ed+7 MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr5047494qgl.90.1410464940260; Thu, 11 Sep 2014 12:49:00 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Thu, 11 Sep 2014 12:49:00 -0700 (PDT) In-Reply-To: References: <20140911.204455.383704477.mbj@tail-f.com> Date: Thu, 11 Sep 2014 12:49:00 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c13986bb9cde0502cf758b Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nFThMFgvlwz0tDPUN9pOQGMd63c Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 19:49:10 -0000 --001a11c13986bb9cde0502cf758b Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 12:21 PM, Ladislav Lhotka wrote: > > On 11 Sep 2014, at 20:44, Martin Bjorklund wrote: > > > Andy Bierman wrote: > >> On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka wrote: > >> > >>> > >>> On 11 Sep 2014, at 17:26, Andy Bierman wrote: > >>> > >>>> It seems clear to me that removing the auto-numbering would be taking > >>>> away a YANG 1.0 feature, even though it is not used in the protocol. > >>>> If vendors are complaining that they are using this feature, then that > >>>> seems more important than removing a CLR to support auto-generated > >>>> enums and bits. > >>>> > >>> > >>> Who are these vendors and why do they need this CLR? > >>> > >> > >> > >> Maybe Martin can say which tail-f customers use this confd feature. > > > > In a sense all of them. Could it be done differently? Sure, but > > since this fetaure is there we use it. (we had a different solution > > before yang, but the current one is better). > > Not being a confd user I have no idea what features and solutions you are > talking about. Do you generate C header files from enumerations? > > I think it is hard to deny that removing the CLR would streamline and > improve the spec, and make enumerations more usable. I am not personally > convinced about the "convenience to implementors" but in any case it is not > supposed to be the highest priority. > The intent of the value/position statements is to convey data model codepoints if they exist (e.g., match a protocol spec). It is not clear what the intent of auto-numbering was at the time. We can't seem to agree on that so we cannot agree it is a feature worth keeping in YANG 1.1. If the data modeler does not intend to give value or position any meaning, then how do they do that with auto-numbering? That is the problem I have with keeping it in YANG 1.1. (You can't turn it off.) It is impossible to tell (outside the server internals) what values are assigned by the server during auto-numbering so how will we ever test conformance for auto-numbering? That's why I think "implementation-specific numbering" is OK in YANG 1.1. > > > > Having both a numeric value and a symbolic identifier for an enum is > > not really a new idea... It is not a co-incident that the enum > > values work like in C (almost ;). > > YANG is not a programming language. > Yes it is -- that's what's new and better about about it ;-) Automation is about consistency and work reduction. The model drives various tasks that are traditionally written by hand. > > Lada > > Andy > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c13986bb9cde0502cf758b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 12:21 PM, Ladislav Lhotka <= ;lhotka@nic.cz> wrote:

On 11 Sep 2014, at 20:44, Martin Bjorklund <mbj@tail-f.com> wrote:

> Andy Bierman <andy@yumaworks.= com> wrote:
>> On Thu, Sep 11, 2014 at 9:33 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>>
>>>
>>> On 11 Sep 2014, at 17:26, Andy Bierman <andy@yumaworks.com> wrote:
>>>
>>>> It seems clear to me that removing the auto-numbering woul= d be taking
>>>> away a YANG 1.0 feature, even though it is not used in the= protocol.
>>>> If vendors are complaining that they are using this featur= e, then that
>>>> seems more important than removing a CLR to support auto-g= enerated
>>>> enums and bits.
>>>>
>>>
>>> Who are these vendors and why do they need this CLR?
>>>
>>
>>
>> Maybe Martin can say which tail-f customers use this confd feature= .
>
> In a sense all of them.  Could it be done differently?  Sure= , but
> since this fetaure is there we use it.  (we had a different solut= ion
> before yang, but the current one is better).

Not being a confd user I have no idea what features and solutions you are t= alking about. Do you generate C header files from enumerations?

I think it is hard to deny that removing the CLR would streamline and impro= ve the spec, and make enumerations more usable. I am not personally convinc= ed about the “convenience to implementors” but in any case it i= s not supposed to be the highest priority.

<= div>The intent of the value/position statements is to convey data model cod= epoints
if they exist (e.g., match a protocol spec).  It is = not clear what the intent of
auto-numbering was at the time. &nbs= p; We can't seem to agree on that so we
cannot agree it is a = feature worth keeping in YANG 1.1.

If the data mod= eler does not intend to give value or position any meaning,
then = how do they do that with auto-numbering?  That is the problem I
<= div>have with keeping it in YANG 1.1. (You can't turn it off.)

It is impossible to tell (outside the server internals) wh= at values are
assigned by the server during auto-numbering so how= will we ever
test conformance for auto-numbering?

=
That's why I think "implementation-specific numbering&q= uot; is OK in YANG 1.1.



>
> Having both a numeric value and a symbolic identifier for an enum is > not really a new idea...   It is not a co-incident that the = enum
> values work like in C (almost ;).

YANG is not a programming language.

Yes= it is -- that's what's new and better about about it ;-)
Automation is about consistency and work reduction.
The model dr= ives various tasks that are traditionally written by hand.
 =

Lada


Andy
 
>
>
> /martin

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c13986bb9cde0502cf758b-- From nobody Thu Sep 11 13:41:19 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB5481A0185 for ; Thu, 11 Sep 2014 13:41:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 IN2IIM2fAk3Q for ; Thu, 11 Sep 2014 13:41:13 -0700 (PDT) Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id 87E7F1A0166 for ; Thu, 11 Sep 2014 13:41:10 -0700 (PDT) Received: from fileserver.snmp.com (fileserver.snmp.com [192.147.142.16]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id QAA18739; Thu, 11 Sep 2014 16:41:06 -0400 (EDT) Received: from LOCALHOST.snmp.com (LOCALHOST.snmp.com [127.0.0.1]) by fileserver.snmp.com (8.9.3/snmpclient.mc-990525) with SMTP id QAA11527; Thu, 11 Sep 2014 16:40:59 -0400 (EDT) Message-Id: <201409112040.QAA11527@fileserver.snmp.com> X-Authentication-Warning: fileserver.snmp.com: LOCALHOST.snmp.com [127.0.0.1] didn't use HELO protocol To: Martin Bjorklund From: David Reid In-reply-to: Your message of Thu, 11 Sep 2014 20:29:22 +0200. <20140911.202922.121311912.mbj@tail-f.com> Date: Thu, 11 Sep 2014 16:40:58 -0400 Sender: reid@snmp.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/asBEjdOHpvpA35cd2Ev08WVAc8I Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: David Reid List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Sep 2014 20:41:15 -0000 > Also, as you said, maybe some other protocol mapping use them. We use SNMP to get some yang defined data. In the case of enumerations, we use the automatically assigned value. -David Reid From nobody Thu Sep 11 18:02:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4821A0263; Thu, 11 Sep 2014 18:02:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.22 X-Spam-Level: X-Spam-Status: No, score=-101.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_FUTURE_48_96=2.181, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, USER_IN_WHITELIST=-100] 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 21qntZqeF9Cy; Thu, 11 Sep 2014 18:02:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1D3051A0306; Thu, 11 Sep 2014 18:02:45 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.119]) by Websense Email Security Gateway with ESMTP id C4B41124E095; Fri, 12 Sep 2014 09:02:37 +0800 (CST) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 68F9D6FE6AC; Fri, 12 Sep 2014 09:02:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s8C12YLv044876; Fri, 12 Sep 2014 09:02:34 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140911.141424.1774159467797949262.mbj@tail-f.com> References: <20140903111127.GA79883@elstar.local> <20140911.141424.1774159467797949262.mbj@tail-f.com> To: Martin Bjorklund MIME-Version: 1.0 X-KeepSent: 6723B0D3:5FABFB41-48257D51:0004EB39; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 15 Sep 2014 09:02:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-09-12 09:02:34, Serialize complete at 2014-09-12 09:02:34 Content-Type: multipart/alternative; boundary="=_alternative 0005BA4948257D51_=" X-MAIL: mse02.zte.com.cn s8C12YLv044876 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a5SL1ScUWhdHz-X9vzOYIPZzd7k Cc: netmod , netmod@ietf.org Subject: Re: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 01:02:51 -0000 This is a multipart message in MIME format. --=_alternative 0005BA4948257D51_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSB0aGluayAncGF0dGVybicganVzdCBkZWZpbmUgYSByZWd1bGFyIGV4cHJlc3Npb24uICdwYXR0 ZXJuJyBpdHNlbGYgDQpzaG91bGQgDQpoYXMgbm8gYW55IG1lYW5pbmcgb2YgZmlsdGVyIHR5cGUu IExpa2UgcGlwZWxpbmUgaW4gdW5peCwgdW5peCB1c2UgfCANCntpbmNsdWRlIHwgZXhjbHVkZSB8 IGJlZ2lufSA8cGF0dGVybj4gdG8gDQppbXBsZW1lbnQgcGlwZWxpbmUgZmlsdGVyLiANCg0KQWN0 dWFsbHksIEkgdGhpbmsgd2Ugc2hvdWxkIGFkZCAnaW5jbHVkZScsJ2V4Y2x1ZGUnIGFuZCAnYmVn aW4nIGtleXdvcmRzIA0KdG8gZXhwcmVzcyBpdC4gDQoNCkJ1dCBmb3IgYmFja3dhcmRzIGNvbXBh dGliaWxpdHkgLCBJIGFkZCBmaWx0ZXIgYXMgc3Vic3RhdGVtZW50IG9mIHBhdHRlcm4gDQp0byBl eHByZXNzIGZpbHRlciB0eXBlLg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCiJuZXRtb2QiIDxuZXRt b2QtYm91bmNlc0BpZXRmLm9yZz4g0LTT2iAyMDE0LTA5LTExIDIwOjE0OjI0Og0KDQo+IE1hcnRp biBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiANCj4gt6K8/sjLOiAgIm5ldG1vZCIgPG5ldG1v ZC1ib3VuY2VzQGlldGYub3JnPg0KPiANCj4gMjAxNC0wOS0xMSAyMDoxNA0KPiANCj4gytW8/sjL DQo+IA0KPiBqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUsIA0KPiANCj4gs63L zQ0KPiANCj4gbmV0bW9kQGlldGYub3JnDQo+IA0KPiDW98ziDQo+IA0KPiBbbmV0bW9kXSBZMjMg LSBzdXBwb3J0IG5lZ2F0aXZlIHBhdHRlcm5zIGFzIHN0cmluZyByZXN0cmljdGlvbnMNCj4gDQo+ IEhpLA0KPiANCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2Jz LXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+IElmIHlvdSBkaXNhZ3JlZSB3aXRoIGFueSBvZiB0 aGUgZm9sbG93aW5nIHByb3Bvc2VkIHJlc29sdXRpb25zLCBwbGVhc2UNCj4gPiBzcGVhayB1cCBh cyBzb29uIGFzIHBvc3NpYmxlIGJ1dCBubyBsYXRlciB0aGFuIFNlcHRlbWJlciAxNiAoc28gdGhh dA0KPiA+IHdlIGhhdmUgdGhlIGlucHV0IGJlZm9yZSB0aGUgZmFjZS10by1mYWNlIGludGVyaW0g bWVldGluZyBzdGFydHMpLiBJZg0KPiA+IHlvdSB3YW50IHRvIHJhaXNlIGEgY29uY2VybiwgcGxl YXNlIHN0YXJ0IGEgdGhyZWF0IHdpdGggdGhlIGlzc3VlDQo+ID4gaWRlbnRpZmllciBpbiB0aGUg c3ViamVjdCBsaW5lLg0KPiANCj4gSSBjb3VsZG4ndCBmaW5kIGFueSByZWFzb25pbmcgYmVoaW5k IHRoZSBwcm9wb3NhbCB0byBhZG9wdCBZMjMtMDIgaW4NCj4gdGhlIG1pbnV0ZXMuDQo+IA0KPiBJ IHByZWZlciB0aGUgc3ludGF4IGluIFkyMy0wMToNCj4gDQo+ICAgICAgICBleGNsdWRlLXBhdHRl cm4gJ1t4WF1bbU1dW2xMXS4qJzsNCj4gDQo+IA0KPiBUaGUgY3VycmVudCAicGF0dGVybiIgc3Rh dGVtZW50IGlzIGRlZmluZWQgYXM6DQo+IA0KPiAgICBJdCBpcyB1c2VkIHRvIHJlc3RyaWN0IHRo ZSBidWlsdC1pbiB0eXBlICJzdHJpbmciLCBvciB0eXBlcyBkZXJpdmVkDQo+ICAgIGZyb20gInN0 cmluZyIsIHRvIHZhbHVlcyB0aGF0IG1hdGNoIHRoZSBwYXR0ZXJuLg0KPiANCj4gV2l0aCBZMjMt MDEsIHRoaXMgZG9lc24ndCBjaGFuZ2UuDQo+IA0KPiBIb3dldmVyLCB3aXRoIHRoZSBzeW50YXgg cHJvcG9zZWQgaW4gWTIzLTAyOg0KPiANCj4gICAgICAgICBwYXR0ZXJuICdbeFhdW21NXVtsTF0u Kicgew0KPiAgICAgICAgICAgZmlsdGVyIGV4Y2x1ZGU7DQo+ICAgICAgICAgfQ0KPiANCj4gdGhl IG1lYW5pbmcgb2YgJ3BhdHRlcm4nIGNoYW5nZXMgZGVwZW5kaW5nIG9uIHRoZSB2YWx1ZSBvZiB0 aGUNCj4gc3Vic3RhdGVtZW50ICJmaWx0ZXIiLg0KPiANCj4gDQo+IEFsc28gSSB0aGluayB0aGUg d29yZCAiZmlsdGVyIiBpcyBub3QgdmVyeSBkZXNjcmlwdGl2ZS4gIEZpbHRlcmluZw0KPiBzb3Vu ZHMgbGlrZSBhIHByb2Nlc3MsIGJ1dCB0aGUgdHlwZSByZXN0cmljdGlvbiBzdGF0ZW1lbnQgZGVm aW5lcyB0aGUNCj4gdmFsdWUgc3BhY2Ugb2YgdGhlIHR5cGUuDQo+IA0KPiANCj4gDQo+IA0KPiAv bWFydGluDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5ldG1vZEBpZXRmLm9yZw0KPiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwg YW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZpbGVnZWQg YW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUgdXNlIG9m IHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNpcGllbnQs IGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhlciBkaXNz ZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0cmljdGx5 IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBs ZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg== --=_alternative 0005BA4948257D51_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgJ3BhdHRlcm4nIGp1c3QgZGVm aW5lIGEgcmVndWxhcg0KZXhwcmVzc2lvbi4gJ3BhdHRlcm4nIGl0c2VsZiBzaG91bGQgPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5oYXMgbm8gYW55IG1lYW5pbmcg b2YgZmlsdGVyIHR5cGUuIExpa2UNCnBpcGVsaW5lIGluIHVuaXgsIHVuaXggdXNlIHwge2luY2x1 ZGUgfCBleGNsdWRlIHwgYmVnaW59ICZsdDtwYXR0ZXJuJmd0Ow0KdG8gPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbXBsZW1lbnQgcGlwZWxpbmUgZmlsdGVyLiA8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkFjdHVhbGx5 LCBJIHRoaW5rIHdlIHNob3VsZCBhZGQgJ2luY2x1ZGUnLCdleGNsdWRlJw0KYW5kICdiZWdpbicg a2V5d29yZHMgdG8gZXhwcmVzcyBpdC4gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj5CdXQgZm9yIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5ICwgSQ0KYWRk IGZpbHRlciBhcyBzdWJzdGF0ZW1lbnQgb2YgcGF0dGVybiB0byBleHByZXNzIGZpbHRlciB0eXBl Ljxicj4NCjwvZm9udD4NCjx0YWJsZT4NCjx0cj4NCjx0ZD4NCjx0ZD48Zm9udCBzaXplPTE+PGJy Pg0KPC9mb250Pg0KPHRhYmxlPg0KPHRyPg0KPHRkPg0KPHRyPg0KPHRkPg0KPHRyPg0KPHRkPg0K PHRyPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZxdW90O25ldG1vZCZxdW90OyAmbHQ7bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcm Z3Q7DQrQtNPaIDIwMTQtMDktMTEgMjA6MTQ6MjQ6PGJyPg0KPGJyPg0KJmd0OyBNYXJ0aW4gQmpv cmtsdW5kICZsdDttYmpAdGFpbC1mLmNvbSZndDsgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ILeivP7IyzogJm5ic3A7JnF1b3Q7bmV0bW9kJnF1b3Q7ICZsdDtuZXRtb2Qt Ym91bmNlc0BpZXRmLm9yZyZndDs8YnI+DQomZ3Q7IDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyAyMDE0LTA5LTExIDIwOjE0PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5 LmRlLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyCz rcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgbmV0 bW9kQGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4N CiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IFtuZXRtb2RdIFkyMyAtIHN1cHBvcnQgbmVnYXRpdmUgcGF0dGVybnMgYXMgc3RyaW5nIHJl c3RyaWN0aW9uczwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCndyb3RlOjxicj4NCiZndDsg Jmd0OyBJZiB5b3UgZGlzYWdyZWUgd2l0aCBhbnkgb2YgdGhlIGZvbGxvd2luZyBwcm9wb3NlZCBy ZXNvbHV0aW9ucywNCnBsZWFzZTxicj4NCiZndDsgJmd0OyBzcGVhayB1cCBhcyBzb29uIGFzIHBv c3NpYmxlIGJ1dCBubyBsYXRlciB0aGFuIFNlcHRlbWJlciAxNiAoc28NCnRoYXQ8YnI+DQomZ3Q7 ICZndDsgd2UgaGF2ZSB0aGUgaW5wdXQgYmVmb3JlIHRoZSBmYWNlLXRvLWZhY2UgaW50ZXJpbSBt ZWV0aW5nIHN0YXJ0cykuDQpJZjxicj4NCiZndDsgJmd0OyB5b3Ugd2FudCB0byByYWlzZSBhIGNv bmNlcm4sIHBsZWFzZSBzdGFydCBhIHRocmVhdCB3aXRoIHRoZSBpc3N1ZTxicj4NCiZndDsgJmd0 OyBpZGVudGlmaWVyIGluIHRoZSBzdWJqZWN0IGxpbmUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkg Y291bGRuJ3QgZmluZCBhbnkgcmVhc29uaW5nIGJlaGluZCB0aGUgcHJvcG9zYWwgdG8gYWRvcHQg WTIzLTAyDQppbjxicj4NCiZndDsgdGhlIG1pbnV0ZXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkg cHJlZmVyIHRoZSBzeW50YXggaW4gWTIzLTAxOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDtleGNsdWRlLXBhdHRlcm4gJ1t4WF1bbU1dW2xMXS4qJzs8YnI+ DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGUgY3VycmVudCAmcXVvdDtwYXR0ZXJuJnF1 b3Q7IHN0YXRlbWVudCBpcyBkZWZpbmVkIGFzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7SXQgaXMgdXNlZCB0byByZXN0cmljdCB0aGUgYnVpbHQtaW4gdHlwZSAmcXVvdDtzdHJp bmcmcXVvdDssDQpvciB0eXBlcyBkZXJpdmVkPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ZnJvbSAm cXVvdDtzdHJpbmcmcXVvdDssIHRvIHZhbHVlcyB0aGF0IG1hdGNoIHRoZSBwYXR0ZXJuLjxicj4N CiZndDsgPGJyPg0KJmd0OyBXaXRoIFkyMy0wMSwgdGhpcyBkb2Vzbid0IGNoYW5nZS48YnI+DQom Z3Q7IDxicj4NCiZndDsgSG93ZXZlciwgd2l0aCB0aGUgc3ludGF4IHByb3Bvc2VkIGluIFkyMy0w Mjo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHBhdHRl cm4gJ1t4WF1bbU1dW2xMXS4qJyB7PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IGZpbHRlciBleGNsdWRlOzxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IH08YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhlIG1lYW5pbmcgb2YgJ3BhdHRlcm4nIGNo YW5nZXMgZGVwZW5kaW5nIG9uIHRoZSB2YWx1ZSBvZiB0aGU8YnI+DQomZ3Q7IHN1YnN0YXRlbWVu dCAmcXVvdDtmaWx0ZXImcXVvdDsuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWxz byBJIHRoaW5rIHRoZSB3b3JkICZxdW90O2ZpbHRlciZxdW90OyBpcyBub3QgdmVyeSBkZXNjcmlw dGl2ZS4NCiZuYnNwO0ZpbHRlcmluZzxicj4NCiZndDsgc291bmRzIGxpa2UgYSBwcm9jZXNzLCBi dXQgdGhlIHR5cGUgcmVzdHJpY3Rpb24gc3RhdGVtZW50IGRlZmluZXMNCnRoZTxicj4NCiZndDsg dmFsdWUgc3BhY2Ugb2YgdGhlIHR5cGUuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC9tYXJ0aW48YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IG5ldG1v ZCBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IG5ldG1vZEBpZXRmLm9yZzxicj4NCiZndDsgPC9mb250 PjwvdHQ+PGEgaHJlZj1odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1v ZD48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v bmV0bW9kPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+PGJyPg0KPC9mb250PjwvdHQ+ DQoNCjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFu eSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25m aWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRk cmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlz Y2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlv biBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJp dGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVs ZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQoN Cjxicj48cHJlPjxmb250IGNvbG9yPSJibHVlIj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkg Tm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAoYW5kIGFueSBh dHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFuZCBjb25maWRl bnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0aGUgYWRkcmVz c2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBhbnkgZGlzY2xv c3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2VtaW5hdGlvbiBv ciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBwcm9oaWJpdGVk LiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVhc2UgZGVsZXRl IGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQoNCjwvZm9udD48L3ByZT48YnI+DQo= --=_alternative 0005BA4948257D51_=-- From nobody Fri Sep 12 01:08:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 081081A067B for ; Fri, 12 Sep 2014 01:08:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jd_hdUgorPvD for ; Fri, 12 Sep 2014 01:08:20 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBC471A059F for ; Fri, 12 Sep 2014 01:04:24 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-f0-5412a8ea2c52 Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 55.E9.02247.AE8A2145; Fri, 12 Sep 2014 10:03:54 +0200 (CEST) Received: from [159.107.197.75] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.174.1; Fri, 12 Sep 2014 10:03:54 +0200 Message-ID: <5412A8E9.3070006@ericsson.com> Date: Fri, 12 Sep 2014 10:03:53 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ladislav Lhotka , Juergen Schoenwaelder , References: <20140903111127.GA79883@elstar.local> In-Reply-To: Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrELMWRmVeSWpSXmKPExsUyM+Jvje6rFUIhBpObdS2ubvzJaHFh1Vw2 i/kXG1kdmD2WLPnJ5LHhgKfHpst3GAOYo7hsUlJzMstSi/TtErgy7r57zFJwk6Niw78tLA2M Z9i6GDk5JARMJPbsfwhli0lcuLceyObiEBI4yiix5PtvVghnDaNE075jjCBVvALaEv/m9bCC 2CwCqhJ7Js8D62YTMJKY2n+eBcQWFYiSuHOpnxWiXlDi5MwnYHERgTKJ378XgdnCAvISXz+s BqsREvCU2HhpJVMXIwcHp4CKxI13iiBhZgFbiQtzrrNA2PIS29/OYYYo15B4eOEv6wRGgVlI NsxC0jILScsCRuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIGBenDLb6sdjAefOx5iFOBg VOLhTbASDBFiTSwrrsw9xCjNwaIkzrvw3LxgIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYzB bhKNkpm32uWMeNL/79k42WKtXb/LYdWrea+6/8t1slqXFk1UF5xxhGt751JjyZfHf7EWKW3T VPRhOHpYL8yQPYFl2xZetzKvqE+Xwn8yRNplTpDyLNhtvin3ROSMty4GE7bt3be76aPIqy93 Ny2avf/64hkyUzVucS6/8081p+py4KKDQi+VWIozEg21mIuKEwGReRXrNQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/U4L8pbtFkU62GnjXW1pfFv-zK0I Subject: Re: [netmod] issue Y10 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:08:27 -0000 Hello, Many of our enumerations have less than 10 enums. For such cases a complete lists of all new values might be the most readable solution. It avoids the need to always look up the original enum. Balazs On 2014-09-11 15:56, Ladislav Lhotka wrote: > Juergen Schoenwaelder writes: >> 2014-07-02 meeting action: LL to write down another syntax proposal >> and MB to expand Y10-01. > I don't remember exactly what idea I had regarding syntax but I think it had to > do with: > - the ability to specify ranges > - the possibility of excluding specified enums > > So maybe instead of the "subset" statement as proposed in Y10-02, we > could allow a sequence of "include" and "exclude" statements. For example: > > include "Mercury .. Mars, Uranus .. Pluto"; > > or, equivalently, > > exclude "Jupiter, Saturn"; > > Lada > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Fri Sep 12 01:57:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DDD3A1A0696 for ; Fri, 12 Sep 2014 01:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 IEgmzsFTYVqn for ; Fri, 12 Sep 2014 01:57:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41C7F1A0547 for ; Fri, 12 Sep 2014 01:57:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B24011352; Fri, 12 Sep 2014 10:56:59 +0200 (CEST) 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 yi-2MDR54Fva; Fri, 12 Sep 2014 10:56:38 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 12 Sep 2014 10:56:59 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F303A20036; Fri, 12 Sep 2014 10:56:58 +0200 (CEST) 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 LVy_62AwNVmW; Fri, 12 Sep 2014 10:56:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38F0F20035; Fri, 12 Sep 2014 10:56:57 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1B3052E6352A; Fri, 12 Sep 2014 10:56:57 +0200 (CEST) Date: Fri, 12 Sep 2014 10:56:56 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140912085656.GB5479@elstar.local> Mail-Followup-To: Martin Bjorklund , netmod@ietf.org References: <20140903111127.GA79883@elstar.local> <20140911.141424.1774159467797949262.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140911.141424.1774159467797949262.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kpfWocWlEZtlCeKSxh68JHtMHMQ Cc: netmod@ietf.org Subject: Re: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 08:57:04 -0000 On Thu, Sep 11, 2014 at 02:14:24PM +0200, Martin Bjorklund wrote: > Hi, > > Juergen Schoenwaelder wrote: > > If you disagree with any of the following proposed resolutions, please > > speak up as soon as possible but no later than September 16 (so that > > we have the input before the face-to-face interim meeting starts). If > > you want to raise a concern, please start a threat with the issue > > identifier in the subject line. > > I couldn't find any reasoning behind the proposal to adopt Y23-02 in > the minutes. > > I prefer the syntax in Y23-01: > > exclude-pattern '[xX][mM][lL].*'; > > > The current "pattern" statement is defined as: > > It is used to restrict the built-in type "string", or types derived > from "string", to values that match the pattern. > > With Y23-01, this doesn't change. > > However, with the syntax proposed in Y23-02: > > pattern '[xX][mM][lL].*' { > filter exclude; > } > > the meaning of 'pattern' changes depending on the value of the > substatement "filter". But without a filter substatement, the semantics are the same as in YANG 1.0. Note that if we set the bar very high here, then other issues can likely be closed quickly as well. ;-) > Also I think the word "filter" is not very descriptive. Filtering > sounds like a process, but the type restriction statement defines the > value space of the type. Yes, "filter" may not be the best word. One advantage of using substatements is that doing so allows to add more modifiers easily (should the WG decide this is useful). For example, another popular modifier is to ignore case. With 'modifiers', we could easily have pattern 'xml.*' { modifier exclude; modifier ignore-case; } while the approach of introducing separate statements would lead to a total of 4 statements (pattern, exclude-pattern, ignore-case-pattern, ignore-case-exclude-pattern). /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 Fri Sep 12 02:12:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76E4C1A069B for ; Fri, 12 Sep 2014 02:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 C-jVEf0g6Tsp for ; Fri, 12 Sep 2014 02:12:03 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8C3691A0422 for ; Fri, 12 Sep 2014 02:12:03 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 74C2C128097C; Fri, 12 Sep 2014 11:12:02 +0200 (CEST) Date: Fri, 12 Sep 2014 11:12:02 +0200 (CEST) Message-Id: <20140912.111202.1472773086721150489.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140912085656.GB5479@elstar.local> References: <20140903111127.GA79883@elstar.local> <20140911.141424.1774159467797949262.mbj@tail-f.com> <20140912085656.GB5479@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bODoGPd2QyPCKkpS8C_me3rXH60 Cc: netmod@ietf.org Subject: Re: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:12:09 -0000 Juergen Schoenwaelder wrote: > On Thu, Sep 11, 2014 at 02:14:24PM +0200, Martin Bjorklund wrote: > > Hi, > > > > Juergen Schoenwaelder wrote: > > > If you disagree with any of the following proposed resolutions, please > > > speak up as soon as possible but no later than September 16 (so that > > > we have the input before the face-to-face interim meeting starts). If > > > you want to raise a concern, please start a threat with the issue > > > identifier in the subject line. > > > > I couldn't find any reasoning behind the proposal to adopt Y23-02 in > > the minutes. > > > > I prefer the syntax in Y23-01: > > > > exclude-pattern '[xX][mM][lL].*'; > > > > > > The current "pattern" statement is defined as: > > > > It is used to restrict the built-in type "string", or types derived > > from "string", to values that match the pattern. > > > > With Y23-01, this doesn't change. > > > > However, with the syntax proposed in Y23-02: > > > > pattern '[xX][mM][lL].*' { > > filter exclude; > > } > > > > the meaning of 'pattern' changes depending on the value of the > > substatement "filter". > > But without a filter substatement, the semantics are the same as in > YANG 1.0. Note that if we set the bar very high here, then other > issues can likely be closed quickly as well. ;-) > > > Also I think the word "filter" is not very descriptive. Filtering > > sounds like a process, but the type restriction statement defines the > > value space of the type. > > Yes, "filter" may not be the best word. One advantage of using > substatements is that doing so allows to add more modifiers easily > (should the WG decide this is useful). For example, another popular > modifier is to ignore case. With 'modifiers', we could easily have > > pattern 'xml.*' { > modifier exclude; > modifier ignore-case; > } I like the name 'modifier'! Should it be: modifier exclude; or modifier negate; ? /martin From nobody Fri Sep 12 02:30:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2AEF1A06A8 for ; Fri, 12 Sep 2014 02:29:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 QaovonJqQUuO for ; Fri, 12 Sep 2014 02:29:52 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 349B41A0643 for ; Fri, 12 Sep 2014 02:29:46 -0700 (PDT) Received: from pluto.hedeland.org (h194n2-hy-a32.ias.bredband.telia.com [81.228.176.194]) by mail.tail-f.com (Postfix) with ESMTPSA id 7FE4C12809A8; Fri, 12 Sep 2014 11:29:45 +0200 (CEST) Message-ID: <5412BD09.700@tail-f.com> Date: Fri, 12 Sep 2014 11:29:45 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:17.0) Gecko/20130428 Thunderbird/17.0.5 MIME-Version: 1.0 To: Martin Bjorklund References: <20140903111127.GA79883@elstar.local> <20140911.141424.1774159467797949262.mbj@tail-f.com> <20140912085656.GB5479@elstar.local> <20140912.111202.1472773086721150489.mbj@tail-f.com> In-Reply-To: <20140912.111202.1472773086721150489.mbj@tail-f.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/J4aec2JG82C2p9BqpQJUbCrWthU Cc: netmod@ietf.org Subject: Re: [netmod] Y23 - support negative patterns as string restrictions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:29:57 -0000 On 2014-09-12 11:12, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: >> On Thu, Sep 11, 2014 at 02:14:24PM +0200, Martin Bjorklund wrote: >>> Hi, >>> >>> Juergen Schoenwaelder wrote: >>>> If you disagree with any of the following proposed resolutions, please >>>> speak up as soon as possible but no later than September 16 (so that >>>> we have the input before the face-to-face interim meeting starts). If >>>> you want to raise a concern, please start a threat with the issue >>>> identifier in the subject line. >>> >>> I couldn't find any reasoning behind the proposal to adopt Y23-02 in >>> the minutes. >>> >>> I prefer the syntax in Y23-01: >>> >>> exclude-pattern '[xX][mM][lL].*'; >>> >>> >>> The current "pattern" statement is defined as: >>> >>> It is used to restrict the built-in type "string", or types derived >>> from "string", to values that match the pattern. >>> >>> With Y23-01, this doesn't change. >>> >>> However, with the syntax proposed in Y23-02: >>> >>> pattern '[xX][mM][lL].*' { >>> filter exclude; >>> } >>> >>> the meaning of 'pattern' changes depending on the value of the >>> substatement "filter". >> >> But without a filter substatement, the semantics are the same as in >> YANG 1.0. Note that if we set the bar very high here, then other >> issues can likely be closed quickly as well. ;-) >> >>> Also I think the word "filter" is not very descriptive. Filtering >>> sounds like a process, but the type restriction statement defines the >>> value space of the type. >> >> Yes, "filter" may not be the best word. One advantage of using >> substatements is that doing so allows to add more modifiers easily >> (should the WG decide this is useful). For example, another popular >> modifier is to ignore case. With 'modifiers', we could easily have >> >> pattern 'xml.*' { >> modifier exclude; >> modifier ignore-case; >> } > > I like the name 'modifier'! +1! FWIW, matches perl terminology. > Should it be: > > modifier exclude; > > or > > modifier negate; > > ? or modifier invert[-match]; - as in grep(3)...? No, I think I prefer 'negate' if we're having a vote.:-) --Per From nobody Fri Sep 12 02:40:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19EDB1A06AB for ; Fri, 12 Sep 2014 02:40:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 HAAdZY_XS1Kz for ; Fri, 12 Sep 2014 02:40:36 -0700 (PDT) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98411A06B5 for ; Fri, 12 Sep 2014 02:40:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25246; q=dns/txt; s=iport; t=1410514836; x=1411724436; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to; bh=Ot+MYY/4y+AI2BRjrKIi2tP83m4GyHNcKiBu/FHlbfE=; b=FBwvea7R/sdEpN6+i7xnL0rbaPajNk+mXT39bt7+KMLJTrRQGivq9ZSM 0wofnCU5kAr/VsTd6cxrhPFf/X0EeZif0n5B2tp5E6dNenYPsvYHVd7HD 4eejSswbR1CzYqatOJu4aHN3tZg5X+JyWrnFWPyhoij3Vqxl8nQK2zEe4 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnQFAMO+ElStJssW/2dsb2JhbABfg2BXgnyFW8AVh0wBgSZ4hAMBAQEEI0sKARALEQMBAgEJFgEHAwICCQMCAQIBDyUJCAYNAQUCAQEFiCUDEQ2oDo5qDYZ+AReNIIFLEAIBPhEHBgOCcIFTBZYAhHOCEIFfhWWHOoY9g2M7LwGCTgEBAQ X-IronPort-AV: E=Sophos;i="5.04,511,1406592000"; d="scan'208,217";a="175239984" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP; 12 Sep 2014 09:40:32 +0000 Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8C9eWMC028558; Fri, 12 Sep 2014 09:40:32 GMT Message-ID: <5412BF90.9050001@cisco.com> Date: Fri, 12 Sep 2014 11:40:32 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Chris Lonvick References: <20140722150553.GB12083@elstar.local> <53CEA093.2070000@cisco.com> <20140730145856.GL29365@pfrc> <53D90D95.5090001@cisco.com> <54101802.5060507@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080902000903010807000300" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/otSruh2bkMc9c6NqaMBCD1gIPQk Cc: "rgerhards@hq.adiscon.com" , "netmod@ietf.org" Subject: Re: [netmod] Syslog YANG Model Presentation X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 09:40:40 -0000 This is a multi-part message in MIME format. --------------080902000903010807000300 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Chris, > Hi Benoit and all, > > I'm not exactly sure what you're asking. I agree with Rainer that the > ID is well written. > > I am not subscribed to the mailing list and have not been following > the discussions so please take my comments with a grain of salt. :-) > > If you're asking if draft-wildes-netmod-syslog-model needs to be > expanded to include the available options resulting from the IETF work > on syslog (which is more than 5424, 5425, and 5426), then I would say > that it does not. It looks to me (I'm not overly familiar with Yang) > that what is described in the ID is equivalent to what can be defined > in a current syslog.conf configuration. IMHO, that should be good > enough at this time to publish the document as an informational RFC > (as it's classified now). This was actually my question. Thanks. > > If you're asking if a potential draft-ietf-netmod-syslog-model > (standards track) should be more thorough to include the available > options resulting from the IETF work on syslog, then I'll give a > definite "maybe". :-) There doesn't appear to be anything in > draft-wildes... that conflicts with the syslog HEADER in 5424; > therefore, it should just work. The Structured-Data is used in the > PAYLOAD and that can't be configured. What would be missing in the > configuration is the specification of the transport. You mention 5425 > and 5426, but there are others: > 5425 - TLS (recommended) > 5426 - UDP (not so much recommended but greatly in use) > 6012 - DTLS > 6587 - TCP (the IESG said to NOT use this, but it is in use :-) > If the document were to be expanded, it would need to include some > very complex rules. For example: > - Facilities 4 and 10 with severities (0-6) send to > sec-logger.example.com via 5425 > - Facility 2 with severities (0-3) send to mail-logger.example.com > via 5426 > - All Facilities with severities (0-2) send to > central-logger.example.com via 6012 > As far as I know, the specification of the transport cannot currently > be configured in generic syslog.conf configurations. I believe that > the implementations that are using something other than UDP are doing > it on a "one off" basis. So, IMHO, trying to force that into a > standards track document shouldn't be done at this time. Ok > > If you _are_ looking for draft-ietf-netmod-syslog-model, I would > suggest using draft-wildes... and add something about assuming that > the selection of a transport is implementation specific at this time, > and that a future revision of the model may include the option to > specify the transport(s). Ok. > > And just since I'm going on and on (and on...), the syslog WG did not > complete a MIB on syslog. If anyone is interested, we left off here: > http://tools.ietf.org/html/draft-ietf-syslog-device-mib-17 > > Just a nit to the authors, the last sentence of page 3 reads: > Optional features are used to specified fields that are not present in > all vendor configurations. > Perhaps s/specified/specify (but honestly I think that the sentence needs to be rewritten). > > And, if I'm totally off base on what you're asking, then please disregard. :-) This is exactly what I wanted to find out. Regards, Benoit > > Best regards, > Chris > > On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise > wrote: > > Dear all, > > As I understand, the conclusion from this email thread is that the > syslog YANG model must support the options for RFC 5424, RFC 5425, > and RFC 5426 > > Regards, Benoit >> Hi, >> The very brief background: >> - the syslog WG was chartered under the Security Area to secure >> the protocol >> - the BEEP work never took off so we rechartered and found that >> we needed to make changes to the protocol itself >> - in making the changes, Rainer Gerhards proposed structured data >> and the WG liked that >> - 5424 makes use of structured data but there are few >> implementations that strictly adhere to the changes made to the >> packet header >> >> On the other hand, everyone likes structured data and I've seen >> it used in many places. As far as I know, there have been no >> efforts to standardize structured data but people are using it in >> many places because it is very versatile and efficient, and it >> gets the job done. :-) >> >> I've been working (off and on and hopefully more 'on' soon) on an >> ID that explains how non-standardized messages have been conveyed >> in IETF-documented protocols. It will need a couple of more >> revisions before it's ready for consideration for publication but >> you may get some ideas from it. >> https://datatracker.ietf.org/doc/draft-lonvick-private-tax/?include_text=1 >> >> Best regards, >> Chris >> >> >> On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy >> Management) > > wrote: >> >> Benoit, >> We (GE MDS) support 5424/5425/5426 structured messages on >> our products (with vendor specific structured-data). >> >> -Jeff Lange >> >> >> >> From: Benoit Claise > > >> >> Date: Wednesday, July 30, 2014 at 11:21 AM >> To: Jeffrey Haas > > >> >> Cc: "lonvick@gmail.com >> > >" > > >>, Kiran Agrahara Sreenivasa >> > > >>, "netmod@ietf.org >> > >" > > >>, "rgerhards@hq.adiscon.com >> > >" > > >> >> Subject: Re: [netmod] Syslog YANG Model Presentation >> >> Jeff, >> >> Thanks. >> So I guess we need to support RFC 5424, RFC 5425, and RFC >> 5426 configuration in the YANG model, right? >> You use only vendor specific STRUCTURED-DATA? Because I don't >> see many in the IANA >> registry, >> and http://tools.ietf.org/html/rfc5424#section-9.2 requests >> IANA registration. >> >> If my memory serves me well (I copied a couple of old >> timers), the STRUCTURED-DATA goal was to standardize the >> syslog message content in the industry, but that did not happen. >> >> Regards, Benoit >> >> Benoit, >> >> On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote: >> >> >> PS: I think you should also refer to the standards-track >> version of >> SYSLOG (RFC 5424) in the references and perhaps filters >> should >> also be able to operate on structured content. >> >> >> Is RFC 5424 actually deployed? >> >> >> Juniper has supported it for years. >> >> -- Jeff >> . >> >> >> >> > > --------------080902000903010807000300 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
Hi Chris,
Hi Benoit and all,

I'm not exactly sure what you're asking.  I agree with Rainer that the ID is well written.

I am not subscribed to the mailing list and have not been following the discussions so please take my comments with a grain of salt.  :-)

If you're asking if draft-wildes-netmod-syslog-model needs to be expanded to include the available options resulting from the IETF work on syslog (which is more than 5424, 5425, and 5426), then I would say that it does not.  It looks to me (I'm not overly familiar with Yang) that what is described in the ID is equivalent to what can be defined in a current syslog.conf configuration.  IMHO, that should be good enough at this time to publish the document as an informational RFC (as it's classified now).
This was actually my question. Thanks.

If you're asking if a potential draft-ietf-netmod-syslog-model (standards track) should be more thorough to include the available options resulting from the IETF work on syslog, then I'll give a definite "maybe".  :-)  There doesn't appear to be anything in draft-wildes... that conflicts with the syslog HEADER in 5424; therefore, it should just work.  The Structured-Data is used in the PAYLOAD and that can't be configured.  What would be missing in the configuration is the specification of the transport.  You mention 5425 and 5426, but there are others:
5425 - TLS (recommended)
5426 - UDP (not so much recommended but greatly in use)
6012 - DTLS
6587 - TCP (the IESG said to NOT use this, but it is in use :-)
If the document were to be expanded, it would need to include some very complex rules.  For example:
 - Facilities 4 and 10 with severities (0-6) send to sec-logger.example.com via 5425
 - Facility 2 with severities (0-3) send to mail-logger.example.com via 5426
 - All Facilities with severities (0-2) send to central-logger.example.com via 6012
As far as I know, the specification of the transport cannot currently be configured in generic syslog.conf configurations.  I believe that the implementations that are using something other than UDP are doing it on a "one off" basis.  So, IMHO, trying to force that into a standards track document shouldn't be done at this time.
Ok

If you _are_ looking for draft-ietf-netmod-syslog-model, I would suggest using draft-wildes... and add something about assuming that the selection of a transport is implementation specific at this time, and that a future revision of the model may include the option to specify the transport(s).
Ok.

And just since I'm going on and on (and on...), the syslog WG did not complete a MIB on syslog.  If anyone is interested, we left off here:

Just a nit to the authors, the last sentence of page 3 reads:
Optional features are used to specified fields that are not present in 
   all vendor configurations.
Perhaps s/specified/specify (but honestly I think that the sentence needs to be rewritten).


And, if I'm totally off base on what you're asking, then please disregard.  :-)
This is exactly what I wanted to find out.

Regards, Benoit


Best regards,
Chris

On Wed, Sep 10, 2014 at 2:21 AM, Benoit Claise <bclaise@cisco.com> wrote:
Dear all,

As I understand, the conclusion from this email thread is that the syslog YANG model must support the options for RFC 5424, RFC 5425, and RFC 5426

Regards, Benoit
Hi,
The very brief background:
- the syslog WG was chartered under the Security Area to secure the protocol
- the BEEP work never took off so we rechartered and found that we needed to make changes to the protocol itself
- in making the changes, Rainer Gerhards proposed structured data and the WG liked that
- 5424 makes use of structured data but there are few implementations that strictly adhere to the changes made to the packet header

On the other hand, everyone likes structured data and I've seen it used in many places.  As far as I know, there have been no efforts to standardize structured data but people are using it in many places because it is very versatile and efficient, and it gets the job done.  :-)

I've been working (off and on and hopefully more 'on' soon) on an ID that explains how non-standardized messages have been conveyed in IETF-documented protocols.  It will need a couple of more revisions before it's ready for consideration for publication but you may get some ideas from it.

Best regards,
Chris


On Thu, Jul 31, 2014 at 6:19 AM, Lange, Jeffrey K (GE Energy Management) <jeffrey.K.lange@ge.com> wrote:
Benoit,
  We (GE MDS) support 5424/5425/5426 structured messages on our products (with vendor specific structured-data).

-Jeff Lange



From: Benoit Claise <bclaise@cisco.com<mailto:bclaise@cisco.com>>
Date: Wednesday, July 30, 2014 at 11:21 AM
To: Jeffrey Haas <jhaas@pfrc.org<mailto:jhaas@pfrc.org>>
Cc: "lonvick@gmail.com<mailto:lonvick@gmail.com>" <lonvick@gmail.com<mailto:lonvick@gmail.com>>, Kiran Agrahara Sreenivasa <kkoushik@Brocade.com<mailto:kkoushik@Brocade.com>>, "netmod@ietf.org<mailto:netmod@ietf.org>" <netmod@ietf.org<mailto:netmod@ietf.org>>, "rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>" <rgerhards@hq.adiscon.com<mailto:rgerhards@hq.adiscon.com>>
Subject: Re: [netmod] Syslog YANG Model Presentation

Jeff,

Thanks.
So I guess we need to support RFC 5424, RFC 5425, and RFC 5426 configuration in the YANG model, right?
You use only vendor specific STRUCTURED-DATA? Because I don't see many in the IANA registry<http://www.iana.org/assignments/syslog-parameters/syslog-parameters.xhtml#syslog-parameters-4>, and http://tools.ietf.org/html/rfc5424#section-9.2 requests IANA registration.

If my memory serves me well (I copied a couple of old timers), the STRUCTURED-DATA goal was to standardize the syslog message content in the industry, but that did not happen.

Regards, Benoit

Benoit,

On Tue, Jul 22, 2014 at 01:34:11PM -0400, Benoit Claise wrote:


PS: I think you should also refer to the standards-track version of
    SYSLOG (RFC 5424) in the references and perhaps filters should
    also be able to operate on structured content.


Is RFC 5424 actually deployed?


Juniper has supported it for years.

-- Jeff
.







--------------080902000903010807000300-- From nobody Fri Sep 12 03:27:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F7811A06AF for ; Fri, 12 Sep 2014 03:27:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mOXZOHMwfonV for ; Fri, 12 Sep 2014 03:27:53 -0700 (PDT) Received: from epost.nunatak.no (epost.nunatak.no [193.200.93.202]) by ietfa.amsl.com (Postfix) with ESMTP id 816B61A03C5 for ; Fri, 12 Sep 2014 03:27:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by epost.nunatak.no (Postfix) with ESMTP id 778883ED811D; Fri, 12 Sep 2014 12:30:25 +0200 (CEST) X-Virus-Scanned: amavisd-new at nunatak.no Received: from epost.nunatak.no ([127.0.0.1]) by localhost (epost.nunatak.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1tLP92CxtcX; Fri, 12 Sep 2014 12:30:20 +0200 (CEST) Received: from [192.168.209.127] (unknown [192.168.209.127]) by epost.nunatak.no (Postfix) with ESMTPSA id 741543EC8014; Fri, 12 Sep 2014 12:30:20 +0200 (CEST) Message-ID: <5412CA9A.6020204@transpacket.com> Date: Fri, 12 Sep 2014 12:27:38 +0200 From: Vladimir Vassilev User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Andy Bierman References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> <20140911075604.GA2241@elstar.local> <54119140.8080003@transpacket.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/C4DSqVhpiwIE7UMIxrS1Y5hTx64 Cc: "netmod@ietf.org" Subject: Re: [netmod] yang json and anyxml X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 10:27:56 -0000 On 09/11/2014 04:35 PM, Andy Bierman wrote: > Recursive groupings would not work in YANG like they do in real languages > because the "uses" is automatically expanded. It needs to be manually > instantiated by the client or server at run-time, not automatically expanded > at compile-time. At this point, YANG might as well provide abstract and > concrete classes, > instead of a crude hack like anyxml. > But thanks for demonstrating my point, which is that you are not using > anyxml > to comply with its interoperable semantics. You are creating restrictions on > the content that are not conveyed to the client. I agree leaving groupings non-recursive makes groupings implementation work simpler and resolvable at compile-time. I agree introduction of concrete classes is proper solution for the recursive model problem. At the moment one can either write a really big yang file with e.g. 128!! recursive container definitions if one accepts limit to the depth of the tree or just live with an anyxml like in the example and leave a hole in the schema not conveying the restrictions to the client. > > A "standard client" should be able to send any valid XML in an edit, > and that will be accepted as "anyxml". How many people are using anyxml > as it is defined, not hacking it to provide a missing feature in YANG? > Except for the and cases there are very few places we use "anyxml" to represent configuration for tools which are not modelled in YANG. For those cases I do not see any advantage of the complexity of translation to json and keeping some relevance to the properties of the parent container e.g. namespace. That is just too much intelligence to ask from the protocol layer. anyxml is a string type with restrictions defined by the xml standard where properties as e.g. identation may or may not be preserved. Adding "anyjson" (wonder why this was never mentioned) and "root" (a private case of concrete class definition) is good step to resolve the confusion. As for the netconf protocol I think it should communicate anyxml as xml string and anyjson as json string. While "root" is encoded with the underlying choice of protocol encoding. For the case of recursive models we as users will just have to leave a hole in the schema with either "anyxml" or "anyjson" or write big recursive yang files until/if ever more flexible concrete class definitions are introduced. > Andy > > Vladimir > > > > > module oids { > > namespace "http://transpacket.com/ns/__oids > "; > > prefix "oids"; > > description > "OID resolver module."; > > revision 2012-11-01 { > description > "Initial revision"; > } > > typedef type-enumeration { > type enumeration { > enum ASN_INTEGER; > enum ASN_OCTET_STR; > enum ASN_COUNTER; > enum ASN_COUNTER64; > enum ASN_GAUGE; > enum ASN_OID; > } > } > grouping oids-grouping { > > list oid { > key num; > leaf num { > type uint16; > description "oid num"; > } > container contents { > choice leaf-container { > case oid-leaf { > leaf type { > type type-enumeration; > } > leaf value { > type string; > description "String value"; > } > } > case oid-container { > //container oids { > // uses oids-grouping; > //} > anyxml oids; > } > } > } > } > } > > container oids { > config false; > > description > "Top-level container for all oid database objects."; > > uses oids-grouping; > } > } > > > Vladimir > > From nobody Fri Sep 12 10:56:25 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B75FE1A6F85 for ; Fri, 12 Sep 2014 10:56:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 AkY4X_R7YXLv for ; Fri, 12 Sep 2014 10:56:21 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 79C581A8029 for ; Fri, 12 Sep 2014 10:56:20 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E272E8F7; Fri, 12 Sep 2014 19:56:18 +0200 (CEST) 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 ELPi0nTZfRX5; Fri, 12 Sep 2014 19:55:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 12 Sep 2014 19:56:18 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 45BD620038; Fri, 12 Sep 2014 19:56:18 +0200 (CEST) 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 oMpfXD-WUS8i; Fri, 12 Sep 2014 19:56:17 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9CE820035; Fri, 12 Sep 2014 19:56:16 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D712F2E640C1; Fri, 12 Sep 2014 19:56:16 +0200 (CEST) Date: Fri, 12 Sep 2014 19:56:16 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140912175616.GC6633@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , "netmod@ietf.org" References: <20140911.204455.383704477.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5V8MGdTQ02HsywymkgWjuiWYS70 Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 17:56:24 -0000 On Thu, Sep 11, 2014 at 12:49:00PM -0700, Andy Bierman wrote: > > If the data modeler does not intend to give value or position any meaning, > then how do they do that with auto-numbering? That is the problem I > have with keeping it in YANG 1.1. (You can't turn it off.) > I think this is an important observation. There are cases where auto numbering gets into the way (and we understand this all too well since the timezone experience). If there would be a way to turn this auto numbering off, we could perhaps all be happy. And even then, I personally would still recommend to assign explicit values where values are meaningful, just to be sure that updates do not cause bad side effects. For me, auto numbering sounded like a good idea back in a day but it is actually brittle wrt. module updates. For small enums, it is not much effort to assign explicit values. Large enums usually tend to be updated more frequently and this is where auto numbering becomes handy and problematic at the same time. /js (speaking as technical contributor) PS: Sure, if someone maps a subset of YANG to SNMP, then clearly a predictable numeric value is needed. The question is whether YANG is required to supply it. -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Fri Sep 12 14:09:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 164711A009A; Fri, 12 Sep 2014 14:09:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 BGbiEwZUfdbu; Fri, 12 Sep 2014 14:09:14 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 7020C1A00F0; Fri, 12 Sep 2014 14:09:14 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 145DDC3DF; Fri, 12 Sep 2014 17:09:14 -0400 (EDT) Date: Fri, 12 Sep 2014 17:09:13 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org Message-ID: <20140912210913.GA10692@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XDHzDUfPPlciawiTy9C9j30qx9I Subject: [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Sep 2014 21:09:20 -0000 With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 From nobody Sat Sep 13 12:12:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04D341A0086 for ; Sat, 13 Sep 2014 12:12:06 -0700 (PDT) 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 GAuPG_qytIkh for ; Sat, 13 Sep 2014 12:12:04 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A12AD1A0081 for ; Sat, 13 Sep 2014 12:12:04 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id v10so2146013qac.41 for ; Sat, 13 Sep 2014 12:12:03 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=czKn4zPKB516CxZNQFgIL3AcSbKo2haZiejYmvey6hg=; b=QNdKXvIUGSkT9qIzu/UnYpwGqwsof8g/qMLshIbzjWm6jLESKmBVoTIrYpVYADNCD0 8c55WDGW5NywZpfiflEZwJp59sIoTWMY/IPeOT/VNB3vDtPXVp9g3YZSBqcdYNAaYjb6 dLMn5dZbPM3Lakhb7w5nMWH9Aek5LX6bre/ebzVJE9MMgqs4+uV1bszz5wA+E61efL2F qlMwohgRZp25+xbQzb/2MecEr6YoafC80YoxL5tRYJajGiEe3ZCFsIOXUehghkRgQ2SA R6qRpgqcTRajYn54wKarFxcngmPhMLzQiHgUlSwFpiWI/PWy1242boIsnZ3hXMgGYxwX 9QXA== X-Gm-Message-State: ALoCoQnIFc9blVQcMaF+PRvWBfMwtIE50T3vMS5pbQ0tdDN9W+u/ZssB4mBUnQt19xozrQZQKbKx MIME-Version: 1.0 X-Received: by 10.224.73.132 with SMTP id q4mr24046379qaj.78.1410635523714; Sat, 13 Sep 2014 12:12:03 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sat, 13 Sep 2014 12:12:03 -0700 (PDT) Date: Sat, 13 Sep 2014 12:12:03 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c3e1424c8fc80502f72d92 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iY9YmlGyVbQ5f5iMmE6N6jj29x8 Subject: [netmod] rfc6087bis Issues List X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Sep 2014 19:12:06 -0000 --001a11c3e1424c8fc80502f72d92 Content-Type: text/plain; charset=ISO-8859-1 Hi, I created an issue tracker on github for the YANG Usage Guidelines update. https://github.com/netmod-wg/rfc6087bis/issues I will try to get the document code in the repo soon, but for now only the issue tracker is being used. If you find any new issues with the draft, please try to enter them in the tracker. http://www.ietf.org/id/draft-ietf-netmod-rfc6087bis-00.txt Andy --001a11c3e1424c8fc80502f72d92 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I created an issue tracker on githu= b for the YANG Usage Guidelines update.


I will try to get the= document code in the repo soon, but for now
only the issue track= er is being used.

If you find any new issues with = the draft, please try to enter them in
the tracker.
http://www.ietf.org/id/draft-ietf-netmod-rfc6087bis-00.txt
<= /div>


Andy


<= /div>
--001a11c3e1424c8fc80502f72d92-- From nobody Sun Sep 14 00:52:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E42421A02CF for ; Sun, 14 Sep 2014 00:52:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 Gv4H6H4kZolG for ; Sun, 14 Sep 2014 00:52:14 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 17BEB1A02A0 for ; Sun, 14 Sep 2014 00:52:14 -0700 (PDT) Received: from [172.29.2.202] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 3EBD913F69B; Sun, 14 Sep 2014 09:52:12 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410681132; bh=UrNhYIofbh4U6FTlPCoZiFbVqerWW4011njO7/n7AiY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Iuz9bQVcRtQilO2vgbhXQxJcnvm7TPUKTlSYSSnQbpZIsU8BasNCqMI3lKXhtp9xA OFqU6iP+EZRRVu5xb5cDnO/UVY4DBnLjIlmBNmexAhxVbnrwF7tRz0TY2YknIUTHQ3 ToxY3a/2ibhU5PlJX4maIMzeFFAm5MrjEzuQ+dQU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140912175616.GC6633@elstar.local> Date: Sun, 14 Sep 2014 09:52:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140911.204455.383704477.mbj@tail-f.com> <20140912175616.GC6633@elstar.local> To: =?iso-8859-1?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rOE_TS8k7AviVa8pjMyeLt6a4VI Cc: "netmod@ietf.org" Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 07:52:16 -0000 On 12 Sep 2014, at 19:56, Juergen Schoenwaelder = wrote: > On Thu, Sep 11, 2014 at 12:49:00PM -0700, Andy Bierman wrote: >>=20 >> If the data modeler does not intend to give value or position any = meaning, >> then how do they do that with auto-numbering? That is the problem I >> have with keeping it in YANG 1.1. (You can't turn it off.) >>=20 >=20 > I think this is an important observation. There are cases where auto > numbering gets into the way (and we understand this all too well since > the timezone experience). If there would be a way to turn this > auto numbering off, we could perhaps all be happy. So could this way be a new modifier of the enumeration type? For = example, auto-numbering true/false; If the default value is true, then the semantics of YANG 1.0 = enumerations is preserved, and new enumerations can use whatever is = appropriate. Lada >=20 > And even then, I personally would still recommend to assign explicit > values where values are meaningful, just to be sure that updates do > not cause bad side effects. For me, auto numbering sounded like a good > idea back in a day but it is actually brittle wrt. module updates. For > small enums, it is not much effort to assign explicit values. Large > enums usually tend to be updated more frequently and this is where > auto numbering becomes handy and problematic at the same time. >=20 > /js (speaking as technical contributor) >=20 > PS: Sure, if someone maps a subset of YANG to SNMP, then clearly a > predictable numeric value is needed. The question is whether YANG > is required to supply it. >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Sep 14 10:29:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4A8A1A00ED for ; Sun, 14 Sep 2014 10:29:48 -0700 (PDT) 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 1nCDZprOF4QN for ; Sun, 14 Sep 2014 10:29:47 -0700 (PDT) Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAEE41A00EC for ; Sun, 14 Sep 2014 10:29:46 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id r5so2998349qcx.26 for ; Sun, 14 Sep 2014 10:29:46 -0700 (PDT) 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=Oy33HP2GvH89axOGZsNVn0gs3xqEynC9jRnGCqG5Zdg=; b=dQfPLBVWLNKgr2kuqJhu/abSJ/ZYisPX43D6mJ3EpySkAvQvBv/kkCcHiHdG4OVOzg QIgLSTG7b4zmLryzkm5R7EuPj8nkgHfp5/4u4i1sSGdi5+iTMNscqLHIcqvXqTksSbCo YdEvODg+c0XjVzdzNgCZuDpiRNOo8YQWuHIFN9gGqVwbYpV0podEFdCbdmiEuh3/DhkP FLEmYKprFaszNlWMVo9GUh0fqpTxTUCNy0OFIZnYbV5EMtL3aa37QxaKdo1kxcsiOdwb GXwmmm0zCjgK4HXNudR4KvS5r1JTGYxp56D/IGfJyUTnjPbj1vz1o+bVavIzlBxhtMS4 HoQw== X-Gm-Message-State: ALoCoQnOy6/gY/navFhGBuJNaBO4o7/IVCB75TmjY57NhtPS+/t/ngnjNAlHKTCJT61I+ckedtux MIME-Version: 1.0 X-Received: by 10.140.98.166 with SMTP id o35mr30688069qge.21.1410715785930; Sun, 14 Sep 2014 10:29:45 -0700 (PDT) Received: by 10.140.83.137 with HTTP; Sun, 14 Sep 2014 10:29:45 -0700 (PDT) In-Reply-To: <8460893C-ADF6-472A-913F-E6A29313F0EB@nic.cz> References: <20140911120337.26309.17065.idtracker@ietfa.amsl.com> <8460893C-ADF6-472A-913F-E6A29313F0EB@nic.cz> Date: Sun, 14 Sep 2014 10:29:45 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a1139304e4cbdeb050309dd34 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NjrFbnNoedhRxxqNZjgWBGdc368 Cc: NETMOD Working Group Subject: Re: [netmod] Fwd: New Version Notification for draft-lhotka-netmod-yang-metadata-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Sep 2014 17:29:48 -0000 --001a1139304e4cbdeb050309dd34 Content-Type: text/plain; charset=ISO-8859-1 On Thu, Sep 11, 2014 at 5:21 AM, Ladislav Lhotka wrote: > Hi, > > this draft tries to cover all aspects of defining and using metadata > annotations with YANG-based data, including their encoding in both XML and > JSON. Consequently, I plan to remove the section on metadata encoding from > draft-ietf-netmod-yang-json. > > I reviewed this draft and it looks good. I did not find any problems with the mappings or the YANG extension, and plan to implement soon. > Lada > > Andy > Begin forwarded message: > > > From: internet-drafts@ietf.org > > Subject: New Version Notification for > draft-lhotka-netmod-yang-metadata-00.txt > > Date: 11 Sep 2014 14:03:37 GMT+2 > > To: Ladislav Lhotka , "Ladislav Lhotka" > > > > > > A new version of I-D, draft-lhotka-netmod-yang-metadata-00.txt > > has been successfully submitted by Ladislav Lhotka and posted to the > > IETF repository. > > > > Name: draft-lhotka-netmod-yang-metadata > > Revision: 00 > > Title: Defining and Using Metadata with YANG > > Document date: 2014-09-11 > > Group: Individual Submission > > Pages: 14 > > URL: > http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-metadata-00.txt > > Status: > https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-metadata/ > > Htmlized: > http://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 > > > > > > Abstract: > > This document defines a YANG extension statement that allows for > > defining metadata annotions in YANG modules. The document also > > specifies the encoding of annotations and rules for annotating > > instances of YANG data nodes. > > > > > > > > > > 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 > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a1139304e4cbdeb050309dd34 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Thu, Sep 11, 2014 at 5:21 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Hi,

this draft tries to cover all aspects of defining and using metadata annota= tions with YANG-based data, including their encoding in both XML and JSON. = Consequently, I plan to remove the section on metadata encoding from draft-= ietf-netmod-yang-json.


I reviewed this draft and it looks goo= d. =A0I did not find any problems with the mappings
or the YANG e= xtension, and plan to implement soon.
=A0
=A0
Lada


Andy
=A0
Begin forwarded message:

> From: internet-drafts@ietf= .org
> Subject: New Version Notification for draft-lhotka-netmod-yang-metadat= a-00.txt
> Date: 11 Sep 2014 14:03:37 GMT+2
> To: Ladislav Lhotka <lhotka@nic.cz= >, "Ladislav Lhotka" <= lhotka@nic.cz>
>
>
> A new version of I-D, draft-lhotka-netmod-yang-metadata-00.txt
> has been successfully submitted by Ladislav Lhotka and posted to the > IETF repository.
>
> Name:=A0 =A0 =A0 =A0 =A0draft-lhotka-netmod-yang-metadata
> Revision:=A0 =A0 =A000
> Title:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Defining and Using Metadata with= YANG
> Document date:=A0 =A0 =A0 =A0 2014-09-11
> Group:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Individual Submission
> Pages:=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 14
> URL:=A0 =A0 =A0 =A0 =A0 =A0 http://www= .ietf.org/internet-drafts/draft-lhotka-netmod-yang-metadata-00.txt
> Status:=A0 =A0 =A0 =A0 =A0https://datatracker.i= etf.org/doc/draft-lhotka-netmod-yang-metadata/
> Htmlized:=A0 =A0 =A0 =A0http://tools.ietf.org/html/= draft-lhotka-netmod-yang-metadata-00
>
>
> Abstract:
>=A0 =A0This document defines a YANG extension statement that allows for=
>=A0 =A0defining metadata annotions in YANG modules.=A0 The document als= o
>=A0 =A0specifies the encoding of annotations and rules for annotating >=A0 =A0instances of YANG data nodes.
>
>
>
>
> Please note that it may take a couple of minutes from the time of subm= ission
> until the htmlized version and diff are available at tools.ietf.org.
>
> The IETF Secretariat
>

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C




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

--001a1139304e4cbdeb050309dd34-- From nobody Sun Sep 14 22:41:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2E941A065D for ; Sun, 14 Sep 2014 22:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 mnyKqXXEp-cC for ; Sun, 14 Sep 2014 22:41:33 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4C51A064D for ; Sun, 14 Sep 2014 22:41:33 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 402F7140076; Mon, 15 Sep 2014 07:41:31 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410759691; bh=bBEZIHoJlky5Qurb0/8ARMTGn+YZ3CxTOYccjRIGr74=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ePYIJi8e6v3RL4HLAk12m0BB90YMdC9zxfIgVcxEQRVGAuINf+HIOSNGzpfsz5N+x 7uRcfdiGz+27whbylsSXtHunLvU+Uv6E5CHD1mWmmJjNJTjcd5rJxNB0zBDZU2dx8j 0Nmvk4z+cbYnCKDPfd0eEcqN7edyv7Pv6cw10iBU= Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 15 Sep 2014 07:41:30 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140911120337.26309.17065.idtracker@ietfa.amsl.com> <8460893C-ADF6-472A-913F-E6A29313F0EB@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4S4R_MT1jgasxOChImSfX4ZcUIc Cc: NETMOD Working Group Subject: Re: [netmod] New Version Notification for draft-lhotka-netmod-yang-metadata-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 05:41:36 -0000 On 14 Sep 2014, at 19:29, Andy Bierman wrote: >=20 >=20 > On Thu, Sep 11, 2014 at 5:21 AM, Ladislav Lhotka = wrote: > Hi, >=20 > this draft tries to cover all aspects of defining and using metadata = annotations with YANG-based data, including their encoding in both XML = and JSON. Consequently, I plan to remove the section on metadata = encoding from draft-ietf-netmod-yang-json. >=20 >=20 > I reviewed this draft and it looks good. I did not find any problems = with the mappings > or the YANG extension, and plan to implement soon. Thanks. I have already implemented it in the DSDL plugin of pyang - the = generated RELAX NG schema can now validate instance documents containing = annotations. Lada=20 > =20 > =20 > Lada >=20 >=20 > Andy > =20 > Begin forwarded message: >=20 > > From: internet-drafts@ietf.org > > Subject: New Version Notification for = draft-lhotka-netmod-yang-metadata-00.txt > > Date: 11 Sep 2014 14:03:37 GMT+2 > > To: Ladislav Lhotka , "Ladislav Lhotka" = > > > > > > A new version of I-D, draft-lhotka-netmod-yang-metadata-00.txt > > has been successfully submitted by Ladislav Lhotka and posted to the > > IETF repository. > > > > Name: draft-lhotka-netmod-yang-metadata > > Revision: 00 > > Title: Defining and Using Metadata with YANG > > Document date: 2014-09-11 > > Group: Individual Submission > > Pages: 14 > > URL: = http://www.ietf.org/internet-drafts/draft-lhotka-netmod-yang-metadata-00.t= xt > > Status: = https://datatracker.ietf.org/doc/draft-lhotka-netmod-yang-metadata/ > > Htmlized: = http://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 > > > > > > Abstract: > > This document defines a YANG extension statement that allows for > > defining metadata annotions in YANG modules. The document also > > specifies the encoding of annotations and rules for annotating > > instances of YANG data nodes. > > > > > > > > > > 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 > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 15 01:16:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0C551A0135 for ; Mon, 15 Sep 2014 01:16:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 9Yas2vcuUeio for ; Mon, 15 Sep 2014 01:16:22 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id CEB641A00FD for ; Mon, 15 Sep 2014 01:16:19 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 8479012807C0; Mon, 15 Sep 2014 10:16:14 +0200 (CEST) Date: Mon, 15 Sep 2014 10:16:14 +0200 (CEST) Message-Id: <20140915.101614.1058068659894833413.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <20140912175616.GC6633@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3Nb8LSGR1x3c2Ujerl47wP4uf9k Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:16:24 -0000 X-List-Received-Date: Mon, 15 Sep 2014 08:16:24 -0000 Ladislav Lhotka wrote: > > On 12 Sep 2014, at 19:56, Juergen Schoenwaelder > wrote: > > > On Thu, Sep 11, 2014 at 12:49:00PM -0700, Andy Bierman wrote: > >> > >> If the data modeler does not intend to give value or position any > >> meaning, > >> then how do they do that with auto-numbering? That is the problem I > >> have with keeping it in YANG 1.1. (You can't turn it off.) > >> > > > > I think this is an important observation. There are cases where auto > > numbering gets into the way (and we understand this all too well since > > the timezone experience). If there would be a way to turn this > > auto numbering off, we could perhaps all be happy. > > So could this way be a new modifier of the enumeration type? For > example, > > auto-numbering true/false; The problem with this is that the code needs to be written to support both cases. I prefer a solution where we know that all enums have values and all bits have positions - i.e., like today in YANG 1.0. If the WG decides that this is problematic, I think it is better to remove the values and positions than trying to compromise and have both. /martin From nobody Mon Sep 15 01:44:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 17B341A0105 for ; Mon, 15 Sep 2014 01:44:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.003 X-Spam-Level: X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-1.652] 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 8l6RnrHON0a0 for ; Mon, 15 Sep 2014 01:44:18 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 516631A01F9 for ; Mon, 15 Sep 2014 01:44:17 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 23A6313FB92; Mon, 15 Sep 2014 10:44:14 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410770654; bh=YOfgw6zeTQyqp9KipCcCyYs4mjBeELA6TTCqfXoH8SQ=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=hVkjoiC3r035wTFqb2ClwAnwHHMF/iLYaQDzlfs/yurVIkWXb+L1JtDSacNm+rSjS 5X8clEzWGXAknMDXtmoL4QlQ/83IJxM/B5n2Ttvr/lGuk+tssqNUZK+VhWSjKA/JXc APojd2D43u/Lkb+S7OfzupIEslf9O9sfAaFu+wP8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140915.101614.1058068659894833413.mbj@tail-f.com> Date: Mon, 15 Sep 2014 10:44:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140912175616.GC6633@elstar.local> <20140915.101614.1058068659894833413.mbj@tail-f.com> To: =?windows-1252?Q?Martin_Bj=F6rklund?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QM5U4p8XqtSNihBTEbJx0jh0RuQ Cc: netmod@ietf.org Subject: Re: [netmod] Y25 - make enum numbering purely informative and optional X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 08:44:20 -0000 On 15 Sep 2014, at 10:16, Martin Bjorklund wrote: > Ladislav Lhotka wrote: >>=20 >> On 12 Sep 2014, at 19:56, Juergen Schoenwaelder >> wrote: >>=20 >>> On Thu, Sep 11, 2014 at 12:49:00PM -0700, Andy Bierman wrote: >>>>=20 >>>> If the data modeler does not intend to give value or position any >>>> meaning, >>>> then how do they do that with auto-numbering? That is the problem = I >>>> have with keeping it in YANG 1.1. (You can't turn it off.) >>>>=20 >>>=20 >>> I think this is an important observation. There are cases where auto >>> numbering gets into the way (and we understand this all too well = since >>> the timezone experience). If there would be a way to turn this >>> auto numbering off, we could perhaps all be happy. >>=20 >> So could this way be a new modifier of the enumeration type? For >> example, >>=20 >> auto-numbering true/false; >=20 > The problem with this is that the code needs to be written to support > both cases. I prefer a solution where we know that all enums Right, but we are in fact dealing with two different types. The = numbering procedure is only a technicality, the substance is that you = have either an extensible (unordered) set of enums or append-only list. = There seem to be use cases for both.=20 I don=92t think it actually makes much of a difference for code, it=92s = more about restrictions for module updates. > have values and all bits have positions - i.e., like today in YANG > 1.0. If the WG decides that this is problematic, I think it is better > to remove the values and positions than trying to compromise and have > both. I=92d be fine with this, too, but the charter rules for YANG 1.1 prevent = us from removing the =93value=94 and =93position=94 statements. Lada >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 15 06:22:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F12EB1A0348; Mon, 15 Sep 2014 06:22:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.554 X-Spam-Level: X-Spam-Status: No, score=-3.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 CmlNXXKY1Te5; Mon, 15 Sep 2014 06:21:59 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6971F1A0326; Mon, 15 Sep 2014 06:21:59 -0700 (PDT) Received: from [192.168.1.150] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 901E7288CCDF; Mon, 15 Sep 2014 09:21:58 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Mon, 15 Sep 2014 09:21:54 -0400 Message-Id: <0271678E-C85C-4115-89B8-392BCBEB86BF@lucidvision.com> References: <20140829064207.GA63316@elstar.local> To: sarikaya@ieee.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I0C7ysP71VWhYQz1sgJMzlpcNzI Cc: "i2rs@ietf.org" , netmod@ietf.org Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:22:01 -0000 --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Netconf is called Netconf; it has nothing to do with SNMP. =20 --Tom On Sep 15, 2014:9:17 AM, at 9:17 AM, Behcet Sarikaya = wrote: > Hi Juergen, >=20 > What is Netconf protocol called? SNMP v4? >=20 > Regards, >=20 > Behcet >=20 > On Fri, Aug 29, 2014 at 1:42 AM, Juergen Schoenwaelder > wrote: >> Hi, >>=20 >> the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one >> of the agenda items is to work on any requirements I2RS might have = for >> YANG 1.1. For this, we need a clear definition of what the I2RS >> requirements are for YANG 1.1, ideally posted as an I-D a few days >> before the interim meeting so that people can come prepared. This >> means there are ~15 days left to produce such a requirements writeup. >>=20 >> /js >>=20 >> [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany >> Fax: +49 421 200 3103 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUFufyAAoJEPcO+I7eiUJZFjkQALJqD/MTFN+Ymm7EzPe2+dxU HR7K2Jus8VSqCxzWzaNCMUimxZSZRqjY2S4QHEc/scfVLP3Kqp03uS20GzBIEXiQ qeOy2/BG0TaHzGyXSK+SqER58+yRNiU9/Q1UMXoV7LN4QBurI6FF+RgL+K16jR8o BiGOlJki7K9z5Wmo+1NDQpuP+DDJZn4B1KtQ8+GBhKoxjK7xKqqt9ZunTAxr4NXO 0TL7WUdDV7cCMdV3zsTq2I4quuZSc7MJ5MEeGk0HIU2Rq+sipP84GiFEkZRhEJG/ 3j3ensdgEbOH0JdggshF2/gjRisSVHXlntUn8C8cHBmXw9lCWBs6SziGwx/hS8e2 Nd6YqiMMuup8JGk6dvhQVbEbuQ9rwaLIgdn+8U15tqQC/o6do6DiAUdJ9Db5ZqcV dEtvlugBQ3H6yjbLctqB2K32r+DtsP66WHH02JG/bMjBJfJ+5b5BpPieFCaKb+cq 0tE0gD9TziwhyGNinyUz0fnSXBp61+X7Tez9N6RzluRm6HX2IKH+zH15JQe5dtwb 4aQKERYddiFpnGuiRndSaNgFCUTbC+Wqacsx66TYHZBHot+FmWuxnjyl8uKfRuBg wQvO3ZWKXY/941pyOivktgncayEYJNfoEVX5c9DDjiLZOBR/ozG68JxiG+vy3Yzb 5g8B49zXPQ44e21s9/Oi =lo3G -----END PGP SIGNATURE----- --Apple-Mail=_14EE3BEA-5E1F-49C9-B5B9-F5CBA757E4D1-- From nobody Mon Sep 15 06:39:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30EF41A0348; Mon, 15 Sep 2014 06:17:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.75 X-Spam-Level: X-Spam-Status: No, score=-1.75 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=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 0B1img4qXRQB; Mon, 15 Sep 2014 06:17:52 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8EC641A0345; Mon, 15 Sep 2014 06:17:51 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id el20so4568854lab.33 for ; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:reply-to:in-reply-to:references:date:message-id :subject:from:to:content-type; bh=4rx7/yHBtxSDEtfR7bWDXAUGpzf6bf3dtn+iN8dXT4s=; b=YSLXajfsbI3M2dC0QxAZriA0mYfa7s3wWpyW5nU6P/f2KPkuEofVAjqvZo9VvdyHud x3w4CoNua++2xS8yjFn2UgXDF25Rt1CjbrjpG3awHdLo0SM+h4esouR1+W4NVk3VaBNH o8lZoGk6mak8dO6MzSA4UaEVQ15G9XH56rpg8tzJdizPu33xADZ+LZfKb7h/O59ak8wm VNpdcsmhXdj8pS7SoFJImpTQC9Okm3MNb5AXfjjzv5Yr9wMe31ZbovErAo8zcOVuQ/Lr gexiCZ/8FNPB2Qch31Y89jX36Q3WSpl4vUIfpUJOGE15D37UP9q5r1LAmM/LGpoqAXm+ GPKg== MIME-Version: 1.0 X-Received: by 10.152.121.8 with SMTP id lg8mr2871851lab.98.1410787069904; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) Received: by 10.114.77.37 with HTTP; Mon, 15 Sep 2014 06:17:49 -0700 (PDT) In-Reply-To: <20140829064207.GA63316@elstar.local> References: <20140829064207.GA63316@elstar.local> Date: Mon, 15 Sep 2014 08:17:49 -0500 Message-ID: From: Behcet Sarikaya To: Juergen Schoenwaelder , "i2rs@ietf.org" , netmod@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/__m2UT0Ql6P34woPmITaJenz9xw X-Mailman-Approved-At: Mon, 15 Sep 2014 06:39:46 -0700 Subject: Re: [netmod] [i2rs] netmod interim and i2rs requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: sarikaya@ieee.org List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:17:53 -0000 Hi Juergen, What is Netconf protocol called? SNMP v4? Regards, Behcet On Fri, Aug 29, 2014 at 1:42 AM, Juergen Schoenwaelder wrote: > Hi, > > the NETMOD WG is holding an interim meeting on Sep. 17/18 [1] and one > of the agenda items is to work on any requirements I2RS might have for > YANG 1.1. For this, we need a clear definition of what the I2RS > requirements are for YANG 1.1, ideally posted as an I-D a few days > before the interim meeting so that people can come prepared. This > means there are ~15 days left to produce such a requirements writeup. > > /js > > [1] https://www.ietf.org/meeting/interim/netmod-2014-09-17.txt > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Mon Sep 15 06:45:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 19C031A034B for ; Mon, 15 Sep 2014 06:45:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.303 X-Spam-Level: X-Spam-Status: No, score=-1.303 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 1jnCKCFIJzGA for ; Mon, 15 Sep 2014 06:45:07 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE9C1A035C for ; Mon, 15 Sep 2014 06:45:07 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BE6706F for ; Mon, 15 Sep 2014 15:45:05 +0200 (CEST) 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 LHjE5C9tohos for ; Mon, 15 Sep 2014 15:45:02 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Mon, 15 Sep 2014 15:45:05 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 24CBE20035 for ; Mon, 15 Sep 2014 15:45:05 +0200 (CEST) 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 kkLTg-pYTgzb; Mon, 15 Sep 2014 15:45:04 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1EB9620036; Mon, 15 Sep 2014 15:45:04 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B01472E655CC; Mon, 15 Sep 2014 15:45:02 +0200 (CEST) Date: Mon, 15 Sep 2014 15:45:01 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140915134501.GA12566@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SQ0LZcC1Zk6SmQT8s9hOjNvOcL4 Subject: [netmod] netmod interim meeting draft agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 13:45:10 -0000 Hi, I thought about running the upcoming interim meeting roughly like this: Wednesday 17: 09:00 Welcome and Agenda Bashing 09:10 YANG 1.1 (Conformance) 12:00 Lunch Break 13:00 YANG 1.1 (Conformance) 15:00 Coffee Break 15:30 YANG 1.1 (Conformance) 17:30 Summary of first day Thursday 18: 09:00 YANG 1.1 (I2RS support) 12:00 Lunch Break 13:00 YANG 1.1 (I2RS support) 15:00 Coffee Break 15:30 YANG 1.1 (other issues) 17:30 Summary of second day It is difficult to judge how long we need for the hard issues so we will likely move the topics as we go. The agenda essentially says we start conformance and then look at I2RS related issues and then if time left we go to the other open issues we have. /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 Sep 15 07:12:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 274C61A0362 for ; Mon, 15 Sep 2014 07:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xSPqTU22VY-H for ; Mon, 15 Sep 2014 07:11:52 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D19E71A0357 for ; Mon, 15 Sep 2014 07:11:51 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-9d-5416f3a5471e Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 0B.37.21334.5A3F6145; Mon, 15 Sep 2014 16:11:49 +0200 (CEST) Received: from [159.107.198.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.56) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 16:11:48 +0200 Message-ID: <5416F3A4.2050305@ericsson.com> Date: Mon, 15 Sep 2014 16:11:48 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Vladimir Vassilev , Andy Bierman , "netmod@ietf.org" References: <20140903121539.GD80206@elstar.local> <20140903.142651.75125438713641072.mbj@tail-f.com> <20140903125512.GF80206@elstar.local> <20140903.145908.2112909954639851720.mbj@tail-f.com> <20140911075604.GA2241@elstar.local> <54119140.8080003@transpacket.com> In-Reply-To: <54119140.8080003@transpacket.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrCLMWRmVeSWpSXmKPExsUyM+Jvje7Sz2IhBnuXK1o8ODKL3WL+xUZW i1Pzv7E6MHssWfKTyePqh5MsHi39F1kCmKO4bFJSczLLUov07RK4Ms7fnMxaME+q4vz3e6wN jL0CXYycHBICJhIPLp5mgrDFJC7cW8/WxcjFISRwlFHi2JYOJghnLaPE+ocPwKp4BbQlelsm soDYLAKqEr0zfjGD2GwCRhJT+8+DxUUFoiTuXOpnhagXlDg58wlYXESgSmJl11egeg4OYQF3 iYY5ghDzJzJLrL4MspmTg1NAX+LzxPlgu5gFbCUuzLnOAmHLS2x/Owdsl5CAhsTDC39ZJzAK zEKyYhaSlllIWhYwMq9iFC1OLS7OTTcy1kstykwuLs7P08tLLdnECAzWg1t+6+5gXP3a8RCj AAejEg/vgh1iIUKsiWXFlbmHGKU5WJTEeRedmxcsJJCeWJKanZpakFoUX1Sak1p8iJGJg1Oq gVHc32rC+dIffqfSja8KPEoUqaiR/p+wWiVwUQKXwA12vZi5Bj1XF8+XMpVhqYg4sHSutd1a q8RVCWaqrMtqFU7qTTJU6Jfw31G40c7bvPVm07ZN07ctdaiW/cZdfrexeu2dGSar9ndc6lO5 lyVzPkR0GWuswalP1zr/aD1VrlE91X82vDaRR4mlOCPRUIu5qDgRALfAV8k3AgAA Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/szUcfhUsbBP05r1-SozB9_nk0ko Subject: [netmod] Recursive containment [was: Re: yang json and anyxml] X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:11:59 -0000 Hello Vladimir, I have been arguing to have recursive containment for quite some time. Have a good number of use-cases to support. regards Balazs On 2014-09-11 14:10, Vladimir Vassilev wrote: > Hello, > > On 09/11/2014 10:20 AM, Andy Bierman wrote: > > This restriction matches the usage of the and > containers > > as the root of an edit or retrieval. This use-case does not have any > > holes in the schema tree. There are no nodes of unknown syntax > > and semantics allowed. > > > > There is one more use-case of anyxml that is not caused by holes in > the schema tree. Modelling of a recursive tree in YANG is currently > not possible due to the following sentence is RFC6020 7.11. The > grouping Statement - "A grouping MUST NOT reference itself, neither > directly nor indirectly through a chain of other groupings." > > A simple model of an OID tree illustrates the problem (check the "case > oid-container" part). In that case one has to use anyxml since the > deterministic option of using recursive grouping is illegal YANG. > There are certain advantages using such recursive models. Is there > reason for not removing the "A grouping MUST NOT reference itself..." > requirement and thus removing one more unnecessary use-case for anyxml > in YANG models? > > > module oids { > > namespace "http://transpacket.com/ns/oids"; > > prefix "oids"; > > description > "OID resolver module."; > > revision 2012-11-01 { > description > "Initial revision"; > } > > typedef type-enumeration { > type enumeration { > enum ASN_INTEGER; > enum ASN_OCTET_STR; > enum ASN_COUNTER; > enum ASN_COUNTER64; > enum ASN_GAUGE; > enum ASN_OID; > } > } > grouping oids-grouping { > > list oid { > key num; > leaf num { > type uint16; > description "oid num"; > } > container contents { > choice leaf-container { > case oid-leaf { > leaf type { > type type-enumeration; > } > leaf value { > type string; > description "String value"; > } > } > case oid-container { > //container oids { > // uses oids-grouping; > //} > anyxml oids; > } > } > } > } > } > > container oids { > config false; > > description > "Top-level container for all oid database objects."; > > uses oids-grouping; > } > } > > > Vladimir > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Sep 15 07:34:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D65F1A0369 for ; Mon, 15 Sep 2014 07:34:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwAKXI3xQuSh for ; Mon, 15 Sep 2014 07:34:55 -0700 (PDT) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB9D1A0363 for ; Mon, 15 Sep 2014 07:34:54 -0700 (PDT) X-AuditID: c1b4fb3a-f79da6d0000008c7-00-5416f90d5ae8 Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 05.99.02247.D09F6145; Mon, 15 Sep 2014 16:34:53 +0200 (CEST) Received: from [159.107.198.108] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.44) with Microsoft SMTP Server id 14.3.174.1; Mon, 15 Sep 2014 16:34:52 +0200 Message-ID: <5416F90C.5090606@ericsson.com> Date: Mon, 15 Sep 2014 16:34:52 +0200 From: Balazs Lengyel User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: References: <20140915134501.GA12566@elstar.local> In-Reply-To: <20140915134501.GA12566@elstar.local> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupjluLIzCtJLcpLzFFi42KZGfG3Rpf3p1iIwa1rwhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoEr43zbQ8aCp/wV3xfeZGxgbObuYuTkkBAwkei8u4wNwhaTuHBv PZgtJHCUUeLGap0uRi4gey2jxJIf85hAErwC2hIL+n4BFXFwsAioSszfFgkSZhMwkpjaf54F xBYViJK4c6mfFaJcUOLkzCdgcREBUYm9H86DxYUFLCVmTn/BCrHLUGLfubmMIDYn0JzLfx+x g9jMArYSF+ZcZ4Gw5SW2v53DDFGvIfHwwl/WCYwCs5CsmIWkZRaSlgWMzKsYRYtTi4tz042M 9FKLMpOLi/Pz9PJSSzYxAgPw4JbfVjsYDz53PMQowMGoxMO7YIdYiBBrYllxZe4hRmkOFiVx 3oXn5gULCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYMwV0HXd0MYvVj/vrUza+zuJvMKCnB1S xUxuqzMqF5QdVz7Ju+q75pf9E7sSLqfpbzXIbi/MvzXB84zuPeklgS3BHHnX92ofeXk1du7N 3QsOtuXOmsj2sK93oYqbrcjxHwe5xW/IPP5kz2ctv3p79upfU8/8U300dalgZ4fHjaP/l4kf Wnxa6qwSS3FGoqEWc1FxIgCPMztSIQIAAA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VcsZLe0iD_t-lmii4gEDte-c8Qo Subject: Re: [netmod] netmod interim meeting draft agenda X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 14:34:57 -0000 Hello Juergen, Some time ago I proposed adding actions to YANG: ==Balazs wrote ========== Re: [netmod] Issue Y36: associate RPCs AND notification with a data node Hello Juergen, We should declare this issue alive because IETF is about rough consensus and running code: - Rough consensus: Major players (Martin, Andy and also myself for Ericsson) indicated strong interest and support (at least for connecting RPCs, a.k.a. actions, to data nodes). That is at least a beginning for a consensus. - Running code: Tail-f, Ericsson, and probably Huawei already has implementations of actions. ... ================ I published a reasonable proposal, which didn't get any blocking comments, so I would like to discuss this on the interim. regards Balazs On 2014-09-15 15:45, Juergen Schoenwaelder wrote: > Hi, > > I thought about running the upcoming interim meeting roughly like this: > > Wednesday 17: 09:00 Welcome and Agenda Bashing > 09:10 YANG 1.1 (Conformance) > 12:00 Lunch Break > 13:00 YANG 1.1 (Conformance) > 15:00 Coffee Break > 15:30 YANG 1.1 (Conformance) > 17:30 Summary of first day > > Thursday 18: 09:00 YANG 1.1 (I2RS support) > 12:00 Lunch Break > 13:00 YANG 1.1 (I2RS support) > 15:00 Coffee Break > 15:30 YANG 1.1 (other issues) > 17:30 Summary of second day > > It is difficult to judge how long we need for the hard issues so we > will likely move the topics as we go. The agenda essentially says we > start conformance and then look at I2RS related issues and then if > time left we go to the other open issues we have. > > /js > -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist ECN: 831 7320 Tel: +36-1-437-7320 Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com From nobody Mon Sep 15 10:48:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4F8B1A87C0 for ; Mon, 15 Sep 2014 10:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 xK5ms5gf8Z1R for ; Mon, 15 Sep 2014 10:48:24 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1EBE1A882C for ; Mon, 15 Sep 2014 10:02:35 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 885DD724; Mon, 15 Sep 2014 19:02:34 +0200 (CEST) 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 Z8bt23byKL37; Mon, 15 Sep 2014 19:02:30 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Sep 2014 19:02:33 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id D99B820037; Mon, 15 Sep 2014 19:02:33 +0200 (CEST) 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 nBkkS4KoDIHD; Mon, 15 Sep 2014 19:02:32 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E0F120036; Mon, 15 Sep 2014 19:02:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3E5292E658F4; Mon, 15 Sep 2014 19:02:29 +0200 (CEST) Date: Mon, 15 Sep 2014 19:02:29 +0200 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20140915170229.GA13054@elstar.local> Mail-Followup-To: Andy Bierman , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/C2TDIXJhdfkbzSovd0kEvPE51v0 Cc: "netmod@ietf.org" Subject: Re: [netmod] rfc6087bis Issues List X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 17:48:28 -0000 On Sat, Sep 13, 2014 at 12:12:03PM -0700, Andy Bierman wrote: > Hi, > > I created an issue tracker on github for the YANG Usage Guidelines update. > > https://github.com/netmod-wg/rfc6087bis/issues > Great. Looking at the various YANG 1.1 minutes, I found: - Y27 "possible action to add guidelines how to go from current to deprecated to obsolete in RFC 6087bis" - Y36 "one could also think about guidelines on how to structure notifications to make resource identification easier" - Y06 "Guidelines should say better use single quotes for pattern." These may not all be actionable but perhaps still useful to track them. /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 Sep 15 12:25:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EC751A03F5 for ; Mon, 15 Sep 2014 12:25:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.952 X-Spam-Level: X-Spam-Status: No, score=-0.952 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RP_MATCHES_RCVD=-1.652, 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 efA1EKrutIFA for ; Mon, 15 Sep 2014 12:25:14 -0700 (PDT) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4E69F1A03EB for ; Mon, 15 Sep 2014 12:25:14 -0700 (PDT) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id rWTQ1o0030QuhwU5BXRD5P; Mon, 15 Sep 2014 19:25:13 +0000 Received: from JV6RVH1 ([67.189.237.137]) by omta02.westchester.pa.mail.comcast.net with comcast id rXRD1o0092yZEBF3NXRD2q; Mon, 15 Sep 2014 19:25:13 +0000 From: "David Harrington" To: , , Date: Mon, 15 Sep 2014 15:25:10 -0400 Message-ID: <01d701cfd11a$c3fcc030$4bf64090$@comcast.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac/RGLZ3mN8UP6S5RJie4vGNm6Vmbw== Content-Language: en-us DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1410809113; bh=EryVY9eBLAHluHLLBKAJxXYUrvsWsMp/LmUWx7KGOyo=; h=Received:Received:From:To:Subject:Date:Message-ID:MIME-Version: Content-Type; b=kEKt7nEoKwwlENUvlELoxmCf/ssAeIm3/OrzpuJtoRYB/a6m6me6cz3glDV9bE71/ 83DE+Nq/BS17HKWA3LRt5oEbhvuZCPV5uxUnKaVypR3WkZGUPAkEgLUwlaNCx652ii RDAXraO1zpYg2UAgkDPpfjWliuPzmdKPlYFOgRNmt/CSO270zSZ0N3H/h667pdvvrc 3Ko5cScoEdGbthCLdwtyY3otYV3OHOcr336u6QnHGLPEQKjYKTmSxW+SZeqfFoanmy P3dtvabLjTgD8IWEiXygUO9/wHLmq2nMSUGPeTF/bkDANMoDeBPIaQgVoYiUNJmLhr 0dH6iaetuiwwA== Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/0IZbUJrubry0TbUd6dMCdljEDP4 Subject: [netmod] YANG module for syslog X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Sep 2014 19:25:15 -0000 Hi, The syslog community came to the IETF a few years ago and asked for help standardizing and securing the syslog protocol. The result is the syslog standard defined in RFC5424. 5425, 5426, and 5427. Subsequent work has been done in RFC5674, 5675, and 5676 to correlate IETF syslog messages with X.733 alarms, and SNMP notifications. Subsequent work has been done in RFC5848 to secure syslog messages both in transit and "at rest". And subsequent work has been to extend the choices of protocol to carry syslog messages in RFC6012 and 6587. It would make much more sense for the IETF to standardize a YANG module for the IETF standard syslog, rather than one of the many variants that preceded standardization. David Harrington dbharrington@comcast.net +1-603-828-1401 From nobody Tue Sep 16 02:40:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37B2B1A020A; Tue, 16 Sep 2014 02:40:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 XphqotvWzSwE; Tue, 16 Sep 2014 02:40:12 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D76C1A01C3; Tue, 16 Sep 2014 02:40:12 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B69EB72D; Tue, 16 Sep 2014 11:40:10 +0200 (CEST) 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 A9-L0JwcBGgg; Tue, 16 Sep 2014 11:40:03 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 16 Sep 2014 11:40:10 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0028520035; Tue, 16 Sep 2014 11:40:10 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id j22Q_vi4bvbT; Tue, 16 Sep 2014 11:40:09 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C9A5020036; Tue, 16 Sep 2014 11:40:08 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E2EEE2E65EB7; Tue, 16 Sep 2014 11:40:07 +0200 (CEST) Date: Tue, 16 Sep 2014 11:40:07 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140916094007.GB14437@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140912210913.GA10692@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140912210913.GA10692@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fIXEvciBhKTk56qFtDCg638x6Ms Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 09:40:15 -0000 On Fri, Sep 12, 2014 at 05:09:13PM -0400, Jeffrey Haas wrote: > With some help from Kent, Dean and Alia, I've put together a rough first > draft of requirements I2RS has on netmod/netconf. It should be strongly > noted that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested > parties. > [...] > > Comments are appreciated. Flames are not unexpected. > Thanks Jeff for putting this together. Concerning section 2.1.1, I am not sure I agree with: The SSH transport does not mandate authentication be done; it is an optional feature. RFC 6242 says: The identity of the SSH server MUST be verified and authenticated by the SSH client according to local policy before password-based authentication data or any configuration or state data is sent to or received from the SSH server. The identity of the SSH client MUST also be verified and authenticated by the SSH server according to local policy to ensure that the incoming SSH client request is legitimate before any configuration or state data is sent to or received from the SSH client. Neither side should establish a NETCONF over SSH connection with an unknown, unexpected, or incorrect identity on the opposite side. I also think that NC over TLS requires that both sides authenticate and verify the certificates. I think as far as NETCONF is concerned, all transports do actually mutual authentication. Perhaps there is confusion here with RESTCONF where the current wording may be read as authentication is optional. But then, this is not past the IESG yet. ;-) /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 Sep 16 04:59:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 600E31A0695 for ; Tue, 16 Sep 2014 04:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.551 X-Spam-Level: X-Spam-Status: No, score=-8.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652] 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 DFKuzcwr95NE for ; Tue, 16 Sep 2014 04:59:55 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8DC01A068F for ; Tue, 16 Sep 2014 04:59:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlkLAFslGFSHCzIm/2dsb2JhbABggkcjI1Nbs2kBAQEBAQeeawGBFBYBAXiEBQEBAxIbXgEMCRVWJgEEGxqIHAGWBoRloF8YhXyGIQGCfINmgR0FkU2TLYRWiH6DXoI0gQIBAQE X-IronPort-AV: E=Sophos; i="5.04,534,1406606400"; d="scan'208,217"; a="82622748" Received: from unknown (HELO p-us1-erheast-smtpauth.us1.avaya.com) ([135.11.50.38]) by co300216-co-outbound.net.avaya.com with ESMTP; 16 Sep 2014 07:59:54 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC02.global.avaya.com) ([135.64.58.12]) by p-us1-erheast-out.us1.avaya.com with ESMTP/TLS/AES128-SHA; 16 Sep 2014 07:59:54 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC02.global.avaya.com ([135.64.58.12]) with mapi id 14.03.0174.001; Tue, 16 Sep 2014 13:59:53 +0200 From: "Romascanu, Dan (Dan)" To: "netmod@ietf.org" Thread-Topic: Webex information for the interim Thread-Index: Ac/RpbY8bMbtjyAKRRKh8FJnTrra0A== Date: Tue, 16 Sep 2014 11:59:51 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.46] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Dc-YEB7hVhIZMAnTD0o04VncgAM Subject: [netmod] Webex information for the interim X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 11:59:57 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I apologize if this was already posted, but I cannot find the remote partic= ipation (Webex) information for the netmod interim. Thanks and Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I apologize if this was already posted, but I cannot= find the remote participation (Webex) information for the netmod interim.

 

Thanks and Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7AZFFEXMB04globa_-- From nobody Tue Sep 16 05:29:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4F1A0426; Tue, 16 Sep 2014 05:29:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.901 X-Spam-Level: X-Spam-Status: No, score=-99.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.652, USER_IN_WHITELIST=-100] 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 wof4B2vAiqF7; Tue, 16 Sep 2014 05:29:31 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C07F1A030C; Tue, 16 Sep 2014 05:29:30 -0700 (PDT) Received: from zte.com.cn (unknown [192.168.168.120]) by Websense Email Security Gateway with ESMTP id 27A84128586E; Tue, 16 Sep 2014 20:29:13 +0800 (CST) Received: from mse01.zte.com.cn (unknown [10.30.3.20]) by Websense Email Security Gateway with ESMTPS id 77415CDAEDA; Tue, 16 Sep 2014 20:29:12 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse01.zte.com.cn with ESMTP id s8GCTKCJ087200; Tue, 16 Sep 2014 20:29:20 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) To: netconf@ietf.org, netmod@ietf.org MIME-Version: 1.0 X-KeepSent: A00A6FAE:C8E0515A-48257D55:0044412C; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 16 Sep 2014 20:29:10 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-09-16 20:29:04, Serialize complete at 2014-09-16 20:29:04 Content-Type: multipart/alternative; boundary="=_alternative 0044960948257D55_=" X-MAIL: mse01.zte.com.cn s8GCTKCJ087200 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mqcYN1tGCUP2MTnqnSHtQOEn2fs Cc: ye.xu1@zte.com.cn, chen.wei3@zte.com.cn, xiao.yuqing@zte.com.cn Subject: [netmod] =?gb2312?b?16q3ojogTmV3IFZlcnNpb24gTm90aWZpY2F0aW9uIGZv?= =?gb2312?b?ciBkcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwLnR4dA==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 12:29:33 -0000 This is a multipart message in MIME format. --=_alternative 0044960948257D55_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgYWxsLA0KDQogICBJIGhhdmUgc3VibWl0dGVkIGEgbmV3IGRyYWZ0IGZvciBuZXRjb25mIHNj aGVtYSBjb25mb3JtYW5jZSANCmFkdmVydGlzZW1lbnQgbWVjaGFuaXNtLg0KcGxlYXNlIHJldmll dyBpdCBhbmQgZ2l2ZSBtZSBzb21lIGFkdmljZS4gDQoNCnRoYW5rcyENCiAgICAgICAgICAgICAg L2ZyYW5rDQoNCg0KDQotLS0tLSDXqreiyMsgt+uz5TEwMTM2NDkyL3VzZXIvenRlX2x0ZCDKsbzk IDIwMTQtMDktMTYgMjA6MjUgLS0tLS0NCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnINC009og MjAxNC0wOS0xNiAyMDoyMTozMDoNCg0KPiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgDQo+IDIw MTQtMDktMTYgMjA6MjENCj4gDQo+IMrVvP7Iyw0KPiANCj4gIlh1IFllIiA8eWUueHUxQHp0ZS5j b20uY24+LCAiRnJhbmsgRmVuZyIgPGZlbmcuY2hvbmczM0B6dGUuY29tLmNuPiwNCj4gRnJhbmsg RmVuZyA8ZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24+LCBYdSBZZSA8eWUueHUxQHp0ZS5jb20uY24+ LCANCj4gDQo+ILOty80NCj4gDQo+INb3zOINCj4gDQo+IE5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv biBmb3IgZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50eHQNCj4gDQo+IA0KPiBB IG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50 eHQNCj4gaGFzIGJlZW4gc3VjY2Vzc2Z1bGx5IHN1Ym1pdHRlZCBieSBGcmFuayBGZW5nIGFuZCBw b3N0ZWQgdG8gdGhlDQo+IElFVEYgcmVwb3NpdG9yeS4NCj4gDQo+IE5hbWU6ICAgICAgZHJhZnQt ZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZQ0KPiBSZXZpc2lvbjogICAwMA0KPiBUaXRsZTogICAg ICBUaGUgbWVjaGFuaXNtIHRvIGFkdmVydGlzZSBzY2hlbWEgY29uZm9ybWFuY2Ugb2YgTkVUQ09O Rg0KPiBEb2N1bWVudCBkYXRlOiAgIDIwMTQtMDktMTYNCj4gR3JvdXA6ICAgICAgSW5kaXZpZHVh bCBTdWJtaXNzaW9uDQo+IFBhZ2VzOiAgICAgIDEyDQo+IFVSTDogICAgICAgICAgICBodHRwOi8v d3d3LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1mcmFuay0NCj4gbmV0Y29uZi1jb25m b3JtYW5jZS0wMC50eHQNCj4gU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0 Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLQ0KPiBuZXRjb25mLWNvbmZvcm1hbmNlLw0KPiBIdG1saXpl ZDogICAgICAgDQpodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmFuay1uZXRjb25m LWNvbmZvcm1hbmNlLTAwDQo+IA0KPiANCj4gQWJzdHJhY3Q6DQo+ICAgIFRoaXMgZG9jdW1lbnQg ZGVzY3JpYmVzIHRoZSB1bmlmaWVkIG1lY2hhbmlzbSB0byBhZHZlcnRpc2Ugc2NoZW1hDQo+ICAg IGNvbmZvcm1hbmNlIG9mIHRoZSBOZXR3b3JrIENvbmZpZ3VyYXRpb24gUHJvdG9jb2wgKE5FVENP TkYpLg0KPiANCj4gIA0KPiANCj4gDQo+IFBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIA0Kc3VibWlzc2lvbg0KPiB1bnRpbCB0 aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYu b3JnLg0KPiANCj4gVGhlIElFVEYgU2VjcmV0YXJpYXQNCj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAo YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2Vt aW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9u IFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwg KGFuZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBh bmQgY29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2Yg dGhlIGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwg YW55IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3Nl bWluYXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkg cHJvaGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxl YXNlIGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0044960948257D55_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCkhpIGFsbCw8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJIGhhdmUg c3VibWl0dGVkIGEgbmV3DQpkcmFmdCBmb3IgbmV0Y29uZiBzY2hlbWEgY29uZm9ybWFuY2UgYWR2 ZXJ0aXNlbWVudCBtZWNoYW5pc20uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5wbGVhc2UgcmV2aWV3IGl0IGFuZCBnaXZlIG1lIHNvbWUgYWR2aWNlLg0KPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj50aGFua3MhPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7IC9mcmFuazwvZm9udD4NCjx0YWJsZT4NCjx0 cj4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MSBjb2xvcj0jODAw MDgwIGZhY2U9InNhbnMtc2VyaWYiPi0tLS0tINeqt6LIyyC367PlMTAxMzY0OTIvdXNlci96dGVf bHRkDQrKsbzkIDIwMTQtMDktMTYgMjA6MjUgLS0tLS08L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcg0LTT2iAyMDE0LTA5LTE2IDIwOjIx OjMwOjxicj4NCjxicj4NCiZndDsgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIDwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAyMDE0LTA5LTE2IDIwOjIxPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJnF1b3Q7WHUgWWUmcXVvdDsg Jmx0O3llLnh1MUB6dGUuY29tLmNuJmd0OywgJnF1b3Q7RnJhbmsgRmVuZyZxdW90Ow0KJmx0O2Zl bmcuY2hvbmczM0B6dGUuY29tLmNuJmd0Oyw8YnI+DQomZ3Q7IEZyYW5rIEZlbmcgJmx0O2Zlbmcu Y2hvbmczM0B6dGUuY29tLmNuJmd0OywgWHUgWWUgJmx0O3llLnh1MUB6dGUuY29tLmNuJmd0OywN CjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTmV3IFZlcnNp b24gTm90aWZpY2F0aW9uIGZvciBkcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwLnR4 dDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IDxicj4N CiZndDsgQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWZyYW5rLW5ldGNvbmYtY29uZm9ybWFu Y2UtMDAudHh0PGJyPg0KJmd0OyBoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEZy YW5rIEZlbmcgYW5kIHBvc3RlZCB0byB0aGU8YnI+DQomZ3Q7IElFVEYgcmVwb3NpdG9yeS48YnI+ DQomZ3Q7IDxicj4NCiZndDsgTmFtZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtkcmFmdC1mcmFuay1u ZXRjb25mLWNvbmZvcm1hbmNlPGJyPg0KJmd0OyBSZXZpc2lvbjogJm5ic3A7IDAwPGJyPg0KJmd0 OyBUaXRsZTogJm5ic3A7ICZuYnNwOyAmbmJzcDtUaGUgbWVjaGFuaXNtIHRvIGFkdmVydGlzZSBz Y2hlbWEgY29uZm9ybWFuY2UNCm9mIE5FVENPTkY8YnI+DQomZ3Q7IERvY3VtZW50IGRhdGU6ICZu YnNwOyAyMDE0LTA5LTE2PGJyPg0KJmd0OyBHcm91cDogJm5ic3A7ICZuYnNwOyAmbmJzcDtJbmRp dmlkdWFsIFN1Ym1pc3Npb248YnI+DQomZ3Q7IFBhZ2VzOiAmbmJzcDsgJm5ic3A7ICZuYnNwOzEy PGJyPg0KJmd0OyBVUkw6ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMv ZHJhZnQtZnJhbmstIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJu ZXQtZHJhZnRzL2RyYWZ0LWZyYW5rLTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxi cj4NCiZndDsgbmV0Y29uZi1jb25mb3JtYW5jZS0wMC50eHQ8YnI+DQomZ3Q7IFN0YXR1czogJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHBzOi8vZGF0 YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLSI+PHR0Pjxmb250IHNpemU9Mj5odHRw czovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1mcmFuay08L2ZvbnQ+PC90dD48L2E+ PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IG5ldGNvbmYtY29uZm9ybWFuY2UvPGJyPg0KJmd0 OyBIdG1saXplZDogJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250PjwvdHQ+PGEgaHJlZj0iaHR0 cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS0w MCI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1mcmFu ay1uZXRjb25mLWNvbmZvcm1hbmNlLTAwPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXplPTI+ PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQWJzdHJhY3Q6PGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7VGhpcyBkb2N1bWVudCBkZXNjcmliZXMgdGhlIHVuaWZpZWQgbWVjaGFuaXNtIHRv IGFkdmVydGlzZQ0Kc2NoZW1hPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Y29uZm9ybWFuY2Ugb2Yg dGhlIE5ldHdvcmsgQ29uZmlndXJhdGlvbiBQcm90b2NvbCAoTkVUQ09ORikuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkg dGFrZSBhIGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2YNCnN1Ym1pc3Npb248YnI+ DQomZ3Q7IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoZSBJRVRGIFNlY3JldGFy aWF0PGJyPg0KJmd0OyA8YnI+DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9 ImJsdWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQg aGVyZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQg Zm9yIHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5v dCBhbiBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRp c3RyaWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRp b24gY29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1l ZGlhdGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJs dWUiPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBj b250YWluZWQgaW4gdGhpcyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVy ZXdpdGgpIGlzIHByaXZpbGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9y IHRoZSBleGNsdXNpdmUgdXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBh biBpbnRlbmRlZCByZWNpcGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3Ry aWJ1dGlvbiBvciBvdGhlciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24g Y29udGFpbmVkIGlzIHN0cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0 aGlzIG1haWwgaW4gZXJyb3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlh dGVseS4NCg0KPC9mb250PjwvcHJlPjxicj4NCg== --=_alternative 0044960948257D55_=-- From nobody Tue Sep 16 07:24:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA4B81A0350 for ; Tue, 16 Sep 2014 07:24:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 SQGYkOZ5cB6l for ; Tue, 16 Sep 2014 07:24:27 -0700 (PDT) Received: from mx0a-000f0801.pphosted.com (mx0a-000f0801.pphosted.com [IPv6:2620:100:9001:7a::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05B041A0348 for ; Tue, 16 Sep 2014 07:24:26 -0700 (PDT) Received: from pps.filterd (m0000542 [127.0.0.1]) by mx0a-000f0801.pphosted.com (8.14.5/8.14.5) with SMTP id s8GEFOTs017522; Tue, 16 Sep 2014 07:24:23 -0700 Received: from hq1wp-exchub02.corp.brocade.com ([144.49.131.13]) by mx0a-000f0801.pphosted.com with ESMTP id 1pef0b9sb1-1 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 16 Sep 2014 07:24:23 -0700 Received: from BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) by HQ1WP-EXCHUB02.corp.brocade.com (10.70.38.101) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 Sep 2014 07:24:23 -0700 Received: from brm-excashub-1.corp.brocade.com (172.16.186.49) by BRMWP-EXCHUB02.corp.brocade.com (172.16.187.99) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 16 Sep 2014 08:24:22 -0600 Received: from brm-exch-3.corp.brocade.com ([169.254.1.90]) by brm-excashub-1.corp.brocade.com ([172.16.186.74]) with mapi; Tue, 16 Sep 2014 08:24:16 -0600 From: Kiran Agrahara Sreenivasa To: "Romascanu, Dan (Dan)" , "netmod@ietf.org" Date: Tue, 16 Sep 2014 08:24:15 -0600 Thread-Topic: Webex information for the interim Thread-Index: Ac/RpbY8bMbtjyAKRRKh8FJnTrra0AAFCdpQ Message-ID: References: <9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7@AZ-FFEXMB04.global.avaya.com> In-Reply-To: <9904FB1B0159DA42B0B887B7FA8119CA5C89D2D7@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_C051D5C82AA58D49B08200C1A16C643106EAF237FBBRMEXCH3corpb_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.12.52, 1.0.28, 0.0.0000 definitions=2014-09-16_03:2014-09-16,2014-09-16,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1409160121 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/AV5mEwBBBJ3KjTUVQUZ9Hzvczg4 Subject: Re: [netmod] Webex information for the interim X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:24:28 -0000 --_000_C051D5C82AA58D49B08200C1A16C643106EAF237FBBRMEXCH3corpb_ Content-Type: text/plain; charset="us-ascii" +1 - I'm waiting on that too. Thanks Kiran From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan) Sent: Tuesday, September 16, 2014 7:00 AM To: netmod@ietf.org Subject: [netmod] Webex information for the interim I apologize if this was already posted, but I cannot find the remote participation (Webex) information for the netmod interim. Thanks and Regards, Dan --_000_C051D5C82AA58D49B08200C1A16C643106EAF237FBBRMEXCH3corpb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

+1 – I’m waiting on that too.

 

Thanks<= /span>

Kiran

 =

&n= bsp;

From: netmod [mailto:= netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sen= t: Tuesday, September 16, 2014 7:00 AM
To: netmod@ietf.orgSubject: [netmod] Webex information for the interim

 

I apologize if this was already posted, but I cannot find the remote = participation (Webex) information for the netmod interim.

 

Thanks and Reg= ards,

 

Dan

 

<= /body>= --_000_C051D5C82AA58D49B08200C1A16C643106EAF237FBBRMEXCH3corpb_-- From nobody Tue Sep 16 07:51:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1204B1A0367; Tue, 16 Sep 2014 07:51:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 b0rZiAq6Q7ZA; Tue, 16 Sep 2014 07:51:24 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 090E01A0515; Tue, 16 Sep 2014 07:51:21 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 9D525C25D; Tue, 16 Sep 2014 10:51:20 -0400 (EDT) Date: Tue, 16 Sep 2014 10:51:20 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140916145120.GE28454@pfrc> References: <20140912210913.GA10692@pfrc> <20140916094007.GB14437@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140916094007.GB14437@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FtUX36RPfEMIQmeXOM2LKK3YFxk Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 14:51:25 -0000 Juergen, On Tue, Sep 16, 2014 at 11:40:07AM +0200, Juergen Schoenwaelder wrote: > Thanks Jeff for putting this together. Concerning section 2.1.1, I am > not sure I agree with: > > The SSH transport does not mandate authentication be done; it is an > optional feature. > > RFC 6242 says: And that was one of the details I missed. As I've been doing my protocol homework, I missed the existence of this RFC. [...] > I also think that NC over TLS requires that both sides authenticate > and verify the certificates. I think as far as NETCONF is concerned, > all transports do actually mutual authentication. > > Perhaps there is confusion here with RESTCONF where the current > wording may be read as authentication is optional. But then, this > is not past the IESG yet. ;-) So, two obvious options for the document I wrote: - Presume restconf will address this, leave it in the requirements until it does. - Consider it pure noise, remove. But I think the major concern has been addressed. Thanks! (And in fairness to Kent, he did think it was covered as well, but we hadn't gotten to the level of RFC citations in our discussion prior to publishing this draft.) -- Jeff From nobody Tue Sep 16 12:44:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7AC01A6F2B for ; Tue, 16 Sep 2014 12:44:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 ZVPW_6o_ukUl for ; Tue, 16 Sep 2014 12:44:54 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8F7FF1A6F0B for ; Tue, 16 Sep 2014 12:44:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10350; q=dns/txt; s=iport; t=1410896695; x=1412106295; h=from:to:subject:date:message-id:mime-version; bh=x1EvCYPfp+M6Ax4/9EESrXmahamIsUyIZqFBYTfIo1k=; b=MdMiuj2AwdrXZUPABU+Bt2uqHPaQk6ujcK/yPUZtZDW8j2+wpu9RpyK6 zrajSk8jhI5Txpxa7auOAHxL4rzsMCI1x+eIZdG4q+g7QW1vTKefgwZit utaN8pfqGV6MOHGixzisM32jCo9r5EJxL0nn9AOgunvs8HKfTUvye9oxe o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIHAFeSGFStJV2d/2dsb2JhbABggkdGU1cEtzOPMYFiiGsWAXEIhAUFgQsBIGAnBIhRlxalNQEXjTuFRYEdBZFNhDeHBoFfjSaGQINebIFIgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,535,1406592000"; d="scan'208,217";a="355709488" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-7.cisco.com with ESMTP; 16 Sep 2014 19:44:54 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id s8GJirqu015263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 16 Sep 2014 19:44:53 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Tue, 16 Sep 2014 14:44:53 -0500 From: "Acee Lindem (acee)" To: "netmod@ietf.org" Thread-Topic: [netmod] Y09 introduce optional keys Thread-Index: AQHP0eavowxbS1ChGUy1hegKeeuUPA== Date: Tue, 16 Sep 2014 19:44:53 +0000 Message-ID: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.199] Content-Type: multipart/alternative; boundary="_000_69AD3EE7C8A04F29A3E6260E5B06445Cciscocom_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VBmiO5PZ0RNBDRIjnKoC6Ua0Hvc Subject: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 19:44:57 -0000 --_000_69AD3EE7C8A04F29A3E6260E5B06445Cciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, In the ISIS model, we are looking for a construct where an ISIS interface a= ttribute applies to level-1, level-2, or both. If it applies to both, that = is the only metric that is specified. If you specify different metrics for = level-1 and level-2 both can be specified. The snipers below are what we ha= ve been discussing. However, it is not really correct. Since if you specify= a metric for =93all-levels=94, you shouldn=92t specify anything else in th= e list. The suggestion was that an optional key could handle this. The alte= rnative would be to have a =93metric=94, =93level-1-metric=94, and =93level= -2-metric=94. grouping interface-level-options { leaf level { type enumeration { enum "level-1" { description "ISIS level 1"; } enum "level-2" { description "ISIS level-2"; } enum "level-all" { description "All ISIS levels"; } } default "level-all"; description "Specify ISIS level for the interface command."; } description "ISIS interface level option.=94; } list isis-metric { key "level"; description "ISIS interface metric"; leaf value { type uint32; description "ISIS metric value"; } uses interface-level-options; } Thanks, Acee Andy Bierman > wrote: > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund > wrote: > > > David Reid > wrote: > > > > Here is a proposal for how to introduce optional keys. > > > > > > Adding optional keys seems like a pretty major new feature for > > > a .1 release. Most of the other issues are fixes or clarifications. > > > Is the benefit worth the cost? > > > > I don't think the cost is that high. With YANG 1.0, people are forced > > to use awkward workarounds, and/or vendor-specific extensions to > > support a use case that seems to be natural in many circumstances. > > Thus, I think it is better to support this natively. (Incidentally, > > just today I got a question from someone involved in the broadband > > forum work why YANG doesn't support optional keys). > > > > > > I think the implementation impact is significant, but the feature could b= e > useful. > The protocol complexity increase is worse that the compiler. > What about adding optional keys to an existing entry? > IMO this cannot be supported with either RESTCONF or NETCONF. > The request will be seen by the server as a create, merge, or replace on > a new resource instance. Right, and I think this is ok. In general it would be nice with a 'rename' operation in the protocols, but that is a different issue. /martin --_000_69AD3EE7C8A04F29A3E6260E5B06445Cciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <0C62636D19853448A29D28602E948416@emea.cisco.com> Content-Transfer-Encoding: quoted-printable 
Hi, 
In the ISIS model, we are looking for a construct where an ISIS interf=
ace attribute applies to level-1, level-2, or both. If it applies to both, =
that is the only metric that is specified. If you specify different metrics=
 for level-1 and level-2 both can be specified. The snipers below are what =
we have been discussing. However, it is not really correct. Since if you sp=
ecify a metric for =93all-levels=94, you shouldn=92t specify anything else =
in the list. The suggestion was that an optional key could handle this. The=
 alternative would be to have a =93metric=94, =93level-1-metric=94, and =93=
level-2-metric=94. 
grouping interface-level-options {
    leaf level {
    =
  type enumeration {
        enum=
 "level-1" {
          =
description 
           =
; "ISIS level 1";
        }<=
/div>
        enum "level-2" {
          description 
            "ISIS level-2"=
;
        }
  &n=
bsp;     enum "level-all" {
  &nb=
sp;       description 
    &=
nbsp;       "All ISIS levels";
&n=
bsp;       }
   }
   =
;   description
        "Spe=
cify ISIS level for the interface command.";
  &=
nbsp; }
    description
  =
    "ISIS interface level option.=94;  

list isis-metric {
       key "level"=
;
        description "ISIS interface me=
tric";
         leaf value {
<=
div>                type uint32;
                description=
 "ISIS metric value";
         =
;}
         uses interface-level-options=
;
}


Thanks,
Acee
Andy Bierman <andy at yumaworks.co=
m> wrote:
> On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund <mbj at tail-f.com> wrote:
>=20
> > David Reid <reid at snmp.com&g=
t; wrote:
> > > > Here is a proposal for how to introduce optional keys.
> > >
> > > Adding optional keys seems like a pretty major new feature f=
or
> > > a .1 release. Most of the other issues are fixes or clarific=
ations.
> > > Is the benefit worth the cost?
> >
> > I don't think the cost is that high.  With YANG 1.0, people are f=
orced
> > to use awkward workarounds, and/or vendor-specific extensions to
> > support a use case that seems to be natural in many circumstances=
.
> > Thus, I think it is better to support this natively.  (Incidental=
ly,
> > just today I got a question from someone involved in the broadban=
d
> > forum work why YANG doesn't support optional keys).
> >
> >
>=20
> I think the implementation impact is significant, but the feature coul=
d be
> useful.
> The protocol complexity increase is worse that the compiler.
> What about adding optional keys to an existing entry?
> IMO this cannot be supported with either RESTCONF or NETCONF.
> The request will be seen by the server as a create, merge, or replace =
on
> a new resource instance.

Right, and I think this is ok.  In general it would be nice with a
'rename' operation in the protocols, but that is a different issue.


/martin

--_000_69AD3EE7C8A04F29A3E6260E5B06445Cciscocom_-- From nobody Tue Sep 16 13:57:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B795E1A03EB for ; Tue, 16 Sep 2014 13:56:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 N-LIgfYNvYXx for ; Tue, 16 Sep 2014 13:56:54 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD4E1A03A3 for ; Tue, 16 Sep 2014 13:56:54 -0700 (PDT) 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.1029.13; Tue, 16 Sep 2014 20:56:52 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.189]) with mapi id 15.00.1029.000; Tue, 16 Sep 2014 20:56:52 +0000 From: Kent Watsen To: Kiran Agrahara Sreenivasa , "Romascanu, Dan (Dan)" , "netmod@ietf.org" Thread-Topic: [netmod] Webex information for the interim Thread-Index: AQHP0fC91tSG1XdSVkuv0FyBifQ3sw== Date: Tue, 16 Sep 2014 20:56:52 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03361FCC43 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(189002)(199003)(377454003)(107886001)(83322001)(19580405001)(15202345003)(83506001)(76482001)(107046002)(20776003)(64706001)(31966008)(15975445006)(97736003)(4396001)(92726001)(106116001)(106356001)(21056001)(16236675004)(77096002)(85306004)(87936001)(83072002)(66066001)(85852003)(92566001)(86362001)(95666004)(99396002)(74662003)(80022003)(90102001)(101416001)(36756003)(79102003)(2656002)(2501002)(46102003)(105586002)(19300405004)(19625215002)(50986999)(54356999)(81342003)(99286002)(74502003)(19580395003)(81542003)(77982003); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D03E1C4981B00kwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SW_1AmqtMpasIuEuJlVa1xq5hok Subject: Re: [netmod] Webex information for the interim X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 20:56:58 -0000 --_000_D03E1C4981B00kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Same here... Kent From: Kiran Agrahara Sreenivasa > Date: Tuesday, September 16, 2014 at 10:24 AM To: "Romascanu, Dan (Dan)" >,= "netmod@ietf.org" > Subject: Re: [netmod] Webex information for the interim +1 - I'm waiting on that too. Thanks Kiran From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (= Dan) Sent: Tuesday, September 16, 2014 7:00 AM To: netmod@ietf.org Subject: [netmod] Webex information for the interim I apologize if this was already posted, but I cannot find the remote partic= ipation (Webex) information for the netmod interim. Thanks and Regards, Dan --_000_D03E1C4981B00kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <3706AD054190E64F980BD84C92DB1210@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable

Same here...

Kent

From: Kiran Agrahara Sreenivasa <= ;kkoushik@Brocade.com>
Date: Tuesday, September 16, 2014 a= t 10:24 AM
To: "Romascanu, Dan (Dan)"= ; <dromasca@avaya.com>, &qu= ot;netmod@ietf.org" <netmod@ietf.org>
Subject: Re: [netmod] Webex informa= tion for the interim

+1 – I’= ;m waiting on that too.

 

Thanks

Kiran

 

 

From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, September 16, 2014 7:00 AM
To: netmod@ietf.org
Subject: [netmod] Webex information for the interim

 

I apologize if this was already posted, but I cannot= find the remote participation (Webex) information for the netmod interim.

 

Thanks and Regards,

 

Dan

 

 --_000_D03E1C4981B00kwatsenjunipernet_-- From nobody Tue Sep 16 14:40:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EE7D1A03BE for ; Tue, 16 Sep 2014 14:40:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.452 X-Spam-Level: X-Spam-Status: No, score=-13.452 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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=-1.652, 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 b44Y3LrhSQ_P for ; Tue, 16 Sep 2014 14:40:51 -0700 (PDT) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 27E5A1A006A for ; Tue, 16 Sep 2014 14:40:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30581; q=dns/txt; s=iport; t=1410903652; x=1412113252; h=message-id:date:from:mime-version:to:subject; bh=9dxbhqeo8PyQiO6ZDCUL2+E8/UrGwej7TwpGIIYdQOs=; b=KVGCQ/iQ6n7n+3T7JOEC3Ybw4bFVpSN7uDCry4W/bB43vQ3WIBek1epU mArjxR0AfoaGXkjCVoXRCaWUvuIMLBiZ57tcCff/SncZNUK97jt4NHxn7 H1yEJh+CwW/y7Vo7ZYbOJWs5uJfmQ8yueLGPbpSIqTqFBNG0tooFenA3v Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvQJAOatGFStJA2G/2dsb2JhbABGFwIBgkdGU1eIV8ABh0cDgRgWAXmENzkSPQsEAQIEAQEWAwIBAgFEBAMNCAEBiDoNNpZ5pTABF48HXAcPAYQjBYYfj2WENYJRgTgnhWmNfYMLVTsvAYJJAQEB X-IronPort-AV: E=Sophos; i="5.04,536,1406592000"; d="scan'208,217"; a="78543635" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-4.cisco.com with ESMTP; 16 Sep 2014 21:40:51 +0000 Received: from [10.131.25.47] (dhcp-10-131-25-47.cisco.com [10.131.25.47]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8GLenJc002420 for ; Tue, 16 Sep 2014 21:40:49 GMT Message-ID: <5418AE61.9070102@cisco.com> Date: Tue, 16 Sep 2014 23:40:49 +0200 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------010001050003010105060104" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WMVG8XrNeNuEgUkCXxEa97_P84o Subject: [netmod] Logistic for the NETMOD interim X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Sep 2014 21:40:54 -0000 This is a multi-part message in MIME format. --------------010001050003010105060104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, If you come physically to the NETMOD interim, please go to Cisco Systems 9th Floor 1 Pennsylvania Plaza New York, NY 10119 You will receive a badge. From there, I will then escort you to our meeting room on the 6th floor. Note that you had to pre-register (with the NETMOD chairs) to be able to access level 9, and that you will have to show your ID. For Webex, here is the information. Disclaimer: we hope Webex will be efficient, as we might have blackboard discussions. ----------------------------------------------------------------------- JOIN USING WebEx Go To: https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246 Meeting Password ----- netmod Meeting Number ----- 202 618 800 ---------------------------------------------------------------- ALERT -- PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: -San Jose/Milpitas (408) area:525-6800 -RTP (919) area:392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones)." If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only.The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800RTP: +1.919.392.3330 US/Canada: +1.866.432.9903United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111Germany: +49.619.6773.9002 Japan: +81.3.5763.9394China: +86.10.8515.5666 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. Regards, Benoit --------------010001050003010105060104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

If you come physically to the NETMOD interim, please go to
    Cisco Systems
    9th Floor
    1 Pennsylvania Plaza
    New York, NY 10119

You will receive a badge. From there, I will then escort you to our meeting room on the 6th floor.
Note that you had to pre-register (with the NETMOD chairs) to be able to access level 9, and that you will have to show your ID.

For Webex, here is the information.
Disclaimer: we hope Webex will be efficient, as we might have blackboard discussions.

-----------------------------------------------------------------------

JOIN USING WebEx

 

Go To:

https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246

 

Meeting Password ----- netmod

Meeting Number ----- 202 618 800

 

----------------------------------------------------------------

ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES

----------------------------------------------------------------

Please dial the local access number for your area from the list below:

-  San Jose/Milpitas (408) area:  525-6800

-  RTP (919) area:  392-3330

 

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones).  “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

 

-------------------------------------------------------

To join the teleconference only

-------------------------------------------------------

1. Dial into Cisco WebEx (view all Global Access Numbers at

http://cisco.com/en/US/about/doing_business/conferencing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330

 

US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117

 

India: +91.80.4350.1111  Germany: +49.619.6773.9002

 

Japan: +81.3.5763.9394  China: +86.10.8515.5666

 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.


Regards, Benoit

--------------010001050003010105060104-- From nobody Wed Sep 17 06:33:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D4DA1A01CB for ; Wed, 17 Sep 2014 06:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652, WEIRD_PORT=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 ULXqEjWvxMNs for ; Wed, 17 Sep 2014 06:33:48 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 782391A00B2 for ; Wed, 17 Sep 2014 06:33:48 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1B4F28F7 for ; Wed, 17 Sep 2014 15:33:47 +0200 (CEST) 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 xwEz75JuLbes for ; Wed, 17 Sep 2014 15:33:33 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Wed, 17 Sep 2014 15:33:43 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id D279520056 for ; Wed, 17 Sep 2014 15:32:28 +0200 (CEST) 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 6xvWLSc3mVrD; Wed, 17 Sep 2014 15:32:26 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3BA6B2011E; Wed, 17 Sep 2014 15:32:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 77BBF2E66E52; Wed, 17 Sep 2014 15:32:25 +0200 (CEST) Date: Wed, 17 Sep 2014 15:32:24 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140917133224.GA17607@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mxXHS7Uvzwa4oyzlyScnIHlAZU0 Subject: [netmod] netmod new york interim etherpad url X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:33:50 -0000 Hi, I am trying to use etherpad for taking notes. The URL is here: http://etherpad.tools.ietf.org:9000/p/notes-ietf-2014-netmod-interim?useMonospaceFont=true /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 17 06:49:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE00D1A039F for ; Wed, 17 Sep 2014 06:49:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 ZR7qKCaKwzvj for ; Wed, 17 Sep 2014 06:49:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C27D1A02D4 for ; Wed, 17 Sep 2014 06:49:07 -0700 (PDT) Received: from [10.102.137.35] (rtp-isp-nat-pool1-1.cisco.com [64.102.254.34]) by mail.nic.cz (Postfix) with ESMTPSA id A84FE13F8D0; Wed, 17 Sep 2014 15:49:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410961745; bh=XITMbMAO91etfuhFidW0ARGxUeDhPtGYdlaS9luQNKM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=fJuZSupKXG5bUKEDyx5VfDhNzFwDrhHbQG+1ZjolaH/KH5u3vevW7KmA8zD/HMvjQ D5Dy86l8cMkf5Bqozp/KPskatf9nkUhBED7bKq8CTln058rr4qi06I2BnIOGOP2B1f 9l46UbDLkOq6ZyhvgeDy8h3Kg26sFJBOUViRg7B0= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> Date: Wed, 17 Sep 2014 09:49:00 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <5C913F0A-AC7C-4725-BFCE-80C8F5DD30F0@nic.cz> References: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> To: "Acee Lindem (acee)" X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/BObSetBHROHKw0lD27zI3h6mIRA Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 13:49:11 -0000 On 16 Sep 2014, at 15:44, Acee Lindem (acee) wrote: > Hi,=20 > In the ISIS model, we are looking for a construct where an ISIS = interface attribute applies to level-1, level-2, or both. If it applies = to both, that is the only metric that is specified. If you specify = different metrics for level-1 and level-2 both can be specified. The = snipers below are what we have been discussing. However, it is not = really correct. Since if you specify a metric for =93all-levels=94, you = shouldn=92t specify anything else in the list. The suggestion was that = an optional key could handle this. The alternative would be to have a = =93metric=94, =93level-1-metric=94, and =93level-2-metric=94. It seems a solution can be to use choice. It would allow to specify = either one parameter to be used by both (all) levels, or a list of = level-specific parameters, but not both. Something like choice metric { leaf metric { =85 } list level-metric { key level; leaf level { =85 } leaf metric { =85 } } } Would it make sense? Lada =20 > =20 > grouping interface-level-options { > leaf level { > type enumeration { > enum "level-1" { > description=20 > "ISIS level 1"; > } > enum "level-2" { > description=20 > "ISIS level-2"; > } > enum "level-all" { > description=20 > "All ISIS levels"; > } > } > default "level-all"; > description > "Specify ISIS level for the interface command."; > } > description > "ISIS interface level option.=94; =20 > } >=20 > list isis-metric { > key "level"; > description "ISIS interface metric"; > leaf value { > type uint32; > description "ISIS metric value"; > } > uses interface-level-options; > } >=20 >=20 > Thanks, > Acee > Andy Bierman > wrote: > > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund tail-f.com > > wrote: > >=20 > > > David Reid snmp.com > > wrote: > > > > > Here is a proposal for how to introduce optional keys. > > > > > > > > Adding optional keys seems like a pretty major new feature for > > > > a .1 release. Most of the other issues are fixes or = clarifications. > > > > Is the benefit worth the cost? > > > > > > I don't think the cost is that high. With YANG 1.0, people are = forced > > > to use awkward workarounds, and/or vendor-specific extensions to > > > support a use case that seems to be natural in many circumstances. > > > Thus, I think it is better to support this natively. = (Incidentally, > > > just today I got a question from someone involved in the broadband > > > forum work why YANG doesn't support optional keys). > > > > > > > >=20 > > I think the implementation impact is significant, but the feature = could be > > useful. > > The protocol complexity increase is worse that the compiler. > > What about adding optional keys to an existing entry? > > IMO this cannot be supported with either RESTCONF or NETCONF. > > The request will be seen by the server as a create, merge, or = replace on > > a new resource instance. >=20 > Right, and I think this is ok. In general it would be nice with a > 'rename' operation in the protocols, but that is a different issue. >=20 >=20 > /martin >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 17 07:07:01 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 678B51A02D9 for ; Wed, 17 Sep 2014 07:06:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 GFd-5Fk2jsro for ; Wed, 17 Sep 2014 07:06:53 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 472C81A039F for ; Wed, 17 Sep 2014 07:06:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4157; q=dns/txt; s=iport; t=1410962808; x=1412172408; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=d6s26RC+/5ISX8JgMqLXJOro2ey1jAVync8AqMtjrH4=; b=ZaygiPlTk4HrX0UHLdo3NbxMwIv52UMpfjzgt9RjwCurzzvTnIFH1QOJ ifF9NG2HchXa1LxRaubItHqi9VlN200QJMtASGhT3MpS90erVvm37Y+Gu iK1BKrqmZFknHNIb10o999nh9E8+9nKl9rz6TKHA2oQ7PXqd4O11IRWBL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFAGGUGVStJV2b/2dsb2JhbABggw1TVwTJGAqGelQBgRIWAXmEBAEBBAEBAWsLEAIBCBguJwslAgQOBRuIIw2+SQEXjxgzB4RLBZFNhDeHBoFfk2eDXmyBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,540,1406592000"; d="scan'208";a="356036915" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Sep 2014 14:06:47 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id s8HE6lPk008844 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Sep 2014 14:06:47 GMT Received: from xmb-aln-x06.cisco.com ([169.254.1.175]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 09:06:47 -0500 From: "Acee Lindem (acee)" To: Ladislav Lhotka Thread-Topic: [netmod] Y09 introduce optional keys Thread-Index: AQHP0n4tFm1fcHgg8UaY/ztioVSdtZwFbQGA Date: Wed, 17 Sep 2014 14:06:46 +0000 Message-ID: References: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> <5C913F0A-AC7C-4725-BFCE-80C8F5DD30F0@nic.cz> In-Reply-To: <5C913F0A-AC7C-4725-BFCE-80C8F5DD30F0@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.152.196] Content-Type: text/plain; charset="Windows-1252" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j9YQAAivh465gWakWA4glhABNbk Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:06:56 -0000 Hi Lada,=20 This might be just what we need - I=B9ll discuss with the model authors. Th= e other alternative is to allow all three metrics and use the most specific specification. In any case, it appears that we are not dependent on optional keys. =20 Thanks, Acee=20 On 9/17/14, 9:49 AM, "Ladislav Lhotka" wrote: > >On 16 Sep 2014, at 15:44, Acee Lindem (acee) wrote: > >> Hi,=20 >> In the ISIS model, we are looking for a construct where an ISIS >>interface attribute applies to level-1, level-2, or both. If it applies >>to both, that is the only metric that is specified. If you specify >>different metrics for level-1 and level-2 both can be specified. The >>snipers below are what we have been discussing. However, it is not >>really correct. Since if you specify a metric for =B3all-levels=B2, you >>shouldn=B9t specify anything else in the list. The suggestion was that an >>optional key could handle this. The alternative would be to have a >>=B3metric=B2, =B3level-1-metric=B2, and =B3level-2-metric=B2. > >It seems a solution can be to use choice. It would allow to specify >either one parameter to be used by both (all) levels, or a list of >level-specific parameters, but not both. Something like > >choice metric { > leaf metric { =8A } > list level-metric { > key level; > leaf level { =8A } > leaf metric { =8A } > } >} > >Would it make sense? > >Lada > =20 > >> =20 >> grouping interface-level-options { >> leaf level { >> type enumeration { >> enum "level-1" { >> description >> "ISIS level 1"; >> } >> enum "level-2" { >> description >> "ISIS level-2"; >> } >> enum "level-all" { >> description >> "All ISIS levels"; >> } >> } >> default "level-all"; >> description >> "Specify ISIS level for the interface command."; >> } >> description >> "ISIS interface level option.=B2; >> } >>=20 >> list isis-metric { >> key "level"; >> description "ISIS interface metric"; >> leaf value { >> type uint32; >> description "ISIS metric value"; >> } >> uses interface-level-options; >> } >>=20 >>=20 >> Thanks, >> Acee >> Andy Bierman > > wrote: >> > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund > tail-f.com >> > wrote: >> >=20 >> > > David Reid > snmp.com >> > wrote: >> > > > > Here is a proposal for how to introduce optional keys. >> > > > >> > > > Adding optional keys seems like a pretty major new feature for >> > > > a .1 release. Most of the other issues are fixes or >>clarifications. >> > > > Is the benefit worth the cost? >> > > >> > > I don't think the cost is that high. With YANG 1.0, people are >>forced >> > > to use awkward workarounds, and/or vendor-specific extensions to >> > > support a use case that seems to be natural in many circumstances. >> > > Thus, I think it is better to support this natively. (Incidentally, >> > > just today I got a question from someone involved in the broadband >> > > forum work why YANG doesn't support optional keys). >> > > >> > > >> >=20 >> > I think the implementation impact is significant, but the feature >>could be >> > useful. >> > The protocol complexity increase is worse that the compiler. >> > What about adding optional keys to an existing entry? >> > IMO this cannot be supported with either RESTCONF or NETCONF. >> > The request will be seen by the server as a create, merge, or replace >>on >> > a new resource instance. >>=20 >> Right, and I think this is ok. In general it would be nice with a >> 'rename' operation in the protocols, but that is a different issue. >>=20 >>=20 >> /martin >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > >-- >Ladislav Lhotka, CZ.NIC Labs >PGP Key ID: E74E8C0C > > > > From nobody Wed Sep 17 07:25:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9791A046C for ; Wed, 17 Sep 2014 07:25:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.153 X-Spam-Level: X-Spam-Status: No, score=-16.153 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=-1.652, 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 KAc0OnYTvkFs for ; Wed, 17 Sep 2014 07:25:28 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 255041A0475 for ; Wed, 17 Sep 2014 07:25:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5802; q=dns/txt; s=iport; t=1410963928; x=1412173528; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=WMDPTG7u7EdC5zgxG8gklT+BlcK59vN7M6fZawb5nAo=; b=jljonrpc6RE7pSwzi+HqCDnw5Sx9mU9GOcIdZYBBLHk3ebkcUMyztSGq MD4t6zJMkdOKJFkdZ5qBo11PDAax+RjnUlsl9F7i1ihS7VIj+m6HMynBU 4MS8ZcJ/w7fCAzpAAfT2oQPa0hGJct4TBSr1BzRhzKsz253OOXOkGStoA 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FAGSYGVStJV2U/2dsb2JhbABggw1TW8kaCoZ5VAGBEhYBeYQDAQEBBAEBAWsLDAQCAQgRBAEBAQodBycLFAkIAgQBDQUIE4gjDb5bARePRjEHBoMogR0FkU6EN4hnk2iDXmyBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,540,1406592000"; d="scan'208";a="355978417" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-8.cisco.com with ESMTP; 17 Sep 2014 14:25:27 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8HEPRXN031907 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 17 Sep 2014 14:25:27 GMT Received: from xmb-aln-x08.cisco.com ([169.254.3.10]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Wed, 17 Sep 2014 09:25:27 -0500 From: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" To: "Acee Lindem (acee)" , Ladislav Lhotka Thread-Topic: [netmod] Y09 introduce optional keys Thread-Index: AQIIdtnD7P+W/hpWoYSUpFJk24OgFQFdBCrqAyTwpiabcAkRwA== Date: Wed, 17 Sep 2014 14:25:26 +0000 Message-ID: <013A9B371AC6DF4C8AD261897D8F243E1141EB64@xmb-aln-x08.cisco.com> References: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> <5C913F0A-AC7C-4725-BFCE-80C8F5DD30F0@nic.cz> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.63.23.147] Content-Type: text/plain; charset="windows-1257" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9eemZSPpq69v0PSjkXWJt8yL7Cw Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 14:25:30 -0000 Hi Lada, I had posted an example previously (which I suggested in one of the calls s= hould be added as a note for Y09) -- reproduced here. In this case a "choic= e" doesn't solve the problem, as there are a set of overlapping identifiers= which are actually used as the key. =3D=3D=3D=3D=3D=3D A list entry may have a key which is a union; i.e. it is indexed by a singl= e value which is one of multiple types. However, a YANG union is not always= sufficient to model a choice between a set of types. Take the following case for example: choice maintenance-domain-identifier { leaf host { type inet:host; } leaf id { type hex-string; } leaf name { type string; } } These strings can be overlapping, so this cannot be represented as a union. =3D=3D=3D=3D=3D=3D There was a discussion of other solutions which involved more controversial= extensions to the language (Y53, rejected) -- but it can be solved with Y0= 9 by making each leaf an optional key. Thanks, Peyman > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Acee Lindem > (acee) > Sent: 17 September 2014 15:07 > To: Ladislav Lhotka > Cc: netmod@ietf.org > Subject: Re: [netmod] Y09 introduce optional keys >=20 > Hi Lada, > This might be just what we need - I=B9ll discuss with the model authors. > The > other alternative is to allow all three metrics and use the most specific > specification. In any case, it appears that we are not dependent on > optional keys. > Thanks, > Acee >=20 > On 9/17/14, 9:49 AM, "Ladislav Lhotka" wrote: >=20 > > > >On 16 Sep 2014, at 15:44, Acee Lindem (acee) wrote: > > > >> Hi, > >> In the ISIS model, we are looking for a construct where an ISIS > >>interface attribute applies to level-1, level-2, or both. If it applies > >>to both, that is the only metric that is specified. If you specify > >>different metrics for level-1 and level-2 both can be specified. The > >>snipers below are what we have been discussing. However, it is not > >>really correct. Since if you specify a metric for =B3all-levels=B2, you > >>shouldn=B9t specify anything else in the list. The suggestion was that = an > >>optional key could handle this. The alternative would be to have a > >>=B3metric=B2, =B3level-1-metric=B2, and =B3level-2-metric=B2. > > > >It seems a solution can be to use choice. It would allow to specify > >either one parameter to be used by both (all) levels, or a list of > >level-specific parameters, but not both. Something like > > > >choice metric { > > leaf metric { =D0 } > > list level-metric { > > key level; > > leaf level { =D0 } > > leaf metric { =D0 } > > } > >} > > > >Would it make sense? > > > >Lada > > > > > >> > >> grouping interface-level-options { > >> leaf level { > >> type enumeration { > >> enum "level-1" { > >> description > >> "ISIS level 1"; > >> } > >> enum "level-2" { > >> description > >> "ISIS level-2"; > >> } > >> enum "level-all" { > >> description > >> "All ISIS levels"; > >> } > >> } > >> default "level-all"; > >> description > >> "Specify ISIS level for the interface command."; > >> } > >> description > >> "ISIS interface level option.=B2; > >> } > >> > >> list isis-metric { > >> key "level"; > >> description "ISIS interface metric"; > >> leaf value { > >> type uint32; > >> description "ISIS metric value"; > >> } > >> uses interface-level-options; > >> } > >> > >> > >> Thanks, > >> Acee > >> Andy Bierman >> > wrote: > >> > On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund >> tail-f.com > >> > wrote: > >> > > >> > > David Reid >> snmp.com > >> > wrote: > >> > > > > Here is a proposal for how to introduce optional keys. > >> > > > > >> > > > Adding optional keys seems like a pretty major new feature for > >> > > > a .1 release. Most of the other issues are fixes or > >>clarifications. > >> > > > Is the benefit worth the cost? > >> > > > >> > > I don't think the cost is that high. With YANG 1.0, people are > >>forced > >> > > to use awkward workarounds, and/or vendor-specific extensions to > >> > > support a use case that seems to be natural in many circumstances. > >> > > Thus, I think it is better to support this natively. > (Incidentally, > >> > > just today I got a question from someone involved in the broadband > >> > > forum work why YANG doesn't support optional keys). > >> > > > >> > > > >> > > >> > I think the implementation impact is significant, but the feature > >>could be > >> > useful. > >> > The protocol complexity increase is worse that the compiler. > >> > What about adding optional keys to an existing entry? > >> > IMO this cannot be supported with either RESTCONF or NETCONF. > >> > The request will be seen by the server as a create, merge, or > replace > >>on > >> > a new resource instance. > >> > >> Right, and I think this is ok. In general it would be nice with a > >> 'rename' operation in the protocols, but that is a different issue. > >> > >> > >> /martin > >> > >> > >> _______________________________________________ > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > > > >-- > >Ladislav Lhotka, CZ.NIC Labs > >PGP Key ID: E74E8C0C > > > > > > > > >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Sep 17 11:11:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA7CC1A0787 for ; Wed, 17 Sep 2014 11:11:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.303 X-Spam-Level: X-Spam-Status: No, score=-2.303 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=-1.652] 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 vTOwc4muvsdT for ; Wed, 17 Sep 2014 11:11:42 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8FCE1A0745 for ; Wed, 17 Sep 2014 11:11:40 -0700 (PDT) Received: from [10.102.137.35] (rtp-isp-nat1.cisco.com [64.102.254.33]) by mail.nic.cz (Postfix) with ESMTPSA id 1F91E13F8D0; Wed, 17 Sep 2014 20:11:37 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1410977499; bh=aEWs+h8yejzqyTW7DOK4uSwbbQrzEK6PQvDVhpWa3SY=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=S9xUeLuXEwmg9A+43MhG7tdckZRfn2Lh1JTpxpM+4ukpEgSwWhe9mNKjH1HFxBfyb c05D/d5U5wQREIe2stygwwHeyg1ZDov1FvdfOB4FAuReg6CSI+RZj21iOaK1SGKL1h MXQMCRa10Kzp9HKnMvJs3sd8GNWuAjkmOfOjZ01Q= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <013A9B371AC6DF4C8AD261897D8F243E1141EB64@xmb-aln-x08.cisco.com> Date: Wed, 17 Sep 2014 14:11:35 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <69AD3EE7-C8A0-4F29-A3E6-260E5B06445C@cisco.com> <5C913F0A-AC7C-4725-BFCE-80C8F5DD30F0@nic.cz> <013A9B371AC6DF4C8AD261897D8F243E1141EB64@xmb-aln-x08.cisco.com> To: "Peyman Owladi -X (powladi - Ensoft Ltd at Cisco)" X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/p9l_SHZMA0LCYl6sRU4dW_Z8fus Cc: "netmod@ietf.org" Subject: Re: [netmod] Y09 introduce optional keys X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 18:11:46 -0000 Hi Peyman, I think you are mixing up =93choice=94 as a schema node and the =93union=94= type. In your example there is no amiguity at all. Lada =20 On 17 Sep 2014, at 10:25, Peyman Owladi -X (powladi - Ensoft Ltd at = Cisco) wrote: > Hi Lada, >=20 > I had posted an example previously (which I suggested in one of the = calls should be added as a note for Y09) -- reproduced here. In this = case a "choice" doesn't solve the problem, as there are a set of = overlapping identifiers which are actually used as the key. >=20 > =3D=3D=3D=3D=3D=3D > A list entry may have a key which is a union; i.e. it is indexed by a = single value which is one of multiple types. However, a YANG union is = not always sufficient to model a choice between a set of types. >=20 > Take the following case for example: >=20 > choice maintenance-domain-identifier { > leaf host { type inet:host; } > leaf id { type hex-string; } > leaf name { type string; } > } >=20 > These strings can be overlapping, so this cannot be represented as a = union. > =3D=3D=3D=3D=3D=3D >=20 > There was a discussion of other solutions which involved more = controversial extensions to the language (Y53, rejected) -- but it can = be solved with Y09 by making each leaf an optional key. >=20 > Thanks, > Peyman >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Acee = Lindem >> (acee) >> Sent: 17 September 2014 15:07 >> To: Ladislav Lhotka >> Cc: netmod@ietf.org >> Subject: Re: [netmod] Y09 introduce optional keys >>=20 >> Hi Lada, >> This might be just what we need - I=B9ll discuss with the model = authors. >> The >> other alternative is to allow all three metrics and use the most = specific >> specification. In any case, it appears that we are not dependent on >> optional keys. >> Thanks, >> Acee >>=20 >> On 9/17/14, 9:49 AM, "Ladislav Lhotka" wrote: >>=20 >>>=20 >>> On 16 Sep 2014, at 15:44, Acee Lindem (acee) wrote: >>>=20 >>>> Hi, >>>> In the ISIS model, we are looking for a construct where an ISIS >>>> interface attribute applies to level-1, level-2, or both. If it = applies >>>> to both, that is the only metric that is specified. If you specify >>>> different metrics for level-1 and level-2 both can be specified. = The >>>> snipers below are what we have been discussing. However, it is not >>>> really correct. Since if you specify a metric for =B3all-levels=B2, = you >>>> shouldn=B9t specify anything else in the list. The suggestion was = that an >>>> optional key could handle this. The alternative would be to have a >>>> =B3metric=B2, =B3level-1-metric=B2, and =B3level-2-metric=B2. >>>=20 >>> It seems a solution can be to use choice. It would allow to specify >>> either one parameter to be used by both (all) levels, or a list of >>> level-specific parameters, but not both. Something like >>>=20 >>> choice metric { >>> leaf metric { =8A } >>> list level-metric { >>> key level; >>> leaf level { =8A } >>> leaf metric { =8A } >>> } >>> } >>>=20 >>> Would it make sense? >>>=20 >>> Lada >>>=20 >>>=20 >>>>=20 >>>> grouping interface-level-options { >>>> leaf level { >>>> type enumeration { >>>> enum "level-1" { >>>> description >>>> "ISIS level 1"; >>>> } >>>> enum "level-2" { >>>> description >>>> "ISIS level-2"; >>>> } >>>> enum "level-all" { >>>> description >>>> "All ISIS levels"; >>>> } >>>> } >>>> default "level-all"; >>>> description >>>> "Specify ISIS level for the interface command."; >>>> } >>>> description >>>> "ISIS interface level option.=B2; >>>> } >>>>=20 >>>> list isis-metric { >>>> key "level"; >>>> description "ISIS interface metric"; >>>> leaf value { >>>> type uint32; >>>> description "ISIS metric value"; >>>> } >>>> uses interface-level-options; >>>> } >>>>=20 >>>>=20 >>>> Thanks, >>>> Acee >>>> Andy Bierman >>>> wrote: >>>>> On Thu, Sep 4, 2014 at 12:21 PM, Martin Bjorklund >>> tail-f.com >>>>> wrote: >>>>>=20 >>>>>> David Reid >>> snmp.com >>>>> wrote: >>>>>>>> Here is a proposal for how to introduce optional keys. >>>>>>>=20 >>>>>>> Adding optional keys seems like a pretty major new feature for >>>>>>> a .1 release. Most of the other issues are fixes or >>>> clarifications. >>>>>>> Is the benefit worth the cost? >>>>>>=20 >>>>>> I don't think the cost is that high. With YANG 1.0, people are >>>> forced >>>>>> to use awkward workarounds, and/or vendor-specific extensions to >>>>>> support a use case that seems to be natural in many = circumstances. >>>>>> Thus, I think it is better to support this natively. >> (Incidentally, >>>>>> just today I got a question from someone involved in the = broadband >>>>>> forum work why YANG doesn't support optional keys). >>>>>>=20 >>>>>>=20 >>>>>=20 >>>>> I think the implementation impact is significant, but the feature >>>> could be >>>>> useful. >>>>> The protocol complexity increase is worse that the compiler. >>>>> What about adding optional keys to an existing entry? >>>>> IMO this cannot be supported with either RESTCONF or NETCONF. >>>>> The request will be seen by the server as a create, merge, or >> replace >>>> on >>>>> a new resource instance. >>>>=20 >>>> Right, and I think this is ok. In general it would be nice with a >>>> 'rename' operation in the protocols, but that is a different issue. >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: E74E8C0C >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Wed Sep 17 14:15:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 856061A6F2B; Wed, 17 Sep 2014 14:15:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.554 X-Spam-Level: X-Spam-Status: No, score=-103.554 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 4d7rgIqYK19q; Wed, 17 Sep 2014 14:15:09 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 2295A1A039F; Wed, 17 Sep 2014 14:15:09 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 6BA7218044F; Wed, 17 Sep 2014 14:14:32 -0700 (PDT) To: andy@yumaworks.com, j.schoenwaelder@jacobs-university.de X-PHP-Originating-Script: 1005:errata_mail_lib.php From: RFC Errata System Message-Id: <20140917211432.6BA7218044F@rfc-editor.org> Date: Wed, 17 Sep 2014 14:14:32 -0700 (PDT) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JpANv6sklkKgacxtes0vydVpdRE Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org Subject: [netmod] [Errata Held for Document Update] RFC6991 (4076) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Sep 2014 21:15:10 -0000 The following errata report has been held for document update for RFC6991, "Common YANG Data Types". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6991&eid=4076 -------------------------------------- Status: Held for Document Update Type: Editorial Reported by: Andy Bierman Date Reported: 2014-08-09 Held by: Benoit Claise (IESG) Section: 3 Original Text ------------- In date-and-time typedef description-stmt (c) The canonical format (see below) of data-and-time values Corrected Text -------------- (c) The canonical format (see below) of date-and-time values Notes ----- date-and-time spelled data-and-time -------------------------------------- RFC6991 (draft-ietf-netmod-rfc6021-bis-03) -------------------------------------- Title : Common YANG Data Types Publication Date : July 2013 Author(s) : J. Schoenwaelder, Ed. Category : PROPOSED STANDARD Source : NETCONF Data Modeling Language Area : Operations and Management Stream : IETF Verifying Party : IESG From nobody Wed Sep 17 17:07:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0168D1A0387; Wed, 17 Sep 2014 17:07:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 IzBv2iVjOPQK; Wed, 17 Sep 2014 17:07:31 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 83F9D1A6EED; Wed, 17 Sep 2014 17:07:30 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140912210913.GA10692@pfrc> In-Reply-To: <20140912210913.GA10692@pfrc> Date: Wed, 17 Sep 2014 20:07:27 -0400 Message-ID: <002601cfd2d4$88acf610$9a06e230$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQn5y50NtQ Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/R5kwTMhNt9F6ADXb1De8eWaC9OE Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 00:07:38 -0000 Jeff: In section 2.6.1, you indicate the notification must "specify type and various parameters for the endpoint session" - is this a new configuration that is I2RS and empheral or is it a part of the netconf event configuration that would need to be added? Same question for the filters in 2.6.2? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements / There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Wed Sep 17 17:20:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76DBE1A6F11; Wed, 17 Sep 2014 17:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 SEYxjfEroT4M; Wed, 17 Sep 2014 17:20:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 213D81A6EFC; Wed, 17 Sep 2014 17:20:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140912210913.GA10692@pfrc> In-Reply-To: <20140912210913.GA10692@pfrc> Date: Wed, 17 Sep 2014 20:20:16 -0400 Message-ID: <002b01cfd2d6$5316a120$f943e360$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002C_01CFD2B4.CC074B10" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQn5y52lJg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a1_3IbOrftBe7EPsDfkO8MFWHOc Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 00:20:21 -0000 This is a multipart message in MIME format. ------=_NextPart_000_002C_01CFD2B4.CC074B10 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: With I2RS datastore (empheral) and I2RS Config there is always a chance that two different actions will change the same data. Take the example config you use in section 2.7 and assume that both I2rs and normal config want to modify this bgp config in the bgp routing process. First - do you think this is possible? If you do then section 2.7's atomic transactions will need to be augmented to indicate the interaction priority between the following different events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rollback). I define interaction priority as the priority (interrupt or sequencing) when one of these events overlaps with another. Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) With some help from Kent, Dean and Alia, I've put together a rough first draft of requirements I2RS has on netmod/netconf. It should be strongly noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve interested parties. As such, please note that this draft is not an I2RS WG draft and does not have current WG consensus. At best, it reflects my attempt to summarize prior discussions and turn them into requirements. This document will most assuredly be wrong and be revised. But it's primary purpose was to provide a start of the discussion of I2RS requirements at the netmod interim meeting next week. My abject apologies to the I2RS and netmod working groups - this was the fastest I could get the text out. Comments are appreciated. Flames are not unexpected. -- Jeff New Internet-Draft is available from the on-line Internet-Drafts directories. Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements / There's also a htmlized version available at: http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_002C_01CFD2B4.CC074B10 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

With = I2RS datastore (empheral) and I2RS Config there is always a chance that = two different actions will change the same data.  Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process.  =  First – do you think this is possible? =  

 

If you do then section 2.7’s atomic = transactions will need to be augmented to indicate the interaction = priority between the following different events I2RS (valid), I2RS = (invalid/roll-back), config (valid), config (rollback).   I = define interaction priority as the priority (interrupt or sequencing) = when one of these events overlaps with another.

 

Sue

=

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: = Friday, September 12, 2014 5:09 PM
To: i2rs@ietf.org; = netmod@ietf.org
Subject: [i2rs] I2RS requests to netmod/netconf (was = netmod interim and i2rs requirements)

 

With = some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf.  It should be = strongly noted that due to a confluence of a lot of bad timing (travel, = vacation,

etc.) I didn't have time = to more broadly reach out and involve interested = parties.

 

As such, please note that this draft is not an I2RS = WG draft and does not have current WG consensus.  At best, it = reflects my attempt to summarize prior discussions and turn them into = requirements.  This document will most assuredly be wrong and be = revised.

 

But it's primary purpose was to provide a start of = the discussion of I2RS requirements at the netmod interim meeting next = week.

 

My abject apologies to the I2RS and netmod working = groups - this was the fastest I could get the text out.

 

Comments are appreciated.  Flames are not = unexpected.

 

-- = Jeff

 

 

 

New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

 

        = Title           : I2RS = requirements for netmod/netconf

        = Author          : Jeffrey = Haas

        = Filename        : = draft-haas-i2rs-netmod-netconf-requirements-00.txt

        = Pages           : = 10

        = Date            : = 2014-09-12

 

Abstract:

   This document covers requests to the = netmod and netconf Working

   Groups for functionality to support = requirements to implement the

   I2RS architecture.

 

 

The = IETF datatracker status page for this draft is:

https://datatracker.ietf.= org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available = at:

http://tools.ietf.org/htm= l/draft-haas-i2rs-netmod-netconf-requirements-00

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_002C_01CFD2B4.CC074B10-- From nobody Thu Sep 18 04:09:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F5B81A8768; Thu, 18 Sep 2014 04:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.22 X-Spam-Level: X-Spam-Status: No, score=-3.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 njGYAr1QDAP7; Thu, 18 Sep 2014 04:08:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 8F19A1A8767; Thu, 18 Sep 2014 04:08:54 -0700 (PDT) Received: from [10.130.39.167] (mobile-198-228-198-084.mycingular.net [198.228.198.84]) by slice.pfrc.org (Postfix) with ESMTPSA id E9B80C3F6; Thu, 18 Sep 2014 07:08:53 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Jeff Haas X-Mailer: iPhone Mail (11D257) In-Reply-To: <002601cfd2d4$88acf610$9a06e230$@ndzh.com> Date: Thu, 18 Sep 2014 07:08:52 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <1DA78568-8684-4CFB-83B3-BBA903334750@pfrc.org> References: <20140912210913.GA10692@pfrc> <002601cfd2d4$88acf610$9a06e230$@ndzh.com> To: Susan Hares Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LdzJJVcXILzSERIbq1X5ppTrMhI Cc: "" , "" Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:09:00 -0000 Sue, Such endpoint and filtering behavior, while necessary for i2rs, may be gener= ally useful. I expect good discussion about it at today's interim session.=20= Jeff > On Sep 17, 2014, at 20:07, "Susan Hares" wrote: >=20 > Jeff: >=20 > In section 2.6.1, you indicate the notification must "specify type and > various parameters for the endpoint session" - is this a new configuration= > that is I2RS and empheral or is it a part of the netconf event configurati= on > that would need to be added? Same question for the filters in 2.6.2?=20= >=20 > Sue=20 >=20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, September 12, 2014 5:09 PM > To: i2rs@ietf.org; netmod@ietf.org > Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2= rs > requirements) >=20 > With some help from Kent, Dean and Alia, I've put together a rough first > draft of requirements I2RS has on netmod/netconf. It should be strongly > noted that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested > parties. >=20 > As such, please note that this draft is not an I2RS WG draft and does not > have current WG consensus. At best, it reflects my attempt to summarize > prior discussions and turn them into requirements. This document will mos= t > assuredly be wrong and be revised. >=20 > But it's primary purpose was to provide a start of the discussion of I2RS > requirements at the netmod interim meeting next week. >=20 > My abject apologies to the I2RS and netmod working groups - this was the > fastest I could get the text out. >=20 > Comments are appreciated. Flames are not unexpected. >=20 > -- Jeff >=20 >=20 >=20 > New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.tx= t > Pages : 10 > Date : 2014-09-12 >=20 > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts > / >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs From nobody Thu Sep 18 04:12:20 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA67E1A86DD; Thu, 18 Sep 2014 04:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.218 X-Spam-Level: X-Spam-Status: No, score=-3.218 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, MIME_QP_LONG_LINE=0.001, RP_MATCHES_RCVD=-1.652, SPF_HELO_PASS=-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 xG1Hz3dVofLz; Thu, 18 Sep 2014 04:12:15 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 6D3111A01D8; Thu, 18 Sep 2014 04:12:15 -0700 (PDT) Received: from [10.130.39.167] (mobile-198-228-198-084.mycingular.net [198.228.198.84]) by slice.pfrc.org (Postfix) with ESMTPSA id 9953FC3F6; Thu, 18 Sep 2014 07:12:14 -0400 (EDT) Content-Type: multipart/alternative; boundary=Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Mime-Version: 1.0 (1.0) From: Jeff Haas X-Mailer: iPhone Mail (11D257) In-Reply-To: <002b01cfd2d6$5316a120$f943e360$@ndzh.com> Date: Thu, 18 Sep 2014 07:12:14 -0400 Content-Transfer-Encoding: 7bit Message-Id: References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> To: Susan Hares Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jc1E5aMta26E9hyJFlLdiMFUf-k Cc: "" , "" Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:12:19 -0000 --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sue, My expectation for such a scenario is that for overlapping config for the sa= me state that BGP will have its neighbor configuration in an IDR defined dat= a model. I2rs will have separate neighbor configuration. In such a case prio= rity is expected to arbitrate the tie breaking.=20 Jeff > On Sep 17, 2014, at 20:20, "Susan Hares" wrote: >=20 > Jeff: > =20 > With I2RS datastore (empheral) and I2RS Config there is always a chance th= at two different actions will change the same data. Take the example config= you use in section 2.7 and assume that both I2rs and normal config want to m= odify this bgp config in the bgp routing process. First =E2=80=93 do you t= hink this is possible? =20 > =20 > If you do then section 2.7=E2=80=99s atomic transactions will need to be a= ugmented to indicate the interaction priority between the following differen= t events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (rol= lback). I define interaction priority as the priority (interrupt or sequen= cing) when one of these events overlaps with another. > =20 > Sue > =20 > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas > Sent: Friday, September 12, 2014 5:09 PM > To: i2rs@ietf.org; netmod@ietf.org > Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2= rs requirements) > =20 > With some help from Kent, Dean and Alia, I've put together a rough first d= raft of requirements I2RS has on netmod/netconf. It should be strongly note= d that due to a confluence of a lot of bad timing (travel, vacation, > etc.) I didn't have time to more broadly reach out and involve interested p= arties. > =20 > As such, please note that this draft is not an I2RS WG draft and does not h= ave current WG consensus. At best, it reflects my attempt to summarize prio= r discussions and turn them into requirements. This document will most assu= redly be wrong and be revised. > =20 > But it's primary purpose was to provide a start of the discussion of I2RS r= equirements at the netmod interim meeting next week. > =20 > My abject apologies to the I2RS and netmod working groups - this was the f= astest I could get the text out. > =20 > Comments are appreciated. Flames are not unexpected. > =20 > -- Jeff > =20 > =20 > =20 > New Internet-Draft is available from the on-line Internet-Drafts directori= es. > =20 > =20 > Title : I2RS requirements for netmod/netconf > Author : Jeffrey Haas > Filename : draft-haas-i2rs-netmod-netconf-requirements-00.t= xt > Pages : 10 > Date : 2014-09-12 > =20 > Abstract: > This document covers requests to the netmod and netconf Working > Groups for functionality to support requirements to implement the > I2RS architecture. > =20 > =20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requiremen= ts/ > =20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 > =20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable
Sue,

My expec= tation for such a scenario is that for overlapping config for the same state= that BGP will have its neighbor configuration in an IDR defined data model.= I2rs will have separate neighbor configuration. In such a case priority is e= xpected to arbitrate the tie breaking. 

Jeff

On Se= p 17, 2014, at 20:20, "Susan Hares" <s= hares@ndzh.com> wrote:

Jeff:

 <= /p>

With I2RS datastore (empheral) and I2RS Config t= here is always a chance that two different actions will change the same data= .  Take the example config you use in section 2.7 and assume that both I= 2rs and normal config want to modify this bgp config in the bgp routing proc= ess.   First =E2=80=93 do you think this is possible?  <= /o:p>

 

If you do then section 2.7=E2=80=99s atomic transactions will need to b= e augmented to indicate the interaction priority between the following diffe= rent events I2RS (valid), I2RS (invalid/roll-back), config (valid), config (= rollback).   I define interaction priority as the priority (interr= upt or sequencing) when one of these events overlaps with another.

 

Sue

 

-----Original Me= ssage-----
From: i2rs [mailto:i2= rs-bounces@ietf.org] On Behalf Of Jeffrey Haas
Sent: Friday, Septembe= r 12, 2014 5:09 PM
To: i2rs@ietf.org= ; netmod@ietf.org
Subject: [i2rs] I= 2RS requests to netmod/netconf (was netmod interim and i2rs requirements)

 

Wi= th some help from Kent, Dean and Alia, I've put together a rough first draft= of requirements I2RS has on netmod/netconf.  It should be strongly not= ed that due to a confluence of a lot of bad timing (travel, vacation,

etc.) I didn't have time to more broadly r= each out and involve interested parties.

 

As such, please note tha= t this draft is not an I2RS WG draft and does not have current WG consensus.=   At best, it reflects my attempt to summarize prior discussions and tu= rn them into requirements.  This document will most assuredly be wrong a= nd be revised.

 

=

But it's primary purpose was to provide a start of= the discussion of I2RS requirements at the netmod interim meeting next week= .

 

My abject apologies to the I2RS and netmod working groups - thi= s was the fastest I could get the text out.

 

Comments are apprecia= ted.  Flames are not unexpected.

 

-- Jeff

 

&nb= sp;

 

New Internet-Draft is available from the on-line Internet-Drafts d= irectories.

 

 

 &= nbsp;      Title      = ;     : I2RS requirements for netmod/netconf<= /p>

        Auth= or          : Jeffrey Haas=

      &nbs= p; Filename        : draft-haas-i2rs-netm= od-netconf-requirements-00.txt

 = ;       Pages     &nb= sp;     : 10

&nb= sp;       Date     &n= bsp;      : 2014-09-12

 

Abstract:

   This document covers requests t= o the netmod and netconf Working

&nb= sp;  Groups for functionality to support requirements to implement the<= o:p>

   I2RS architecture.=

 

 

The IETF datatracker s= tatus page for this draft is:

https://datatr= acker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available at:

http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requiremen= ts-00

 

_______________________________________________<= o:p>

i2rs mailing list

i2rs@ietf.org

https://www.ietf.org/= mailman/listinfo/i2rs

= --Apple-Mail-22B5C956-2439-4A5A-B2BD-38C9F51FDB12-- From nobody Thu Sep 18 04:50:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 121FD1A8747 for ; Thu, 18 Sep 2014 04:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 e3qgaq-Vvnqa for ; Thu, 18 Sep 2014 04:50:01 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BA4BA1A874C for ; Thu, 18 Sep 2014 04:49:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=28182; q=dns/txt; s=iport; t=1411040992; x=1412250592; h=message-id:date:from:mime-version:to:subject; bh=/ewzAVcEpDXLWoXzQKMHfBO3cI59L9oF51e4UEJjmC0=; b=NAV1XSAOUctfWDd9deoMapU32Vv+Yk+sWpFBhhoQyrpx8Skjp49hrR6Y sCAtz5kyHDlL9tf7eEktIFf4mOF7gYSNvKK8JKxomF1PuI7wAlIKHm01T x3VjVjoEvyl5cJlvSzsbYc4XxP5umKwevR8ZkDppYqXj+w27CVAtMapbn w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AooHAHjGGlStJA2N/2dsb2JhbABGFwOCR0ZTV4hbwHOIWRYBeYQ3ORI9CwQHAQEWAwIBAgFEBAMNCAEBiDoNNpsypWQBF4xCAYJwXAeEMwWGH49mhDaCUYE4KIVphH6JAYMLbyEvAYJJAQEB X-IronPort-AV: E=Sophos; i="5.04,546,1406592000"; d="scan'208,217"; a="79015200" Received: from alln-core-8.cisco.com ([173.36.13.141]) by alln-iport-1.cisco.com with ESMTP; 18 Sep 2014 11:49:37 +0000 Received: from [10.82.216.22] (rtp-vpn3-22.cisco.com [10.82.216.22]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id s8IBnaxN016268 for ; Thu, 18 Sep 2014 11:49:36 GMT Message-ID: <541AC6CF.4060002@cisco.com> Date: Thu, 18 Sep 2014 07:49:35 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: NETMOD Working Group Content-Type: multipart/alternative; boundary="------------050308030603070508020304" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2J-KgYC1FIP33hOA46TOMsd2NeE Subject: [netmod] New webex info for today interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 11:50:08 -0000 This is a multi-part message in MIME format. --------------050308030603070508020304 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear all, Here it is. The meeting starts in 1h10 from now. Regards, Benoit ----------------------------------------------------------------------- JOIN USING WebEx Go To: https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246 Meeting Password ----- netmod Meeting Number ----- 202 618 800 ---------------------------------------------------------------- ALERT -- PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: -San Jose/Milpitas (408) area:525-6800 -RTP (919) area:392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones)." If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number." Please use the call-back option whenever possible and otherwise dial local numbers only.The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign. San Jose, CA: +1.408.525.6800RTP: +1.919.392.3330 US/Canada: +1.866.432.9903United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111Germany: +49.619.6773.9002 Japan: +81.3.5763.9394China: +86.10.8515.5666 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation. Regards, Benoit --------------050308030603070508020304 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dear all,

Here it is.
The meeting starts in 1h10 from now.

Regards, Benoit

-----------------------------------------------------------------------

JOIN USING WebEx

 

Go To:

https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246

 

Meeting Password ----- netmod

Meeting Number ----- 202 618 800

 

----------------------------------------------------------------

ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES

----------------------------------------------------------------

Please dial the local access number for your area from the list below:

-  San Jose/Milpitas (408) area:  525-6800

-  RTP (919) area:  392-3330

 

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones).  “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

 

-------------------------------------------------------

To join the teleconference only

-------------------------------------------------------

1. Dial into Cisco WebEx (view all Global Access Numbers at

http://cisco.com/en/US/about/doing_business/conferencing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330

 

US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117

 

India: +91.80.4350.1111  Germany: +49.619.6773.9002

 

Japan: +81.3.5763.9394  China: +86.10.8515.5666

 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.


Regards, Benoit


--------------050308030603070508020304-- From nobody Thu Sep 18 05:52:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99B0C1A02D5 for ; Thu, 18 Sep 2014 05:52:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_PASS=-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 H3bk5VhJt5z9 for ; Thu, 18 Sep 2014 05:52:14 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1bon0787.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::1:787]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DFFC61A87CA for ; Thu, 18 Sep 2014 05:51:23 -0700 (PDT) Received: from CO1PR05MB457.namprd05.prod.outlook.com (10.141.72.141) by CO1PR05MB538.namprd05.prod.outlook.com (10.141.73.24) with Microsoft SMTP Server (TLS) id 15.0.1024.12; Thu, 18 Sep 2014 12:51:00 +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.1029.13; Thu, 18 Sep 2014 12:50:59 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.179]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.80]) with mapi id 15.00.1029.000; Thu, 18 Sep 2014 12:50:59 +0000 From: Kent Watsen To: Benoit Claise , NETMOD Working Group Thread-Topic: [netmod] New webex info for today interim meeting Thread-Index: AQHP0za4tscj8KxYrE+584MuTUCq1pwGlOQA Date: Thu, 18 Sep 2014 12:50:58 +0000 Message-ID: References: <541AC6CF.4060002@cisco.com> In-Reply-To: <541AC6CF.4060002@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.12] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:;UriScan:; x-forefront-prvs: 033857D0BD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(199003)(377454003)(164054003)(189002)(107886001)(86362001)(20776003)(107046002)(83072002)(87936001)(36756003)(31966008)(19580405001)(83322001)(76482002)(64706001)(50986999)(101416001)(97736003)(81342003)(92726001)(2656002)(66066001)(16799955002)(54356999)(99396002)(106356001)(79102003)(15975445006)(81542003)(83506001)(106116001)(19617315012)(16236675004)(4396001)(15202345003)(99286002)(90102001)(76176999)(74502003)(105586002)(19580395003)(95666004)(19625215002)(77982003)(21056001)(74662003)(80022003)(77096002)(85306004)(46102003)(85852003)(15395725005)(92566001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB457; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_D0404D1C81E70kwatsenjunipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fK05lYwSP0iwG4so0qMa-FhPbVs Subject: Re: [netmod] New webex info for today interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 12:52:18 -0000 --_000_D0404D1C81E70kwatsenjunipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Benoit, That Webex invite says that it's for yesterday (Wed 17) and that it's not s= tarted yet - maybe a different URL? Thanks, Kent From: Benoit Claise > Date: Thursday, September 18, 2014 at 7:49 AM To: NETMOD Working Group > Subject: [netmod] New webex info for today interim meeting Dear all, Here it is. The meeting starts in 1h10 from now. Regards, Benoit ----------------------------------------------------------------------- JOIN USING WebEx Go To: https://cisco.webex.com/cisco/j.php?MTID=3Dm3949f8b2f33047bbe5c06a068969824= 6 Meeting Password ----- netmod Meeting Number ----- 202 618 800 ---------------------------------------------------------------- ALERT - PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408= ) OR (919) AREA CODES ---------------------------------------------------------------- Please dial the local access number for your area from the list below: - San Jose/Milpitas (408) area: 525-6800 - RTP (919) area: 392-3330 Dialing the WebEx toll free numbers from within 408 or 919 area codes is no= t enabled (non-Cisco phones). " If you dial the toll-free numbers within t= he 408 or 919 area codes you will be instructed to hang up and dial the loc= al access number." Please use the call-back option whenever possible and ot= herwise dial local numbers only. The affected toll free numbers are: (866)= 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP are= a. ------------------------------------------------------- To join the teleconference only ------------------------------------------------------- 1. Dial into Cisco WebEx (view all Global Access Numbers at http://cisco.com/en/US/about/doing_business/conferencing/index.html 2. Follow the prompts to enter the Meeting Number (listed above) or Access = Code followed by the # sign. San Jose, CA: +1.408.525.6800 RTP: +1.919.392.3330 US/Canada: +1.866.432.9903 United Kingdom: +44.20.8824.0117 India: +91.80.4350.1111 Germany: +49.619.6773.9002 Japan: +81.3.5763.9394 China: +86.10.8515.5666 IMPORTANT NOTICE: This WebEx service includes a feature that allows audio a= nd any documents and other materials exchanged or viewed during the session= to be recorded. By joining this session, you automatically consent to such= recordings. If you do not consent to the recording, discuss your concerns = with the meeting host prior to the start of the recording or do not join th= e session. Please note that any such recordings may be subject to discovery= in the event of litigation. Regards, Benoit --_000_D0404D1C81E70kwatsenjunipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <0D4D369ED8ACCA4988B451290F180B31@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable
Hi Benoit,

That Webex invite says that it's for yesterday (Wed 17) and that it's = not started yet – maybe a different URL?

Thanks,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, September 18, 2014 = at 7:49 AM
To: NETMOD Working Group <netmod@ietf.org>
Subject: [netmod] New webex info fo= r today interim meeting

Dear all,

Here it is.
The meeting starts in 1h10 from now.

Regards, Benoit

----------------------------------------------------= -------------------

JOIN USING WebEx

 

Go To:

https://cisco.webex.com/cisco/j.php?M= TID=3Dm3949f8b2f33047bbe5c06a0689698246

 

Meeting Password ----- netmod

Meeting Number ----- 202 618 800

 

----------------------------------------------------= ------------

ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE= NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES

----------------------------------------------------= ------------

Please dial the local access number for your area fr= om the list below:

-  San = Jose/Milpitas (408) area:  525-6800

-  RTP = (919) area:  392-3330

 <= /o:p>

Dialing the WebEx toll free numbers from within 408 = or 919 area codes is not enabled (non-Cisco phones).  “ If you dial the toll-free numbers within the 408 or 919 area= codes you will be instructed to hang up and dial the local access number.&= #8221; Please use the call-back option whenever possible and otherwise dial= local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/= Milpitas area and (866) 349-3520 for the RTP area.

 

----------------------------------------------------= ---

To join the teleconference only

----------------------------------------------------= ---

1. Dial into Cisco WebEx (view all Global Access Num= bers at

http://cisco.com/en/US/about/doing_business/con= ferencing/index.html

2. Follow the prompts to enter the Meeting Number (l= isted above) or Access Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330

 

US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117

 

India: +91.80.4350.1111  Germany: +49.619.6773.9002

 

Japan: +81.3.5763.9394  China: +86.10.8515.5666

 

IMPORTANT NOTICE: This WebEx service includes a feat= ure that allows audio and any documents and other materials exchanged or vi= ewed during the session to be recorded. By joining this session, you automa= tically consent to such recordings. If you do not consent to the recording, discuss your concerns with the mee= ting host prior to the start of the recording or do not join the session. P= lease note that any such recordings may be subject to discovery in the even= t of litigation.


Regards, Benoit


 --_000_D0404D1C81E70kwatsenjunipernet_-- From nobody Thu Sep 18 06:27:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AAD21A038C for ; Thu, 18 Sep 2014 06:27:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -16.152 X-Spam-Level: X-Spam-Status: No, score=-16.152 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=-1.652, 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 wZVXAmkCLKgE for ; Thu, 18 Sep 2014 06:27:39 -0700 (PDT) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56DD71A02D5 for ; Thu, 18 Sep 2014 06:27:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31296; q=dns/txt; s=iport; t=1411046859; x=1412256459; h=message-id:date:from:mime-version:to:subject:references: in-reply-to; bh=XGUDaP1pZ9nthe7o3N1/WuIU9Oop//REcpl7h/GXJmU=; b=h4BdC6MWIouZUEvST8PBUq8BD3uG/88UhHJeRSKK8he2irU7bddOr3FR f7AQWWiSo3wMQyHJ5aPXxe8Nk4JYRVOJBp95J6WO4ih4teWD3sIhV766U dZirE6MGYCa1lBrnUuR0HUq1v46nSViXsPyQr9xP1CQgE0ocL8tutQtFy 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApAHAPfcGlStJA2G/2dsb2JhbABGFwOCR0ZTV4hbwHiHSwGBDRYBeYQDAQEBBC05EhELDgMDAQIKCwQHAQEGBwkDAgECATQJBwEDAwEMBgIBAYg6DTbBMwEXjEIBgnAzARcRB4QzBYYfj2aENoJRgTgohWmEfokBgwtvIS8BgkkBAQE X-IronPort-AV: E=Sophos; i="5.04,547,1406592000"; d="scan'208,217"; a="79046210" Received: from alln-core-12.cisco.com ([173.36.13.134]) by alln-iport-1.cisco.com with ESMTP; 18 Sep 2014 13:27:37 +0000 Received: from [10.131.25.47] (dhcp-10-131-25-47.cisco.com [10.131.25.47]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id s8IDRbV8025104; Thu, 18 Sep 2014 13:27:37 GMT Message-ID: <541ADDC9.3040902@cisco.com> Date: Thu, 18 Sep 2014 09:27:37 -0400 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0 MIME-Version: 1.0 To: Kent Watsen , NETMOD Working Group References: <541AC6CF.4060002@cisco.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------090602030507040907050200" Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/yusoIsMmUbAuBtgvfMYgBcmYsHU Subject: Re: [netmod] New webex info for today interim meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 13:27:42 -0000 This is a multi-part message in MIME format. --------------090602030507040907050200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Kent, Dan and I are in this webex below. Regards, Benoit > Hi Benoit, > > That Webex invite says that it's for yesterday (Wed 17) and that it's > not started yet -- maybe a different URL? > > Thanks, > Kent > > > From: Benoit Claise > > Date: Thursday, September 18, 2014 at 7:49 AM > To: NETMOD Working Group > > Subject: [netmod] New webex info for today interim meeting > > Dear all, > > Here it is. > The meeting starts in 1h10 from now. > > Regards, Benoit > > ----------------------------------------------------------------------- > > JOIN USING WebEx > > Go To: > > https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246 > > Meeting Password ----- netmod > > Meeting Number ----- 202 618 800 > > ---------------------------------------------------------------- > > ALERT -- PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN > THE (408) OR (919) AREA CODES > > ---------------------------------------------------------------- > > Please dial the local access number for your area from the list below: > > -San Jose/Milpitas (408) area:525-6800 > > -RTP (919) area:392-3330 > > Dialing the WebEx toll free numbers from within 408 or 919 area codes > is not enabled (non-Cisco phones)." If you dial the toll-free numbers > within the 408 or 919 area codes you will be instructed to hang up and > dial the local access number." Please use the call-back option > whenever possible and otherwise dial local numbers only.The affected > toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area > and (866) 349-3520 for the RTP area. > > ------------------------------------------------------- > > To join the teleconference only > > ------------------------------------------------------- > > 1. Dial into Cisco WebEx (view all Global Access Numbers at > > http://cisco.com/en/US/about/doing_business/conferencing/index.html > > 2. Follow the prompts to enter the Meeting Number (listed above) or > Access Code followed by the # sign. > > San Jose, CA: +1.408.525.6800RTP: +1.919.392.3330 > > US/Canada: +1.866.432.9903United Kingdom: +44.20.8824.0117 > > India: +91.80.4350.1111Germany: +49.619.6773.9002 > > Japan: +81.3.5763.9394China: +86.10.8515.5666 > > IMPORTANT NOTICE: This WebEx service includes a feature that allows > audio and any documents and other materials exchanged or viewed during > the session to be recorded. By joining this session, you automatically > consent to such recordings. If you do not consent to the recording, > discuss your concerns with the meeting host prior to the start of the > recording or do not join the session. Please note that any such > recordings may be subject to discovery in the event of litigation. > > > Regards, Benoit > > --------------090602030507040907050200 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Kent,

Dan and I are in this webex below.

Regards, Benoit
Hi Benoit,

That Webex invite says that it's for yesterday (Wed 17) and that it's not started yet – maybe a different URL?

Thanks,
Kent


From: Benoit Claise <bclaise@cisco.com>
Date: Thursday, September 18, 2014 at 7:49 AM
To: NETMOD Working Group <netmod@ietf.org>
Subject: [netmod] New webex info for today interim meeting

Dear all,

Here it is.
The meeting starts in 1h10 from now.

Regards, Benoit

-----------------------------------------------------------------------

JOIN USING WebEx

 

Go To:

https://cisco.webex.com/cisco/j.php?MTID=m3949f8b2f33047bbe5c06a0689698246

 

Meeting Password ----- netmod

Meeting Number ----- 202 618 800

 

----------------------------------------------------------------

ALERT – PLEASE READ: DO NOT DIAL THE TOLL FREE NUMBERS FROM WITHIN THE (408) OR (919) AREA CODES

----------------------------------------------------------------

Please dial the local access number for your area from the list below:

-  San Jose/Milpitas (408) area:  525-6800

-  RTP (919) area:  392-3330

 

Dialing the WebEx toll free numbers from within 408 or 919 area codes is not enabled (non-Cisco phones).  “ If you dial the toll-free numbers within the 408 or 919 area codes you will be instructed to hang up and dial the local access number.” Please use the call-back option whenever possible and otherwise dial local numbers only.  The affected toll free numbers are: (866) 432-9903 for the San Jose/Milpitas area and (866) 349-3520 for the RTP area.

 

-------------------------------------------------------

To join the teleconference only

-------------------------------------------------------

1. Dial into Cisco WebEx (view all Global Access Numbers at

http://cisco.com/en/US/about/doing_business/conferencing/index.html

2. Follow the prompts to enter the Meeting Number (listed above) or Access Code followed by the # sign.

 

San Jose, CA: +1.408.525.6800  RTP: +1.919.392.3330

 

US/Canada: +1.866.432.9903  United Kingdom: +44.20.8824.0117

 

India: +91.80.4350.1111  Germany: +49.619.6773.9002

 

Japan: +81.3.5763.9394  China: +86.10.8515.5666

 

IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. By joining this session, you automatically consent to such recordings. If you do not consent to the recording, discuss your concerns with the meeting host prior to the start of the recording or do not join the session. Please note that any such recordings may be subject to discovery in the event of litigation.


Regards, Benoit

--------------090602030507040907050200-- From nobody Thu Sep 18 09:59:15 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 092AF1A04E7; Thu, 18 Sep 2014 09:59:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 hZcMiTZ1fCHl; Thu, 18 Sep 2014 09:58:57 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id B1C451A04A1; Thu, 18 Sep 2014 09:58:53 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.183.212; From: "Susan Hares" To: "'Jeff Haas'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> In-Reply-To: Date: Thu, 18 Sep 2014 12:58:51 -0400 Message-ID: <004601cfd361$d2cbe520$7863af60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0047_01CFD340.4BBCDD30" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3mcoapM8A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1TSpC6T3IDnGvRB4ceESQelzpzY Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 16:59:01 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0047_01CFD340.4BBCDD30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Jeff: =20 Where does the priority live =E2=80=93 in I2RS or in config module or in = BGP routing model? How does this work with the three datastore = proposals: 1) separate empheral data store, 2) configuration state in = existing datastore tagged by model as empheral, and 3) whole data stores = tagged empheral, config, or both. Is the routing code that sets the = priority and handles the rollback?=20 =20 Config datastore ----------------routing bgp code=20 | I2rs instance/datastore --------------- =20 =20 Sue=20 =20 From: Jeff Haas [mailto:jhaas@pfrc.org]=20 Sent: Thursday, September 18, 2014 7:12 AM To: Susan Hares Cc: ; Subject: Re: [i2rs] I2RS requests to netmod/netconf (was netmod interim = and i2rs requirements) =20 Sue, =20 My expectation for such a scenario is that for overlapping config for = the same state that BGP will have its neighbor configuration in an IDR = defined data model. I2rs will have separate neighbor configuration. In = such a case priority is expected to arbitrate the tie breaking.=20 Jeff On Sep 17, 2014, at 20:20, "Susan Hares" wrote: Jeff: =20 With I2RS datastore (empheral) and I2RS Config there is always a chance = that two different actions will change the same data. Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process. = First =E2=80=93 do you think this is possible? =20 =20 If you do then section 2.7=E2=80=99s atomic transactions will need to be = augmented to indicate the interaction priority between the following = different events I2RS (valid), I2RS (invalid/roll-back), config (valid), = config (rollback). I define interaction priority as the priority = (interrupt or sequencing) when one of these events overlaps with = another.=20 =20 Sue =20 -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Friday, September 12, 2014 5:09 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] I2RS requests to netmod/netconf (was netmod interim and = i2rs requirements) =20 With some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf. It should be strongly = noted that due to a confluence of a lot of bad timing (travel, vacation, etc.) I didn't have time to more broadly reach out and involve = interested parties. =20 As such, please note that this draft is not an I2RS WG draft and does = not have current WG consensus. At best, it reflects my attempt to = summarize prior discussions and turn them into requirements. This = document will most assuredly be wrong and be revised. =20 But it's primary purpose was to provide a start of the discussion of = I2RS requirements at the netmod interim meeting next week. =20 My abject apologies to the I2RS and netmod working groups - this was the = fastest I could get the text out. =20 Comments are appreciated. Flames are not unexpected. =20 -- Jeff =20 =20 =20 New Internet-Draft is available from the on-line Internet-Drafts = directories. =20 =20 Title : I2RS requirements for netmod/netconf Author : Jeffrey Haas Filename : = draft-haas-i2rs-netmod-netconf-requirements-00.txt Pages : 10 Date : 2014-09-12 =20 Abstract: This document covers requests to the netmod and netconf Working Groups for functionality to support requirements to implement the I2RS architecture. =20 =20 The IETF datatracker status page for this draft is: = = https://datatracker.ietf.org/doc/draft-haas-i2rs-netmod-netconf-requireme= nts/ =20 There's also a htmlized version available at: = = http://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00= =20 _______________________________________________ i2rs mailing list i2rs@ietf.org = https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_0047_01CFD340.4BBCDD30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Where does the priority = live =E2=80=93 in I2RS or in config module or in BGP routing model? = =C2=A0How does this work with the three datastore proposals: 1) separate = empheral data store, 2) configuration state in existing datastore tagged = by model as empheral, and 3) whole data stores tagged empheral, config, = or both. =C2=A0=C2=A0Is the routing code that sets the priority and = handles the rollback?

 

Config datastore = ----------------routing bgp code

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=

I2rs instance/datastore = ---------------

 

 

Sue =

 

From:= = Jeff Haas [mailto:jhaas@pfrc.org]
Sent: Thursday, September = 18, 2014 7:12 AM
To: Susan Hares
Cc: = <i2rs@ietf.org>; <netmod@ietf.org>
Subject: Re: = [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 

Sue,

 

My expectation for such a scenario is that for = overlapping config for the same state that BGP will have its neighbor = configuration in an IDR defined data model. I2rs will have separate = neighbor configuration. In such a case priority is expected to arbitrate = the tie breaking. 

Jeff


On Sep 17, 2014, at = 20:20, "Susan Hares" <shares@ndzh.com> = wrote:

Jeff:

 

With = I2RS datastore (empheral) and I2RS Config there is always a chance that = two different actions will change the same data.  Take the example = config you use in section 2.7 and assume that both I2rs and normal = config want to modify this bgp config in the bgp routing process.  =  First =E2=80=93 do you think this is possible? =  

 

If you do then section 2.7=E2=80=99s atomic = transactions will need to be augmented to indicate the interaction = priority between the following different events I2RS (valid), I2RS = (invalid/roll-back), config (valid), config (rollback).   I = define interaction priority as the priority (interrupt or sequencing) = when one of these events overlaps with another.

 

Sue

 

-----Original Message-----
From: i2rs [mailto:i2rs-bounces@ietf.org] = On Behalf Of Jeffrey Haas
Sent: Friday, September 12, 2014 5:09 = PM
To: i2rs@ietf.org; netmod@ietf.org
Subject: [i2rs] = I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 

With = some help from Kent, Dean and Alia, I've put together a rough first = draft of requirements I2RS has on netmod/netconf.  It should be = strongly noted that due to a confluence of a lot of bad timing (travel, = vacation,

etc.) I didn't have time = to more broadly reach out and involve interested = parties.

 

As such, please note that this draft is not an I2RS = WG draft and does not have current WG consensus.  At best, it = reflects my attempt to summarize prior discussions and turn them into = requirements.  This document will most assuredly be wrong and be = revised.

 

But it's primary purpose was to provide a start of = the discussion of I2RS requirements at the netmod interim meeting next = week.

 

My abject apologies to the I2RS and netmod working = groups - this was the fastest I could get the text out.

 

Comments are appreciated.  Flames are not = unexpected.

 

-- = Jeff

 

 

 

New = Internet-Draft is available from the on-line Internet-Drafts = directories.

 

 

        = Title           : I2RS = requirements for netmod/netconf

        = Author          : Jeffrey = Haas

        = Filename        : = draft-haas-i2rs-netmod-netconf-requirements-00.txt

        = Pages           : = 10

        = Date            : = 2014-09-12

 

Abstract:

   This document covers requests to the = netmod and netconf Working

   Groups for functionality to support = requirements to implement the

   I2RS architecture.

 

 

The = IETF datatracker status page for this draft is:

https://datatracker.ietf.= org/doc/draft-haas-i2rs-netmod-netconf-requirements/

 

There's also a htmlized version available = at:

http://tools.ietf.org/htm= l/draft-haas-i2rs-netmod-netconf-requirements-00

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_0047_01CFD340.4BBCDD30-- From nobody Thu Sep 18 14:08:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E24EC1A88A9 for ; Thu, 18 Sep 2014 14:08:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 sJwuNC_Sy6ds for ; Thu, 18 Sep 2014 14:08:28 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB06E1A8929 for ; Thu, 18 Sep 2014 14:08:28 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 86FC2E41C01B9; Thu, 18 Sep 2014 21:08:23 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8IL8Qqv008818 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 18 Sep 2014 17:08:26 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Thu, 18 Sep 2014 17:08:26 -0400 From: "Sterne, Jason (Jason)" To: Ladislav Lhotka , Balazs Lengyel Thread-Topic: [netmod] YANG 1.1 Y12 (initialized-by-system) Thread-Index: Ac/MY97+sqNJWhnwQHW0OUsseK+t2QAK+SKAABfXXgAAAQrhgAGjQ+XA Date: Thu, 18 Sep 2014 21:08:25 +0000 Message-ID: References: <20140909.224005.02423221.mbj@tail-f.com> <541005A4.50209@ericsson.com> <9D8CC12B-E4CE-4A4E-9830-D7B372FF7F47@nic.cz> In-Reply-To: <9D8CC12B-E4CE-4A4E-9830-D7B372FF7F47@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LedxvORqFC36kc7QQHY9pnFU6C0 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Sep 2014 21:08:31 -0000 Hi guys, I can't immediately see how initialized-by-system is more complicated or un= clear than its use with a leaf-list but I may be missing something. It wou= ld be a statement that simply tells the client that they should read the li= st to find pre-populated entries. WRT Martin's comment when I mentioned a system created 'admin' user and 'sy= stem' interface:=20 "This is already possible today. Most systems come with some kind of fa= ctory default config. When a client connects the very first time, it canno= t assume that the config is empty." That is true but doesn't the same argument hold for the use of initialized-= by-system for leafs and leaf-lists ? You don't *need* initialized-by-syste= m for leafs, leaf-lists or lists but it is useful to know what areas might = have pre-populated config. I agree the system-controlled interfaces in RFC 7223 are a bit different th= an this initialized-by-system concept in Y12. System-controlled (RFC 7223= ) is simply operational data (not part of the config ds). There is also a need to handle items that are initialized by the system but= are also considered part of the config datastore. Some of these items ca= n be deleted by the operator (e.g. for security they don't want the pre-pop= ulated 'admin' user).=20 Deletion of these entries can be done with an operation=3D'de= lete' but things get a little difficult when you support a startup datastor= e. When you delete the pre-initialized "admin" user in the running config= , and then copy the running config to the startup config, how do you indica= te in the startup config that the router should remove the "admin" user dur= ing startup ? I can't see how to model that with netconf/yang (i.e. what w= ould a of that list look like for the "admin" user ? Absence= of the user would not suppress the user during bootup). Some more comments below. Regards, Jason -----Original Message----- From: Ladislav Lhotka [mailto:lhotka@nic.cz]=20 Sent: Wednesday, September 10, 2014 4:33 AM To: Balazs Lengyel Cc: Martin Bj=F6rklund; Sterne, Jason (Jason); netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) On 10 Sep 2014, at 10:02, Balazs Lengyel wrot= e: > Hello, > IMHO initialized by system would be just as useful for lists as well. >=20 > In Ericsson a big number of lists (managed objects) are created by the sy= stem. It is usually forbidden to remove these system created lists, but som= etimes allowed. If it is forbidden, then it really looks like system-controlled list entrie= s: http://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-15#section-4.1 I think that letting the system (perhaps on behalf of other protocols like = DHCP or HNCP) write to NETCONF datastores should not be considered normal. = What if the datastore is locked when the write is supposed to happen? [>>JS] I don't think of it as a "NETCONF datastore". It is the system dat= astore and NETCONF is one protocol used to access and change it. Other i= nterfaces may also change it (SNMP, CLI). Some interfaces like DHCP may a= ffect behavior of the node and have saved state that isn't considered "conf= ig" and in that case it wouldn't be in the datastore (but may be in some ep= hemeral ds). I don't think we should get too deep into ephemeral datastor= es in this email thread but going back to the original point -> the system = may need to write to the config datastore (especially during system initial= ization). That's also why I think we need to develop the concept of a separate operat= ional datastore. The system could write there anytime without interfering w= ith NETCONF datastores. [>>JS] Are you thinking the operator could do an on that "ope= rational" datastore ? There may be a need to allow an operator to delete = some of these system initialized objects. > We also have such items under user created lists: if the user creates the= upper level list, then the system will automatically create the lower leve= l ones. > E.g. HW can be detected by the system and the relevant list-entries creat= ed, while some leafs for the HW will be user settable. All this is covered by system-controlled list entries. [>>JS] Agreed if the entries can't be deleted or modified by an operator >=20 > Why doesn't this apply to candidate? Actually, yes. If the system writes something only into running, then the c= lient who happens to be editing candidate may not be able to perform commit= anymore due to restricted access to the system-written data. Lada > regards Balazs >=20 >=20 > On 2014-09-09 22:40, Martin Bjorklund wrote: >>> Was there any previous discussion about having the=20 >>> initialized-by-system concept somehow applying to lists (i.e.=20 >>> indicating that the system might initialize some list instances/entries= )? >> IIRC everyone agreed that this was not needed. Unclear use cases,=20 >> and unclear how it would work. >>=20 >> /martin >=20 > --=20 > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > ECN: 831 7320 Tel: +36-1-437-7320 > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Thu Sep 18 17:45:21 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C98811A9122; Thu, 18 Sep 2014 17:45:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vHU-J4qsGFcO; Thu, 18 Sep 2014 17:45:16 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 98DCB1A9121; Thu, 18 Sep 2014 17:45:16 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.6.2.p6 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140919004516.31558.98225.idtracker@ietfa.amsl.com> Date: Thu, 18 Sep 2014 17:45:16 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nv1tquiGddwMPi860aJuwUzPc48 Cc: netmod@ietf.org Subject: [netmod] I-D Action: draft-ietf-netmod-snmp-cfg-08.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 00:45:18 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the NETCONF Data Modeling Language Working Group of the IETF. Title : A YANG Data Model for SNMP Configuration Authors : Martin Bjorklund Juergen Schoenwaelder Filename : draft-ietf-netmod-snmp-cfg-08.txt Pages : 81 Date : 2014-09-18 Abstract: This document defines a collection of YANG definitions for configuring SNMP engines. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-netmod-snmp-cfg-08 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-snmp-cfg-08 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 Sep 19 03:08:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E89E31A0079 for ; Fri, 19 Sep 2014 03:08:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.201 X-Spam-Level: X-Spam-Status: No, score=-3.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652, WEIRD_PORT=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 ohbAho8DSQ4j for ; Fri, 19 Sep 2014 03:08:39 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C099D1A0071 for ; Fri, 19 Sep 2014 03:08:38 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8A9A472D for ; Fri, 19 Sep 2014 12:08:37 +0200 (CEST) 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 0VlHOHp1xYI3 for ; Fri, 19 Sep 2014 12:08:13 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 19 Sep 2014 12:08:34 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8DD6A20036 for ; Fri, 19 Sep 2014 12:08:34 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Sw2oSzwNy5po; Fri, 19 Sep 2014 12:08:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DB48D20035; Fri, 19 Sep 2014 12:08:30 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0BB0F2E683E6; Fri, 19 Sep 2014 12:08:29 +0200 (CEST) Date: Fri, 19 Sep 2014 12:08:29 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140919100829.GA22159@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="h31gzZEtNLTqOjlF" Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LDv8rmujc5bSxSW1oWbGsrxivsY Subject: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 10:08:43 -0000 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, here are the draft minutes - please let me know what needs to be fixed. http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt I have to send the minutes to the secretariat for inclusion in the proceedings by the end of next week - so please send me any corrections until Thursday next week. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 --h31gzZEtNLTqOjlF Content-Type: text/plain; charset=utf-8 Content-Disposition: attachment; filename="netmod-2014-09-18-minutes.txt" Content-Transfer-Encoding: 8bit ============================================================= NETCONF Data Modeling Language WG (netmod) YANG 1.1 Interim Meeting (New York) Wednesday/Thursday, September 17/18, 2014, 09:00-18:00 Minutes Juergen Schoenwaelder ============================================================= * Agenda The agenda of the meeting is to work on YANG 1.1 open issues and in particular on - issues related to YANG 1.1 conformance; - issues related to YANG 1.1 datastores and I2RS support; - any remaining open YANG 1.1 issues. Wednesday 17: 09:00 Welcome and Agenda Bashing 09:10 YANG 1.1 (Conformance) 12:00 Lunch Break 13:00 YANG 1.1 (Conformance) 15:00 Coffee Break 15:30 YANG 1.1 (Conformance) 17:30 Summary of first day Thursday 18: 09:00 YANG 1.1 (I2RS support) 12:00 Lunch Break 13:00 YANG 1.1 (I2RS support) 15:00 Coffee Break 15:30 YANG 1.1 (other issues) 17:30 Summary of second day The topics mentioned in parenthesis are indicative. We will adapt depending on how fast we make progress. * Participants - Juergen Schoenwaelder (JS), Jacobs University Bremen - Lada Lhotka (LL), CZ.NIC Labs - Andy Bierman (AB), YumaWorks - Martin Bjoerklund (MB), Tail-f Systems / Cisco Systems - Mahesh Jethanandani (MJ), Cisco Systems - Benoit Claise (BC), Cisco Systems - Balazs Lengyel (BL), Ericsson - Peter Van Horne (PH), Cisco Systems - Jeffrey Haas (JH), Juniper Networks - Dean Bogdanovic (DB), Juniper Networks - Kent Watsen (KW), Juniper Networks (remote) - Dan Romascanu (DR), Avaya (remote) - Eric Voit (EV), Cisco Systems (remote) - Kiran Agrahara Sreenivasa (KS), Brocade (remote) * Etherpad http://etherpad.tools.ietf.org:9000/p/notes-ietf-2014-netmod-interim?useMonospaceFont=true * Recording https://cisco.webex.com/ciscosales/lsr.php?RCID=279b4f69a41148a7b35fdd8ababb7d2f * Issue List http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html * Y45 better conformance mechanism - JS: What is exactly the problem? - AB: current model based on importing modules this is too coarse grained - LL: routing model is a good example; the model is rather generic but implementations implement certain address families or specific routing protocols - KW: important that a client can figure out what exactly a server implements - JS, JH: What is the actual usage of 'conformance' information? We also need to distinguish conformance requirements from implementation capabilities - MB: This is most important for configuration, much less for state information - AB: There are also some modules that only define things like typedefs where it is unclear what implementing them really means - KW: we could use the "if-feature" more, but assumes being able to anticipate possible/common deviations. (can anyone see this update?) - AB: Customers do not like to write deviations - MB: Some of our customers do like writing deviations - AB: there are cases where the implemented API is split over multiple modules - AB: Announcing a module means "I am implementing the base" which is not always true. - PH: Reality is often that product groups implement subsets of modules that are required by the product groups; we try to work with features but this is difficult - PH: Another problem is that different teams use different tool chains and like to have different annotations to drive automation - PH: We prefer to work with features rather than deviations - JS: Predicting the features needed in the future is hard; refactoring modules is difficult in the IETF but likely also in large companies - AB: We can't change any published contracts - LL: I believe this is too strict - JS: Who writes package definitions? Module writers, management application implementers, NETCONF server implementers? - MB: Does the package definition have to be advertised? - AB: Probably not needed to be advertised - JH: Who is publishing package contracts? A body like the IETF, a management application writer, customers? - LL: Perhaps we need to find a way to define features later and outside of the module - MB: Perhaps we need to allow adding if-feature during module revisions - JS: How is this different from AB's proposal? - MB: This is clearly restricted to what features do and not allow arbitrary changes described in description clauses. - AB: Features right now do not even express how features depend on each other. - JH: How can vendors 'add' a feature to standard module? - AB: We need to have import >= revision (this may be a separate issue to track) - AB: An important goal is to be able to reconstruct the schema tree a certain implementation uses. - LL: Should do something like git-like, that is having 'version' numbers at different levels of the schema tree to make it easier to find out where things have changed? - MB: Consider adding indicators to the existing way we do announce conformance (e.g., indicating a module is just for importing types) - KW: Why not have vendors advertise the xpath of all the leaf/subtrees actually supported? - AB: A module that is purely optional is of little value for network management application writers. - MB: Do we continue to require a revision of a module in order to add a feature? - LL: It would be useful to have a require mechanism; the routing module does not import address specific modules but an implementation needs to implement a concrete address family - JS: What speaks against defining conformance outside of modules? - MB: This makes everything optional and then vendors implement only what they want to implement - KW et al: Vendors already today only implement what they want or are forced to implement, for business reasons. - KW: Turn it around, encourage vendors to announce correctly the 'features' they support instead of expecting them to announce what they do not do fully - MB, BL: It is unclear from RFC6020 whether all modules are advertised. This question came up several times with ietf-yang-types etc. - AB: We have an augmentation of the monitoring data model that says whether a module is implemented or just imported (e.g. to obtain typedefs). Summary so far, 3 potential tracks 1. Let’s drop feature/deviation and have everything as optional 2. Keep what we have today + the ability to have new features in a revised YANG module 3. Define features or something else outside of the modules a. One way is "package" (from draft-bierman-netmod-yang-conformance-02 b. potentially other solution, like a new YANG command Proposal: Keep features as the unit of conformance in YANG 1.1 but consider certain improvements: - indicate in the module advertisement data model the conformance associated with a module (full = "all base data nodes, rpcs, notifications", ) - support import by revision >= N OR remove import by revision (which is mostly important for groupings that get modified) - allow adding/removing features/if-features in revised YANG modules - add text with examples to the guidelines document - BL: There are a number of things like cardinality restrictions or subsets of identities supported that are typically implementation / product specific and outside of the general conformance mechanism. - MB: We did consider adding if-feature to enums (and hopefully also for identities). This is covered by Y11. - MB: Shall we require include by revision in YANG 1.1? This seems to be a bug-fix since otherwise it is absolutely unclear what a certain version of a module contains. - MB: If include by revision is mandatory, then we can find everything from the import statements. - AB: SMIv2 conformance remains static even if modules are updated. This is lacking in YANG. * Y16 module advertisement optimization / Y54 remove the advertisement of conformance information in NETCONF hello message - MB: YANG 1.0 modules will continue to be advertised in hello messages but for YANG 1.1 modules, we may advertise only a module set 'hash'. - MB: We should provide access to the module list in the same way for NETCONF and RESTCONF. - DB: We may have to support different module sets on NETCONF/RESTCONF or different module sets for different users or different module sets for different datastores. - MB: Since hello basically works, is this really a problem to fix, given the overall overhead of the secure transports NC is running over? RC does not have the equivalent of hello. - JS: The hello message size is mostly an issue for short lived sessions. - JH: Or for sessions running over links with noticeable packet loss rates. - DB: This may be an issue for eNodeBs. Proposal: We do not send YANG 1.1 module URIs but instead we send a hash or identifier. - JS: What is the scope of the hash or identifier? Is it scoped by the user or just by the NETCONF server? Do we go with a hello RPC or just pull this from a data model? Data model allows control from NACM, which may be a feature. Use the RESTCONF model as a starting point? Or revise RFC 6022? - BL: RFC6022 has NACM applied to it and thus it provides effectively information specific to a user. - LL: I suggest to factor the protocol bindings out of the YANG 1.1 specification into a different document. - JS: It would be nice to have the meta model Randy has been talking about but right now it seems a major surgery to a 1.1 update. - MB: Perhaps it is sufficient if all NETCONF specific parts are flagged in proper subsections. Proposal: We create a new ietf-yang-advertisement module that details a data model for the advertisement of YANG data models (that works in the same way for NETCONF and RESTCONF). * Y49 clarify nested submodule behavior Side discussion that submodule include is too complex. * Y42 a better model for configuration versus state data is needed - JS: Lets address this topic in several steps: 1st step: identify I2RS requirements for YANG 2nd step: identify which of those require changes in YANG 1.1 3rd step: discussion solution space - JH: Main issue seems the requirement to deal with ephemeral state - JS: Who decided when whether something is ephemeral or not? - JS: What determines the lifetime of ephemeral state? - MB: What is the data model for ephemeral state? Can the whole config data model be used for ephemeral state? - JH: One option is to have per module an indication whether it supports ephemeral state - JS: From a NETCONF view, is I2RS not just another (routing) protocol injecting routing state? - JH: Yes, but it may do more than just routing state. +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node - JH: Ephemeral state exists until reboot or an explicit action to clean up a complete ephemeral datastore or all state injected by a certain user into an ephemeral datastore - AB, MB: Important to keep the config datastore sane and valid - MB: What are the semantics of MUST constraints in ephemeral datastores? - BL: Datastore merge semantics are not necessarily clear. Are leafs from the config datastore of a list entry show through given an incomplete list entry in an ephemeral datastore? Do defaults apply? What is the merged content for validation (e.g., evaluation of MUST constraints)? - JH: This looks a lot like a union filesystem. - MB: Do we need to have merge attributes, e.g. to say that a certain prefix is to be deleted. - AB: How can this be made significantly faster than NETCONF's config datastores? Attempt of a summary where we are: - ephemeral is a new datastore that overlays the configuration datastore - data is merged into the operational state (delete/merge/replace attributes control how deltas are applied) - nodes have metadata (who created it, the priority or preference) - BC: How can we keep this simple? Is it realistic to assume that operators will be able to assign meaningful priorities? - JS: Why not have a priority per datastore and if multiple applications need different priorities, use multiple ephemeral datastores. - JH: Priorities (preferences) are assigned based on the target datastore and the user sending the data - BL: What the is value of having priorities/preferences lower than the config datastore? - MB: The config datastore does not have tags to say things not configured really should not be there. - DB: I think priorities lower than the config datastore are not needed. - JH: So far, I2RS wanted to allow priorities lower than config. - BL: I think we should have an edit-soft which can fail if overlay data becomes invalid and an edit-hard that will succeed but push the error to the application injecting ephemeral state. - JS: So, what do we need to change in YANG 1.1? - MB: config true|ephemeral|false (config true means can be edited in config and ephemeral datastores, ephemeral means can only be edited in ephemeral datastores, false means only operational state) Conclusion: We do not need any changes for YANG 1.1 (hurray) but instead we need a document that introduces ephemeral datastores and clarifies what validation means with ephemeral datastores. In addition, the NETCONF WG needs to do work to define suitable protocol operations and RESTCONF needs to make sure it is prepared to support ephemeral datastores. There is also NETCONF work to be done to improve notification handling. The only YANG 1.1 homework is to make sure that the language in the YANG 1.1 specification is flexible enough to enable the introduction of ephemeral datastores. * Y09 optional keys - MB: The current solution requires to change the syntax of instance identifier. Below is an example for a key "a b": | a | b | instance identifier | |---+---+---------------------| | 1 | 1 | /foo/[a=1][b=1] | | 2 | - | /foo/[a=2][not b] | | - | 2 | /foo/[not a][b=2] | | 2 | 1 | /foo/[a=2][b=1] | Note that /foo/[a=2] gives you the two list elements (2,-) and (2,1). - JS: How does this impact NACM? - MB: NACM formally uses an xpath derived type but the description refers to instance-identifier; a 1.0 NACM implementation of course won't support the new 'not' syntax. - PH: Would having a default on a key leaf help? - AB: Not every type has a default unused value in the value space. - JS: Longer discussion about workarounds, artificial keys (surrogate keys in DB speak) vs. natural keys. - JS: The real value of this dropped for me when we realized that optional keys can not be added. - AB: What is the problem? - MB: An old client will suddenly get multiple instances for something he things is leading to a unique instance. - Proposal: It remains unclear what the risk of changing instance-identifier is. To move forward with this, it might be necessary to have an explicit discussion on the mailing list where we explain that this issue leads to a change of the instance-identifier type and people should check whether that is acceptable for their implementations and tool chains or whether this can cause serious implementation problems/costs. * Y36 associate a notification with a data node - BL: for actions, access control rules apply easily - BL: maintaining context of operations associated with data nodes - BL: multiple implementations - JS: This may have to be split into a separate issue. - MB: This is how tail-f does actions today: eth0 container interfaces { list interface { action restart { input {...} output {...} } notification ... { } } } - JS: Why do you not send an instance-identifier as the first argument? - JS: Is this really naturally falling under NACM? - AB: I see the value of having actions linked to resources. - AB: Can actions appear in groupings? - MB: Actions are heavily used by customers. - MB: This requires to define an action RPC (and perhaps a special notification) and an update of NACM detailing how NACM applies to this. Resolution: MB to draft a solution proposal, JS to split actions out of Y36 into a separate issue. * ??? unique leaf-list - AB: The issue is that there is no way to delete a particular element since there is no unique name. - AB: With xpath, you could do /foo[a=1][b-2][position() = 1] leaf-list foo 10 20 30 10 - AB: What happens if there are already 10 nodes? How does 'replace' work? 10 - BL: I am fine with replacing all leaf-list nodes. - AB: 'replace' on a leaf-list has no meaning. - MB: What about 'delete'? What about insert after 10? - MB: It is not clear how to delete the whole list. - LL: This is a problem if one for example represents an AS path as a leaf-list. - JS: We should track this as another issue in the issue list. * Y18 when expression context Not discussed since we did run out of time. * Next Steps - JS will update the issue list, moving issues that have been resolved to the EDIT state. - MB will start producing a series of I-Ds to turn the resolutions into concrete text - We will move to bi-weekly virtual interim meetings to resolve any issues left and to deal with questions that might come up during the editing phase - The next virtual interim meeting will take place on Wednesday October 1st. --h31gzZEtNLTqOjlF-- From nobody Fri Sep 19 03:14:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF3B21A008D for ; Fri, 19 Sep 2014 03:14:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.202 X-Spam-Level: X-Spam-Status: No, score=-3.202 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-1.652] 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 9SJGFMIcMa59 for ; Fri, 19 Sep 2014 03:14:23 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C561E1A007D for ; Fri, 19 Sep 2014 03:14:17 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 97D29A85 for ; Fri, 19 Sep 2014 12:14:16 +0200 (CEST) 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 jNTbPl6RUqn1 for ; Fri, 19 Sep 2014 12:13:55 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 19 Sep 2014 12:14:16 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2224E20036 for ; Fri, 19 Sep 2014 12:14:16 +0200 (CEST) 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 7JE3Ozk6r9Ml; Fri, 19 Sep 2014 12:14:15 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4561D20035; Fri, 19 Sep 2014 12:14:15 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 344322E68471; Fri, 19 Sep 2014 12:14:15 +0200 (CEST) Date: Fri, 19 Sep 2014 12:14:15 +0200 From: Juergen Schoenwaelder To: netmod@ietf.org Message-ID: <20140919101415.GA22197@elstar.local> Mail-Followup-To: netmod@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bVBO7KF9UdWUZm9_E8OBoQUyBRk Subject: [netmod] next netmod virtual interim meetings X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 10:14:25 -0000 Hi, there will be no NETMOD virtual interim meeting next week. The next virtual interim meeting to work on YANG 1.1 issues is scheduled for Wednesday 2014-10-01 and the plan is to meet biweekly to work on YANG 1.1 issues. This means that we have scheduled virtual interim meeting time that can be used for other purposes. /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 Fri Sep 19 11:06:41 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36A5A1A0AEB for ; Fri, 19 Sep 2014 11:06:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 p1ZdwUWeE8de for ; Fri, 19 Sep 2014 11:06:36 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 282F21A0ADF for ; Fri, 19 Sep 2014 11:06:35 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 2C5B47EA83AD1; Fri, 19 Sep 2014 18:06:30 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s8JI6X7b020187 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 14:06:33 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 14:06:33 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder , "netmod@ietf.org" Thread-Topic: Y49 at interim NY meeting Thread-Index: AQHP0/G2B/li9SvRKkmN0FJQqc16VpwIvx6g Date: Fri, 19 Sep 2014 18:06:32 +0000 Message-ID: References: <20140919100829.GA22159@elstar.local> In-Reply-To: <20140919100829.GA22159@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CLkFp_oSJN0S0xcaXvJ9CRhwYh0 Subject: [netmod] Y49 at interim NY meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:06:39 -0000 Hi guys, Is there rough consensus on current "best practices" for nested sub-modules= ? I know there's been a lot of debate over this one in the past months. Is it incorrect to do simple nesting like a C #include, e.g.=20 module a includes submodule b (but not c) module b includes submodule c Jason -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen Schoenwa= elder Sent: Friday, September 19, 2014 6:08 AM To: netmod@ietf.org Subject: [netmod] draft minutes yang 1.1 interim meeting new york Hi, here are the draft minutes - please let me know what needs to be fixed.=20 http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.= txt I have to send the minutes to the secretariat for inclusion in the proceedi= ngs by the end of next week - so please send me any corrections until Thurs= day next week. /js --=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 Fri Sep 19 11:13:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8841E1A0B0C for ; Fri, 19 Sep 2014 11:12:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 9pP-OTM28Gzb for ; Fri, 19 Sep 2014 11:12:53 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 873B31A0B0A for ; Fri, 19 Sep 2014 11:12:31 -0700 (PDT) Received: from localhost (unknown [88.128.80.87]) by mail.tail-f.com (Postfix) with ESMTPSA id C025E1280457; Fri, 19 Sep 2014 20:12:26 +0200 (CEST) Date: Fri, 19 Sep 2014 14:12:12 -0400 (EDT) Message-Id: <20140919.141212.1330647465189699823.mbj@tail-f.com> To: jason.sterne@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: References: <20140919100829.GA22159@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/lWbLyGb3pjgscQm8oHZJlDTTH8M Cc: netmod@ietf.org Subject: Re: [netmod] Y49 at interim NY meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:12:59 -0000 "Sterne, Jason (Jason)" wrote: > Hi guys, > > Is there rough consensus on current "best practices" for nested > sub-modules ? I know there's been a lot of debate over this one in > the past months. > > Is it incorrect to do simple nesting like a C #include, e.g. > module a includes submodule b (but not c) > module b includes submodule c The problem is that RFC 6020 in unclear about this. Hence Y49 in order to clarify. I think that everyone agree that including all submodules in the main module is legal. What is unclear is if: module a include b (but not c) submodule b include c is legal or not. So - if you instead do module a include b and c you're good. /martin From nobody Fri Sep 19 11:17:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 049BC1A069B for ; Fri, 19 Sep 2014 11:17:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 tptuAaQ9k9cX for ; Fri, 19 Sep 2014 11:17:34 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9BDDB1A064D for ; Fri, 19 Sep 2014 11:17:34 -0700 (PDT) Received: from localhost (unknown [88.128.80.87]) by mail.tail-f.com (Postfix) with ESMTPSA id F00651280457; Fri, 19 Sep 2014 20:17:31 +0200 (CEST) Date: Fri, 19 Sep 2014 14:17:26 -0400 (EDT) Message-Id: <20140919.141726.294146032804399145.mbj@tail-f.com> To: jason.sterne@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: References: <541005A4.50209@ericsson.com> <9D8CC12B-E4CE-4A4E-9830-D7B372FF7F47@nic.cz> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/zwTlSu6Z1r2fuatiUc6ip666UcE Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:17:39 -0000 "Sterne, Jason (Jason)" wrote: > Hi guys, > > I can't immediately see how initialized-by-system is more complicated > or unclear than its use with a leaf-list but I may be missing > something. It would be a statement that simply tells the client that > they should read the list to find pre-populated entries. I am not sure what you mean with "pre-populated". > WRT Martin's comment when I mentioned a system created 'admin' user > and 'system' interface: > > "This is already possible today. Most systems come with some kind of > factory default config. When a client connects the very first time, > it cannot assume that the config is empty." > > That is true but doesn't the same argument hold for the use of > initialized-by-system for leafs and leaf-lists ? initialized-by-system is not used to mark factory defaults. It is used to tell the server that when its parent node is created, the system will provide a value unless set by the client. > You don't *need* > initialized-by-system for leafs, leaf-lists or lists Correct. > but it is useful > to know what areas might have pre-populated config. > > I agree the system-controlled interfaces in RFC 7223 are a bit > different than this initialized-by-system concept in Y12. > System-controlled (RFC 7223) is simply operational data (not part of > the config ds). > > There is also a need to handle items that are initialized by the > system but are also considered part of the config datastore. Some of > these items can be deleted by the operator (e.g. for security they > don't want the pre-populated 'admin' user). This goes outside the scope of the proposed initialized-by-system. IMO this should be solved with access control, rather than special treatment in the code. /martin From nobody Fri Sep 19 11:37:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E90B1A6FB1 for ; Fri, 19 Sep 2014 11:37:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 tB9aREGq8E8a for ; Fri, 19 Sep 2014 11:37:07 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44BB51A6FB7 for ; Fri, 19 Sep 2014 11:37:07 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id B197512029082; Fri, 19 Sep 2014 18:37:01 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s8JIb5XK029087 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 14:37:05 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 14:37:05 -0400 From: "Sterne, Jason (Jason)" To: Martin Bjorklund Thread-Topic: [netmod] YANG 1.1 Y12 (initialized-by-system) Thread-Index: Ac/MY97+sqNJWhnwQHW0OUsseK+t2QAK+SKAABfXXgAAAQrhgAGjQ+XAADXIgQAACDmKQA== Date: Fri, 19 Sep 2014 18:37:04 +0000 Message-ID: References: <541005A4.50209@ericsson.com> <9D8CC12B-E4CE-4A4E-9830-D7B372FF7F47@nic.cz> <20140919.141726.294146032804399145.mbj@tail-f.com> In-Reply-To: <20140919.141726.294146032804399145.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_jJW-0KV1cDpjkhA9fk1YKBM0jY Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:37:09 -0000 Thx Martin. Pls see below. Jason -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Friday, September 19, 2014 2:17 PM To: Sterne, Jason (Jason) Cc: lhotka@nic.cz; balazs.lengyel@ericsson.com; netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) "Sterne, Jason (Jason)" wrote: > Hi guys, >=20 > I can't immediately see how initialized-by-system is more complicated=20 > or unclear than its use with a leaf-list but I may be missing=20 > something. It would be a statement that simply tells the client that=20 > they should read the list to find pre-populated entries. I am not sure what you mean with "pre-populated". > WRT Martin's comment when I mentioned a system created 'admin' user=20 > and 'system' interface: >=20 > "This is already possible today. Most systems come with some kind of > factory default config. When a client connects the very first time, > it cannot assume that the config is empty." >=20 > That is true but doesn't the same argument hold for the use of=20 > initialized-by-system for leafs and leaf-lists ? initialized-by-system is not used to mark factory defaults. It is used to = tell the server that when its parent node is created, the system will provi= de a value unless set by the client. [>>JS] Thx. I didn't realize that was the primary use case but I can see h= ow that makes sense. That is a bit different than what I'm looking for bu= t I was hoping this initialized-by-system could somehow help. I'm not so = convinced now (especially to handle operator deletion of those system entri= es). I will start a separate thread for it. > You don't *need* > initialized-by-system for leafs, leaf-lists or lists Correct. [>>JS] Considering your use case I think maybe there is a case where it is = needed -> for mandatory leafs that may get initialized by the system. The= 'type' leaf in the ietf-interfaces is one that confused me (if it is manda= tory how can a client know it can create an interface without specifying a = value for it ?). > but it is useful > to know what areas might have pre-populated config. >=20 > I agree the system-controlled interfaces in RFC 7223 are a bit=20 > different than this initialized-by-system concept in Y12. > System-controlled (RFC 7223) is simply operational data (not part of=20 > the config ds). >=20 > There is also a need to handle items that are initialized by the=20 > system but are also considered part of the config datastore. Some of=20 > these items can be deleted by the operator (e.g. for security they=20 > don't want the pre-populated 'admin' user). This goes outside the scope of the proposed initialized-by-system. IMO this should be solved with access control, rather than special treatmen= t in the code. /martin From nobody Fri Sep 19 11:42:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4EEB1A7033 for ; Fri, 19 Sep 2014 11:42:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.551 X-Spam-Level: X-Spam-Status: No, score=-3.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.652] 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 RVqS30_MFNEc for ; Fri, 19 Sep 2014 11:42:25 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6360E1A7023 for ; Fri, 19 Sep 2014 11:42:25 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 36EE936BA78ED for ; Fri, 19 Sep 2014 18:42:20 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s8JIgMjF003272 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 19 Sep 2014 14:42:22 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 14:42:22 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: system created list entries Thread-Index: Ac/UOXIBDteTWVTgRUK+a6lLgcO5sQ== Date: Fri, 19 Sep 2014 18:42:21 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C947E55US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1Or2gRrSuuO9-Zfd26crOhYBYQ8 Subject: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 18:42:27 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C947E55US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Forking off a new thread since Y12 doesn't look like it will be applicable = to this issue. >From the Y12 thread: - JS: It would be a statement that simply tells the client that they = should read the list to find pre-populated entries. - MJB: I am not sure what you mean with "pre-populated". I wasn't sure what term to use here but the main use case I see is for list= s that are described in the data model (in the YANG modules) and have an en= try that is automatically created by the system at startup time. Other entries may be created by the user later, and the user needs to be ab= le to delete the system created entries (and make that persistent in a star= tup datastore so that after a subsequent bootup the system entry is deleted= ). I don't think these are "defaults" as defaults are described in RFC6020. = I was thinking it would make sense for them to be considered as part of the= contents of the datastore but I'm stumped on how to keep them deleted. Another possible solution is to treat these system created items as operati= onal data and have items in the config model to suppress them but that forc= es the creation of a lot of new config items (and anticipation of what the = system might want to automatically pre-populate/create). Jason --_000_A125E53CE190A749957C19483DC79F9F5C947E55US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Forking off a new thread since Y12 doesn’t look like it will be = applicable to this issue.  
 
From the Y12 thread:
  • JS: It would be a statement that simply tells the client that they shou= ld read the list to find pre-populated entries.
  • MJB: I am not sure = what you mean with "pre-populated".
    •
&= nbsp;
I= wasn't sure what term to use here but the main use case I see is for lists= that are described in the data model (in the YANG modules) and have an ent= ry that is automatically created by the system at startup time. 
&= nbsp;
O= ther entries may be created by the user later, and the user needs to be abl= e to delete the system created entries (and make that persistent in a start= up datastore so that after a subsequent bootup the system entry is deleted).  
&= nbsp;
I= don't think these are "defaults" as defaults are described in RF= C6020.   I was thinking it would make sense for them to be consid= ered as part of the contents of the datastore but I’m stumped on how to keep them deleted.
&= nbsp;
A= nother possible solution is to treat these system created items as operatio= nal data and have items in the config model to suppress them but that force= s the creation of a lot of new config items (and anticipation of what the system might want to automatically pre-= populate/create).
&= nbsp;
J= ason
 
 
 
 --_000_A125E53CE190A749957C19483DC79F9F5C947E55US70TWXCHMBA11z_-- From nobody Fri Sep 19 12:04:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D605F1A06F0 for ; Fri, 19 Sep 2014 12:03:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.553 X-Spam-Level: X-Spam-Status: No, score=-3.553 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652, 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 vq4ZZ_jAbnNF for ; Fri, 19 Sep 2014 12:03:44 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id AA8171A86E3 for ; Fri, 19 Sep 2014 12:03:42 -0700 (PDT) Received: from localhost (unknown [88.128.80.87]) by mail.tail-f.com (Postfix) with ESMTPSA id ACD241280934; Fri, 19 Sep 2014 21:03:40 +0200 (CEST) Date: Fri, 19 Sep 2014 14:51:58 -0400 (EDT) Message-Id: <20140919.145158.1514198271114340913.mbj@tail-f.com> To: jason.sterne@alcatel-lucent.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/JLymDU9D1CuzSYh2fpEqUd8ob9w Cc: netmod@ietf.org Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:03:50 -0000 Hi, I don't see the problem; if I understand your description this works fine today. When the system starts up initially, nothing prevents it from initializing its config db w/ factory defaults. When a client connects, it can get-config to discover the initial db. The client can delete/create/modify the db as usual. The initial data is not special. /martin "Sterne, Jason (Jason)" wrote: > Forking off a new thread since Y12 doesn't look like it will be > applicable to this issue. > > >From the Y12 thread: > - JS: It would be a statement that simply tells the client that they > - should read the list to find pre-populated entries. > - MJB: I am not sure what you mean with "pre-populated". > > I wasn't sure what term to use here but the main use case I see is for > lists that are described in the data model (in the YANG modules) and > have an entry that is automatically created by the system at startup > time. > > Other entries may be created by the user later, and the user needs to > be able to delete the system created entries (and make that persistent > in a startup datastore so that after a subsequent bootup the system > entry is deleted). > > I don't think these are "defaults" as defaults are described in > RFC6020. I was thinking it would make sense for them to be considered > as part of the contents of the datastore but I'm stumped on how to > keep them deleted. > > Another possible solution is to treat these system created items as > operational data and have items in the config model to suppress them > but that forces the creation of a lot of new config items (and > anticipation of what the system might want to automatically > pre-populate/create). > > Jason > > > From nobody Fri Sep 19 12:56:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62F471A068A for ; Fri, 19 Sep 2014 12:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.552 X-Spam-Level: X-Spam-Status: No, score=-3.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.652] 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 SxtVP_HwY9VI for ; Fri, 19 Sep 2014 12:56:23 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF0DF1A0572 for ; Fri, 19 Sep 2014 12:56:23 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id BD5AFBA4ED593; Fri, 19 Sep 2014 19:56:18 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8JJuLL5026162 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 19 Sep 2014 15:56:22 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Fri, 19 Sep 2014 15:56:22 -0400 From: "Sterne, Jason (Jason)" To: Martin Bjorklund Thread-Topic: [netmod] system created list entries Thread-Index: Ac/UOXIBDteTWVTgRUK+a6lLgcO5sQAIt8cAAAZqtgA= Date: Fri, 19 Sep 2014 19:56:20 +0000 Message-ID: References: <20140919.145158.1514198271114340913.mbj@tail-f.com> In-Reply-To: <20140919.145158.1514198271114340913.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SNqglND0DNWJzwvTb5-cf284rK0 Cc: "netmod@ietf.org" Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Sep 2014 19:56:25 -0000 I'm good with your explanation that a system can just create list entries i= n the config datastore and a client should do a get-config to discover them= . The client can then delete those entries - no problem so far. A deletion simply causes an absence of that list entry in the datastore. = A would simply not have that item in the list - again no probl= em so far. But now I want that deletion to be persistent (i.e. that entry should not e= xist after the next bootup). If we take an example of a system that has a = running and a startup datastore, and we perform a copy-config from running-= >startup, then the startup ds doesn't contain that list entry. At the nex= t reboot the system will happily create that entry again. Maybe this is just an implementation specific issue that is outside the sco= pe of netconf & yang but if anyone has a solution that fits in with netconf= /yang that would be useful. Jason -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Friday, September 19, 2014 2:52 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] system created list entries Hi, I don't see the problem; if I understand your description this works fine t= oday. When the system starts up initially, nothing prevents it from initializing = its config db w/ factory defaults. When a client connects, it can get-config to discover the initial db. The client can delete/create/modify the db as usual. The initial data is n= ot special. /martin "Sterne, Jason (Jason)" wrote: > Forking off a new thread since Y12 doesn't look like it will be=20 > applicable to this issue. >=20 > >From the Y12 thread: > - JS: It would be a statement that simply tells the client that the= y > - should read the list to find pre-populated entries. > - MJB: I am not sure what you mean with "pre-populated". >=20 > I wasn't sure what term to use here but the main use case I see is for=20 > lists that are described in the data model (in the YANG modules) and=20 > have an entry that is automatically created by the system at startup=20 > time. >=20 > Other entries may be created by the user later, and the user needs to=20 > be able to delete the system created entries (and make that persistent=20 > in a startup datastore so that after a subsequent bootup the system=20 > entry is deleted). >=20 > I don't think these are "defaults" as defaults are described in=20 > RFC6020. I was thinking it would make sense for them to be considered=20 > as part of the contents of the datastore but I'm stumped on how to=20 > keep them deleted. >=20 > Another possible solution is to treat these system created items as=20 > operational data and have items in the config model to suppress them=20 > but that forces the creation of a lot of new config items (and=20 > anticipation of what the system might want to automatically=20 > pre-populate/create). >=20 > Jason >=20 >=20 >=20 From nobody Sun Sep 21 18:13:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A984F1A039F for ; Sun, 21 Sep 2014 18:13:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.836 X-Spam-Level: X-Spam-Status: No, score=-99.836 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 JuMfxJqg2N2i for ; Sun, 21 Sep 2014 18:13:43 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id DA35B1A037A for ; Sun, 21 Sep 2014 18:13:42 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id 3D5B4126016D; Mon, 22 Sep 2014 09:13:33 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s8M1DS0h035338; Mon, 22 Sep 2014 09:13:28 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140919100829.GA22159@elstar.local> References: <20140919100829.GA22159@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: EC72E7D2:210E49C3-48257D5B:0005A673; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Mon, 22 Sep 2014 09:13:28 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-09-22 09:13:16, Serialize complete at 2014-09-22 09:13:16 Content-Type: multipart/alternative; boundary="=_alternative 0006BA1348257D5B_=" X-MAIL: mse02.zte.com.cn s8M1DS0h035338 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/NuHqKakgaeZdV86YJBMDonYo-P0 Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 01:13:47 -0000 This is a multipart message in MIME format. --=_alternative 0006BA1348257D5B_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 KiBZMTYgbW9kdWxlIGFkdmVydGlzZW1lbnQgb3B0aW1pemF0aW9uIC8gWTU0IHJlbW92ZSB0aGUg YWR2ZXJ0aXNlbWVudCBvZiANCmNvbmZvcm1hbmNlIGluZm9ybWF0aW9uIGluIE5FVENPTkYgaGVs bG8gbWVzc2FnZQ0KDQogIC0gTUI6IFlBTkcgMS4wIG1vZHVsZXMgd2lsbCBjb250aW51ZSB0byBi ZSBhZHZlcnRpc2VkIGluIGhlbGxvDQogICAgbWVzc2FnZXMgYnV0IGZvciBZQU5HIDEuMSBtb2R1 bGVzLCB3ZSBtYXkgYWR2ZXJ0aXNlIG9ubHkgYSBtb2R1bGUNCiAgICBzZXQgJ2hhc2gnLg0KIA0K ICAtIE1COiBXZSBzaG91bGQgcHJvdmlkZSBhY2Nlc3MgdG8gdGhlIG1vZHVsZSBsaXN0IGluIHRo ZSBzYW1lIHdheQ0KICAgIGZvciBORVRDT05GIGFuZCBSRVNUQ09ORi4NCiANCiAgLSBEQjogV2Ug bWF5IGhhdmUgdG8gc3VwcG9ydCBkaWZmZXJlbnQgbW9kdWxlIHNldHMgb24NCiAgICBORVRDT05G L1JFU1RDT05GIG9yIGRpZmZlcmVudCBtb2R1bGUgc2V0cyBmb3IgZGlmZmVyZW50IHVzZXJzIG9y DQogICAgZGlmZmVyZW50IG1vZHVsZSBzZXRzIGZvciBkaWZmZXJlbnQgZGF0YXN0b3Jlcy4NCiAN CiAgLSBNQjogU2luY2UgaGVsbG8gYmFzaWNhbGx5IHdvcmtzLCBpcyB0aGlzIHJlYWxseSBhIHBy b2JsZW0gdG8gZml4LA0KICAgIGdpdmVuIHRoZSBvdmVyYWxsIG92ZXJoZWFkIG9mIHRoZSBzZWN1 cmUgdHJhbnNwb3J0cyBOQyBpcyBydW5uaW5nDQogICAgb3Zlcj8gUkMgZG9lcyBub3QgaGF2ZSB0 aGUgZXF1aXZhbGVudCBvZiBoZWxsby4NCiANCiAgLSBKUzogVGhlIGhlbGxvIG1lc3NhZ2Ugc2l6 ZSBpcyBtb3N0bHkgYW4gaXNzdWUgZm9yIHNob3J0IGxpdmVkDQogICAgc2Vzc2lvbnMuDQogIC0g Skg6IE9yIGZvciBzZXNzaW9ucyBydW5uaW5nIG92ZXIgbGlua3Mgd2l0aCBub3RpY2VhYmxlIHBh Y2tldCBsb3NzDQogICAgcmF0ZXMuDQogIC0gREI6IFRoaXMgbWF5IGJlIGFuIGlzc3VlIGZvciBl Tm9kZUJzLg0KIA0KICBQcm9wb3NhbDogV2UgZG8gbm90IHNlbmQgWUFORyAxLjEgbW9kdWxlIFVS SXMgYnV0IGluc3RlYWQgd2Ugc2VuZCBhDQogIGhhc2ggb3IgaWRlbnRpZmllci4gDQoNCg0KW2Zy YW5rXTogSSB0aGluayBpdCdzIGVub3VnaCB0aGF0IHNlcnZlciBvbmx5IHNlbmQgYSBoYXNoIHRv IGluZGljYXRlIGFsbCANCm1vZHVsZXMnIA0KY29uZm9ybWFuY2UgaW5mb3JtYXRpb24uIEl0J3Mg bm90IG5lY2Vzc2FyeSB0aGF0IGV2ZXJ5IG1vZHVsZSBzZW5kIGl0J3MgDQpvd24gaGFzaA0KaW4g aGVsbG8gbWVzc2FnZSwgYmVjYXVzZSBtb3VkbGVzJyBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbiBh cmUgbm90IHRvbyANCmxhcmdlLCBjbGllbnQNCmNhbiBnZXQgYWxsIG1vZHVsZXMnIGNvbmZvcm1h bmNlIGluZm9ybWF0aW9uIHdoZW4gaXQgZmluZCBzZXJ2ZXIncyANCmNvbmZvcm1hbmNlIGhhcyBj aGFuZ2VkLg0KDQpwbGVhc2Ugc2VlIG15IG5ldyBkcmFmdDoNCmh0dHA6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS8NCg0KIA0KDQogLSBK UzogV2hhdCBpcyB0aGUgc2NvcGUgb2YgdGhlIGhhc2ggb3IgaWRlbnRpZmllcj8gSXMgaXQgc2Nv cGVkIGJ5DQogICAgdGhlIHVzZXIgb3IganVzdCBieSB0aGUgTkVUQ09ORiBzZXJ2ZXI/IERvIHdl IGdvIHdpdGggYSBoZWxsbyBSUEMNCiAgICBvciBqdXN0IHB1bGwgdGhpcyBmcm9tIGEgZGF0YSBt b2RlbD8gRGF0YSBtb2RlbCBhbGxvd3MgY29udHJvbA0KICAgIGZyb20gTkFDTSwgd2hpY2ggbWF5 IGJlIGEgZmVhdHVyZS4gVXNlIHRoZSBSRVNUQ09ORiBtb2RlbCBhcyBhDQogICAgc3RhcnRpbmcg cG9pbnQ/IE9yIHJldmlzZSBSRkMgNjAyMj8NCg0KICAtIEJMOiBSRkM2MDIyIGhhcyBOQUNNIGFw cGxpZWQgdG8gaXQgYW5kIHRodXMgaXQgcHJvdmlkZXMNCiAgICBlZmZlY3RpdmVseSBpbmZvcm1h dGlvbiBzcGVjaWZpYyB0byBhIHVzZXIuDQogIC0gTEw6IEkgc3VnZ2VzdCB0byBmYWN0b3IgdGhl IHByb3RvY29sIGJpbmRpbmdzIG91dCBvZiB0aGUgWUFORyAxLjENCiAgICBzcGVjaWZpY2F0aW9u IGludG8gYSBkaWZmZXJlbnQgZG9jdW1lbnQuDQogIC0gSlM6IEl0IHdvdWxkIGJlIG5pY2UgdG8g aGF2ZSB0aGUgbWV0YSBtb2RlbCBSYW5keSBoYXMgYmVlbiB0YWxraW5nDQogICAgYWJvdXQgYnV0 IHJpZ2h0IG5vdyBpdCBzZWVtcyBhIG1ham9yIHN1cmdlcnkgdG8gYSAxLjEgdXBkYXRlLg0KICAt IE1COiBQZXJoYXBzIGl0IGlzIHN1ZmZpY2llbnQgaWYgYWxsIE5FVENPTkYgc3BlY2lmaWMgcGFy dHMgYXJlDQogICAgZmxhZ2dlZCBpbiBwcm9wZXIgc3Vic2VjdGlvbnMuDQoNCiAgUHJvcG9zYWw6 IFdlIGNyZWF0ZSBhIG5ldyBpZXRmLXlhbmctYWR2ZXJ0aXNlbWVudCBtb2R1bGUgdGhhdA0KICBk ZXRhaWxzIGEgZGF0YSBtb2RlbCBmb3IgdGhlIGFkdmVydGlzZW1lbnQgb2YgWUFORyBkYXRhIG1v ZGVscyAodGhhdA0KICB3b3JrcyBpbiB0aGUgc2FtZSB3YXkgZm9yIE5FVENPTkYgYW5kIFJFU1RD T05GKS4NCg0KW2ZyYW5rXTogSSBoYXZlIGNyZWF0ZWQgYSBtb2R1bGUgY2FsbGVkIGlldGYtbmV0 Y29uZi1jb25mb3JtYW5jZSB0byANCnN1cHBvcnQNCmNsaWVudCB0byBnZXQgc2VydmVyJ3MgZGV0 YWlsIGNvbmZvcm1hbmNlIGluZm9ybWF0aW9uLg0KDQpwbGVhc2Ugc2VlIG15IG5ldyBkcmFmdDoN Cmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJhbmstbmV0Y29uZi1jb25m b3JtYW5jZS8NCg0KDQoNCg0KIm5ldG1vZCIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnPiDQtNPa IDIwMTQtMDktMTkgMTg6MDg6Mjk6DQoNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IA0KPiC3orz+yMs6ICAibmV0bW9kIiA8bmV0 bW9kLWJvdW5jZXNAaWV0Zi5vcmc+DQo+IA0KPiAyMDE0LTA5LTE5IDE4OjA4DQo+IA0KPiDH67Tw uLQguPgNCj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVu aXZlcnNpdHkuZGU+DQo+IA0KPiDK1bz+yMsNCj4gDQo+IG5ldG1vZEBpZXRmLm9yZywgDQo+IA0K PiCzrcvNDQo+IA0KPiDW98ziDQo+IA0KPiBbbmV0bW9kXSBkcmFmdCBtaW51dGVzIHlhbmcgMS4x IGludGVyaW0gbWVldGluZyBuZXcgeW9yaw0KPiANCj4gSGksDQo+IA0KPiBoZXJlIGFyZSB0aGUg ZHJhZnQgbWludXRlcyAtIHBsZWFzZSBsZXQgbWUga25vdyB3aGF0IG5lZWRzIHRvIGJlDQo+IGZp eGVkLiANCj4gDQo+IA0KaHR0cDovL3N2bi50b29scy5pZXRmLm9yZy9zdm4vd2cvbmV0bW9kL3lh bmctMS4xL25ldG1vZC0yMDE0LTA5LTE4LW1pbnV0ZXMudHh0DQoNCj4gDQo+IEkgaGF2ZSB0byBz ZW5kIHRoZSBtaW51dGVzIHRvIHRoZSBzZWNyZXRhcmlhdCBmb3IgaW5jbHVzaW9uIGluIHRoZQ0K PiBwcm9jZWVkaW5ncyBieSB0aGUgZW5kIG9mIG5leHQgd2VlayAtIHNvIHBsZWFzZSBzZW5kIG1l IGFueQ0KPiBjb3JyZWN0aW9ucyB1bnRpbCBUaHVyc2RheSBuZXh0IHdlZWsuDQo+IA0KPiAvanMN Cj4gDQo+IC0tIA0KPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENh bXB1cyBSaW5nIDEsIDI4NzU5IEJyZW1lbiwgR2VybWFueQ0KPiBGYXg6ICAgKzQ5IDQyMSAyMDAg MzEwMyAgICAgICAgIDxodHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLz4NCj4gW7i9vP4g Im5ldG1vZC0yMDE0LTA5LTE4LW1pbnV0ZXMudHh0IiCxuyC367PlMTAxMzY0OTIvdXNlci96dGVf bHRkIMm+DQo+ILP9XV9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24g U2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCAo YW5kIGFueSBhdHRhY2htZW50IHRyYW5zbWl0dGVkIGhlcmV3aXRoKSBpcyBwcml2aWxlZ2VkIGFu ZCBjb25maWRlbnRpYWwgYW5kIGlzIGludGVuZGVkIGZvciB0aGUgZXhjbHVzaXZlIHVzZSBvZiB0 aGUgYWRkcmVzc2VlKHMpLiAgSWYgeW91IGFyZSBub3QgYW4gaW50ZW5kZWQgcmVjaXBpZW50LCBh bnkgZGlzY2xvc3VyZSwgcmVwcm9kdWN0aW9uLCBkaXN0cmlidXRpb24gb3Igb3RoZXIgZGlzc2Vt aW5hdGlvbiBvciB1c2Ugb2YgdGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpcyBzdHJpY3RseSBw cm9oaWJpdGVkLiAgSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtYWlsIGluIGVycm9yLCBwbGVh c2UgZGVsZXRlIGl0IGFuZCBub3RpZnkgdXMgaW1tZWRpYXRlbHkuDQo= --=_alternative 0006BA1348257D5B_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxicj4NCiogWTE2IG1vZHVsZSBhZHZlcnRp c2VtZW50IG9wdGltaXphdGlvbiAvIFk1NCByZW1vdmUgdGhlIGFkdmVydGlzZW1lbnQNCm9mIGNv bmZvcm1hbmNlIGluZm9ybWF0aW9uIGluIE5FVENPTkYgaGVsbG8gbWVzc2FnZTwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IC0gTUI6IFlBTkcg MS4wIG1vZHVsZXMgd2lsbCBjb250aW51ZQ0KdG8gYmUgYWR2ZXJ0aXNlZCBpbiBoZWxsbzwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBtZXNz YWdlcyBidXQgZm9yIFlBTkcNCjEuMSBtb2R1bGVzLCB3ZSBtYXkgYWR2ZXJ0aXNlIG9ubHkgYSBt b2R1bGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAm bmJzcDsgc2V0ICdoYXNoJy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAtIE1COiBXZSBzaG91bGQgcHJvdmlkZSBhY2Nlc3MN CnRvIHRoZSBtb2R1bGUgbGlzdCBpbiB0aGUgc2FtZSB3YXk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgZm9yIE5FVENPTkYgYW5kIFJFU1RD T05GLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7IC0gREI6IFdlIG1heSBoYXZlIHRvIHN1cHBvcnQNCmRpZmZlcmVudCBtb2R1 bGUgc2V0cyBvbjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7ICZuYnNwOyBORVRDT05GL1JFU1RDT05GIG9yIGRpZmZlcmVudA0KbW9kdWxlIHNldHMgZm9y IGRpZmZlcmVudCB1c2VycyBvcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+Jm5ic3A7ICZuYnNwOyBkaWZmZXJlbnQgbW9kdWxlIHNldHMNCmZvciBkaWZmZXJlbnQg ZGF0YXN0b3Jlcy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPiZuYnNwOyAtIE1COiBTaW5jZSBoZWxsbyBiYXNpY2FsbHkgd29ya3MsDQpp cyB0aGlzIHJlYWxseSBhIHByb2JsZW0gdG8gZml4LDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBnaXZlbiB0aGUgb3ZlcmFsbCBvdmVyaGVh ZA0Kb2YgdGhlIHNlY3VyZSB0cmFuc3BvcnRzIE5DIGlzIHJ1bm5pbmc8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgb3Zlcj8gUkMgZG9lcyBu b3QgaGF2ZQ0KdGhlIGVxdWl2YWxlbnQgb2YgaGVsbG8uPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgLSBKUzogVGhlIGhlbGxv IG1lc3NhZ2Ugc2l6ZQ0KaXMgbW9zdGx5IGFuIGlzc3VlIGZvciBzaG9ydCBsaXZlZDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBzZXNzaW9u cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAtIEpI OiBPciBmb3Igc2Vzc2lvbnMgcnVubmluZw0Kb3ZlciBsaW5rcyB3aXRoIG5vdGljZWFibGUgcGFj a2V0IGxvc3M8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNw OyAmbmJzcDsgcmF0ZXMuPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4mbmJzcDsgLSBEQjogVGhpcyBtYXkgYmUgYW4gaXNzdWUgZm9yDQplTm9kZUJzLjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7IDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7 IFByb3Bvc2FsOiBXZSBkbyBub3Qgc2VuZCBZQU5HDQoxLjEgbW9kdWxlIFVSSXMgYnV0IGluc3Rl YWQgd2Ugc2VuZCBhPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4m bmJzcDsgaGFzaCBvciBpZGVudGlmaWVyLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPltmcmFua106IEkgdGhpbmsgaXQncyBlbm91Z2ggdGhh dCBzZXJ2ZXINCm9ubHkgc2VuZCBhIGhhc2ggdG8gaW5kaWNhdGUgYWxsIG1vZHVsZXMnIDwvZm9u dD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Y29uZm9ybWFuY2UgaW5mb3Jt YXRpb24uIEl0J3Mgbm90IG5lY2Vzc2FyeQ0KdGhhdCBldmVyeSBtb2R1bGUgc2VuZCBpdCdzIG93 biBoYXNoPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5pbiBoZWxs byBtZXNzYWdlLCBiZWNhdXNlIG1vdWRsZXMnIGNvbmZvcm1hbmNlDQppbmZvcm1hdGlvbiBhcmUg bm90IHRvbyBsYXJnZSwgY2xpZW50PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5jYW4gZ2V0IGFsbCBtb2R1bGVzJyBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbg0Kd2hl biBpdCBmaW5kIHNlcnZlcidzIGNvbmZvcm1hbmNlIGhhcyBjaGFuZ2VkLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cGxlYXNlIHNlZSBteSBuZXcgZHJh ZnQ6PC9mb250Pg0KPGJyPjxhIGhyZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS8iPjxmb250IHNpemU9MiBmYWNlPSJzYW5z LXNlcmlmIj5odHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWZyYW5rLW5ldGNv bmYtY29uZm9ybWFuY2UvPC9mb250PjwvYT4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDstIEpTOiBXaGF0IGlzIHRoZSBzY29wZSBvZiB0aGUNCmhhc2ggb3Ig aWRlbnRpZmllcj8gSXMgaXQgc2NvcGVkIGJ5PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IHRoZSB1c2VyIG9yIGp1c3QgYnkgdGhlDQpORVRD T05GIHNlcnZlcj8gRG8gd2UgZ28gd2l0aCBhIGhlbGxvIFJQQzwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBvciBqdXN0IHB1bGwgdGhpcyBm cm9tDQphIGRhdGEgbW9kZWw/IERhdGEgbW9kZWwgYWxsb3dzIGNvbnRyb2w8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgZnJvbSBOQUNNLCB3 aGljaCBtYXkgYmUNCmEgZmVhdHVyZS4gVXNlIHRoZSBSRVNUQ09ORiBtb2RlbCBhcyBhPC9mb250 Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IHN0YXJ0 aW5nIHBvaW50PyBPciByZXZpc2UNClJGQyA2MDIyPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IC0gQkw6IFJGQzYwMjIgaGFzIE5BQ00gYXBw bGllZA0KdG8gaXQgYW5kIHRodXMgaXQgcHJvdmlkZXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDsgZWZmZWN0aXZlbHkgaW5mb3JtYXRpb24N CnNwZWNpZmljIHRvIGEgdXNlci48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPiZuYnNwOyAtIExMOiBJIHN1Z2dlc3QgdG8gZmFjdG9yIHRoZQ0KcHJvdG9jb2wgYmlu ZGluZ3Mgb3V0IG9mIHRoZSBZQU5HIDEuMTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i c2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwOyBzcGVjaWZpY2F0aW9uIGludG8gYSBkaWZmZXJlbnQN CmRvY3VtZW50LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5i c3A7IC0gSlM6IEl0IHdvdWxkIGJlIG5pY2UgdG8gaGF2ZQ0KdGhlIG1ldGEgbW9kZWwgUmFuZHkg aGFzIGJlZW4gdGFsa2luZzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+Jm5ic3A7ICZuYnNwOyBhYm91dCBidXQgcmlnaHQgbm93IGl0DQpzZWVtcyBhIG1ham9yIHN1 cmdlcnkgdG8gYSAxLjEgdXBkYXRlLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fu cy1zZXJpZiI+Jm5ic3A7IC0gTUI6IFBlcmhhcHMgaXQgaXMgc3VmZmljaWVudA0KaWYgYWxsIE5F VENPTkYgc3BlY2lmaWMgcGFydHMgYXJlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj4mbmJzcDsgJm5ic3A7IGZsYWdnZWQgaW4gcHJvcGVyIHN1YnNlY3Rpb25zLjwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7IFBy b3Bvc2FsOiBXZSBjcmVhdGUgYSBuZXcgaWV0Zi15YW5nLWFkdmVydGlzZW1lbnQNCm1vZHVsZSB0 aGF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJzcDsgZGV0 YWlscyBhIGRhdGEgbW9kZWwgZm9yIHRoZQ0KYWR2ZXJ0aXNlbWVudCBvZiBZQU5HIGRhdGEgbW9k ZWxzICh0aGF0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4mbmJz cDsgd29ya3MgaW4gdGhlIHNhbWUgd2F5IGZvciBORVRDT05GDQphbmQgUkVTVENPTkYpLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+W2ZyYW5rXTogSSBo YXZlIGNyZWF0ZWQgYSBtb2R1bGUgY2FsbGVkDQo8L2ZvbnQ+PHR0Pjxmb250IHNpemU9Mz5pZXRm LW5ldGNvbmYtY29uZm9ybWFuY2U8L2ZvbnQ+PC90dD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1z ZXJpZiI+DQp0byBzdXBwb3J0PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj5jbGllbnQgdG8gZ2V0IHNlcnZlcidzIGRldGFpbCBjb25mb3JtYW5jZQ0KaW5mb3JtYXRp b24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5wbGVh c2Ugc2VlIG15IG5ldyBkcmFmdDo8L2ZvbnQ+DQo8YnI+PGEgaHJlZj0iaHR0cDovL2RhdGF0cmFj a2VyLmlldGYub3JnL2RvYy9kcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLyI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtZnJhbmstbmV0Y29uZi1jb25mb3JtYW5jZS88L2ZvbnQ+PC9hPg0KPHRhYmxlPg0KPHRy Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m cXVvdDtuZXRtb2QmcXVvdDsgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0Ow0K0LTT2iAy MDE0LTA5LTE5IDE4OjA4OjI5Ojxicj4NCjxicj4NCiZndDsgSnVlcmdlbiBTY2hvZW53YWVsZGVy ICZsdDtqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUmZ3Q7DQo8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgt6K8/sjLOiAmbmJzcDsmcXVvdDtuZXRtb2Qm cXVvdDsgJmx0O25ldG1vZC1ib3VuY2VzQGlldGYub3JnJmd0Ozxicj4NCiZndDsgPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDIwMTQtMDktMTkgMTg6MDg8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDH67TwuLQguPg8YnI+DQom Z3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlJmd0OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7IG5ldG1vZEBpZXRmLm9yZywgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyA8YnI+DQomZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZn dDsgPGJyPg0KJmd0OyBbbmV0bW9kXSBkcmFmdCBtaW51dGVzIHlhbmcgMS4xIGludGVyaW0gbWVl dGluZyBuZXcgeW9yazwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBoZXJlIGFyZSB0aGUgZHJhZnQgbWludXRl cyAtIHBsZWFzZSBsZXQgbWUga25vdyB3aGF0IG5lZWRzIHRvIGJlPGJyPg0KJmd0OyBmaXhlZC4g PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDwvZm9udD48L3R0PjxhIGhyZWY9Imh0dHA6Ly9zdm4udG9v bHMuaWV0Zi5vcmcvc3ZuL3dnL25ldG1vZC95YW5nLTEuMS9uZXRtb2QtMjAxNC0wOS0xOC1taW51 dGVzLnR4dCI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vc3ZuLnRvb2xzLmlldGYub3JnL3N2bi93 Zy9uZXRtb2QveWFuZy0xLjEvbmV0bW9kLTIwMTQtMDktMTgtbWludXRlcy50eHQ8L2ZvbnQ+PC90 dD48L2E+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBoYXZlIHRvIHNl bmQgdGhlIG1pbnV0ZXMgdG8gdGhlIHNlY3JldGFyaWF0IGZvciBpbmNsdXNpb24gaW4gdGhlPGJy Pg0KJmd0OyBwcm9jZWVkaW5ncyBieSB0aGUgZW5kIG9mIG5leHQgd2VlayAtIHNvIHBsZWFzZSBz ZW5kIG1lIGFueTxicj4NCiZndDsgY29ycmVjdGlvbnMgdW50aWwgVGh1cnNkYXkgbmV4dCB3ZWVr Ljxicj4NCiZndDsgPGJyPg0KJmd0OyAvanM8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0gPGJyPg0K Jmd0OyBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyBKYWNvYnMgVW5pdmVyc2l0eQ0KQnJlbWVuIGdHbWJIPGJyPg0KJmd0OyBQaG9uZTogKzQ5 IDQyMSAyMDAgMzU4NyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgQ2FtcHVzIFJpbmcgMSwN CjI4NzU5IEJyZW1lbiwgR2VybWFueTxicj4NCiZndDsgRmF4OiAmbmJzcDsgKzQ5IDQyMSAyMDAg MzEwMyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJmx0OzwvZm9udD48L3R0PjxhIGhyZWY9 Imh0dHA6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvIj48dHQ+PGZvbnQgc2l6ZT0yPmh0dHA6 Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPC9mb250PjwvdHQ+PC9hPjx0dD48Zm9udCBzaXpl PTI+Jmd0Ozxicj4NCiZndDsgW7i9vP4gJnF1b3Q7bmV0bW9kLTIwMTQtMDktMTgtbWludXRlcy50 eHQmcXVvdDsgsbsgt+uz5TEwMTM2NDkyL3VzZXIvenRlX2x0ZA0Kyb48YnI+DQomZ3Q7ILP9XV9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBu ZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBuZXRtb2RAaWV0Zi5vcmc8YnI+DQomZ3Q7IDwv Zm9udD48L3R0PjxhIGhyZWY9aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRtb2Q+PHR0Pjxmb250IHNpemU9Mj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL25ldG1vZDwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9udD48 L3R0Pg0KDQo8YnI+PHByZT48Zm9udCBjb2xvcj0iYmx1ZSI+DQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNl Y3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFu ZCBhbnkgYXR0YWNobWVudCB0cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQg Y29uZmlkZW50aWFsIGFuZCBpcyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhl IGFkZHJlc3NlZShzKS4gIElmIHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55 IGRpc2Nsb3N1cmUsIHJlcHJvZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWlu YXRpb24gb3IgdXNlIG9mIHRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJv aGliaXRlZC4gIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNl IGRlbGV0ZSBpdCBhbmQgbm90aWZ5IHVzIGltbWVkaWF0ZWx5Lg0KDQo8L2ZvbnQ+PC9wcmU+PGJy Pg0K --=_alternative 0006BA1348257D5B_=-- From nobody Sun Sep 21 23:28:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C8161A1A32 for ; Sun, 21 Sep 2014 23:28:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.8 X-Spam-Level: X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8] 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 xRuCxah8t8Ox for ; Sun, 21 Sep 2014 23:28:28 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 809081A1A37 for ; Sun, 21 Sep 2014 23:28:27 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 0FA9454086F; Mon, 22 Sep 2014 08:28:25 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZGV5CuQuRqb; Mon, 22 Sep 2014 08:28:20 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 9B71A540488; Mon, 22 Sep 2014 08:28:19 +0200 (CEST) From: Ladislav Lhotka To: Martin Bjorklund , jason.sterne@alcatel-lucent.com In-Reply-To: <20140919.141212.1330647465189699823.mbj@tail-f.com> References: <20140919100829.GA22159@elstar.local> <20140919.141212.1330647465189699823.mbj@tail-f.com> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 22 Sep 2014 08:28:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KbmieyQCr-esU4muS8CU0RbiPJM Cc: netmod@ietf.org Subject: Re: [netmod] Y49 at interim NY meeting X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:28:31 -0000 Martin Bjorklund writes: > "Sterne, Jason (Jason)" wrote: >> Hi guys, >> >> Is there rough consensus on current "best practices" for nested >> sub-modules ? I know there's been a lot of debate over this one in >> the past months. >> >> Is it incorrect to do simple nesting like a C #include, e.g. >> module a includes submodule b (but not c) >> module b includes submodule c > > The problem is that RFC 6020 in unclear about this. Hence Y49 in > order to clarify. > > I think that everyone agree that including all submodules in the main > module is legal. What is unclear is if: > > module a include b (but not c) > submodule b include c > > is legal or not. > > So - if you instead do > > module a include b and c > > you're good. Yes. IMO YANG 1.1 spec should state that all submodules must be included from the main module, and then without further ado all submodules have access to all definitions from the main module and all other submodules. Anything else hardly makes sense because the main module and all submodules share the same namespace anyway. For compatibility, includes from submodules can remain legal but they would be a no-op. While this proposal is not strictly backward compatible, I think it could be considered a bugfix. Lada > > > > /martin > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Sun Sep 21 23:35:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2028F1A1A3B for ; Sun, 21 Sep 2014 23:35:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PRUG2OqnvFMf for ; Sun, 21 Sep 2014 23:35:22 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CBD831A1A32 for ; Sun, 21 Sep 2014 23:35:21 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 4FF0254086F; Mon, 22 Sep 2014 08:35:20 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qHYoeIbBhEED; Mon, 22 Sep 2014 08:35:17 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 29585540488; Mon, 22 Sep 2014 08:35:17 +0200 (CEST) From: Ladislav Lhotka To: Juergen Schoenwaelder , netmod@ietf.org In-Reply-To: <20140919100829.GA22159@elstar.local> References: <20140919100829.GA22159@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 22 Sep 2014 08:35:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/E2b5He00edpLmFiMCQ4dtdA50bY Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 06:35:23 -0000 Hi, I am not sure I agree with the following: Juergen Schoenwaelder writes: > Proposal: Keep features as the unit of conformance in YANG 1.1 but > consider certain improvements: > - indicate in the module advertisement data model the conformance > associated with a module (full = "all base data nodes, rpcs, > notifications", ) I think "full" should mean "everything except nodes depending on features that the server does not advertise". My understanding was that "base" means only nodes that don't depend on any feature, regardless of what the server advertises. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 01:34:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CC741A1A4A for ; Mon, 22 Sep 2014 01:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 nTuLWNtRa8Js for ; Mon, 22 Sep 2014 01:34:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 839CB1A004D for ; Mon, 22 Sep 2014 01:34:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 377D2747; Mon, 22 Sep 2014 10:34:24 +0200 (CEST) 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 Od6LZyrf3AH3; Mon, 22 Sep 2014 10:34:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 10:34:23 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D89420038; Mon, 22 Sep 2014 10:34:23 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id jmGo9Wx0jTdD; Mon, 22 Sep 2014 10:34:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5C2B420035; Mon, 22 Sep 2014 10:34:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 139B22E841F6; Mon, 22 Sep 2014 10:34:21 +0200 (CEST) Date: Mon, 22 Sep 2014 10:34:20 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140922083420.GD16886@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , Martin Bjorklund , "netmod@ietf.org" References: <20140919.145158.1514198271114340913.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jL9XRlJhf6or4MgqusmaHvoUbHM Cc: "netmod@ietf.org" Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 08:34:29 -0000 On Fri, Sep 19, 2014 at 07:56:20PM +0000, Sterne, Jason (Jason) wrote: > I'm good with your explanation that a system can just create list entries in the config datastore and a client should do a get-config to discover them. The client can then delete those entries - no problem so far. > > A deletion simply causes an absence of that list entry in the datastore. A would simply not have that item in the list - again no problem so far. > > But now I want that deletion to be persistent (i.e. that entry should not exist after the next bootup). If we take an example of a system that has a running and a startup datastore, and we perform a copy-config from running->startup, then the startup ds doesn't contain that list entry. At the next reboot the system will happily create that entry again. > > Maybe this is just an implementation specific issue that is outside the scope of netconf & yang but if anyone has a solution that fits in with netconf/yang that would be useful. > Are you saying that the system ignores the fact that a list entry got explicitly deleted? In that case, I think this likely more a shortcoming of a particular implementation. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Mon Sep 22 03:53:14 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BBED1A1A4C for ; Mon, 22 Sep 2014 03:53:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 PXbJQFh0UKXH for ; Mon, 22 Sep 2014 03:53:11 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 9ABCB1A1A45 for ; Mon, 22 Sep 2014 03:53:11 -0700 (PDT) Received: from mars.tail-f.com (mars.tail-f.com [192.168.1.70]) by mail.tail-f.com (Postfix) with ESMTPSA id 5022F1280457; Mon, 22 Sep 2014 12:53:10 +0200 (CEST) Message-ID: <541FFF96.8050602@tail-f.com> Date: Mon, 22 Sep 2014 12:53:10 +0200 From: Per Hedeland User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Juergen Schoenwaelder , "netmod@ietf.org" References: <20140919.145158.1514198271114340913.mbj@tail-f.com> <20140922083420.GD16886@elstar.local> In-Reply-To: <20140922083420.GD16886@elstar.local> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mWteteqnLPgxmsbEMy89KbcvB2Y Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 10:53:13 -0000 On 2014-09-22 10:34, Juergen Schoenwaelder wrote: > On Fri, Sep 19, 2014 at 07:56:20PM +0000, Sterne, Jason (Jason) wrote: >> I'm good with your explanation that a system can just create list entries in the config datastore and a client should do a get-config to discover them. The client can then delete those entries - no problem so far. >> >> A deletion simply causes an absence of that list entry in the datastore. A would simply not have that item in the list - again no problem so far. >> >> But now I want that deletion to be persistent (i.e. that entry should not exist after the next bootup). If we take an example of a system that has a running and a startup datastore, and we perform a copy-config from running->startup, then the startup ds doesn't contain that list entry. At the next reboot the system will happily create that entry again. >> >> Maybe this is just an implementation specific issue that is outside the scope of netconf & yang but if anyone has a solution that fits in with netconf/yang that would be useful. >> > > Are you saying that the system ignores the fact that a list entry got > explicitly deleted? In that case, I think this likely more a > shortcoming of a particular implementation. > > /js > I believe Jason is just not looking far enough "outside" of netconf/yang... On a system with startup and running, such "factory default" config must be part of the *initial* *startup* contents - i.e. it cannot be created as part of the startup -> running copy that occurs at *every* reboot. --Per Hedeland From nobody Mon Sep 22 03:54:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 165461A1A3C for ; Mon, 22 Sep 2014 03:54:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 NCyu2F_r_d37 for ; Mon, 22 Sep 2014 03:54:52 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA12D1A1A97 for ; Mon, 22 Sep 2014 03:54:51 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BBD31F69; Mon, 22 Sep 2014 12:54:50 +0200 (CEST) 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 OBUzkOnXqNUI; Mon, 22 Sep 2014 12:54:49 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 12:54:49 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF85A20036; Mon, 22 Sep 2014 12:54:49 +0200 (CEST) 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 tDRpP43Z989Z; Mon, 22 Sep 2014 12:54:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CA87920035; Mon, 22 Sep 2014 12:54:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id BA7EC2E848E4; Mon, 22 Sep 2014 12:54:48 +0200 (CEST) Date: Mon, 22 Sep 2014 12:54:47 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922105447.GB17207@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140919100829.GA22159@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/RlE-6wHV57QxggNfnMk_QZQ3NtA Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 10:54:54 -0000 On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > Hi, > > I am not sure I agree with the following: > > Juergen Schoenwaelder writes: > > > Proposal: Keep features as the unit of conformance in YANG 1.1 but > > consider certain improvements: > > - indicate in the module advertisement data model the conformance > > associated with a module (full = "all base data nodes, rpcs, > > notifications", ) > > I think "full" should mean "everything except nodes depending on > features that the server does not advertise". > > My understanding was that "base" means only nodes that don't depend on > any feature, regardless of what the server advertises. I understood full as in draft-bierman-netmod-yang-conformance-03.txt: o full: Full implementation of the module base is required. This is the default value if the require-conformance statement is not present. I assume 'full' is kind of a misnomer but I think we did refer to Andy's I-D during the discussions. So from this perspective, do you agree with the minutes? /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 Sep 22 04:21:27 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E1071A0084 for ; Mon, 22 Sep 2014 04:21:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 ZG3VjDcui_YV for ; Mon, 22 Sep 2014 04:21:24 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ECFEB1A007E for ; Mon, 22 Sep 2014 04:21:23 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 63B231409C6; Mon, 22 Sep 2014 13:21:22 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411384882; bh=Mx41hCR7GV3gc3WZsQ+NzFpt1RctgY4kNJwWFzyE3y4=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Cf3yiqJdGGxcxcqkruJdXmG0hiyNf1q6tMsv/FASL8Bb6kGaQzkFkdlqtXRt3njbx N0msNqudvsxNXFRotsae+VpBd9ghJlIRBoWrsQvtEcQowbRocMD0Xxsd0/FPFF5Wpb tWoXXrHvx8ZEiToxnWxtjyZoDtMhgLQHfVADtLBs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140922105447.GB17207@elstar.local> Date: Mon, 22 Sep 2014 13:21:21 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5btbrWIG15Off8OsmORzE_newN8 Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 11:21:25 -0000 On 22 Sep 2014, at 12:54, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: >> Hi, >>=20 >> I am not sure I agree with the following: >>=20 >> Juergen Schoenwaelder writes: >>=20 >>> Proposal: Keep features as the unit of conformance in YANG 1.1 but >>> consider certain improvements: >>> - indicate in the module advertisement data model the = conformance >>> associated with a module (full =3D "all base data nodes, rpcs, >>> notifications", ) >>=20 >> I think "full" should mean "everything except nodes depending on >> features that the server does not advertise". >>=20 >> My understanding was that "base" means only nodes that don't depend = on >> any feature, regardless of what the server advertises. >=20 > I understood full as in draft-bierman-netmod-yang-conformance-03.txt: >=20 > o full: Full implementation of the module base is required. This = is > the default value if the require-conformance statement is not > present. >=20 > I assume 'full' is kind of a misnomer but I think we did refer to > Andy's I-D during the discussions. So from this perspective, do you > agree with the minutes? IMO =93full=94 is not only a misnomer but also a dubious alternative to = =93import=94. A server advertising full conformance + feature X should = implement all data nodes that depend only on feature X. I don=92t think the proposal should be as it is in the minutes. I = actually noticed this already in Etherpad but since the discussion had = already moved elsewhere, I didn=92t want to reopen it, so I am doing it = now. Lada >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 04:37:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D7B1A0099 for ; Mon, 22 Sep 2014 04:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 9QdZ7JgdOYcw for ; Mon, 22 Sep 2014 04:37:45 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 887031A007E for ; Mon, 22 Sep 2014 04:37:45 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 575A676A; Mon, 22 Sep 2014 13:37:44 +0200 (CEST) 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 Tt9i_mcWdOcP; Mon, 22 Sep 2014 13:37:43 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 13:37:43 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F31B20036; Mon, 22 Sep 2014 13:37:43 +0200 (CEST) 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 2IXSqVrKBJam; Mon, 22 Sep 2014 13:37:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 23E8920035; Mon, 22 Sep 2014 13:37:42 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 135662E84B4C; Mon, 22 Sep 2014 13:37:42 +0200 (CEST) Date: Mon, 22 Sep 2014 13:37:42 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922113742.GB17472@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SuNNqDlD2uwuiRKOBT3_9VLM0Yw Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 11:37:47 -0000 On Mon, Sep 22, 2014 at 01:21:21PM +0200, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 12:54, Juergen Schoenwaelder wrote: > > > On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > >> Hi, > >> > >> I am not sure I agree with the following: > >> > >> Juergen Schoenwaelder writes: > >> > >>> Proposal: Keep features as the unit of conformance in YANG 1.1 but > >>> consider certain improvements: > >>> - indicate in the module advertisement data model the conformance > >>> associated with a module (full = "all base data nodes, rpcs, > >>> notifications", ) > >> > >> I think "full" should mean "everything except nodes depending on > >> features that the server does not advertise". > >> > >> My understanding was that "base" means only nodes that don't depend on > >> any feature, regardless of what the server advertises. > > > > I understood full as in draft-bierman-netmod-yang-conformance-03.txt: > > > > o full: Full implementation of the module base is required. This is > > the default value if the require-conformance statement is not > > present. > > > > I assume 'full' is kind of a misnomer but I think we did refer to > > Andy's I-D during the discussions. So from this perspective, do you > > agree with the minutes? > > IMO “full†is not only a misnomer but also a dubious alternative to “importâ€. A server advertising full conformance + feature X should implement all data nodes that depend only on feature X. > > I don’t think the proposal should be as it is in the minutes. I actually noticed this already in Etherpad but since the discussion had already moved elsewhere, I didn’t want to reopen it, so I am doing it now. > Lada, if you want to fix the minutes, send a clear patch here. If you want to continue a discussion, please do it in a thread that has the issue in the subject line. I am not clear what your goal here is. /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 Sep 22 04:52:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3044D1A1AA7 for ; Mon, 22 Sep 2014 04:52:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 VC_VDHkisq1Q for ; Mon, 22 Sep 2014 04:52:36 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 22AEA1A038F for ; Mon, 22 Sep 2014 04:52:35 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 680941409C6; Mon, 22 Sep 2014 13:52:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411386753; bh=FK+2RHXygSpTWVhQh096Br/EVNk49a8kVRaDPIIj1gc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=aKfw7feS5c7q25j8oHQFSSbaszDWdy95/82iOPHpADAq503iZPQMiALouVgQklw/p xMfggNh8YQAE2/aGinKCpzrFp0mEAYSumT1b7Dia2bOBSyDiMBg7dr3/8oLqsrI0gw 4s0cIm8Sm/yt4zd4dojZ8VTHAdSxe03piBKmodx8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140922113742.GB17472@elstar.local> Date: Mon, 22 Sep 2014 13:52:32 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <3196105C-B397-4DBF-A97B-B1874C444589@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> <20140922113742.GB17472@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/a6guz7XQ7iTmt6w24KkpyiEDaGk Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 11:52:38 -0000 On 22 Sep 2014, at 13:37, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 01:21:21PM +0200, Ladislav Lhotka wrote: >>=20 >> On 22 Sep 2014, at 12:54, Juergen Schoenwaelder = wrote: >>=20 >>> On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: >>>> Hi, >>>>=20 >>>> I am not sure I agree with the following: >>>>=20 >>>> Juergen Schoenwaelder = writes: >>>>=20 >>>>> Proposal: Keep features as the unit of conformance in YANG 1.1 = but >>>>> consider certain improvements: >>>>> - indicate in the module advertisement data model the = conformance >>>>> associated with a module (full =3D "all base data nodes, = rpcs, >>>>> notifications", ) >>>>=20 >>>> I think "full" should mean "everything except nodes depending on >>>> features that the server does not advertise". >>>>=20 >>>> My understanding was that "base" means only nodes that don't depend = on >>>> any feature, regardless of what the server advertises. >>>=20 >>> I understood full as in = draft-bierman-netmod-yang-conformance-03.txt: >>>=20 >>> o full: Full implementation of the module base is required. This = is >>> the default value if the require-conformance statement is not >>> present. >>>=20 >>> I assume 'full' is kind of a misnomer but I think we did refer to >>> Andy's I-D during the discussions. So from this perspective, do you >>> agree with the minutes? >>=20 >> IMO =93full=94 is not only a misnomer but also a dubious alternative = to =93import=94. A server advertising full conformance + feature X = should implement all data nodes that depend only on feature X. >>=20 >> I don=92t think the proposal should be as it is in the minutes. I = actually noticed this already in Etherpad but since the discussion had = already moved elsewhere, I didn=92t want to reopen it, so I am doing it = now. >>=20 >=20 > Lada, >=20 > if you want to fix the minutes, send a clear patch here. If you want > to continue a discussion, please do it in a thread that has the issue > in the subject line. I am not clear what your goal here is. Why, my goal of course is to patch the minutes. BTW, I think the part = about =93import=94 conformance level fell through the cracks somehow - = it should follow after the dangling comma in the parentheses. I propose = this change: OLD - indicate in the module advertisement data model the conformance associated with a module (full =3D "all base data nodes, rpcs, notifications", ) NEW - indicate in the module advertisement data model the conformance associated with a module (full =3D "all data nodes, rpcs, notifications that are ether unconditional or depend on = advertised features", import =3D =93only extensions, typedefs, groupings, = identities and features that are defined at the top level of the module") Lada >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 05:16:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E83241A1AB3 for ; Mon, 22 Sep 2014 05:16:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 tZV_cbzIThWA for ; Mon, 22 Sep 2014 05:16:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C6891A1A97 for ; Mon, 22 Sep 2014 05:16:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B0D778F3; Mon, 22 Sep 2014 14:16:52 +0200 (CEST) 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 29iz2E5C4qIo; Mon, 22 Sep 2014 14:16:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 14:16:51 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7CBF620037; Mon, 22 Sep 2014 14:16:48 +0200 (CEST) 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 rAyifWKoOXML; Mon, 22 Sep 2014 14:16:48 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9D8D920036; Mon, 22 Sep 2014 14:16:47 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6E45F2E84CA1; Mon, 22 Sep 2014 14:16:46 +0200 (CEST) Date: Mon, 22 Sep 2014 14:16:46 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922121646.GB17653@elstar.local> Mail-Followup-To: Ladislav Lhotka , netmod@ietf.org References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> <20140922113742.GB17472@elstar.local> <3196105C-B397-4DBF-A97B-B1874C444589@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3196105C-B397-4DBF-A97B-B1874C444589@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DCba0vlu9BinReH-ZdIKKpXDyH4 Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:16:56 -0000 On Mon, Sep 22, 2014 at 01:52:32PM +0200, Ladislav Lhotka wrote: > > Why, my goal of course is to patch the minutes. BTW, I think the part about “import†conformance level fell through the cracks somehow - it should follow after the dangling comma in the parentheses. I propose this change: > > OLD > > - indicate in the module advertisement data model the conformance > associated with a module (full = "all base data nodes, rpcs, > notifications", ) > > > NEW > > - indicate in the module advertisement data model the conformance > associated with a module (full = "all data nodes, rpcs, > notifications that are ether unconditional or depend on advertised > features", import = “only extensions, typedefs, groupings, identities > and features that are defined at the top level of the module") > Thanks for the concrete proposal. But I am not sure - at least I have been using the definition of 'full' in Andy's draft during the meeting (I recall that I looked the I-D up because I was unsure about the semantics). So I guess it would help to hear from the other participants what they recall we have been discussing when we mentioned 'full'. /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 Sep 22 05:23:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1E251A1AB3 for ; Mon, 22 Sep 2014 05:23:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 pT4V1t_geDEh for ; Mon, 22 Sep 2014 05:23:44 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4747E1A1AAC for ; Mon, 22 Sep 2014 05:23:44 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id EE12C1409C6; Mon, 22 Sep 2014 14:23:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411388622; bh=q/ebxwMkYTOYs0jcF9n4r+idVP2rmmEVnqDm4zcIfaI=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=T20Dgo7hp/sRQOJbwp5v8AtWNg7uhK3uJ3GaO98106oepsFKse3Wx+ejMkTspk9PP arcgywkyr3L3g2oT1Ip1eUfpPSPUHSFx//VYGSkjqVMjBX0h6QC9i0uZHKr6Vtilwr 0wxVgm5Q9d21eMmiQAGHp8i3EcF53+/MNMYEWhqI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140922121646.GB17653@elstar.local> Date: Mon, 22 Sep 2014 14:23:41 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <204E2D3C-D2F8-4A4A-9D66-4DF15227BE82@nic.cz> <20140922113742.GB17472@elstar.local> <3196105C-B397-4DBF-A97B-B1874C444589@nic.cz> <20140922121646.GB17653@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4bUXI1FIYyMJoCu2ZmrBs2nmbTY Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:23:46 -0000 On 22 Sep 2014, at 14:16, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 01:52:32PM +0200, Ladislav Lhotka wrote: >>=20 >> Why, my goal of course is to patch the minutes. BTW, I think the part = about =93import=94 conformance level fell through the cracks somehow - = it should follow after the dangling comma in the parentheses. I propose = this change: >>=20 >> OLD >>=20 >> - indicate in the module advertisement data model the conformance >> associated with a module (full =3D "all base data nodes, rpcs, >> notifications", ) >>=20 >>=20 >> NEW >>=20 >> - indicate in the module advertisement data model the conformance >> associated with a module (full =3D "all data nodes, rpcs, >> notifications that are ether unconditional or depend on = advertised >> features", import =3D =93only extensions, typedefs, groupings, = identities >> and features that are defined at the top level of the module") >>=20 >=20 > Thanks for the concrete proposal.=20 >=20 > But I am not sure - at least I have been using the definition of > 'full' in Andy's draft during the meeting (I recall that I looked the > I-D up because I was unsure about the semantics). I formulated what =93full=94 is supposed to mean in the discussion, = along the above lines, and nobody protested. I am not going to search = for it the webex recording though. :-)=20 >=20 > So I guess it would help to hear from the other participants what they > recall we have been discussing when we mentioned 'full=92. Yes, that would be useful. Thanks, Lada >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 05:27:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F7AC1A1ABC for ; Mon, 22 Sep 2014 05:27:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 k6jVXAd5BFlR for ; Mon, 22 Sep 2014 05:27:19 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id B83361A1AAC for ; Mon, 22 Sep 2014 05:27:19 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 780581280457; Mon, 22 Sep 2014 14:27:18 +0200 (CEST) Date: Mon, 22 Sep 2014 14:27:18 +0200 (CEST) Message-Id: <20140922.142718.1612235506630232831.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140922121646.GB17653@elstar.local> References: <20140922113742.GB17472@elstar.local> <3196105C-B397-4DBF-A97B-B1874C444589@nic.cz> <20140922121646.GB17653@elstar.local> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wmUWxsHE7sH-XHXxDSNsMfMh-rM Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:27:21 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBNb24sIFNlcCAyMiwgMjAxNCBhdCAwMTo1MjozMlBNICswMjAwLCBM YWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+ID4gDQo+ID4gV2h5LCBteSBnb2FsIG9mIGNvdXJzZSBp cyB0byBwYXRjaCB0aGUgbWludXRlcy4gQlRXLCBJIHRoaW5rIHRoZSBwYXJ0IGFib3V0IOKAnGlt cG9ydOKAnSBjb25mb3JtYW5jZSBsZXZlbCBmZWxsIHRocm91Z2ggdGhlIGNyYWNrcyBzb21laG93 IC0gaXQgc2hvdWxkIGZvbGxvdyBhZnRlciB0aGUgZGFuZ2xpbmcgY29tbWEgaW4gdGhlIHBhcmVu dGhlc2VzLiBJIHByb3Bvc2UgdGhpcyBjaGFuZ2U6DQo+ID4gDQo+ID4gT0xEDQo+ID4gDQo+ID4g ICAgICAtIGluZGljYXRlIGluIHRoZSBtb2R1bGUgYWR2ZXJ0aXNlbWVudCBkYXRhIG1vZGVsIHRo ZSBjb25mb3JtYW5jZQ0KPiA+ICAgICAgICBhc3NvY2lhdGVkIHdpdGggYSBtb2R1bGUgKGZ1bGwg PSAiYWxsIGJhc2UgZGF0YSBub2RlcywgcnBjcywNCj4gPiAgICAgICAgbm90aWZpY2F0aW9ucyIs ICkNCj4gPiANCj4gPiANCj4gPiBORVcNCj4gPiANCj4gPiAgICAgIC0gaW5kaWNhdGUgaW4gdGhl IG1vZHVsZSBhZHZlcnRpc2VtZW50IGRhdGEgbW9kZWwgdGhlIGNvbmZvcm1hbmNlDQo+ID4gICAg ICAgIGFzc29jaWF0ZWQgd2l0aCBhIG1vZHVsZSAoZnVsbCA9ICJhbGwgZGF0YSBub2RlcywgcnBj cywNCj4gPiAgICAgICAgbm90aWZpY2F0aW9ucyB0aGF0IGFyZSBldGhlciB1bmNvbmRpdGlvbmFs IG9yIGRlcGVuZCBvbiBhZHZlcnRpc2VkDQo+ID4gICAgICAgIGZlYXR1cmVzIiwgaW1wb3J0ID0g 4oCcb25seSBleHRlbnNpb25zLCB0eXBlZGVmcywgZ3JvdXBpbmdzLCBpZGVudGl0aWVzDQo+ID4g ICAgICAgIGFuZCBmZWF0dXJlcyB0aGF0IGFyZSBkZWZpbmVkIGF0IHRoZSB0b3AgbGV2ZWwgb2Yg dGhlIG1vZHVsZSIpDQo+ID4gDQo+IA0KPiBUaGFua3MgZm9yIHRoZSBjb25jcmV0ZSBwcm9wb3Nh bC4gDQo+IA0KPiBCdXQgSSBhbSBub3Qgc3VyZSAtIGF0IGxlYXN0IEkgaGF2ZSBiZWVuIHVzaW5n IHRoZSBkZWZpbml0aW9uIG9mDQo+ICdmdWxsJyBpbiBBbmR5J3MgZHJhZnQgZHVyaW5nIHRoZSBt ZWV0aW5nIChJIHJlY2FsbCB0aGF0IEkgbG9va2VkIHRoZQ0KPiBJLUQgdXAgYmVjYXVzZSBJIHdh cyB1bnN1cmUgYWJvdXQgdGhlIHNlbWFudGljcykuDQo+IA0KPiBTbyBJIGd1ZXNzIGl0IHdvdWxk IGhlbHAgdG8gaGVhciBmcm9tIHRoZSBvdGhlciBwYXJ0aWNpcGFudHMgd2hhdCB0aGV5DQo+IHJl Y2FsbCB3ZSBoYXZlIGJlZW4gZGlzY3Vzc2luZyB3aGVuIHdlIG1lbnRpb25lZCAnZnVsbCcuDQoN CkkgdGhpbmsgYm90aCBleHBsYW5haXRpb25zIGFyZSBjb3JyZWN0LCBidXQgTGFkYSdzIHByb3Bv c2FsIGlzIG1vcmUNCmRldGFpbGVkLiAgSW4gdGhlIGVuZCBpdCBkb2Vzbid0IG1hdHRlciBtdWNo IGIvYyB3ZSBuZWVkIHRvIGFncmVlIG9uDQpjb25jcmV0ZSB0ZXh0IGluIHRoZSBkb2N1bWVudCBh bnl3YXkuDQoNCg0KL21hcnRpbg0K From nobody Mon Sep 22 05:30:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 845B81A1ABC for ; Mon, 22 Sep 2014 05:30:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 JVsrpIR8qCRi for ; Mon, 22 Sep 2014 05:30:10 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C19D1A1AAC for ; Mon, 22 Sep 2014 05:30:10 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 589606F7; Mon, 22 Sep 2014 14:30:09 +0200 (CEST) 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 Lo9sdRQ6M5f7; Mon, 22 Sep 2014 14:30:08 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 14:30:08 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3301020037; Mon, 22 Sep 2014 14:30:08 +0200 (CEST) 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 f29Co_AZv03Z; Mon, 22 Sep 2014 14:30:07 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6D7C920035; Mon, 22 Sep 2014 14:30:06 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 34CEB2E84E4D; Mon, 22 Sep 2014 14:30:06 +0200 (CEST) Date: Mon, 22 Sep 2014 14:30:06 +0200 From: Juergen Schoenwaelder To: feng.chong33@zte.com.cn Message-ID: <20140922123006.GE17653@elstar.local> Mail-Followup-To: feng.chong33@zte.com.cn, netmod@ietf.org References: <20140919100829.GA22159@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6ai4md-oyBVzVHH01WoiVPZS_oc Cc: netmod@ietf.org Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 12:30:12 -0000 On Mon, Sep 22, 2014 at 09:13:28AM +0800, feng.chong33@zte.com.cn wrote: > * Y16 module advertisement optimization / Y54 remove the advertisement of > conformance information in NETCONF hello message > > - MB: YANG 1.0 modules will continue to be advertised in hello > messages but for YANG 1.1 modules, we may advertise only a module > set 'hash'. > > - MB: We should provide access to the module list in the same way > for NETCONF and RESTCONF. > > - DB: We may have to support different module sets on > NETCONF/RESTCONF or different module sets for different users or > different module sets for different datastores. > > - MB: Since hello basically works, is this really a problem to fix, > given the overall overhead of the secure transports NC is running > over? RC does not have the equivalent of hello. > > - JS: The hello message size is mostly an issue for short lived > sessions. > - JH: Or for sessions running over links with noticeable packet loss > rates. > - DB: This may be an issue for eNodeBs. > > Proposal: We do not send YANG 1.1 module URIs but instead we send a > hash or identifier. > > > [frank]: I think it's enough that server only send a hash to indicate all > modules' > conformance information. This is exactly what was discussed. But then we also discussed that it is not really a hash but more of an identifier for the given module set. We also discussed what the scope of such an identifier would be. > Proposal: We create a new ietf-yang-advertisement module that > details a data model for the advertisement of YANG data models (that > works in the same way for NETCONF and RESTCONF). > > [frank]: I have created a module called ietf-netconf-conformance to > support > client to get server's detail conformance information. > > please see my new draft: > http://datatracker.ietf.org/doc/draft-frank-netconf-conformance/ > We are aware of the I-D and there were some concerns that the I-D is too complex and has elements we do not understand (like what are 'functions') nor was it clear that including deviation into the get-schema-conformance RPC was a good idea. /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 Sep 22 06:26:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B04B21A1ACF for ; Mon, 22 Sep 2014 06:26:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 boIP-kI103Pn for ; Mon, 22 Sep 2014 06:26:02 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 468931A1AC9 for ; Mon, 22 Sep 2014 06:26:02 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id D825E66EAAD77; Mon, 22 Sep 2014 13:25:58 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8MDPv5n013801 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 09:25:58 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 09:25:57 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] system created list entries Thread-Index: Ac/UOXIBDteTWVTgRUK+a6lLgcO5sQAIt8cAAAZqtgAAeuMGAAAA+YfQ Date: Mon, 22 Sep 2014 13:25:57 +0000 Message-ID: References: <20140919.145158.1514198271114340913.mbj@tail-f.com> <20140922083420.GD16886@elstar.local> In-Reply-To: <20140922083420.GD16886@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/jfuU3dh6P807bwWFepv3GDtfsBA Cc: "netmod@ietf.org" Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 13:26:08 -0000 Hi guys, This isn't as simple as a system just ignoring a deletion. It is about how= that deletion would look in a . An absence of the entry doesn= 't tell the client that the system created entry is being explicitly suppre= ssed/deleted (and an absence can't represent the explicit delete/suppressio= n that in theory should be shown in a startup ds). Let me walk through an example in a bit more detail: ## (A) system model list foo { key "entry" leaf entry { type string; } } ## (B) initial result from the ds on a newly booted = system contains an entry that is populated by the system at startup time system-created-1 ## (C) user does an to add a new foo entry ' client-created-1= '. Results of a now look like this: system-created-1 client-created-1 ## (D) user deletes the entry 'system-created-1'. Results of a look like this: client-created-1 ## (E) now a from to . Does a of the return the same as what we see in (D) above ? If so -= what tells the system during the next startup to actually suppress 'system= -created-1' ? A simple absence of system-created-1 from the ds can't really cau= se the deletion of that entry IMO. A completely empty ds should= have the system come up with the 'system-created-1' entry configured. Maybe the only solution is an implementation specific item in the startup d= s that says to explicitly delete 'system-created-1' but I was looking for a= ny way to model/show this in NETCONF/YANG. Regards, Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 4:34 AM To: Sterne, Jason (Jason) Cc: Martin Bjorklund; netmod@ietf.org Subject: Re: [netmod] system created list entries On Fri, Sep 19, 2014 at 07:56:20PM +0000, Sterne, Jason (Jason) wrote: > I'm good with your explanation that a system can just create list entries= in the config datastore and a client should do a get-config to discover th= em. The client can then delete those entries - no problem so far. >=20 > A deletion simply causes an absence of that list entry in the datastore. = A would simply not have that item in the list - again no pro= blem so far. >=20 > But now I want that deletion to be persistent (i.e. that entry should not= exist after the next bootup). If we take an example of a system that has = a running and a startup datastore, and we perform a copy-config from runnin= g->startup, then the startup ds doesn't contain that list entry. At the n= ext reboot the system will happily create that entry again. >=20 > Maybe this is just an implementation specific issue that is outside the s= cope of netconf & yang but if anyone has a solution that fits in with netco= nf/yang that would be useful. >=20 Are you saying that the system ignores the fact that a list entry got expli= citly deleted? In that case, I think this likely more a shortcoming of a pa= rticular implementation. /js --=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 Mon Sep 22 07:06:38 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C88261A1ACE for ; Mon, 22 Sep 2014 07:06:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.892 X-Spam-Level: X-Spam-Status: No, score=-1.892 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, THIS_AD=0.086] 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 K6hcdDolcUAA for ; Mon, 22 Sep 2014 07:06:26 -0700 (PDT) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675DA1A1BFD for ; Mon, 22 Sep 2014 06:50:12 -0700 (PDT) Received: by mail-qc0-f182.google.com with SMTP id m20so41705qcx.41 for ; Mon, 22 Sep 2014 06:50:11 -0700 (PDT) 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=fkX7FZ30kGW/pjJizhDgHDB1i2IIXcsBisQmdxlq5zs=; b=HrvISWZ7IqfdUdvSwKgHII9kAl4nB2xDA1ejsEiI/AAeXdcmJG1GDsLISYrxC9CcdH o6zvdr4p3Yvi3yB3iQci39C3hR3RBbXD1cbAbuyEChY6kAsumTiIJGka/dFT/vGSKmoV cv1DpW0/1vTSnGDPcalr7/RsT7QcowhxbNs9oJK9Uf4ehMTrsC8yGgwBP+CP/aG20ain B0godfNSiboLcZtVKGwj6V1ddUdah6ayOXsjI9SejE6zVVJY5HJOlhxLfivDUe0WDg0l fCo9ZP5DqJXoaXuAtTuaBbnBc3dHVWh7Gp7u/zFDLi1HulEO5e/o7h0aLfU3EJjGhi4M Vb7w== X-Gm-Message-State: ALoCoQmX+7XG1eRckO7f8q2LDYZ9oNMxDsrIhGRrbCowz02Qh3I/ctHvdGaiHsHBxt5Hc5dLHJ52 MIME-Version: 1.0 X-Received: by 10.140.98.11 with SMTP id n11mr9237969qge.83.1411393811419; Mon, 22 Sep 2014 06:50:11 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 06:50:11 -0700 (PDT) In-Reply-To: <20140922105447.GB17207@elstar.local> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> Date: Mon, 22 Sep 2014 06:50:11 -0700 Message-ID: From: Andy Bierman To: Juergen Schoenwaelder , Ladislav Lhotka , "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a113ac3a0c4db9f0503a7ba14 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/On1W5jtgrAin0HaFkGt7shdxkdo Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:06:30 -0000 --001a113ac3a0c4db9f0503a7ba14 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > > Hi, > > > > I am not sure I agree with the following: > > > > Juergen Schoenwaelder writes: > > > > > Proposal: Keep features as the unit of conformance in YANG 1.1 but > > > consider certain improvements: > > > - indicate in the module advertisement data model the conformance > > > associated with a module (full = "all base data nodes, rpcs, > > > notifications", ) > > > > I think "full" should mean "everything except nodes depending on > > features that the server does not advertise". > > > > My understanding was that "base" means only nodes that don't depend on > > any feature, regardless of what the server advertises. > > I understood full as in draft-bierman-netmod-yang-conformance-03.txt: > > o full: Full implementation of the module base is required. This is > the default value if the require-conformance statement is not > present. > > I assume 'full' is kind of a misnomer but I think we did refer to > Andy's I-D during the discussions. So from this perspective, do you > agree with the minutes? > The term "module base": o module base: There is an implied "base" version of the module, which includes all statements which are not conditional. The module base may be empty, a subset of all statements, or the entire module. The term "conditional node" o conditional node: An object that has one or more "if-feature" sub- statements associated with it. Note that objects affected by "when" statements are not considered conditional for conformance purposes. Hopefully not all people skip over the Terms section because they think it is part of the boilerplate. I am about to publish draft-04 that addresses only module-level conformance,. The 1 day spent at the interim helped understand the problems of conformance drift and conformance ambiguity a little better. There are still some details that are broken wrt/ interim consensus. For example, many client applications expect the entire module set used by the server will be advertised. Removing modules from this advertisement will break such applications. > /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113ac3a0c4db9f0503a7ba14 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > Hi,
>
> I am not sure I agree with the following:
>
> Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
>
> >=A0 =A0 Proposal: Keep features as the unit of conformance in YANG= 1.1 but
> >=A0 =A0 consider certain improvements:
> >=A0 =A0 =A0 - indicate in the module advertisement data model the = conformance
> >=A0 =A0 =A0 =A0 associated with a module (full =3D "all base = data nodes, rpcs,
> >=A0 =A0 =A0 =A0 notifications", )
>
> I think "full" should mean "everything except nodes dep= ending on
> features that the server does not advertise".
>
> My understanding was that "base" means only nodes that don&#= 39;t depend on
> any feature, regardless of what the server advertises.

I understood full as in draft-bierman-netmod-yang-conformance-03.txt:

=A0 =A0o=A0 full: Full implementation of the module base is required.=A0 Th= is is
=A0 =A0 =A0 the default value if the require-conformance statement is not =A0 =A0 =A0 present.

I assume 'full' is kind of a misnomer but I think we did refer to Andy's I-D during the discussions. So from this perspective, do you
agree with the minutes?

The term "= module base":


=A0 =A0o =A0modu= le base: There is an implied "base" version of the module,
<= div>=A0 =A0 =A0 which includes all statements which are not conditional.=A0= The
=A0 =A0 =A0 module base may be empty, a subset of all statem= ents, or the
=A0 =A0 =A0 entire module.

= The term "conditional node"

=A0 o = =A0conditional node: An object that has one or more "if-feature" = sub-
=A0 =A0 =A0 statements associated with it.=A0 Note that obje= cts affected by
=A0 =A0 =A0 "when" statements are not c= onsidered conditional for conformance
=A0 =A0 =A0 purposes.
=

Hopefully not all people skip over the Terms sect= ion because they think
it is part of the boilerplate.
<= br>
I am about to publish draft-04 that addresses only module-lev= el conformance,.
The 1 day spent at the interim helped understand= the problems of
conformance drift and conformance ambiguity a li= ttle better.

There are still some details that are= broken wrt/ interim consensus.
For example, many client applicat= ions expect the entire module set
used by the server will be adve= rtised.=A0 Removing modules from this
advertisement will break su= ch applications.=A0



/js


Andy
=A0
=
--
Juergen Schoenwaelder=A0 =A0 =A0 =A0 =A0 =A0Jacobs University Bremen gGmbH<= br> Phone: +49 421 200 3587=A0 =A0 =A0 =A0 =A0Campus Ring 1, 28759 Bremen, Germ= any
Fax:=A0 =A0+49 421 200 3103=A0 =A0 =A0 =A0 =A0<http://www.jacobs-university.de/&= gt;

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

--001a113ac3a0c4db9f0503a7ba14-- From nobody Mon Sep 22 07:07:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F08621A1B27 for ; Mon, 22 Sep 2014 07:07:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 4YzPZAzj1BZ3 for ; Mon, 22 Sep 2014 07:07:42 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C26731A6EE8 for ; Mon, 22 Sep 2014 06:52:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6073F73C; Mon, 22 Sep 2014 15:52:25 +0200 (CEST) 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 9yboMJDs3q-C; Mon, 22 Sep 2014 15:52:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 15:52:24 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2D28F20036; Mon, 22 Sep 2014 15:52:24 +0200 (CEST) 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 sIaudAF60CT2; Mon, 22 Sep 2014 15:52:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CE6F020035; Mon, 22 Sep 2014 15:52:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CBFDB2E85660; Mon, 22 Sep 2014 15:52:21 +0200 (CEST) Date: Mon, 22 Sep 2014 15:52:21 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140922135221.GA18260@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , Martin Bjorklund , "netmod@ietf.org" References: <20140919.145158.1514198271114340913.mbj@tail-f.com> <20140922083420.GD16886@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Npmcjubj2B7-oj0mxP27WKOSybs Cc: "netmod@ietf.org" Subject: Re: [netmod] system created list entries X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:07:47 -0000 On Mon, Sep 22, 2014 at 01:25:57PM +0000, Sterne, Jason (Jason) wrote: > Hi guys, > > This isn't as simple as a system just ignoring a deletion. It is about how that deletion would look in a . An absence of the entry doesn't tell the client that the system created entry is being explicitly suppressed/deleted (and an absence can't represent the explicit delete/suppression that in theory should be shown in a startup ds). > > Let me walk through an example in a bit more detail: > > ## (A) system model > > list foo { > key "entry" > leaf entry { > type string; > } > } > > ## (B) initial result from the ds on a newly booted system contains an entry that is populated by the system at startup time > > > > system-created-1 > > > > ## (C) user does an to add a new foo entry ' client-created-1'. Results of a now look like this: > > > > system-created-1 > > > client-created-1 > > > > ## (D) user deletes the entry 'system-created-1'. Results of a look like this: > > > > client-created-1 > > > > ## (E) now a from to . Does a of the return the same as what we see in (D) above ? I hope so. > If so - what tells the system during the next startup to actually suppress 'system-created-1' ? > > A simple absence of system-created-1 from the ds can't really cause the deletion of that entry IMO. A completely empty ds should have the system come up with the 'system-created-1' entry configured. > Exactly. The startup config is not empty anymore so that system should not auto-populate it anymore. > Maybe the only solution is an implementation specific item in the startup ds that says to explicitly delete 'system-created-1' but I was looking for any way to model/show this in NETCONF/YANG. > Some CLIs work in the way you describe where the deletion of always automatically generated stuff is part of the explicit config. This is not how I think NETCONF/YANG works. Things can be even a bit more tricky to implement since auto-population of entries may be needed for hot pluggable components even if there is already some other config. So the condition is not just config empty yes/no but relevant config empty yes/no or you would have to keep track whether auto-population has already been carried out. But for sure, blindly always auto-populating on every restart seems to be a bit too simplistic. /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 Sep 22 07:11:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAE341A1AF5 for ; Mon, 22 Sep 2014 07:11:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 RPOnJxeLF9EO for ; Mon, 22 Sep 2014 07:11:50 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BBE51A1AF8 for ; Mon, 22 Sep 2014 07:03:11 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id EE582140BCE; Mon, 22 Sep 2014 16:03:09 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411394590; bh=lWTxQnlnQNW9NnbNELMe9ZQMP7vy9qW2fFP7p/o+t2I=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=ESpnuv2Sr4LXS/YzzxbGYT2XZ/1CX6+X6GAuQISzQlu1sBfks06Zi/tmo2Kc9G5NS Xg+zGRhKNrzbwrEIhUVRNE4CCekL6YEh8pt2XZYJ6pwHw1of0s1aXczwD2++QTBqoD I94w6Erztt/VJL+PyjUh3obNFUKtn3WaFUd2jMw4= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 22 Sep 2014 16:03:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-rCqyQAR1LXbZ2sDAwltXA4si7E Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:11:51 -0000 On 22 Sep 2014, at 15:50, Andy Bierman wrote: >=20 >=20 > On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > > Hi, > > > > I am not sure I agree with the following: > > > > Juergen Schoenwaelder writes: > > > > > Proposal: Keep features as the unit of conformance in YANG 1.1 = but > > > consider certain improvements: > > > - indicate in the module advertisement data model the = conformance > > > associated with a module (full =3D "all base data nodes, = rpcs, > > > notifications", ) > > > > I think "full" should mean "everything except nodes depending on > > features that the server does not advertise". > > > > My understanding was that "base" means only nodes that don't depend = on > > any feature, regardless of what the server advertises. >=20 > I understood full as in draft-bierman-netmod-yang-conformance-03.txt: >=20 > o full: Full implementation of the module base is required. This = is > the default value if the require-conformance statement is not > present. >=20 > I assume 'full' is kind of a misnomer but I think we did refer to > Andy's I-D during the discussions. So from this perspective, do you > agree with the minutes? >=20 > The term "module base": >=20 >=20 > o module base: There is an implied "base" version of the module, > which includes all statements which are not conditional. The > module base may be empty, a subset of all statements, or the > entire module. >=20 > The term "conditional node" >=20 > o conditional node: An object that has one or more "if-feature" = sub- > statements associated with it. Note that objects affected by > "when" statements are not considered conditional for conformance > purposes. >=20 > Hopefully not all people skip over the Terms section because they = think > it is part of the boilerplate. I didn=92t skip that section, and that=92s why I raised this issue. = Unconditional nodes are not enough for full conformance - if they were, = why bother with features? Lada >=20 > I am about to publish draft-04 that addresses only module-level = conformance,. > The 1 day spent at the interim helped understand the problems of > conformance drift and conformance ambiguity a little better. >=20 > There are still some details that are broken wrt/ interim consensus. > For example, many client applications expect the entire module set > used by the server will be advertised. Removing modules from this > advertisement will break such applications.=20 >=20 >=20 >=20 > /js >=20 >=20 > Andy > =20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 07:13:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D00631A00E6 for ; Mon, 22 Sep 2014 07:13:45 -0700 (PDT) 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 GK7Fo4CDNWYI for ; Mon, 22 Sep 2014 07:13:42 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B5B71A1B3C for ; Mon, 22 Sep 2014 07:09:39 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id r5so84057qcx.10 for ; Mon, 22 Sep 2014 07:09:38 -0700 (PDT) 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=y3ZgC8i9IFVfPAnvUpau1uWB7+GL0j8Dgvo/ySreZwQ=; b=RQLaknohx7AEck324nElpnWo77GbFvXDyAjISs6bjSAmLch8ttmz4C9fb0oPYrNtll J4bbapMXcQsgfC+tCduwkxg2ODqwxPXFJJjFDpWkVe/yx7fvIk0cogSTUU/QVT+TSo6E A4grkSiv3txRSnCQ05Pfz+lWrDl73DQYOqmqaGS37B5VCqNDx3QZqrKV2dGptlQ4pFDL mBWwv6uH/KJhBrMMxJVnqJSKZKGYJauZ9MkQd8HVV39af+xzcRs+Alj3Ip7v0f4C0S8B rt4APIL2GKKkvSBAnhslzC1RcEDvRgpnQzyjeFPB8VWoNvi2RH6Sm3cBWn0rzBUhBoMn Y39Q== X-Gm-Message-State: ALoCoQkGFodhg3OtzLoi74DgJPstEypX/9DNYZlbrPR37GLk7LQv7yW0qoQ/WGBe4JNZm/sMdhv+ MIME-Version: 1.0 X-Received: by 10.224.60.129 with SMTP id p1mr2793173qah.99.1411394978240; Mon, 22 Sep 2014 07:09:38 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 07:09:38 -0700 (PDT) In-Reply-To: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> Date: Mon, 22 Sep 2014 07:09:38 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3d8d451336f0503a800e6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kzYV0yYjBYQcrmqAn79CvIK2VF8 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:13:46 -0000 --001a11c3d8d451336f0503a800e6 Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 7:03 AM, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 15:50, Andy Bierman wrote: > > > > > > > On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote: > > > Hi, > > > > > > I am not sure I agree with the following: > > > > > > Juergen Schoenwaelder writes: > > > > > > > Proposal: Keep features as the unit of conformance in YANG 1.1 but > > > > consider certain improvements: > > > > - indicate in the module advertisement data model the > conformance > > > > associated with a module (full = "all base data nodes, rpcs, > > > > notifications", ) > > > > > > I think "full" should mean "everything except nodes depending on > > > features that the server does not advertise". > > > > > > My understanding was that "base" means only nodes that don't depend on > > > any feature, regardless of what the server advertises. > > > > I understood full as in draft-bierman-netmod-yang-conformance-03.txt: > > > > o full: Full implementation of the module base is required. This is > > the default value if the require-conformance statement is not > > present. > > > > I assume 'full' is kind of a misnomer but I think we did refer to > > Andy's I-D during the discussions. So from this perspective, do you > > agree with the minutes? > > > > The term "module base": > > > > > > o module base: There is an implied "base" version of the module, > > which includes all statements which are not conditional. The > > module base may be empty, a subset of all statements, or the > > entire module. > > > > The term "conditional node" > > > > o conditional node: An object that has one or more "if-feature" sub- > > statements associated with it. Note that objects affected by > > "when" statements are not considered conditional for conformance > > purposes. > > > > Hopefully not all people skip over the Terms section because they think > > it is part of the boilerplate. > > I didn't skip that section, and that's why I raised this issue. > Unconditional nodes are not enough for full conformance - if they were, why > bother with features? > > huh? The server can choose it if wants to advertise any features from a module. Simply importing another module does not pull in any statements associated with a YANG feature. Perhaps the term "full" should be "base" instead. The term "full" is not relevant to YANG conformance. There are only the parts that are not conditional (base) and an ad-hoc collection of purely optional conditional parts. > Lada > Andy > > > > > I am about to publish draft-04 that addresses only module-level > conformance,. > > The 1 day spent at the interim helped understand the problems of > > conformance drift and conformance ambiguity a little better. > > > > There are still some details that are broken wrt/ interim consensus. > > For example, many client applications expect the entire module set > > used by the server will be advertised. Removing modules from this > > advertisement will break such applications. > > > > > > > > /js > > > > > > Andy > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c3d8d451336f0503a800e6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 7:03 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

On 22 Sep 2014, at 15:50, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> On Mon, Sep 22, 2014 at 3:54 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-univers= ity.de> wrote:
> On Mon, Sep 22, 2014 at 08:35:16AM +0200, Ladislav Lhotka wrote:
> > Hi,
> >
> > I am not sure I agree with the following:
> >
> > Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> writes:
> >
> > >    Proposal: Keep features as the unit of conforma= nce in YANG 1.1 but
> > >    consider certain improvements:
> > >      - indicate in the module advertisement d= ata model the conformance
> > >        associated with a module (full = =3D "all base data nodes, rpcs,
> > >        notifications", )
> >
> > I think "full" should mean "everything except node= s depending on
> > features that the server does not advertise".
> >
> > My understanding was that "base" means only nodes that = don't depend on
> > any feature, regardless of what the server advertises.
>
> I understood full as in draft-bierman-netmod-yang-conformance-03.txt:<= br> >
>    o  full: Full implementation of the module base is r= equired.  This is
>       the default value if the require-conformance= statement is not
>       present.
>
> I assume 'full' is kind of a misnomer but I think we did refer= to
> Andy's I-D during the discussions. So from this perspective, do yo= u
> agree with the minutes?
>
> The term "module base":
>
>
>    o  module base: There is an implied "base"= version of the module,
>       which includes all statements which are not = conditional.  The
>       module base may be empty, a subset of all st= atements, or the
>       entire module.
>
> The term "conditional node"
>
>   o  conditional node: An object that has one or more &= quot;if-feature" sub-
>       statements associated with it.  Note th= at objects affected by
>       "when" statements are not consider= ed conditional for conformance
>       purposes.
>
> Hopefully not all people skip over the Terms section because they thin= k
> it is part of the boilerplate.

I didn’t skip that section, and that’s why I raised this issue.= Unconditional nodes are not enough for full conformance - if they were, wh= y bother with features?


huh?
The server can choose i= t if wants to advertise any features from a module.
Simply import= ing another module does not pull in any statements associated with
a YANG feature.

Perhaps the term "full"= ; should be "base" instead.
The term "full" i= s not relevant to YANG conformance.
There are only the parts that= are not conditional (base)
and an ad-hoc collection of purely op= tional conditional parts.


 
Lada

Andy
 

>
> I am about to publish draft-04 that addresses only module-level confor= mance,.
> The 1 day spent at the interim helped understand the problems of
> conformance drift and conformance ambiguity a little better.
>
> There are still some details that are broken wrt/ interim consensus. > For example, many client applications expect the entire module set
> used by the server will be advertised.  Removing modules from thi= s
> advertisement will break such applications.
>
>
>
> /js
>
>
> Andy
>
> --
> Juergen Schoenwaelder           Jacobs U= niversity Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1= , 28759 Bremen, Germany
> Fax:   +49 421 200 3103         <= ;http://www.= jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c3d8d451336f0503a800e6-- From nobody Mon Sep 22 07:20:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3A74E1A1ACB for ; Mon, 22 Sep 2014 07:20:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 4Wu3j11dDXqC for ; Mon, 22 Sep 2014 07:20:35 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B2DCD1A1AB9 for ; Mon, 22 Sep 2014 07:20:34 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 83765752; Mon, 22 Sep 2014 16:20:33 +0200 (CEST) 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 9xlvYCbHEJc5; Mon, 22 Sep 2014 16:20:32 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 16:20:32 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8430C20036; Mon, 22 Sep 2014 16:20:32 +0200 (CEST) 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 eSFBne8onUhD; Mon, 22 Sep 2014 16:20:31 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FD2120035; Mon, 22 Sep 2014 16:20:31 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1829E2E85856; Mon, 22 Sep 2014 16:20:31 +0200 (CEST) Date: Mon, 22 Sep 2014 16:20:30 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922142030.GD18309@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@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.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Jiknj3OKzfbzMHoXkCZXNC6HUkM Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:20:40 -0000 On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote: > > I didn’t skip that section, and that’s why I raised this issue. > Unconditional nodes are not enough for full conformance - if > they were, why bother with features? This is why I said 'full' is a misnomer. I have changed the minutes as follows: Index: netmod-2014-09-18-minutes.txt =================================================================== --- netmod-2014-09-18-minutes.txt (revision 72) +++ netmod-2014-09-18-minutes.txt (working copy) @@ -162,8 +169,10 @@ Proposal: Keep features as the unit of conformance in YANG 1.1 but consider certain improvements: - indicate in the module advertisement data model the conformance - associated with a module (full = "all base data nodes, rpcs, - notifications", ) + associated with a module (base = "all unconditional data nodes, + rpcs, notifications", import = "only extensions, typedefs, + groupings, identities and features that are defined at the top + level of the module") - support import by revision >= N OR remove import by revision (which is mostly important for groupings that get modified) - allow adding/removing features/if-features in revised YANG Does this resolve this issue with the minutes? /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 Sep 22 07:21:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 398501A1AD3 for ; Mon, 22 Sep 2014 07:21:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGfClrynUX0n for ; Mon, 22 Sep 2014 07:21:53 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) (using TLSv1.1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0BDC61A1AD4 for ; Mon, 22 Sep 2014 07:21:53 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by trail.lhotka.name (Postfix) with ESMTP id 2B5B354086F; Mon, 22 Sep 2014 16:21:51 +0200 (CEST) Received: from trail.lhotka.name ([127.0.0.1]) by localhost (trail.lhotka.name [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxnPDHIux2gr; Mon, 22 Sep 2014 16:21:43 +0200 (CEST) Received: from localhost (unknown [172.29.2.201]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by trail.lhotka.name (Postfix) with ESMTPSA id 2D29C540030; Mon, 22 Sep 2014 16:21:42 +0200 (CEST) From: Ladislav Lhotka To: Andy Bierman In-Reply-To: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> User-Agent: Notmuch/0.18.1 (http://notmuchmail.org) Emacs/24.3.50.2 (x86_64-apple-darwin13.0.0) Date: Mon, 22 Sep 2014 16:21:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KJPnSIugo_oMjFt9Culvm_V8sSc Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:21:58 -0000 Andy Bierman writes: > huh? > The server can choose it if wants to advertise any features from a module. > Simply importing another module does not pull in any statements associated > with > a YANG feature. > > Perhaps the term "full" should be "base" instead. > The term "full" is not relevant to YANG conformance. > There are only the parts that are not conditional (base) > and an ad-hoc collection of purely optional conditional parts. > module M { ... feature X; leaf foo { type empty; } leaf bar { if-feature X; type uint8; } } Now, the server advertises module M with feature X, and also claims "full" conformance. Is it OK if it only implements "foo" and not "bar" (because only the former is a part of "base module")? The point is as soon as a feature is advertised, the corresponding conditional parts are no more purely optional. Lada -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 07:49:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8BA1A1AF9 for ; Mon, 22 Sep 2014 07:49:33 -0700 (PDT) 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 fC_00a9hYCTn for ; Mon, 22 Sep 2014 07:49:20 -0700 (PDT) Received: from mail-qg0-f50.google.com (mail-qg0-f50.google.com [209.85.192.50]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C1DDF1A1B16 for ; Mon, 22 Sep 2014 07:49:14 -0700 (PDT) Received: by mail-qg0-f50.google.com with SMTP id q107so2923661qgd.23 for ; Mon, 22 Sep 2014 07:49:14 -0700 (PDT) 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=xLGOEsUPnuLigQ/3xNEr0a2MXqsoDngQcGQgUw+Ki4I=; b=a/8NcXB1QFXVCObcJpIBaLsKd2/GFBZcmZHvt7Sn5/h/WwU9adfNCWq70aJWspcsMx 2SGIs/2bPO0nUuD9E3VsAU8cmP2LGv0ws5XJT+6NDmNxlyeaa5dUqyTElvSefeBX/EQ7 yGi8GTv51Q8XvMonHciwCceS9THIYXHR4gEFl85vUE6YzPQAFvZL9G4OAZXBRTqfeEGx SZDZWyS5Ynx8YtMVPLiz5nFhlBo5Y1sq2Qys9VHVeYtDeTBeKpoo5qZDnTBZivrvTJ4a AHeZiYPr97SCBT28TJctnsA65xl0G6a5G38tJBRnEcUBaYJz2SbSJWqKhe63tl2GyHbc +xAw== X-Gm-Message-State: ALoCoQm9MckS2ECYZOuvUK6OmTn52/FFe/2eycar+x0RdVN0EGvkScvsqBhLsS+Lk3WeNQuqlzCs MIME-Version: 1.0 X-Received: by 10.140.98.11 with SMTP id n11mr9818713qge.83.1411397353910; Mon, 22 Sep 2014 07:49:13 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 07:49:13 -0700 (PDT) In-Reply-To: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> Date: Mon, 22 Sep 2014 07:49:13 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113ac3a0ead0720503a88dde Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6pxZJjqf5IYCMoBTvxCrQyTD32A Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 14:49:34 -0000 --001a113ac3a0ead0720503a88dde Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka wrote: > Andy Bierman writes: > > > huh? > > The server can choose it if wants to advertise any features from a > module. > > Simply importing another module does not pull in any statements > associated > > with > > a YANG feature. > > > > Perhaps the term "full" should be "base" instead. > > The term "full" is not relevant to YANG conformance. > > There are only the parts that are not conditional (base) > > and an ad-hoc collection of purely optional conditional parts. > > > > module M { > ... > feature X; > leaf foo { type empty; } > leaf bar { > if-feature X; > type uint8; > } > } > > Now, the server advertises module M with feature X, and also claims > "full" conformance. Is it OK if it only implements "foo" and not "bar" > (because only the former is a part of "base module")? > nobody has ever suggested that implementation of an optional part could be done instead of the non-optional parts. > > The point is as soon as a feature is advertised, the corresponding > conditional parts are no more purely optional. > > yes -- that is how YANG features work. Not sure why we need reminding of that. Advertising "module=M&revision=2014-01-01" is needed so the module set is complete. Applications use that for a parts list, not conformance. The server would only add "&features=X" if it elected to support the conditional parts for X. > Lada > Andy > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > --001a113ac3a0ead0720503a88dde Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> huh?
> The server can choose it if wants to advertise any features from a mod= ule.
> Simply importing another module does not pull in any statements associ= ated
> with
> a YANG feature.
>
> Perhaps the term "full" should be "base" instead.<= br> > The term "full" is not relevant to YANG conformance.
> There are only the parts that are not conditional (base)
> and an ad-hoc collection of purely optional conditional parts.
>

module M {
=A0 ...
=A0 feature X;
=A0 leaf foo { type empty; }
=A0 leaf bar {
=A0 =A0 if-feature X;
=A0 =A0 type uint8;
=A0 }
}

Now, the server advertises module M with feature X, and also claims
"full" conformance. Is it OK if it only implements "foo"= ; and not "bar"
(because only the former is a part of "base module")?

nobody has ever suggested that implementation of a= n optional part
could be done instead of the non-optional parts.<= /div>
=A0

The point is as soon as a feature is advertised, the corresponding
conditional parts are no more purely optional.


yes -- that is how YANG features work.= =A0 Not sure why we need reminding of that.

Advert= ising "module=3DM&revision=3D2014-01-01" is needed so the mod= ule set is
complete. Applications use that for a parts list, not = conformance.=A0 The server
would only add "&features=3DX= " if it elected to support the conditional parts for X.

=
=A0
Lada

Andy
=A0

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

--001a113ac3a0ead0720503a88dde-- From nobody Mon Sep 22 08:04:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D084C1A1AF3 for ; Mon, 22 Sep 2014 08:04:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 fN1ptBrYN0oa for ; Mon, 22 Sep 2014 08:04:30 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 547901A0145 for ; Mon, 22 Sep 2014 08:04:30 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id BFE53140AC7; Mon, 22 Sep 2014 17:04:28 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411398269; bh=Iu+zyxKjZIzSEleBy13YCq6G4TagNHcxKrruShtSBXU=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=CggRz8eRuslj4tR28f88BY2ZbmxtClCr3nMt/gHhGNg9JJWf4EHgzLLiqhAE1JCau YbHCA1WnFOP/KXhPs7tZXgNVid2NAuadJiO/ndwdCLh40SIxLEmE6otGLEVUdxSpqx sUhx4BLnAo1bk9y8vWC32EbayZXzVR8PpibrI7FI= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 22 Sep 2014 17:04:26 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1oduWkL0wkKW9ti__K6AiCZlDK8 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:04:32 -0000 On 22 Sep 2014, at 16:49, Andy Bierman wrote: >=20 >=20 > On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka = wrote: > Andy Bierman writes: >=20 > > huh? > > The server can choose it if wants to advertise any features from a = module. > > Simply importing another module does not pull in any statements = associated > > with > > a YANG feature. > > > > Perhaps the term "full" should be "base" instead. > > The term "full" is not relevant to YANG conformance. > > There are only the parts that are not conditional (base) > > and an ad-hoc collection of purely optional conditional parts. > > >=20 > module M { > ... > feature X; > leaf foo { type empty; } > leaf bar { > if-feature X; > type uint8; > } > } >=20 > Now, the server advertises module M with feature X, and also claims > "full" conformance. Is it OK if it only implements "foo" and not "bar" > (because only the former is a part of "base module")? >=20 > nobody has ever suggested that implementation of an optional part > could be done instead of the non-optional parts. My understanding of full conformance is that *both* foo and bar must be = implemented in this case. > =20 >=20 > The point is as soon as a feature is advertised, the corresponding > conditional parts are no more purely optional. >=20 >=20 > yes -- that is how YANG features work. Not sure why we need reminding = of that. >=20 > Advertising "module=3DM&revision=3D2014-01-01" is needed so the module = set is > complete. Applications use that for a parts list, not conformance. = The server > would only add "&features=3DX" if it elected to support the = conditional parts for X. In my view, full/import is orthogonal to feature specification. A module = may be advertised with "&features=3DX=94 and only import conformance = level. Lada >=20 > =20 > Lada >=20 > Andy > =20 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 08:16:30 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED5181A1AD2 for ; Mon, 22 Sep 2014 08:16:26 -0700 (PDT) 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 HrikAsiPEKpg for ; Mon, 22 Sep 2014 08:16:18 -0700 (PDT) Received: from mail-qg0-f48.google.com (mail-qg0-f48.google.com [209.85.192.48]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CFD1A1AC6 for ; Mon, 22 Sep 2014 08:16:17 -0700 (PDT) Received: by mail-qg0-f48.google.com with SMTP id z107so3065365qgd.35 for ; Mon, 22 Sep 2014 08:16:16 -0700 (PDT) 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=Z8oGTJEGPPMZg2F4r8vmfSPhEsQExFI1gKktY1j6C/w=; b=ZhndLl8ETigdaGil3BcuCXstJoQoy+Gxova++fUev0uH8HoYgnLPTlpgtA/3vlUvnm yqtxnapCeDOVuTV6A197mbpZIzTkqLACEE00DyfU5l5I7fYyF11M6YHkDtJHLtdTT3VH 7zZ1Je40pQK42i2jAVzJkbG5Kkhh5YXaBvU461n3ZsWwNpuI0PfDU8s5VV3pLYb3O24j vePCs3BoueTZUlp1GgLHAuoOamcEpM4KEFb05U39fCuDNDEPTsoTMk2fphTtcvGpRKpw hcKU/1+4hEQdLtlycISRTTNGkD/BCPkoHen7EE690927W69nH0h4p68EZAJ22H37xPum tYTg== X-Gm-Message-State: ALoCoQkjb7v5ks/nlt3nyD8tm/Ae89CTYLYhrT7X4yvFuYQdbjdvAx+ag8OoUv91Jz5GVBnmdkJ4 MIME-Version: 1.0 X-Received: by 10.224.73.132 with SMTP id q4mr23583549qaj.78.1411398976771; Mon, 22 Sep 2014 08:16:16 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 08:16:16 -0700 (PDT) In-Reply-To: <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> Date: Mon, 22 Sep 2014 08:16:16 -0700 Message-ID: From: Andy Bierman To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a11c3e142a5ce080503a8ee8e Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/1j6ge_0tgmfKM9P3-xH9S2fnXM8 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:16:27 -0000 --001a11c3e142a5ce080503a8ee8e Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 8:04 AM, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 16:49, Andy Bierman wrote: > > > > > > > On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > huh? > > > The server can choose it if wants to advertise any features from a > module. > > > Simply importing another module does not pull in any statements > associated > > > with > > > a YANG feature. > > > > > > Perhaps the term "full" should be "base" instead. > > > The term "full" is not relevant to YANG conformance. > > > There are only the parts that are not conditional (base) > > > and an ad-hoc collection of purely optional conditional parts. > > > > > > > module M { > > ... > > feature X; > > leaf foo { type empty; } > > leaf bar { > > if-feature X; > > type uint8; > > } > > } > > > > Now, the server advertises module M with feature X, and also claims > > "full" conformance. Is it OK if it only implements "foo" and not "bar" > > (because only the former is a part of "base module")? > > > > nobody has ever suggested that implementation of an optional part > > could be done instead of the non-optional parts. > > My understanding of full conformance is that *both* foo and bar must be > implemented in this case. > If the server does not advertise feature X: foo is mandatory to implement If the server does advertise feature X: foo and bar are mandatory to implement > > > > > > The point is as soon as a feature is advertised, the corresponding > > conditional parts are no more purely optional. > > > > > > yes -- that is how YANG features work. Not sure why we need reminding > of that. > > > > Advertising "module=M&revision=2014-01-01" is needed so the module set is > > complete. Applications use that for a parts list, not conformance. The > server > > would only add "&features=X" if it elected to support the conditional > parts for X. > > In my view, full/import is orthogonal to feature specification. A module > may be advertised with "&features=X" and only import conformance level. > > My understanding is the all objects are mandatory to implement unless they have "if-feature" statements. Then all of the corresponding features must be advertised by the server or the data node does not need to be supported. Lada > > Andy > > > > > > Lada > > > > Andy > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > > --001a11c3e142a5ce080503a8ee8e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 8:04 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

On 22 Sep 2014, at 16:49, Andy Bierman <andy@yumaworks.com> wrote:

>
>
> On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
> Andy Bierman <andy@yumaworks.= com> writes:
>
> > huh?
> > The server can choose it if wants to advertise any features from = a module.
> > Simply importing another module does not pull in any statements a= ssociated
> > with
> > a YANG feature.
> >
> > Perhaps the term "full" should be "base" inst= ead.
> > The term "full" is not relevant to YANG conformance. > > There are only the parts that are not conditional (base)
> > and an ad-hoc collection of purely optional conditional parts. > >
>
> module M {
>   ...
>   feature X;
>   leaf foo { type empty; }
>   leaf bar {
>     if-feature X;
>     type uint8;
>   }
> }
>
> Now, the server advertises module M with feature X, and also claims > "full" conformance. Is it OK if it only implements "foo= " and not "bar"
> (because only the former is a part of "base module")?
>
> nobody has ever suggested that implementation of an optional part
> could be done instead of the non-optional parts.

My understanding of full conformance is that *both* foo and bar must be imp= lemented in this case.

If the server do= es not advertise feature X: foo is mandatory to implement
If the = server does advertise feature X: foo and bar are mandatory to implement



>
>
> The point is as soon as a feature is advertised, the corresponding
> conditional parts are no more purely optional.
>
>
> yes -- that is how YANG features work.  Not sure why we need remi= nding of that.
>
> Advertising "module=3DM&revision=3D2014-01-01" is needed= so the module set is
> complete. Applications use that for a parts list, not conformance.&nbs= p; The server
> would only add "&features=3DX" if it elected to support = the conditional parts for X.

In my view, full/import is orthogonal to feature specification. A module ma= y be advertised with "&features=3DX” and only import conform= ance level.



My understanding is the= all objects are mandatory to implement unless they have
"if= -feature" statements. Then all of the corresponding features must be a= dvertised by
the server or the data node does not need to be supp= orted.


Lada


Andy
 
>
>
> Lada
>
> Andy
>
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C





--001a11c3e142a5ce080503a8ee8e-- From nobody Mon Sep 22 08:34:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44FA91A1AF5 for ; Mon, 22 Sep 2014 08:34:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 HTvnKa7uCgeo for ; Mon, 22 Sep 2014 08:34:15 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15AC91A1A64 for ; Mon, 22 Sep 2014 08:34:15 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 65EA3140A24; Mon, 22 Sep 2014 17:34:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411400053; bh=FM6lFjK0pfICDPAtYR+W0SI6mhSyKFbwWKIc++uFSP0=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=RPRwf9IP9au6bk5wzRxoKNFtx5y39tpzmFoe10ajrUI3SQNPmYTmw6E2P8qc9TO4y 0I6Hl9XumXeZybOGm2zkstodn+X/MAiboZJ7bhSxNEFmGBFHUnTQxlOLVE0C92kyxN GnOfuNxUQcYHSCwWVR5pobmuZvLwo8y7noFSczZ8= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 22 Sep 2014 17:34:11 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/pScKt2MHz5lGHOePBjcmYXNHUzE Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:34:16 -0000 On 22 Sep 2014, at 17:16, Andy Bierman wrote: >=20 >=20 > On Mon, Sep 22, 2014 at 8:04 AM, Ladislav Lhotka = wrote: >=20 > On 22 Sep 2014, at 16:49, Andy Bierman wrote: >=20 > > > > > > On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka = wrote: > > Andy Bierman writes: > > > > > huh? > > > The server can choose it if wants to advertise any features from a = module. > > > Simply importing another module does not pull in any statements = associated > > > with > > > a YANG feature. > > > > > > Perhaps the term "full" should be "base" instead. > > > The term "full" is not relevant to YANG conformance. > > > There are only the parts that are not conditional (base) > > > and an ad-hoc collection of purely optional conditional parts. > > > > > > > module M { > > ... > > feature X; > > leaf foo { type empty; } > > leaf bar { > > if-feature X; > > type uint8; > > } > > } > > > > Now, the server advertises module M with feature X, and also claims > > "full" conformance. Is it OK if it only implements "foo" and not = "bar" > > (because only the former is a part of "base module")? > > > > nobody has ever suggested that implementation of an optional part > > could be done instead of the non-optional parts. >=20 > My understanding of full conformance is that *both* foo and bar must = be implemented in this case. >=20 > If the server does not advertise feature X: foo is mandatory to = implement > If the server does advertise feature X: foo and bar are mandatory to = implement >=20 >=20 >=20 > > > > > > The point is as soon as a feature is advertised, the corresponding > > conditional parts are no more purely optional. > > > > > > yes -- that is how YANG features work. Not sure why we need = reminding of that. > > > > Advertising "module=3DM&revision=3D2014-01-01" is needed so the = module set is > > complete. Applications use that for a parts list, not conformance. = The server > > would only add "&features=3DX" if it elected to support the = conditional parts for X. >=20 > In my view, full/import is orthogonal to feature specification. A = module may be advertised with "&features=3DX=94 and only import = conformance level. >=20 >=20 >=20 > My understanding is the all objects are mandatory to implement unless = they have > "if-feature" statements. Then all of the corresponding features must = be advertised by > the server or the data node does not need to be supported. Maybe it would be wiser to wait till the next revision of the = conformance draft because the package declaration is a source of = additional confusion (for me at least). Anyway, my understanding of full/import conformance declaration at the = *module* level is that the server is able to say: 1. full =3D I am implementing everything. 2. import =3D I am only using top-level groupings, typedefs, features = etc. from that module. Features then seem really orthogonal to this information because = conditional nodes may be both in the data trees and in top-level = groupings. Lada >=20 >=20 > Lada >=20 >=20 > Andy > =20 > > > > > > Lada > > > > Andy > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 08:35:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCAF81A1AAD for ; Mon, 22 Sep 2014 08:35:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 Kjb_aGgQEwDO for ; Mon, 22 Sep 2014 08:35:53 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3E171A1A99 for ; Mon, 22 Sep 2014 08:35:52 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B13D0779; Mon, 22 Sep 2014 17:35:51 +0200 (CEST) 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 oYU78UCTFmgl; Mon, 22 Sep 2014 17:35:50 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 17:35:50 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7407220036; Mon, 22 Sep 2014 17:35:50 +0200 (CEST) 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 vWzuNOKpghQj; Mon, 22 Sep 2014 17:35:49 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A1FFD20035; Mon, 22 Sep 2014 17:35:48 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 6FA6D2E85990; Mon, 22 Sep 2014 17:35:48 +0200 (CEST) Date: Mon, 22 Sep 2014 17:35:48 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922153548.GC18615@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <51FB47B0-B2BB-42DC-BBCB-C698698CC3BD@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4J9zWnz-UpVU3CsilZ2DB0k7WhE Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:35:55 -0000 Folks, can we please stop discussing issues in this thread? This thread is for discussing meeting minutes. Thanks. /js On Mon, Sep 22, 2014 at 05:04:26PM +0200, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 16:49, Andy Bierman wrote: > > > > > > > On Mon, Sep 22, 2014 at 7:21 AM, Ladislav Lhotka wrote: > > Andy Bierman writes: > > > > > huh? > > > The server can choose it if wants to advertise any features from a module. > > > Simply importing another module does not pull in any statements associated > > > with > > > a YANG feature. > > > > > > Perhaps the term "full" should be "base" instead. > > > The term "full" is not relevant to YANG conformance. > > > There are only the parts that are not conditional (base) > > > and an ad-hoc collection of purely optional conditional parts. > > > > > > > module M { > > ... > > feature X; > > leaf foo { type empty; } > > leaf bar { > > if-feature X; > > type uint8; > > } > > } > > > > Now, the server advertises module M with feature X, and also claims > > "full" conformance. Is it OK if it only implements "foo" and not "bar" > > (because only the former is a part of "base module")? > > > > nobody has ever suggested that implementation of an optional part > > could be done instead of the non-optional parts. > > My understanding of full conformance is that *both* foo and bar must be implemented in this case. > > > > > > > The point is as soon as a feature is advertised, the corresponding > > conditional parts are no more purely optional. > > > > > > yes -- that is how YANG features work. Not sure why we need reminding of that. > > > > Advertising "module=M&revision=2014-01-01" is needed so the module set is > > complete. Applications use that for a parts list, not conformance. The server > > would only add "&features=X" if it elected to support the conditional parts for X. > > In my view, full/import is orthogonal to feature specification. A module may be advertised with "&features=X†and only import conformance level. > > Lada > > > > > > > Lada > > > > Andy > > > > > > -- > > Ladislav Lhotka, CZ.NIC Labs > > PGP Key ID: E74E8C0C > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > -- 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 Sep 22 08:44:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3701A1AFA for ; Mon, 22 Sep 2014 08:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 Um-D2AmN5R1e for ; Mon, 22 Sep 2014 08:44:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3DB31A1A9E for ; Mon, 22 Sep 2014 08:44:00 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 0B0BE140A24; Mon, 22 Sep 2014 17:43:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411400639; bh=nHuE365D3dY/k6stjj0GgUmQxZJoEjyBWyOqHxKGaLw=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=tL7/vIHGXNIFjiwm2P2Nralua1k64bHUpsmG74IxBXUjUwBJKBTkRMc4st4Tzpckx sHY7yHgSPgz+89gnUUqVxKOuVB8ORzcgo4gezNKaU59cS+BQikx4ZtftRSLORAL/v7 BC1+JljbML6l2bkWy8gsyTF69TO5BCXGDMkU1XGo= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140922142030.GD18309@elstar.local> Date: Mon, 22 Sep 2014 17:43:56 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8FD6D582-9E43-4652-87CE-2AFEDE02F51E@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <20140922142030.GD18309@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SwBWYTM8AvAPiupnI9zjx0I2PCo Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:44:02 -0000 On 22 Sep 2014, at 16:20, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote: >>=20 >> I didn=92t skip that section, and that=92s why I raised this issue.=20= >> Unconditional nodes are not enough for full conformance - if >> they were, why bother with features? >=20 > This is why I said 'full' is a misnomer. I have changed the minutes as > follows: >=20 > Index: netmod-2014-09-18-minutes.txt > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > --- netmod-2014-09-18-minutes.txt (revision 72) > +++ netmod-2014-09-18-minutes.txt (working copy) > @@ -162,8 +169,10 @@ > Proposal: Keep features as the unit of conformance in YANG 1.1 but > consider certain improvements: > - indicate in the module advertisement data model the conformance > - associated with a module (full =3D "all base data nodes, rpcs, > - notifications", ) > + associated with a module (base =3D "all unconditional data = nodes, > + rpcs, notifications", import =3D "only extensions, typedefs, > + groupings, identities and features that are defined at the top > + level of the module") > - support import by revision >=3D N OR remove import by revision > (which is mostly important for groupings that get modified) > - allow adding/removing features/if-features in revised YANG >=20 > Does this resolve this issue with the minutes? I don=92t think so. What is the difference between full and base wrt to = advertised features? Lada >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 08:56:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 122441A1B2C for ; Mon, 22 Sep 2014 08:56:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 4-Cm0hPrtdLo for ; Mon, 22 Sep 2014 08:56:25 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 145461A00AE for ; Mon, 22 Sep 2014 08:56:25 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CF92490; Mon, 22 Sep 2014 17:56:23 +0200 (CEST) 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 PH405WS3cQf9; Mon, 22 Sep 2014 17:56:22 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 17:56:22 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id D139E20036; Mon, 22 Sep 2014 17:56:22 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id N7JZlW8i3CyF; Mon, 22 Sep 2014 17:56:22 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC84720035; Mon, 22 Sep 2014 17:56:21 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id B9A6E2E85A04; Mon, 22 Sep 2014 17:56:21 +0200 (CEST) Date: Mon, 22 Sep 2014 17:56:21 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922155621.GA18762@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <20140922142030.GD18309@elstar.local> <8FD6D582-9E43-4652-87CE-2AFEDE02F51E@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <8FD6D582-9E43-4652-87CE-2AFEDE02F51E@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GQrSCBNUMQ2OOIq0wAGVfZ5WDB8 Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 15:56:27 -0000 On Mon, Sep 22, 2014 at 05:43:56PM +0200, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 16:20, Juergen Schoenwaelder wrote: > > > On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote: > >> > >> I didn’t skip that section, and that’s why I raised this issue. > >> Unconditional nodes are not enough for full conformance - if > >> they were, why bother with features? > > > > This is why I said 'full' is a misnomer. I have changed the minutes as > > follows: > > > > Index: netmod-2014-09-18-minutes.txt > > =================================================================== > > --- netmod-2014-09-18-minutes.txt (revision 72) > > +++ netmod-2014-09-18-minutes.txt (working copy) > > @@ -162,8 +169,10 @@ > > Proposal: Keep features as the unit of conformance in YANG 1.1 but > > consider certain improvements: > > - indicate in the module advertisement data model the conformance > > - associated with a module (full = "all base data nodes, rpcs, > > - notifications", ) > > + associated with a module (base = "all unconditional data nodes, > > + rpcs, notifications", import = "only extensions, typedefs, > > + groupings, identities and features that are defined at the top > > + level of the module") > > - support import by revision >= N OR remove import by revision > > (which is mostly important for groupings that get modified) > > - allow adding/removing features/if-features in revised YANG > > > > Does this resolve this issue with the minutes? > > I don’t think so. What is the difference between full and base wrt to advertised features? > It is unclear. It was unclear during the meeting. The purpose of minutes is to reflect the meeting. I happy to change base back to full. ;-) /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 Sep 22 09:33:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9553A1A0203 for ; Mon, 22 Sep 2014 09:33:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.137 X-Spam-Level: X-Spam-Status: No, score=-1.137 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HELO_EQ_CZ=0.445, HOST_EQ_CZ=0.904, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.786] 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 cEqGZPi9BkWr for ; Mon, 22 Sep 2014 09:33:07 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1ED41A1B25 for ; Mon, 22 Sep 2014 09:33:06 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id F0C1A140A24; Mon, 22 Sep 2014 18:33:04 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1411403585; bh=ZihAk7BPzsDZ59yfqeP31dHnBzHA+wH1hPaEAAdCSwc=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=Uaupf8t74aRR52WxoZQNgHRUmWaBUaj8L5sG784l7yBd6THopHMw3b0J40pt4t6UT wWwAqaKtlUmSM39NNJiDrw0Vnwi4v4FjT2nLPwWDrBw5rHkKg9AxXgnn273l0QZZ0B y+6h3JxUwaUVPQYxRzQTxzIo6xUsailgAOSMtmhk= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <20140922155621.GA18762@elstar.local> Date: Mon, 22 Sep 2014 18:33:02 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <08C07D1A-1056-4782-9E79-37BF8217A92A@nic.cz> References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <20140922142030.GD18309@elstar.local> <8FD6D582-9E43-4652-87CE-2AFEDE02F51E@nic.cz> <20140922155621.GA18762@elstar.local> To: =?windows-1252?Q?J=FCrgen_Sch=F6nw=E4lder?= X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/65I0m9JR3azHCvTw0yyLfQKqtEg Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 16:33:08 -0000 On 22 Sep 2014, at 17:56, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 05:43:56PM +0200, Ladislav Lhotka wrote: >>=20 >> On 22 Sep 2014, at 16:20, Juergen Schoenwaelder = wrote: >>=20 >>> On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote: >>>>=20 >>>> I didn=92t skip that section, and that=92s why I raised this issue.=20= >>>> Unconditional nodes are not enough for full conformance - if >>>> they were, why bother with features? >>>=20 >>> This is why I said 'full' is a misnomer. I have changed the minutes = as >>> follows: >>>=20 >>> Index: netmod-2014-09-18-minutes.txt >>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>> --- netmod-2014-09-18-minutes.txt (revision 72) >>> +++ netmod-2014-09-18-minutes.txt (working copy) >>> @@ -162,8 +169,10 @@ >>> Proposal: Keep features as the unit of conformance in YANG 1.1 but >>> consider certain improvements: >>> - indicate in the module advertisement data model the = conformance >>> - associated with a module (full =3D "all base data nodes, = rpcs, >>> - notifications", ) >>> + associated with a module (base =3D "all unconditional data = nodes, >>> + rpcs, notifications", import =3D "only extensions, typedefs, >>> + groupings, identities and features that are defined at the = top >>> + level of the module") >>> - support import by revision >=3D N OR remove import by revision >>> (which is mostly important for groupings that get modified) >>> - allow adding/removing features/if-features in revised YANG >>>=20 >>> Does this resolve this issue with the minutes? >>=20 >> I don=92t think so. What is the difference between full and base wrt = to advertised features? >>=20 >=20 > It is unclear. It was unclear during the meeting. The purpose of > minutes is to reflect the meeting. I happy to change base back to > full. ;-) Actually, it might be better to delete the text in parentheses and leave = it to the draft to define these terms properly. Lada =20 >=20 > /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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Sep 22 10:06:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0DF21A1BA4; Mon, 22 Sep 2014 10:06:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbLG_S_IVr8G; Mon, 22 Sep 2014 10:06:33 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F27F1A1BAC; Mon, 22 Sep 2014 10:06:27 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 5.6.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140922170627.32426.41231.idtracker@ietfa.amsl.com> Date: Mon, 22 Sep 2014 10:06:27 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/KGkKlDMVajrZGX5psUCvpLLlsdg Cc: netmod chair , netmod mailing list , RFC Editor Subject: [netmod] Protocol Action: 'A YANG Data Model for SNMP Configuration' to Proposed Standard (draft-ietf-netmod-snmp-cfg-08.txt) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:06:41 -0000 The IESG has approved the following document: - 'A YANG Data Model for SNMP Configuration' (draft-ietf-netmod-snmp-cfg-08.txt) as Proposed Standard This document is the product of the NETCONF Data Modeling Language Working Group. The IESG contact persons are Benoit Claise and Joel Jaeggli. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-netmod-snmp-cfg/ Technical Summary This document defines a collection of YANG definitions for configuring SNMP engines. The configuration data model in particular targets SNMP deployments where SNMP runs in read-only mode and NETCONF is used to configure the SNMP agent. Nevertheless, the data model has been designed to allow implementations that support write access both via SNMP and NETCONF in order to interwork with SNMP-managed management applications manipulating SNMP agent configuration using SNMP. Working Group Summary Was there anything in WG process that is worth noting? For example, was there controversy about particular points or were there decisions where the consensus was particularly rough? This document is a NETMOD Working Group document, adopted in 2012-06-05. This document WG last call was completed on Dec 20, 2013. A number of comments were posted to the list and addressed in revision -04 of the draft. This version of the draft was reviewed by the WG chairs. We believe that it is now stable and complete. Document Quality I polled the WG and NuDesign Technologies and Tail-F responded indicating they have implementations of the MIB and have provided their feedback. A few other people indicated they have or plan to implement the module, but did not want to be named or give details. Martin and Jürgen are key Yang Doctors and provided sigifnicant review of the document as it progressed. Benoit felt that this was significant and thorough enough review to count as a Yang Doctor review. Personnel Tom Nadeau is the Document Shepherd for this document. Benoit Claise is the responsible Area Director. From nobody Mon Sep 22 10:31:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 892B31A1A60 for ; Mon, 22 Sep 2014 10:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 wOEJs1pyVDES for ; Mon, 22 Sep 2014 10:31:43 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ADEEC1A1BAC for ; Mon, 22 Sep 2014 10:31:42 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id A4D42C79A8CAD for ; Mon, 22 Sep 2014 17:31:38 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s8MHVffw000599 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 13:31:41 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 13:31:41 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: YANG 1.1 Y16 (optimized hello) and revisions Thread-Index: Ac/WixFDq4XPgLJIRhazuRn0Dezuag== Date: Mon, 22 Sep 2014 17:31:40 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C948971US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ulzFWrJaVcadOa5KugFSlX265Zg Subject: [netmod] YANG 1.1 Y16 (optimized hello) and revisions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:31:47 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C948971US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all, I saw the minutes about Y16 from the Sept 17/18 interim meeting (and some o= f the followup discussions in the meeting minutes thread) but I didn't noti= ce discussion about revisions. In Y16-02 how would indications of revisions work for an = ? The 100+ modules in a hello can each have a revision indicated but onc= e we aggregate them up into a single "set" does a new revision of one of th= e modules constitute a new set ? a new overall revision for the set ? Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5C948971US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi all,
 
I saw the minutes about Y16 from the Sept 17/18 interim meeting (and s= ome of the followup discussions in the meeting minutes thread) but I didn&#= 8217;t notice discussion about revisions.
 
In Y16-02 how would indications of revisions work for an <id-of-mod= ule-set> ?   The 100+ modules in a hello can each have a r= evision indicated but once we aggregate them up into a single “set= 221; does a new revision of one of the modules constitute a new set ?   a new overall revision for the set ?
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5C948971US70TWXCHMBA11z_-- From nobody Mon Sep 22 10:49:56 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C54D1A1B5A for ; Mon, 22 Sep 2014 10:49:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.685 X-Spam-Level: X-Spam-Status: No, score=-2.685 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786] 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 H8iGU1Aew7Yn for ; Mon, 22 Sep 2014 10:49:51 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44A5E1A1AA3 for ; Mon, 22 Sep 2014 10:49:51 -0700 (PDT) Received: from us70uusmtp3.zam.alcatel-lucent.com (unknown [135.5.2.65]) by Websense Email Security Gateway with ESMTPS id 6D667754D3EF for ; Mon, 22 Sep 2014 17:49:47 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp3.zam.alcatel-lucent.com (GMO) with ESMTP id s8MHnor3024363 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 13:49:50 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 13:49:50 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: conformance & features in netconf Thread-Index: Ac/WjZq3fjHfgaHhQXSt5pX6tl8Hkg== Date: Mon, 22 Sep 2014 17:49:49 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5C948A05US70TWXCHMBA11z_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fcoks-QlhWZNShthlmj-Ytg1-FQ Subject: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 17:49:53 -0000 --_000_A125E53CE190A749957C19483DC79F9F5C948A05US70TWXCHMBA11z_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The discussion about Y16 triggered another question that I've never been cl= ear on. In theory when a server advertises a in the it is supp= osed to include a list of features in the hello. From section 5.6.4 of RF= C 6020: feature-parameter =3D "features=3D" feature *( "," feature ) NETCONF itself seems to be somewhat of an exception. RFC 6241 has module = ietf-netconf that is advertised in a hello like this: urn:ietf:params:netconf:base:1.1 But the RFC says that to advertise, for example, support for the startup da= tastore a server is supposed to advertise another capability (urn:ietf:para= ms:netconf:capability:startup:1.0). But the yang module has 'startup' as= a feature so doesn't that simply mean advertising the following ? urn:ietf:params:netconf:base:1.1?features=3Dstartup Are we supposed to do both ? Maybe this is just for historical reasons (Y= ANG came after NETCONF)... Regards, Jason --_000_A125E53CE190A749957C19483DC79F9F5C948A05US70TWXCHMBA11z_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The discussion about Y16 triggered another question that I’ve ne= ver been clear on.
 
In theory when a server advertises a <capability> in the <hel= lo> it is supposed to include a list of features in the hello. &nbs= p; From section 5.6.4 of RFC 6020:
feature-parameter   =3D "f= eatures=3D" feature *( "," feature )
 
NETCONF itself seems to be somewhat of an exception.   RFC 6= 241 has module ietf-netconf that is advertised in a hello like this:
=        <capability>
=          urn:ietf:params:netconf:ba= se:1.1
=        </capability>
 
But the RFC says that to advertise, for example, support for the start= up datastore a server is supposed to advertise another capability (urn:ietf= :params:netconf:capability:startup:1.0).    But the yang mod= ule has ‘startup’ as a feature so doesn’t that simply mean advertising the following ?
=        <capability>
=          urn:ietf:params:netconf:ba= se:1.1?features=3Dstartup
=        </capability>
 
Are we supposed to do both ?   Maybe this is just for histor= ical reasons (YANG came after NETCONF)…
 
Regards,
Jason
 
 --_000_A125E53CE190A749957C19483DC79F9F5C948A05US70TWXCHMBA11z_-- From nobody Mon Sep 22 11:15:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746FE1A1BA0 for ; Mon, 22 Sep 2014 11:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 SqUh5glN2MR4 for ; Mon, 22 Sep 2014 11:15:26 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B22B1A1B9F for ; Mon, 22 Sep 2014 11:15:26 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F0E358F3; Mon, 22 Sep 2014 20:15:24 +0200 (CEST) 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 pv5V5yEcdmEU; Mon, 22 Sep 2014 20:15:23 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 20:15:24 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E668620036; Mon, 22 Sep 2014 20:15:23 +0200 (CEST) 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 jC8lvhfuhl_g; Mon, 22 Sep 2014 20:15:23 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C4B1B20035; Mon, 22 Sep 2014 20:15:22 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF4272E85C12; Mon, 22 Sep 2014 20:15:21 +0200 (CEST) Date: Mon, 22 Sep 2014 20:15:21 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140922181521.GA19096@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/QhTjlhJ2zQgJt-JhxTGC7OT-WZ4 Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1 Y16 (optimized hello) and revisions X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:15:28 -0000 On Mon, Sep 22, 2014 at 05:31:40PM +0000, Sterne, Jason (Jason) wrote: > Hi all, > > I saw the minutes about Y16 from the Sept 17/18 interim meeting (and some of the followup discussions in the meeting minutes thread) but I didn't notice discussion about revisions. > > In Y16-02 how would indications of revisions work for an ? The 100+ modules in a hello can each have a revision indicated but once we aggregate them up into a single "set" does a new revision of one of the modules constitute a new set ? a new overall revision for the set ? > We did not work out the details but the general idea was that whenever things change, there would have to be a new identifier for the module set. And the silent assumption in NETCONF is that capability changes lead to a restart of a session. Not exactly sure at the moment how this would be dealt with in RESTCONF (perhaps the ID is carried in a header on every response message). /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 Sep 22 11:19:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 29D4F1A1BCA for ; Mon, 22 Sep 2014 11:19:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 vMKTdnknJBMf for ; Mon, 22 Sep 2014 11:19:36 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B895A1A1BCF for ; Mon, 22 Sep 2014 11:19:36 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6FC688F3; Mon, 22 Sep 2014 20:19:35 +0200 (CEST) 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 sulqss45XYdk; Mon, 22 Sep 2014 20:19:34 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 20:19:34 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8CFBA20035; Mon, 22 Sep 2014 20:19:34 +0200 (CEST) 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 piU6Xmiaie_Z; Mon, 22 Sep 2014 20:19:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8C3C20036; Mon, 22 Sep 2014 20:19:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id A6F942E85C61; Mon, 22 Sep 2014 20:19:33 +0200 (CEST) Date: Mon, 22 Sep 2014 20:19:33 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140922181933.GB19096@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7SZC_C_L21FH_D9X4qsDjkz5zVM Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:19:38 -0000 On Mon, Sep 22, 2014 at 05:49:49PM +0000, Sterne, Jason (Jason) wrote: > The discussion about Y16 triggered another question that I've never been clear on. > > In theory when a server advertises a in the it is supposed to include a list of features in the hello. From section 5.6.4 of RFC 6020: > feature-parameter = "features=" feature *( "," feature ) > > NETCONF itself seems to be somewhat of an exception. RFC 6241 has module ietf-netconf that is advertised in a hello like this: > > urn:ietf:params:netconf:base:1.1 > > > But the RFC says that to advertise, for example, support for the startup datastore a server is supposed to advertise another capability (urn:ietf:params:netconf:capability:startup:1.0). But the yang module has 'startup' as a feature so doesn't that simply mean advertising the following ? > > urn:ietf:params:netconf:base:1.1?features=startup > > > Are we supposed to do both ? Maybe this is just for historical reasons (YANG came after NETCONF)... Yes, historical reasons. /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 Sep 22 11:54:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1941A1AF4 for ; Mon, 22 Sep 2014 11:54:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 MFMqq-sAW6m1 for ; Mon, 22 Sep 2014 11:54:56 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D93C1A1B4B for ; Mon, 22 Sep 2014 11:54:56 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E01D6321; Mon, 22 Sep 2014 20:54:54 +0200 (CEST) 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 v6oZiEIoR4lo; Mon, 22 Sep 2014 20:54:53 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 20:54:53 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6EF820036; Mon, 22 Sep 2014 20:54:53 +0200 (CEST) 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 hRcNOfFed7-l; Mon, 22 Sep 2014 20:54:52 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 409C420035; Mon, 22 Sep 2014 20:54:51 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 3C44A2E85D65; Mon, 22 Sep 2014 20:54:49 +0200 (CEST) Date: Mon, 22 Sep 2014 20:54:49 +0200 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20140922185449.GA19274@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , "netmod@ietf.org" References: <20140919100829.GA22159@elstar.local> <20140922105447.GB17207@elstar.local> <20140922142030.GD18309@elstar.local> <8FD6D582-9E43-4652-87CE-2AFEDE02F51E@nic.cz> <20140922155621.GA18762@elstar.local> <08C07D1A-1056-4782-9E79-37BF8217A92A@nic.cz> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <08C07D1A-1056-4782-9E79-37BF8217A92A@nic.cz> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/7BruU9F_2CLO9BXr6GoIVhRMR3Q Cc: "netmod@ietf.org" Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 18:54:58 -0000 On Mon, Sep 22, 2014 at 06:33:02PM +0200, Ladislav Lhotka wrote: > > On 22 Sep 2014, at 17:56, Juergen Schoenwaelder wrote: > > > On Mon, Sep 22, 2014 at 05:43:56PM +0200, Ladislav Lhotka wrote: > >> > >> On 22 Sep 2014, at 16:20, Juergen Schoenwaelder wrote: > >> > >>> On Mon, Sep 22, 2014 at 04:03:08PM +0200, Ladislav Lhotka wrote: > >>>> > >>>> I didn’t skip that section, and that’s why I raised this issue. > >>>> Unconditional nodes are not enough for full conformance - if > >>>> they were, why bother with features? > >>> > >>> This is why I said 'full' is a misnomer. I have changed the minutes as > >>> follows: > >>> > >>> Index: netmod-2014-09-18-minutes.txt > >>> =================================================================== > >>> --- netmod-2014-09-18-minutes.txt (revision 72) > >>> +++ netmod-2014-09-18-minutes.txt (working copy) > >>> @@ -162,8 +169,10 @@ > >>> Proposal: Keep features as the unit of conformance in YANG 1.1 but > >>> consider certain improvements: > >>> - indicate in the module advertisement data model the conformance > >>> - associated with a module (full = "all base data nodes, rpcs, > >>> - notifications", ) > >>> + associated with a module (base = "all unconditional data nodes, > >>> + rpcs, notifications", import = "only extensions, typedefs, > >>> + groupings, identities and features that are defined at the top > >>> + level of the module") > >>> - support import by revision >= N OR remove import by revision > >>> (which is mostly important for groupings that get modified) > >>> - allow adding/removing features/if-features in revised YANG > >>> > >>> Does this resolve this issue with the minutes? > >> > >> I don’t think so. What is the difference between full and base wrt to advertised features? > >> > > > > It is unclear. It was unclear during the meeting. The purpose of > > minutes is to reflect the meeting. I happy to change base back to > > full. ;-) > > Actually, it might be better to delete the text in parentheses and leave it to the draft to define these terms properly. > These are minutes - they do not define anything. I will add 'e.g.,' in front of base and I hope this resolves this issue with the minutes. NEW: - indicate in the module advertisement data model the conformance associated with a module (e.g., base = "all unconditional data nodes, rpcs, notifications", import = "only extensions, typedefs, groupings, identities and features that are defined at the top level of the module") /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 Sep 22 12:21:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 424121A1BAA for ; Mon, 22 Sep 2014 12:20:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 N6kWg-y-aMyj for ; Mon, 22 Sep 2014 12:20:56 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389721A1BE4 for ; Mon, 22 Sep 2014 12:20:53 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 2E75E9808A929; Mon, 22 Sep 2014 19:20:49 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8MJKpth013661 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 15:20:52 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 15:20:52 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] conformance & features in netconf Thread-Index: Ac/WjZq3fjHfgaHhQXSt5pX6tl8HkgAJa5WAAAaOjaA= Date: Mon, 22 Sep 2014 19:20:51 +0000 Message-ID: References: <20140922181933.GB19096@elstar.local> In-Reply-To: <20140922181933.GB19096@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gCSZPHVaKkX74cqPMh9IjO6e8-o Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:20:58 -0000 Thx. I just noticed that the namespace defined in the RFC 6241 ietf-netconf modu= le is base:1.0. I didn't expect that. I'm a little puzzled as to the ad= vertisement that should be made in the hello in an example where a server s= upports both 1.0 and 1.1 and both validate:1.0 and 1.1 for example. Is th= e following correct ? In theory there is no module called ietf-netconf with a namespace base:1.1 = so it looks somewhat strange to have that combination and a revision and fe= atures listed against it. urn:ietf:params:netconf:base:1.0?module=3Dietf-netconf&revision=3D2011-= 06-01&features=3Dwritable-running,validate urn:ietf:params:netconf:base:1.1?module=3Dietf-netconf&revision=3D2011-= 06-01&features=3Dwritable-running,validate urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:validate:1.0 urn:ietf:params:netconf:capability:startup:1.0 Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 2:20 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] conformance & features in netconf On Mon, Sep 22, 2014 at 05:49:49PM +0000, Sterne, Jason (Jason) wrote: > The discussion about Y16 triggered another question that I've never been = clear on. >=20 > In theory when a server advertises a in the it is su= pposed to include a list of features in the hello. From section 5.6.4 of = RFC 6020: > feature-parameter =3D "features=3D" feature *( "," feature ) >=20 > NETCONF itself seems to be somewhat of an exception. RFC 6241 has modul= e ietf-netconf that is advertised in a hello like this: > > urn:ietf:params:netconf:base:1.1 > >=20 > But the RFC says that to advertise, for example, support for the startup = datastore a server is supposed to advertise another capability (urn:ietf:pa= rams:netconf:capability:startup:1.0). But the yang module has 'startup' = as a feature so doesn't that simply mean advertising the following ? > > urn:ietf:params:netconf:base:1.1?features=3Dstartup > >=20 > Are we supposed to do both ? Maybe this is just for historical reasons = (YANG came after NETCONF)... Yes, historical reasons. /js --=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 Mon Sep 22 12:25:02 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16A991A1ACA for ; Mon, 22 Sep 2014 12:25:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 DlQOzOcQSFco for ; Mon, 22 Sep 2014 12:24:58 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68AFE1A1B4F for ; Mon, 22 Sep 2014 12:24:58 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 767B05CB450D8; Mon, 22 Sep 2014 19:24:54 +0000 (GMT) Received: from US70UWXCHHUB01.zam.alcatel-lucent.com (us70uwxchhub01.zam.alcatel-lucent.com [135.5.2.48]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s8MJOuTo003121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 15:24:56 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70UWXCHHUB01.zam.alcatel-lucent.com ([135.5.2.48]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 15:24:56 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] conformance & features in netconf Thread-Index: Ac/WjZq3fjHfgaHhQXSt5pX6tl8HkgAJa5WAAAaOjaAADK3RoA== Date: Mon, 22 Sep 2014 19:24:55 +0000 Message-ID: References: <20140922181933.GB19096@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/N3o-0Z-8eVc_-JSbgWks5K3qq_8 Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:25:01 -0000 I meant 'writeable-running' in that last capability instead of 'startup'. -----Original Message----- From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Sterne, Jason (J= ason) Sent: Monday, September 22, 2014 3:21 PM To: Juergen Schoenwaelder Cc: netmod@ietf.org Subject: Re: [netmod] conformance & features in netconf Thx. I just noticed that the namespace defined in the RFC 6241 ietf-netconf modu= le is base:1.0. I didn't expect that. I'm a little puzzled as to the ad= vertisement that should be made in the hello in an example where a server s= upports both 1.0 and 1.1 and both validate:1.0 and 1.1 for example. Is th= e following correct ? In theory there is no module called ietf-netconf with a namespace base:1.1 = so it looks somewhat strange to have that combination and a revision and fe= atures listed against it. urn:ietf:params:netconf:base:1.0?module=3Dietf-netconf&revision=3D2011-= 06-01&features=3Dwritable-running,validate urn:ietf:params:netconf:base:1.1?module=3Dietf-netconf&revision=3D2011-= 06-01&features=3Dwritable-running,validate urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:validate:1.0 urn:ietf:params:netconf:capability:startup:1.0 Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 2:20 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] conformance & features in netconf On Mon, Sep 22, 2014 at 05:49:49PM +0000, Sterne, Jason (Jason) wrote: > The discussion about Y16 triggered another question that I've never been = clear on. >=20 > In theory when a server advertises a in the it is su= pposed to include a list of features in the hello. From section 5.6.4 of = RFC 6020: > feature-parameter =3D "features=3D" feature *( "," feature ) >=20 > NETCONF itself seems to be somewhat of an exception. RFC 6241 has modul= e ietf-netconf that is advertised in a hello like this: > > urn:ietf:params:netconf:base:1.1 > >=20 > But the RFC says that to advertise, for example, support for the startup = datastore a server is supposed to advertise another capability (urn:ietf:pa= rams:netconf:capability:startup:1.0). But the yang module has 'startup' = as a feature so doesn't that simply mean advertising the following ? > > urn:ietf:params:netconf:base:1.1?features=3Dstartup > >=20 > Are we supposed to do both ? Maybe this is just for historical reasons = (YANG came after NETCONF)... Yes, historical reasons. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod From nobody Mon Sep 22 12:55:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44E811A1B0E for ; Mon, 22 Sep 2014 12:55:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 kArwtPMDj32p for ; Mon, 22 Sep 2014 12:55:13 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 155D21A1B58 for ; Mon, 22 Sep 2014 12:55:13 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id A3B5BC296; Mon, 22 Sep 2014 15:55:12 -0400 (EDT) Date: Mon, 22 Sep 2014 15:55:12 -0400 From: Jeffrey Haas To: netmod@ietf.org Message-ID: <20140922195512.GF6550@pfrc> References: <20140919100829.GA22159@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140919100829.GA22159@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/2lb0HyPCUW_jon1efV4Kwf7Crx4 Subject: Re: [netmod] draft minutes yang 1.1 interim meeting new york X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 19:55:16 -0000 On Fri, Sep 19, 2014 at 12:08:29PM +0200, Juergen Schoenwaelder wrote: > here are the draft minutes - please let me know what needs to be > fixed. > > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt For I2RS purposes, close enough. Thank you for taking the minutes. My action item is to write up a more specific set of discussion minutes for I2RS and derive our next actions from WG discussion. -- Jeff From nobody Mon Sep 22 13:01:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 362231A1BAA; Mon, 22 Sep 2014 13:01:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 1u7D3kTQf5DF; Mon, 22 Sep 2014 13:01:55 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 348DC1A1B63; Mon, 22 Sep 2014 13:01:55 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 00E91C296; Mon, 22 Sep 2014 16:01:54 -0400 (EDT) Date: Mon, 22 Sep 2014 16:01:54 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140922200154.GG6550@pfrc> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <004601cfd361$d2cbe520$7863af60$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5KdVth1BWqWrPdFKW2zB6GE6410 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:01:56 -0000 Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff From nobody Mon Sep 22 13:22:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 630DA1A01D8 for ; Mon, 22 Sep 2014 13:22:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 d3wR8zbcIQfe for ; Mon, 22 Sep 2014 13:21:59 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37A151A00AD for ; Mon, 22 Sep 2014 13:21:59 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 014FB8E8; Mon, 22 Sep 2014 22:21:58 +0200 (CEST) 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 ZrO49J18cNtO; Mon, 22 Sep 2014 22:21:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Sep 2014 22:21:57 +0200 (CEST) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id E08C720036; Mon, 22 Sep 2014 22:21:56 +0200 (CEST) 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 zED3yVZ5ai2c; Mon, 22 Sep 2014 22:21:55 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2909820035; Mon, 22 Sep 2014 22:21:55 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E8B5E2E85E59; Mon, 22 Sep 2014 22:21:54 +0200 (CEST) Date: Mon, 22 Sep 2014 22:21:54 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140922202154.GB19448@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: <20140922181933.GB19096@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/k_Dvv3pkPfh-DEtJnIWbl8JkzTQ Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:22:01 -0000 Do not confuse protcol capabilities, data model announcements and namespaces. Since the namespace is parsed before any protocol capabilities, it turns out we will never change the base:1.0 in the namespace. Hence, for protocol version negotiation, the announced protocol capability matters. /js On Mon, Sep 22, 2014 at 07:20:51PM +0000, Sterne, Jason (Jason) wrote: > Thx. > > I just noticed that the namespace defined in the RFC 6241 ietf-netconf module is base:1.0. I didn't expect that. I'm a little puzzled as to the advertisement that should be made in the hello in an example where a server supports both 1.0 and 1.1 and both validate:1.0 and 1.1 for example. Is the following correct ? > > In theory there is no module called ietf-netconf with a namespace base:1.1 so it looks somewhat strange to have that combination and a revision and features listed against it. > > > urn:ietf:params:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&features=writable-running,validate > > > urn:ietf:params:netconf:base:1.1?module=ietf-netconf&revision=2011-06-01&features=writable-running,validate > > > urn:ietf:params:netconf:capability:validate:1.1 > > > urn:ietf:params:netconf:capability:validate:1.0 > > > urn:ietf:params:netconf:capability:startup:1.0 > > > Jason > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, September 22, 2014 2:20 PM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] conformance & features in netconf > > On Mon, Sep 22, 2014 at 05:49:49PM +0000, Sterne, Jason (Jason) wrote: > > The discussion about Y16 triggered another question that I've never been clear on. > > > > In theory when a server advertises a in the it is supposed to include a list of features in the hello. From section 5.6.4 of RFC 6020: > > feature-parameter = "features=" feature *( "," feature ) > > > > NETCONF itself seems to be somewhat of an exception. RFC 6241 has module ietf-netconf that is advertised in a hello like this: > > > > urn:ietf:params:netconf:base:1.1 > > > > > > But the RFC says that to advertise, for example, support for the startup datastore a server is supposed to advertise another capability (urn:ietf:params:netconf:capability:startup:1.0). But the yang module has 'startup' as a feature so doesn't that simply mean advertising the following ? > > > > urn:ietf:params:netconf:base:1.1?features=startup > > > > > > Are we supposed to do both ? Maybe this is just for historical reasons (YANG came after NETCONF)... > > Yes, historical reasons. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 -- 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 Sep 22 13:48:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 948D11A1AC6 for ; Mon, 22 Sep 2014 13:48:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 Kbucrh1Kmzse for ; Mon, 22 Sep 2014 13:48:11 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B675A1A1AC1 for ; Mon, 22 Sep 2014 13:48:11 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id AE985561BEB6; Mon, 22 Sep 2014 20:48:08 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s8MKmAYT023575 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Sep 2014 16:48:10 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 16:48:10 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] conformance & features in netconf Thread-Index: Ac/WjZq3fjHfgaHhQXSt5pX6tl8HkgAJa5WAAAaOjaD//+26AIAAP6Lw Date: Mon, 22 Sep 2014 20:48:10 +0000 Message-ID: References: <20140922181933.GB19096@elstar.local> <20140922202154.GB19448@elstar.local> In-Reply-To: <20140922202154.GB19448@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UwsVVgDoHrlY_ZkCsXvK7urFMok Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 20:48:15 -0000 Hi Juergen, Yep - I am mixing those together but they seem mixed in the RFCs (at least = for base:1.0).=20 RFC 6020 says supported yang modules (which I'm assuming includes ietf-netc= onf) are supposed to have their namespace listed in a in the = , along with 'features=3D', revision=3D', etc. =20 At the same time RFC 6241 says to list base:1.x as entries. = =20 But the base:1.0 URN (used to indicate a protocol version) is the same URN = as the ietf-netconf namespace (used to indicate a data model). Sorry if I'm being dense here. Maybe if you could let me know how the hel= lo in my example should look (if I have it wrong) I'll understand what you = mean. Should I be completely separating the protocol version capabilities= from the ietf-netconf module support like this ? (strange to have the bas= e:1.0 URN listed twice though): urn:ietf:params:netconf:base:1.0 =20 urn:ietf:params:netconf:base:1.1 urn:ietf:params:netconf:capability:validate:1.1 urn:ietf:params:netconf:capability:validate:1.0 urn:ietf:params:netconf:capability:writable-running:1.0 urn:ietf:params:netconf:base:1.0?module=3Dietf-netconf&revision=3D2011-= 06-01&features=3Dwritable-running,validate Regards, Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Monday, September 22, 2014 4:22 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] conformance & features in netconf Do not confuse protcol capabilities, data model announcements and namespace= s. Since the namespace is parsed before any protocol capabilities, it turns= out we will never change the base:1.0 in the namespace. Hence, for protoco= l version negotiation, the announced protocol capability matters. /js On Mon, Sep 22, 2014 at 07:20:51PM +0000, Sterne, Jason (Jason) wrote: > Thx. >=20 > I just noticed that the namespace defined in the RFC 6241 ietf-netconf mo= dule is base:1.0. I didn't expect that. I'm a little puzzled as to the = advertisement that should be made in the hello in an example where a server= supports both 1.0 and 1.1 and both validate:1.0 and 1.1 for example. Is = the following correct ? >=20 > In theory there is no module called ietf-netconf with a namespace base:1.= 1 so it looks somewhat strange to have that combination and a revision and = features listed against it. >=20 > > urn:ietf:params:netconf:base:1.0?module=3Dietf-netconf&revision=3D201= 1 > -06-01&features=3Dwritable-running,validate > > > urn:ietf:params:netconf:base:1.1?module=3Dietf-netconf&revision=3D201= 1 > -06-01&features=3Dwritable-running,validate > > > urn:ietf:params:netconf:capability:validate:1.1 > > > urn:ietf:params:netconf:capability:validate:1.0 > > > urn:ietf:params:netconf:capability:startup:1.0 > >=20 > Jason >=20 > -----Original Message----- > From: Juergen Schoenwaelder=20 > [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Monday, September 22, 2014 2:20 PM > To: Sterne, Jason (Jason) > Cc: netmod@ietf.org > Subject: Re: [netmod] conformance & features in netconf >=20 > On Mon, Sep 22, 2014 at 05:49:49PM +0000, Sterne, Jason (Jason) wrote: > > The discussion about Y16 triggered another question that I've never bee= n clear on. > >=20 > > In theory when a server advertises a in the it is = supposed to include a list of features in the hello. From section 5.6.4 o= f RFC 6020: > > feature-parameter =3D "features=3D" feature *( "," feature ) > >=20 > > NETCONF itself seems to be somewhat of an exception. RFC 6241 has mod= ule ietf-netconf that is advertised in a hello like this: > > > > urn:ietf:params:netconf:base:1.1 > > > >=20 > > But the RFC says that to advertise, for example, support for the startu= p datastore a server is supposed to advertise another capability (urn:ietf:= params:netconf:capability:startup:1.0). But the yang module has 'startup= ' as a feature so doesn't that simply mean advertising the following ? > > > > urn:ietf:params:netconf:base:1.1?features=3Dstartup > > > >=20 > > Are we supposed to do both ? Maybe this is just for historical reason= s (YANG came after NETCONF)... >=20 > Yes, historical reasons. >=20 > /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 --=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 Mon Sep 22 14:05:57 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D32D1A6EFE; Mon, 22 Sep 2014 14:05:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.455 X-Spam-Level: X-Spam-Status: No, score=-0.455 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 fcCCo918-beL; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 675401A6EFB; Mon, 22 Sep 2014 14:05:47 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id F0E53C3DE; Mon, 22 Sep 2014 17:05:46 -0400 (EDT) Date: Mon, 22 Sep 2014 17:05:46 -0400 From: Jeffrey Haas To: i2rs@ietf.org, netmod@ietf.org Message-ID: <20140922210546.GA5676@pfrc> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5Qw2MWnOlIim2-C8P_TLaRl7JZE Subject: [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:05:49 -0000 [BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff From nobody Mon Sep 22 14:10:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 43F821A6EFB for ; Mon, 22 Sep 2014 14:09:56 -0700 (PDT) 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 86USkvXhf99k for ; Mon, 22 Sep 2014 14:09:54 -0700 (PDT) Received: from mail-qg0-f47.google.com (mail-qg0-f47.google.com [209.85.192.47]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C9E81A6EE7 for ; Mon, 22 Sep 2014 14:09:53 -0700 (PDT) Received: by mail-qg0-f47.google.com with SMTP id z107so3477010qgd.20 for ; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) 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=oljvjbs9hqp2AZBnwVEa+slVKGsQIiDVRcGOckIRDCk=; b=bvaQLfaIMRV/QU15A88c/prbyt20AECuHO4eOo1eQvsEXOklBJmL+AngBUueT7qJmS YsMX17Ct9UV2/hZQizIAVVhcWhM32cG0pSD88eoxXmVx8PkBtqveOTaRfx7H/49EeteX 4T6pgEP8/a3Bdf7RZeA5cwjMnei0+oyaU0XqW6tsjdUfMAkEOsWprRdUZkWnBvfWeTGo 4yVmEcRHHSUUFxbpDhr+8v4l96VRuTxyWwDJRwF6M/3v9CqrZb/v6iiRNLRnRLPEFbux DaMhKkuQy8mU5cGcfXozbg1ZhFydhT3IeWuCRstGI8+f0oEpEGCIncw+RXfOw8IGlzCJ BdYA== X-Gm-Message-State: ALoCoQk7f8WGD//NF6X/9SxDgvxlZLp/+IC1Lup85Nk2PJWw1jK+I6aLKqdag17pZVvGntXXVVQc MIME-Version: 1.0 X-Received: by 10.140.21.177 with SMTP id 46mr12848351qgl.90.1411420192746; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Mon, 22 Sep 2014 14:09:52 -0700 (PDT) In-Reply-To: <20140922200154.GG6550@pfrc> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> Date: Mon, 22 Sep 2014 14:09:52 -0700 Message-ID: From: Andy Bierman To: Jeffrey Haas Content-Type: multipart/alternative; boundary=001a11c1398637c9db0503addf6f Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/L2EC2WVEZqv2JEQ3XkeoX3ANfB4 Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 21:09:56 -0000 --001a11c1398637c9db0503addf6f Content-Type: text/plain; charset=ISO-8859-1 On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: > Sue, > > On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > > Where does the priority live ??? in I2RS or in config module or in BGP > > routing model? How does this work with the three datastore proposals: 1) > > separate empheral data store, 2) configuration state in existing > datastore > > tagged by model as empheral, and 3) whole data stores tagged empheral, > > config, or both. Is the routing code that sets the priority and handles > > the rollback? > > Priority received quite a bit of discussion during the netmod interim. The > reason why it was not explicitly spelled out in my first version of the > draft is that the implementation would vary considerably depending on which > answer netmod guided us toward for how we get ephemeral state. > > The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my > meeting minutes. If you don't believe I've adequately addressed it in that > writeup (coming shortly), please let me know and we'll resume. > > -- Jeff > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a11c1398637c9db0503addf6f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:
Sue,

On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> Where does the priority live ??? in I2RS or in config module or in BGP=
> routing model?=A0 How does this work with the three datastore proposal= s: 1)
> separate empheral data store, 2) configuration state in existing datas= tore
> tagged by model as empheral, and 3) whole data stores tagged empheral,=
> config, or both.=A0 =A0Is the routing code that sets the priority and = handles
> the rollback?

Priority received quite a bit of discussion during the netmod interim.=A0 T= he
reason why it was not explicitly spelled out in my first version of the
draft is that the implementation would vary considerably depending on which=
answer netmod guided us toward for how we get ephemeral state.


The rationale for the priority-based &= quot;first one wins" access control model is still unclear
t= o me.

A simple NACM extension to add group priorit= y has already been proposed,
which seems fine to me. So is this h= ow it works?

=A0 #1) NACM data rules can be used t= o grant or deny access to specific I2RS data nodes.
=A0 =A0 =A0 = =A0 Steps #2 and #3 assume access is granted here

= =A0 #2) the I2RS agent maintains the owner and owner priority of the data s= omehow.
=A0 =A0 =A0 =A0 =A0The priority is configured in each NAC= M group for enforcement purposes. =A0
=A0 =A0 =A0 =A0 =A0This dat= a used to decide if existing data can be overwritten by a different client.=
=A0 =A0 =A0 =A0 =A0(I think highest priority wins if target data= already exists)
=A0
=A0 #3) if both writer and cur= rent owner have the same priority, then current owner wins

Breaking ties by first-one-wins seems just as arbitrary as last-on= e-wins.=A0 It seems to be based on
the order that the networking = devices will boot.=A0 Can somebody explain why it is better?

=
I am still unclear how the operator know the exact data each cli= ent
will want to use, and how they determine the meaningful overl= ap
(e.g. what will break for client B if client A causes 2 of its= 7 entries to be deleted?)

This information seems = to be required in order to configure the tie-breaking priorities properly,<= /div>
but I think the intent is that the operator will just know what I= 2RS clients are installed
and know how to prioritize them, just b= ased on their purpose.



It turned out they gave us a fourth option.=A0 I'll be summarizing that= in my
meeting minutes.=A0 If you don't believe I've adequately addressed = it in that
writeup (coming shortly), please let me know and we'll resume.

-- Jeff



Andy
=A0
_______________________________________________
netmod mailing list
netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod

--001a11c1398637c9db0503addf6f-- From nobody Mon Sep 22 15:02:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6293F1A1AA1 for ; Mon, 22 Sep 2014 15:02:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 TdO6FPpo5aUo for ; Mon, 22 Sep 2014 15:02:49 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpswa-esg-01.alcatel-lucent.com [135.245.18.29]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C82871A036E for ; Mon, 22 Sep 2014 15:02:48 -0700 (PDT) Received: from us70tusmtp1.zam.alcatel-lucent.com (unknown [135.5.2.63]) by Websense Email Security Gateway with ESMTPS id 341A7AA2ADB98 for ; Mon, 22 Sep 2014 22:02:44 +0000 (GMT) Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id s8MM2lr5007169 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Mon, 22 Sep 2014 18:02:47 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.03.0195.001; Mon, 22 Sep 2014 18:02:47 -0400 From: "Sterne, Jason (Jason)" To: "netmod@ietf.org" Thread-Topic: clear-text vs hashed values Thread-Index: AQHP1rDxFUH0XeFbYE29Cu6WJM+DnA== Date: Mon, 22 Sep 2014 22:02:47 +0000 Message-ID: References: <20140909.224005.02423221.mbj@tail-f.com> In-Reply-To: <20140909.224005.02423221.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xuWIgEav8DpRA3lBaaSVQrECzIU Subject: [netmod] clear-text vs hashed values X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Sep 2014 22:02:51 -0000 Starting a new thread for this clear-text vs hash issue (mentioned in Y12). In some cases there is a need for an operator to be able to enter a clear-t= ext value but can never read it back as clear text (only as a hash). =20 If the operator can configure a clear-text value, but can only read back a = hashed value, are the write and the read really to/from the same leaf in th= e datastore ? Maybe some new attribute of a leaf that indicates you won't read back what = you wrote ? There may also be a need in some cases to allow the hashed value to be ente= red (i.e. copying from one place to another without knowing the underlying = clear-text value). What semantics could we use in the to sa= y we are writing a hashed value (so don't re-hash) ? I'm assuming this issue is outside the scope of Yang 1.1 (i.e. won't be sol= ved as part of Y12) but I'm still interested in any thoughts on solving thi= s at some point.=20 Jason -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Tuesday, September 09, 2014 4:40 PM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1 Y12 (initialized-by-system) Hi, "Sterne, Jason (Jason)" wrote: > Hi all, >=20 > I see in the issues list that initialized-by-system is intended to be=20 > applicable to leafs and leaf-lists. >=20 > Can someone give an example of how that might look for a leaf-list ? =20 > Is it just to indicate that there may be a system initialized member=20 > of the leaf-list ? Right; when the parent node is created, the system initializes one or more = members of the leaf-list. > Was there any previous discussion about having the=20 > initialized-by-system concept somehow applying to lists (i.e.=20 > indicating that the system might initialize some list instances/entries)? IIRC everyone agreed that this was not needed. Unclear use cases, and uncl= ear how it would work. > For example -> the network element > (server) may automatically add an interface called "system" or a user=20 > called "admin" during startup. This is already possible today. Most systems come with some kind of factor= y default config. When a client connects the very first time, it cannot as= sume that the config is empty. > The initialized-by-system could perhaps be indicated at the list level=20 > to at least indicate that there may be system initialized list entries=20 > (i.e. to prompt the client to to see them). >=20 > I'm also interested in the note that says "A similar issue: passwd of=20 > type crypt-hash.". I'd like to see what the intended use case is=20 > behind that sentence (I'm hoping it might help me with an issue we=20 > have that sounds similar). If a clear-text value is written to a node of type crypt-hash, the server c= alculates the hash and stores the hash value instead of the clear text valu= e. This is not the same as initialized-by system, but similar. /martin From nobody Mon Sep 22 17:57:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D75D91A6F88 for ; Mon, 22 Sep 2014 17:57:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.036 X-Spam-Level: X-Spam-Status: No, score=-99.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.786, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 oFbIj6QB7GSB for ; Mon, 22 Sep 2014 17:57:34 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by ietfa.amsl.com (Postfix) with ESMTP id D1F0E1A038D for ; Mon, 22 Sep 2014 17:57:33 -0700 (PDT) Received: from mse02.zte.com.cn (unknown [10.30.3.21]) by Websense Email Security Gateway with ESMTPS id C51A71265A88; Tue, 23 Sep 2014 08:57:25 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse02.zte.com.cn with ESMTP id s8N0vP6t020360; Tue, 23 Sep 2014 08:57:25 +0800 (GMT-8) (envelope-from feng.chong33@zte.com.cn) In-Reply-To: <20140922123006.GE17653@elstar.local> References: <20140919100829.GA22159@elstar.local> <20140922123006.GE17653@elstar.local> To: Juergen Schoenwaelder MIME-Version: 1.0 X-KeepSent: 38A575BE:8AAE8A96-48257D5C:0004C3C7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.3 September 15, 2011 Message-ID: From: feng.chong33@zte.com.cn Date: Tue, 23 Sep 2014 08:57:26 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 8.5.3FP6|November 21, 2013) at 2014-09-23 08:57:10, Serialize complete at 2014-09-23 08:57:10 Content-Type: multipart/alternative; boundary="=_alternative 0005421348257D5C_=" X-MAIL: mse02.zte.com.cn s8N0vP6t020360 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UIPmeQram1rQYkAAi70TSNpuJ6w Cc: netmod@ietf.org Subject: [netmod] =?gb2312?b?tPC4tDogUmU6ICBkcmFmdCBtaW51dGVzIHlhbmcgMS4x?= =?gb2312?b?IGludGVyaW0gbWVldGluZyBuZXcgeW9yaw==?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 00:57:39 -0000 This is a multipart message in MIME format. --=_alternative 0005421348257D5C_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+INC009ogDQoyMDE0LTA5LTIyIDIwOjMwOjA2Og0KDQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPiANCj4gMjAxNC0wOS0yMiAy MDozMA0KPiANCj4gx+u08Li0ILj4DQo+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPg0KPiANCj4gytW8/sjLDQo+IA0KPiBmZW5nLmNo b25nMzNAenRlLmNvbS5jbiwgDQo+IA0KPiCzrcvNDQo+IA0KPiBuZXRtb2RAaWV0Zi5vcmcNCj4g DQo+INb3zOINCj4gDQo+IFJlOiBbbmV0bW9kXSBkcmFmdCBtaW51dGVzIHlhbmcgMS4xIGludGVy aW0gbWVldGluZyBuZXcgeW9yaw0KPiANCj4gT24gTW9uLCBTZXAgMjIsIDIwMTQgYXQgMDk6MTM6 MjhBTSArMDgwMCwgZmVuZy5jaG9uZzMzQHp0ZS5jb20uY24gd3JvdGU6DQo+ID4gKiBZMTYgbW9k dWxlIGFkdmVydGlzZW1lbnQgb3B0aW1pemF0aW9uIC8gWTU0IHJlbW92ZSB0aGUgYWR2ZXJ0aXNl bWVudCANCm9mIA0KPiA+IGNvbmZvcm1hbmNlIGluZm9ybWF0aW9uIGluIE5FVENPTkYgaGVsbG8g bWVzc2FnZQ0KPiA+IA0KPiA+ICAgLSBNQjogWUFORyAxLjAgbW9kdWxlcyB3aWxsIGNvbnRpbnVl IHRvIGJlIGFkdmVydGlzZWQgaW4gaGVsbG8NCj4gPiAgICAgbWVzc2FnZXMgYnV0IGZvciBZQU5H IDEuMSBtb2R1bGVzLCB3ZSBtYXkgYWR2ZXJ0aXNlIG9ubHkgYSBtb2R1bGUNCj4gPiAgICAgc2V0 ICdoYXNoJy4NCj4gPiANCj4gPiAgIC0gTUI6IFdlIHNob3VsZCBwcm92aWRlIGFjY2VzcyB0byB0 aGUgbW9kdWxlIGxpc3QgaW4gdGhlIHNhbWUgd2F5DQo+ID4gICAgIGZvciBORVRDT05GIGFuZCBS RVNUQ09ORi4NCj4gPiANCj4gPiAgIC0gREI6IFdlIG1heSBoYXZlIHRvIHN1cHBvcnQgZGlmZmVy ZW50IG1vZHVsZSBzZXRzIG9uDQo+ID4gICAgIE5FVENPTkYvUkVTVENPTkYgb3IgZGlmZmVyZW50 IG1vZHVsZSBzZXRzIGZvciBkaWZmZXJlbnQgdXNlcnMgb3INCj4gPiAgICAgZGlmZmVyZW50IG1v ZHVsZSBzZXRzIGZvciBkaWZmZXJlbnQgZGF0YXN0b3Jlcy4NCj4gPiANCj4gPiAgIC0gTUI6IFNp bmNlIGhlbGxvIGJhc2ljYWxseSB3b3JrcywgaXMgdGhpcyByZWFsbHkgYSBwcm9ibGVtIHRvIGZp eCwNCj4gPiAgICAgZ2l2ZW4gdGhlIG92ZXJhbGwgb3ZlcmhlYWQgb2YgdGhlIHNlY3VyZSB0cmFu c3BvcnRzIE5DIGlzIHJ1bm5pbmcNCj4gPiAgICAgb3Zlcj8gUkMgZG9lcyBub3QgaGF2ZSB0aGUg ZXF1aXZhbGVudCBvZiBoZWxsby4NCj4gPiANCj4gPiAgIC0gSlM6IFRoZSBoZWxsbyBtZXNzYWdl IHNpemUgaXMgbW9zdGx5IGFuIGlzc3VlIGZvciBzaG9ydCBsaXZlZA0KPiA+ICAgICBzZXNzaW9u cy4NCj4gPiAgIC0gSkg6IE9yIGZvciBzZXNzaW9ucyBydW5uaW5nIG92ZXIgbGlua3Mgd2l0aCBu b3RpY2VhYmxlIHBhY2tldCBsb3NzDQo+ID4gICAgIHJhdGVzLg0KPiA+ICAgLSBEQjogVGhpcyBt YXkgYmUgYW4gaXNzdWUgZm9yIGVOb2RlQnMuDQo+ID4gDQo+ID4gICBQcm9wb3NhbDogV2UgZG8g bm90IHNlbmQgWUFORyAxLjEgbW9kdWxlIFVSSXMgYnV0IGluc3RlYWQgd2Ugc2VuZCBhDQo+ID4g ICBoYXNoIG9yIGlkZW50aWZpZXIuIA0KPiA+IA0KPiA+IA0KPiA+IFtmcmFua106IEkgdGhpbmsg aXQncyBlbm91Z2ggdGhhdCBzZXJ2ZXIgb25seSBzZW5kIGEgaGFzaCB0byBpbmRpY2F0ZSANCmFs bCANCj4gPiBtb2R1bGVzJyANCj4gPiBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbi4NCj4gDQo+IFRo aXMgaXMgZXhhY3RseSB3aGF0IHdhcyBkaXNjdXNzZWQuIEJ1dCB0aGVuIHdlIGFsc28gZGlzY3Vz c2VkIHRoYXQgaXQNCj4gaXMgbm90IHJlYWxseSBhIGhhc2ggYnV0IG1vcmUgb2YgYW4gaWRlbnRp ZmllciBmb3IgdGhlIGdpdmVuIG1vZHVsZQ0KPiBzZXQuIFdlIGFsc28gZGlzY3Vzc2VkIHdoYXQg dGhlIHNjb3BlIG9mIHN1Y2ggYW4gaWRlbnRpZmllciB3b3VsZCBiZS4NCg0KSSBhZ3JlZSBpdCdz IG5vdCByZWFsbHkgYSBoYXNoLCBpdCBpcyBhIGlkZW50aWZpZXIuIEJ1dCBJIHRoaW5rIHRoaXMg DQppZGVudGlmaWVyDQpzaG91bGQgYmUgb3BlbiB0byB2ZW5kb3IgdG8gZGVmaW5lLiBJIHN1Z2dl c3QgV0cgdXNlIGNvbmZvcm1hbmNlLUlEIA0KbWVudGlvbmVkIGluIA0KbXkgZHJhZnQgYXMgdGVy bWlub2xvZ3kgZm9yIHRoaXMgaWRlbnRpZmllci4NCg0KPiANCj4gPiAgIFByb3Bvc2FsOiBXZSBj cmVhdGUgYSBuZXcgaWV0Zi15YW5nLWFkdmVydGlzZW1lbnQgbW9kdWxlIHRoYXQNCj4gPiAgIGRl dGFpbHMgYSBkYXRhIG1vZGVsIGZvciB0aGUgYWR2ZXJ0aXNlbWVudCBvZiBZQU5HIGRhdGEgbW9k ZWxzICh0aGF0DQo+ID4gICB3b3JrcyBpbiB0aGUgc2FtZSB3YXkgZm9yIE5FVENPTkYgYW5kIFJF U1RDT05GKS4NCj4gPiANCj4gPiBbZnJhbmtdOiBJIGhhdmUgY3JlYXRlZCBhIG1vZHVsZSBjYWxs ZWQgaWV0Zi1uZXRjb25mLWNvbmZvcm1hbmNlIHRvIA0KPiA+IHN1cHBvcnQNCj4gPiBjbGllbnQg dG8gZ2V0IHNlcnZlcidzIGRldGFpbCBjb25mb3JtYW5jZSBpbmZvcm1hdGlvbi4NCj4gPiANCj4g PiBwbGVhc2Ugc2VlIG15IG5ldyBkcmFmdDoNCj4gPiBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWZyYW5rLW5ldGNvbmYtY29uZm9ybWFuY2UvDQo+ID4gDQo+IA0KPiBXZSBh cmUgYXdhcmUgb2YgdGhlIEktRCBhbmQgdGhlcmUgd2VyZSBzb21lIGNvbmNlcm5zIHRoYXQgdGhl IEktRCBpcw0KPiB0b28gY29tcGxleCBhbmQgaGFzIGVsZW1lbnRzIHdlIGRvIG5vdCB1bmRlcnN0 YW5kIChsaWtlIHdoYXQgYXJlDQo+ICdmdW5jdGlvbnMnKSBub3Igd2FzIGl0IGNsZWFyIHRoYXQg aW5jbHVkaW5nIGRldmlhdGlvbiBpbnRvIHRoZQ0KPiBnZXQtc2NoZW1hLWNvbmZvcm1hbmNlIFJQ QyB3YXMgYSBnb29kIGlkZWEuDQoNCidvcHRpb25hbCBmdW5jdGlvbnMnIGlzIGp1c3QgJ2ZlYXR1 cmUnIGluIFlBTkcuDQoNCj4gDQo+IC9qcw0KPiANCj4gLS0gDQo+IEp1ZXJnZW4gU2Nob2Vud2Fl bGRlciAgICAgICAgICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+IFBob25lOiAr NDkgNDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSwgMjg3NTkgQnJlbWVuLCBHZXJt YW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHA6Ly93d3cuamFjb2Jz LXVuaXZlcnNpdHkuZGUvPg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgKGFuZCBhbnkgYXR0YWNobWVudCB0 cmFuc21pdHRlZCBoZXJld2l0aCkgaXMgcHJpdmlsZWdlZCBhbmQgY29uZmlkZW50aWFsIGFuZCBp cyBpbnRlbmRlZCBmb3IgdGhlIGV4Y2x1c2l2ZSB1c2Ugb2YgdGhlIGFkZHJlc3NlZShzKS4gIElm IHlvdSBhcmUgbm90IGFuIGludGVuZGVkIHJlY2lwaWVudCwgYW55IGRpc2Nsb3N1cmUsIHJlcHJv ZHVjdGlvbiwgZGlzdHJpYnV0aW9uIG9yIG90aGVyIGRpc3NlbWluYXRpb24gb3IgdXNlIG9mIHRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaXMgc3RyaWN0bHkgcHJvaGliaXRlZC4gIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgbWFpbCBpbiBlcnJvciwgcGxlYXNlIGRlbGV0ZSBpdCBhbmQgbm90 aWZ5IHVzIGltbWVkaWF0ZWx5Lg0K --=_alternative 0005421348257D5C_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 PHR0Pjxmb250IHNpemU9Mj5KdWVyZ2VuIFNjaG9lbndhZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRl ckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDsNCtC009ogMjAxNC0wOS0yMiAyMDozMDowNjo8YnI+ DQo8YnI+DQomZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAmbHQ7ai5zY2hvZW53YWVsZGVyQGph Y29icy11bml2ZXJzaXR5LmRlJmd0Ow0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDIwMTQtMDktMjIgMjA6MzA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDsgPGJyPg0KJmd0OyDH67TwuLQguPg8YnI+DQomZ3Q7IEp1ZXJnZW4gU2Nob2Vud2FlbGRl ciAmbHQ7ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlJmd0OzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGZlbmcuY2hvbmczM0B6dGUu Y29tLmNuLCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyCzrcvNPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg bmV0bW9kQGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsg1vfM4jwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+ DQomZ3Q7IFJlOiBbbmV0bW9kXSBkcmFmdCBtaW51dGVzIHlhbmcgMS4xIGludGVyaW0gbWVldGlu ZyBuZXcgeW9yazwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IE9uIE1vbiwgU2VwIDIyLCAyMDE0IGF0IDA5OjEzOjI4QU0gKzA4MDAsIGZlbmcuY2hvbmcz M0B6dGUuY29tLmNuDQp3cm90ZTo8YnI+DQomZ3Q7ICZndDsgKiBZMTYgbW9kdWxlIGFkdmVydGlz ZW1lbnQgb3B0aW1pemF0aW9uIC8gWTU0IHJlbW92ZSB0aGUgYWR2ZXJ0aXNlbWVudA0Kb2YgPGJy Pg0KJmd0OyAmZ3Q7IGNvbmZvcm1hbmNlIGluZm9ybWF0aW9uIGluIE5FVENPTkYgaGVsbG8gbWVz c2FnZTxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IC0gTUI6IFlBTkcgMS4w IG1vZHVsZXMgd2lsbCBjb250aW51ZSB0byBiZSBhZHZlcnRpc2VkDQppbiBoZWxsbzxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7IG1lc3NhZ2VzIGJ1dCBmb3IgWUFORyAxLjEgbW9kdWxlcywg d2UgbWF5IGFkdmVydGlzZQ0Kb25seSBhIG1vZHVsZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5i c3A7IHNldCAnaGFzaCcuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOzxicj4NCiZndDsgJmd0OyAmbmJz cDsgLSBNQjogV2Ugc2hvdWxkIHByb3ZpZGUgYWNjZXNzIHRvIHRoZSBtb2R1bGUgbGlzdCBpbiB0 aGUNCnNhbWUgd2F5PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgZm9yIE5FVENPTkYgYW5k IFJFU1RDT05GLjxicj4NCiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IC0g REI6IFdlIG1heSBoYXZlIHRvIHN1cHBvcnQgZGlmZmVyZW50IG1vZHVsZSBzZXRzIG9uPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgTkVUQ09ORi9SRVNUQ09ORiBvciBkaWZmZXJlbnQgbW9k dWxlIHNldHMgZm9yIGRpZmZlcmVudA0KdXNlcnMgb3I8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZu YnNwOyBkaWZmZXJlbnQgbW9kdWxlIHNldHMgZm9yIGRpZmZlcmVudCBkYXRhc3RvcmVzLjxicj4N CiZndDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IC0gTUI6IFNpbmNlIGhlbGxv IGJhc2ljYWxseSB3b3JrcywgaXMgdGhpcyByZWFsbHkgYSBwcm9ibGVtDQp0byBmaXgsPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgZ2l2ZW4gdGhlIG92ZXJhbGwgb3ZlcmhlYWQgb2YgdGhl IHNlY3VyZSB0cmFuc3BvcnRzDQpOQyBpcyBydW5uaW5nPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDsgb3Zlcj8gUkMgZG9lcyBub3QgaGF2ZSB0aGUgZXF1aXZhbGVudCBvZiBoZWxsby48YnI+ DQomZ3Q7ICZndDsgJm5ic3A7PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAtIEpTOiBUaGUgaGVsbG8g bWVzc2FnZSBzaXplIGlzIG1vc3RseSBhbiBpc3N1ZSBmb3Igc2hvcnQNCmxpdmVkPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgc2Vzc2lvbnMuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAtIEpI OiBPciBmb3Igc2Vzc2lvbnMgcnVubmluZyBvdmVyIGxpbmtzIHdpdGggbm90aWNlYWJsZQ0KcGFj a2V0IGxvc3M8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwOyByYXRlcy48YnI+DQomZ3Q7ICZn dDsgJm5ic3A7IC0gREI6IFRoaXMgbWF5IGJlIGFuIGlzc3VlIGZvciBlTm9kZUJzLjxicj4NCiZn dDsgJmd0OyAmbmJzcDs8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IFByb3Bvc2FsOiBXZSBkbyBub3Qg c2VuZCBZQU5HIDEuMSBtb2R1bGUgVVJJcyBidXQgaW5zdGVhZA0Kd2Ugc2VuZCBhPGJyPg0KJmd0 OyAmZ3Q7ICZuYnNwOyBoYXNoIG9yIGlkZW50aWZpZXIuIDxicj4NCiZndDsgJmd0OyA8YnI+DQom Z3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFtmcmFua106IEkgdGhpbmsgaXQncyBlbm91Z2ggdGhh dCBzZXJ2ZXIgb25seSBzZW5kIGEgaGFzaCB0bw0KaW5kaWNhdGUgYWxsIDxicj4NCiZndDsgJmd0 OyBtb2R1bGVzJyA8YnI+DQomZ3Q7ICZndDsgY29uZm9ybWFuY2UgaW5mb3JtYXRpb24uPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFRoaXMgaXMgZXhhY3RseSB3aGF0IHdhcyBkaXNjdXNzZWQuIEJ1dCB0 aGVuIHdlIGFsc28gZGlzY3Vzc2VkIHRoYXQNCml0PGJyPg0KJmd0OyBpcyBub3QgcmVhbGx5IGEg aGFzaCBidXQgbW9yZSBvZiBhbiBpZGVudGlmaWVyIGZvciB0aGUgZ2l2ZW4gbW9kdWxlPGJyPg0K Jmd0OyBzZXQuIFdlIGFsc28gZGlzY3Vzc2VkIHdoYXQgdGhlIHNjb3BlIG9mIHN1Y2ggYW4gaWRl bnRpZmllciB3b3VsZA0KYmUuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5JIGFncmVlIGl0J3Mgbm90IHJlYWxseSBhIGhhc2gsIGl0IGlzIGEgaWRlbnRpZmllci4NCkJ1 dCBJIHRoaW5rIHRoaXMgaWRlbnRpZmllcjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+c2hvdWxkIGJlIG9wZW4gdG8gdmVuZG9yIHRvIGRlZmluZS4gSSBzdWdnZXN0IFdHIHVzZQ0K Y29uZm9ybWFuY2UtSUQgbWVudGlvbmVkIGluIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+bXkgZHJhZnQgYXMgdGVybWlub2xvZ3kgZm9yIHRoaXMgaWRlbnRpZmllci48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyBQcm9wb3NhbDogV2UgY3JlYXRlIGEgbmV3IGlldGYteWFuZy1hZHZlcnRpc2VtZW50IG1v ZHVsZQ0KdGhhdDxicj4NCiZndDsgJmd0OyAmbmJzcDsgZGV0YWlscyBhIGRhdGEgbW9kZWwgZm9y IHRoZSBhZHZlcnRpc2VtZW50IG9mIFlBTkcgZGF0YQ0KbW9kZWxzICh0aGF0PGJyPg0KJmd0OyAm Z3Q7ICZuYnNwOyB3b3JrcyBpbiB0aGUgc2FtZSB3YXkgZm9yIE5FVENPTkYgYW5kIFJFU1RDT05G KS48YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFtmcmFua106IEkgaGF2ZSBjcmVhdGVk IGEgbW9kdWxlIGNhbGxlZCBpZXRmLW5ldGNvbmYtY29uZm9ybWFuY2UNCnRvIDxicj4NCiZndDsg Jmd0OyBzdXBwb3J0PGJyPg0KJmd0OyAmZ3Q7IGNsaWVudCB0byBnZXQgc2VydmVyJ3MgZGV0YWls IGNvbmZvcm1hbmNlIGluZm9ybWF0aW9uLjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg cGxlYXNlIHNlZSBteSBuZXcgZHJhZnQ6PGJyPg0KJmd0OyAmZ3Q7IDwvZm9udD48L3R0PjxhIGhy ZWY9Imh0dHA6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtZnJhbmstbmV0Y29uZi1j b25mb3JtYW5jZS8iPjx0dD48Zm9udCBzaXplPTI+aHR0cDovL2RhdGF0cmFja2VyLmlldGYub3Jn L2RvYy9kcmFmdC1mcmFuay1uZXRjb25mLWNvbmZvcm1hbmNlLzwvZm9udD48L3R0PjwvYT48dHQ+ PGZvbnQgc2l6ZT0yPjxicj4NCiZndDsgJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgYXJl IGF3YXJlIG9mIHRoZSBJLUQgYW5kIHRoZXJlIHdlcmUgc29tZSBjb25jZXJucyB0aGF0IHRoZSBJ LUQNCmlzPGJyPg0KJmd0OyB0b28gY29tcGxleCBhbmQgaGFzIGVsZW1lbnRzIHdlIGRvIG5vdCB1 bmRlcnN0YW5kIChsaWtlIHdoYXQgYXJlPGJyPg0KJmd0OyAnZnVuY3Rpb25zJykgbm9yIHdhcyBp dCBjbGVhciB0aGF0IGluY2x1ZGluZyBkZXZpYXRpb24gaW50byB0aGU8YnI+DQomZ3Q7IGdldC1z Y2hlbWEtY29uZm9ybWFuY2UgUlBDIHdhcyBhIGdvb2QgaWRlYS48L2ZvbnQ+PC90dD4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPidvcHRpb25hbCBmdW5jdGlvbnMnIGlzIGp1c3QgJ2ZlYXR1 cmUnIGluIFlBTkcuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7 IDxicj4NCiZndDsgL2pzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IC0tIDxicj4NCiZndDsgSnVlcmdl biBTY2hvZW53YWVsZGVyICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgSmFjb2Jz IFVuaXZlcnNpdHkNCkJyZW1lbiBnR21iSDxicj4NCiZndDsgUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IENhbXB1cyBSaW5nIDEsDQoyODc1OSBCcmVt ZW4sIEdlcm1hbnk8YnI+DQomZ3Q7IEZheDogJm5ic3A7ICs0OSA0MjEgMjAwIDMxMDMgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZsdDs8L2ZvbnQ+PC90dD48YSBocmVmPSJodHRwOi8vd3d3 LmphY29icy11bml2ZXJzaXR5LmRlLyI+PHR0Pjxmb250IHNpemU9Mj5odHRwOi8vd3d3LmphY29i cy11bml2ZXJzaXR5LmRlLzwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPiZndDs8YnI+ DQo8L2ZvbnQ+PC90dD4NCg0KPGJyPjxwcmU+PGZvbnQgY29sb3I9ImJsdWUiPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZv cm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhp cyBtYWlsIChhbmQgYW55IGF0dGFjaG1lbnQgdHJhbnNtaXR0ZWQgaGVyZXdpdGgpIGlzIHByaXZp bGVnZWQgYW5kIGNvbmZpZGVudGlhbCBhbmQgaXMgaW50ZW5kZWQgZm9yIHRoZSBleGNsdXNpdmUg dXNlIG9mIHRoZSBhZGRyZXNzZWUocykuICBJZiB5b3UgYXJlIG5vdCBhbiBpbnRlbmRlZCByZWNp cGllbnQsIGFueSBkaXNjbG9zdXJlLCByZXByb2R1Y3Rpb24sIGRpc3RyaWJ1dGlvbiBvciBvdGhl ciBkaXNzZW1pbmF0aW9uIG9yIHVzZSBvZiB0aGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGlzIHN0 cmljdGx5IHByb2hpYml0ZWQuICBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1haWwgaW4gZXJy b3IsIHBsZWFzZSBkZWxldGUgaXQgYW5kIG5vdGlmeSB1cyBpbW1lZGlhdGVseS4NCg0KPC9mb250 PjwvcHJlPjxicj4NCg== --=_alternative 0005421348257D5C_=-- From nobody Tue Sep 23 00:00:52 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E47C1A1BA5 for ; Tue, 23 Sep 2014 00:00:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 oJdPOclQiYuT for ; Tue, 23 Sep 2014 00:00:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A291E1A1BB8 for ; Tue, 23 Sep 2014 00:00:42 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F3202A93; Tue, 23 Sep 2014 09:00:40 +0200 (CEST) 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 WZn69dzABzPu; Tue, 23 Sep 2014 09:00:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Sep 2014 09:00:37 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B66B520063; Tue, 23 Sep 2014 09:00:37 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id P5--eu_pzU0A; Tue, 23 Sep 2014 09:00:34 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00BCC200AB; Tue, 23 Sep 2014 09:00:33 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id C86F92E86299; Tue, 23 Sep 2014 09:00:33 +0200 (CEST) Date: Tue, 23 Sep 2014 09:00:33 +0200 From: Juergen Schoenwaelder To: "Sterne, Jason (Jason)" Message-ID: <20140923070033.GB20455@elstar.local> Mail-Followup-To: "Sterne, Jason (Jason)" , "netmod@ietf.org" References: <20140922181933.GB19096@elstar.local> <20140922202154.GB19448@elstar.local> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cLdu14CM3De5oNfaMWeZ49aGFHk Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:00:50 -0000 On Mon, Sep 22, 2014 at 08:48:10PM +0000, Sterne, Jason (Jason) wrote: > > Sorry if I'm being dense here. Maybe if you could let me know how > the hello in my example should look (if I have it wrong) I'll > understand what you mean. Should I be completely separating the > protocol version capabilities from the ietf-netconf module support > like this ? (strange to have the base:1.0 URN listed twice though): > > urn:ietf:params:netconf:base:1.0 > urn:ietf:params:netconf:base:1.1 > urn:ietf:params:netconf:capability:validate:1.1 > urn:ietf:params:netconf:capability:validate:1.0 > urn:ietf:params:netconf:capability:writable-running:1.0 > urn:ietf:params:netconf:base:1.0?module=ietf-netconf&revision=2011-06-01&features=writable-running,validate > I think the last should use "urn:ietf:params:xml:ns:netconf:base:1.0" instead of "urn:ietf:params:netconf:base:1.0" since this is the value of the namespace statement in ietf-netconf.yang. Note that NETCONF was designed before there was YANG and NETCONF even today in principle may be used with other data modeling languages. Note that the last capability line above is a YANG module announcement and defined in RFC 6020. So plain NETCONF would not have it. Yes, this will likely be not relevant in many implementations but there are reasons why we ended up with this (mainly NETCONF simply predates YANG). /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 Sep 23 05:54:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CFEF91A1BAD; Tue, 23 Sep 2014 00:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtbdCGDKQHhY; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from koko.ripe.net (koko.ripe.net [IPv6:2001:67c:2e8:11::c100:1348]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 653A41A1BAF; Tue, 23 Sep 2014 00:50:46 -0700 (PDT) Received: from titi.ripe.net ([193.0.23.11]) by koko.ripe.net with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.72) (envelope-from ) id 1XWKrv-0002h1-Nx; Tue, 23 Sep 2014 09:50:42 +0200 Received: from kitten.ripe.net ([2001:67c:2e8:1::c100:1f0] helo=guest125.guestnet.ripe.net) by titi.ripe.net with esmtp (Exim 4.72) (envelope-from ) id 1XWKrv-0006eB-9H; Tue, 23 Sep 2014 09:50:39 +0200 Message-ID: <5421264E.3020103@bwijnen.net> Date: Tue, 23 Sep 2014 09:50:38 +0200 From: "Bert Wijnen (IETF)" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Jeffrey Haas , netconf References: <20140922210546.GA5676@pfrc> In-Reply-To: <20140922210546.GA5676@pfrc> Content-Type: text/plain; charset=windows-1252; 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: 86ab03e524994f79ca2c75a176445dd4e612c824b427cae28f7af699a306405d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/SRl7O7AM_60anhAw3fJRCJtt0NY X-Mailman-Approved-At: Tue, 23 Sep 2014 05:54:05 -0700 Subject: Re: [netmod] [Netconf] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 07:50:49 -0000 [bcc to i2rs and netmod]; I propose to discuss the netconf aspects of this on the netconf mailing list. However, for i2rs "consensus" on the specific netconf requirements, I think it MUSR be dealth with on i2rs list. Thanks Jeff, this is good for netconf participants to be aware of. And to discuss/comment on. Bert On 22/09/14 23:05, Jeffrey Haas wrote: > [BCC: netconf] > > The netmod interim in New York City last week was a productive discussion for > I2RS, although it was frustrating in its conclusions. (Those conclusions > mostly being, "There's mostly no work needed here, go talk to netconf!") > However, given the large overlap of WG membership between netmod and > netconf, it should hopefully make the next form of this meeting somewhat > easier to have. > > Thanks to Cisco for providing the venue for the interim. > > This writeup is presented to document my perception of our discussion and > provide the seed to start further discussion in i2rs. No specific requests > are being made to netconf at this point - and to reduce accidental noise as > we try to converge on our discussion points, I have placed them in the BCC > field. We can make more formal requests once the i2rs discussion of the > netmod interim has gotten some traction. > > Juergen has placed the full netmod minutes here: > http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.txt > > A small excerpt from those minutes: > : Conclusion: We do not need any changes for YANG 1.1 (hurray) but > : instead we need a document that introduces ephemeral datastores and > : clarifies what validation means with ephemeral datastores. In > : addition, the NETCONF WG needs to do work to define suitable > : protocol operations and RESTCONF needs to make sure it is prepared > : to support ephemeral datastores. There is also NETCONF work to be > : done to improve notification handling. The only YANG 1.1 homework is > : to make sure that the language in the YANG 1.1 specification is > : flexible enough to enable the introduction of ephemeral datastores. > > Background: > > The seed for the discussion at this interim was the somewhat hastily > authored document: > https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 > > ----- > > Ephemeral state: > > The I2RS portion of the discussion was kicked off by talking about the > ephemeral state that I2RS wants to have and why it is important that it is > ephemeral. The three options from section 2.1 were presented and discussed > at length. The points about the advantages of a separate datastore (easy > cleanup, clear segregation of state) were compared against the desire of > other non-I2RS users wanting ephemeral state. A point that was raised early > was, "why can't we simply let the operators choose whether something is > ephemeral or not?" > > This lead to a discussion regarding the nature of "priority" and what its > impact was with regard to how ephemeral state was kept. One thing that > became apparent during this discussion is the I2RS Architecture draft is > potentially not clear enough about the distinction of I2RS state priority > vs. Local Config priority (section 6.3 of the Architecture draft) and client > priority (section 7.8); the word priority is overloaded. > > Clarifying client priority vs. state priority lead further into where such > data is kept and how it is used. Room discussion eventually went to > identity and how it was associated with priority. An observation was made > that this information is effectively meta-state being kept on the > configuration nodes. Such information, not being yang specific, was > suggested as a point for netconf. It was observed that the identity may be > useful information for general users and may not be i2rs specific. The > analogy was made to "git blame" (and other similar source-control annotation > mechanisms). > > The "where is the ephemeral state kept" conversation began to converge > around a possible fourth option - one that apparently had some discussion > much earlier in the i2rs working group's life, apparently. Here's my > attempt to describe the conclusions of that discussion: > > - There is a new ephemeral datastore. > - It may be used by my many applications, including I2RS. > - It has the property that the schema of config state is "visible" in it > from a read-only perspective. > - It has the property that writes to it may either create new state that is > disjoint from the config data store state or it may cause changes to > information that is/was visible from the config state. Such changes may > be merge, override, delete, e.g. > - This "shadowing" behavior avoids issues in the existing yang by not > requiring additional language semantics that would require mechanisms to > cross-reference between datastores. (One might observe this is somewhat > similar to Object Oriented programming where the configuration state > serves as a "base class" with ephemeral configuration extending that > base. A different analogy is the union filesystem semantic.) > > Issues that came up with this model under discussion: > > - Validation is a problem with this design. (And was likely even more > complicated in the original 3 discussion points. This was one of the > elements that drove us to this fourth option.) > - It is possible to refer to config state from ephemeral state for > conditions (must, when), but not vice-versa. > - We (i2rs) must decide what happens when ephemeral state has conditions > that are invalidated by a change to the underlying config state. In such > a case, the config state may validate, but i2rs may not. Does the > operation succeed or fail? > - Such constraints and their validation impact may negatively impact the > desired speed properties of i2rs. However, it was also observed this is > only the case when such references exist and that "fast" i2rs operations > could simply be modeled with no dependencies on config state. > > - Ephemeral state priority vs. Local Config priority is difficult to fully > support in such a model. In the above discussion, ephemeral state always > has priority over Local Config. > - Providing for Local Config to have lower priority may be possible, but > introduces some unusual semantics. > - Does I2RS have clear use cases for Local Config winning? The example of > "configuration of last resort" was offered but is potentially a weak case. > > In summary, the fourth option was strongly driven by the arguments of "what > keeps things simple". The original three options were apparently not simple > enough and there's some doubt about the impacts of the fourth. > > Possible yang 1.1 implications: If the above model works, the discussed > configuration semantic may be the previously discussed > "config (false|true|ephemeral);" > > ------ > > Mutual authentication was also discussed. As noted on list conversation > after draft-haas-* was published, while restconf doesn't currently require > it, it is suspected that it will have such a requirement before working > through IESG. > > I suggest that I2RS requirements are addressed for this point. > > ----- > > Identity requirements for the primary identity are covered by authentication > requirements for the existing protocols. The "secondary identity" > requirement is a netconf issues and we should talk to them about the > implications. Since the primary requirement for this feature is for > auditing, this may simply be meta-data that is kept on configuration state. > (See commentary above.) > > It is noted, however, that introducing something like a secondary identity > would require changes to SSH and/or TLS and may be somewhat difficult to > make the case to the owning working groups. > > Per-client priority effectively becomes the ability to say "you can't write > to this if the state exists and has an owner with a higher priority". > Further discussion on this point is needed in light of the fourth option we > were presented. > > ------ > > Persistance of subscriptions. Effectively we were told "go talk to netconf, > it's out of scope for yang 1.1". > > Some discussion was given to the filtering considerations. Extending the > filtering options of the ietf-inet-types module may be appropriate. > [Juergen, is this an action item for yang 1.1?] > > ----- > > Hopefully this is clear enough to kick off discussion. > > -- Jeff > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Tue Sep 23 05:59:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 420BB1A1A27 for ; Tue, 23 Sep 2014 05:59:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786] 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 eiBWTP7zArwQ for ; Tue, 23 Sep 2014 05:59:06 -0700 (PDT) Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-02.alcatel-lucent.com [135.245.18.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D97E11A8027 for ; Tue, 23 Sep 2014 05:59:05 -0700 (PDT) Received: from us70uusmtp4.zam.alcatel-lucent.com (unknown [135.5.2.66]) by Websense Email Security Gateway with ESMTPS id 36026CD55B97A; Tue, 23 Sep 2014 12:59:03 +0000 (GMT) Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id s8NCx4ri026113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 23 Sep 2014 08:59:04 -0400 Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.186]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.03.0195.001; Tue, 23 Sep 2014 08:59:04 -0400 From: "Sterne, Jason (Jason)" To: Juergen Schoenwaelder Thread-Topic: [netmod] conformance & features in netconf Thread-Index: Ac/WjZq3fjHfgaHhQXSt5pX6tl8HkgAJa5WAAAaOjaD//+26AIAAP6LwgAByzoD//+C3QA== Date: Tue, 23 Sep 2014 12:59:04 +0000 Message-ID: References: <20140922181933.GB19096@elstar.local> <20140922202154.GB19448@elstar.local> <20140923070033.GB20455@elstar.local> In-Reply-To: <20140923070033.GB20455@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.5.27.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CBCL5KNe_nRKzK7FmW3bc4PhdNI Cc: "netmod@ietf.org" Subject: Re: [netmod] conformance & features in netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 12:59:09 -0000 Thanks Juergen. That is clear now. I had not noticed the difference in th= e middle of the urns for the ietf-netconf yang module namespace vs the netc= onf protocol capability. I thought they were the same and that was causin= g my confusion about what to advertise. I agree that the last should use = urn:ietf:params:xml:ns:netconf:base:1.0. Regards, Jason -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Tuesday, September 23, 2014 3:01 AM To: Sterne, Jason (Jason) Cc: netmod@ietf.org Subject: Re: [netmod] conformance & features in netconf On Mon, Sep 22, 2014 at 08:48:10PM +0000, Sterne, Jason (Jason) wrote: >=20 > Sorry if I'm being dense here. Maybe if you could let me know how the=20 > hello in my example should look (if I have it wrong) I'll understand=20 > what you mean. Should I be completely separating the protocol version=20 > capabilities from the ietf-netconf module support like this ? =20 > (strange to have the base:1.0 URN listed twice though): >=20 > urn:ietf:params:netconf:base:1.0 > urn:ietf:params:netconf:base:1.1 > urn:ietf:params:netconf:capability:validate:1.1 y>=20 > urn:ietf:params:netconf:capability:validate:1.0 y>=20 > urn:ietf:params:netconf:capability:writable-running:1.0 apability>=20 > urn:ietf:params:netconf:base:1.0?module=3Dietf-netconf&r > evision=3D2011-06-01&features=3Dwritable-running,validate >=20 I think the last should use "urn:ietf:params:xml:ns:netconf:base:1.0" instead of "urn:ietf:params:netconf:base:1.0" since this is the value of th= e namespace statement in ietf-netconf.yang. Note that NETCONF was designed before there was YANG and NETCONF even today= in principle may be used with other data modeling languages. Note that the last capability line above is a YANG module announcement and = defined in RFC 6020. So plain NETCONF would not have it. Yes, this will lik= ely be not relevant in many implementations but there are reasons why we en= ded up with this (mainly NETCONF simply predates YANG). /js --=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 Sep 23 15:14:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 340031A1BD3; Tue, 23 Sep 2014 15:14:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 S6r8_SCIJaq7; Tue, 23 Sep 2014 15:14:20 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5B42D1A8880; Tue, 23 Sep 2014 15:14:20 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" , , References: <20140922210546.GA5676@pfrc> In-Reply-To: <20140922210546.GA5676@pfrc> Date: Tue, 23 Sep 2014 18:14:16 -0400 Message-ID: <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteJzAsZSg Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/ghFJgmGC00R31ltkNNuuh6ZmPSI Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Sep 2014 22:14:22 -0000 Jeff: The fourth option is interesting and creative. A few questions/requests: 1) How would the fourth model be expressed in the yang model - config (empheral)? 2) Please define your definition of local config with an example., and 3) please give an example of the (must, when) use cases envisioned? Sue Hares -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Monday, September 22, 2014 5:06 PM To: i2rs@ietf.org; netmod@ietf.org Subject: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf [BCC: netconf] The netmod interim in New York City last week was a productive discussion for I2RS, although it was frustrating in its conclusions. (Those conclusions mostly being, "There's mostly no work needed here, go talk to netconf!") However, given the large overlap of WG membership between netmod and netconf, it should hopefully make the next form of this meeting somewhat easier to have. Thanks to Cisco for providing the venue for the interim. This writeup is presented to document my perception of our discussion and provide the seed to start further discussion in i2rs. No specific requests are being made to netconf at this point - and to reduce accidental noise as we try to converge on our discussion points, I have placed them in the BCC field. We can make more formal requests once the i2rs discussion of the netmod interim has gotten some traction. Juergen has placed the full netmod minutes here: http://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/netmod-2014-09-18-minutes.t xt A small excerpt from those minutes: : Conclusion: We do not need any changes for YANG 1.1 (hurray) but : instead we need a document that introduces ephemeral datastores and : clarifies what validation means with ephemeral datastores. In : addition, the NETCONF WG needs to do work to define suitable : protocol operations and RESTCONF needs to make sure it is prepared : to support ephemeral datastores. There is also NETCONF work to be : done to improve notification handling. The only YANG 1.1 homework is : to make sure that the language in the YANG 1.1 specification is : flexible enough to enable the introduction of ephemeral datastores. Background: The seed for the discussion at this interim was the somewhat hastily authored document: https://tools.ietf.org/html/draft-haas-i2rs-netmod-netconf-requirements-00 ----- Ephemeral state: The I2RS portion of the discussion was kicked off by talking about the ephemeral state that I2RS wants to have and why it is important that it is ephemeral. The three options from section 2.1 were presented and discussed at length. The points about the advantages of a separate datastore (easy cleanup, clear segregation of state) were compared against the desire of other non-I2RS users wanting ephemeral state. A point that was raised early was, "why can't we simply let the operators choose whether something is ephemeral or not?" This lead to a discussion regarding the nature of "priority" and what its impact was with regard to how ephemeral state was kept. One thing that became apparent during this discussion is the I2RS Architecture draft is potentially not clear enough about the distinction of I2RS state priority vs. Local Config priority (section 6.3 of the Architecture draft) and client priority (section 7.8); the word priority is overloaded. Clarifying client priority vs. state priority lead further into where such data is kept and how it is used. Room discussion eventually went to identity and how it was associated with priority. An observation was made that this information is effectively meta-state being kept on the configuration nodes. Such information, not being yang specific, was suggested as a point for netconf. It was observed that the identity may be useful information for general users and may not be i2rs specific. The analogy was made to "git blame" (and other similar source-control annotation mechanisms). The "where is the ephemeral state kept" conversation began to converge around a possible fourth option - one that apparently had some discussion much earlier in the i2rs working group's life, apparently. Here's my attempt to describe the conclusions of that discussion: - There is a new ephemeral datastore. - It may be used by my many applications, including I2RS. - It has the property that the schema of config state is "visible" in it from a read-only perspective. - It has the property that writes to it may either create new state that is disjoint from the config data store state or it may cause changes to information that is/was visible from the config state. Such changes may be merge, override, delete, e.g. - This "shadowing" behavior avoids issues in the existing yang by not requiring additional language semantics that would require mechanisms to cross-reference between datastores. (One might observe this is somewhat similar to Object Oriented programming where the configuration state serves as a "base class" with ephemeral configuration extending that base. A different analogy is the union filesystem semantic.) Issues that came up with this model under discussion: - Validation is a problem with this design. (And was likely even more complicated in the original 3 discussion points. This was one of the elements that drove us to this fourth option.) - It is possible to refer to config state from ephemeral state for conditions (must, when), but not vice-versa. - We (i2rs) must decide what happens when ephemeral state has conditions that are invalidated by a change to the underlying config state. In such a case, the config state may validate, but i2rs may not. Does the operation succeed or fail? - Such constraints and their validation impact may negatively impact the desired speed properties of i2rs. However, it was also observed this is only the case when such references exist and that "fast" i2rs operations could simply be modeled with no dependencies on config state. - Ephemeral state priority vs. Local Config priority is difficult to fully support in such a model. In the above discussion, ephemeral state always has priority over Local Config. - Providing for Local Config to have lower priority may be possible, but introduces some unusual semantics. - Does I2RS have clear use cases for Local Config winning? The example of "configuration of last resort" was offered but is potentially a weak case. In summary, the fourth option was strongly driven by the arguments of "what keeps things simple". The original three options were apparently not simple enough and there's some doubt about the impacts of the fourth. Possible yang 1.1 implications: If the above model works, the discussed configuration semantic may be the previously discussed "config (false|true|ephemeral);" ------ Mutual authentication was also discussed. As noted on list conversation after draft-haas-* was published, while restconf doesn't currently require it, it is suspected that it will have such a requirement before working through IESG. I suggest that I2RS requirements are addressed for this point. ----- Identity requirements for the primary identity are covered by authentication requirements for the existing protocols. The "secondary identity" requirement is a netconf issues and we should talk to them about the implications. Since the primary requirement for this feature is for auditing, this may simply be meta-data that is kept on configuration state. (See commentary above.) It is noted, however, that introducing something like a secondary identity would require changes to SSH and/or TLS and may be somewhat difficult to make the case to the owning working groups. Per-client priority effectively becomes the ability to say "you can't write to this if the state exists and has an owner with a higher priority". Further discussion on this point is needed in light of the fourth option we were presented. ------ Persistance of subscriptions. Effectively we were told "go talk to netconf, it's out of scope for yang 1.1". Some discussion was given to the filtering considerations. Extending the filtering options of the ietf-inet-types module may be appropriate. [Juergen, is this an action item for yang 1.1?] ----- Hopefully this is clear enough to kick off discussion. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Tue Sep 23 17:59:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA6BD1A8994; Tue, 23 Sep 2014 17:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 3l-ZuNTJZGrM; Tue, 23 Sep 2014 17:59:40 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 736F81A8996; Tue, 23 Sep 2014 17:59:40 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" , "'Jeffrey Haas'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> In-Reply-To: Date: Tue, 23 Sep 2014 20:59:36 -0400 Message-ID: <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_025C_01CFD771.48B19E70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3kBfPWaBwKMmSaPAmFsweWcdrMZQA== Content-Language: en-us X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OP8U_VtMpeP1SyoiNW9g42K9boo Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 00:59:43 -0000 This is a multipart message in MIME format. ------=_NextPart_000_025C_01CFD771.48B19E70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: The concept on priority and FCFS is "if a remote client talks to an agent at a priority - then it should not be knocked out by another remote client coming later at the same priority". In my mind this is different that the boot/reboot configuration case. Do you think I am correct? Sue From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, September 22, 2014 5:10 PM To: Jeffrey Haas Cc: Susan Hares; i2rs@ietf.org; netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_025C_01CFD771.48B19E70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

 

The concept on priority and FCFS is “if a remote client talks = to an agent at a priority – then it should not be knocked out by = another remote client coming later at the same priority”.  In = my mind this is different that the boot/reboot configuration case.  =  Do you think I am correct?

 

Sue

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, = September 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: = Susan Hares; i2rs@ietf.org; netmod@ietf.org
Subject: Re: = [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and = i2rs requirements)

 

 

 

On Mon, = Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> = wrote:

Sue,

On Thu, Sep 18, 2014 at = 12:58:51PM -0400, Susan Hares wrote:
> Where does the priority = live ??? in I2RS or in config module or in BGP
> routing = model?  How does this work with the three datastore proposals: = 1)
> separate empheral data store, 2) configuration state in = existing datastore
> tagged by model as empheral, and 3) whole = data stores tagged empheral,
> config, or both.   Is the = routing code that sets the priority and handles
> the = rollback?

Priority received quite a bit of discussion during the = netmod interim.  The
reason why it was not explicitly spelled = out in my first version of the
draft is that the implementation would = vary considerably depending on which
answer netmod guided us toward = for how we get ephemeral state.

 

The rationale for the priority-based "first one = wins" access control model is still = unclear

to = me.

 

A = simple NACM extension to add group priority has already been = proposed,

which seems fine = to me. So is this how it works?

 

  #1) NACM data rules can be used to grant or = deny access to specific I2RS data nodes.

        Steps #2 and #3 assume = access is granted here

 

  #2) the I2RS agent maintains the owner and = owner priority of the data somehow.

         The priority is = configured in each NACM group for enforcement purposes. =  

    =      This data used to decide if existing data can be = overwritten by a different client.

         (I think highest = priority wins if target data already exists)

 

  #3) if both writer and current owner have the = same priority, then current owner wins

 

Breaking ties by first-one-wins seems just as = arbitrary as last-one-wins.  It seems to be based = on

the order that the = networking devices will boot.  Can somebody explain why it is = better?

 

I = am still unclear how the operator know the exact data each = client

will want to use, = and how they determine the meaningful = overlap

(e.g. what will = break for client B if client A causes 2 of its 7 entries to be = deleted?)

 

This information seems to be required in order to = configure the tie-breaking priorities = properly,

but I think the = intent is that the operator will just know what I2RS clients are = installed

and know how to = prioritize them, just based on their = purpose.

 

 

 

It turned out they gave us a fourth = option.  I'll be summarizing that in my
meeting minutes.  = If you don't believe I've adequately addressed it in that
writeup = (coming shortly), please let me know and we'll resume.

-- = Jeff

 

 

Andy

 

_______________________________________________
netm= od mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 

------=_NextPart_000_025C_01CFD771.48B19E70-- From nobody Tue Sep 23 18:24:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6281A89AC for ; Tue, 23 Sep 2014 18:24:37 -0700 (PDT) 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 QPdFIwie8jAp for ; Tue, 23 Sep 2014 18:24:34 -0700 (PDT) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 976811A89A7 for ; Tue, 23 Sep 2014 18:24:34 -0700 (PDT) Received: by mail-qa0-f54.google.com with SMTP id n8so2479325qaq.13 for ; Tue, 23 Sep 2014 18:24:33 -0700 (PDT) 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=8cdFOlMGMuN31dtsshrRsa0gF3Urae8kBMp9TRG1WXs=; b=NwiYgwFKcRNflOG7MPqqTz5a6ZnrSHho5ll3aIg/O8Qq9vBuMvsER4AExy+ZcgdXQ/ ZzNyR31+BEPsmMvC6TjZcDmnFrK0xN/0Hlc7G5VwyxeJ4IcvzV0Ss0AiM9DwLoAnfUam KEpkx/jLbfMDKPHqEcSaR1cwZphdSfStzeIPZSLrRUv4ZKaWXjJW6SNy6Rja0N+FKMHk 3UxNmQUqTnPd1Ow3aCo3V2s7C1Nl1Ad1oIfgmuByYgAEfZolhWZVi95ba2JLrcK8fcg5 611ibhNeb8Aq0LNedHPTwGiHsN/vvShcQAvctgj4+V9wZXBYU9cKIMDiZCAhYvzton0r Zi8g== X-Gm-Message-State: ALoCoQkrLenHitB2/AdLNre74FMU21V1Bv4HgiSRcFEZVfK4UgHhlJJWN7AqSjqOcx5/Z5x5ltxg MIME-Version: 1.0 X-Received: by 10.224.20.9 with SMTP id d9mr4954293qab.7.1411521873655; Tue, 23 Sep 2014 18:24:33 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 23 Sep 2014 18:24:33 -0700 (PDT) In-Reply-To: <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> Date: Tue, 23 Sep 2014 18:24:33 -0700 Message-ID: From: Andy Bierman To: Susan Hares Content-Type: multipart/alternative; boundary=001a11c1c560df75790503c58b49 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DdUynqH27Ri2fqBTMQwrOS7o8Yk Cc: "i2rs@ietf.org" , "netmod@ietf.org" Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 01:24:37 -0000 --001a11c1c560df75790503c58b49 Content-Type: text/plain; charset=ISO-8859-1 On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares wrote: > Andy: > > > > The concept on priority and FCFS is "if a remote client talks to an agent > at a priority - then it should not be knocked out by another remote client > coming later at the same priority". In my mind this is different that the > boot/reboot configuration case. Do you think I am correct? > > > Sure. I guess I am assuming each I2RS client has some reconnect-and-reload strategy. Normally, the clients will get notified when some data gets bumped or the agent restarts. Then there may be a race between the 2+ clients with same priority. IMO ties are really errors, and the operator is going to need to assign different priorities or set some config so all the clients run without data collisions. Sue > > > Andy > *From:* Andy Bierman [mailto:andy@yumaworks.com] > *Sent:* Monday, September 22, 2014 5:10 PM > *To:* Jeffrey Haas > *Cc:* Susan Hares; i2rs@ietf.org; netmod@ietf.org > *Subject:* Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was > netmod interim and i2rs requirements) > > > > > > > > On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: > > Sue, > > On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > > Where does the priority live ??? in I2RS or in config module or in BGP > > routing model? How does this work with the three datastore proposals: 1) > > separate empheral data store, 2) configuration state in existing > datastore > > tagged by model as empheral, and 3) whole data stores tagged empheral, > > config, or both. Is the routing code that sets the priority and handles > > the rollback? > > Priority received quite a bit of discussion during the netmod interim. The > reason why it was not explicitly spelled out in my first version of the > draft is that the implementation would vary considerably depending on which > answer netmod guided us toward for how we get ephemeral state. > > > > The rationale for the priority-based "first one wins" access control model > is still unclear > > to me. > > > > A simple NACM extension to add group priority has already been proposed, > > which seems fine to me. So is this how it works? > > > > #1) NACM data rules can be used to grant or deny access to specific I2RS > data nodes. > > Steps #2 and #3 assume access is granted here > > > > #2) the I2RS agent maintains the owner and owner priority of the data > somehow. > > The priority is configured in each NACM group for enforcement > purposes. > > This data used to decide if existing data can be overwritten by a > different client. > > (I think highest priority wins if target data already exists) > > > > #3) if both writer and current owner have the same priority, then > current owner wins > > > > Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. > It seems to be based on > > the order that the networking devices will boot. Can somebody explain why > it is better? > > > > I am still unclear how the operator know the exact data each client > > will want to use, and how they determine the meaningful overlap > > (e.g. what will break for client B if client A causes 2 of its 7 entries > to be deleted?) > > > > This information seems to be required in order to configure the > tie-breaking priorities properly, > > but I think the intent is that the operator will just know what I2RS > clients are installed > > and know how to prioritize them, just based on their purpose. > > > > > > > > It turned out they gave us a fourth option. I'll be summarizing that in my > meeting minutes. If you don't believe I've adequately addressed it in that > writeup (coming shortly), please let me know and we'll resume. > > -- Jeff > > > > > > Andy > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --001a11c1c560df75790503c58b49 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares <shares@ndzh.com> wrote:

 

The concept on priority and FCFS is “if a remote clie= nt talks to an agent at a priority – then it should not be knocked ou= t by another remote client coming later at the same priority”.  = In my mind this is different that the boot/reboot configuration case. =  Do you think I am correct?

 


Sure.

I guess I am ass= uming each I2RS client has some reconnect-and-reload strategy.
No= rmally, the clients will get notified when some data gets bumped or the age= nt restarts.
Then there may be a race between the 2+ clients with= same priority.

IMO ties are really errors, and th= e operator is going to need to assign different priorities
or set= some config so all the clients run without data collisions.

=

Sue

 


A= ndy
 

From:<= /span> Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, S= eptember 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: Susan Ha= res; i2rs@ietf.org; = netmod@ietf.orgSubject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was n= etmod interim and i2rs requirements)

 

 <= u>

 

On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:<= /u>

Sue,
On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> W= here does the priority live ??? in I2RS or in config module or in BGP
&g= t; routing model?  How does this work with the three datastore proposa= ls: 1)
> separate empheral data store, 2) configuration state in exis= ting datastore
> tagged by model as empheral, and 3) whole data store= s tagged empheral,
> config, or both.   Is the routing code= that sets the priority and handles
> the rollback?

Priority r= eceived quite a bit of discussion during the netmod interim.  The
r= eason why it was not explicitly spelled out in my first version of the
d= raft is that the implementation would vary considerably depending on which<= br>answer netmod guided us toward for how we get ephemeral state.=

 

The rationale for the priority-based "first one win= s" access control model is still unclear

<= p class=3D"MsoNormal">to me.

 

A simple NAC= M extension to add group priority has already been proposed,<= /p>

which seems fine to me. So is this how= it works?

 =

  #1) NACM data rules can= be used to grant or deny access to specific I2RS data nodes.=

        Steps #2 = and #3 assume access is granted here

 

&n= bsp; #2) the I2RS agent maintains the owner and owner priority of the data = somehow.

    &= nbsp;    The priority is configured in each NACM group for enforc= ement purposes.  

&= nbsp;        This data used to decide if existing data = can be overwritten by a different client.

         (I think highest priori= ty wins if target data already exists)

 

&n= bsp; #3) if both writer and current owner have the same priority, then curr= ent owner wins

&n= bsp;

Breaking ties by first-one= -wins seems just as arbitrary as last-one-wins.  It seems to be based = on

the order that the ne= tworking devices will boot.  Can somebody explain why it is better?=

 

I am still unclear how the operator know th= e exact data each client

will want to use, and how they determine the meaningful overlap<= /u>

(e.g. what will break for client B= if client A causes 2 of its 7 entries to be deleted?)

 

This information seems to be required in order to configure = the tie-breaking priorities properly,

but I think the intent is that the operator will just know w= hat I2RS clients are installed

and know how to prioritize them, just based on their purpose.=

 

=

 

 

It = turned out they gave us a fourth option.  I'll be summarizing that= in my
meeting minutes.  If you don't believe I've adequate= ly addressed it in that
writeup (coming shortly), please let me know and= we'll resume.

-- Jeff

 

=  

Andy

 

______= _________________________________________
netmod mailing list
netmod@ietf.org
https:= //www.ietf.org/mailman/listinfo/netmod

 

=

--001a11c1c560df75790503c58b49-- From nobody Wed Sep 24 00:00:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 083B31A70FD; Wed, 24 Sep 2014 00:00:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.736 X-Spam-Level: X-Spam-Status: No, score=-1.736 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786] 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 4j0CcJEE1XtZ; Wed, 24 Sep 2014 00:00:33 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7F4E1A7D80; Wed, 24 Sep 2014 00:00:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 490648EC; Wed, 24 Sep 2014 09:00:30 +0200 (CEST) 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 mVRktvTn_6oH; Wed, 24 Sep 2014 09:00:26 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Sep 2014 09:00:28 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 98EB520036; Wed, 24 Sep 2014 09:00:28 +0200 (CEST) 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 whYcsPoUodHW; Wed, 24 Sep 2014 09:00:27 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2FBC320035; Wed, 24 Sep 2014 09:00:26 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 0F7382E87AEF; Wed, 24 Sep 2014 09:00:26 +0200 (CEST) Date: Wed, 24 Sep 2014 09:00:26 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140924070025.GD23280@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140922210546.GA5676@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/net5MZUf6piudJo1wZAfIcWf4K8 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:00:35 -0000 On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > - This "shadowing" behavior avoids issues in the existing yang by not > requiring additional language semantics that would require mechanisms to > cross-reference between datastores. (One might observe this is somewhat > similar to Object Oriented programming where the configuration state > serves as a "base class" with ephemeral configuration extending that > base. A different analogy is the union filesystem semantic.) I believe the OO analogy is largely mis-leading, I think the union filesystem semantics are much closer. > Possible yang 1.1 implications: If the above model works, the discussed > configuration semantic may be the previously discussed > "config (false|true|ephemeral);" My understanding that both the config datastore and any ephemeral datastores largely use the same data model (or schema). So config true|false remains unchanged - the difference is the datastore you write to. > It is noted, however, that introducing something like a secondary identity > would require changes to SSH and/or TLS and may be somewhat difficult to > make the case to the owning working groups. I do not follow here. The secure transport delivers what NETCONF calls a username, the identity of the NETCONF client. If this client acts on behalf of another application (the secondary identity), then this identity is meta data should be attached to the information submitted to the ephemeral datastore. I do not see why this would lead to any changes to SSH or TLS. > Some discussion was given to the filtering considerations. Extending the > filtering options of the ietf-inet-types module may be appropriate. > [Juergen, is this an action item for yang 1.1?] The YANG 1.1 issue Y20 is about adding a set of built-in xpath functions. I like to ask I2RS to tell us what functions they need. We do have IP prefix-length matching on our radar. If other functions are required, please let us know as soon as possible. Now, this mostly is about the xpath function set that can be used in must and when expressions. You probably want to use them also in filtering expressions in the protocol. This is where things again become a protocol issues. Note that RFC 6241 says on page 17: The XPath expression is interpreted in the following context: [...] * The function library is the core function library. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 00:10:32 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 760A91A88E1; Wed, 24 Sep 2014 00:10:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 GqSOOsAXMtQQ; Wed, 24 Sep 2014 00:10:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2EC641A883F; Wed, 24 Sep 2014 00:10:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F2C9A119E; Wed, 24 Sep 2014 09:10:27 +0200 (CEST) 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 mW2L-EoZmbkb; Wed, 24 Sep 2014 09:10:25 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Sep 2014 09:10:27 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F49620035; Wed, 24 Sep 2014 09:10:27 +0200 (CEST) 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 1ODQjyjL0k1P; Wed, 24 Sep 2014 09:10:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAD8F20036; Wed, 24 Sep 2014 09:10:24 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 43E642E87BAB; Wed, 24 Sep 2014 09:10:24 +0200 (CEST) Date: Wed, 24 Sep 2014 09:10:24 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140924071023.GF23280@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/bA95sZ777jOArpujHdG7VuXR65s Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:10:30 -0000 On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > Jeff: > > The fourth option is interesting and creative. A few questions/requests: 1) > How would the fourth model be expressed in the yang model - config > (empheral)? The beauty of the fourth option is that it does not require a large set of new data models. The idea is that you have a standard config data model and you use the same model for an ephemeral datastore. The server will then take the contents of the config datastore and 'merge' it with the content of any ephemeral datastores to produce what the box ends up doing (the operational state). The merging function will take priorities into account should conflicts arise. Here is the relevant figure (taken from the meeting minutes): +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 00:27:03 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 09F7D1A70FD; Wed, 24 Sep 2014 00:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 HbrULYEIB4gc; Wed, 24 Sep 2014 00:27:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id CFB7B1A1BA7; Wed, 24 Sep 2014 00:27:00 -0700 (PDT) Received: from localhost (host-83-131-122-43.h4.t-ht.net [83.131.122.43]) by mail.tail-f.com (Postfix) with ESMTPSA id 596191280457; Wed, 24 Sep 2014 09:26:59 +0200 (CEST) Date: Wed, 24 Sep 2014 09:26:58 +0200 (CEST) Message-Id: <20140924.092658.622309529428712352.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20140924070025.GD23280@elstar.local> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> X-Mailer: Mew version 6.5 on Emacs 24.3 / 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/netmod/nWDJA7hH62obMgnnUyKUX5GUoz0 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:27:02 -0000 Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > Some discussion was given to the filtering considerations. Extending the > > filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. > > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. The quoted text is for the error-path. For the filter, rfc 6241 says (p 67): o The function library is the core function library, plus any functions defined by the data model. /martin From nobody Wed Sep 24 00:32:39 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20FEF1A8F3D; Wed, 24 Sep 2014 00:32:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 DYC-skantalX; Wed, 24 Sep 2014 00:32:31 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1751B1A8F3C; Wed, 24 Sep 2014 00:32:31 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DCBAF1169; Wed, 24 Sep 2014 09:32:29 +0200 (CEST) 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 mYqlggRY3BYT; Wed, 24 Sep 2014 09:32:27 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Sep 2014 09:32:29 +0200 (CEST) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ED81120036; Wed, 24 Sep 2014 09:32:28 +0200 (CEST) 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 rymYJ39t4Y-7; Wed, 24 Sep 2014 09:32:28 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F0C4020037; Wed, 24 Sep 2014 09:32:27 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id D0BB42E87C83; Wed, 24 Sep 2014 09:32:27 +0200 (CEST) Date: Wed, 24 Sep 2014 09:32:27 +0200 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20140924073227.GI23280@elstar.local> Mail-Followup-To: Martin Bjorklund , jhaas@pfrc.org, i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924.092658.622309529428712352.mbj@tail-f.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wD0pSA4u3Xz3uSy7_6Nff_7iuLE Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 07:32:33 -0000 On Wed, Sep 24, 2014 at 09:26:58AM +0200, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > > > Now, this mostly is about the xpath function set that can be used in > > must and when expressions. You probably want to use them also in > > filtering expressions in the protocol. This is where things again > > become a protocol issues. Note that RFC 6241 says on page 17: > > > > The XPath expression is interpreted in the following context: > > > > [...] > > > > * The function library is the core function library. > > The quoted text is for the error-path. For the filter, rfc 6241 says > (p 67): > > o The function library is the core function library, plus any > functions defined by the data model. > Oops. So we are in a better shape than I thought. Good news I would say (although this binding of protocol and data model leads to interesting effects but I do not want to go down there). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 04:35:54 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2D19C1A702C; Wed, 24 Sep 2014 04:35:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 hKQsHqpDaSXC; Wed, 24 Sep 2014 04:35:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 3ADFC1A6FFA; Wed, 24 Sep 2014 04:35:49 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 4D14A289E175; Wed, 24 Sep 2014 07:35:49 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924071023.GF23280@elstar.local> Date: Wed, 24 Sep 2014 07:35:47 -0400 Message-Id: References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/nWSKByNDCzAMeANF-SR3VUDElAY Cc: i2rs@ietf.org, netmod@ietf.org, Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 11:35:52 -0000 --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: > On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: >> Jeff: >>=20 >> The fourth option is interesting and creative. A few = questions/requests: 1) >> How would the fourth model be expressed in the yang model - config >> (empheral)?=20 >=20 > The beauty of the fourth option is that it does not require a large > set of new data models. The idea is that you have a standard config > data model and you use the same model for an ephemeral datastore. The > server will then take the contents of the config datastore and 'merge' > it with the content of any ephemeral datastores to produce what the > box ends up doing (the operational state). The merging function will > take priorities into account should conflicts arise. Here is the > relevant figure (taken from the meeting minutes): >=20 > +-----------------+ > | | > +--- (+) ---+ | > ^ ^ v > +---+ +---+ +---+ > | | | | | | > |(1)| | | | | > | | | | | | > +---+ +---+ +---+ >=20 > NC config ephemeral operational > datastore datastore state >=20 > (1) The complete NC config datastore is at certain synchronization > points made persistent >=20 > (+) Priority resolution, priorities may be per datastore or per > user or per 'application' or even per data node These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 --Tom >=20 > /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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIqyTAAoJEPcO+I7eiUJZp7sP/A9DoeIfM8f8vrpONDu8toFd r0eYAoAHUxMxuGiWIMIbv45/aIajphsArcvNtEPjxyVzMDIu7CBrryioyO1gPv2r qoIjmAS/FFx2PKhUWeJ7l9ll3btLo9aUMIEBVNkyCIA5rktEu8Wo9nFWlrzlHOF4 dEkvv+OHPXImEfaJrKeyceqktU+5eKWTRpr63gt6FVkEHrAA9CCiL18n0JlmCNDi /vDIQPFX/Vts000ucyywxdG7E3XOYXq5nSWGcLwzboNH/7vmcXvkCDtaM9G29Y7I WYkgH0z93epGljAR/lIIm6LzQtHbe6FDcwHoKw88bJjQm493LRtYSXSzJFIzxH5F ZodzkW13r0lA259GdvvsBffmihcIGHvJUZw/RiGP6xl0GuUHqMMRhHYyq3LOxH9q DZWaL8QqIBorkDnebTWFWXMBXLTZKLpeEch/ByP+6f2FYVNjeZdtpflTt9V/p5CX grvKQAefxiSTwM0ezKPLaCnKusKI8BssI1T6PV9R9IKCwWwP9rMUeAbD05M66thP 4Vb6D/rASnc2rb9LO4h1sfd+vICa0yjSEAsoUluI/hA9n49uJmk5lVD9gOvKAseT msLliN/DMIMOUWxh6q9aKPJnO2AhhS3XW9nyTQ/TVQvpUpxMThFyUOnum9hXwebu /JlEN8031G4Vky14uTAu =qbhE -----END PGP SIGNATURE----- --Apple-Mail=_68D4C3CB-B7C4-46CE-91C1-4876B4E865CD-- From nobody Wed Sep 24 04:50:48 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 985FD1A6FFA; Wed, 24 Sep 2014 04:50:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.088 X-Spam-Level: X-Spam-Status: No, score=-2.088 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 gnWk-xxMUJ_U; Wed, 24 Sep 2014 04:50:45 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 789121A7023; Wed, 24 Sep 2014 04:50:42 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id F2E9A289E1D5; Wed, 24 Sep 2014 07:50:41 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924070025.GD23280@elstar.local> Date: Wed, 24 Sep 2014 07:50:39 -0400 Message-Id: <51E02238-F84C-4102-B7D2-395EF67C2FE0@lucidvision.com> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/CAoVNwm5NzxA4LcOQkCXh-QtPdc Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 11:50:46 -0000 --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:3:00 AM, at 3:00 AM, Juergen Schoenwaelder = wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: >=20 >> - This "shadowing" behavior avoids issues in the existing yang by not >> requiring additional language semantics that would require = mechanisms to >> cross-reference between datastores. (One might observe this is = somewhat >> similar to Object Oriented programming where the configuration state >> serves as a "base class" with ephemeral configuration extending that >> base. A different analogy is the union filesystem semantic.) >=20 > I believe the OO analogy is largely mis-leading, I think the union > filesystem semantics are much closer. Yes I agree. They are configuration objects. There might be two = copies of the same object across data stores not an inheritance = relationship: say one in the run-time/ephemeral, one in the persistent. > Possible yang 1.1 implications: If the above model works, the = discussed >> configuration semantic may be the previously discussed >> "config (false|true|ephemeral);" >=20 > My understanding that both the config datastore and any ephemeral > datastores largely use the same data model (or schema). So config > true|false remains unchanged - the difference is the datastore you > write to. They should use precisely the same data models with perhaps a = sub-set being actually implemented at any given time in the ephemeral = one given that some objects might not make sense in that context. In = the diagram you drew in the previous email I responded to, you showed = this analogy very well I think. --Tom > It is noted, however, that introducing something like a secondary = identity >> would require changes to SSH and/or TLS and may be somewhat difficult = to >> make the case to the owning working groups. >=20 > I do not follow here. The secure transport delivers what NETCONF calls > a username, the identity of the NETCONF client. If this client acts on > behalf of another application (the secondary identity), then this > identity is meta data should be attached to the information submitted > to the ephemeral datastore. I do not see why this would lead to any > changes to SSH or TLS. >=20 >> Some discussion was given to the filtering considerations. Extending = the >> filtering options of the ietf-inet-types module may be appropriate. >> [Juergen, is this an action item for yang 1.1?] >=20 > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. >=20 > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: >=20 > The XPath expression is interpreted in the following context: >=20 > [...] >=20 > * The function library is the core function library. >=20 > /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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIrAPAAoJEPcO+I7eiUJZgbUQAKGs3R3HLL1nZwqtR/aDFK/M XDyQU61sjrw56fv+xo/SvQshEq84+t4X+qaPDXa3KZsD7yqEEfts2salmWNAbUMQ fcC2mvheqmT3yGigt1lAYjFqLzj3fOsLIrQNknX72i4EEOpvcKjtMZBXq8TUnOvS 0Ymu/Pn5+Uax8NwphSXkc9jcPzAFsqOPyk70YSrZKloiAeJ46rgJZrw4/exy3xwn KloLN5GBIX1NoNq8TI+6J0c8fwQXuxU3mpp3rpGqsEFGHZAn35lu8AOVrwpXvGsQ Qx/cCaO0G/YURgBqtsC+58WJBPeyftptUF+CtFJ+J6VjOTeb0o4c+UuPSsqgcdv3 9A9T27nLf6ofcF/4kSv5ccdWElRJ6+S2oB1t12phr+DnQATMX0ZQvwDxbmXCfCgy Lfe1Yg5VAL6yZ3gcBP4z5OVH9MKEqLnr9eFdV21WodZ8wASiIXjkkeIk1lQNOpFm 5pVCGf2wRZ+9IBR0tjgrlxsdzAg9rgLzyU7+K/VA0yCUHX3rkKpW+g0pFJE28+Ff 0DzoVG1ahe3/Wby7ddcCMDnAG/kHOWlj5krk5LI9pKQTfmFS8Tw8/mt/z6QPVCuZ Jn5F/SCSwWihHEShqOg6y3k7AXWkjnKTjU/WCRELb58Dk6FY1NXB5z56IjP2zv8V cBy4bM1HrKHK9E19P0B4 =rjZE -----END PGP SIGNATURE----- --Apple-Mail=_14EE95F7-1BDA-4834-886E-63C645F1B8D0-- From nobody Wed Sep 24 08:34:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77DA51A014F; Wed, 24 Sep 2014 08:34:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 m0-6pQjCAsGA; Wed, 24 Sep 2014 08:34:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 04BEB1A0142; Wed, 24 Sep 2014 08:34:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C40B2C2BE; Wed, 24 Sep 2014 11:34:01 -0400 (EDT) Date: Wed, 24 Sep 2014 11:34:01 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140924153401.GC2639@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zkvdo4jZ6sETl3W6gyZcSkdemeE Cc: i2rs@ietf.org, Susan Hares , netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:34:03 -0000 On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: [...] > > > > +-----------------+ > > | | > > +--- (+) ---+ | > > ^ ^ v > > +---+ +---+ +---+ > > | | | | | | > > |(1)| | | | | > > | | | | | | > > +---+ +---+ +---+ > > > > NC config ephemeral operational > > datastore datastore state > > > > (1) The complete NC config datastore is at certain synchronization > > points made persistent > > > > (+) Priority resolution, priorities may be per datastore or per > > user or per 'application' or even per data node > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. It has its own complications. Do we permit more than one ephemeral datastore? If so, this simplifies data object priority when resolving the operational state. But this also complicates operational state integrity when you have multiple cross references. -- Jeff From nobody Wed Sep 24 08:38:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 44DA21A0143; Wed, 24 Sep 2014 08:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.754 X-Spam-Level: X-Spam-Status: No, score=-1.754 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_45=0.6, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 MOIuBzqDiC7B; Wed, 24 Sep 2014 08:38:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 69D171A0142; Wed, 24 Sep 2014 08:38:02 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 2D42FC4A4; Wed, 24 Sep 2014 11:38:02 -0400 (EDT) Date: Wed, 24 Sep 2014 11:38:02 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140924153802.GD2639@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924070025.GD23280@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Nxn0y3sv7Ut99NDNXn-_XPY4I3I Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:38:03 -0000 On Wed, Sep 24, 2014 at 09:00:26AM +0200, Juergen Schoenwaelder wrote: > I believe the OO analogy is largely mis-leading, I think the union > filesystem semantics are much closer. Accepted. I'll stick to the union filesystem example alone for the future. > > Possible yang 1.1 implications: If the above model works, the discussed > > configuration semantic may be the previously discussed > > "config (false|true|ephemeral);" > > My understanding that both the config datastore and any ephemeral > datastores largely use the same data model (or schema). So config > true|false remains unchanged - the difference is the datastore you > write to. I had forgotten this detail. > > It is noted, however, that introducing something like a secondary identity > > would require changes to SSH and/or TLS and may be somewhat difficult to > > make the case to the owning working groups. > > I do not follow here. The secure transport delivers what NETCONF calls > a username, the identity of the NETCONF client. If this client acts on > behalf of another application (the secondary identity), then this > identity is meta data should be attached to the information submitted > to the ephemeral datastore. I do not see why this would lead to any > changes to SSH or TLS. I tried to raise this as a question during the interim, but I think it was lost. How should the meta-data be transported? > > Some discussion was given to the filtering considerations. Extending the > > filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. The primary ones I am aware of are operations on network addresses and prefixes. Was netmod looking for an explicit manifest of such operations? This may have overlap in the work for the ACL module that is already a netmod document. > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. We'll raise this point separately to netconf. -- Jeff From nobody Wed Sep 24 08:44:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5702D1A015F; Wed, 24 Sep 2014 08:43:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 SJaU1uTsO5yw; Wed, 24 Sep 2014 08:43:53 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 018491A014F; Wed, 24 Sep 2014 08:43:53 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id C4FACC2BE; Wed, 24 Sep 2014 11:43:52 -0400 (EDT) Date: Wed, 24 Sep 2014 11:43:52 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140924154352.GE2639@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/F3SRtoTENSCaR4YFu95in_jCkHU Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 15:43:54 -0000 Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few questions/requests: 1) > How would the fourth model be expressed in the yang model - config > (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an > example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff From nobody Wed Sep 24 09:54:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05A171A01DC; Wed, 24 Sep 2014 09:54:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 dTiMvV1kMq1V; Wed, 24 Sep 2014 09:54:43 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9061B1A0179; Wed, 24 Sep 2014 09:54:43 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id A4747289EA87; Wed, 24 Sep 2014 12:54:42 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140924153401.GC2639@pfrc> Date: Wed, 24 Sep 2014 12:54:39 -0400 Message-Id: <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> To: Jeffrey Haas X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8MIn3WkC0uZAXbtWjpkLFmPd8hk Cc: i2rs@ietf.org, Susan Hares , netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 16:54:45 -0000 --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas = wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: > [...] >>>=20 >>> +-----------------+ >>> | | >>> +--- (+) ---+ | >>> ^ ^ v >>> +---+ +---+ +---+ >>> | | | | | | >>> |(1)| | | | | >>> | | | | | | >>> +---+ +---+ +---+ >>>=20 >>> NC config ephemeral operational >>> datastore datastore state >>>=20 >>> (1) The complete NC config datastore is at certain synchronization >>> points made persistent >>>=20 >>> (+) Priority resolution, priorities may be per datastore or per >>> user or per 'application' or even per data node >>=20 >> These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 >=20 > It has its own complications. >=20 > Do we permit more than one ephemeral datastore? If so, this = simplifies data > object priority when resolving the operational state. But this also > complicates operational state integrity when you have multiple cross I vote for keeping this simple for starters. Lets get an = implementation or two of a single ephemeral data store. This avoids = having multiple priorities too; its just 1. --Tom > references. >=20 > -- Jeff >=20 --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIvdPAAoJEPcO+I7eiUJZzpwP/2h/o4bwDX9nkT0KP1pW1Tu0 J9ch7P9Yw9BcUKspOOeY8CrzYp6V+0XI6wGsMFmQjIASPYQ73u/4jHSKc4JsGUaP 9aowUc7bGqQQUYIp1nRQsKXoJjIMVbC5b0xzCR2q+8n8Et+PjlEtoGhzYAY99oim 789aG8U+jJ1BvshY+KEhBGxHlIm8UqIkzDsKTlAU9BW0O1r2aqmfMUliEHU9T/4g 9deyYbH47GN7bWwHcJBvI4AVmdLN2sauOCEKBlxGoGEK7EhkBaHuoDzkG6mF6lLd xpjDJ5RckEd8Yzs6qW1pK3NupYT6zD7aQm5HtoZqYkH9EBVE100R5am+iBnCpcAL XPmOev6yNAPs1wFH7VxhCk3sSbhsmcw732uaKTAufJLdLZ+CXyVRVwKtlHvBcqon /8aFuKwMQdIvl4UnVFSO1EHT4zmPWwj8+Lgqhjc1zLY8IsRVWM9pPJSEU7YIzheq 3mvPmCTCBZnwkfWboCjpn+X8Ept8F6TO35ouxh1ckcTbXHoxVBKUtT3C2GyfUqfv 97cNPyFTRXMt4zfziGUqXYAekZ7nTlNCbqCRuxY+b76O2Jh5o5LCBtUCKHgO6BHt QZn0NFy/YibDq6fUjdNoaAlY0reWjrsPoiCYfcD7yCzjUt3WHUpdsYB7GdA/BP+w phgGObYIE6RPtq01qHv3 =doPl -----END PGP SIGNATURE----- --Apple-Mail=_F1850331-51E9-4E01-B205-1C6AD163E0FE-- From nobody Wed Sep 24 11:30:47 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387441A032C for ; Wed, 24 Sep 2014 11:30:45 -0700 (PDT) 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 JqEECl1GVDQz for ; Wed, 24 Sep 2014 11:30:40 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A97A1A031C for ; Wed, 24 Sep 2014 11:30:40 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id f51so6573923qge.31 for ; Wed, 24 Sep 2014 11:30:39 -0700 (PDT) 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=7WQdMtr4q+Ij3fQHOMZ938SsgY1fZJ19DYWBZPnQwuE=; b=lZLUxwFR+5mSTD0QMPg3S2ltZhrmIDA64JWWlmTZXhhl3MdyPCEoKeyoli/+xkUnc/ DBNya1ZWIJtb7ZjhEtFqPgKwJmEqr91BCxK9IXBcZDdHYbYmcHUIDzRMAJV2zuYxjM5i Th17gf0ehNmh4/pPuAJYrzRJtqqw8wZwcpzop5LEuU1XtcZwgMpdAw5RR5U9oGwSIc+j SzS03gF0Btvl/DbiqS13d+ley3kIg3gGD1paU/dsP9QsRWsbLS3Dp8q7o1gDRRV/r9ca 1Cb97+MD917nTwsa+SwBqZGrbkpgJDO+49IMeErCYYSYZUADXgk97zT+yB4tnyNEDTzk DQAw== X-Gm-Message-State: ALoCoQn7HwDJLB9Pubb813mk0pfPnSDO13UtsKRlPzw6yFBC3CyUwukqd4jnGX4ZMeMWUfY5F3gz MIME-Version: 1.0 X-Received: by 10.140.22.177 with SMTP id 46mr12411176qgn.35.1411583439249; Wed, 24 Sep 2014 11:30:39 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 24 Sep 2014 11:30:39 -0700 (PDT) In-Reply-To: <20140924182604.27116.89952.idtracker@ietfa.amsl.com> References: <20140924182604.27116.89952.idtracker@ietfa.amsl.com> Date: Wed, 24 Sep 2014 11:30:39 -0700 Message-ID: From: Andy Bierman To: "netmod@ietf.org" Content-Type: multipart/alternative; boundary=001a11c12fb877f3750503d3e1a3 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WRn7O2umWQ2sG-mTesdvoFS-TRM Subject: [netmod] Fwd: I-D Action: draft-bierman-netmod-yang-conformance-04.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 18:30:45 -0000 --001a11c12fb877f3750503d3e1a3 Content-Type: text/plain; charset=ISO-8859-1 FYI, I rewrote the YANG Conformance draft based mostly on discussions at the recent NETMOD interim meeting. I don't think we fully solved the problem of what it means wrt/ conformance to import a module. Andy ---------- Forwarded message ---------- From: Date: Wed, Sep 24, 2014 at 11:26 AM Subject: I-D Action: draft-bierman-netmod-yang-conformance-04.txt To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : YANG Conformance Specification Author : Andy Bierman Filename : draft-bierman-netmod-yang-conformance-04.txt Pages : 35 Date : 2014-09-24 Abstract: This document describes conformance specification and advertisement mechanisms for NETCONF servers implementing YANG data model modules. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-bierman-netmod-yang-conformance/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-bierman-netmod-yang-conformance-04 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-bierman-netmod-yang-conformance-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 --001a11c12fb877f3750503d3e1a3 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
FYI,

I rewrote the YANG Conformance dra= ft based mostly on discussions at
the recent NETMOD interim meeti= ng.=A0 I don't think we fully solved
the problem of what it m= eans wrt/ conformance to import a module.


Andy

---------- = Forwarded message ----------
From: <internet-dr= afts@ietf.org>
Date: Wed, Sep 24, 2014 at 11:26 AM
Subj= ect: I-D Action: draft-bierman-netmod-yang-conformance-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 =A0: YANG Conformance Specificatio= n
=A0 =A0 =A0 =A0 Author=A0 =A0 =A0 =A0 =A0 : Andy Bierman
=A0 =A0 =A0 =A0 Filename=A0 =A0 =A0 =A0 : draft-bierman-netmod-yang-conform= ance-04.txt
=A0 =A0 =A0 =A0 Pages=A0 =A0 =A0 =A0 =A0 =A0: 35
=A0 =A0 =A0 =A0 Date=A0 =A0 =A0 =A0 =A0 =A0 : 2014-09-24

Abstract:
=A0 =A0This document describes conformance specification and advertisement<= br> =A0 =A0mechanisms for NETCONF servers implementing YANG data model modules.=


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-bierman-n= etmod-yang-conformance/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-bierman-netmod-yang= -conformance-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=3Ddraft-bie= rman-netmod-yang-conformance-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

--001a11c12fb877f3750503d3e1a3-- From nobody Wed Sep 24 14:01:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A88401A0687; Wed, 24 Sep 2014 14:01:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 aufXpMzTyBMX; Wed, 24 Sep 2014 14:00:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0129.outbound.protection.outlook.com [65.55.169.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 999691A02F6; Wed, 24 Sep 2014 14:00:56 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB421.namprd05.prod.outlook.com (10.141.58.139) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Wed, 24 Sep 2014 21:00:54 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Wed, 24 Sep 2014 21:00:54 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP1qkCvY2EU2y81E2yFJqHoPh2n5wPShsAgACVywCAAEolgIAAQpCAgAAWiICAAETKAA== Date: Wed, 24 Sep 2014 21:00:54 +0000 Message-ID: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> In-Reply-To: <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB421; x-forefront-prvs: 03449D5DD1 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(24454002)(51704005)(377454003)(97736003)(90102001)(106356001)(107046002)(79102003)(74502003)(74662003)(77982003)(46102003)(81342003)(80022003)(95666004)(36756003)(77096002)(77156001)(110136001)(4396001)(99286002)(87286001)(105586002)(62966002)(106116001)(66066001)(85306004)(20776003)(83716003)(93886004)(87936001)(2656002)(104166001)(88136002)(83072002)(85852003)(89996001)(82746002)(33656002)(15975445006)(19580405001)(83322001)(57306001)(31966008)(50986999)(64706001)(81542003)(50226001)(19580395003)(101416001)(76176999)(92566001)(76482002)(92726001)(93916002)(120916001)(21056001)(10300001)(86362001)(99396003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB421; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <3EE5853D4D41F947AD559667123BA529@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/I8PJJcPUjLrya17GTqYuIVJNtUI Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:01:05 -0000 On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau wr= ote: >=20 > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas wrot= e: >=20 >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: >> [...] >>>>=20 >>>> +-----------------+ >>>> | | >>>> +--- (+) ---+ | >>>> ^ ^ v >>>> +---+ +---+ +---+ >>>> | | | | | | >>>> |(1)| | | | | >>>> | | | | | | >>>> +---+ +---+ +---+ >>>>=20 >>>> NC config ephemeral operational >>>> datastore datastore state >>>>=20 >>>> (1) The complete NC config datastore is at certain synchronization >>>> points made persistent >>>>=20 >>>> (+) Priority resolution, priorities may be per datastore or per >>>> user or per 'application' or even per data node >>>=20 >>> These are precisely the qualities I and some others were thinking of w= hen we started i2rs. The idea is quite simple, as you have said above and r= eally needs not be complicated more. =20 >>=20 >> It has its own complications. >>=20 >> Do we permit more than one ephemeral datastore? If so, this simplifies = data >> object priority when resolving the operational state. But this also >> complicates operational state integrity when you have multiple cross >=20 > I vote for keeping this simple for starters. Lets get an implementation = or two of a single ephemeral data store. This avoids having multiple priori= ties too; its just 1. >=20 > --Tom We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example: residential services business services each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.=20 As we are still keeping 1 to 1 overlay, not many to 1. Dean >=20 >=20 >> references. >>=20 >> -- Jeff >>=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Sep 24 14:19:29 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D53331A1A06 for ; Wed, 24 Sep 2014 14:19:26 -0700 (PDT) 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 F6bIAeLc9Ts7 for ; Wed, 24 Sep 2014 14:19:24 -0700 (PDT) Received: from mail-qg0-f44.google.com (mail-qg0-f44.google.com [209.85.192.44]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 31C171A1A24 for ; Wed, 24 Sep 2014 14:19:24 -0700 (PDT) Received: by mail-qg0-f44.google.com with SMTP id f51so6897147qge.3 for ; Wed, 24 Sep 2014 14:19:23 -0700 (PDT) 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=5jBjajOtyMO3A9BCmjF5rgkGUNJ7ymM060lZ66jiSTw=; b=bRhEg2Tl49jipnAuZd87O0foZDNSTAh6HCDxtAteQSj1+cPjLJEuUGo/NO4uctn/ed PI6PRYDnSQp5v2AUAKmOhaZ/AI2Bu7n8ZnCW7XlnNtpz9APZ0nY3dNGXVLDOryoLWKQi GWkGY0RYKBsjqHTSrntBTruUxwidP3StZbWYqGhDrhJcxg6NgbJRmPs2f6MgAz96Rjum cGbt9Q+ZEr3UEHeVLCJQuDeE7wCmDDTSXSdrpbAnZKA9XTn6yZmbB513SEzTFI6r1Clk AqWnbtNkiV/FLtVrjkIx+eu3AiIxD1Hh3oOfqMmqKHAl4/igyRBUYgADJO1wTuNrmjuZ bqkw== X-Gm-Message-State: ALoCoQkpNCVy3nyEx8JMhdW2TR9IObiFWy/Tf3WMOVBe4o16poOiQEq0H5rU2X8bARkt8ByKgtiH MIME-Version: 1.0 X-Received: by 10.140.98.11 with SMTP id n11mr13758334qge.83.1411593563340; Wed, 24 Sep 2014 14:19:23 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Wed, 24 Sep 2014 14:19:23 -0700 (PDT) In-Reply-To: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> Date: Wed, 24 Sep 2014 14:19:23 -0700 Message-ID: From: Andy Bierman To: Dean Bogdanovic Content-Type: multipart/alternative; boundary=001a113ac3a0e926a90503d63c68 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xkTgNI570S_k3EPz1lGAj8KRDf4 Cc: Susan Hares , "netmod@ietf.org" , "i2rs@ietf.org" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:19:27 -0000 --001a113ac3a0e926a90503d63c68 Content-Type: text/plain; charset=ISO-8859-1 On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic wrote: > > On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > wrote: > > > > > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > wrote: > > > >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >> [...] > >>>> > >>>> +-----------------+ > >>>> | | > >>>> +--- (+) ---+ | > >>>> ^ ^ v > >>>> +---+ +---+ +---+ > >>>> | | | | | | > >>>> |(1)| | | | | > >>>> | | | | | | > >>>> +---+ +---+ +---+ > >>>> > >>>> NC config ephemeral operational > >>>> datastore datastore state > >>>> > >>>> (1) The complete NC config datastore is at certain synchronization > >>>> points made persistent > >>>> > >>>> (+) Priority resolution, priorities may be per datastore or per > >>>> user or per 'application' or even per data node > >>> > >>> These are precisely the qualities I and some others were thinking > of when we started i2rs. The idea is quite simple, as you have said above > and really needs not be complicated more. > >> > >> It has its own complications. > >> > >> Do we permit more than one ephemeral datastore? If so, this simplifies > data > >> object priority when resolving the operational state. But this also > >> complicates operational state integrity when you have multiple cross > > > > I vote for keeping this simple for starters. Lets get an > implementation or two of a single ephemeral data store. This avoids having > multiple priorities too; its just 1. > > > > --Tom > We can allow multiple ephemeral data stores, but the only dependency can > be with the NC config datastore. Example: > > residential services > business services > > What does this really mean? I did not understand the details at the interim. Does this mean each datastore has separate data models? Does this mean each service represent separate I2RS clients? The only real reason to have multiple ephemeral datastores would be to create the same instances of 1 or more data nodes in multiple datastores. (multiple concurrent overlays). IMO this sort of complexity should be left out of the agent. each of the configuration sits in their own ephemeral datastore, but only > dependency is on NC config store. > > As we are still keeping 1 to 1 overlay, not many to 1. > Dean > > Andy > > > > > >> references. > >> > >> -- Jeff > >> > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > --001a113ac3a0e926a90503d63c68 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic <= deanb@juniper.net> wrote:

On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

>
> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:<= br> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
>> [...]
>>>>
>>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0+-----------------+
>>>>=A0 =A0 =A0 =A0 =A0 =A0 =A0|=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0|
>>>>=A0 =A0 =A0 =A0+--- (+) ---+=A0 =A0 =A0 =A0 =A0 =A0|
>>>>=A0 =A0 =A0 =A0^=A0 =A0 =A0 =A0 =A0 =A0^=A0 =A0 =A0 =A0 =A0= =A0v
>>>>=A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+ >>>>=A0 =A0 =A0|=A0 =A0|=A0 =A0 =A0 =A0|=A0 =A0|=A0 =A0 =A0 =A0= |=A0 =A0|
>>>>=A0 =A0 =A0|(1)|=A0 =A0 =A0 =A0|=A0 =A0|=A0 =A0 =A0 =A0|=A0= =A0|
>>>>=A0 =A0 =A0|=A0 =A0|=A0 =A0 =A0 =A0|=A0 =A0|=A0 =A0 =A0 =A0= |=A0 =A0|
>>>>=A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+=A0 =A0 =A0 =A0+---+ >>>>
>>>>=A0 =A0NC config=A0 ephemeral=A0 =A0 operational
>>>>=A0 =A0datastore=A0 datastore=A0 =A0 =A0 state
>>>>
>>>>=A0 (1) The complete NC config datastore is at certain sync= hronization
>>>>=A0 points made persistent
>>>>
>>>>=A0 (+) Priority resolution, priorities may be per datastor= e or per
>>>>=A0 user or per 'application' or even per data node=
>>>
>>>=A0 =A0 =A0These are precisely the qualities I and some others = were thinking of when we started i2rs. The idea is quite simple, as you hav= e said above and really needs not be complicated more.
>>
>> It has its own complications.
>>
>> Do we permit more than one ephemeral datastore?=A0 If so, this sim= plifies data
>> object priority when resolving the operational state.=A0 But this = also
>> complicates operational state integrity when you have multiple cro= ss
>
>=A0 =A0 =A0 =A0I vote for keeping this simple for starters. Lets get an= implementation or two of a single ephemeral data store. This avoids having= multiple priorities too; its just 1.
>
>=A0 =A0 =A0 =A0--Tom
We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example:

residential services
business services



What does this really m= ean?
I did not understand the details at the interim.
D= oes this mean each datastore has separate data models?
Does this = mean each service represent separate I2RS clients?

The only real reason to have multiple ephemeral datastores
would= be to create the same instances of 1 or more data nodes
in multi= ple datastores. (multiple concurrent overlays).

IM= O this sort of complexity should be left out of the agent.


each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.

As we are still keeping 1 to 1 overlay, not many to 1.=A0

Dean



Andy
=A0
>
>
>> references.
>>
>> -- Jeff
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs

--001a113ac3a0e926a90503d63c68-- From nobody Wed Sep 24 14:51:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 972501A031F; Wed, 24 Sep 2014 14:51:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 wOEk3CXTmjOT; Wed, 24 Sep 2014 14:51:14 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 8EFA31A06FD; Wed, 24 Sep 2014 14:51:14 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id C982F289F2FB; Wed, 24 Sep 2014 17:51:13 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> Date: Wed, 24 Sep 2014 17:51:09 -0400 Message-Id: <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/DcPyEqTbpxYGw6hFVJ_GWBIshYU Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 21:51:18 -0000 --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Why not start with just 1? On Sep 24, 2014:5:00 PM, at 5:00 PM, Dean Bogdanovic = wrote: >=20 > On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau = wrote: >=20 >>=20 >> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas = wrote: >>=20 >>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder = wrote: >>> [...] >>>>>=20 >>>>> +-----------------+ >>>>> | | >>>>> +--- (+) ---+ | >>>>> ^ ^ v >>>>> +---+ +---+ +---+ >>>>> | | | | | | >>>>> |(1)| | | | | >>>>> | | | | | | >>>>> +---+ +---+ +---+ >>>>>=20 >>>>> NC config ephemeral operational >>>>> datastore datastore state >>>>>=20 >>>>> (1) The complete NC config datastore is at certain synchronization >>>>> points made persistent >>>>>=20 >>>>> (+) Priority resolution, priorities may be per datastore or per >>>>> user or per 'application' or even per data node >>>>=20 >>>> These are precisely the qualities I and some others were = thinking of when we started i2rs. The idea is quite simple, as you have = said above and really needs not be complicated more. =20 >>>=20 >>> It has its own complications. >>>=20 >>> Do we permit more than one ephemeral datastore? If so, this = simplifies data >>> object priority when resolving the operational state. But this also >>> complicates operational state integrity when you have multiple cross >>=20 >> I vote for keeping this simple for starters. Lets get an = implementation or two of a single ephemeral data store. This avoids = having multiple priorities too; its just 1. >>=20 >> --Tom > We can allow multiple ephemeral data stores, but the only dependency = can be with the NC config datastore. Example: >=20 > residential services > business services >=20 > each of the configuration sits in their own ephemeral datastore, but = only dependency is on NC config store.=20 >=20 > As we are still keeping 1 to 1 overlay, not many to 1. >=20 > Dean >=20 >>=20 >>=20 >>> references. >>>=20 >>> -- Jeff >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUIzzNAAoJEPcO+I7eiUJZm3kQAI3S1lVULf4IEVrFAF173jsz jZDFLGfhDEkJlZK2MaPKUmC3hTO5XNpkha4Ta2+wRaGtxcmyILR3LjleaAuB4RmT Bm6zuJV8dOUTKy36AP6zqgHdlZQILyR18Z1l6YVupTVkYoEbaMaPDkc8hN0eH31Y SBYOaQx0ivHwh1nNY+Wp2sbQllod90WQm2hniPBbWOdEi9Ib3HlfpV2EozPe9pn8 BeUtzVV6Ys1b8Q8gyKN7Wh/DOj1aybI/dV8A5o95N/AWLuzDVYie0TN6y7DL4H87 mHC6fSCfaGg6TH4A/dL4ZJ2sp4DGxfBi6IbyKdNrW8b8unqWsQhYe6apBxw33/ej jR1ChjRWG468Iob7UKIupYsPWz4/Blv+k04rCbgR5fk3+l02ORvzbl/0vD7mxb/F 0uTbZ/orLQJnU48+9TEVYmN1n8+JGYjZhKSz1JLEoOJDVpm8nDuoknIZ/36gIyNJ 0mWUaHqKvwGsew9geFojKni0uJDXCSDF673NLOKjmAL3tn6a7AlK/1jHbDJGTn4Q c8dTYWZExcF/xYtm4InmZ4ZdG2F5ixwG68LYrAsx6VBryGe1VWypxTCEkokP71KY P1LBoziDX4Bxn3NUvNAEV2gNP657JEhtwCsvm5PtqiOURCjWx2MkiMpH9MAUW0Z+ C0jIzJZ9vNk7H3bbmPCY =1Kg2 -----END PGP SIGNATURE----- --Apple-Mail=_9F7F45E2-8575-443F-9B71-AD19147A4D03-- From nobody Wed Sep 24 18:42:55 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4E951A6EFC; Wed, 24 Sep 2014 18:42:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 BqQPDvNLHbot; Wed, 24 Sep 2014 18:42:50 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0123.outbound.protection.outlook.com [207.46.100.123]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF7FC1A6EFE; Wed, 24 Sep 2014 18:42:49 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB044.namprd05.prod.outlook.com (10.255.202.154) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 01:42:49 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 01:42:47 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 01:42:47 +0000 From: Dean Bogdanovic To: "Thomas D. Nadeau" Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP1qkCvY2EU2y81E2yFJqHoPh2n5wPShsAgACVywCAAEolgIAAQpCAgAAWiICAAETKAIAADg2AgABAtgA= Date: Thu, 25 Sep 2014 01:42:47 +0000 Message-ID: <0DB06D85-18C3-4874-90D5-3305057CF7C3@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> In-Reply-To: <9EEC8F6A-DC47-434D-A41E-CDC1D2C6DC4F@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(377454003)(199003)(24454002)(189002)(93916002)(86362001)(99396003)(90102001)(76482002)(106356001)(106116001)(77096002)(10300001)(77156001)(76176999)(92726001)(92566001)(97736003)(36756003)(120916001)(15975445006)(31966008)(50986999)(82746002)(19580395003)(57306001)(19580405001)(66066001)(101416001)(107046002)(79102003)(83322001)(74502003)(81342003)(33656002)(64706001)(74662003)(46102003)(77982003)(4396001)(80022003)(81542003)(50226001)(104166001)(83072002)(20776003)(89996001)(88136002)(87936001)(105586002)(2656002)(62966002)(99286002)(85306004)(95666004)(83716003)(93886004)(85852003)(87286001)(110136001)(21056001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB044; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/_n7d_f8_9f_dfnOKNXnvAxDhPCg Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:42:52 -0000 Tom, I'm in favor of starting with one, but can see use cases for more. Please k= eep in mind that in case for more ephemeral data stores, they will all have= same schema, but different models in ephemeral stores. There will be no de= pendencies between ephemeral data stores. Dean On Sep 24, 2014, at 5:51 PM, Thomas D. Nadeau wro= te: > Why not start with just 1? >=20 > On Sep 24, 2014:5:00 PM, at 5:00 PM, Dean Bogdanovic = wrote: >=20 >>=20 >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau = wrote: >>=20 >>>=20 >>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas wr= ote: >>>=20 >>>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: >>>> [...] >>>>>>=20 >>>>>> +-----------------+ >>>>>> | | >>>>>> +--- (+) ---+ | >>>>>> ^ ^ v >>>>>> +---+ +---+ +---+ >>>>>> | | | | | | >>>>>> |(1)| | | | | >>>>>> | | | | | | >>>>>> +---+ +---+ +---+ >>>>>>=20 >>>>>> NC config ephemeral operational >>>>>> datastore datastore state >>>>>>=20 >>>>>> (1) The complete NC config datastore is at certain synchronization >>>>>> points made persistent >>>>>>=20 >>>>>> (+) Priority resolution, priorities may be per datastore or per >>>>>> user or per 'application' or even per data node >>>>>=20 >>>>> These are precisely the qualities I and some others were thinking of= when we started i2rs. The idea is quite simple, as you have said above and= really needs not be complicated more. =20 >>>>=20 >>>> It has its own complications. >>>>=20 >>>> Do we permit more than one ephemeral datastore? If so, this simplifie= s data >>>> object priority when resolving the operational state. But this also >>>> complicates operational state integrity when you have multiple cross >>>=20 >>> I vote for keeping this simple for starters. Lets get an implementatio= n or two of a single ephemeral data store. This avoids having multiple prio= rities too; its just 1. >>>=20 >>> --Tom >> We can allow multiple ephemeral data stores, but the only dependency can= be with the NC config datastore. Example: >>=20 >> residential services >> business services >>=20 >> each of the configuration sits in their own ephemeral datastore, but onl= y dependency is on NC config store.=20 >>=20 >> As we are still keeping 1 to 1 overlay, not many to 1. >>=20 >> Dean >>=20 >>>=20 >>>=20 >>>> references. >>>>=20 >>>> -- Jeff >>>>=20 >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >>=20 >=20 From nobody Wed Sep 24 18:48:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2070D1A6F04; Wed, 24 Sep 2014 18:48:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 dMcGGqMbsv7j; Wed, 24 Sep 2014 18:48:03 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0142.outbound.protection.outlook.com [207.46.100.142]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A51B1A6EFE; Wed, 24 Sep 2014 18:48:03 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB124.namprd05.prod.outlook.com (10.255.199.28) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Thu, 25 Sep 2014 01:48:02 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 01:48:01 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.90]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 01:48:01 +0000 From: Dean Bogdanovic To: Andy Bierman Thread-Topic: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP2D04ho2Qh+oBWEeVzhOAmMpnHZwRFP2A Date: Thu, 25 Sep 2014 01:48:01 +0000 Message-ID: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB424;UriScan:; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(24454002)(189002)(377454003)(51704005)(199003)(77982003)(46102003)(80022003)(4396001)(33656002)(81342003)(74662003)(64706001)(74502003)(83072002)(20776003)(89996001)(50226001)(81542003)(16236675004)(104166001)(19617315012)(57306001)(19580405001)(19580395003)(83322001)(66066001)(101416001)(107046002)(79102003)(87286001)(110136001)(21056001)(105586002)(99286002)(2656002)(62966002)(88136002)(87936001)(83716003)(93886004)(85852003)(95666004)(85306004)(106116001)(106356001)(77096002)(93916002)(86362001)(76482002)(90102001)(99396003)(15975445006)(31966008)(97736003)(36756003)(120916001)(82746002)(50986999)(76176999)(77156001)(10300001)(92726001)(92566001)(104396001)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB424; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:ovrnspm; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_2384FE3B832540EA9C25B7A452564424junipernet_" MIME-Version: 1.0 X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB124; X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eHujD0i3xFNwRXZofEYhGizKE5o Cc: Susan Hares , "netmod@ietf.org" , "i2rs@ietf.org" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 01:48:06 -0000 --_000_2384FE3B832540EA9C25B7A452564424junipernet_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Sep 24, 2014, at 5:19 PM, Andy Bierman > wrote: On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic > wrote: On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > wrote: > > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > wrote: > >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder > wro= te: >> [...] >>>> >>>> +-----------------+ >>>> | | >>>> +--- (+) ---+ | >>>> ^ ^ v >>>> +---+ +---+ +---+ >>>> | | | | | | >>>> |(1)| | | | | >>>> | | | | | | >>>> +---+ +---+ +---+ >>>> >>>> NC config ephemeral operational >>>> datastore datastore state >>>> >>>> (1) The complete NC config datastore is at certain synchronization >>>> points made persistent >>>> >>>> (+) Priority resolution, priorities may be per datastore or per >>>> user or per 'application' or even per data node >>> >>> These are precisely the qualities I and some others were thinking o= f when we started i2rs. The idea is quite simple, as you have said above an= d really needs not be complicated more. >> >> It has its own complications. >> >> Do we permit more than one ephemeral datastore? If so, this simplifies = data >> object priority when resolving the operational state. But this also >> complicates operational state integrity when you have multiple cross > > I vote for keeping this simple for starters. Lets get an implementa= tion or two of a single ephemeral data store. This avoids having multiple p= riorities too; its just 1. > > --Tom We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example: residential services business services What does this really mean? I did not understand the details at the interim. Does this mean each datastore has separate data models? yes, each data store has separate data models Does this mean each service represent separate I2RS clients? each ephemeral datastore represents separate I2RS clients. The only real reason to have multiple ephemeral datastores would be to create the same instances of 1 or more data nodes in multiple datastores. (multiple concurrent overlays). I view it differently. In subscriber management different data models are u= sed for residential and business subscribers. Some service data models can = be very unique for business customers. So separating them in different data= stores makes sense, as they there are no overlaps with each other, only wi= th NC config store. In this case, we can get better performance. IMO this sort of complexity should be left out of the agent. each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store. As we are still keeping 1 to 1 overlay, not many to 1. Dean Andy > > >> references. >> >> -- Jeff >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs --_000_2384FE3B832540EA9C25B7A452564424junipernet_ Content-Type: text/html; charset="iso-8859-1" Content-ID: Content-Transfer-Encoding: quoted-printable
On Sep 24, 2014, at 5:19 PM, Andy Bierman <andy@yumaworks.com> wrote:



On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic= <deanb@juniper.ne= t> wrote:

On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:

>
> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas <jhaas@pfrc.org> wrote:
>
>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote:<= br> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder <= ;j.schoenwaelder@ja= cobs-university.de> wrote:
>> [...]
>>>>
>>>>             +------= -----------+
>>>>             |  &nb= sp;              |
>>>>       +--- (+) ---+  =          |
>>>>       ^        &nb= sp;  ^           v
>>>>     +---+       = ;+---+       +---+
>>>>     |   |      &nb= sp;|   |       |   |
>>>>     |(1)|       | =  |       |   |
>>>>     |   |      &nb= sp;|   |       |   |
>>>>     +---+       = ;+---+       +---+
>>>>
>>>>   NC config  ephemeral    operati= onal
>>>>   datastore  datastore      = state
>>>>
>>>>  (1) The complete NC config datastore is at certain s= ynchronization
>>>>  points made persistent
>>>>
>>>>  (+) Priority resolution, priorities may be per d= atastore or per
>>>>  user or per 'application' or even per data node
>>>
>>>     These are precisely the qualities I and som= e others were thinking of when we started i2rs. The idea is quite simple, a= s you have said above and really needs not be complicated more.
>>
>> It has its own complications.
>>
>> Do we permit more than one ephemeral datastore?  If so, this = simplifies data
>> object priority when resolving the operational state.  But th= is also
>> complicates operational state integrity when you have multiple cro= ss
>
>       I vote for keeping this simple for starters.= Lets get an implementation or two of a single ephemeral data store. This a= voids having multiple priorities too; its just 1.
>
>       --Tom
We can allow multiple ephemeral data stores, but the only dependency can be= with the NC config datastore. Example:

residential services
business services



What does this really mean?
I did not understand the details at the interim.
Does this mean each datastore has separate data models?

yes, each data store has separate data models
 
Does this mean each service represent separate I2RS clients?

each ephemeral datastore represents separate I2RS clients.


The only real reason to have multiple ephemeral datastores
would be to create the same instances of 1 or more data nodes
in multiple datastores. (multiple concurrent overlays).

I view it differently. In subscriber management different data models are u= sed for residential and business subscribers. Some service data models can = be very unique for business customers. So separating them in different data= stores makes sense, as they there are no overlaps with each other, only with NC config store. In this case, = we can get better performance.

IMO this sort of complexity should be left out of the agent.


each of the configuration sits in their own ephemeral datastore, but only d= ependency is on NC config store.

As we are still keeping 1 to 1 overlay, not many to 1. 

Dean



Andy
 
>
>
>> references.
>>
>> -- Jeff
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

_______________________________________________
i2rs mailing list
i2rs@ietf.org
ht= tps://www.ietf.org/mailman/listinfo/i2rs


--_000_2384FE3B832540EA9C25B7A452564424junipernet_-- From nobody Wed Sep 24 23:25:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB08C1A6F7E; Wed, 24 Sep 2014 23:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 R9dAnmNqm4rk; Wed, 24 Sep 2014 23:25:01 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34A2E1A1A8C; Wed, 24 Sep 2014 23:25:01 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00BB8111C; Thu, 25 Sep 2014 08:24:59 +0200 (CEST) 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 9xNw2V21zELW; Thu, 25 Sep 2014 08:24:56 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 08:24:59 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E9B1F20036; Thu, 25 Sep 2014 08:24:58 +0200 (CEST) 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 S2sn7dScftCz; Thu, 25 Sep 2014 08:24:57 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0EE0520035; Thu, 25 Sep 2014 08:24:56 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id E63802E88E2F; Thu, 25 Sep 2014 08:24:56 +0200 (CEST) Date: Thu, 25 Sep 2014 08:24:56 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140925062456.GB26200@elstar.local> Mail-Followup-To: Jeffrey Haas , "Thomas D. Nadeau" , i2rs@ietf.org, Susan Hares , netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924153401.GC2639@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/eHvgZzgS6plBz80O2GchDomWu-w Cc: netmod@ietf.org, Susan Hares , i2rs@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 06:25:02 -0000 On Wed, Sep 24, 2014 at 11:34:01AM -0400, Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: > [...] > > > > > > +-----------------+ > > > | | > > > +--- (+) ---+ | > > > ^ ^ v > > > +---+ +---+ +---+ > > > | | | | | | > > > |(1)| | | | | > > > | | | | | | > > > +---+ +---+ +---+ > > > > > > NC config ephemeral operational > > > datastore datastore state > > > > > > (1) The complete NC config datastore is at certain synchronization > > > points made persistent > > > > > > (+) Priority resolution, priorities may be per datastore or per > > > user or per 'application' or even per data node > > > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. > > It has its own complications. > > Do we permit more than one ephemeral datastore? If so, this simplifies data > object priority when resolving the operational state. But this also > complicates operational state integrity when you have multiple cross > references. It complicates the merge operation - it does not affect the integrity of the operational state. But even that may not be true, at least not from the point of the merge algorithm. There likely is not much difference between merging 1 or N ephemeral datastores. And at the end of the day, if you have I2RS systems injecting conflicts, then it does not matter whether that happens in 1 ephemeral datastore and N ephemeral datastores. Having N ephemeral datastores had the advantage that I can easily disable a complete ephemeral datastore by modifying its priority while multiple I2RS systems writing concurrently into the same scratchpad will be much more fun to deal with. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Wed Sep 24 23:32:33 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB9041A6F82; Wed, 24 Sep 2014 23:32:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 tLqD3Daxm6y5; Wed, 24 Sep 2014 23:32:29 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21B161A1AC6; Wed, 24 Sep 2014 23:32:29 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id DFE8D111C; Thu, 25 Sep 2014 08:32:27 +0200 (CEST) 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 FGvQi8pew4Xg; Thu, 25 Sep 2014 08:32:24 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 08:32:26 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id DAE0E20036; Thu, 25 Sep 2014 08:32:26 +0200 (CEST) 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 x9UB7gFQlAXJ; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 322E220035; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 2E0682E88E76; Thu, 25 Sep 2014 08:32:25 +0200 (CEST) Date: Thu, 25 Sep 2014 08:32:25 +0200 From: Juergen Schoenwaelder To: Jeffrey Haas Message-ID: <20140925063225.GC26200@elstar.local> Mail-Followup-To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140924153802.GD2639@pfrc> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/rfr8tjMdV2UuwIu8Ce1J5lS_1zo Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 06:32:32 -0000 On Wed, Sep 24, 2014 at 11:38:02AM -0400, Jeffrey Haas wrote: > > > > I do not follow here. The secure transport delivers what NETCONF calls > > a username, the identity of the NETCONF client. If this client acts on > > behalf of another application (the secondary identity), then this > > identity is meta data should be attached to the information submitted > > to the ephemeral datastore. I do not see why this would lead to any > > changes to SSH or TLS. > > I tried to raise this as a question during the interim, but I think it was > lost. How should the meta-data be transported? > Likely as meta-data attributes. https://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > The primary ones I am aware of are operations on network addresses and > prefixes. Was netmod looking for an explicit manifest of such operations? We are happy to receive input. A starting point is here. http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 This I-D, however, does not define functions for network addresses. > This may have overlap in the work for the ACL module that is already a > netmod document. I am lost here. I do not see how additional xpath functions related to the NACM (which came out of NETCONF not NETMOD). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 25 03:12:07 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39A9B1A6F62; Thu, 25 Sep 2014 03:12:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 PZjUEtISPZ_p; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0F7C1A1A5D; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 547161C064D; Thu, 25 Sep 2014 03:12:04 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [118.143.25.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 8D73A1C062D; Thu, 25 Sep 2014 03:12:02 -0700 (PDT) Message-ID: <5423EA70.7070907@joelhalpern.com> Date: Thu, 25 Sep 2014 06:12:00 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic , Andy Bierman References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> In-Reply-To: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/VtAWJBe2CpZIJFYXwPcujkr_Wwc Cc: "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:12:06 -0000 Separate ephemeral data stores for distinct I2RS clients would seem a very bad idea. It is perfectly acceptable for one client to read information being manipulated by another cleitn. And if so, the reader should see the results of that other clients activity. Also, separate stores would not produce the error results required in the case of collision. So no, I do not see a use case from I2RS for multiple ephemeral data stores. Yours, Joel On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: > > On Sep 24, 2014, at 5:19 PM, Andy Bierman > wrote: > >> >> >> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic > > wrote: >> >> >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >> > wrote: >> >> > >> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >> > wrote: >> > >> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >> > > wrote: >> >> [...] >> >>>> >> >>>> +-----------------+ >> >>>> | | >> >>>> +--- (+) ---+ | >> >>>> ^ ^ v >> >>>> +---+ +---+ +---+ >> >>>> | | | | | | >> >>>> |(1)| | | | | >> >>>> | | | | | | >> >>>> +---+ +---+ +---+ >> >>>> >> >>>> NC config ephemeral operational >> >>>> datastore datastore state >> >>>> >> >>>> (1) The complete NC config datastore is at certain >> synchronization >> >>>> points made persistent >> >>>> >> >>>> (+) Priority resolution, priorities may be per datastore or per >> >>>> user or per 'application' or even per data node >> >>> >> >>> These are precisely the qualities I and some others were >> thinking of when we started i2rs. The idea is quite simple, as you >> have said above and really needs not be complicated more. >> >> >> >> It has its own complications. >> >> >> >> Do we permit more than one ephemeral datastore? If so, this >> simplifies data >> >> object priority when resolving the operational state. But this >> also >> >> complicates operational state integrity when you have multiple >> cross >> > >> > I vote for keeping this simple for starters. Lets get an >> implementation or two of a single ephemeral data store. This >> avoids having multiple priorities too; its just 1. >> > >> > --Tom >> We can allow multiple ephemeral data stores, but the only >> dependency can be with the NC config datastore. Example: >> >> residential services >> business services >> >> >> >> What does this really mean? >> I did not understand the details at the interim. >> Does this mean each datastore has separate data models? > > yes, each data store has separate data models > >> Does this mean each service represent separate I2RS clients? > > each ephemeral datastore represents separate I2RS clients. > >> >> The only real reason to have multiple ephemeral datastores >> would be to create the same instances of 1 or more data nodes >> in multiple datastores. (multiple concurrent overlays). > > I view it differently. In subscriber management different data models > are used for residential and business subscribers. Some service data > models can be very unique for business customers. So separating them in > different data stores makes sense, as they there are no overlaps with > each other, only with NC config store. In this case, we can get better > performance. >> >> IMO this sort of complexity should be left out of the agent. >> >> >> each of the configuration sits in their own ephemeral datastore, >> but only dependency is on NC config store. >> >> As we are still keeping 1 to 1 overlay, not many to 1. >> >> >> Dean >> >> >> >> Andy >> >> > >> > >> >> references. >> >> >> >> -- Jeff >> >> >> > >> > _______________________________________________ >> > netmod mailing list >> > netmod@ietf.org >> > https://www.ietf.org/mailman/listinfo/netmod >> >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >> >> > > > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Thu Sep 25 03:26:51 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 535121A1C04; Thu, 25 Sep 2014 03:26:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 JE3bHd3sGTpj; Thu, 25 Sep 2014 03:26:47 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 392871A01F6; Thu, 25 Sep 2014 03:26:47 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 09D086F5; Thu, 25 Sep 2014 12:26:46 +0200 (CEST) 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 d4AFDhBVxi53; Thu, 25 Sep 2014 12:26:41 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Thu, 25 Sep 2014 12:26:44 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4811820037; Thu, 25 Sep 2014 12:26:44 +0200 (CEST) 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 Xm_2qWgc0RSm; Thu, 25 Sep 2014 12:26:42 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 546BF20035; Thu, 25 Sep 2014 12:26:41 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 1D2612E89517; Thu, 25 Sep 2014 12:26:40 +0200 (CEST) Date: Thu, 25 Sep 2014 12:26:40 +0200 From: Juergen Schoenwaelder To: "Joel M. Halpern" Message-ID: <20140925102640.GA27142@elstar.local> Mail-Followup-To: "Joel M. Halpern" , Dean Bogdanovic , Andy Bierman , "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5423EA70.7070907@joelhalpern.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/aP5U46U5-IxyAJh62P6VHYxt1lQ Cc: "i2rs@ietf.org" , Susan Hares , "netmod@ietf.org" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:26:50 -0000 Joel, my expectations about the intelligence of I2RS clients is perhaps lower than yours. Do you really believe I2RS clients will be smart to adapt to whatever some other unknown conflicting I2RS client injects into a shared ephemeral datastore? I do not expect smartness. My hope is that I2RS clients involved in a conflict can be signalled and probably more important that a human operator can be signalled that I2RS clients step into each other so that a human can take action to resolve things. Automatic conflict resultion based on observation what state is injected by other I2RS clients seems to me a huge (idealistic) assumption. I would find conflict detection during the merge operation likely more reliable than conflict detection based on smart I2RS clients monitoring closely what is going on in a shared datastore. I assume there will be dumb I2RS clients. /js On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: > Separate ephemeral data stores for distinct I2RS clients would seem a > very bad idea. > It is perfectly acceptable for one client to read information being > manipulated by another cleitn. And if so, the reader should see the > results of that other clients activity. > > Also, separate stores would not produce the error results required in > the case of collision. > > So no, I do not see a use case from I2RS for multiple ephemeral data stores. > > Yours, > Joel > > On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: > > > >On Sep 24, 2014, at 5:19 PM, Andy Bierman >> wrote: > > > >> > >> > >>On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> wrote: > >> > >> > >> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau > >> > wrote: > >> > >> > > >> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas > >> > wrote: > >> > > >> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > >> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder > >> >> > wrote: > >> >> [...] > >> >>>> > >> >>>> +-----------------+ > >> >>>> | | > >> >>>> +--- (+) ---+ | > >> >>>> ^ ^ v > >> >>>> +---+ +---+ +---+ > >> >>>> | | | | | | > >> >>>> |(1)| | | | | > >> >>>> | | | | | | > >> >>>> +---+ +---+ +---+ > >> >>>> > >> >>>> NC config ephemeral operational > >> >>>> datastore datastore state > >> >>>> > >> >>>> (1) The complete NC config datastore is at certain > >> synchronization > >> >>>> points made persistent > >> >>>> > >> >>>> (+) Priority resolution, priorities may be per datastore or per > >> >>>> user or per 'application' or even per data node > >> >>> > >> >>> These are precisely the qualities I and some others were > >> thinking of when we started i2rs. The idea is quite simple, as you > >> have said above and really needs not be complicated more. > >> >> > >> >> It has its own complications. > >> >> > >> >> Do we permit more than one ephemeral datastore? If so, this > >> simplifies data > >> >> object priority when resolving the operational state. But this > >> also > >> >> complicates operational state integrity when you have multiple > >> cross > >> > > >> > I vote for keeping this simple for starters. Lets get an > >> implementation or two of a single ephemeral data store. This > >> avoids having multiple priorities too; its just 1. > >> > > >> > --Tom > >> We can allow multiple ephemeral data stores, but the only > >> dependency can be with the NC config datastore. Example: > >> > >> residential services > >> business services > >> > >> > >> > >>What does this really mean? > >>I did not understand the details at the interim. > >>Does this mean each datastore has separate data models? > > > >yes, each data store has separate data models > > > >>Does this mean each service represent separate I2RS clients? > > > >each ephemeral datastore represents separate I2RS clients. > > > >> > >>The only real reason to have multiple ephemeral datastores > >>would be to create the same instances of 1 or more data nodes > >>in multiple datastores. (multiple concurrent overlays). > > > >I view it differently. In subscriber management different data models > >are used for residential and business subscribers. Some service data > >models can be very unique for business customers. So separating them in > >different data stores makes sense, as they there are no overlaps with > >each other, only with NC config store. In this case, we can get better > >performance. > >> > >>IMO this sort of complexity should be left out of the agent. > >> > >> > >> each of the configuration sits in their own ephemeral datastore, > >> but only dependency is on NC config store. > >> > >> As we are still keeping 1 to 1 overlay, not many to 1. > >> > >> > >> Dean > >> > >> > >> > >>Andy > >> > >> > > >> > > >> >> references. > >> >> > >> >> -- Jeff > >> >> > >> > > >> > _______________________________________________ > >> > netmod mailing list > >> > netmod@ietf.org > >> > https://www.ietf.org/mailman/listinfo/netmod > >> > >> _______________________________________________ > >> i2rs mailing list > >> i2rs@ietf.org > >> https://www.ietf.org/mailman/listinfo/i2rs > >> > >> > > > > > > > >_______________________________________________ > >i2rs mailing list > >i2rs@ietf.org > >https://www.ietf.org/mailman/listinfo/i2rs > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 From nobody Thu Sep 25 03:33:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD0EE1A6F61; Thu, 25 Sep 2014 03:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 JmnZD16uQHtG; Thu, 25 Sep 2014 03:33:14 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 638881A1C04; Thu, 25 Sep 2014 03:33:14 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id A73311280934; Thu, 25 Sep 2014 12:33:13 +0200 (CEST) Date: Thu, 25 Sep 2014 12:33:13 +0200 (CEST) Message-Id: <20140925.123313.352492571894922280.mbj@tail-f.com> To: jhaas@pfrc.org From: Martin Bjorklund In-Reply-To: <20140924153802.GD2639@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> 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/netmod/JKQQsXeD9Y7JGOt2Gxi7web8Ya4 Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:33:15 -0000 Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 09:00:26AM +0200, Juergen Schoenwaelder wrote: > > > It is noted, however, that introducing something like a secondary identity > > > would require changes to SSH and/or TLS and may be somewhat difficult to > > > make the case to the owning working groups. > > > > I do not follow here. The secure transport delivers what NETCONF calls > > a username, the identity of the NETCONF client. If this client acts on > > behalf of another application (the secondary identity), then this > > identity is meta data should be attached to the information submitted > > to the ephemeral datastore. I do not see why this would lead to any > > changes to SSH or TLS. > > I tried to raise this as a question during the interim, but I think it was > lost. How should the meta-data be transported? In general, NETCONF / RESTCONF with YANG supports the concept of meta-data, and meta-data is in XML transported as an XML attribute. (For JSON encoding see http://tools.ietf.org/id/draft-lhotka-netmod-yang-metadata-00.txt) > > > Some discussion was given to the filtering considerations. Extending the > > > filtering options of the ietf-inet-types module may be appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > The primary ones I am aware of are operations on network addresses and > prefixes. Was netmod looking for an explicit manifest of such operations? Yes this would help. /martin From nobody Thu Sep 25 03:39:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 989841A6F61; Thu, 25 Sep 2014 03:39:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 4vOLBM38JTEn; Thu, 25 Sep 2014 03:39:31 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 8BD4B1A1C04; Thu, 25 Sep 2014 03:39:31 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id CB0791280934; Thu, 25 Sep 2014 12:39:30 +0200 (CEST) Date: Thu, 25 Sep 2014 12:39:30 +0200 (CEST) Message-Id: <20140925.123930.1268640776659322434.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/cA093BVa_crI5-PUZbPyKr2Dbyc Cc: netmod@ietf.org, i2rs@ietf.org, shares@ndzh.com Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 10:39:32 -0000 Dean Bogdanovic wrote: > > On Sep 24, 2014, at 5:19 PM, Andy Bierman > > wrote: > We can allow multiple ephemeral data stores, but the only dependency > can be with the NC config datastore. Example: > > residential services > business services > > > > > What does this really mean? > > I did not understand the details at the interim. > > Does this mean each datastore has separate data models? > > yes, each data store has separate data models Now I am confused. At the interim we agreed (and you argued for :) that the schema (= data models) is the same for the config and ephemeral datastore. > I view it differently. In subscriber management different data models > are used for residential and business subscribers. Some service data > models can be very unique for business customers. Ok. > So separating them > in different data stores makes sense, as they there are no overlaps > with each other, only with NC config store. But since they are disjoint, there are really no reasons for not keeping them in the same datastore, since there will be no conflicts. > In this case, we can get > better performance. I can't see why, but this is probably an implementation issue. /martin From nobody Thu Sep 25 04:14:28 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 798421A02EA; Thu, 25 Sep 2014 04:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 Bu8WN-rJa_GH; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E0D871A1A8A; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id C772F1C062D; Thu, 25 Sep 2014 04:14:25 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net Received: from Joels-MacBook-Pro.local (unknown [118.143.25.125]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 288221C0565; Thu, 25 Sep 2014 04:14:23 -0700 (PDT) Message-ID: <5423F90D.3050104@joelhalpern.com> Date: Thu, 25 Sep 2014 07:14:21 -0400 From: "Joel M. Halpern" User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Dean Bogdanovic , Andy Bierman , "netmod@ietf.org" , Susan Hares , "i2rs@ietf.org" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> In-Reply-To: <20140925102640.GA27142@elstar.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/3LdLQSyr7yNorh-40zh5Va23SHw Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 11:14:27 -0000 (I believe that your talking about dumb clients is because I2RS and NetCONF YANG use terms differently. In I2RS, the Agent is the thing in the box, and the Client is the smarter things outside the box.) We wrote very specific rules into the architecture document the WG adopted, specifically because we wanted to bound the expected intelligence of the I2RS Agent. The agent is required to detect collision. It is required to generate error notification upon collision. It is also required to use the priority mechanism to produce a predictable composite result in the case of collision. The odds of that result being what the human beings want is pretty small But it is predictable. Which is all we felt we could ask for. Yours, Joel On 9/25/14, 6:26 AM, Juergen Schoenwaelder wrote: > Joel, > > my expectations about the intelligence of I2RS clients is perhaps > lower than yours. Do you really believe I2RS clients will be smart to > adapt to whatever some other unknown conflicting I2RS client injects > into a shared ephemeral datastore? > > I do not expect smartness. My hope is that I2RS clients involved in a > conflict can be signalled and probably more important that a human > operator can be signalled that I2RS clients step into each other so > that a human can take action to resolve things. Automatic conflict > resultion based on observation what state is injected by other I2RS > clients seems to me a huge (idealistic) assumption. > > I would find conflict detection during the merge operation likely > more reliable than conflict detection based on smart I2RS clients > monitoring closely what is going on in a shared datastore. > > I assume there will be dumb I2RS clients. > > /js > > On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: >> Separate ephemeral data stores for distinct I2RS clients would seem a >> very bad idea. >> It is perfectly acceptable for one client to read information being >> manipulated by another cleitn. And if so, the reader should see the >> results of that other clients activity. >> >> Also, separate stores would not produce the error results required in >> the case of collision. >> >> So no, I do not see a use case from I2RS for multiple ephemeral data stores. >> >> Yours, >> Joel >> >> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>> >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >>> >>>> >>>> >>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> > wrote: >>>> >>>> >>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>>> > wrote: >>>> >>>> > >>>> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>>> > wrote: >>>> > >>>> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>>> >>> > wrote: >>>> >> [...] >>>> >>>> >>>> >>>> +-----------------+ >>>> >>>> | | >>>> >>>> +--- (+) ---+ | >>>> >>>> ^ ^ v >>>> >>>> +---+ +---+ +---+ >>>> >>>> | | | | | | >>>> >>>> |(1)| | | | | >>>> >>>> | | | | | | >>>> >>>> +---+ +---+ +---+ >>>> >>>> >>>> >>>> NC config ephemeral operational >>>> >>>> datastore datastore state >>>> >>>> >>>> >>>> (1) The complete NC config datastore is at certain >>>> synchronization >>>> >>>> points made persistent >>>> >>>> >>>> >>>> (+) Priority resolution, priorities may be per datastore or per >>>> >>>> user or per 'application' or even per data node >>>> >>> >>>> >>> These are precisely the qualities I and some others were >>>> thinking of when we started i2rs. The idea is quite simple, as you >>>> have said above and really needs not be complicated more. >>>> >> >>>> >> It has its own complications. >>>> >> >>>> >> Do we permit more than one ephemeral datastore? If so, this >>>> simplifies data >>>> >> object priority when resolving the operational state. But this >>>> also >>>> >> complicates operational state integrity when you have multiple >>>> cross >>>> > >>>> > I vote for keeping this simple for starters. Lets get an >>>> implementation or two of a single ephemeral data store. This >>>> avoids having multiple priorities too; its just 1. >>>> > >>>> > --Tom >>>> We can allow multiple ephemeral data stores, but the only >>>> dependency can be with the NC config datastore. Example: >>>> >>>> residential services >>>> business services >>>> >>>> >>>> >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>> >>> yes, each data store has separate data models >>> >>>> Does this mean each service represent separate I2RS clients? >>> >>> each ephemeral datastore represents separate I2RS clients. >>> >>>> >>>> The only real reason to have multiple ephemeral datastores >>>> would be to create the same instances of 1 or more data nodes >>>> in multiple datastores. (multiple concurrent overlays). >>> >>> I view it differently. In subscriber management different data models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. So separating them in >>> different data stores makes sense, as they there are no overlaps with >>> each other, only with NC config store. In this case, we can get better >>> performance. >>>> >>>> IMO this sort of complexity should be left out of the agent. >>>> >>>> >>>> each of the configuration sits in their own ephemeral datastore, >>>> but only dependency is on NC config store. >>>> >>>> As we are still keeping 1 to 1 overlay, not many to 1. >>>> >>>> >>>> Dean >>>> >>>> >>>> >>>> Andy >>>> >>>> > >>>> > >>>> >> references. >>>> >> >>>> >> -- Jeff >>>> >> >>>> > >>>> > _______________________________________________ >>>> > netmod mailing list >>>> > netmod@ietf.org >>>> > https://www.ietf.org/mailman/listinfo/netmod >>>> >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>> >>>> >>> >>> >>> >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Sep 25 05:19:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73D6B1A6FC4; Thu, 25 Sep 2014 05:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 o7ljS7u_ZPW0; Thu, 25 Sep 2014 05:19:13 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4CB1A6FBE; Thu, 25 Sep 2014 05:19:12 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id DC35728A0088; Thu, 25 Sep 2014 08:19:11 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <5423EA70.7070907@joelhalpern.com> Date: Thu, 25 Sep 2014 08:19:06 -0400 Message-Id: <9CFB901E-F91F-4B65-A968-12E9E0038A3C@lucidvision.com> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> To: "Joel M. Halpern" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/deqIjRwDYbm8Q1b0d9Ah8nOsgsE Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:19:14 -0000 --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:6:12 AM, at 6:12 AM, Joel M. Halpern = wrote: > Separate ephemeral data stores for distinct I2RS clients would seem a = very bad idea. > It is perfectly acceptable for one client to read information being = manipulated by another cleitn. And if so, the reader should see the = results of that other clients activity. I agree with Joel here. I was quite surprised by Dean's first = note making this statement. This seems like undue complication to the = whole situation. Making this work can be quite straight-forward. The = problem with having a store per-client is that well, clients can be = ephemeral too. People need to remember that the i2rs clients are = probably going to be applications that might come and go, and as such = should a device have to keep around a lot of state for everyone that = talks to it via its Rest/i2rs API? That does not sound like a good idea = to me, even if we time it out. > Also, separate stores would not produce the error results required in = the case of collision. Yes, that is precisely another issue that came to mind - besides = the scale of having one per client, do we really want to place the = burden on the device to let all clients know of collisions when merging? = What if those clients have "gone away"?=20 > So no, I do not see a use case from I2RS for multiple ephemeral data = stores. Agree %100. --Tom >=20 > Yours, > Joel >=20 > On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>=20 >> On Sep 24, 2014, at 5:19 PM, Andy Bierman > > wrote: >>=20 >>>=20 >>>=20 >>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >> > wrote: >>>=20 >>>=20 >>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>> > wrote: >>>=20 >>> > >>> > On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>> > wrote: >>> > >>> >> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau = wrote: >>> >>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>> >> > wrote: >>> >> [...] >>> >>>> >>> >>>> +-----------------+ >>> >>>> | | >>> >>>> +--- (+) ---+ | >>> >>>> ^ ^ v >>> >>>> +---+ +---+ +---+ >>> >>>> | | | | | | >>> >>>> |(1)| | | | | >>> >>>> | | | | | | >>> >>>> +---+ +---+ +---+ >>> >>>> >>> >>>> NC config ephemeral operational >>> >>>> datastore datastore state >>> >>>> >>> >>>> (1) The complete NC config datastore is at certain >>> synchronization >>> >>>> points made persistent >>> >>>> >>> >>>> (+) Priority resolution, priorities may be per datastore or = per >>> >>>> user or per 'application' or even per data node >>> >>> >>> >>> These are precisely the qualities I and some others were >>> thinking of when we started i2rs. The idea is quite simple, as = you >>> have said above and really needs not be complicated more. >>> >> >>> >> It has its own complications. >>> >> >>> >> Do we permit more than one ephemeral datastore? If so, this >>> simplifies data >>> >> object priority when resolving the operational state. But = this >>> also >>> >> complicates operational state integrity when you have multiple >>> cross >>> > >>> > I vote for keeping this simple for starters. Lets get an >>> implementation or two of a single ephemeral data store. This >>> avoids having multiple priorities too; its just 1. >>> > >>> > --Tom >>> We can allow multiple ephemeral data stores, but the only >>> dependency can be with the NC config datastore. Example: >>>=20 >>> residential services >>> business services >>>=20 >>>=20 >>>=20 >>> What does this really mean? >>> I did not understand the details at the interim. >>> Does this mean each datastore has separate data models? >>=20 >> yes, each data store has separate data models >>=20 >>> Does this mean each service represent separate I2RS clients? >>=20 >> each ephemeral datastore represents separate I2RS clients. >>=20 >>>=20 >>> The only real reason to have multiple ephemeral datastores >>> would be to create the same instances of 1 or more data nodes >>> in multiple datastores. (multiple concurrent overlays). >>=20 >> I view it differently. In subscriber management different data models >> are used for residential and business subscribers. Some service data >> models can be very unique for business customers. So separating them = in >> different data stores makes sense, as they there are no overlaps with >> each other, only with NC config store. In this case, we can get = better >> performance. >>>=20 >>> IMO this sort of complexity should be left out of the agent. >>>=20 >>>=20 >>> each of the configuration sits in their own ephemeral datastore, >>> but only dependency is on NC config store. >>>=20 >>> As we are still keeping 1 to 1 overlay, not many to 1. >>>=20 >>>=20 >>> Dean >>>=20 >>>=20 >>>=20 >>> Andy >>>=20 >>> > >>> > >>> >> references. >>> >> >>> >> -- Jeff >>> >> >>> > >>> > _______________________________________________ >>> > netmod mailing list >>> > netmod@ietf.org >>> > https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> i2rs mailing list >> i2rs@ietf.org >> https://www.ietf.org/mailman/listinfo/i2rs >>=20 >=20 > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs >=20 --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJAg6AAoJEPcO+I7eiUJZjNwQAIi4uP9r/pB7HyPLXPHy2Iwo 6HaJ6QeGGcQuOFYW2WJP3ygXpnS4cDFjssZZP9uA1El/tj+lTnIhzawV+jlJshPC 7+1tXMAUvyvwgbhE4MvyJv8mTYGSvbmhaMvyC0x0QYiRUfY3jzs6MYUV5lCb38sP IvAYBhN+VXPYtQ+87R1k6W1u0qOFZrDJRE1acZlO+XWcfYK+s8Id4msO2hTzU1OM rRWxG3sTinst6zaa/qwIqBCrGWSLmAyVCbgg8Jswe1V/UBgQC3MHNXo1dooaS9Yy Q5QAi338n0a6G7Wp6DKBJKkyW9QTgFINIiAK/q4sOc6O9jM7Lks8o5PvVwYhABAw vk3Rxl+a7jWdgrvKQlMrCJ801NUTSMMXME1zx9zM0B7jaR9rFNQL60gBpH/zndjO zy4zBfUiaBfJ8CQD3dglxmaoeA20YbVcpoIAq6DiM2ai4p9i0ZSp2rlXikpw8BuW AFfxs6c1rlwN/5DRJFjh+M50Zb0807otWxK+/pV2GH1j9mr/zFycoFtDTrsPPlJk SrVvpLeOhgtDXuhjhgrSiKo8TlzWHi2YleikJ9IfdQ2m8HPjlj5enolBQqIR/N07 wQUv37nuKm3H4+61v8xAmNjucj17UYojW/YrSYKjzom/86RkzBCqZeextqwHd5jf PwPDqLmsD11e7P22O3Kk =AEvr -----END PGP SIGNATURE----- --Apple-Mail=_2B799685-83B8-4667-BE20-C4C95B00E27B-- From nobody Thu Sep 25 05:30:13 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 88C8F1A6FC5; Thu, 25 Sep 2014 05:30:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 mGoYLBD63HJE; Thu, 25 Sep 2014 05:30:05 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id F3BA61A0005; Thu, 25 Sep 2014 05:30:04 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 2911828A00C6; Thu, 25 Sep 2014 08:30:04 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: <20140925102640.GA27142@elstar.local> Date: Thu, 25 Sep 2014 08:29:57 -0400 Message-Id: References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/EmtgtCn_8rnUbJP4I1AP9FT0ZPw Cc: "i2rs@ietf.org" , "netmod@ietf.org" , Susan Hares Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:30:10 -0000 --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:6:26 AM, at 6:26 AM, Juergen Schoenwaelder = wrote: > Joel, >=20 > my expectations about the intelligence of I2RS clients is perhaps > lower than yours. Do you really believe I2RS clients will be smart to > adapt to whatever some other unknown conflicting I2RS client injects > into a shared ephemeral datastore? >=20 > I do not expect smartness. My hope is that I2RS clients involved in a > conflict can be signalled and probably more important that a human > operator can be signalled that I2RS clients step into each other so > that a human can take action to resolve things. Automatic conflict > resultion based on observation what state is injected by other I2RS > clients seems to me a huge (idealistic) assumption. >=20 > I would find conflict detection during the merge operation likely=20 > more reliable than conflict detection based on smart I2RS clients > monitoring closely what is going on in a shared datastore. >=20 > I assume there will be dumb I2RS clients. I too assume "dumb" clients (i.e.: or those with minimal = computational horsepower). Given that assumption, I've thought that the = "merge" operation should be a simple copy-over-the-stored-config = operation. This is why we shouldn't have more than one ephemeral store. = If its treated this way, its quite literally, just a copy-over = operation. My original ideas around i2rs were always such that the = ephemeral store was just a scratch pad where objects were stored to = reflect a shadow of a subset of the running config (just the forwarding = state information) until such time as it could get copied there "soon" = after, either via a timer popping or an explicit command from the OS or = client(s). Access to that store was done using a variant of Netconf = that a) avoided the configuration verification process from Netconf and = b) was RESTful in nature. What we have been discussing here with = multiple stores (and priorities) has vastly and IMHO unnecessarily, = complicated the original idea which was quite simple and obtainable with = mostly off-the-shelf technological components (i.e.: RESTConf + a hacked = Netconf daemon + yang models). It is the latter recipe from with which = I think we should use as a starting point to build crash test dummy = implementations from to see if this thing works rather than discussing = the theoretical aspects of complicating that further. Sorry, just my = $.02.=20 --Tom >=20 > /js >=20 > On Thu, Sep 25, 2014 at 06:12:00AM -0400, Joel M. Halpern wrote: >> Separate ephemeral data stores for distinct I2RS clients would seem a=20= >> very bad idea. >> It is perfectly acceptable for one client to read information being=20= >> manipulated by another cleitn. And if so, the reader should see the=20= >> results of that other clients activity. >>=20 >> Also, separate stores would not produce the error results required in=20= >> the case of collision. >>=20 >> So no, I do not see a use case from I2RS for multiple ephemeral data = stores. >>=20 >> Yours, >> Joel >>=20 >> On 9/24/14, 9:48 PM, Dean Bogdanovic wrote: >>>=20 >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >>>=20 >>>>=20 >>>>=20 >>>> On Wed, Sep 24, 2014 at 2:00 PM, Dean Bogdanovic >>> > wrote: >>>>=20 >>>>=20 >>>> On Sep 24, 2014, at 12:54 PM, Thomas D. Nadeau >>>> > wrote: >>>>=20 >>>>>=20 >>>>> On Sep 24, 2014:11:34 AM, at 11:34 AM, Jeffrey Haas >>>> > wrote: >>>>>=20 >>>>>> On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: >>>>>>> On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder >>>> >>> > wrote: >>>>>> [...] >>>>>>>>=20 >>>>>>>> +-----------------+ >>>>>>>> | | >>>>>>>> +--- (+) ---+ | >>>>>>>> ^ ^ v >>>>>>>> +---+ +---+ +---+ >>>>>>>> | | | | | | >>>>>>>> |(1)| | | | | >>>>>>>> | | | | | | >>>>>>>> +---+ +---+ +---+ >>>>>>>>=20 >>>>>>>> NC config ephemeral operational >>>>>>>> datastore datastore state >>>>>>>>=20 >>>>>>>> (1) The complete NC config datastore is at certain >>>> synchronization >>>>>>>> points made persistent >>>>>>>>=20 >>>>>>>> (+) Priority resolution, priorities may be per datastore or per >>>>>>>> user or per 'application' or even per data node >>>>>>>=20 >>>>>>> These are precisely the qualities I and some others were >>>> thinking of when we started i2rs. The idea is quite simple, as = you >>>> have said above and really needs not be complicated more. >>>>>>=20 >>>>>> It has its own complications. >>>>>>=20 >>>>>> Do we permit more than one ephemeral datastore? If so, this >>>> simplifies data >>>>>> object priority when resolving the operational state. But this >>>> also >>>>>> complicates operational state integrity when you have multiple >>>> cross >>>>>=20 >>>>> I vote for keeping this simple for starters. Lets get an >>>> implementation or two of a single ephemeral data store. This >>>> avoids having multiple priorities too; its just 1. >>>>>=20 >>>>> --Tom >>>> We can allow multiple ephemeral data stores, but the only >>>> dependency can be with the NC config datastore. Example: >>>>=20 >>>> residential services >>>> business services >>>>=20 >>>>=20 >>>>=20 >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>>=20 >>> yes, each data store has separate data models >>>=20 >>>> Does this mean each service represent separate I2RS clients? >>>=20 >>> each ephemeral datastore represents separate I2RS clients. >>>=20 >>>>=20 >>>> The only real reason to have multiple ephemeral datastores >>>> would be to create the same instances of 1 or more data nodes >>>> in multiple datastores. (multiple concurrent overlays). >>>=20 >>> I view it differently. In subscriber management different data = models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. So separating them = in >>> different data stores makes sense, as they there are no overlaps = with >>> each other, only with NC config store. In this case, we can get = better >>> performance. >>>>=20 >>>> IMO this sort of complexity should be left out of the agent. >>>>=20 >>>>=20 >>>> each of the configuration sits in their own ephemeral datastore, >>>> but only dependency is on NC config store. >>>>=20 >>>> As we are still keeping 1 to 1 overlay, not many to 1. >>>>=20 >>>>=20 >>>> Dean >>>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>>=20 >>>>>=20 >>>>>> references. >>>>>>=20 >>>>>> -- Jeff >>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> netmod mailing list >>>>> netmod@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>> _______________________________________________ >>>> i2rs mailing list >>>> i2rs@ietf.org >>>> https://www.ietf.org/mailman/listinfo/i2rs >>>>=20 >>>>=20 >>>=20 >>>=20 >>>=20 >>> _______________________________________________ >>> i2rs mailing list >>> i2rs@ietf.org >>> https://www.ietf.org/mailman/listinfo/i2rs >>>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > --=20 > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJArFAAoJEPcO+I7eiUJZ190P/RZcZcDvCNuEPMmNOSgvWxVD GOmz+k9AntCwa4SycKoCYjQcxJYpTGUvpRuigBMoQJ15JbKpaOCSy5q7Hr5QFvwa aIQ4pDumXfxfgn3GoFst15hH2rLzoJODSShi5OjD/HC9+9NIWbov8P++s4KnDT7f Gfcm2prg+8yFM8GJPGIEY9xwMebkpNQICacOzSyF4f6z9PwoNwsqNww3zUO8ll80 UFZMfINzHh6cdfONEnava9hgnRTru/0zAmWytmGu5m1huJyb343JCVgRlgzhPKAn 4AyejkvDwAN5ygBDTEjAdds+cWIH2csRHhNuFzR6U9NfihsH5xMPHW8GxiiGYNWe Qn1nt6oiHzgfAmq2A5idt9c5C/zEohcSntO1ZxBGn0vIVzYf9WubSIQeM/sDPPXd J0aJpcIJAcbnsY+67cvoiwYI4Nve0jh/Brl2SJd2OmQIPFnPf3/FdC28PYVzkuUH WhTBgm+BCJZVw9p2+2D03hGYwfJy5E33dhc5vqgwFfiJCLYL61/HLNm+WiSNoAiR FBsR5l+cr9q9wssYhZYP8kWVLcZNl8tTevuPUlxvXP+sGzNUewEdaRqX8WfakKgj KEkiPBZel4wFz1D3x+ukdXcrLeOaBsEIknih9pWRxpdUlTdIgLAdiZM0L5cV6whI ZODXu+aEShY+wv+NdQPV =/pba -----END PGP SIGNATURE----- --Apple-Mail=_05080C65-2A45-4C58-B8A2-B0645D94D4D0-- From nobody Thu Sep 25 05:37:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E63E1A6FC7; Thu, 25 Sep 2014 05:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-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 y4qxyC0MFdrk; Thu, 25 Sep 2014 05:37:45 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0732.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::732]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C3231A6FCD; Thu, 25 Sep 2014 05:37:10 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Thu, 25 Sep 2014 12:36:46 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Thu, 25 Sep 2014 12:36:46 +0000 From: Dean Bogdanovic To: Martin Bjorklund Thread-Topic: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Thread-Index: AQHP2Kz+t2GpzYpGM0SSGwtZmoqRg5wRyWAA Date: Thu, 25 Sep 2014 12:36:45 +0000 Message-ID: References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> In-Reply-To: <20140925.123930.1268640776659322434.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-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.10] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0345CFD558 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(24454002)(377454003)(51704005)(189002)(199003)(89996001)(20776003)(88136002)(19580395003)(66066001)(82746002)(83322001)(85852003)(64706001)(104166001)(83072002)(19580405001)(76176999)(110136001)(87286001)(107046002)(50986999)(62966002)(90102001)(101416001)(21056001)(33656002)(77096002)(85306004)(93886004)(81542003)(31966008)(46102003)(106356001)(77982003)(74662003)(80022003)(10300001)(87936001)(86362001)(50226001)(76482002)(92566001)(97736003)(95666004)(57306001)(93916002)(2656002)(83716003)(4396001)(74502003)(81342003)(105586002)(106116001)(99286002)(120916001)(92726001)(79102003)(77156001)(36756003)(99396003)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/g5UUCzMTj1EGoJ9BFLzc-WOTSrM Cc: "" , "" , "" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:37:47 -0000 On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: > Dean Bogdanovic wrote: >>=20 >> On Sep 24, 2014, at 5:19 PM, Andy Bierman >> > wrote: >> We can allow multiple ephemeral data stores, but the only dependency >> can be with the NC config datastore. Example: >>=20 >> residential services >> business services >>=20 >>=20 >>=20 >>> What does this really mean? >>> I did not understand the details at the interim. >>> Does this mean each datastore has separate data models? >>=20 >> yes, each data store has separate data models >=20 > Now I am confused. At the interim we agreed (and you argued for :) > that the schema (=3D data models) is the same for the config and > ephemeral datastore. Here is an example. The device supports x number of features and has a data= model that represents the whole device. From that data model (schema), I d= ecide to build a service that is using only parts of all available and stor= e it into ephemeral DB, example L3VPN. Now in ephemeral only L3VPN service = configurations will be stored. >=20 >=20 >=20 >> I view it differently. In subscriber management different data models >> are used for residential and business subscribers. Some service data >> models can be very unique for business customers. >=20 > Ok. >=20 >> So separating them >> in different data stores makes sense, as they there are no overlaps >> with each other, only with NC config store. >=20 > But since they are disjoint, there are really no reasons for not > keeping them in the same datastore, since there will be no conflicts. >=20 >> In this case, we can get >> better performance. >=20 > I can't see why, but this is probably an implementation issue. >=20 >=20 > /martin From nobody Thu Sep 25 05:44:17 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC7F1A6FD7; Thu, 25 Sep 2014 05:44:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 sPKDyYBsRPQp; Thu, 25 Sep 2014 05:44:08 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id DF00E1A6FD3; Thu, 25 Sep 2014 05:44:07 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id 61AE628A0157; Thu, 25 Sep 2014 08:44:07 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Thu, 25 Sep 2014 08:44:01 -0400 Message-Id: <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OCzWV3VwCf__Kz2PX4wjcAp4N1Q Cc: "" , "" , "" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:44:14 -0000 --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Sep 25, 2014:8:36 AM, at 8:36 AM, Dean Bogdanovic = wrote: >=20 > On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: >=20 >> Dean Bogdanovic wrote: >>>=20 >>> On Sep 24, 2014, at 5:19 PM, Andy Bierman >>> > wrote: >>> We can allow multiple ephemeral data stores, but the only dependency >>> can be with the NC config datastore. Example: >>>=20 >>> residential services >>> business services >>>=20 >>>=20 >>>=20 >>>> What does this really mean? >>>> I did not understand the details at the interim. >>>> Does this mean each datastore has separate data models? >>>=20 >>> yes, each data store has separate data models >>=20 >> Now I am confused. At the interim we agreed (and you argued for :) >> that the schema (=3D data models) is the same for the config and >> ephemeral datastore. > Here is an example. The device supports x number of features and has a = data model that represents the whole device. =46rom that data model = (schema), I decide to build a service that is using only parts of all = available and store it into ephemeral DB, example L3VPN. Now in = ephemeral only L3VPN service configurations will be stored. I2RS does not model the entire device; just its "routing system" = components. --Tom >=20 >>=20 >>=20 >>=20 >>> I view it differently. In subscriber management different data = models >>> are used for residential and business subscribers. Some service data >>> models can be very unique for business customers. >>=20 >> Ok. >>=20 >>> So separating them >>> in different data stores makes sense, as they there are no overlaps >>> with each other, only with NC config store. >>=20 >> But since they are disjoint, there are really no reasons for not >> keeping them in the same datastore, since there will be no conflicts. >>=20 >>> In this case, we can get >>> better performance. >>=20 >> I can't see why, but this is probably an implementation issue. >>=20 >>=20 >> /martin >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJA4RAAoJEPcO+I7eiUJZwi4P/jS0trfbTRxnCRLZJxoNZn/X pxdR1h6HHPjxVEI6wAdcm9m+4s0SP9SZuaQVtHllAdfISWKDqqvXvPucuYAC2vgb 1BLGgRxMHx0w84Go8H/l/gCmLh3CHyQeQESD87lxmgLG8Cx3WCyNoK17E3oiTt64 q776z4T+c6J4x8bhtM4fFD7deaDWpAO5V//vkjwiBrk/hQHNOC4XFTByLUSJPZLT 2AR6UUdzs/cf1sykyeNX0V43ZiOpRSrumG+1qkQclCrG8B3Q2rGjzC00rdK23cnl IvcUFhG+jlcOl3WXhQCmD3i+MIw3FZBmQjbT93q6JewkV8XitLqyKKGoi/2BIZAl 5MUIR0f3uWJIzhrnDL4P0moDXvIvG9/w4/ISgaDgV66V/qH5Li6ZD92ugkkjUN7K 2FRzlsKhxxTxPTp2rjqcl7Fq5IrVFOiQ7a6JFa0jkSKmAnb8wZ/Nnd97uaoCSyWn OUPvXQcHNG4RkED3pmpgibNG9mGyU/KeRtq6tIv4hHzv6wh0jidsa1tzvN3Jgpb2 aNzMtlb60erdvffRgPjtJjOGAj9xEBEJ9+SyGWCvfgbjVqgP8oRLqqPX+IQEnXDe e6tX/cOCizc43Ynwa9OaV8tp2uOJOFLoKYyEd2omyE1/nmOeD6C5igcadufIacef NHAWn80RbXq8fR+94d4Z =sRTS -----END PGP SIGNATURE----- --Apple-Mail=_E7304180-C1E8-4250-894B-51D0341CF501-- From nobody Thu Sep 25 05:44:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 721211A6FD5; Thu, 25 Sep 2014 05:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 2Ui8GeJSuysB; Thu, 25 Sep 2014 05:44:33 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 36FDA1A6FD2; Thu, 25 Sep 2014 05:44:33 -0700 (PDT) Received: from localhost (x15.tail-f.com [192.168.1.60]) by mail.tail-f.com (Postfix) with ESMTPSA id 23C711280934; Thu, 25 Sep 2014 14:44:32 +0200 (CEST) Date: Thu, 25 Sep 2014 14:44:31 +0200 (CEST) Message-Id: <20140925.144431.1189410629141675157.mbj@tail-f.com> To: deanb@juniper.net From: Martin Bjorklund In-Reply-To: References: <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.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/netmod/NKd4SwSJPNRcUJKX7ogn6gENRUU Cc: netmod@ietf.org, i2rs@ietf.org, shares@ndzh.com Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 12:44:36 -0000 Dean Bogdanovic wrote: > > On Sep 25, 2014, at 6:39 AM, Martin Bjorklund wrote: > > > Dean Bogdanovic wrote: > >> > >> On Sep 24, 2014, at 5:19 PM, Andy Bierman > >> > wrote: > >> We can allow multiple ephemeral data stores, but the only dependency > >> can be with the NC config datastore. Example: > >> > >> residential services > >> business services > >> > >> > >> > >>> What does this really mean? > >>> I did not understand the details at the interim. > >>> Does this mean each datastore has separate data models? > >> > >> yes, each data store has separate data models > > > > Now I am confused. At the interim we agreed (and you argued for :) > > that the schema (= data models) is the same for the config and > > ephemeral datastore. > Here is an example. The device supports x number of features and has a > data model that represents the whole device. From that data model > (schema), I decide to build a service that is using only parts of all > available and store it into ephemeral DB, example L3VPN. Now in > ephemeral only L3VPN service configurations will be stored. This is fine. This means that the *schema* is the same for both data stores, but the instance data is different. Note that the set of data models make up the schema; thus both data stores have the *same* data models (same schema), not separate. /martin From nobody Thu Sep 25 07:21:35 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2F861A6FE9 for ; Thu, 25 Sep 2014 07:21:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 iNinxS9p3Tsb for ; Thu, 25 Sep 2014 07:21:32 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 6A21C1A00F5 for ; Thu, 25 Sep 2014 07:21:32 -0700 (PDT) Received: from [192.168.1.120] (static-72-71-250-38.cncdnh.fast04.myfairpoint.net [72.71.250.38]) by lucidvision.com (Postfix) with ESMTP id BE92A28A037F; Thu, 25 Sep 2014 10:21:31 -0400 (EDT) From: "Thomas D. Nadeau" Content-Type: multipart/signed; boundary="Apple-Mail=_993C1FAD-A1CF-43D1-888C-C4D1091EC4ED"; protocol="application/pgp-signature"; micalg=pgp-sha512 Date: Thu, 25 Sep 2014 10:21:25 -0400 Message-Id: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> To: NETMOD Working Group Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/JDWY5QZ5ugQWdfSCgmCYlSsMvQg Cc: netmod-chairs@tools.ietf.org, netmod-ads@tools.ietf.org Subject: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:21:34 -0000 --Apple-Mail=_993C1FAD-A1CF-43D1-888C-C4D1091EC4ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Netmod WG: Juergen, Benoit and I have discussed a plan by which we will = divide up the interim meetings into two categories. Going forward, we = will alternate meetings each week to focus on either a) Yang Model = production or b) Yang 1.1 updates/issue discussion/resolution. Starting = with the next scheduled meeting two weeks on Wednesday, October 8, 2012, = we will begin this cadence with a) and then b), and as such will be = working on Yang Model production at that meeting. The following meeting = will focus on b) and so on.=20 Ahead of each Yang Modeling meeting I would like to ask that = those wishing to propose models for discussion do so as early as = possible so that an agenda can be assembled ahead of time. Please either = post proposals to the NETMOD list or to me directly and I will keep = track of proposals in the issue tracker. Also, in order to address = feedback we have received after the last official IETF meeting that the = agenda slots are too tight to facilitate significant/detailed discussion = of models, the meeting format will be fairly loose to allow for = extensive discussion/hacking of models. Given this change it is = possible that if significant discussion and progress is made on a single = model, that only that single model will be discussed during an entire = meeting. It is possible too that if that discussion is not concluded, = that it spills over into the next meeting two weeks later. =20 Meeting minutes/notes will be kept in the same format and posted = as are done for the current meetings. If anyone has suggestions/questions regarding the meeting format = updates, please discuss here. Cheers, =09 --Tom --Apple-Mail=_993C1FAD-A1CF-43D1-888C-C4D1091EC4ED Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUJCTlAAoJEPcO+I7eiUJZP/EQAIMDlzfq5m08TsOLD+RuyFTd iv+IUPTxyEmvqTitUPgJxgS/By9ql8lQiV49kKLBnq73Zpv4wGQOLdkgzoZL0UZI d4LYdHPAjAuJqLwvvMTYjEnytCtMRnugGnymJszFSHr1iq91vw+QjB78xY9G5Tna XaPXbL32s8FSGxvUOr/UcUj/ZZd0xGwj6vYaA6x1GhR0hH/QvrorAmGAvly+U5+u d2dj27MtHgl03ANTwgUGqInYZZfHud9H8dftckjnT1EcpbdGKc00vaGnM3BabIa2 Z2VWeXcNY7C7iRq3JEZos1Xye0EvOLaxCxj34pgVIZXrTwUCZSr3XM1GoAAPkfp8 glBC3QVZp3jEhFeyo2avr2aQxgxhkudGVpYwO2qQa8AbCtRybuip+qAaZQfiLqB0 mKUX7iZUrfnw0RU3XOiR3NPBby7rfTeCyo0zhrE6JkaB5KpWJxUMVhdA0hQX7kh0 S2MBvZ1GkbmkPkJfAo8QG0+tPkLdcjJycsfIVc+2JGxBhMoSJmaEDzBztep79vXB RT2ynFtbDUf5nslaM01g+/TBehwXhhPP5Lxareyk0P8kAX4nmGB4m8FCIp8CjSvO YdbkHUkIQgUWq+7KlDrJYgcvgXDwbM6nrj4RZx5EZC3T1YSprnndf38YP2p3POgT +PzxaMftPRB67Y8hcFwx =ycYL -----END PGP SIGNATURE----- --Apple-Mail=_993C1FAD-A1CF-43D1-888C-C4D1091EC4ED-- From nobody Thu Sep 25 07:23:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5415E1A6FF5; Thu, 25 Sep 2014 07:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 fJhc8F8azzbC; Thu, 25 Sep 2014 07:23:02 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 016321A6FEE; Thu, 25 Sep 2014 07:23:01 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id B06B3C202; Thu, 25 Sep 2014 10:23:01 -0400 (EDT) Date: Thu, 25 Sep 2014 10:23:01 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140925142301.GC10261@pfrc> References: <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <284C62E4-EBA9-4D21-829B-CF80C91A1FEA@lucidvision.com> <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <5423EA70.7070907@joelhalpern.com> <20140925102640.GA27142@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/qL_eYIZix4zIDSvNI-J5F2DZWOo Cc: "i2rs@ietf.org" , Susan Hares , "netmod@ietf.org" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:23:03 -0000 On Thu, Sep 25, 2014 at 08:29:57AM -0400, Thomas D. Nadeau wrote: > On Sep 25, 2014:6:26 AM, at 6:26 AM, Juergen Schoenwaelder wrote: [...] > > I assume there will be dumb I2RS clients. > > I too assume "dumb" clients (i.e.: or those with minimal computational > horsepower). Given that assumption, I've thought that the "merge" > operation should be a simple copy-over-the-stored-config operation. Mostly correct, but with the idea that you can "delete" from the ephemeral datastore perspective shadowed local config state by effectively leaving a hole in the ephemeral config. E.g.: Local Config: A[1] A[2] A[3] Ephemeral Config: DELETE A[2] A[4] Active Config (post merge): A[1] A[3] A[4] -- Jeff From nobody Thu Sep 25 07:25:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D1291A6F0B; Thu, 25 Sep 2014 07:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 B4NNkehqscTt; Thu, 25 Sep 2014 07:25:37 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 553391A6FF7; Thu, 25 Sep 2014 07:25:37 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 1DAA9C202; Thu, 25 Sep 2014 10:25:37 -0400 (EDT) Date: Thu, 25 Sep 2014 10:25:37 -0400 From: Jeffrey Haas To: "Thomas D. Nadeau" Message-ID: <20140925142537.GD10261@pfrc> References: <820EBD44-7421-4116-8888-7E06B72C3BAD@juniper.net> <2384FE3B-8325-40EA-9C25-B7A452564424@juniper.net> <20140925.123930.1268640776659322434.mbj@tail-f.com> <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B559804-7739-4CCD-8040-82B775D9D3B0@lucidvision.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9RFAUzlH3UO7M8N6AaGM8aIpfOc Cc: "" , "" , "" Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:25:44 -0000 On Thu, Sep 25, 2014 at 08:44:01AM -0400, Thomas D. Nadeau wrote: > On Sep 25, 2014:8:36 AM, at 8:36 AM, Dean Bogdanovic wrote: > > Here is an example. The device supports x number of features and has a data model that represents the whole device. From that data model (schema), I decide to build a service that is using only parts of all available and store it into ephemeral DB, example L3VPN. Now in ephemeral only L3VPN service configurations will be stored. > > I2RS does not model the entire device; just its "routing system" components. While we're primarily concerned with I2RS semantics, the discussion has effectively broadened because the ephemeral mechanism we're discussing may be used by non-I2RS clients. I chatted with Dean a few minutes ago. I think much of the confusion regarding multiple ephemeral datastores is a result of a JUNOS implementation detail. He'll clarify the externally visible behavior which is more like what we've previously disucssed. -- Jeff From nobody Thu Sep 25 07:28:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBCFC1A6FEE; Thu, 25 Sep 2014 07:27:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 5zM3C7Qxfbbv; Thu, 25 Sep 2014 07:27:56 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id DECCE1A6F30; Thu, 25 Sep 2014 07:27:56 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id AAEABC202; Thu, 25 Sep 2014 10:27:56 -0400 (EDT) Date: Thu, 25 Sep 2014 10:27:56 -0400 From: Jeffrey Haas To: Jeffrey Haas , i2rs@ietf.org, netmod@ietf.org Message-ID: <20140925142756.GE10261@pfrc> References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924153802.GD2639@pfrc> <20140925063225.GC26200@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140925063225.GC26200@elstar.local> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/XdpS3uw0c8g7R3dpjPIOi0zZzVM Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 14:27:58 -0000 On Thu, Sep 25, 2014 at 08:32:25AM +0200, Juergen Schoenwaelder wrote: > Likely as meta-data attributes. > > https://tools.ietf.org/html/draft-lhotka-netmod-yang-metadata-00 More homework for me. Thanks. > > The primary ones I am aware of are operations on network addresses and > > prefixes. Was netmod looking for an explicit manifest of such operations? > > We are happy to receive input. A starting point is here. > > http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 > > This I-D, however, does not define functions for network addresses. > > > This may have overlap in the work for the ACL module that is already a > > netmod document. > > I am lost here. I do not see how additional xpath functions related to > the NACM (which came out of NETCONF not NETMOD). I was referring to http://tools.ietf.org/html/draft-bogdanovic-netmod-acl-model-00 -- Jeff From nobody Thu Sep 25 15:05:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B31E91A19FC; Thu, 25 Sep 2014 15:05:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 c0JHyamudmPt; Thu, 25 Sep 2014 15:05:03 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id E72AF1A19F8; Thu, 25 Sep 2014 15:05:02 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Andy Bierman'" References: <20140912210913.GA10692@pfrc> <002b01cfd2d6$5316a120$f943e360$@ndzh.com> <004601cfd361$d2cbe520$7863af60$@ndzh.com> <20140922200154.GG6550@pfrc> <025b01cfd792$cfc00a20$6f401e60$@ndzh.com> In-Reply-To: Date: Thu, 25 Sep 2014 18:04:58 -0400 Message-ID: <010d01cfd90c$bfb57950$3f206bf0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_010E_01CFD8EB.38A93080" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF152CPuE+kSzEZATJqaJUcwSLQnwIbKt3gAQ37k3kBfPWaBwKMmSaPAmFsweUA8uKOdAIOcdCJnGGeAAA= X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gUGkuubHKa5IaqKdunVOa-aXCng Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 22:05:06 -0000 This is a multipart message in MIME format. ------=_NextPart_000_010E_01CFD8EB.38A93080 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Andy: I agree that ties are really errors, and I think the architecture document tries to say that the priority is just a way to allow the first one that wins - to stay connected. You are correct - the client must have a connect and reload strategy. Sue From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy Bierman Sent: Tuesday, September 23, 2014 9:25 PM To: Susan Hares Cc: Jeffrey Haas; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Tue, Sep 23, 2014 at 5:59 PM, Susan Hares wrote: Andy: The concept on priority and FCFS is "if a remote client talks to an agent at a priority - then it should not be knocked out by another remote client coming later at the same priority". In my mind this is different that the boot/reboot configuration case. Do you think I am correct? Sure. I guess I am assuming each I2RS client has some reconnect-and-reload strategy. Normally, the clients will get notified when some data gets bumped or the agent restarts. Then there may be a race between the 2+ clients with same priority. IMO ties are really errors, and the operator is going to need to assign different priorities or set some config so all the clients run without data collisions. Sue Andy From: Andy Bierman [mailto:andy@yumaworks.com] Sent: Monday, September 22, 2014 5:10 PM To: Jeffrey Haas Cc: Susan Hares; i2rs@ietf.org; netmod@ietf.org Subject: Re: [netmod] [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs requirements) On Mon, Sep 22, 2014 at 1:01 PM, Jeffrey Haas wrote: Sue, On Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote: > Where does the priority live ??? in I2RS or in config module or in BGP > routing model? How does this work with the three datastore proposals: 1) > separate empheral data store, 2) configuration state in existing datastore > tagged by model as empheral, and 3) whole data stores tagged empheral, > config, or both. Is the routing code that sets the priority and handles > the rollback? Priority received quite a bit of discussion during the netmod interim. The reason why it was not explicitly spelled out in my first version of the draft is that the implementation would vary considerably depending on which answer netmod guided us toward for how we get ephemeral state. The rationale for the priority-based "first one wins" access control model is still unclear to me. A simple NACM extension to add group priority has already been proposed, which seems fine to me. So is this how it works? #1) NACM data rules can be used to grant or deny access to specific I2RS data nodes. Steps #2 and #3 assume access is granted here #2) the I2RS agent maintains the owner and owner priority of the data somehow. The priority is configured in each NACM group for enforcement purposes. This data used to decide if existing data can be overwritten by a different client. (I think highest priority wins if target data already exists) #3) if both writer and current owner have the same priority, then current owner wins Breaking ties by first-one-wins seems just as arbitrary as last-one-wins. It seems to be based on the order that the networking devices will boot. Can somebody explain why it is better? I am still unclear how the operator know the exact data each client will want to use, and how they determine the meaningful overlap (e.g. what will break for client B if client A causes 2 of its 7 entries to be deleted?) This information seems to be required in order to configure the tie-breaking priorities properly, but I think the intent is that the operator will just know what I2RS clients are installed and know how to prioritize them, just based on their purpose. It turned out they gave us a fourth option. I'll be summarizing that in my meeting minutes. If you don't believe I've adequately addressed it in that writeup (coming shortly), please let me know and we'll resume. -- Jeff Andy _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod ------=_NextPart_000_010E_01CFD8EB.38A93080 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Andy:

I agree that ties are really errors, and I think the architecture = document tries to say that the priority is just a way to allow the first = one that wins – to stay connected.  You are correct – = the client must have a connect and reload strategy. =

 

Sue  

 

From:= = i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Tuesday, September 23, 2014 9:25 = PM
To: Susan Hares
Cc: Jeffrey Haas; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] [netmod] I2RS requests to = netmod/netconf (was netmod interim and i2rs = requirements)

 

 

 

On Tue, = Sep 23, 2014 at 5:59 PM, Susan Hares <shares@ndzh.com> = wrote:

Andy:

 

The concept on priority and FCFS is “if a remote client talks = to an agent at a priority – then it should not be knocked out by = another remote client coming later at the same priority”.  In = my mind this is different that the boot/reboot configuration case.  =  Do you think I am correct?

 

 

Sure.

 

I = guess I am assuming each I2RS client has some reconnect-and-reload = strategy.

Normally, the = clients will get notified when some data gets bumped or the agent = restarts.

Then there may = be a race between the 2+ clients with same = priority.

 

IMO ties are really errors, and the operator is going = to need to assign different priorities

or set some config so all the clients run without data = collisions.

 

 

Sue

 

 

Andy

 

From:= = Andy Bierman [mailto:andy@yumaworks.com]
Sent: Monday, = September 22, 2014 5:10 PM
To: Jeffrey Haas
Cc: = Susan Hares; i2rs@ietf.org; netmod@ietf.org
Subject: Re: [netmod] = [i2rs] I2RS requests to netmod/netconf (was netmod interim and i2rs = requirements)

 <= /o:p>

 <= /o:p>

 <= /o:p>

On Mon, Sep = 22, 2014 at 1:01 PM, Jeffrey Haas <jhaas@pfrc.org> wrote:

Sue,

On = Thu, Sep 18, 2014 at 12:58:51PM -0400, Susan Hares wrote:
> Where = does the priority live ??? in I2RS or in config module or in BGP
> = routing model?  How does this work with the three datastore = proposals: 1)
> separate empheral data store, 2) configuration = state in existing datastore
> tagged by model as empheral, and 3) = whole data stores tagged empheral,
> config, or both.  =  Is the routing code that sets the priority and handles
> the = rollback?

Priority received quite a bit of discussion during the = netmod interim.  The
reason why it was not explicitly spelled = out in my first version of the
draft is that the implementation would = vary considerably depending on which
answer netmod guided us toward = for how we get ephemeral state.

 <= /o:p>

The = rationale for the priority-based "first one wins" access = control model is still unclear

to = me.

 <= /o:p>

A simple = NACM extension to add group priority has already been = proposed,

which seems = fine to me. So is this how it works?

 <= /o:p>

  #1) = NACM data rules can be used to grant or deny access to specific I2RS = data nodes.

  =       Steps #2 and #3 assume access is granted = here

 <= /o:p>

  #2) = the I2RS agent maintains the owner and owner priority of the data = somehow.

  =        The priority is configured in each NACM group = for enforcement purposes.  

  =        This data used to decide if existing data can = be overwritten by a different client.

  =        (I think highest priority wins if target data = already exists)

 <= /o:p>

  #3) = if both writer and current owner have the same priority, then current = owner wins

 <= /o:p>

Breaking = ties by first-one-wins seems just as arbitrary as last-one-wins.  = It seems to be based on

the order = that the networking devices will boot.  Can somebody explain why it = is better?

 <= /o:p>

I am still = unclear how the operator know the exact data each = client

will want = to use, and how they determine the meaningful = overlap

(e.g. what = will break for client B if client A causes 2 of its 7 entries to be = deleted?)

 <= /o:p>

This = information seems to be required in order to configure the tie-breaking = priorities properly,

but I think = the intent is that the operator will just know what I2RS clients are = installed

and know = how to prioritize them, just based on their = purpose.

 <= /o:p>

 <= /o:p>

 <= /o:p>

It turned out = they gave us a fourth option.  I'll be summarizing that in = my
meeting minutes.  If you don't believe I've adequately = addressed it in that
writeup (coming shortly), please let me know and = we'll resume.

-- Jeff

 <= /o:p>

 <= /o:p>

Andy

 <= /o:p>

____________= ___________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

 <= /o:p>

 

------=_NextPart_000_010E_01CFD8EB.38A93080-- From nobody Thu Sep 25 15:25:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5255A1A0352; Thu, 25 Sep 2014 15:25:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 0Xqhzse5nCji; Thu, 25 Sep 2014 15:25:56 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id C14C01A016D; Thu, 25 Sep 2014 15:25:55 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Juergen Schoenwaelder'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> In-Reply-To: <20140924071023.GF23280@elstar.local> Date: Thu, 25 Sep 2014 18:25:51 -0400 Message-ID: <012c01cfd90f$aa2fcd30$fe8f6790$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_012D_01CFD8EE.23216180" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAirw7sacndAm4A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OMkF_5GbqiN8ZJKDR0cdfh8Hdqw Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 22:25:57 -0000 This is a multipart message in MIME format. ------=_NextPart_000_012D_01CFD8EE.23216180 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Juregen: Option 4 does make things easy. What happens if a particular node/variables that I2RS wants, would not normally be in the configuration? Should you configure that node in the empheral store only? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder Sent: Wednesday, September 24, 2014 3:10 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > Jeff: > > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? The beauty of the fourth option is that it does not require a large set of new data models. The idea is that you have a standard config data model and you use the same model for an ephemeral datastore. The server will then take the contents of the config datastore and 'merge' it with the content of any ephemeral datastores to produce what the box ends up doing (the operational state). The merging function will take priorities into account should conflicts arise. Here is the relevant figure (taken from the meeting minutes): +-----------------+ | | +--- (+) ---+ | ^ ^ v +---+ +---+ +---+ | | | | | | |(1)| | | | | | | | | | | +---+ +---+ +---+ NC config ephemeral operational datastore datastore state (1) The complete NC config datastore is at certain synchronization points made persistent (+) Priority resolution, priorities may be per datastore or per user or per 'application' or even per data node /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1, 28759 Bremen, Germany Fax: +49 421 200 3103 < http://www.jacobs-university.de/> _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs ------=_NextPart_000_012D_01CFD8EE.23216180 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Juregen:

 

Option = 4 does make things easy.  What happens if a particular = node/variables that I2RS wants, would not normally be in the = configuration?  Should you configure that node in the empheral = store only?

 

Sue =

 

-----Original Message-----
From: i2rs = [mailto:i2rs-bounces@ietf.org] On Behalf Of Juergen = Schoenwaelder
Sent: Wednesday, September 24, 2014 3:10 AM
To: = Susan Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] [netmod] Summary of discussion = from netmod interim on i2rs requirements on netmod/netconf

 

On = Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares = wrote:

> Jeff:

>

> = The fourth option is interesting and creative. A few

> questions/requests: 1) How would the fourth = model be expressed in the

> = yang model  - config (empheral)?

 

The beauty of the = fourth option is that it does not require a large set of new data = models. The idea is that you have a standard config data model and you = use the same model for an ephemeral datastore. The server will then take = the contents of the config datastore and 'merge'

it with the content = of any ephemeral datastores to produce what the box ends up doing (the = operational state). The merging function will take priorities into = account should conflicts arise. Here is the relevant figure (taken from = the meeting minutes):

 

           &= nbsp;   +-----------------+

           &= nbsp;   = |            =      |

         +--- (+) = ---+           = |

         = ^           = ^           = v

       = +---+       = +---+       +---+

       |   = |       |   = |       |   = |

       |(1)|     =   |   |       = |   |

       |   = |       |   = |       |   = |

       = +---+       = +---+       +---+

 

     NC config  = ephemeral    operational

     datastore  = datastore      state

 

    = (1) The complete NC config datastore is at certain = synchronization

    = points made persistent

 

    = (+) Priority resolution, priorities may be per datastore or = per

    = user or per 'application' or even per data node

 

/js

 

-- =

Juergen = Schoenwaelder          = Jacobs University Bremen gGmbH

Phone: +49 421 200 = 3587         Campus Ring 1, = 28759 Bremen, Germany

Fax:   +49 421 200 = 3103         <http://www.jacobs-univers= ity.de/>

 

_______________________________________________=

i2rs mailing list

i2rs@ietf.org<= o:p>

https://www.ietf.org/mail= man/listinfo/i2rs

------=_NextPart_000_012D_01CFD8EE.23216180-- From nobody Thu Sep 25 15:38:36 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F2D1A19FC for ; Thu, 25 Sep 2014 15:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.287 X-Spam-Level: X-Spam-Status: No, score=-14.287 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GB_AFFORDABLE=1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.786, 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 ytzZr02VuoaS for ; Thu, 25 Sep 2014 15:38:21 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 389741A1A0E for ; Thu, 25 Sep 2014 15:38:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8150; q=dns/txt; s=iport; t=1411684690; x=1412894290; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=69cPhiMQeEzboDcvVtBoZb6L2BVH5kSCF8KSLo14hpU=; b=P05K6ebA0FbNku1FDjSa3QlFsJU6zcx3weEX5W0Ct2/VkjkW+wwhY3wP glzTvZfJ0obUTD2t4Qam1WtP/ZGBI6WE9oWQXN0FL+9HEnl2EMJtdJUzI RfHiG8Sk7WvPuR3LXlQSCT98rB032lBD+gGYNC20ZvVki9rum/hrIDTws E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlAPAF2YJFStJA2K/2dsb2JhbAAZAUaDDlNXBIJ9xzKHTAIYbhYBcgmEAwEBAQQjEUMCDAYBBhMEAQEDAgYCGwMCBDAUAQgJAQQOBQgBEQGIIw2ONTmcTIVPkEsBF4EsjkExDYJyNoEdBZFghDqIa5N0g2NsAYFHgQIBAQE X-IronPort-AV: E=Sophos;i="5.04,600,1406592000"; d="scan'208";a="358292481" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-8.cisco.com with ESMTP; 25 Sep 2014 22:38:09 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s8PMc9g9022968 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Thu, 25 Sep 2014 22:38:09 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0195.001; Thu, 25 Sep 2014 17:38:09 -0500 From: "Eric Voit (evoit)" To: "netmod@ietf.org" Thread-Topic: "00" Notification for draft-voit-netmod-peer-mount-requirements Thread-Index: Ac/ZEV2GAz62sHUQQeu4mQO0cFNdqA== Date: Thu, 25 Sep 2014 22:38:08 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/IaIdmvKVh_YqeGH0tnA7iDToRCA Cc: "Ambika Prasad Tripathy \(ambtripa\)" , "Prabhakara Yellai \(pyellai\)" , "Shashi Kumar Bansal \(shabansa\)" Subject: [netmod] "00" Notification for draft-voit-netmod-peer-mount-requirements X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 22:38:30 -0000 V2UgaGF2ZSBiZWVuIGRldmVsb3BpbmcgU0ROIGFwcGxpY2F0aW9ucyB3aGljaCByZXF1aXJlIHF1 aWNrLCBpdGVyYXRpdmUgYWNjZXNzIHRvIG9iamVjdHMgcmVwcmVzZW50aW5nIG5ldHdvcmsgYW5k IGRldmljZSBhYnN0cmFjdGlvbnMuwqAgVGhlc2Ugb2JqZWN0cyBpbmNsdWRlIG9uZXMgYXV0aG9y aXRhdGl2ZWx5IG93bmVkIGJ5IGEgbG9jYWwgc3lzdGVtLCBhcyB3ZWxsIGFzIG9uZXMgcHJvdmlk ZWQgZnJvbSByZW1vdGUgZGF0YXN0b3Jlcy7CoCBUd28gc3VjaCBhcHBsaWNhdGlvbnMgd2UgaGF2 ZSBwcm90b3R5cGVkIGFyZSDigJxDbG91ZCBQb2xpY2Vy4oCdIGFuZCDigJxERG9TIFRocmVzaG9s ZGluZ+KAnS4gwqAoU2VlIGxpbmtzIGJlbG93IGZvciBtb3JlIG9uIHRoZXNlIGFwcHMuKQ0KDQpU aGUgZ29vZCBuZXdzIGlzIHRoYXQgd2UgZm91bmQgWUFORyBtb2RlbHMgYW5kIHN5bnRheCB0byBi ZSBhIG5pY2UgZml0IGZvciB0aGVzZSBhcHBsaWNhdGlvbnMuwqDCoCBIb3dldmVyIHdlIGhhdmUg YmVlbiB0cnlpbmcgdG8gY292ZXIgc2V2ZXJhbCBtaXNzaW5nIGVsZW1lbnRzOg0KDQpNaXNzaW5n IEVsZW1lbnQgIzE6IERldmVsb3BlciBTaW1wbGljaXR5DQpXZSB3YW50ZWQgYXBwbGljYXRpb25z IHRvIGFjY2VzcyByZW1vdGUgb2JqZWN0cyBmcm9tIGEgc2luZ2xlIGRhdGFzdG9yZSwgd2l0aG91 dCBoYXZpbmcgdG8gaGF2ZSB0aGUgYXBwbGljYXRpb25zIHBlZXIgZGlyZWN0bHkgd2l0aCByZW1v dGUgZGV2aWNlcy7CoCBXZSBhbHNvIHdhbnRlZCBjbGllbnRzIGFuZCBhcHBsaWNhdGlvbnMgdG8g YWNjZXNzIGRhdGFzdG9yZXMgaW4gdGhlIHNhbWUgd2F5IGluZGVwZW5kZW50IG9mIHdoZXRoZXIg dGhlIGFwcGxpY2F0aW9ucyB3ZXJlIGhvc3RlZCBvbiBhIE5ldHdvcmsgRWxlbWVudCBvciBDb250 cm9sbGVyLg0KDQpNaXNzaW5nIEVsZW1lbnQgIzI6IFdobyBvd25zIGFuIE9iamVjdD8NCkFwcGxp Y2F0aW9ucyBjYW4ndCB0ZWxsIHdoaWNoIE5ldHdvcmsgRWxlbWVudCBhY3Jvc3MgYSBzZXQgb2Yg ZGV2aWNlcyBpcyB0aGUgYXV0aG9yaXRhdGl2ZSBvd25lciBvZiBhIHBhcnRpY3VsYXIgcmVwbGlj YXRlZCBvYmplY3QuwqAgU2luY2UgcmVwbGljYXRlZCBkYXRhIGdldHMgb3V0IG9mIHN5bmNoLCBy ZXNvbHV0aW9uIC8gY29udmVyZ2VuY2UgaXMgYSBwcm9ibGVtLg0KDQpNaXNzaW5nIEVsZW1lbnQg IzM6IE1haW50YWluaW5nIGNhY2hlcyBvZiByZW1vdGUgaW5mb3JtYXRpb24NCkFwcGxpY2F0aW9u cyBuZWVkIHRpbWVseSBhY2Nlc3MgdG8gcmVtb3RlIGluZm9ybWF0aW9uLCB3aGljaCBjYW4gbmVj ZXNzaXRhdGUgdGhlIGludHJvZHVjdGlvbiBjYWNoZSBpbmZyYXN0cnVjdHVyZS7CoCBOZXRjb25m IHByb3ZpZGVzIGxpdHRsZSBzdXBwb3J0IHRvIGZhY2lsaXRhdGUgdGhpcy7CoCBGb3IgZXhhbXBs ZSwgbm90aWZpY2F0aW9ucyBhcmUgbm90IGEgZ29vZCBtYXRjaCB0byBzdWJzY3JpYmUgdG8gcHVz aC11cGRhdGVzLsKgIA0KDQpUbyBzb2x2ZSB0aGVzZSBwcm9ibGVtcywgd2UgbmVlZCB0ZWNobm9s b2d5IHNvbHV0aW9ucyB3aGljaCB3b3JrIGVxdWFsbHkgd2VsbCBmb3IgYm90aCBDb250cm9sbGVy cyBhbmQgTmV0d29yayBFbGVtZW50cy7CoCBUaGVzZSBzb2x1dGlvbnMgbXVzdCBleHBvc2UgbG9j YWwgZGF0YXN0b3JlcyB3aGljaCBwcm92aWRlIGF1dGhvcml0YXRpdmUsIGNvbnNvbGlkYXRlZCB2 aWV3cyBvZiBkaXN0cmlidXRlZCBuZXR3b3JrIG9iamVjdHMuwqAgVGhpcyBtdXN0IGJlIGRvbmUg aW4gYSB3YXkgd2hpY2ggYWxsb3dzIHRoZSBhcHBsaWNhdGlvbnMgdG8gc2l0IGFueXdoZXJlIGlu IHRoZSBuZXR3b3JrLCBvbiB2YXJpb3VzIGFic3RyYWN0aW9ucywgd2hpbGUgbWFpbnRhaW5pbmcg ZG9tYWluIGNvbnNpc3RlbmN5LiBBbmQgdGhpcyBtdXN0IGJlIGRvbmUgd2hpbGUgbWF4aW1pemlu ZyBhcHBsaWNhdGlvbiBkZXZlbG9wZXIgc2ltcGxpY2l0eS7CoCANCg0KVGhpcyBkcmFmdCBpcyBp bnRlbmRlZCB0byBzdGFydCBhZ2dyZWdhdGluZyByZXF1aXJlbWVudHMgaW4gdGhpcyBzcGFjZS7C oCBUaGUgZHJhZnQgaXMgbm90IGNvbXBsZXRlLCBzbyBpdCB3b3VsZCBiZSBncmVhdCB0byBoZWFy IGZyb20gb3RoZXJzIHdobyBhcmUgaW50ZXJlc3RlZCBpbiBoZWxwaW5nIHNvIHRoYXQgd2UgZW5k IHVwIHdpdGggYSBtb3JlIGNvbXByZWhlbnNpdmUgY29udGV4dC4NCg0KU29sdXRpb25zIGRvIGV4 aXN0IHdoaWNoIGNhbiBzb2x2ZSBhIHN1YnNldCBvZiB0aGVzZSByZXF1aXJlbWVudHMuwqAgT25l IHBhcnRpY3VsYXIgdGVjaG5vbG9neSB3ZSBoYXZlIGJ1aWx0IGlzIGtub3duIGFzIOKAnHBlZXIg bW91bnTigJ0uwqAgUGVlciBtb3VudCBnaXZlcyB0aGUgYWJpbGl0eSB0byByZWZlcmVuY2UgWUFO RyBpbmZvcm1hdGlvbiBpbnRvIGEgbG9jYWwgZGF0YXN0b3JlIGZyb20gcmVtb3RlIGRhdGFzdG9y ZXMuwqAgVGhpcyBwcm92aWRlcyBjbGllbnQgYXBwbGljYXRpb25zIHdpdGggbG9jYWwgYWNjZXNz IHRvIGluZm9ybWF0aW9uIHdoaWNoIG1pZ2h0IGJlIHRyYW5zcGFyZW50bHkgZmVkZXJhdGVkIGFj cm9zcyBtdWx0aXBsZSBzeXN0ZW1zIGFuZCBkYXRhc3RvcmVzLsKgIEl0IGFsc28gcmV0YWlucyBj bGVhciBvYmplY3Qgb3duZXJzaGlwIHRvIG1pbmltaXplIHN5bmNocm9uaXphdGlvbiBhbmQgaW50 ZXItc3lzdGVtIGRlcGVuZGVuY3kgaXNzdWVzLsKgwqAgVGhlcmUgYXJlIGFscmVhZHkgaW1wbGVt ZW50YXRpb25zIG9mIHRoaXMgdGVjaG5vbG9neSwgZm9yIGV4YW1wbGUsIGluIE9wZW4gRGF5bGln aHQuwqAgSG93ZXZlciwgd2UgYmVsaWV2ZSByZXF1aXJlbWVudHMgYW5kIHVzZSBjYXNlcyBmb3Ig dGhpcyB0ZWNobm9sb2d5IGFwcGx5IGVxdWFsbHkgd2VsbCB0byBuZXR3b3JrIGRldmljZXMuwqAg DQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiBlaXRoZXIgdGhlIHJlcXVpcmVtZW50cyBvciB0ZWNo bm9sb2d5IHNwZWNpZmljYXRpb25zIGFyZSBwcm9ibGVtIHlvdSBhcmUgaW50ZXJlc3RlZCBpbiBl eHBsb3JpbmcuDQoNClRoYW5rcyENCkVyaWMsIEFsZXgsIFByYWJoYWthcmEsIEFtYmlrYSwgU2hh c2hpDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddIA0KU2VudDogVGh1cnNk YXksIFNlcHRlbWJlciAyNSwgMjAxNCA4OjQxIEFNDQpUbzogUHJhYmhha2FyYSBZZWxsYWkgKHB5 ZWxsYWkpOyBTaGFzaGkgS3VtYXIgQmFuc2FsIChzaGFiYW5zYSk7IEFtYmlrYSBQcmFzYWQgVHJp cGF0aHkgKGFtYnRyaXBhKTsgQWxleGFuZGVyIENsZW1tIChhbGV4KTsgRXJpYyBWb2l0IChldm9p dCk7IEFtYmlrYSBQcmFzYWQgVHJpcGF0aHkgKGFtYnRyaXBhKTsgQWxleGFuZGVyIENsZW1tIChh bGV4KTsgUHJhYmhha2FyYSBZZWxsYWkgKHB5ZWxsYWkpOyBFcmljIFZvaXQgKGV2b2l0KTsgU2hh c2hpIEt1bWFyIEJhbnNhbCAoc2hhYmFuc2EpDQpTdWJqZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmlj YXRpb24gZm9yIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91bnQtcmVxdWlyZW1lbnRzLTAwLnR4 dA0KDQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50 LXJlcXVpcmVtZW50cy0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg RXJpYyBWb2l0IGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZTrCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgIGRyYWZ0LXZvaXQtbmV0bW9kLXBlZXItbW91 bnQtcmVxdWlyZW1lbnRzDQpSZXZpc2lvbjrCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAwMA0K VGl0bGU6wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoCBSZXF1aXJlbWVu dHMgZm9yIFBlZXIgTW91bnRpbmcgb2YgWUFORyBzdWJ0cmVlcyBmcm9tIFJlbW90ZSBEYXRhc3Rv cmVzDQpEb2N1bWVudCBkYXRlOiAyMDE0LTA5LTI1DQpHcm91cDrCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0KUGFnZXM6wqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoCAyMg0KVVJMOsKgwqDCoMKgwqDCoMKgwqDCoMKgwqAgaHR0 cDovL3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtdm9pdC1uZXRtb2QtcGVlci1t b3VudC1yZXF1aXJlbWVudHMtMDAudHh0DQpTdGF0dXM6wqDCoMKgwqDCoMKgwqDCoCBodHRwczov L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJl cXVpcmVtZW50cy8NCkh0bWxpemVkOsKgwqDCoMKgwqDCoCBodHRwOi8vdG9vbHMuaWV0Zi5vcmcv aHRtbC9kcmFmdC12b2l0LW5ldG1vZC1wZWVyLW1vdW50LXJlcXVpcmVtZW50cy0wMA0KDQoNCkFi c3RyYWN0Og0KwqDCoCBOZXR3b3JrIGludGVncmF0ZWQgYXBwbGljYXRpb25zIHdhbnQgc2ltcGxl IHdheXMgdG8gYWNjZXNzIFlBTkcNCsKgwqAgb2JqZWN0cyBhbmQgc3VidHJlZXMgd2hpY2ggbWln aHQgYmUgZGlzdHJpYnV0ZWQgYWNyb3NzIG5ldHdvcmsuDQrCoMKgIFBlcmZvcm1hbmNlIHJlcXVp cmVtZW50cyBtYXkgZGljdGF0ZSB0aGF0IGl0IGlzIHVuYWZmb3JkYWJsZSBmb3IgYQ0KwqDCoCBz dWJzZXQgb2YgdGhlc2UgYXBwbGljYXRpb25zIHRvIGdvIHRocm91Z2ggZXhpc3RpbmcgY2VudHJh bGl6ZWQNCsKgwqAgbWFuYWdlbWVudCBicm9rZXJzLsKgIEZvciBzdWNoIGFwcGxpY2F0aW9ucywg ZGV2ZWxvcG1lbnQgY29tcGxleGl0eQ0KwqDCoCBtdXN0IGJlIG1pbmltaXplZC7CoCBTcGVjaWZp YyBhc3BlY3RzIG9mIGNvbXBsZXhpdHkgZGV2ZWxvcGVycyB3YW50IHRvDQrCoMKgIGlnbm9yZSBp bmNsdWRlOg0KDQrCoMKgIG/CoCB3aGV0aGVyIGF1dGhvcml0YXRpdmUgaW5mb3JtYXRpb24gaXMg YWN0dWFsbHkgc291cmNlZCBmcm9tIHJlbW90ZQ0KwqDCoMKgwqDCoCBkYXRhc3RvcmVzIChhcyB3 ZWxsIGFzIGhvdyB0byBnZXQgdG8gdGhvc2UgZGF0YXN0b3JlcyksDQoNCsKgwqAgb8KgIHdoZXRo ZXIgc3VjaCBpbmZvcm1hdGlvbiBoYXMgYmVlbiBsb2NhbGx5IGNhY2hlZCBvciBub3QsDQoNCsKg wqAgb8KgIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8sIG9uZSwgb3IgbW9yZSBjb250cm9sbGVycyBh c3NlcnRpbmcNCsKgwqDCoMKgwqAgb3duZXJzaGlwIG9mIGluZm9ybWF0aW9uLCBhbmQNCg0KwqDC oCBvwqAgd2hldGhlciB0aGVyZSBhcmUgaW50ZXJhY3Rpb25zIHdpdGggb3RoZXIgYXBwbGljYXRp b25zDQrCoMKgwqDCoMKgIGNvbmN1cnJlbnRseSBydW5uaW5nIGVsc2V3aGVyZQ0KDQrCoMKgIFRo ZSBzb2x1dGlvbiByZXF1aXJlbWVudHMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQgZGV0YWls IHdoYXQgaXMNCsKgwqAgbmVlZGVkIHRvIHN1cHBvcnQgYXBwbGljYXRpb24gYWNjZXNzIHRvIGF1 dGhvcml0YXRpdmUgbmV0d29yayBZQU5HDQrCoMKgIG9iamVjdHMgZnJvbSBjb250cm9sbGVycyAo c3Rhcikgb3IgcGVlcmluZyBuZXR3b3JrIGRldmljZXMgKG1lc2gpIGluDQrCoMKgIHN1Y2ggYSB3 YXkgdG8gbWVldCB0aGVzZSBnb2Fscy4NCg0KwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg wqDCoMKgwqDCoMKgwqDCoMKgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBj b3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0 bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4N Cg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0K From nobody Thu Sep 25 16:01:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 914FE1A00C0; Thu, 25 Sep 2014 16:01:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 UE1vEwphnGGG; Thu, 25 Sep 2014 16:01:19 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A346D1A00B9; Thu, 25 Sep 2014 16:01:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Martin Bjorklund'" , References: <20140922210546.GA5676@pfrc> <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> In-Reply-To: <20140924.092658.622309529428712352.mbj@tail-f.com> Date: Thu, 25 Sep 2014 19:01:15 -0400 Message-ID: <017f01cfd914$9c693e70$d53bbb50$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAIsC/HyAjLRcSWcoOsr0A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6Otc0r7dvyoySPeBfMocZU5Znyo Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Sep 2014 23:01:21 -0000 Martin: Does this mean if the I2RS model provides additional functions that are not a base configuration model that the xpath should just work? Xpath1- Config - ISIS Yang model that configures Xpath2 - I2RS ISIS empheral - inherits all the configuration state ____ I2RS ISIS actions - report on the interface changes on ISIS L1 interfaces Is my I2RS ISIS model a combination of the inherited state and the I2RS actions? Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund Sent: Wednesday, September 24, 2014 3:27 AM To: j.schoenwaelder@jacobs-university.de Cc: jhaas@pfrc.org; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Juergen Schoenwaelder wrote: > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > Some discussion was given to the filtering considerations. > > Extending the filtering options of the ietf-inet-types module may be appropriate. > > [Juergen, is this an action item for yang 1.1?] > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > functions. I like to ask I2RS to tell us what functions they need. We > do have IP prefix-length matching on our radar. If other functions are > required, please let us know as soon as possible. > > Now, this mostly is about the xpath function set that can be used in > must and when expressions. You probably want to use them also in > filtering expressions in the protocol. This is where things again > become a protocol issues. Note that RFC 6241 says on page 17: > > The XPath expression is interpreted in the following context: > > [...] > > * The function library is the core function library. The quoted text is for the error-path. For the filter, rfc 6241 says (p 67): o The function library is the core function library, plus any functions defined by the data model. /martin _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From boxs.jq@gmail.com Thu Sep 25 22:16:58 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7EE21A1A10 for ; Thu, 25 Sep 2014 22:16:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 lPYvvw0PMRSP for ; Thu, 25 Sep 2014 22:16:58 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5AD5A1A1A0E for ; Thu, 25 Sep 2014 22:16:49 -0700 (PDT) Received: by mail-yk0-f170.google.com with SMTP id 19so3688027ykq.29 for ; Thu, 25 Sep 2014 22:16:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=gAJbHC0TbeH04mD2jls9ysvnWB93PyFYtxOut/P/XEM=; b=lc71rEVGR6MrQeQcsa4SOjUXTBdV3EyJvM6tIQs15Yqh1f605Z34Jk6oaNhRM/zXLZ bl11DLlEn6yw/GEioLDxueVmPxrq4mdFbMn29dBc8gXIKP/BD/UnqEt//hwmhk63ZFYM EhQHH7N//aHuISvLtWbOkFDxjDUoxXk5A5Xk7J8jE6GA0ILNichE0JDeB+YXx7oBFeJL R7QIIYVaSYDe3UXRUzh9U/VfSSBZjJi5+dN7qg34ARx/iufJgUzGLAK+6oSdvXePzpWb 85yGUgcblqOe5acrvSgVgIKGwBqE7s6sh2HIpSLFjgD6nqz8kWpPMsIrDyUSUlTdd025 VIPg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=gAJbHC0TbeH04mD2jls9ysvnWB93PyFYtxOut/P/XEM=; b=ngqJth0GBUgIYjl7b+Z9HLFHXesdG3KwscD7Fd08ck7TfHrvZocARkJG93se+wqMTj B45FDpidxCaXrm+uUhDdd5dYITuS4pCtk7zmPSuuy/3j86ucY9Gsk9A+6tX1i9oG/old qWRM8jPpg+nfvky/YrcpSh3DFRmqDHFo/0YrA= X-Received: by 10.236.121.228 with SMTP id r64mr19431648yhh.31.1411708608703; Thu, 25 Sep 2014 22:16:48 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.6 with HTTP; Thu, 25 Sep 2014 22:16:27 -0700 (PDT) From: Xiao SHI Date: Fri, 26 Sep 2014 01:16:27 -0400 X-Google-Sender-Auth: q4QRo3z5A88kJCsq9u-DGwY5EzE Message-ID: To: netmod@ietf.org Content-Type: multipart/alternative; boundary=20cf3010e68d25f37f0503f106bb Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/UWnyCjEQLnpQGdYMTXaTS6xfLKY Cc: Richard Yang Subject: [netmod] Referencing rpc input in rpc output using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 05:18:16 -0000 --20cf3010e68d25f37f0503f106bb Content-Type: text/plain; charset=UTF-8 Hi all, I was trying to reference some rpc input data in rpc output, specifically: Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input contains a set of nodes I care about, and I'd like to make sure that my output (rpc response) contains only the nodes that appeared in the input. I tried to use leafref statement to model this restriction. Here's my YANG model: rpc my-rpc { input { container my-set { leaf-list nodes { type node; } } } output { list my-output { leaf nodes { type leafref { path "..."; // trying to refer to the nodes leaf-list in input. } } } } } It doesn't seem like I am allowed to refer to an rpc leaf? (When I used pyang to validate, it throws an error saying the path references a rpc node.) Should I try something other than leafref? I tried to use must statment with XPATH expression, but I couldn't find an "in" operator in XPATH. I am fairly new to YANG, any help would be much appreciated. Thank you! Xiao --20cf3010e68d25f37f0503f106bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

I was trying to reference some = rpc input data in rpc output, specifically:

Suppos= e I have an universe of nodes {A, B, C, D, E}, and my rpc input contains a = set of nodes I care about, and I'd like to make sure that my output (rp= c response) contains only the nodes that appeared in the input. I tried to = use leafref statement to model this restriction.

H= ere's my YANG model:
rpc my-rpc {
=C2=A0 input {
=C2=A0 =C2=A0 container my-set {
=C2=A0 =C2=A0 =C2=A0 lea= f-list nodes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type node;
= =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }
=C2=A0 }
=C2=A0 output {
=C2=A0 =C2=A0 list my-output {
=C2= =A0 =C2=A0 =C2=A0 leaf nodes {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 type l= eafref {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 path "...";= // trying to refer to the nodes leaf-list in input.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2= =A0 }
=C2=A0 }
}

It doesn'= t seem like I am allowed to refer to an rpc leaf? (When I used pyang to val= idate, it throws an error saying the path references a rpc node.) Should I = try something other than leafref? I tried to use must statment with XPATH e= xpression, but I couldn't find an "in" operator in XPATH.

I am fairly new to YANG, any help would be much appre= ciated.

Thank you!
Xiao
--20cf3010e68d25f37f0503f106bb-- From nobody Thu Sep 25 23:37:23 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56D4B1A1A4B for ; Thu, 25 Sep 2014 23:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 V-2fmGGV_5hn for ; Thu, 25 Sep 2014 23:37:20 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 1BA921A1A43 for ; Thu, 25 Sep 2014 23:37:17 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 696C51280474; Fri, 26 Sep 2014 08:37:15 +0200 (CEST) Date: Fri, 26 Sep 2014 08:37:14 +0200 (CEST) Message-Id: <20140926.083714.2095466170873894971.mbj@tail-f.com> To: xiao.shi@yale.edu From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.5 on Emacs 23.4 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/suoSy5NAyG7iOlqkTKQstmuT6b0 Cc: netmod@ietf.org Subject: Re: [netmod] Referencing rpc input in rpc output using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 06:37:22 -0000 Hi, Xiao SHI wrote: > Hi all, > > I was trying to reference some rpc input data in rpc output, specifically: > > Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input > contains a set of nodes I care about, and I'd like to make sure that my > output (rpc response) contains only the nodes that appeared in the input. I > tried to use leafref statement to model this restriction. This constraint is not possible to express formally in YANG. The only thing you can do is document this in the description clause. /martin > > Here's my YANG model: > rpc my-rpc { > input { > container my-set { > leaf-list nodes { > type node; > } > } > } > output { > list my-output { > leaf nodes { > type leafref { > path "..."; // trying to refer to the nodes leaf-list in input. > } > } > } > } > } > > It doesn't seem like I am allowed to refer to an rpc leaf? (When I used > pyang to validate, it throws an error saying the path references a rpc > node.) Should I try something other than leafref? I tried to use must > statment with XPATH expression, but I couldn't find an "in" operator in > XPATH. > > I am fairly new to YANG, any help would be much appreciated. > > Thank you! > Xiao From nobody Thu Sep 25 23:44:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 685F21A1A43; Thu, 25 Sep 2014 23:44:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, 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 KtDwCMrq8xft; Thu, 25 Sep 2014 23:44:01 -0700 (PDT) Received: from mail.tail-f.com (mail.tail-f.com [83.241.162.140]) by ietfa.amsl.com (Postfix) with ESMTP id 39B741A1A32; Thu, 25 Sep 2014 23:44:01 -0700 (PDT) Received: from localhost (173-38-208-169.cisco.com [173.38.208.169]) by mail.tail-f.com (Postfix) with ESMTPSA id 3C9B91280474; Fri, 26 Sep 2014 08:44:00 +0200 (CEST) Date: Fri, 26 Sep 2014 08:43:59 +0200 (CEST) Message-Id: <20140926.084359.2189946003061989153.mbj@tail-f.com> To: shares@ndzh.com From: Martin Bjorklund In-Reply-To: <017f01cfd914$9c693e70$d53bbb50$@ndzh.com> References: <20140924070025.GD23280@elstar.local> <20140924.092658.622309529428712352.mbj@tail-f.com> <017f01cfd914$9c693e70$d53bbb50$@ndzh.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/netmod/qyuKKjKgBr8CSSAdaRk21QueDTA Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 06:44:03 -0000 "Susan Hares" wrote: > Martin: > > Does this mean if the I2RS model provides additional functions that are not > a base configuration model that the xpath should just work? It means that the protocol specification does not lock down the set of XPath functions available in a filter. However, there is no standard way currently to declare new XPath functions in YANG data models. (see the expired https://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00 for some ideas in this area). (For the set of core XPath functions see http://www.w3.org/TR/xpath/#corelib) /martin > Xpath1- Config - ISIS Yang model that configures > Xpath2 - I2RS ISIS empheral - inherits all the configuration state > ____ I2RS ISIS actions - report on the interface changes on ISIS > L1 interfaces > > Is my I2RS ISIS model a combination of the inherited state and the I2RS > actions? > > Sue > > > -----Original Message----- > From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Wednesday, September 24, 2014 3:27 AM > To: j.schoenwaelder@jacobs-university.de > Cc: jhaas@pfrc.org; i2rs@ietf.org; netmod@ietf.org > Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on > i2rs requirements on netmod/netconf > > Juergen Schoenwaelder wrote: > > On Mon, Sep 22, 2014 at 05:05:46PM -0400, Jeffrey Haas wrote: > > > Some discussion was given to the filtering considerations. > > > Extending the filtering options of the ietf-inet-types module may be > appropriate. > > > [Juergen, is this an action item for yang 1.1?] > > > > The YANG 1.1 issue Y20 is about adding a set of built-in xpath > > functions. I like to ask I2RS to tell us what functions they need. We > > do have IP prefix-length matching on our radar. If other functions are > > required, please let us know as soon as possible. > > > > Now, this mostly is about the xpath function set that can be used in > > must and when expressions. You probably want to use them also in > > filtering expressions in the protocol. This is where things again > > become a protocol issues. Note that RFC 6241 says on page 17: > > > > The XPath expression is interpreted in the following context: > > > > [...] > > > > * The function library is the core function library. > > The quoted text is for the error-path. For the filter, rfc 6241 says (p > 67): > > o The function library is the core function library, plus any > functions defined by the data model. > > > /martin > > _______________________________________________ > i2rs mailing list > i2rs@ietf.org > https://www.ietf.org/mailman/listinfo/i2rs > From nobody Fri Sep 26 09:21:18 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8D01A8A7F; Fri, 26 Sep 2014 09:21:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 eZUa3SUgkGxc; Fri, 26 Sep 2014 09:21:10 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id A2F7D1A8A88; Fri, 26 Sep 2014 09:20:23 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Juergen Schoenwaelder'" , "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <20140925062456.GB26200@elstar.local> In-Reply-To: <20140925062456.GB26200@elstar.local> Date: Fri, 26 Sep 2014 12:20:15 -0400 Message-ID: <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAirw7sYBPQLsZQJvt0DrAf4qT3uccaV38A== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/FOTOpjMR-doEG73bIwk7ugHVXHA Cc: netmod@ietf.org, i2rs@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:21:12 -0000 Juregen and Jeff: Can you define what a merge is? Could you define it using the example below and another one? I know you have talked around the subject, but I need another examples so I can adjust the drafts in progress with co-authors (ISIS IM-DM, OSPF IM-DM, BGP IM-DM, PBR IM/DM) for i2rs. Sue ============ list foo { key id; leaf id { type int32; } leaf a { type int32; } } local config: foo 42 In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in ephemeral we now have a single node (a) with value 4711. -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Thursday, September 25, 2014 2:25 AM To: Jeffrey Haas Cc: Thomas D. Nadeau; i2rs@ietf.org; Susan Hares; netmod@ietf.org Subject: Re: [i2rs] [netmod] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf On Wed, Sep 24, 2014 at 11:34:01AM -0400, Jeffrey Haas wrote: > On Wed, Sep 24, 2014 at 07:35:47AM -0400, Thomas D. Nadeau wrote: > > On Sep 24, 2014:3:10 AM, at 3:10 AM, Juergen Schoenwaelder wrote: > [...] > > > > > > +-----------------+ > > > | | > > > +--- (+) ---+ | > > > ^ ^ v > > > +---+ +---+ +---+ > > > | | | | | | > > > |(1)| | | | | > > > | | | | | | > > > +---+ +---+ +---+ > > > > > > NC config ephemeral operational > > > datastore datastore state > > > > > > (1) The complete NC config datastore is at certain synchronization > > > points made persistent > > > > > > (+) Priority resolution, priorities may be per datastore or per > > > user or per 'application' or even per data node > > > > These are precisely the qualities I and some others were thinking of when we started i2rs. The idea is quite simple, as you have said above and really needs not be complicated more. > > It has its own complications. > > Do we permit more than one ephemeral datastore? If so, this > simplifies data object priority when resolving the operational state. > But this also complicates operational state integrity when you have > multiple cross references. It complicates the merge operation - it does not affect the integrity of the operational state. But even that may not be true, at least not from the point of the merge algorithm. There likely is not much difference between merging 1 or N ephemeral datastores. And at the end of the day, if you have I2RS systems injecting conflicts, then it does not matter whether that happens in 1 ephemeral datastore and N ephemeral datastores. Having N ephemeral datastores had the advantage that I can easily disable a complete ephemeral datastore by modifying its priority while multiple I2RS systems writing concurrently into the same scratchpad will be much more fun to deal with. /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 Fri Sep 26 09:23:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EDAC1A8A1D; Fri, 26 Sep 2014 09:23:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.946 X-Spam-Level: X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=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 OjDU6gw7s_ab; Fri, 26 Sep 2014 09:23:25 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4D2611A8A8A; Fri, 26 Sep 2014 09:22:29 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> In-Reply-To: <20140924154352.GE2639@pfrc> Date: Fri, 26 Sep 2014 12:22:25 -0400 Message-ID: <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D4_01CFD984.8824FE70" X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAfcWsUScoHWRYA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/9ShC6DkvrLpZ-kl_PhlM1XZBj4g Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 16:23:26 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D4_01CFD984.8824FE70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Jeff: Just to confirm three facts before I put them in i2rs drafts (based on Juergen's email - based on Juergen's email: I2RS is "config true empheral". If i2rs has additional configuration for BGP related to your I2RS peers for reporting routes: . BGP based config + I2RS additional config + AS Config Can I2RS have additional configuration values specific to I2RS? For example, information regarding how often to report the routes for a particular pear? Sue -----Original Message----- From: Jeffrey Haas [mailto:jhaas@pfrc.org] Sent: Wednesday, September 24, 2014 11:44 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff ------=_NextPart_000_02D4_01CFD984.8824FE70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Jeff:

 

Just = to confirm three facts before I put them in i2rs drafts (based on = Juergen's email

- based on = Juergen's email:   I2RS is "config true = empheral". 

 

If = i2rs has additional configuration for BGP related to your I2RS peers for = reporting routes:

 

·         = BGP based config + I2RS additional config = + AS Config

 

Can = I2RS have additional configuration values specific to I2RS?  For = example, information regarding how often to report the routes for a = particular pear? 

 

Sue =

 

-----Original Message-----
From: Jeffrey Haas = [mailto:jhaas@pfrc.org]
Sent: Wednesday, September 24, 2014 11:44 = AM
To: Susan Hares
Cc: 'Jeffrey Haas'; i2rs@ietf.org; = netmod@ietf.org
Subject: Re: [i2rs] Summary of discussion from netmod = interim on i2rs requirements on netmod/netconf

 

Sue,

 

On = Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares = wrote:

> The fourth option is = interesting and creative. A few

> questions/requests: 1) How would the fourth = model be expressed in the

> = yang model  - config (empheral)?

 

I = believe Juergen has answered this point.

 

> = 2)  Please define your definition of local config with an = example.,

 

This corresponds to "config true" state, = probably in the running datastore.

The semantics on the impact for the commit model = when writable-running is not in use haven't been fully = explored.

 

> and 3) please give an example of the (must, = when) use cases

> = envisioned?

 

In the = original proposal in my draft, when we had completely disjoint = datastores, consider the BGP I2RS ephemeral peer case.  The I2RS = model would have a container of ephemeral peers.  That container = might not specify the local Autonomous System number.  In that = case, there would be a MUST requirement for that neighbor that there = exist a system-wide configured Autonomous System number, probably in the = local Config.

 

Currently, there is no syntax that says how to = examine nodes that are in a different datastore.  From an XPath = context, the current datastore is the document context.

 

In the = new proposal, since the ephemeral datastore gets a shadow of the local = config, there is no need to have extensions to XPath to refer between = data stores.

 

However, if we end up with more than one ephemeral = datastore (not recommended for this reason), such an issue = returns.

 

-- Jeff

------=_NextPart_000_02D4_01CFD984.8824FE70-- From nobody Fri Sep 26 10:11:10 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CE51A1AAD; Fri, 26 Sep 2014 10:11:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.945 X-Spam-Level: X-Spam-Status: No, score=0.945 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845] 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 HNZN53j-SDno; Fri, 26 Sep 2014 10:11:06 -0700 (PDT) Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9F86A1A0174; Fri, 26 Sep 2014 10:11:06 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.124.172.144; From: "Susan Hares" To: "'Jeffrey Haas'" References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> In-Reply-To: <20140924154352.GE2639@pfrc> Date: Fri, 26 Sep 2014 13:11:02 -0400 Message-ID: <032401cfd9ac$da30b060$8e921120$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQF3IdMyVAHRiXadTYRdGi5dr3BteAKWU6WdAfcWsUScoKoxgA== X-Authenticated-User: skh@ndzh.com Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/alBY72xKp6jImseWTqnqZMyAA9c Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Sep 2014 17:11:08 -0000 Jeff: Could you give me an example of the interim's thoughts on commit versus Alexander's message: http://www.ietf.org/mail-archive/web/i2rs/current/msg01974.html Sue -----Original Message----- From: i2rs [mailto:i2rs-bounces@ietf.org] On Behalf Of Jeffrey Haas Sent: Wednesday, September 24, 2014 11:44 AM To: Susan Hares Cc: 'Jeffrey Haas'; i2rs@ietf.org; netmod@ietf.org Subject: Re: [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf Sue, On Tue, Sep 23, 2014 at 06:14:16PM -0400, Susan Hares wrote: > The fourth option is interesting and creative. A few > questions/requests: 1) How would the fourth model be expressed in the > yang model - config (empheral)? I believe Juergen has answered this point. > 2) Please define your definition of local config with an example., This corresponds to "config true" state, probably in the running datastore. The semantics on the impact for the commit model when writable-running is not in use haven't been fully explored. > and 3) please give an example of the (must, when) use cases > envisioned? In the original proposal in my draft, when we had completely disjoint datastores, consider the BGP I2RS ephemeral peer case. The I2RS model would have a container of ephemeral peers. That container might not specify the local Autonomous System number. In that case, there would be a MUST requirement for that neighbor that there exist a system-wide configured Autonomous System number, probably in the local Config. Currently, there is no syntax that says how to examine nodes that are in a different datastore. From an XPath context, the current datastore is the document context. In the new proposal, since the ephemeral datastore gets a shadow of the local config, there is no need to have extensions to XPath to refer between data stores. However, if we end up with more than one ephemeral datastore (not recommended for this reason), such an issue returns. -- Jeff _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs From nobody Sat Sep 27 22:43:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F85C1A030F for ; Sat, 27 Sep 2014 22:43:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.377 X-Spam-Level: X-Spam-Status: No, score=-1.377 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 KHQwtBI58q5T for ; Sat, 27 Sep 2014 22:43:54 -0700 (PDT) Received: from mail-oi0-x229.google.com (mail-oi0-x229.google.com [IPv6:2607:f8b0:4003:c06::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CC48C1A0309 for ; Sat, 27 Sep 2014 22:43:53 -0700 (PDT) Received: by mail-oi0-f41.google.com with SMTP id u20so11644500oif.0 for ; Sat, 27 Sep 2014 22:43:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aAy2yf3iZ0arwOeSsXy7WhrvALIyb53gbGEH47dyEs0=; b=tX2RyIE6eLdGAJhI9InZhoERieMgjFEOzvxB4QVIm3Sx90Jf+rZwnK3nkwchIPsUpy wrt/jB3o5aTn/PECtp/qNoSSsKKl6tBd0ysx5OklV33Rwv/vzzeJukNcby3dHxNTm5nP eaffbjODlxM2hUCx6A+0iak7erlD7kdT1czjX9YFwsrMQVAvUge5ywQL5BRsO2FLVsej YuFVQMI/EkeO1SCfxtwKXuoXaLVtZ1fewfYSAWa/tCAqcRTzP5hRFKepGaBC/iGXwqUp 31JkjWMKqUBojs5w1gzomOn9y5u/J7RgPL0IIITJW/lboaEppvc4Oaldha9hAZVhD32T cnPA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=aAy2yf3iZ0arwOeSsXy7WhrvALIyb53gbGEH47dyEs0=; b=ezore+Y70s11WR1sLFT4nRaJ7Xn4xESOoRe4tqN65O2pFLCACfVWvTgEk7t5Bi+YO8 qse5OSTwfWzkMrIycZdiR5h8tmRNEY9oxujrMaXu4RkKkRJdNl+YnKvBRbcf8AIdhIjn rZfX4E843+fBTZNXwRubb8hHZ2urPCYmndDMM= X-Received: by 10.60.160.74 with SMTP id xi10mr32851241oeb.56.1411883033220; Sat, 27 Sep 2014 22:43:53 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.182.108.65 with HTTP; Sat, 27 Sep 2014 22:43:33 -0700 (PDT) In-Reply-To: <20140926.083714.2095466170873894971.mbj@tail-f.com> References: <20140926.083714.2095466170873894971.mbj@tail-f.com> From: Xiao SHI Date: Sun, 28 Sep 2014 01:43:33 -0400 X-Google-Sender-Auth: r_rs9ehHNCJyIr6zO7dbLylSM3c Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=089e0117697da8d9a1050419a2b6 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/WmF8KcnWHhZoKFyf1DbkxnT75ww Cc: netmod@ietf.org Subject: Re: [netmod] Referencing rpc input in rpc output using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 05:43:55 -0000 --089e0117697da8d9a1050419a2b6 Content-Type: text/plain; charset=UTF-8 Hi Martin, Thanks for your reply! Just out of curiosity, is there a particular reason that leafref cannot refer to things in rpc-input? Is this a design choice? Or would this be a future feature? Thanks, Xiao On Fri, Sep 26, 2014 at 2:37 AM, Martin Bjorklund wrote: > Hi, > > Xiao SHI wrote: > > Hi all, > > > > I was trying to reference some rpc input data in rpc output, > specifically: > > > > Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input > > contains a set of nodes I care about, and I'd like to make sure that my > > output (rpc response) contains only the nodes that appeared in the > input. I > > tried to use leafref statement to model this restriction. > > This constraint is not possible to express formally in YANG. > > The only thing you can do is document this in the description clause. > > > /martin > > > > > > > Here's my YANG model: > > rpc my-rpc { > > input { > > container my-set { > > leaf-list nodes { > > type node; > > } > > } > > } > > output { > > list my-output { > > leaf nodes { > > type leafref { > > path "..."; // trying to refer to the nodes leaf-list in input. > > } > > } > > } > > } > > } > > > > It doesn't seem like I am allowed to refer to an rpc leaf? (When I used > > pyang to validate, it throws an error saying the path references a rpc > > node.) Should I try something other than leafref? I tried to use must > > statment with XPATH expression, but I couldn't find an "in" operator in > > XPATH. > > > > I am fairly new to YANG, any help would be much appreciated. > > > > Thank you! > > Xiao > --089e0117697da8d9a1050419a2b6 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Martin,

Thanks for your reply!
=

Just out of curiosity, is there a particular reason tha= t leafref cannot refer to things in rpc-input? Is this a design choice? Or = would this be a future feature?

Thanks,
= Xiao

O= n Fri, Sep 26, 2014 at 2:37 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Xiao SHI <xiao.shi@yale.edu>= wrote:
> Hi all,
>
> I was trying to reference some rpc input data in rpc output, specifica= lly:
>
> Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input<= br> > contains a set of nodes I care about, and I'd like to make sure th= at my
> output (rpc response) contains only the nodes that appeared in the inp= ut. I
> tried to use leafref statement to model this restriction.

This constraint is not possible to express formally in YANG.

The only thing you can do is document this in the description clause.


/martin



>
> Here's my YANG model:
> rpc my-rpc {
>=C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0container my-set {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list nodes {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type node;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0output {
>=C2=A0 =C2=A0 =C2=A0list my-output {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nodes {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "..."; // tryin= g to refer to the nodes leaf-list in input.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> It doesn't seem like I am allowed to refer to an rpc leaf? (When I= used
> pyang to validate, it throws an error saying the path references a rpc=
> node.) Should I try something other than leafref? I tried to use must<= br> > statment with XPATH expression, but I couldn't find an "in&qu= ot; operator in
> XPATH.
>
> I am fairly new to YANG, any help would be much appreciated.
>
> Thank you!
> Xiao

--089e0117697da8d9a1050419a2b6-- From nobody Sun Sep 28 12:44:37 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A28F1A1BC8 for ; Sun, 28 Sep 2014 12:44:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, 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 CojsdAdrQeeS for ; Sun, 28 Sep 2014 12:44:35 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A43671A1B91 for ; Sun, 28 Sep 2014 12:44:34 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id t60so11981697wes.37 for ; Sun, 28 Sep 2014 12:44:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8EcDRV4Sh8/33xBKB+ulPy+JejYYGt4EZX5lI4IkRBs=; b=m8H55xtgEfVwtn7/AasOXJ2pV7CbZdR5V21F5pNcnabWtiL1nkXzSvBuE65k4n6uDV 55YspEqfpX/wxHb/FAMGi4maDoYLEZfqVQVrJ/K8kwaHldtjx3r/+/UHa1JwRgvITUcf NetXtdu2pH4o6coj/28KmBXKX/wNDKcFaodqdRrD+p/Fbugdqc7tmq1xh0/816o4Jl0E VbSWWEy2CsJtVjSQ76eYWp0arDnZO1JP8Lqu4QPHsDyyfyMRZTFavSgo9ZtIKxHhFm9a ol8s42FBwxvtUtdr2Fo4Ado/L8ZzbJpj1smQrayuqmDhSOOqs/Ab7Cq/lnaGNfoR+SYF rgUQ== MIME-Version: 1.0 X-Received: by 10.181.27.132 with SMTP id jg4mr43007967wid.28.1411933473124; Sun, 28 Sep 2014 12:44:33 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.139 with HTTP; Sun, 28 Sep 2014 12:44:33 -0700 (PDT) In-Reply-To: References: <20140926.083714.2095466170873894971.mbj@tail-f.com> Date: Sun, 28 Sep 2014 15:44:33 -0400 X-Google-Sender-Auth: BQoh2g9P0Ju0L35MRRoIlOGkIOw Message-ID: From: "Y. Richard Yang" To: Xiao SHI Content-Type: multipart/alternative; boundary=001a11c3435c1cb9950504256162 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/OrxMQbUuuZ0RxHd5IafZ2KS9CaI Cc: netmod@ietf.org Subject: Re: [netmod] Referencing rpc input in rpc output using YANG X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Sep 2014 19:44:36 -0000 --001a11c3435c1cb9950504256162 Content-Type: text/plain; charset=UTF-8 I can guess that YANG constraints are focused only on the consistency of the global "universe" of data, not each transaction. Hence, if one considers rpc as the transactions part, not the universe part, then it is a reasonable design. Is this a right way to understand the design? Richard On Sun, Sep 28, 2014 at 1:43 AM, Xiao SHI wrote: > Hi Martin, > > Thanks for your reply! > > Just out of curiosity, is there a particular reason that leafref cannot > refer to things in rpc-input? Is this a design choice? Or would this be a > future feature? > > Thanks, > Xiao > > On Fri, Sep 26, 2014 at 2:37 AM, Martin Bjorklund wrote: > >> Hi, >> >> Xiao SHI wrote: >> > Hi all, >> > >> > I was trying to reference some rpc input data in rpc output, >> specifically: >> > >> > Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input >> > contains a set of nodes I care about, and I'd like to make sure that my >> > output (rpc response) contains only the nodes that appeared in the >> input. I >> > tried to use leafref statement to model this restriction. >> >> This constraint is not possible to express formally in YANG. >> >> The only thing you can do is document this in the description clause. >> >> >> /martin >> >> >> >> > >> > Here's my YANG model: >> > rpc my-rpc { >> > input { >> > container my-set { >> > leaf-list nodes { >> > type node; >> > } >> > } >> > } >> > output { >> > list my-output { >> > leaf nodes { >> > type leafref { >> > path "..."; // trying to refer to the nodes leaf-list in >> input. >> > } >> > } >> > } >> > } >> > } >> > >> > It doesn't seem like I am allowed to refer to an rpc leaf? (When I used >> > pyang to validate, it throws an error saying the path references a rpc >> > node.) Should I try something other than leafref? I tried to use must >> > statment with XPATH expression, but I couldn't find an "in" operator in >> > XPATH. >> > >> > I am fairly new to YANG, any help would be much appreciated. >> > >> > Thank you! >> > Xiao >> > --001a11c3435c1cb9950504256162 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I can guess that YANG constraints are focused only on= the consistency of the global "universe" of data, not each trans= action. Hence, if one considers rpc as the transactions part, not the unive= rse part, then it is a reasonable design. Is this a right way to understand= the design?

Richard

On Sun, Sep 28, 2014 at 1:43 AM, Xiao= SHI <xiao.shi@yale.edu> wrote:
Hi Martin,

Thanks for your reply!=

Just out of curiosity, is there a particular reas= on that leafref cannot refer to things in rpc-input? Is this a design choic= e? Or would this be a future feature?

Thanks,
Xiao

On Fri, Sep 26, 2014 at 2:37 A= M, Martin Bjorklund <mbj@tail-f.com> wrote:
Hi,

Xiao SHI <xiao.sh= i@yale.edu> wrote:
> Hi all,
>
> I was trying to reference some rpc input data in rpc output, specifica= lly:
>
> Suppose I have an universe of nodes {A, B, C, D, E}, and my rpc input<= br> > contains a set of nodes I care about, and I'd like to make sure th= at my
> output (rpc response) contains only the nodes that appeared in the inp= ut. I
> tried to use leafref statement to model this restriction.

This constraint is not possible to express formally in YANG.

The only thing you can do is document this in the description clause.


/martin



>
> Here's my YANG model:
> rpc my-rpc {
>=C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0container my-set {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf-list nodes {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type node;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
>=C2=A0 =C2=A0output {
>=C2=A0 =C2=A0 =C2=A0list my-output {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0leaf nodes {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type leafref {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0path "..."; // tryin= g to refer to the nodes leaf-list in input.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0}
> }
>
> It doesn't seem like I am allowed to refer to an rpc leaf? (When I= used
> pyang to validate, it throws an error saying the path references a rpc=
> node.) Should I try something other than leafref? I tried to use must<= br> > statment with XPATH expression, but I couldn't find an "in&qu= ot; operator in
> XPATH.
>
> I am fairly new to YANG, any help would be much appreciated.
>
> Thank you!
> Xiao
--001a11c3435c1cb9950504256162-- From nobody Sun Sep 28 23:32:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F8F91A6FC1; Sun, 28 Sep 2014 23:31:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.336 X-Spam-Level: X-Spam-Status: No, score=-2.336 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.786] 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 TW6G0osyJb5k; Sun, 28 Sep 2014 23:31:54 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 35F831A6FC6; Sun, 28 Sep 2014 23:31:54 -0700 (PDT) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9682A75C; Mon, 29 Sep 2014 08:31:52 +0200 (CEST) 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 CFvKdk3Vsmxt; Mon, 29 Sep 2014 08:31:51 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Sep 2014 08:31:52 +0200 (CEST) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2665120036; Mon, 29 Sep 2014 08:31:52 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3KdlbGIalfAa; Mon, 29 Sep 2014 08:31:51 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B5D9720035; Mon, 29 Sep 2014 08:31:50 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id 946DD2EA67D2; Mon, 29 Sep 2014 08:31:49 +0200 (CEST) Date: Mon, 29 Sep 2014 08:31:49 +0200 From: Juergen Schoenwaelder To: Susan Hares Message-ID: <20140929063149.GB76248@elstar.local> Mail-Followup-To: Susan Hares , 'Jeffrey Haas' , "'Thomas D. Nadeau'" , i2rs@ietf.org, netmod@ietf.org References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924071023.GF23280@elstar.local> <20140924153401.GC2639@pfrc> <20140925062456.GB26200@elstar.local> <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02ce01cfd9a5$c1e81f40$45b85dc0$@ndzh.com> User-Agent: Mutt/1.4.2.3i Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8K-XlNSiEfgqgIAUDGZiXFlyXWw Cc: netmod@ietf.org, i2rs@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 06:31:56 -0000 On Fri, Sep 26, 2014 at 12:20:15PM -0400, Susan Hares wrote: > Juregen and Jeff: > > Can you define what a merge is? Could you define it using the example below > and another one? I know you have talked around the subject, but I need > another examples so I can adjust the drafts in progress with co-authors > (ISIS IM-DM, OSPF IM-DM, BGP IM-DM, PBR IM/DM) for i2rs. > > Sue > > ============ > list foo { > key id; > leaf id { type int32; } > leaf a { type int32; } > } > > local config: > > foo 42 > > In ephemeral config we now do SET /foo[id=42]/a to 4711. Thus, in > ephemeral we now have a single node (a) with value 4711. > Merge as in NETCONF. We also discussed to have meta data attached to nodes in ephemeral datastores in order to allow things to be deleted etc. /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 Sep 29 07:16:22 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980F31A1A9E; Mon, 29 Sep 2014 07:16:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 UGGrhuDzRsYv; Mon, 29 Sep 2014 07:16:18 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id 750EA1A8755; Mon, 29 Sep 2014 07:15:22 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 3ADAFC141; Mon, 29 Sep 2014 10:15:22 -0400 (EDT) Date: Mon, 29 Sep 2014 10:15:22 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140929141522.GA7854@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <02d301cfd9a6$0f331c00$2d995400$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/j0YgNNfLlWcZZ7EIC-9GDoN-7Eg Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:16:19 -0000 [Note that I'm responding to things in thread-order. I2RS was very busy for a few days while I had to pay attention to other things, so my responses may appear to jump around a bit.] Sue, On Fri, Sep 26, 2014 at 12:22:25PM -0400, Susan Hares wrote: > > Just to confirm three facts before I put them in i2rs drafts (based on > Juergen's email > > - based on Juergen's email: I2RS is "config true empheral". This is a point of discussion. A critical thing to realize from the netmod interim is that it was simply a first step to trying to define what "ephemeral" even *means* in the context of existing yang and netconf/restconf. The "option 4" solution was the proposal that worked its way through discussion points with the yang experts, but still needs discussion within I2RS and then related followup with netconf if we decide it's the way to go. I like the idea, but as discussion is pointing out, there's a lot of details to reconcile. The impact of this upon writing data models for I2RS would appear to be at this point: - They're just "config true" (per correction from Juergen), but simply done in the ephemeral datastore. How you document that they're just in the ephemeral data store is unclear at this point. - They're otherwise just normal models. - But if they're intended to be i2rs ephemeral extensions on local config models (e.g. protocol WG data models), we have some dependency work to reconcile with those groups. > If i2rs has additional configuration for BGP related to your I2RS peers for > reporting routes: > > > > . BGP based config + I2RS additional config + AS Config > > > > Can I2RS have additional configuration values specific to I2RS? For > example, information regarding how often to report the routes for a > particular pear? Correct. We have roughly four scenarios with regard to modeling impact: A. Completely disjoint models for I2RS that use no state from other protocol modules and no dependencies, but interact with underlying state of that protocol. E.g. BGP configuration in an I2RS model that doesn't extend a IDR Yang module nor have constraints in such a module. B. A disjoint model for I2RS that has constraints against other modules. E.g. the I2RS BGP module may have a "must" statement against a IDR yang module's "autonomous system" configuration. C. A hybrid I2RS module that augments an underlying protocol module. This is the scenario you're suggesting above. The critical detail is since it's an augmentation it is suggesting there exists such a protocol module. D. There is a unified module developed in some working group that may simply choose to store some of its state in an ephemeral fashion. D is the newest option enabled by the "option 4" discussion from the netmod interim. -- Jeff From nobody Mon Sep 29 07:16:53 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3B6E1A1A9E; Mon, 29 Sep 2014 07:16:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.354 X-Spam-Level: X-Spam-Status: No, score=-2.354 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, IP_NOT_FRIENDLY=0.334, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 D9moIv-gjJNC; Mon, 29 Sep 2014 07:16:44 -0700 (PDT) Received: from slice.pfrc.org (slice.pfrc.org [67.207.130.108]) by ietfa.amsl.com (Postfix) with ESMTP id ABD251A1AE2; Mon, 29 Sep 2014 07:16:36 -0700 (PDT) Received: by slice.pfrc.org (Postfix, from userid 1001) id 70A88C141; Mon, 29 Sep 2014 10:16:36 -0400 (EDT) Date: Mon, 29 Sep 2014 10:16:36 -0400 From: Jeffrey Haas To: Susan Hares Message-ID: <20140929141636.GB7854@pfrc> References: <20140922210546.GA5676@pfrc> <01ee01cfd77b$b6fc48d0$24f4da70$@ndzh.com> <20140924154352.GE2639@pfrc> <032401cfd9ac$da30b060$8e921120$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <032401cfd9ac$da30b060$8e921120$@ndzh.com> User-Agent: Mutt/1.5.21 (2010-09-15) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/GQLPoG1tZLmExKzke72rmO4to2o Cc: i2rs@ietf.org, netmod@ietf.org Subject: Re: [netmod] [i2rs] Summary of discussion from netmod interim on i2rs requirements on netmod/netconf X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 14:16:50 -0000 Sue, On Fri, Sep 26, 2014 at 01:11:02PM -0400, Susan Hares wrote: > Jeff: > > Could you give me an example of the interim's thoughts on commit versus > Alexander's message: > > http://www.ietf.org/mail-archive/web/i2rs/current/msg01974.html I'll address this point in the original thread. -- Jeff From nobody Tue Sep 30 08:06:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21A8F1A1A5A for ; Tue, 30 Sep 2014 08:06:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 gi8I3QE_ewtj for ; Tue, 30 Sep 2014 08:06:01 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0112.outbound.protection.outlook.com [207.46.100.112]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 20F4B1A1A33 for ; Tue, 30 Sep 2014 08:06:01 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB423.namprd05.prod.outlook.com (10.141.58.146) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 15:05:56 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 15:05:56 +0000 From: Dean Bogdanovic To: "netmod@ietf.org" Thread-Topic: Comparing address families in must statement Thread-Index: AQHP3MAJZOrB82EFq0mSjqmbW7sf5g== Date: Tue, 30 Sep 2014 15:05:56 +0000 Message-ID: <167EE31C-1B19-42AD-9215-A140D23599F9@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB423; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(199003)(80022003)(83716003)(86362001)(85852003)(2656002)(87936001)(66066001)(92726001)(36756003)(106116001)(50226001)(105586002)(95666004)(10300001)(2501002)(31966008)(46102003)(76482002)(106356001)(92566001)(4396001)(97736003)(77156001)(57306001)(82746002)(99396003)(88136002)(107046002)(99286002)(120916001)(87286001)(89996001)(20776003)(107886001)(50986999)(110136001)(21056001)(77096002)(2351001)(33656002)(64706001)(85306004)(62966002)(104166001)(101416001)(229853001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB423; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-ID: <620EF1AB88B4944491E5DE896F60F32A@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/efbLbbv_UeK8-qHPsOamD2Tg4r0 Subject: [netmod] Comparing address families in must statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:06:03 -0000 Hi, I'm trying to figure out a must statement, where entries have to be in the = same address family. Here is the example below import ietf-inet-types { prefix "types"; =20 } =20 import ietf-acl { prefix "ietf-acl"; } augment "/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:matc= hes" { choice route-prefix{ description "Define route filter match criteria"; case range { container range { leaf lower_bound { type types:ip-prefix; mandatory true; } leaf upper_bound { type types:ip-prefix; must "if lower_bound address family current() !=3D upper_bound addre= ss family" error-message "The upper_bound value has to be the same address fami= ly as lower_bound" mandatory true; } } } } Trying to find out if there is ability to extract the pattern constraints f= rom a type and then apply it. Or something like type.pattern() so something= like ip:ip-prefix.pattern(current()) thx Dean From nobody Tue Sep 30 08:28:06 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB5961A1A6A for ; Tue, 30 Sep 2014 08:28:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 YqYJleoDJ1r6 for ; Tue, 30 Sep 2014 08:28:01 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65C651A1A3B for ; Tue, 30 Sep 2014 08:27:53 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id 6FAD313F742; Tue, 30 Sep 2014 17:27:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1412090871; bh=OVqCj+GRAyIrwfTaUpve9/ko+7D45HNIuTN+p9hxYbM=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=O/v1mv6pTnSljQGkuNFX7kNs7Ep3B7YIX8yWhzY5AWFhzqY0rX3cfv+wH9R5a0smn x/KRCPyiWsPZz0o2gp/0/01usXn9SnwBv5doBGGS34j56vPo6kFbeE2D9ZB0MDM0kL FoXqXENunUCLBRu4qLFLHVqkEzT300jRYKT9Zrrs= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <167EE31C-1B19-42AD-9215-A140D23599F9@juniper.net> Date: Tue, 30 Sep 2014 17:27:50 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <6152915A-4E26-4238-B657-5BAD732AFB20@nic.cz> References: <167EE31C-1B19-42AD-9215-A140D23599F9@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/C4Tc6v438YBFCWmdCiknf1hu8i0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Comparing address families in must statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 15:28:02 -0000 Hi Dean, On 30 Sep 2014, at 17:05, Dean Bogdanovic wrote: > Hi, >=20 > I'm trying to figure out a must statement, where entries have to be in = the same address family. Here is the example below Such a constraint is used in the ietf-routing module, see the definition = of =93default-rib=94. I am not sure though that this is what you want. >=20 > import ietf-inet-types { > prefix "types"; =20 > } >=20 > import ietf-acl { > prefix "ietf-acl"; > } >=20 > augment = "/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:matches" { > choice route-prefix{ > description "Define route filter match criteria"; > case range { > container range { > leaf lower_bound { > type types:ip-prefix; > mandatory true; > } > leaf upper_bound { > type types:ip-prefix; > must "if lower_bound address family current() !=3D = upper_bound address family" > error-message "The upper_bound value has to be the same = address family as lower_bound" > mandatory true; > } > } > } > } >=20 > Trying to find out if there is ability to extract the pattern = constraints from a type and then apply it. Or something like = type.pattern() so something like ip:ip-prefix.pattern(current()) One of the XPath extension functions proposed for YANG 1.1 is re-match, = see the expired draft = http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00= #section-4.5 I am not sure why you need to extract type patterns and apply them in = XPath expressions but this in not possible in YANG 1.0 and won=92t be in = 1.1 either. Lada >=20 > thx >=20 > Dean >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Tue Sep 30 09:06:49 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BE6A1A1A64 for ; Tue, 30 Sep 2014 09:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.287 X-Spam-Level: X-Spam-Status: No, score=-15.287 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.786, 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 Yjw8cFdFlFGR for ; Tue, 30 Sep 2014 09:06:29 -0700 (PDT) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BD671A1A67 for ; Tue, 30 Sep 2014 09:06:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2404; q=dns/txt; s=iport; t=1412093189; x=1413302789; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=zkl/K/P7MZm2wBkFJARif6hx/LhW2GZMnqPSi80of3o=; b=E6PldODXQu+KFxmYqVQEB39RSOuiTV/lGrUXp+bM/tXU0RSYNaTC/Rn/ 252ehjtx1Auv2C32aP7KMGFZ31nMem5XVZiqScCzMBQ6Z4Jb6Pxy+86CR TSdLFy3F18IsTaO7w7zneDj+niTCSRNZ1bemRCBKBNwyCnGMlwfQo6HCe s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiEFAMLTKlStJA2B/2dsb2JhbABggw6BKgTRcQKBChYBe4QDAQEBBDo/DAQCAQgRBAEBCxQJBzIUCQgCBAENBQiINr8eARePMTwxBwaDKIEdAQSRaoZ6mjuDY2yBSIECAQEB X-IronPort-AV: E=Sophos;i="5.04,627,1406592000"; d="scan'208";a="82770528" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-2.cisco.com with ESMTP; 30 Sep 2014 16:06:28 +0000 Received: from xhc-rcd-x05.cisco.com (xhc-rcd-x05.cisco.com [173.37.183.79]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id s8UG6S1B016665 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 16:06:28 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x05.cisco.com ([173.37.183.79]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 11:06:28 -0500 From: "Eric Voit (evoit)" To: "Thomas D. Nadeau" , NETMOD Working Group Thread-Topic: [netmod] NETMOD Interim Meeting Format Update Thread-Index: AQHP2MwOBw86cq58vkCO9taX9m1WiJwZ2aIw Date: Tue, 30 Sep 2014 16:06:28 +0000 Message-ID: References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> In-Reply-To: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/kj_GDDxN2bvfl9EouNC_FDtxXj8 Cc: "netmod-chairs@tools.ietf.org" , "netmod-ads@tools.ietf.org" Subject: Re: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:06:38 -0000 I would like to talk about draft-voit-netmod-peer-mount-requirements at an upcoming (next Wednesday's?) meeting. Can you put it on the agenda? Alex is also aiming to have "-02" of draft-clemm-netmod-mount available Friday. It would be good to talk about that as well. Thanks, Eric > -----Original Message----- > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. > Nadeau > Sent: Thursday, September 25, 2014 10:21 AM > To: NETMOD Working Group > Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org > Subject: [netmod] NETMOD Interim Meeting Format Update >=20 >=20 > Netmod WG: >=20 > Juergen, Benoit and I have discussed a plan by which we will divide up > the interim meetings into two categories. Going forward, we will alternat= e > meetings each week to focus on either a) Yang Model production or b) Yang= 1.1 > updates/issue discussion/resolution. Starting with the next scheduled me= eting > two weeks on Wednesday, October 8, 2012, we will begin this cadence with = a) > and then b), and as such will be working on Yang Model production at that > meeting. The following meeting will focus on b) and so on. >=20 > Ahead of each Yang Modeling meeting I would like to ask that those > wishing to propose models for discussion do so as early as possible so th= at an > agenda can be assembled ahead of time. Please either post proposals to th= e > NETMOD list or to me directly and I will keep track of proposals in the i= ssue > tracker. Also, in order to address feedback we have received after the la= st > official IETF meeting that the agenda slots are too tight to facilitate > significant/detailed discussion of models, the meeting format will be fai= rly loose > to allow for extensive discussion/hacking of models. Given this change i= t is > possible that if significant discussion and progress is made on a single = model, > that only that single model will be discussed during an entire meeting. I= t is > possible too that if that discussion is not concluded, that it spills ove= r into the > next meeting two weeks later. >=20 > Meeting minutes/notes will be kept in the same format and posted as > are done for the current meetings. >=20 > If anyone has suggestions/questions regarding the meeting format > updates, please discuss here. >=20 > Cheers, >=20 > --Tom >=20 >=20 From nobody Tue Sep 30 09:27:45 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 143CA1A1AD5 for ; Tue, 30 Sep 2014 09:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 UeXxBpRzHIKN for ; Tue, 30 Sep 2014 09:27:41 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 819A61A1A65 for ; Tue, 30 Sep 2014 09:27:40 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id B393528A8E79; Tue, 30 Sep 2014 12:27:38 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_AB6F1621-5BF5-4096-A4EA-24A427031D10"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 30 Sep 2014 09:27:35 -0700 Message-Id: References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> To: Voit Eric X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/5ZVgRjnwYvoc5bviISdk6tZSvrw Cc: "netmod-chairs@tools.ietf.org" , "netmod-ads@tools.ietf.org" , NETMOD Working Group Subject: Re: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:27:43 -0000 --Apple-Mail=_AB6F1621-5BF5-4096-A4EA-24A427031D10 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Cool. We can add you to the agenda for the next meeting. Please = prepare to give a brief introduction/review of the draft and then have = an interactive discussion around it.=20 --Tom On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) = wrote: > I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting. Can you put it on the = agenda? >=20 > Alex is also aiming to have "-02" of draft-clemm-netmod-mount > available Friday. It would be good to talk about that as well. >=20 > Thanks, > Eric >=20 >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. >> Nadeau >> Sent: Thursday, September 25, 2014 10:21 AM >> To: NETMOD Working Group >> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org >> Subject: [netmod] NETMOD Interim Meeting Format Update >>=20 >>=20 >> Netmod WG: >>=20 >> Juergen, Benoit and I have discussed a plan by which we will = divide up >> the interim meetings into two categories. Going forward, we will = alternate >> meetings each week to focus on either a) Yang Model production or b) = Yang 1.1 >> updates/issue discussion/resolution. Starting with the next = scheduled meeting >> two weeks on Wednesday, October 8, 2012, we will begin this cadence = with a) >> and then b), and as such will be working on Yang Model production at = that >> meeting. The following meeting will focus on b) and so on. >>=20 >> Ahead of each Yang Modeling meeting I would like to ask that = those >> wishing to propose models for discussion do so as early as possible = so that an >> agenda can be assembled ahead of time. Please either post proposals = to the >> NETMOD list or to me directly and I will keep track of proposals in = the issue >> tracker. Also, in order to address feedback we have received after = the last >> official IETF meeting that the agenda slots are too tight to = facilitate >> significant/detailed discussion of models, the meeting format will be = fairly loose >> to allow for extensive discussion/hacking of models. Given this = change it is >> possible that if significant discussion and progress is made on a = single model, >> that only that single model will be discussed during an entire = meeting. It is >> possible too that if that discussion is not concluded, that it spills = over into the >> next meeting two weeks later. >>=20 >> Meeting minutes/notes will be kept in the same format and posted = as >> are done for the current meetings. >>=20 >> If anyone has suggestions/questions regarding the meeting format >> updates, please discuss here. >>=20 >> Cheers, >>=20 >> --Tom >>=20 >>=20 >=20 >=20 --Apple-Mail=_AB6F1621-5BF5-4096-A4EA-24A427031D10 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKtn3AAoJEPcO+I7eiUJZuAgP/1oWE+aptC9mB/yt9LDzXOrQ sKnLE0bO37ql1BaxJOExuE9GgGvTrX8v84yxD7o0GWw8cv8OkTRpqUhytO0tKBP0 skDcrvRzUBlt8rg78Xt2dwyFue/XbPwY6kLnR8/mcpPwL+8TTSLemnludTDiP9r4 WvmDHFdosp7Pe0FaDDpBAfc/Vi4QpYafd9xCgayrBu0G6qtLxC7epJ/vH9yQhZF7 ZeQ/xGWhKmQj3or9zQzCku4d06A0Y5CsAEOUzoR0wGTTpIAVytPHZPxQrS4XssgJ A3u16KrBhAlhdLyR3E1oO5VXtwnUTRcHcu8BL+4oltrPxm0sV/KPP7ija046Lh6I yV2BJix9SAOJWYgcxoeM6/mX0wUeWKav3NuzznokQ8spsceHaImVQIv0TRyKiVXO GF1U1Wv9yRYeWBnht8VcL2WOQFRp3fqC5qLZs2SQqNzhnkAW4dm6TDhb8aevNMJx SO8nAiYqnuc5b8z1Y2oc5d0n9hyfd3Wd2J0hTDvJrQt1xcSsUoTVwDgo2HKXej7N gTv8BZPbgeBHyhAXvgqY+5f+TOao7yGsV0widLLFdrnQ3n9BqqRNfxZ5eTQzdrfq a4wumWP6cHBrRu3IN6bbzND6nyPu3WxNBvS4KqkuiGB8e2feUGneXolClNfcZkG1 ety/R+clWCrvOpM7ACR/ =gCXX -----END PGP SIGNATURE----- --Apple-Mail=_AB6F1621-5BF5-4096-A4EA-24A427031D10-- From nobody Tue Sep 30 09:56:04 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68D8B1A1B30 for ; Tue, 30 Sep 2014 09:55:57 -0700 (PDT) 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 nw_XE_h5RGDi for ; Tue, 30 Sep 2014 09:55:53 -0700 (PDT) Received: from mail-vc0-f173.google.com (mail-vc0-f173.google.com [209.85.220.173]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 915C51A1B2E for ; Tue, 30 Sep 2014 09:55:53 -0700 (PDT) Received: by mail-vc0-f173.google.com with SMTP id ij19so2698597vcb.32 for ; Tue, 30 Sep 2014 09:55:52 -0700 (PDT) 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=tJLu6NB5CY8yBjQhr4svdv/h53Vu3tIrdbVpLyvjUhI=; b=BLsWtpwjvy0XUMYuuDBrGQMcPO1Bv2goUylgGLoKm8LJ30h3nWyCsrfmiTst4cHpll C8YPgNqrKbE8tog4nrWfREX7VpJuzSWIn1GR3Wy72Tqe1wwBFB+MkpyC9oH0OpY3QpAm tI8zbT/akh1r8PHP3T0YEL9U2n5i1+KltgWL/bPSeK7V0VqU0wBl7gLbIykcETzFSg3o guapFoWKkJ8/bNqMQxMNyHrFGsuyuSPuw1iBwMBkv0TuSjaJJu9FUsAHwtIzZJK9pKJ6 wBHWUnZlLNhYKoHS7VkgRe0gH8IHigVEYFlXwCeicj83tdzR1B7EzyfFBM7iQvnOCTCT VvlQ== X-Gm-Message-State: ALoCoQmV+iIROwyevBqboarl5af9wio4yEKKPJlu1LXgI/TC4RxJ2zXRJD3ivpKcznOxLsCPEz/o MIME-Version: 1.0 X-Received: by 10.52.61.99 with SMTP id o3mr10282052vdr.46.1412096152721; Tue, 30 Sep 2014 09:55:52 -0700 (PDT) Received: by 10.31.168.200 with HTTP; Tue, 30 Sep 2014 09:55:52 -0700 (PDT) In-Reply-To: References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> Date: Tue, 30 Sep 2014 09:55:52 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a113403d0926ffb05044b4129 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/iyZj-WfDNSXys58vkfXpfLusPqQ Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group , "netmod-ads@tools.ietf.org" Subject: Re: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 16:55:57 -0000 --001a113403d0926ffb05044b4129 Content-Type: text/plain; charset=ISO-8859-1 Hi, I would like to finish the current chartered items, instead of starting new work. IMO new unchartered work can be discussed on the mailing list. Andy On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau wrote: > > Cool. We can add you to the agenda for the next meeting. Please > prepare to give a brief introduction/review of the draft and then have an > interactive discussion around it. > > --Tom > > > On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) > wrote: > > > I would like to talk about draft-voit-netmod-peer-mount-requirements > > at an upcoming (next Wednesday's?) meeting. Can you put it on the > agenda? > > > > Alex is also aiming to have "-02" of draft-clemm-netmod-mount > > available Friday. It would be good to talk about that as well. > > > > Thanks, > > Eric > > > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. > >> Nadeau > >> Sent: Thursday, September 25, 2014 10:21 AM > >> To: NETMOD Working Group > >> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org > >> Subject: [netmod] NETMOD Interim Meeting Format Update > >> > >> > >> Netmod WG: > >> > >> Juergen, Benoit and I have discussed a plan by which we will > divide up > >> the interim meetings into two categories. Going forward, we will > alternate > >> meetings each week to focus on either a) Yang Model production or b) > Yang 1.1 > >> updates/issue discussion/resolution. Starting with the next scheduled > meeting > >> two weeks on Wednesday, October 8, 2012, we will begin this cadence > with a) > >> and then b), and as such will be working on Yang Model production at > that > >> meeting. The following meeting will focus on b) and so on. > >> > >> Ahead of each Yang Modeling meeting I would like to ask that those > >> wishing to propose models for discussion do so as early as possible so > that an > >> agenda can be assembled ahead of time. Please either post proposals to > the > >> NETMOD list or to me directly and I will keep track of proposals in the > issue > >> tracker. Also, in order to address feedback we have received after the > last > >> official IETF meeting that the agenda slots are too tight to facilitate > >> significant/detailed discussion of models, the meeting format will be > fairly loose > >> to allow for extensive discussion/hacking of models. Given this change > it is > >> possible that if significant discussion and progress is made on a > single model, > >> that only that single model will be discussed during an entire meeting. > It is > >> possible too that if that discussion is not concluded, that it spills > over into the > >> next meeting two weeks later. > >> > >> Meeting minutes/notes will be kept in the same format and posted as > >> are done for the current meetings. > >> > >> If anyone has suggestions/questions regarding the meeting format > >> updates, please discuss here. > >> > >> Cheers, > >> > >> --Tom > >> > >> > > > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a113403d0926ffb05044b4129 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,

I would like to finish the current = chartered items, instead of starting new work.
IMO new unchartere= d work can be discussed on the mailing list.


<= /div>
Andy


On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau <tnade= au@lucidvision.com> wrote:
=
=A0 =A0 =A0 =A0 Cool. We can add you to the agenda for the next meeting.=A0= Please prepare to give a brief introduction/review of the draft and then h= ave an interactive discussion around it.

=A0 =A0 =A0 =A0 --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting.=A0 =A0Can you put it o= n the agenda?
>
> Alex is also aiming to have "-02" of=A0 draft-clemm-netmod-m= ount
> available Friday.=A0 It would be good to talk about that as well.
>
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:ne= tmod-bounces@ietf.org] On Behalf Of Thomas D.
>> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@= tools.ietf.org; netmod-ads= @tools.ietf.org
>> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>=A0 =A0 =A0 Netmod WG:
>>
>>=A0 =A0 =A0 Juergen, Benoit and I have discussed a plan by which we= will divide up
>> the interim meetings into two categories. Going forward, we will a= lternate
>> meetings each week to focus on either a) Yang Model production or = b) Yang 1.1
>> updates/issue discussion/resolution.=A0 Starting with the next sch= eduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this cadenc= e with a)
>> and then b), and as such will be working on Yang Model production = at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>=A0 =A0 =A0 Ahead of each Yang Modeling meeting I would like to ask= that those
>> wishing to propose models for discussion do so as early as possibl= e so that an
>> agenda can be assembled ahead of time. Please either post proposal= s to the
>> NETMOD list or to me directly and I will keep track of proposals i= n the issue
>> tracker. Also, in order to address feedback we have received after= the last
>> official IETF meeting that the agenda slots are too tight to facil= itate
>> significant/detailed discussion of models, the meeting format will= be fairly loose
>> to allow for extensive discussion/hacking of models.=A0 Given this= change it is
>> possible that if significant discussion and progress is made on a = single model,
>> that only that single model will be discussed during an entire mee= ting. It is
>> possible too that if that discussion is not concluded, that it spi= lls over into the
>> next meeting two weeks later.
>>
>>=A0 =A0 =A0 Meeting minutes/notes will be kept in the same format a= nd posted as
>> are done for the current meetings.
>>
>>=A0 =A0 =A0 If anyone has suggestions/questions regarding the meeti= ng format
>> updates, please discuss here.
>>
>>=A0 =A0 =A0 Cheers,
>>
>>=A0 =A0 =A0 --Tom
>>
>>
>
>


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


--001a113403d0926ffb05044b4129-- From nobody Tue Sep 30 10:06:05 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E94281A1B23 for ; Tue, 30 Sep 2014 10:06:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -15.286 X-Spam-Level: X-Spam-Status: No, score=-15.286 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.786, 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 bTn95Vsvagz7 for ; Tue, 30 Sep 2014 10:06:00 -0700 (PDT) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 303FF1A1B51 for ; Tue, 30 Sep 2014 10:06:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12857; q=dns/txt; s=iport; t=1412096761; x=1413306361; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=uqgMWIg2w+C8y9ykGpyJf7AG0JDj3srvy3x8IA+b7ds=; b=ENL9mKp75Ntkm1udWTXfgaPRwjlne5fME06rNVj/yWxEsFbHdUOAgmou YD3v5T5By/8FE4BNWTN/iCvIX8tbYTFtigBoVZpI4SandIqidbRJ47wYw 4WKRFhJZVECVfqkHKgMTr2lmHGZ88vXj63DqZD0BUVi6g9uoD4gNNu5Ec w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjEFAFXiKlStJA2E/2dsb2JhbABggkhGU1cEyhoBCYZ5VAKBChYBe4QDAQEBAwEBAQEqQQsFBwQCAQgRBAEBCx0HJwsUCQgCBAENBQiILggNvngBEwSPMTwtBAYBBoMogR0FkWqGepo7g2NsgUiBAgEBAQ X-IronPort-AV: E=Sophos;i="5.04,627,1406592000"; d="scan'208,217";a="359542597" Received: from alln-core-10.cisco.com ([173.36.13.132]) by rcdn-iport-5.cisco.com with ESMTP; 30 Sep 2014 17:06:00 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by alln-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id s8UH5xIJ029358 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 30 Sep 2014 17:05:59 GMT Received: from xmb-aln-x11.cisco.com ([169.254.6.41]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0195.001; Tue, 30 Sep 2014 12:05:58 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , "Thomas D. Nadeau" Thread-Topic: [netmod] NETMOD Interim Meeting Format Update Thread-Index: AQHP2MwOBw86cq58vkCO9taX9m1WiJwZ2aIwgABfeYCAAAfnAP//rKug Date: Tue, 30 Sep 2014 17:05:57 +0000 Message-ID: References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.116.134.135] Content-Type: multipart/alternative; boundary="_000_EF64FF31F4C4384DBCE5D513A791C2B120A3CC4Axmbalnx11ciscoc_" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/LK5bCxPB1YzbVQJ5veabH1C30CM Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group , "netmod-ads@tools.ietf.org" Subject: Re: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:06:03 -0000 --_000_EF64FF31F4C4384DBCE5D513A791C2B120A3CC4Axmbalnx11ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andy, The two drafts we are hoping to present are currently being discussed in I2= RS (potential "Mount" use for Ephemeral data) and SUPA (for Uses Cases and = potential Charter impact). Based on this I believe there is value in jump-starting discussions in this= WG. Sometimes it is hard to get the full context via a dry-read of the dr= aft. Eric From: Andy Bierman, September 30, 2014 12:56 PM Hi, I would like to finish the current chartered items, instead of starting new= work. IMO new unchartered work can be discussed on the mailing list. Andy On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau > wrote: Cool. We can add you to the agenda for the next meeting. Please pr= epare to give a brief introduction/review of the draft and then have an int= eractive discussion around it. --Tom On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) > wrote: > I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting. Can you put it on the agend= a? > > Alex is also aiming to have "-02" of draft-clemm-netmod-mount > available Friday. It would be good to talk about that as well. > > Thanks, > Eric > >> -----Original Message----- >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas D. >> Nadeau >> Sent: Thursday, September 25, 2014 10:21 AM >> To: NETMOD Working Group >> Cc: netmod-chairs@tools.ietf.org; n= etmod-ads@tools.ietf.org >> Subject: [netmod] NETMOD Interim Meeting Format Update >> >> >> Netmod WG: >> >> Juergen, Benoit and I have discussed a plan by which we will divide= up >> the interim meetings into two categories. Going forward, we will alterna= te >> meetings each week to focus on either a) Yang Model production or b) Yan= g 1.1 >> updates/issue discussion/resolution. Starting with the next scheduled m= eeting >> two weeks on Wednesday, October 8, 2012, we will begin this cadence with= a) >> and then b), and as such will be working on Yang Model production at tha= t >> meeting. The following meeting will focus on b) and so on. >> >> Ahead of each Yang Modeling meeting I would like to ask that those >> wishing to propose models for discussion do so as early as possible so t= hat an >> agenda can be assembled ahead of time. Please either post proposals to t= he >> NETMOD list or to me directly and I will keep track of proposals in the = issue >> tracker. Also, in order to address feedback we have received after the l= ast >> official IETF meeting that the agenda slots are too tight to facilitate >> significant/detailed discussion of models, the meeting format will be fa= irly loose >> to allow for extensive discussion/hacking of models. Given this change = it is >> possible that if significant discussion and progress is made on a single= model, >> that only that single model will be discussed during an entire meeting. = It is >> possible too that if that discussion is not concluded, that it spills ov= er into the >> next meeting two weeks later. >> >> Meeting minutes/notes will be kept in the same format and posted as >> are done for the current meetings. >> >> If anyone has suggestions/questions regarding the meeting format >> updates, please discuss here. >> >> Cheers, >> >> --Tom >> >> > > _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod --_000_EF64FF31F4C4384DBCE5D513A791C2B120A3CC4Axmbalnx11ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Andy,

 <= /p>

The two drafts we are hop= ing to present are currently being discussed in I2RS (potential “Moun= t” use for Ephemeral data) and SUPA (for Uses Cases and potential Charter impact).

 <= /p>

Based on this I believe t= here is value in jump-starting discussions in this WG.  Sometimes it i= s hard to get the full context via a dry-read of the draft. 

 <= /p>

Eric

 <= /p>

From: Andy Bie= rman, September 30, 2014 12:56 PM

Hi,

 

I would like to finish the current chartered items, = instead of starting new work.

IMO new unchartered work can be discussed on the mai= ling list.

 

 

Andy

 

 

On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau &l= t;tnadeau@luci= dvision.com> wrote:


        Cool. We can add you to the agenda for the next= meeting.  Please prepare to give a brief introduction/review of the d= raft and then have an interactive discussion around it.

        --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> I would like to talk about draft-voit-netmod-peer-mount-requirements > at an upcoming (next Wednesday's?) meeting.   Can you put it= on the agenda?
>
> Alex is also aiming to have "-02" of  draft-clemm-netmo= d-mount
> available Friday.  It would be good to talk about that as well. >
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:ne= tmod-bounces@ietf.org] On Behalf Of Thomas D.
>> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@= tools.ietf.org; netmod-ads@tools.ietf.org<= br> >> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>      Netmod WG:
>>
>>      Juergen, Benoit and I have discussed a plan by= which we will divide up
>> the interim meetings into two categories. Going forward, we will a= lternate
>> meetings each week to focus on either a) Yang Model production or = b) Yang 1.1
>> updates/issue discussion/resolution.  Starting with the next = scheduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this cadenc= e with a)
>> and then b), and as such will be working on Yang Model production = at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>      Ahead of each Yang Modeling meeting I would li= ke to ask that those
>> wishing to propose models for discussion do so as early as possibl= e so that an
>> agenda can be assembled ahead of time. Please either post proposal= s to the
>> NETMOD list or to me directly and I will keep track of proposals i= n the issue
>> tracker. Also, in order to address feedback we have received after= the last
>> official IETF meeting that the agenda slots are too tight to facil= itate
>> significant/detailed discussion of models, the meeting format will= be fairly loose
>> to allow for extensive discussion/hacking of models.  Given t= his change it is
>> possible that if significant discussion and progress is made on a = single model,
>> that only that single model will be discussed during an entire mee= ting. It is
>> possible too that if that discussion is not concluded, that it spi= lls over into the
>> next meeting two weeks later.
>>
>>      Meeting minutes/notes will be kept in the same= format and posted as
>> are done for the current meetings.
>>
>>      If anyone has suggestions/questions regarding = the meeting format
>> updates, please discuss here.
>>
>>      Cheers,
>>
>>      --Tom
>>
>>
>
>


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

 

--_000_EF64FF31F4C4384DBCE5D513A791C2B120A3CC4Axmbalnx11ciscoc_-- From nobody Tue Sep 30 10:15:59 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12C101A1B6E for ; Tue, 30 Sep 2014 10:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.687 X-Spam-Level: X-Spam-Status: No, score=-2.687 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 idp29MZOF-NW for ; Tue, 30 Sep 2014 10:15:50 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 1104D1A1B6F for ; Tue, 30 Sep 2014 10:15:50 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id 3CFE328A8FE8; Tue, 30 Sep 2014 13:15:47 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_5E5B4182-4D80-4C91-8714-8A1BE5CE5A25"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 30 Sep 2014 10:15:44 -0700 Message-Id: <8ECCF40D-132A-4662-B983-3D5B94211AD4@lucidvision.com> References: <79C50B72-6505-4A01-A3FE-6A5FEBD71750@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4aq6cQYHkzZtunoWBQDYcGdOMBM Cc: "netmod-chairs@tools.ietf.org" , NETMOD Working Group , "netmod-ads@tools.ietf.org" Subject: Re: [netmod] NETMOD Interim Meeting Format Update X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 17:15:57 -0000 --Apple-Mail=_5E5B4182-4D80-4C91-8714-8A1BE5CE5A25 Content-Type: multipart/alternative; boundary="Apple-Mail=_857E15C0-CB86-4FAE-B2A6-26D1F5CCAC79" --Apple-Mail=_857E15C0-CB86-4FAE-B2A6-26D1F5CCAC79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 This is the interim meeting. This was the only request for = discussion post my announcement of the meeting, so its going on the = agenda. *) --Tom On Sep 30, 2014:9:55 AM, at 9:55 AM, Andy Bierman = wrote: > Hi, >=20 > I would like to finish the current chartered items, instead of = starting new work. > IMO new unchartered work can be discussed on the mailing list. >=20 >=20 > Andy >=20 >=20 > On Tue, Sep 30, 2014 at 9:27 AM, Thomas D. Nadeau = wrote: >=20 > Cool. We can add you to the agenda for the next meeting. = Please prepare to give a brief introduction/review of the draft and then = have an interactive discussion around it. >=20 > --Tom >=20 >=20 > On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) = wrote: >=20 > > I would like to talk about draft-voit-netmod-peer-mount-requirements > > at an upcoming (next Wednesday's?) meeting. Can you put it on the = agenda? > > > > Alex is also aiming to have "-02" of draft-clemm-netmod-mount > > available Friday. It would be good to talk about that as well. > > > > Thanks, > > Eric > > > >> -----Original Message----- > >> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Thomas = D. > >> Nadeau > >> Sent: Thursday, September 25, 2014 10:21 AM > >> To: NETMOD Working Group > >> Cc: netmod-chairs@tools.ietf.org; netmod-ads@tools.ietf.org > >> Subject: [netmod] NETMOD Interim Meeting Format Update > >> > >> > >> Netmod WG: > >> > >> Juergen, Benoit and I have discussed a plan by which we will = divide up > >> the interim meetings into two categories. Going forward, we will = alternate > >> meetings each week to focus on either a) Yang Model production or = b) Yang 1.1 > >> updates/issue discussion/resolution. Starting with the next = scheduled meeting > >> two weeks on Wednesday, October 8, 2012, we will begin this cadence = with a) > >> and then b), and as such will be working on Yang Model production = at that > >> meeting. The following meeting will focus on b) and so on. > >> > >> Ahead of each Yang Modeling meeting I would like to ask that = those > >> wishing to propose models for discussion do so as early as possible = so that an > >> agenda can be assembled ahead of time. Please either post proposals = to the > >> NETMOD list or to me directly and I will keep track of proposals in = the issue > >> tracker. Also, in order to address feedback we have received after = the last > >> official IETF meeting that the agenda slots are too tight to = facilitate > >> significant/detailed discussion of models, the meeting format will = be fairly loose > >> to allow for extensive discussion/hacking of models. Given this = change it is > >> possible that if significant discussion and progress is made on a = single model, > >> that only that single model will be discussed during an entire = meeting. It is > >> possible too that if that discussion is not concluded, that it = spills over into the > >> next meeting two weeks later. > >> > >> Meeting minutes/notes will be kept in the same format and = posted as > >> are done for the current meetings. > >> > >> If anyone has suggestions/questions regarding the meeting = format > >> updates, please discuss here. > >> > >> Cheers, > >> > >> --Tom > >> > >> > > > > >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_857E15C0-CB86-4FAE-B2A6-26D1F5CCAC79 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1

This is the interim meeting. =   This was the only request for discussion post my announcement of = the meeting, so its going on the agenda. *)

= --Tom

On Sep 30, 2014:9:55 AM, at 9:55 = AM, Andy Bierman <andy@yumaworks.com> = wrote:

Hi,

I would like to = finish the current chartered items, instead of starting new = work.
IMO new unchartered work can be discussed on the mailing = list.


Andy


On Tue, Sep 30, = 2014 at 9:27 AM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:

        Cool. We can add you to the agenda for the = next meeting.  Please prepare to give a brief introduction/review = of the draft and then have an interactive discussion around it.

        --Tom


On Sep 30, 2014:9:06 AM, at 9:06 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:

> I would like to talk about = draft-voit-netmod-peer-mount-requirements
> at an upcoming (next Wednesday's?) meeting.   Can you put = it on the agenda?
>
> Alex is also aiming to have "-02" of  = draft-clemm-netmod-mount
> available Friday.  It would be good to talk about that as = well.
>
> Thanks,
> Eric
>
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On = Behalf Of Thomas D.
>> Nadeau
>> Sent: Thursday, September 25, 2014 10:21 AM
>> To: NETMOD Working Group
>> Cc: netmod-chairs@tools.ietf.org<= /a>; netmod-ads@tools.ietf.org >> Subject: [netmod] NETMOD Interim Meeting Format Update
>>
>>
>>      Netmod WG:
>>
>>      Juergen, Benoit and I have discussed a plan = by which we will divide up
>> the interim meetings into two categories. Going forward, we = will alternate
>> meetings each week to focus on either a) Yang Model production = or b) Yang 1.1
>> updates/issue discussion/resolution.  Starting with the = next scheduled meeting
>> two weeks on Wednesday, October 8, 2012, we will begin this = cadence with a)
>> and then b), and as such will be working on Yang Model = production at that
>> meeting. The following meeting will focus on b) and so on.
>>
>>      Ahead of each Yang Modeling meeting I would = like to ask that those
>> wishing to propose models for discussion do so as early as = possible so that an
>> agenda can be assembled ahead of time. Please either post = proposals to the
>> NETMOD list or to me directly and I will keep track of = proposals in the issue
>> tracker. Also, in order to address feedback we have received = after the last
>> official IETF meeting that the agenda slots are too tight to = facilitate
>> significant/detailed discussion of models, the meeting format = will be fairly loose
>> to allow for extensive discussion/hacking of models.  = Given this change it is
>> possible that if significant discussion and progress is made on = a single model,
>> that only that single model will be discussed during an entire = meeting. It is
>> possible too that if that discussion is not concluded, that it = spills over into the
>> next meeting two weeks later.
>>
>>      Meeting minutes/notes will be kept in the = same format and posted as
>> are done for the current meetings.
>>
>>      If anyone has suggestions/questions = regarding the meeting format
>> updates, please discuss here.
>>
>>      Cheers,
>>
>>      --Tom
>>
>>
>
>


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



= --Apple-Mail=_857E15C0-CB86-4FAE-B2A6-26D1F5CCAC79-- --Apple-Mail=_5E5B4182-4D80-4C91-8714-8A1BE5CE5A25 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKuVBAAoJEPcO+I7eiUJZzHMP/1bQazsTDis9OdF3kPEZihHw liCu4COV5UELwDm7QkwqUXcMthLfBwUga6O1aKmoK3lExGaZw13yszWRW5llMqur taYCGHmqG3TbBarFZHE7FZD6PsBKeDdgP18+zWMlflNrJ7BUw3mzdG6qqW8PpoJE CiJvr5ZKKuZIl+8Socz6d8JoDQQgmFfnvkyeRcxQdZI0OHuRaltnafED09H3OobF XAbj9UMjdcCv+jqaXNyk1mdZvKONawLrcnqCqH0icxlvzpfdVpR/2BbVBdfVioT0 q0JYrwciR8XiW3peMj4YYhUZC1pieUr8ob+DoVt+VQ0H5ZBubNHJSSXf75Z99Edj 8nzdgwMkRQhez0kVnrOxx3eAZD2jvFybpe+X9uDlHUwYcyJjIPQDopDUwaswqiL3 sJpupjj6U5752W32Nyq++K/FIQiQ+FFf+EmcDand8KIyxeYYjuBFouY7CZqweBpg gYKB1ZXkbKv3iUjNf/sD6epZ26vE72RB+m1Ffw5wOEzgS4RMexzXe1hVgMzGN2Qx pSB1sj0+8bwtJa5mTaQqAT4dAror040K1IlNWlHaxqlidiHbTYUD4aTaKMCQCdSz lYapJyoTU8QALOfU4keCrVLvjgSYSmsELD8Ex6s2slNLzf/ESsYyAmsO0VScWHmQ lQst1XYT3CQxzlFAimCV =EV8D -----END PGP SIGNATURE----- --Apple-Mail=_5E5B4182-4D80-4C91-8714-8A1BE5CE5A25-- From nobody Tue Sep 30 11:48:00 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0566B1A877E for ; Tue, 30 Sep 2014 11:47:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 gIy8E3cQ8Mbp for ; Tue, 30 Sep 2014 11:47:56 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0130.outbound.protection.outlook.com [65.55.169.130]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBE321A877C for ; Tue, 30 Sep 2014 11:47:55 -0700 (PDT) Received: from BN1PR05MB424.namprd05.prod.outlook.com (10.141.58.148) by BN1PR05MB422.namprd05.prod.outlook.com (10.141.58.142) with Microsoft SMTP Server (TLS) id 15.0.1039.15; Tue, 30 Sep 2014 18:47:53 +0000 Received: from BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) by BN1PR05MB424.namprd05.prod.outlook.com ([169.254.8.206]) with mapi id 15.00.1039.011; Tue, 30 Sep 2014 18:47:52 +0000 From: Dean Bogdanovic To: Ladislav Lhotka Thread-Topic: [netmod] Comparing address families in must statement Thread-Index: AQHP3MAJZOrB82EFq0mSjqmbW7sf5pwZzLAAgAA34oA= Date: Tue, 30 Sep 2014 18:47:52 +0000 Message-ID: <150D2166-A756-4F15-BA01-3E9B578E338D@juniper.net> References: <167EE31C-1B19-42AD-9215-A140D23599F9@juniper.net> <6152915A-4E26-4238-B657-5BAD732AFB20@nic.cz> In-Reply-To: <6152915A-4E26-4238-B657-5BAD732AFB20@nic.cz> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.1510) x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.241.13] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:BN1PR05MB422; x-forefront-prvs: 0350D7A55D x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(51704005)(199003)(189002)(377454003)(24454002)(88136002)(97736003)(62966002)(85852003)(46102003)(80022003)(86362001)(93916002)(20776003)(95666004)(77096002)(66066001)(101416001)(82746002)(99286002)(50986999)(92566001)(110136001)(50226001)(89996001)(92726001)(77156001)(85306004)(31966008)(76176999)(83716003)(19580395003)(4396001)(10300001)(2656002)(33656002)(106356001)(76482002)(120916001)(36756003)(15975445006)(106116001)(87286001)(99396003)(19580405001)(575784001)(107046002)(104166001)(21056001)(87936001)(57306001)(105586002)(15202345003)(64706001)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN1PR05MB422; H:BN1PR05MB424.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <16F5272EEE71AB45830339DC9928912C@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/zU-oRZOIEmuhK8eyFDimczxD77w Cc: "netmod@ietf.org" Subject: Re: [netmod] Comparing address families in must statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 18:47:58 -0000 Lada, Thank you for the reply. Re-match function would be nice to have, but as it= is not coming, will model it differently.=20 Dean On Sep 30, 2014, at 11:27 AM, Ladislav Lhotka wrote: > Hi Dean, >=20 > On 30 Sep 2014, at 17:05, Dean Bogdanovic wrote: >=20 >> Hi, >>=20 >> I'm trying to figure out a must statement, where entries have to be in t= he same address family. Here is the example below >=20 > Such a constraint is used in the ietf-routing module, see the definition = of =93default-rib=94. I am not sure though that this is what you want. >=20 >>=20 >> import ietf-inet-types { >> prefix "types"; =20 >> } >>=20 >> import ietf-acl { >> prefix "ietf-acl"; >> } >>=20 >> augment "/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:mat= ches" { >> choice route-prefix{ >> description "Define route filter match criteria"; >> case range { >> container range { >> leaf lower_bound { >> type types:ip-prefix; >> mandatory true; >> } >> leaf upper_bound { >> type types:ip-prefix; >> must "if lower_bound address family current() !=3D upper_bound ad= dress family" >> error-message "The upper_bound value has to be the same address f= amily as lower_bound" >> mandatory true; >> } >> } >> } >> } >>=20 >> Trying to find out if there is ability to extract the pattern constraint= s from a type and then apply it. Or something like type.pattern() so someth= ing like ip:ip-prefix.pattern(current()) >=20 > One of the XPath extension functions proposed for YANG 1.1 is re-match, s= ee the expired draft >=20 > http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-0= 0#section-4.5 >=20 > I am not sure why you need to extract type patterns and apply them in XPa= th expressions but this in not possible in YANG 1.0 and won=92t be in 1.1 e= ither. >=20 > Lada >=20 >>=20 >> thx >>=20 >> Dean >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=20 >=20 >=20 >=20 From nobody Tue Sep 30 13:31:11 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4C7F1A8972; Tue, 30 Sep 2014 13:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 VnB-7DKNrvpA; Tue, 30 Sep 2014 13:31:06 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6CAF41A8895; Tue, 30 Sep 2014 13:31:05 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id ex7so5179959wid.15 for ; Tue, 30 Sep 2014 13:31:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:date:message-id:subject:from:to:cc:content-type; bh=UHpTxlrJIKfc0+YSRGUULAnzVCPsXbhWiUYvB6tauT4=; b=yzy/LT+OkFMGVeLZ+sjUFvt0gUXwW7U2nukclmGmoh6edI4+ioLuHhQQPRI2/goEDR TdFKXLDDb28xcftbWBj6pon2mL3rVQAE781wm0Hi+7KXicScW6TjyrYgDE7e4imn8w4G Y4tKvc4sE+/CVPvZFwaXxYl7/hPzJLWkTuWGH/nelYpRskOKUDFbgBuIbX2wdnUOJUF+ HOu5f7UU3mxpnhIBTQnluXSOvoI43Z6tZcWJz2PWapLhxNImnXUqd4bx8UoCfOtAAcam 7VReRfKRFPa4cBc7ZIaP8oadf4H8uQSD01ahCxii5KJQiUG3xsFEFVayBLoeK+D44cg0 O7Vw== MIME-Version: 1.0 X-Received: by 10.180.187.100 with SMTP id fr4mr8412086wic.83.1412109064018; Tue, 30 Sep 2014 13:31:04 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.139 with HTTP; Tue, 30 Sep 2014 13:31:03 -0700 (PDT) Date: Tue, 30 Sep 2014 16:31:03 -0400 X-Google-Sender-Auth: mDxS1oMMCO7yiuSxPkSHzB06HEw Message-ID: From: "Y. Richard Yang" To: netmod@ietf.org Content-Type: multipart/alternative; boundary=001a11c387f42523c305044e438c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/i84sxqjB60oAF1Wwf-Ei4L9wj0c Cc: IETF ALTO Subject: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:31:08 -0000 --001a11c387f42523c305044e438c Content-Type: text/plain; charset=UTF-8 Hi all, A few of us are doing an exercise of defining a YANG module to express the ALTO protocol (RFC7285). Multiple problems come up and here is one problem we encounter. First, the context. A design decision of the ALTO protocol is to use key-value stores (maps), which are different from lists or containers. Many large-scale systems are designed based on key-value stores, and many programming frameworks provide hash maps. A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): "network-map" : { "PID1" : { "ipv4" : [ "192.0.2.0/24", "198.51.100.0/25" ] }, "PID2" : { "ipv4" : [ "198.51.100.128/25" ] }, "PID3" : { "ipv4" : [ "0.0.0.0/0" ], "ipv6" : [ "::/0" ] } One way to express this in YANG is the following: ===example YANG=== list network-map { key "pid"; leaf pid { type string; } leaf endpoint-address-group ... { // ... } } ================== Following the currently defined json encoding, the output will be: { "network-map" : [ { "pid" : "PID1", // ... }, { "pid" : "PID2", // ... }, { "pid" : "PID3", // ... } ] } But this not what we want, because it is using an array, not a map. One does not have to use an array to store the map. We see two possibilities, if to produce the output. One is in the encoding process: define such outputs on matching a template: list MyList { key x; leaf x { type string; } leaf y { ... } } The second is that maybe this should be resolved in YANG; i.e., introducing a new data type (beyond list, container), but something like key-value store, say named map: map MyMap { key my-key { ... }; value my-value { } } Note that the second mapping involves work if the key type is not a simple type (say string or numbers). A typical approach in some software framework is to define a hash function on key. We have discussed the issue with Lada, and now take the issue to the mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the data type in YANG. Any comments will be appreciated. Thanks! Richard --001a11c387f42523c305044e438c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

A few of us are doing an exerci= se of defining a YANG module to express the ALTO protocol (RFC7285). Multip= le problems come up and here is one problem we encounter.=C2=A0
<= br>
First, the context. A design decision of the ALTO protocol is = to use key-value stores (maps), which are different from lists or container= s. Many large-scale systems are designed based on key-value stores, and man= y programming frameworks provide hash maps.

=
A particular example of using key-value map is the network-map, w= hich is defined as a key-value store to enforce that each named endpoint ad= dress group has a unique name. A specific example is=C2=A0in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.tx= t):

=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&qu= ot;network-map" : {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID1" : {
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"192.0.2.0/24",
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0"198.51.100.0/25"
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0]
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID2"= ; : {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0"198.51.100.128/25&quo= t;
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID3&= quot; : {
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0"0.0.0.0/0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0],
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv6" : [
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"::/0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= }

One way to express this in YANG is the fo= llowing:
=3D=3D=3Dexample YANG=3D=3D=3D
list network-map {
=
= =C2=A0 key "pid";
=C2=A0 leaf pid {
=C2=A0 =C2=A0 type stri= ng;
=C2=A0 }
=C2=A0 leaf endpoint-address-group ... {
=C2=A0 =C2= =A0 // ...
=C2=A0 }
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D

Following the currently defined= json encoding, the output will be:
{
=C2=A0 "network-map" = : [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID1= ",
=C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
=C2=A0 =C2=A0 },
=C2=A0 = =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID2",
<= div style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">=C2= =A0 =C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 = =C2=A0 =C2=A0 "pid" : "PID3",
=C2=A0 =C2=A0 =C2=A0 /= / ...
=C2=A0 =C2=A0 }
=C2=A0 ]
}=C2=A0

=
But this not what we want, because it is using an array, not a m= ap. One does not have to use an array to store the map.

We see two possibilities, = if to produce the output. One is in the encoding process:=C2=A0define such outputs on matching a t= emplate:

<= div>list MyList {
=C2=A0 key x;
=C2=A0 leaf x {
=C2=A0 =C2=A0 type string;
=C2=A0 }
=C2=A0 l= eaf y {=C2=A0
=C2=A0 =C2= =A0...
=C2=A0 }
}

The second is that maybe this should be resolved i= n YANG; i.e., introducing a new data type (beyond list, container), but som= ething like key-value store, say named map:

map MyMap {
=C2=A0 key my-key {
=C2=A0 =C2=A0 ...
=C2=A0 };
=C2=A0 v= alue my-value {
=C2=A0 }<= /div>
}

Note that the second = mapping involves work if the key type is not a simple type (say string or n= umbers). A typical approach in some software framework is to define a hash = function on key.=C2=A0

We have discus= sed the issue with Lada, and now take the issue to the mailing list. If any= one else has encountered similar problems, please let us know. We also want= to get a sense of any interest in introducing the data type in YANG. Any c= omments will be appreciated.

Thanks!
Richard
--001a11c387f42523c305044e438c-- From nobody Tue Sep 30 13:55:31 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A013A1A8A45; Tue, 30 Sep 2014 13:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 3al0pbq4adDS; Tue, 30 Sep 2014 13:55:28 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A2B961A8A42; Tue, 30 Sep 2014 13:55:27 -0700 (PDT) Received: from [10.110.1.6] (static-72-71-250-37.cncdnh.fast04.myfairpoint.net [72.71.250.37]) by lucidvision.com (Postfix) with ESMTP id 28B7228A95B5; Tue, 30 Sep 2014 16:55:24 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_4BCEF824-88AF-4D39-8954-C0D157E7DC72"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 30 Sep 2014 13:55:20 -0700 Message-Id: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> References: To: "Y. Richard Yang" X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/-_1xt-mO_GnklUqh14zFvy9h2XQ Cc: IETF ALTO , NETMOD Working Group Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 20:55:29 -0000 --Apple-Mail=_4BCEF824-88AF-4D39-8954-C0D157E7DC72 Content-Type: multipart/alternative; boundary="Apple-Mail=_5726FC3E-0930-4202-949C-4B20402B4B80" --Apple-Mail=_5726FC3E-0930-4202-949C-4B20402B4B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii =09 I was discussing this very same issue here at the ODL Yangathon = yesterday. Others are stumbling onto this same issue. --Tom > Hi all, >=20 > A few of us are doing an exercise of defining a YANG module to express = the ALTO protocol (RFC7285). Multiple problems come up and here is one = problem we encounter.=20 >=20 > First, the context. A design decision of the ALTO protocol is to use = key-value stores (maps), which are different from lists or containers. = Many large-scale systems are designed based on key-value stores, and = many programming frameworks provide hash maps. >=20 > A particular example of using key-value map is the network-map, which = is defined as a key-value store to enforce that each named endpoint = address group has a unique name. A specific example is in Section = 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): >=20 > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24", > "198.51.100.0/25" > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25" > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0" > ], > "ipv6" : [ > "::/0" > ] > } >=20 > One way to express this in YANG is the following: > =3D=3D=3Dexample YANG=3D=3D=3D > list network-map { > key "pid"; > leaf pid { > type string; > } > leaf endpoint-address-group ... { > // ... > } > } > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >=20 > Following the currently defined json encoding, the output will be: > { > "network-map" : [ > { > "pid" : "PID1", > // ... > }, > { > "pid" : "PID2", > // ... > }, > { > "pid" : "PID3", > // ... > } > ] > }=20 >=20 > But this not what we want, because it is using an array, not a map. = One does not have to use an array to store the map. >=20 > We see two possibilities, if to produce the output. One is in the = encoding process: define such outputs on matching a template: >=20 > list MyList { > key x; > leaf x { > type string; > } > leaf y {=20 > ... > } > } >=20 > The second is that maybe this should be resolved in YANG; i.e., = introducing a new data type (beyond list, container), but something like = key-value store, say named map: >=20 > map MyMap { > key my-key { > ... > }; > value my-value { > } > } >=20 > Note that the second mapping involves work if the key type is not a = simple type (say string or numbers). A typical approach in some software = framework is to define a hash function on key.=20 >=20 > We have discussed the issue with Lada, and now take the issue to the = mailing list. If anyone else has encountered similar problems, please = let us know. We also want to get a sense of any interest in introducing = the data type in YANG. Any comments will be appreciated. >=20 > Thanks! >=20 > Richard > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_5726FC3E-0930-4202-949C-4B20402B4B80 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii =
I was discussing this very same = issue here at the ODL Yangathon yesterday.  Others are stumbling = onto this same issue.

= --Tom


Hi all,

A few of us are doing an exercise = of defining a YANG module to express the ALTO protocol (RFC7285). = Multiple problems come up and here is one problem we = encounter. 

First,= the context. A design decision of the ALTO protocol is to use key-value = stores (maps), which are different from lists or containers. Many = large-scale systems are designed based on key-value stores, and many = programming frameworks provide hash maps.

A = particular example of using key-value map is the network-map, which is = defined as a key-value store to enforce that each named endpoint address = group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.o= rg/rfc/rfc7285.txt):

         "network-map" : = {
      =      "PID1" : {
             "ipv4" : = [
      =          "192.0.2.0/24",
            =    "198.51.100.0/25"
            =  ]
    =        },
           "PID2" : = {
      =        "ipv4" : [
            =    "198.51.100.128/25"
=           =    ]
  =          },
           "PID3" : = {
      =        "ipv4" : [
            =    "0.0.0.0/0"
            =  ],
    =          "ipv6" : [
            =    "::/0"
            =  ]
    =        }

One way to = express this in YANG is the following:
=3D=3D= =3Dexample YANG=3D=3D=3D
list = network-map {
 = key "pid";
 = leaf pid {
 =   type string;
 = }
 = leaf endpoint-address-group ... {
 =   // ...
 = }
}
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Following the currently defined json encoding, the output will = be:
{
 = "network-map" : [
 =   {
 =     "pid" : "PID1",
 =      // ...
 =   },
 =   {
 =     "pid" : "PID2",
 =     // ...
 =   },
 =   {
 =     "pid" : "PID3",
 =     // ...
 =   }
 = ]
} 

But this not what we want, because it = is using an array, not a map. One does not have to use an array to store = the map.

We see two possibilities, if to = produce the output. One is in the encoding process: define such outputs on = matching a template:
<= font face=3D"arial, sans-serif">
list MyList {
  key x;
  leaf x {
    type string;
  }
  leaf y { 
   ...
  }
}

The second is that maybe this should be = resolved in YANG; i.e., introducing a new data type (beyond list, = container), but something like key-value store, say named = map:

map MyMap {
  key my-key {
    ...
  };
  value my-value {
  }
}

Note that the second mapping involves work if = the key type is not a simple type (say string or numbers). A typical = approach in some software framework is to define a hash function on = key. 

We have discussed the = issue with Lada, and now take the issue to the mailing list. If anyone = else has encountered similar problems, please let us know. We also want = to get a sense of any interest in introducing the data type in YANG. Any = comments will be = appreciated.

Thanks!

Ric= hard
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.or= g/mailman/listinfo/netmod

= --Apple-Mail=_5726FC3E-0930-4202-949C-4B20402B4B80-- --Apple-Mail=_4BCEF824-88AF-4D39-8954-C0D157E7DC72 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKxi4AAoJEPcO+I7eiUJZE2QQAJlMBHSAUUvN8Pt+i3floNmt 2EBiArpQIgpCZkDL1asTb6SMXQ//x6+4HU1zIMM4/P24WbfohWGJEsf+lS4eQuuZ SEO21y8OqHMBOuA/bkM4nnE1gz73nR2HeHxsuEFGmcYzLqkjObaBJV5AmvMredI8 v6EgBWpdwwDbVEzbSU/qqFBEYl64m56VKgeizFUUXZHGqag+/61Hom5nHfNcnWmZ 5N8AD+g04eFnQCCL3L1yY/4SaQVrlK8Hwk1R+U3h7ovr7hr3ZU0jCU7ceKkamwBf XH4+nB7FJuz8LHjO5a6sXtu0JdmZNqevpMxe6mVwLfuFiD7cMnww+DQ/SdppjODn i6n6E8AOxenTWPTxu4vX6jHqQVASG2EVHCXsCfJ88mpyS3Laew8XPHjpSb9iwGX5 yLDq+7gQthMDG9xB+exLGWJKJGYPEWHnw9xfJbHL2IkwdrlJQsFnWMKM9fyz3d0A knLH7CtEJg3KjcTKWvUJxsFb2ZQF/v8wzFGIAHiwCXr/WeqqgBUW7lvS4+l+EARZ 2A7zVbesR+IVcAYSt16YzZBA7HyTqn+25AHKh2oMmSPG7xwUU/s8l6QNYSAmsDMy XybqZdS9/pfI/NfLgS87jBGjHW6bFdADFAKDmeCEa5ypXmWpa99XHVif6Pbp1DN9 +VjD8abWWNKlIfrUy0Z0 =AQHE -----END PGP SIGNATURE----- --Apple-Mail=_4BCEF824-88AF-4D39-8954-C0D157E7DC72-- From nobody Tue Sep 30 14:17:12 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 661BE1A914B for ; Tue, 30 Sep 2014 14:16:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable 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 RKdULsz_L4kc for ; Tue, 30 Sep 2014 14:16:55 -0700 (PDT) Received: from mail-qc0-f179.google.com (mail-qc0-f179.google.com [209.85.216.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F1941A9144 for ; Tue, 30 Sep 2014 14:16:55 -0700 (PDT) Received: by mail-qc0-f179.google.com with SMTP id x3so4237705qcv.24 for ; Tue, 30 Sep 2014 14:16:54 -0700 (PDT) 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=3f4vqoZ5MlpQEENg4mLp7a3pKi4fzRnawQ7GFGu2Fus=; b=YcouL5tvUj26pE6SOFlEr6zg/CwiCDHqbZM69LukVDNoxNiON2+tu2Yqr7Bh4qLzz8 cu3UztRSDLqbAAvocMaSbJwRMLBlVs7dGZ6M9n+3kKyWIARxZzPjt6SxX1TB7UJjaqM0 Ez/MvfDcKpatDR6hokuxAnb5lFqt4pwxNlsNN5J36A4awLP8uNUBp6SkSzOD9p+ogOdm QmLS1oiNHUqJ5robJ44W0/O1bzlq7VIKxEHYlqEutLpVX6C8kIBOGM1K2fN8LIj1+tcA 3Zq0VmLN2uPRs+BIo+rU2JxtJeSMB38/0cIiWYbtrYFJrzfMPWc4M801gv8noogKu20s Rv+g== X-Gm-Message-State: ALoCoQnZKUKG+LqmMm+aQ+8HR5BnzQiF2bnIK0kHS9FE31RL0wIUKxcYLK2ciDipHguUFoNusNTp MIME-Version: 1.0 X-Received: by 10.224.28.68 with SMTP id l4mr64328066qac.16.1412111814610; Tue, 30 Sep 2014 14:16:54 -0700 (PDT) Received: by 10.140.37.52 with HTTP; Tue, 30 Sep 2014 14:16:54 -0700 (PDT) In-Reply-To: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> References: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> Date: Tue, 30 Sep 2014 14:16:54 -0700 Message-ID: From: Andy Bierman To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=001a11c2c3ce18270705044ee7cd Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/Gwfk4gUdB4pAkb8l0rRdYRGhTmY Cc: IETF ALTO , NETMOD Working Group Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:16:59 -0000 --001a11c2c3ce18270705044ee7cd Content-Type: text/plain; charset=ISO-8859-1 Hi, On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau wrote: > > I was discussing this very same issue here at the ODL Yangathon > yesterday. Others are stumbling onto this same issue. > > Do you mean you want control over the YANG to JSON mapping? IMO, YANG needs to be independent of the protocol message encoding. The implementation burden on servers is already too high. There should only be 1 mapping for each encoding format. How would you change YANG to get this JSON encoding? --Tom > > > Andy > Hi all, > > A few of us are doing an exercise of defining a YANG module to express the > ALTO protocol (RFC7285). Multiple problems come up and here is one problem > we encounter. > > First, the context. A design decision of the ALTO protocol is to use > key-value stores (maps), which are different from lists or containers. Many > large-scale systems are designed based on key-value stores, and many > programming frameworks provide hash maps. > > A particular example of using key-value map is the network-map, which is > defined as a key-value store to enforce that each named endpoint address > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24", > "198.51.100.0/25" > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25" > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0" > ], > "ipv6" : [ > "::/0" > ] > } > > One way to express this in YANG is the following: > ===example YANG=== > list network-map { > key "pid"; > leaf pid { > type string; > } > leaf endpoint-address-group ... { > // ... > } > } > ================== > > Following the currently defined json encoding, the output will be: > { > "network-map" : [ > { > "pid" : "PID1", > // ... > }, > { > "pid" : "PID2", > // ... > }, > { > "pid" : "PID3", > // ... > } > ] > } > > But this not what we want, because it is using an array, not a map. One > does not have to use an array to store the map. > > We see two possibilities, if to produce the output. One is in the encoding > process: define such outputs on matching a template: > > list MyList { > key x; > leaf x { > type string; > } > leaf y { > ... > } > } > > The second is that maybe this should be resolved in YANG; i.e., > introducing a new data type (beyond list, container), but something like > key-value store, say named map: > > map MyMap { > key my-key { > ... > }; > value my-value { > } > } > > Note that the second mapping involves work if the key type is not a simple > type (say string or numbers). A typical approach in some software framework > is to define a hash function on key. > > We have discussed the issue with Lada, and now take the issue to the > mailing list. If anyone else has encountered similar problems, please let > us know. We also want to get a sense of any interest in introducing the > data type in YANG. Any comments will be appreciated. > > Thanks! > > Richard > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --001a11c2c3ce18270705044ee7cd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,


On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau <tnade= au@lucidvision.com> wrote:
=
<= /span>
I was disc= ussing this very same issue here at the ODL Yangathon yesterday.=A0 Others = are stumbling onto this same issue.


Do you mean you want control over the YANG to JSO= N mapping?
IMO, YANG needs to be independent of the protocol mess= age encoding.
The implementation burden on servers is already too= high.
There should only be 1 mapping for each encoding format.

How would you change YANG to get this JSON encoding= ?



--Tom



Andy
=A0
Hi all,

A few of us are doing an= exercise of defining a YANG module to express the ALTO protocol (RFC7285).= Multiple problems come up and here is one problem we encounter.=A0

First, the context. A design decision of the ALTO protocol= is to use key-value stores (maps), which are different from lists or conta= iners. Many large-scale systems are designed based on key-value stores, and= many programming frameworks provide hash maps.

A particular example of using key-value map is the network-ma= p, which is defined as a key-value store to enforce that each named endpoin= t address group has a unique name. A specific example is=A0in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor= .org/rfc/rfc7285.txt):
=A0 =A0 =A0 =A0 = =A0"network-map" : {
=A0 =A0 =A0 =A0 =A0 =A0"PID1" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0"ipv4" : [
=A0 =A0 =A0 =A0 =A0 =A0 =A0= =A0"192.0.2.0/24",
= =A0 =A0 =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 =A0 =A0},
=A0 =A0 =A0 =A0 =A0 =A0"PID2" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0"ipv4" : [
=A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0"198.51.100.= 128/25"
=A0 =A0 = =A0 =A0 =A0 =A0 =A0]
=A0 = =A0 =A0 =A0 =A0 =A0},
=A0= =A0 =A0 =A0 =A0 =A0"PID3" : {
=A0 =A0 =A0 =A0 =A0 =A0 =A0"ipv4" : [
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"= ;0.0.0.0/0"<= /div>
=A0 =A0 =A0 =A0 =A0 =A0 =A0],
=A0 =A0 =A0 =A0 =A0 =A0 =A0= "ipv6" : [
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0"::/0"
=A0 =A0 =A0 =A0 =A0 =A0 =A0]
=A0 =A0 =A0 =A0 =A0 =A0}

=
One way to express this in YANG is the following:
=3D=3D=3Dexa= mple YANG=3D=3D=3D
list network-map {
=A0 key "pid";
<= div style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">=A0= leaf pid {
=A0 =A0 type string;
=A0 }
=A0 leaf endpoint-address-g= roup ... {
=A0 =A0 // ...
=A0 }
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D

Following the cu= rrently defined json encoding, the output will be:
{
=A0 "networ= k-map" : [
=A0 =A0 {
=A0 =A0 =A0 "pid" : "PID1&qu= ot;,
=A0 =A0 =A0 =A0// ...
=A0 =A0 },
=A0 =A0 {
=A0 =A0 =A0 &qu= ot;pid" : "PID2",
=A0 =A0 =A0 // ...
=A0 =A0 },
<= div style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">=A0= =A0 {
=A0 =A0 =A0 "pid" : "PID3",
=A0 =A0 =A0 = // ...
=A0 =A0 }
=A0 ]
}=A0

= But this not what we want, because it is using an array, not a map. One doe= s not have to use an array to store the map.

We see two possibilities, if to produ= ce the output. One is in the encoding process:=A0define such outputs on matching a template:

list MyList {
=A0 key x;
= =A0 leaf x {
=A0 =A0 type= string;
=A0 }
=A0 leaf y {=A0
=A0 =A0...
=A0 }
}<= /font>

The second is that= maybe this should be resolved in YANG; i.e., introducing a new data type (= beyond list, container), but something like key-value store, say named map:=

map MyMap {
=A0= key my-key {
=A0 =A0 ...=
=A0 };
=A0 value my-value {
=A0 }
}

Note= that the second mapping involves work if the key type is not a simple type= (say string or numbers). A typical approach in some software framework is = to define a hash function on key.=A0

= We have discussed the issue with Lada, and now take the issue to the mailin= g list. If anyone else has encountered similar problems, please let us know= . We also want to get a sense of any interest in introducing the data type = in YANG. Any comments will be appreciated.

Thanks!=

Richard
_______________________________________________
netmod mailing list
<= a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
= = https://www.ietf.org/mailman/listinfo/netmod

=

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


--001a11c2c3ce18270705044ee7cd-- From nobody Tue Sep 30 14:38:09 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D89D1A916D; Tue, 30 Sep 2014 14:38:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 2Xg_8we_oYYm; Tue, 30 Sep 2014 14:38:01 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8F0F1A9149; Tue, 30 Sep 2014 14:38:00 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id cc10so4786047wib.16 for ; Tue, 30 Sep 2014 14:37:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=8PV5/X8N4Xy+ZmkC7dqTKOWt1z1HAs/Ds1tRnkvmrq4=; b=0Ii7oZNBiugAZXhGVs8jJjP7jGjYtI27hfzayv1xj6RBc1iohltTvBjOFKxUUkQ7jM StvjqfP8kTnL5Mw37FGWi/TJhCBQPrXvS2LdlpovDkmTqGk9+b6nfxCTdWBZ25nR5j5a pEWLOaqov+tKAO+qT3ojx/V+bYLkV4hReHPTlyBLBgtqKLXKBeLXSUp2aLxfASAn+Q7j ST4GK8wVo73WEYoitUXMc0LdyNzEnm+TL2bVBoZulsR2+x8n+3Vtr359MJhCMf/XyGZI GCBxVy8P3QckKQNS3i4I0YyRQVpCPQqVEXq/2geN+1xbRrDcIIzp3V4rUqZHAPiZe/eK BDOQ== MIME-Version: 1.0 X-Received: by 10.194.58.13 with SMTP id m13mr6803540wjq.134.1412113079515; Tue, 30 Sep 2014 14:37:59 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.139 with HTTP; Tue, 30 Sep 2014 14:37:59 -0700 (PDT) Received: by 10.27.178.139 with HTTP; Tue, 30 Sep 2014 14:37:59 -0700 (PDT) In-Reply-To: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> References: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> Date: Tue, 30 Sep 2014 17:37:59 -0400 X-Google-Sender-Auth: NjGxvhzPTH45n5bEd8GZCQO8cGY Message-ID: From: "Y. Richard Yang" To: "Thomas D. Nadeau" Content-Type: multipart/alternative; boundary=047d7bacbdbe7cc24105044f325c Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/gfRonIh8Tu8rkTddsEzjjG2K0qM Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:38:03 -0000 --047d7bacbdbe7cc24105044f325c Content-Type: text/plain; charset=UTF-8 Cool! It us good to know that we are not the only one. Richard On Sep 30, 2014 4:55 PM, "Thomas D. Nadeau" wrote: > > I was discussing this very same issue here at the ODL Yangathon > yesterday. Others are stumbling onto this same issue. > > --Tom > > > Hi all, > > A few of us are doing an exercise of defining a YANG module to express the > ALTO protocol (RFC7285). Multiple problems come up and here is one problem > we encounter. > > First, the context. A design decision of the ALTO protocol is to use > key-value stores (maps), which are different from lists or containers. Many > large-scale systems are designed based on key-value stores, and many > programming frameworks provide hash maps. > > A particular example of using key-value map is the network-map, which is > defined as a key-value store to enforce that each named endpoint address > group has a unique name. A specific example is in Section 11.2.1.7 of RFC > 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): > > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24", > "198.51.100.0/25" > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25" > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0" > ], > "ipv6" : [ > "::/0" > ] > } > > One way to express this in YANG is the following: > ===example YANG=== > list network-map { > key "pid"; > leaf pid { > type string; > } > leaf endpoint-address-group ... { > // ... > } > } > ================== > > Following the currently defined json encoding, the output will be: > { > "network-map" : [ > { > "pid" : "PID1", > // ... > }, > { > "pid" : "PID2", > // ... > }, > { > "pid" : "PID3", > // ... > } > ] > } > > But this not what we want, because it is using an array, not a map. One > does not have to use an array to store the map. > > We see two possibilities, if to produce the output. One is in the encoding > process: define such outputs on matching a template: > > list MyList { > key x; > leaf x { > type string; > } > leaf y { > ... > } > } > > The second is that maybe this should be resolved in YANG; i.e., > introducing a new data type (beyond list, container), but something like > key-value store, say named map: > > map MyMap { > key my-key { > ... > }; > value my-value { > } > } > > Note that the second mapping involves work if the key type is not a simple > type (say string or numbers). A typical approach in some software framework > is to define a hash function on key. > > We have discussed the issue with Lada, and now take the issue to the > mailing list. If anyone else has encountered similar problems, please let > us know. We also want to get a sense of any interest in introducing the > data type in YANG. Any comments will be appreciated. > > Thanks! > > Richard > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > --047d7bacbdbe7cc24105044f325c Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Cool! It us good to know that we are not the only one.

Richard

On Sep 30, 2014 4:55 PM, "Thomas D. Nadeau&= quot; <tnadeau@lucidvision.co= m> wrote:

I was discuss= ing this very same issue here at the ODL Yangathon yesterday.=C2=A0 Others = are stumbling onto this same issue.

--Tom


Hi all,

A few of us are doi= ng an exercise of defining a YANG module to express the ALTO protocol (RFC7= 285). Multiple problems come up and here is one problem we encounter.=C2=A0=

First, the context. A design decision of the ALTO = protocol is to use key-value stores (maps), which are different from lists = or containers. Many large-scale systems are designed based on key-value sto= res, and many programming frameworks provide hash maps.

A particular example of using key-value map is the ne= twork-map, which is defined as a key-value store to enforce that each named= endpoint address group has a unique name. A specific example is=C2=A0in Section 11.2.1.7 of RFC 7285 (http://www= .rfc-editor.org/rfc/rfc7285.txt):

=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0"network-map" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&quo= t;PID1" : {
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"19= 2.0.2.0/24",
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"198.51.100.0/25"
<= div>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0]
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID2" : {<= /div>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"<= a href=3D"http://198.51.100.128/25" target=3D"_blank">198.51.100.128/25= "
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"P= ID3" : {
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0"0.0.0.0/= 0"
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv6&quo= t; : [
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"::/0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0]
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0}

One way to express t= his in YANG is the following:
=3D=3D=3Dexample YANG=3D=3D=3D
<= div style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">lis= t network-map {
=C2=A0 key "pid";
=C2=A0 leaf pid {
=C2= =A0 =C2=A0 type string;
=C2=A0 }
=C2=A0 leaf endpoint-address-group .= .. {
=C2=A0 =C2=A0 // ...
=C2=A0 }
}
=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Following the= currently defined json encoding, the output will be:
{
=C2=A0 "= ;network-map" : [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid= " : "PID1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
=C2=A0 = =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : &quo= t;PID2",
=C2=A0 =C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 },
=C2=A0 = =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID3",
<= div style=3D"font-family:arial,sans-serif;font-size:12.8000001907349px">=C2= =A0 =C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 }
=C2=A0 ]
}= =C2=A0

But this not what we want, because it is us= ing an array, not a map. One does not have to use an array to store the map= .

We se= e two possibilities, if to produce the output. One is in the encoding proce= ss:=C2=A0define such ou= tputs on matching a template:

list MyList {
=C2=A0 key x;
=C2=A0 leaf x {
=C2=A0 =C2=A0 type string;
=C2=A0 }
=C2=A0 leaf y {=C2=A0
=C2=A0 =C2=A0...
}
=

The second is that maybe this = should be resolved in YANG; i.e., introducing a new data type (beyond list,= container), but something like key-value store, say named map:
<= font face=3D"arial, sans-serif">
map MyMap {
=C2=A0 key my-k= ey {
=C2=A0 =C2=A0 ...
=C2=A0 };
=C2=A0 value my-value {
=C2=A0 }
}

N= ote that the second mapping involves work if the key type is not a simple t= ype (say string or numbers). A typical approach in some software framework = is to define a hash function on key.=C2=A0

We have discussed the issue with Lada, and now take the issue to the = mailing list. If anyone else has encountered similar problems, please let u= s know. We also want to get a sense of any interest in introducing the data= type in YANG. Any comments will be appreciated.

T= hanks!

Richard
_______________________________________________
netmod mailing list
<= a href=3D"mailto:netmod@ietf.org" target=3D"_blank">netmod@ietf.org
= = https://www.ietf.org/mailman/listinfo/netmod

=
--047d7bacbdbe7cc24105044f325c-- From nobody Tue Sep 30 14:48:42 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48A131A930A; Tue, 30 Sep 2014 14:48:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.276 X-Spam-Level: X-Spam-Status: No, score=-1.276 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 7IYnyqOgPaJA; Tue, 30 Sep 2014 14:48:38 -0700 (PDT) Received: from mail-wi0-x233.google.com (mail-wi0-x233.google.com [IPv6:2a00:1450:400c:c05::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D41FB1A9251; Tue, 30 Sep 2014 14:48:36 -0700 (PDT) Received: by mail-wi0-f179.google.com with SMTP id d1so4844256wiv.6 for ; Tue, 30 Sep 2014 14:48:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=VYV83UY4BxGFE24dlTG16XmMKAfWZ2nmjATzJyL8jaM=; b=v/hcMC0YG3gkXwqAtQ7eKmXpVDJnNVpxLYgh3lS5lP8LH3amfF/1sReFxH4qWIpsw/ kTL7aG8dWMf2yUCDwkO56ngYghwYvk/4I5m/wuwyj68JivIqfLY9E8kendbMVjm/K7A5 BA57sMzDBuOTxBpUIv947+Y8oYZOv43e02PYrtK1tBj53Ms/Bu9VTyDCZJf85uiSyXB3 2jPZ2h3anfR+fZn0KoI0uSmYRrSx3D1UpXKddJ+eOjNgLueSBoQBJ8BsCbm20H8S5V1j 4RBZhAqcF6XW24Jo4sUeA2JREORCYANFuX0M3Rbv8OvOjKgEntKGPZMyPOLjCD7y8HyH g+ew== MIME-Version: 1.0 X-Received: by 10.180.198.10 with SMTP id iy10mr8985294wic.10.1412113715484; Tue, 30 Sep 2014 14:48:35 -0700 (PDT) Sender: yang.r.yang@gmail.com Received: by 10.27.178.139 with HTTP; Tue, 30 Sep 2014 14:48:35 -0700 (PDT) Received: by 10.27.178.139 with HTTP; Tue, 30 Sep 2014 14:48:35 -0700 (PDT) In-Reply-To: References: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> Date: Tue, 30 Sep 2014 17:48:35 -0400 X-Google-Sender-Auth: 9rJQyjGGgQczEzUNR3sXMbhhC2g Message-ID: From: "Y. Richard Yang" To: Andy Bierman Content-Type: multipart/alternative; boundary=047d7b6226d064dd8205044f584d Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/oe8E07giSi80G9mYTY4PO-ekuHc Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 21:48:40 -0000 --047d7b6226d064dd8205044f584d Content-Type: text/plain; charset=UTF-8 On Sep 30, 2014 5:16 PM, "Andy Bierman" wrote: > > Hi, > > > On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau wrote: >> >> >> I was discussing this very same issue here at the ODL Yangathon yesterday. Others are stumbling onto this same issue. >> > > Do you mean you want control over the YANG to JSON mapping? Yes and no. The issue is raised in the context of encoding. But it is a more general issue regarding completeness of data types in YANG: - list is an ordered array - container is a static, heterogeneous associate array - key-value store is a dynamic (size unknown at compile time), homogeneous array. It is a commonly used data type. > IMO, YANG needs to be independent of the protocol message encoding. > The implementation burden on servers is already too high. > There should only be 1 mapping for each encoding format. > > How would you change YANG to get this JSON encoding? There are at least two possibilities. Please see previous email. Make sense? Richard > > > >> --Tom >> >> > > Andy > >>> >>> Hi all, >>> >>> A few of us are doing an exercise of defining a YANG module to express the ALTO protocol (RFC7285). Multiple problems come up and here is one problem we encounter. >>> >>> First, the context. A design decision of the ALTO protocol is to use key-value stores (maps), which are different from lists or containers. Many large-scale systems are designed based on key-value stores, and many programming frameworks provide hash maps. >>> >>> A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): >>> >>> "network-map" : { >>> "PID1" : { >>> "ipv4" : [ >>> "192.0.2.0/24", >>> "198.51.100.0/25" >>> ] >>> }, >>> "PID2" : { >>> "ipv4" : [ >>> "198.51.100.128/25" >>> ] >>> }, >>> "PID3" : { >>> "ipv4" : [ >>> "0.0.0.0/0" >>> ], >>> "ipv6" : [ >>> "::/0" >>> ] >>> } >>> >>> One way to express this in YANG is the following: >>> ===example YANG=== >>> list network-map { >>> key "pid"; >>> leaf pid { >>> type string; >>> } >>> leaf endpoint-address-group ... { >>> // ... >>> } >>> } >>> ================== >>> >>> Following the currently defined json encoding, the output will be: >>> { >>> "network-map" : [ >>> { >>> "pid" : "PID1", >>> // ... >>> }, >>> { >>> "pid" : "PID2", >>> // ... >>> }, >>> { >>> "pid" : "PID3", >>> // ... >>> } >>> ] >>> } >>> >>> But this not what we want, because it is using an array, not a map. One does not have to use an array to store the map. >>> >>> We see two possibilities, if to produce the output. One is in the encoding process: define such outputs on matching a template: >>> >>> list MyList { >>> key x; >>> leaf x { >>> type string; >>> } >>> leaf y { >>> ... >>> } >>> } >>> >>> The second is that maybe this should be resolved in YANG; i.e., introducing a new data type (beyond list, container), but something like key-value store, say named map: >>> >>> map MyMap { >>> key my-key { >>> ... >>> }; >>> value my-value { >>> } >>> } >>> >>> Note that the second mapping involves work if the key type is not a simple type (say string or numbers). A typical approach in some software framework is to define a hash function on key. >>> >>> We have discussed the issue with Lada, and now take the issue to the mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the data type in YANG. Any comments will be appreciated. >>> >>> Thanks! >>> >>> Richard >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > --047d7b6226d064dd8205044f584d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Sep 30, 2014 5:16 PM, "Andy Bierman" <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> wrote:
>>
>>
>> I was discussing this very same issue here at the ODL Yangathon ye= sterday.=C2=A0 Others are stumbling onto this same issue.
>>
>
> Do you mean you want control over the YANG to JSON mapping?

Yes and no. The issue is raised in the context of encoding. = But it is a more general issue regarding completeness of data types in YANG= :

- list is an ordered array

- container is a static, heterogeneous associate array

- key-value store is a dynamic (size unknown at compile time= ), homogeneous array. It is a commonly used data type.

> IMO, YANG needs to be independent of the protocol messa= ge encoding.
> The implementation burden on servers is already too high.
> There should only be 1 mapping for each encoding format.
>
> How would you change YANG to get this JSON encoding?

There are at least two possibilities. Please see previous em= ail. Make sense?

Richard
>
>
>
>> --Tom
>>
>>
>
> Andy
> =C2=A0
>>>
>>> Hi all,
>>>
>>> A few of us are doing an exercise of defining a YANG module to= express the ALTO protocol (RFC7285). Multiple problems come up and here is= one problem we encounter.=C2=A0
>>>
>>> First, the context. A design decision of the ALTO protocol is = to use key-value stores (maps), which are different from lists or container= s. Many large-scale systems are designed based on key-value stores, and man= y programming frameworks provide hash maps.
>>>
>>> A particular example of using key-value map is the network-map= , which is defined as a key-value store to enforce that each named endpoint= address group has a unique name. A specific example is=C2=A0in Section 11.= 2.1.7 of RFC 7285 (ht= tp://www.rfc-editor.org/rfc/rfc7285.txt):
>>>
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"network-map" : {<= br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID1" : {<= br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4&quo= t; : [
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"<= a href=3D"http://192.0.2.0/24">192.0.2.0/24",
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"<= a href=3D"http://198.51.100.0/25">198.51.100.0/25"
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID2" : {<= br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4&quo= t; : [
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"<= a href=3D"http://198.51.100.128/25">198.51.100.128/25"
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID3" : {<= br> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4&quo= t; : [
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"<= a href=3D"http://0.0.0.0/0">0.0.0.0/0"
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0],
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv6&quo= t; : [
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0":= :/0"
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>>>
>>> One way to express this in YANG is the following:
>>> =3D=3D=3Dexample YANG=3D=3D=3D
>>> list network-map {
>>> =C2=A0 key "pid";
>>> =C2=A0 leaf pid {
>>> =C2=A0 =C2=A0 type string;
>>> =C2=A0 }
>>> =C2=A0 leaf endpoint-address-group ... {
>>> =C2=A0 =C2=A0 // ...
>>> =C2=A0 }
>>> }
>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>
>>> Following the currently defined json encoding, the output will= be:
>>> {
>>> =C2=A0 "network-map" : [
>>> =C2=A0 =C2=A0 {
>>> =C2=A0 =C2=A0 =C2=A0 "pid" : "PID1",
>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
>>> =C2=A0 =C2=A0 },
>>> =C2=A0 =C2=A0 {
>>> =C2=A0 =C2=A0 =C2=A0 "pid" : "PID2",
>>> =C2=A0 =C2=A0 =C2=A0 // ...
>>> =C2=A0 =C2=A0 },
>>> =C2=A0 =C2=A0 {
>>> =C2=A0 =C2=A0 =C2=A0 "pid" : "PID3",
>>> =C2=A0 =C2=A0 =C2=A0 // ...
>>> =C2=A0 =C2=A0 }
>>> =C2=A0 ]
>>> }=C2=A0
>>>
>>> But this not what we want, because it is using an array, not a= map. One does not have to use an array to store the map.
>>>
>>> We see two possibilities, if to produce the output. One is in = the encoding process:=C2=A0define such outputs on matching a template:
>>>
>>> list MyList {
>>> =C2=A0 key x;
>>> =C2=A0 leaf x {
>>> =C2=A0 =C2=A0 type string;
>>> =C2=A0 }
>>> =C2=A0 leaf y {=C2=A0
>>> =C2=A0 =C2=A0...
>>> =C2=A0 }
>>> }
>>>
>>> The second is that maybe this should be resolved in YANG; i.e.= , introducing a new data type (beyond list, container), but something like = key-value store, say named map:
>>>
>>> map MyMap {
>>> =C2=A0 key my-key {
>>> =C2=A0 =C2=A0 ...
>>> =C2=A0 };
>>> =C2=A0 value my-value {
>>> =C2=A0 }
>>> }
>>>
>>> Note that the second mapping involves work if the key type is = not a simple type (say string or numbers). A typical approach in some softw= are framework is to define a hash function on key.=C2=A0
>>>
>>> We have discussed the issue with Lada, and now take the issue = to the mailing list. If anyone else has encountered similar problems, pleas= e let us know. We also want to get a sense of any interest in introducing t= he data type in YANG. Any comments will be appreciated.
>>>
>>> Thanks!
>>>
>>> Richard
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https= ://www.ietf.org/mailman/listinfo/netmod
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://w= ww.ietf.org/mailman/listinfo/netmod
>>
>

--047d7b6226d064dd8205044f584d-- From nobody Tue Sep 30 15:00:24 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D04B1A9245; Tue, 30 Sep 2014 15:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.686 X-Spam-Level: X-Spam-Status: No, score=-2.686 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=0.001, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 wQ_GrEkuoLY9; Tue, 30 Sep 2014 15:00:15 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id A2AD71ACC81; Tue, 30 Sep 2014 15:00:12 -0700 (PDT) Received: from [172.20.40.235] (unknown [12.199.206.2]) by lucidvision.com (Postfix) with ESMTP id DA40528A9797; Tue, 30 Sep 2014 18:00:10 -0400 (EDT) Content-Type: multipart/signed; boundary="Apple-Mail=_76DD145F-A893-41FC-A733-4A3DBBDBF532"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: "Thomas D. Nadeau" In-Reply-To: Date: Tue, 30 Sep 2014 15:00:06 -0700 Message-Id: References: <1FBF3FB2-BB27-4940-BE99-2F9B75D6563A@lucidvision.com> To: Andy Bierman X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/mwdDFz-BrnCJSGEjblGI65cN9P8 Cc: IETF ALTO , NETMOD Working Group Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Sep 2014 22:00:22 -0000 --Apple-Mail=_76DD145F-A893-41FC-A733-4A3DBBDBF532 Content-Type: multipart/alternative; boundary="Apple-Mail=_E3CBC1A5-5D44-48B2-85A7-D5BB6DD896EF" --Apple-Mail=_E3CBC1A5-5D44-48B2-85A7-D5BB6DD896EF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 On Sep 30, 2014:2:16 PM, at 2:16 PM, Andy Bierman = wrote: > Hi, >=20 >=20 > On Tue, Sep 30, 2014 at 1:55 PM, Thomas D. Nadeau = wrote: > =09 > I was discussing this very same issue here at the ODL Yangathon = yesterday. Others are stumbling onto this same issue. >=20 >=20 > Do you mean you want control over the YANG to JSON mapping? > IMO, YANG needs to be independent of the protocol message encoding. > The implementation burden on servers is already too high. > There should only be 1 mapping for each encoding format. >=20 > How would you change YANG to get this JSON encoding? That isn't what I was getting at - the key-value pair = representation was asked about. It is a pain representing this as a = list. --Tom >=20 >=20 >=20 > --Tom >=20 >=20 >=20 > Andy > =20 >> Hi all, >>=20 >> A few of us are doing an exercise of defining a YANG module to = express the ALTO protocol (RFC7285). Multiple problems come up and here = is one problem we encounter.=20 >>=20 >> First, the context. A design decision of the ALTO protocol is to use = key-value stores (maps), which are different from lists or containers. = Many large-scale systems are designed based on key-value stores, and = many programming frameworks provide hash maps. >>=20 >> A particular example of using key-value map is the network-map, which = is defined as a key-value store to enforce that each named endpoint = address group has a unique name. A specific example is in Section = 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): >>=20 >> "network-map" : { >> "PID1" : { >> "ipv4" : [ >> "192.0.2.0/24", >> "198.51.100.0/25" >> ] >> }, >> "PID2" : { >> "ipv4" : [ >> "198.51.100.128/25" >> ] >> }, >> "PID3" : { >> "ipv4" : [ >> "0.0.0.0/0" >> ], >> "ipv6" : [ >> "::/0" >> ] >> } >>=20 >> One way to express this in YANG is the following: >> =3D=3D=3Dexample YANG=3D=3D=3D >> list network-map { >> key "pid"; >> leaf pid { >> type string; >> } >> leaf endpoint-address-group ... { >> // ... >> } >> } >> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>=20 >> Following the currently defined json encoding, the output will be: >> { >> "network-map" : [ >> { >> "pid" : "PID1", >> // ... >> }, >> { >> "pid" : "PID2", >> // ... >> }, >> { >> "pid" : "PID3", >> // ... >> } >> ] >> }=20 >>=20 >> But this not what we want, because it is using an array, not a map. = One does not have to use an array to store the map. >>=20 >> We see two possibilities, if to produce the output. One is in the = encoding process: define such outputs on matching a template: >>=20 >> list MyList { >> key x; >> leaf x { >> type string; >> } >> leaf y {=20 >> ... >> } >> } >>=20 >> The second is that maybe this should be resolved in YANG; i.e., = introducing a new data type (beyond list, container), but something like = key-value store, say named map: >>=20 >> map MyMap { >> key my-key { >> ... >> }; >> value my-value { >> } >> } >>=20 >> Note that the second mapping involves work if the key type is not a = simple type (say string or numbers). A typical approach in some software = framework is to define a hash function on key.=20 >>=20 >> We have discussed the issue with Lada, and now take the issue to the = mailing list. If anyone else has encountered similar problems, please = let us know. We also want to get a sense of any interest in introducing = the data type in YANG. Any comments will be appreciated. >>=20 >> Thanks! >>=20 >> Richard >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 >=20 --Apple-Mail=_E3CBC1A5-5D44-48B2-85A7-D5BB6DD896EF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=iso-8859-1
On Sep 30, 2014:2:16 PM, at 2:16 PM, = Andy Bierman <andy@yumaworks.com> = wrote:

Hi,


On Tue, Sep 30, = 2014 at 1:55 PM, Thomas D. Nadeau <tnadeau@lucidvision.com> = wrote:
=
I = was discussing this very same issue here at the ODL Yangathon = yesterday.  Others are stumbling onto this same = issue.


Do= you mean you want control over the YANG to JSON mapping?
IMO, = YANG needs to be independent of the protocol message = encoding.
The implementation burden on servers is already too = high.
There should only be 1 mapping for each encoding = format.

How would you change YANG to get this = JSON = encoding?

That = isn't what I was getting at - the key-value pair representation was = asked about. It is a pain representing this as a = list.

= --Tom






= --Tom



Andy
 
Hi all,

A few of us are doing an exercise = of defining a YANG module to express the ALTO protocol (RFC7285). = Multiple problems come up and here is one problem we = encounter. 

First,= the context. A design decision of the ALTO protocol is to use key-value = stores (maps), which are different from lists or containers. Many = large-scale systems are designed based on key-value stores, and many = programming frameworks provide hash maps.

A = particular example of using key-value map is the network-map, which is = defined as a key-value store to enforce that each named endpoint address = group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt):

        =  "network-map" : {
           "PID1" : = {
      =        "ipv4" : [
            =    "192.0.2.0/24",
               "198.51.100.0/25"
            =  ]
    =        },
           "PID2" : = {
      =        "ipv4" : [
            =    "198.51.100.128/25"
            =  ]
    =        },
           "PID3" : = {
      =        "ipv4" : [
            =    "0.0.0.0/0"
            =  ],
    =          "ipv6" : [
            =    "::/0"
            =  ]
    =        }

One way to = express this in YANG is the following:
=3D=3D= =3Dexample YANG=3D=3D=3D
list = network-map {
 = key "pid";
 = leaf pid {
 =   type string;
 = }
 = leaf endpoint-address-group ... {
 =   // ...
 = }
}
=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Following the currently defined json encoding, the output will = be:
{
 = "network-map" : [
 =   {
 =     "pid" : "PID1",
 =      // ...
 =   },
 =   {
 =     "pid" : "PID2",
 =     // ...
 =   },
 =   {
 =     "pid" : "PID3",
 =     // ...
 =   }
 = ]
} 

But this not what we want, because it = is using an array, not a map. One does not have to use an array to store = the map.

We see two possibilities, if to = produce the output. One is in the encoding process: define such outputs on = matching a template:
<= font face=3D"arial, sans-serif">
list MyList {
  key x;
  leaf x {
    type string;
  }
  leaf y { 
   ...
  }
}

The second is that maybe this should be = resolved in YANG; i.e., introducing a new data type (beyond list, = container), but something like key-value store, say named = map:

map MyMap {
  key my-key {
    ...
  };
  value my-value {
  }
}

Note that the second mapping involves work if = the key type is not a simple type (say string or numbers). A typical = approach in some software framework is to define a hash function on = key. 

We have discussed the = issue with Lada, and now take the issue to the mailing list. If anyone = else has encountered similar problems, please let us know. We also want = to get a sense of any interest in introducing the data type in YANG. Any = comments will be = appreciated.

Thanks!

Ric= hard
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


_____________________________________________= __
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod



= --Apple-Mail=_E3CBC1A5-5D44-48B2-85A7-D5BB6DD896EF-- --Apple-Mail=_76DD145F-A893-41FC-A733-4A3DBBDBF532 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJUKyfmAAoJEPcO+I7eiUJZgQUP/2r4OIn2GGaVvUJ19SFoshIB M5qhfcUYYoABExRnfGDuW9aiFziOgtXSeZ4AC6qfkB1eHUTIppxIcX789je8ZcVM jMVu9JMyuPOdwEECVnFrKhydPhEb3tCj4/nqYIDDnBCuAdRhtoLAkeiGMZ3gdno8 pEznCScYrkd/gx6lFcXfNDpSZ4EnFImxqaFLLnNfxqDM46j2abu7tfQMUQbQt81y bXKjeGXcy79HQqW2f/qZKu6LXHh27s+3rh0u5EL9Ix/09r+1p83E8t7aq8bjQVXq nLrNam6mkhAfe2YWcB52hAN04SQ40xY+d/cSstHnDmG7iG7b8j1HFA8u+cXb/nbw 2nK996Y9mWUqwB/le2Jqsqi6sf3rGMlsnpyFhtQ4+g+c6g0p42CX0+AHHcF2EvxV SnzEK2sMBRqf8qcSN7QVIGMsu+NAfUqJ9fywMTmA66D50mm+OKsiQDS9dhCpZVWw ldOPtM480yr+2ZRDHmCH+bEe7JfkTa1f+kPNc/VhhZvDqvY4tYqdmCH1j68DFysC n2NTHM/1ot3oio2mKING0WWIvqtdel2Jfsxbm9jwYljF6IwPfgeBj3nS4q6RifeC Uxnsf4qFK2iZzjm8MGHu5Goe2qhO2bYW+wzlFX78Ky5+PzIYrKwe9O5ecBr9gfvL RqBthLHxZvCCbUG7Ci0g =VrCm -----END PGP SIGNATURE----- --Apple-Mail=_76DD145F-A893-41FC-A733-4A3DBBDBF532-- From nobody Tue Sep 30 18:37:46 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 476421ACD54; Tue, 30 Sep 2014 18:37:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NORMAL_HTTP_TO_IP=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 opSWXiDl24vV; Tue, 30 Sep 2014 18:37:39 -0700 (PDT) Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0105.outbound.protection.outlook.com [65.55.169.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6658E1ACD67; Tue, 30 Sep 2014 18:37:39 -0700 (PDT) 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.1039.15; Wed, 1 Oct 2014 01:37:36 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 01:37:36 +0000 From: Kent Watsen To: "Y. Richard Yang" , "netmod@ietf.org" Thread-Topic: [netmod] Key-value data structures in YANG/JSON encoding Thread-Index: AQHP3O19TPFlivkdt0aXryQhIzUulJwaAVgA Date: Wed, 1 Oct 2014 01:37:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.4.140807 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [66.129.239.14] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB459; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(6019001)(41574002)(53754006)(377454003)(199003)(189002)(15975445006)(10300001)(4396001)(50986999)(120916001)(76482002)(99936001)(15202345003)(101416001)(46102003)(97736003)(86362001)(64706001)(54356999)(66066001)(99396003)(19580395003)(2656002)(80022003)(106356001)(19580405001)(92726001)(76176999)(92566001)(105586002)(31966008)(107046002)(106116001)(77096002)(85306004)(95666004)(2501002)(21056001)(2171001)(20776003)(83506001)(87936001)(99286002)(36756003)(85852003)(16193025007); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB459; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; A:1; MX:1; LANG:en; Content-Type: multipart/mixed; boundary="_002_D050993D8364Ekwatsenjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/fyVgggLjSzKc6sYrp8X05Ze1BCk Cc: IETF ALTO Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:37:42 -0000 --_002_D050993D8364Ekwatsenjunipernet_ Content-Type: text/plain; charset="us-ascii" Content-ID: <9FEDB7C92D48DD419B036EEF876F707B@namprd05.prod.outlook.com> Content-Transfer-Encoding: quoted-printable >From a data-modeling perspective, it makes sense to be able to define maps. For instance, one can envision said information being used during code-generation for in-memory and persisted datastores. *If* it is not required that the JSON encoding be a JSON map, your yang module could create a derived type: typedef map { type list; } container network-map { map entry { key "pid"; leaf pid { type string; } leaf-list ipv4 { type inet:ipv4-prefix; } leaf-list ipv6 { type inet:ipv6-prefix; } } } I actually just tried this (see attached file), but pyang complains: pyang --strict alto-test.yang alto-test.yang:7: warning: imported module ietf-inet-types not used alto-test.yang:25: error: type "list" not found in module alto-test alto-test.yang:30: error: unexpected keyword "map" RFC 6020 doesn't limit which types can be used in a typedef statement, so this might be a bug in pyang... Kent =20 From: "Y. Richard Yang" Date: Tuesday, September 30, 2014 at 1:31 PM To: "netmod@ietf.org" Cc: IETF ALTO Subject: [netmod] Key-value data structures in YANG/JSON encoding Hi all, A few of us are doing an exercise of defining a YANG module to express the ALTO protocol (RFC7285). Multiple problems come up and here is one problem we encounter.=20 First, the context. A design decision of the ALTO protocol is to use key-value stores (maps), which are different from lists or containers. Many large-scale systems are designed based on key-value stores, and many programming frameworks provide hash maps. A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific example is in Section 11.2.1.7 of RFC 7285 (http://www.rfc-editor.org/rfc/rfc7285.txt): "network-map" : { "PID1" : { "ipv4" : [ "192.0.2.0/24 ", "198.51.100.0/25 " ] }, "PID2" : { "ipv4" : [ "198.51.100.128/25 " ] }, "PID3" : { "ipv4" : [ "0.0.0.0/0 " ], "ipv6" : [ "::/0" ] } One way to express this in YANG is the following: =3D=3D=3Dexample YANG=3D=3D=3D list network-map { key "pid"; leaf pid { type string; } leaf endpoint-address-group ... { // ... } } =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Following the currently defined json encoding, the output will be: { "network-map" : [ { "pid" : "PID1", // ... }, { "pid" : "PID2", // ... }, { "pid" : "PID3", // ... } ] }=20 But this not what we want, because it is using an array, not a map. One does not have to use an array to store the map. We see two possibilities, if to produce the output. One is in the encoding process: define such outputs on matching a template: list MyList { key x; leaf x { type string; } leaf y {=20 ... } } The second is that maybe this should be resolved in YANG; i.e., introducing a new data type (beyond list, container), but something like key-value store, say named map: map MyMap { key my-key { ... }; value my-value { } } Note that the second mapping involves work if the key type is not a simple type (say string or numbers). A typical approach in some software framework is to define a hash function on key. We have discussed the issue with Lada, and now take the issue to the mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the data type in YANG. Any comments will be appreciated. Thanks! Richard --_002_D050993D8364Ekwatsenjunipernet_ Content-Type: application/octet-stream; name="alto-test.yang" Content-Description: alto-test.yang Content-Disposition: attachment; filename="alto-test.yang"; size=724; creation-date="Wed, 01 Oct 2014 01:37:36 GMT"; modification-date="Wed, 01 Oct 2014 01:37:36 GMT" Content-ID: <4F91A7407D209D4AB7065FE54E2699F5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 bW9kdWxlIGFsdG8tdGVzdCB7CgogIHlhbmctdmVyc2lvbiAxOwogIG5hbWVzcGFjZSAiaHR0cDov L2Zvb2Jhci5jb20vYWx0by10ZXN0IjsKICBwcmVmaXggdG9hc3Q7CgogIGltcG9ydCBpZXRmLWlu ZXQtdHlwZXMgewogICAgIHByZWZpeCAiaW5ldCI7ICAgIAogIH0KCiAgb3JnYW5pemF0aW9uICJO ZXRjb25mIENlbnRyYWwiOwoKICBjb250YWN0CiAgICAiQW5keSBCaWVybWFuIDxhbmR5QG5ldGNv bmZjZW50cmFsLm9yZz4iOwoKICBkZXNjcmlwdGlvbgogICAgIllBTkcgdmVyc2lvbiBvZiB0aGUg VE9BU1RFUi1NSUIuIjsKCiAgcmV2aXNpb24gIjIwMDktMTEtMjAiIHsKICAgIGRlc2NyaXB0aW9u CiAgICAgICJUb2FzdGVyIG1vZHVsZSBpbiBwcm9ncmVzcy4iOwogIH0KCiAgdHlwZWRlZiBtYXAg ewogICAgICB0eXBlIGxpc3Q7CiAgfQoKICBjb250YWluZXIgYWx0by10ZXN0IHsKICAgIGNvbnRh aW5lciBuZXR3b3JrLW1hcCB7CiAgICAgIG1hcCBlbnRyeSB7CiAgICAgICAga2V5ICJwaWQiOwog ICAgICAgIGxlYWYgcGlkIHsKICAgICAgICAgIHR5cGUgc3RyaW5nOwogICAgICAgIH0KICAgICAg ICBsZWFmLWxpc3QgaXB2NCB7CiAgICAgICAgICB0eXBlIGluZXQ6aXB2NC1wcmVmaXg7CiAgICAg ICAgfQogICAgICAgIGxlYWYtbGlzdCBpcHY2IHsKICAgICAgICAgIHR5cGUgaW5ldDppcHY2LXBy ZWZpeDsKICAgICAgICB9CiAgICAgIH0KICAgIH0KICB9Cgp9CgoKCg== --_002_D050993D8364Ekwatsenjunipernet_-- From nobody Tue Sep 30 18:59:34 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E168B1A0056; Tue, 30 Sep 2014 18:59:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.376 X-Spam-Level: X-Spam-Status: No, score=-1.376 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, NORMAL_HTTP_TO_IP=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 OMryvIF7s_gg; Tue, 30 Sep 2014 18:59:29 -0700 (PDT) Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com [IPv6:2607:f8b0:4002:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A26991A0048; Tue, 30 Sep 2014 18:59:28 -0700 (PDT) Received: by mail-yh0-f51.google.com with SMTP id 29so56452yhl.24 for ; Tue, 30 Sep 2014 18:59:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tR6vxwt+U7TkmO6o59NIY0/UKkuVpNZtA9Zv3MyljWY=; b=vILjRC6oipJp161Thc4ZcJebizNLfvPx3XhLsNG1tlB/KwcvoX+9wSrFw4KjS0Z4hM aPwGAcjGkbMmWaeIBNoZB+kLl1HNEZi4c8HScGOgVvInSsO2hVGd/E52KfrF+z048AIB k5SXvbofZy8xZq9I4gpaqXW6znuiLVZU3ena1AETMpAxI40rbghWGC5QRBDKtZGnUKKa NDJBI6GuH7FoMHL9K2n1Pk/OX4L81qg68hJarOl0eKuZ4bcfA5/lnzWPddbYx+qblBZ+ uSk2i1YGFGuHVwqZV3IEbgITxfpt3dr9mAn1UXG92LtR0a7wYQ8cgNRi7NHUlE2jP6u0 aIzw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yale.edu; s=googleprd; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=tR6vxwt+U7TkmO6o59NIY0/UKkuVpNZtA9Zv3MyljWY=; b=uEyHK3ptgnjBrOxmDSs+W2NHjnChpkb+lTPpHC12CAXBQmsv9CtSNNPGvPfoDsfnuq e2yLSi/o4t+OgC1AqSzUu2suZ8eACyWIPHI7NHn3AGZNYBNgBwXqg9tqJ8IcH7b8b5TI uCNwP3bd2tP4KvaGa+/pFcZOEhw/eiJRFztKE= X-Received: by 10.236.160.100 with SMTP id t64mr71300367yhk.7.1412128767871; Tue, 30 Sep 2014 18:59:27 -0700 (PDT) MIME-Version: 1.0 Sender: boxs.jq@gmail.com Received: by 10.170.97.6 with HTTP; Tue, 30 Sep 2014 18:59:07 -0700 (PDT) In-Reply-To: References: From: Xiao SHI Date: Tue, 30 Sep 2014 21:59:07 -0400 X-Google-Sender-Auth: wa8yoibshLHcjfabYOxgfllO27Y Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=20cf30426d9e9613e5050452d937 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/8Z6h_n0MwdcoGI5I-nCFRt14V_E Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 01:59:31 -0000 --20cf30426d9e9613e5050452d937 Content-Type: text/plain; charset=UTF-8 Hi Kent, That's a viable solution, but I still have a few questions about it. In RFC6020 Sec. 7.4, the type statement takes an argument that's a built-in type or derived type (which are all based in built-in types), but in Sec. 4.2.4 Built-in types do not include "list." I think "list" is handled as a statement rather than a type in YANG. Regardless, it would require some extension in YANG to express the key-value structure. In addition, I do think it is important that the JSON representation is a JSON map object, which encodes what element the key is and also automatically enforces uniqueness. Cheers, Xiao On Tue, Sep 30, 2014 at 9:37 PM, Kent Watsen wrote: > > >From a data-modeling perspective, it makes sense to be able to define > maps. For instance, one can envision said information being used during > code-generation for in-memory and persisted datastores. > > *If* it is not required that the JSON encoding be a JSON map, your yang > module could create a derived type: > > typedef map { > type list; > } > > container network-map { > map entry { > key "pid"; > leaf pid { > type string; > } > leaf-list ipv4 { > type inet:ipv4-prefix; > } > leaf-list ipv6 { > type inet:ipv6-prefix; > } > } > } > > > > I actually just tried this (see attached file), but pyang complains: > > pyang --strict alto-test.yang > > alto-test.yang:7: warning: imported module ietf-inet-types not used > alto-test.yang:25: error: type "list" not found in module alto-test > alto-test.yang:30: error: unexpected keyword "map" > > > RFC 6020 doesn't limit which types can be used in a typedef statement, so > this might be a bug in pyang... > > > > Kent > > > > > > > > From: "Y. Richard Yang" > Date: Tuesday, September 30, 2014 at 1:31 PM > To: "netmod@ietf.org" > Cc: IETF ALTO > Subject: [netmod] Key-value data structures in YANG/JSON encoding > > > Hi all, > > A few of us are doing an exercise of defining a YANG module to express the > ALTO protocol (RFC7285). Multiple problems come up and here is one problem > we encounter. > > First, the context. A design decision of the ALTO protocol is to use > key-value stores (maps), which are different from lists or containers. > Many large-scale systems are designed based > on key-value stores, and many programming frameworks provide hash maps. > > > A particular example of using key-value map is the network-map, which is > defined as a key-value store to enforce that each named endpoint address > group has a unique name. A specific > example is in Section 11.2.1.7 of RFC 7285 > (http://www.rfc-editor.org/rfc/rfc7285.txt): > > "network-map" : { > "PID1" : { > "ipv4" : [ > "192.0.2.0/24 ", > "198.51.100.0/25 " > ] > }, > "PID2" : { > "ipv4" : [ > "198.51.100.128/25 " > ] > }, > "PID3" : { > "ipv4" : [ > "0.0.0.0/0 " > ], > "ipv6" : [ > "::/0" > ] > } > > One way to express this in YANG is the following: > ===example YANG=== > list network-map { > key "pid"; > leaf pid { > type string; > } > leaf endpoint-address-group ... { > // ... > } > } > ================== > > > Following the currently defined json encoding, the output will be: > { > "network-map" : [ > { > "pid" : "PID1", > // ... > }, > { > "pid" : "PID2", > // ... > }, > { > "pid" : "PID3", > // ... > } > ] > } > > But this not what we want, because it is using an array, not a map. One > does not have to use an array to store the map. > > We see two possibilities, if to produce the output. One is in the encoding > process: define such > outputs on matching a template: > > list MyList { > key x; > leaf x { > type string; > } > leaf y { > ... > } > } > > > The second is that maybe this should be resolved in YANG; i.e., > introducing a new data type (beyond list, container), but something like > key-value store, say > named map: > > map MyMap { > key my-key { > ... > }; > value my-value { > } > } > > Note that the second mapping involves work if the key type is not a simple > type (say string or numbers). A typical approach in some software > framework is to > define a hash function on key. > > > We have discussed the issue with Lada, and now take the issue to the > mailing list. If anyone else has encountered similar problems, please let > us know. We also want to get a sense of any interest in introducing the > data type in YANG. Any comments will > be appreciated. > > Thanks! > > Richard > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --20cf30426d9e9613e5050452d937 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Kent,

That's a viable solution, = but I still have a few questions about it.

In RFC6= 020 Sec. 7.4, the type statement takes an argument that's a built-in ty= pe or derived type (which are all based in built-in types), but in Sec. 4.2= .4 Built-in types do not include "list." I think "list"= is handled as a statement rather than a type in YANG. Regardless, it would= require some extension in YANG to express the key-value structure.

In addition, I do think it is important that the JSON rep= resentation is a JSON map object, which encodes what element the key is and= also automatically enforces uniqueness.

Cheers,
Xiao

On Tue, Sep 30, 2014 at 9:37 PM, Kent Watsen <= kwatsen@juniper.ne= t> wrote:

>From a data-modeling perspective, it makes sense to be able to define maps.=C2=A0 For instance, one can envision said information being used duri= ng
code-generation for in-memory and persisted datastores.

*If* it is not required that the JSON encoding be a JSON map, your yang
module could create a derived type:

=C2=A0 =C2=A0 typedef map {
=C2=A0 =C2=A0 =C2=A0 type list;
=C2=A0 =C2=A0 }

=C2=A0 =C2=A0 container network-map {
=C2=A0 =C2=A0 =C2=A0 map entry {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 key "pid";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf pid {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type string;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list ipv4 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type inet:ipv4-prefix;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf-list ipv6 {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 type inet:ipv6-prefix;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 }



I actually just tried this (see attached file), but pyang complains:

=C2=A0 pyang --strict alto-test.yang

=C2=A0 alto-test.yang:7: warning: imported module ietf-inet-types not used<= br> =C2=A0 alto-test.yang:25: error: type "list" not found in module = alto-test
=C2=A0 alto-test.yang:30: error: unexpected keyword "map"


RFC 6020 doesn't limit which types can be used in a typedef statement, = so
this might be a bug in pyang...



Kent







From:=C2=A0 "Y. Richard Yang" <yry@cs.yale.edu>
Date:=C2=A0 Tuesday, September 30, 2014 at 1:31 PM
To:=C2=A0 "netmod@ietf.org"= ; <netmod@ietf.org>
Cc:=C2=A0 IETF ALTO <alto@ietf.org&= gt;
Subject:=C2=A0 [netmod] Key-value data structures in YANG/JSON encoding


Hi all,

A few of us are doing an exercise of defining a YANG module to express the<= br> ALTO protocol (RFC7285). Multiple problems come up and here is one problem<= br> we encounter.

First, the context. A design decision of the ALTO protocol is to use
key-value stores (maps), which are different from lists or containers.
Many large-scale systems are designed based
=C2=A0on key-value stores, and many programming frameworks provide hash map= s.


A particular example of using key-value map is the network-map, which is defined as a key-value store to enforce that each named endpoint address group has a unique name. A specific
=C2=A0example is in Section 11.2.1.7 of RFC 7285
(ht= tp://www.rfc-editor.org/rfc/rfc7285.txt):

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"network-map" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID1" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"192.0.2.0/24 <http://192.0.2.0/24>", =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"198.51.100.0/25 <http://198.51.100.0/25>&quo= t;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID2" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"198.51.100.128/25 <http://198.51.100.128/25>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0},
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"PID3" : {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv4" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"0.0.0.0/0 <http://0.0.0.0/0>"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0],
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"ipv6" : [
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"::/0"
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}

One way to express this in YANG is the following:
=3D=3D=3Dexample YANG=3D=3D=3D
list network-map {
=C2=A0 key "pid";
=C2=A0 leaf pid {
=C2=A0 =C2=A0 type string;
=C2=A0 }
=C2=A0 leaf endpoint-address-group ... {
=C2=A0 =C2=A0 // ...
=C2=A0 }
}
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D


Following the currently defined json encoding, the output will be:
{
=C2=A0 "network-map" : [
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID1",
=C2=A0 =C2=A0 =C2=A0 =C2=A0// ...
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID2",
=C2=A0 =C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 },
=C2=A0 =C2=A0 {
=C2=A0 =C2=A0 =C2=A0 "pid" : "PID3",
=C2=A0 =C2=A0 =C2=A0 // ...
=C2=A0 =C2=A0 }
=C2=A0 ]
}

But this not what we want, because it is using an array, not a map. One
does not have to use an array to store the map.

We see two possibilities, if to produce the output. One is in the encoding<= br> process: define such
=C2=A0outputs on matching a template:

list MyList {
=C2=A0 key x;
=C2=A0 leaf x {
=C2=A0 =C2=A0 type string;
=C2=A0 }
=C2=A0 leaf y {
=C2=A0 =C2=A0...
=C2=A0 }
}


The second is that maybe this should be resolved in YANG; i.e.,
introducing a new data type (beyond list, container), but something like key-value store, say
=C2=A0named map:

map MyMap {
=C2=A0 key my-key {
=C2=A0 =C2=A0 ...
=C2=A0 };
=C2=A0 value my-value {
=C2=A0 }
}

Note that the second mapping involves work if the key type is not a simple<= br> type (say string or numbers). A typical approach in some software
framework is to
=C2=A0define a hash function on key.


We have discussed the issue with Lada, and now take the issue to the
mailing list. If anyone else has encountered similar problems, please let us know. We also want to get a sense of any interest in introducing the
data type in YANG. Any comments will
=C2=A0be appreciated.

Thanks!

Richard


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


--20cf30426d9e9613e5050452d937-- From nobody Tue Sep 30 19:31:50 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C67A91A007D; Tue, 30 Sep 2014 19:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 hWEr5gkWCcCJ; Tue, 30 Sep 2014 19:31:43 -0700 (PDT) Received: from na01-by2-obe.outbound.protection.outlook.com (mail-by2on0120.outbound.protection.outlook.com [207.46.100.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C0121A0081; Tue, 30 Sep 2014 19:31:43 -0700 (PDT) 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.1039.15; Wed, 1 Oct 2014 02:31:41 +0000 Received: from CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) by CO1PR05MB458.namprd05.prod.outlook.com ([169.254.10.194]) with mapi id 15.00.1039.011; Wed, 1 Oct 2014 02:31:41 +0000 From: Kent Watsen To: Xiao SHI Thread-Topic: [netmod] Key-value data structures in YANG/JSON encoding Thread-Index: AQHP3O19TPFlivkdt0aXryQhIzUulJwaAVgAgAB7XoCAAAkZZA== Date: Wed, 1 Oct 2014 02:31:40 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [166.170.38.213] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:CO1PR05MB460; x-forefront-prvs: 0351D213B3 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(164054003)(199003)(10300001)(2656002)(99396003)(80022003)(76482002)(92726001)(64706001)(33656002)(92566001)(46102003)(85852003)(2171001)(4396001)(83716003)(87936001)(85306004)(54356999)(50986999)(95666004)(101416001)(36756003)(99286002)(105586002)(106116001)(21056001)(97736003)(110136001)(82746002)(66066001)(20776003)(31966008)(107046002)(86362001)(76176999)(120916001)(106356001)(77096002)(104396001); DIR:OUT; SFP:1102; SCL:1; SRVR:CO1PR05MB460; H:CO1PR05MB458.namprd05.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: juniper.net Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/xsDYOoiqmKC0IZIqj5vffdCaMhM Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 02:31:45 -0000 > In RFC6020 Sec. 7.4, the type statement takes an argument that's a built-= in type or derived type (which are all based in built-in types), but in Sec= . 4.2.4 Built-in types do not include "list." > I think "list" is handled as a statement rather than a type in YANG. Ah, yes, that explains it - good catch. So a new statement would be needed= after all... Thanks, Kent= From nobody Tue Sep 30 19:37:16 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1433D1A0087; Tue, 30 Sep 2014 19:37:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.688 X-Spam-Level: X-Spam-Status: No, score=-2.688 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.786, SPF_HELO_PASS=-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 Dg8aI6s8h8k2; Tue, 30 Sep 2014 19:37:13 -0700 (PDT) Received: from lucidvision.com (lucidvision.com [72.71.250.34]) by ietfa.amsl.com (Postfix) with ESMTP id 31CA61A008F; Tue, 30 Sep 2014 19:37:12 -0700 (PDT) Received: from [10.228.143.65] (unknown [166.170.39.10]) by lucidvision.com (Postfix) with ESMTP id 605A428A9CDF; Tue, 30 Sep 2014 22:37:11 -0400 (EDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) From: Thomas Nadeau X-Mailer: iPhone Mail (12A405) In-Reply-To: Date: Tue, 30 Sep 2014 19:37:09 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Kent Watsen Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/4M187YkOVdBz8qdr2ph92nIebpU Cc: IETF ALTO , "netmod@ietf.org" Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 02:37:14 -0000 Please note this as an issue for a future version of yang.=20 Tom=20 > On Sep 30, 2014, at 7:31 PM, Kent Watsen wrote: >=20 >=20 >> In RFC6020 Sec. 7.4, the type statement takes an argument that's a built-= in type or derived type (which are all based in built-in types), but in Sec.= 4.2.4 Built-in types do not include "list." >> I think "list" is handled as a statement rather than a type in YANG. >=20 > Ah, yes, that explains it - good catch. So a new statement would be neede= d after all... >=20 > Thanks, > Kent > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 From nobody Tue Sep 30 20:23:26 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE51A00E1; Tue, 30 Sep 2014 20:23:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l282Cke2OhOX; Tue, 30 Sep 2014 20:23:22 -0700 (PDT) Received: from elasmtp-spurfowl.atl.sa.earthlink.net (elasmtp-spurfowl.atl.sa.earthlink.net [209.86.89.66]) by ietfa.amsl.com (Postfix) with ESMTP id 1B3A71A00D0; Tue, 30 Sep 2014 20:23:21 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=dk20050327; d=mindspring.com; b=QEw9YP6n1Fu1jlEz6UCMgcNOtuVJhiDYHEwy1oEkdvtImZrfLzGexSYeUeUF3z6M; h=Message-ID:Date:From:Reply-To:To:Subject:Cc:Mime-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:X-ELNK-Trace:X-Originating-IP; Received: from [209.86.224.30] (helo=mswamui-chipeau.atl.sa.earthlink.net) by elasmtp-spurfowl.atl.sa.earthlink.net with esmtpa (Exim 4.67) (envelope-from ) id 1XZAVc-0003Ol-P6; Tue, 30 Sep 2014 23:23:20 -0400 Received: from 76.254.52.49 by webmail.earthlink.net with HTTP; Tue, 30 Sep 2014 23:23:20 -0400 Message-ID: <6882466.1412133800694.JavaMail.root@mswamui-chipeau.atl.sa.earthlink.net> Date: Tue, 30 Sep 2014 20:23:20 -0700 (GMT-07:00) From: Randy Presuhn To: "Y. Richard Yang" Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-ELNK-Trace: 4488c18417c9426da92b9037bc8bcf44d4c20f6b8d69d88825aa8a2065c9591f3c8a8a29ec0a8ddb21a0b3208149454d350badd9bab72f9c350badd9bab72f9c X-Originating-IP: 209.86.224.30 Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/wH_o0UNc7sP457j_DX9Xy9Etvpk Cc: IETF ALTO , netmod@ietf.org Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Randy Presuhn List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 03:23:24 -0000 Hi - >From: "Y. Richard Yang" >Sent: Sep 30, 2014 2:48 PM >To: Andy Bierman >Cc: IETF ALTO , netmod@ietf.org >Subject: Re: [netmod] Key-value data structures in YANG/JSON encoding ... >more general issue regarding completeness of data types in YANG: > >- list is an ordered array > >- container is a static, heterogeneous associate array ... Why do you say "static"? Randy From nobody Tue Sep 30 23:48:40 2014 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 669201A01F9 for ; Tue, 30 Sep 2014 23:48:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.437 X-Spam-Level: X-Spam-Status: No, score=-1.437 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.786] 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 VIzbfpMeeHdy for ; Tue, 30 Sep 2014 23:48:37 -0700 (PDT) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CE661A008A for ; Tue, 30 Sep 2014 23:48:37 -0700 (PDT) Received: from [172.29.2.201] (unknown [77.48.225.7]) by mail.nic.cz (Postfix) with ESMTPSA id E69821405A3; Wed, 1 Oct 2014 08:48:35 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nic.cz; s=default; t=1412146116; bh=qGBZkjjJ/ZPwmQWtijB8O8lW0Ya6JYpaT9TyjxNfRMg=; h=Content-Type:Mime-Version:Subject:From:In-Reply-To:Date:Cc: Content-Transfer-Encoding:Message-Id:References:To; b=pmhnJ3xOOrApbmbHUryaqcUUymi2LCFbdONzhTPGXplIwU2rluP+Fj3zs5PyOiD3j 1besCbV0huEw6M3qh0n5Wr3jCL9H58ZDf6KCd8/xV+HjoYb/Jc1ZsnkYmf58vm/cZN /rwlSuuD5q1tgEgh+1gKdhqU8G6hFzAatw78Q/rA= Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Ladislav Lhotka In-Reply-To: <150D2166-A756-4F15-BA01-3E9B578E338D@juniper.net> Date: Wed, 1 Oct 2014 08:48:35 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <36E697B1-910A-4645-8AEA-525B164E90B6@nic.cz> References: <167EE31C-1B19-42AD-9215-A140D23599F9@juniper.net> <6152915A-4E26-4238-B657-5BAD732AFB20@nic.cz> <150D2166-A756-4F15-BA01-3E9B578E338D@juniper.net> To: Dean Bogdanovic X-Mailer: Apple Mail (2.1878.6) X-Virus-Scanned: clamav-milter 0.98.1 at mail X-Virus-Status: Clean Archived-At: http://mailarchive.ietf.org/arch/msg/netmod/6mElCtag07HHN3aglUzqRRxiIc0 Cc: "netmod@ietf.org" Subject: Re: [netmod] Comparing address families in must statement X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Oct 2014 06:48:39 -0000 On 30 Sep 2014, at 20:47, Dean Bogdanovic wrote: > Lada, >=20 > Thank you for the reply. Re-match function would be nice to have, but = as it is not coming, will model it differently. Oh, the fact that Martin=92s draft has expired doesn=92t mean these new = XPath functions are gone - they should appear in YANG 1.1, see issue = Y20: https://svn.tools.ietf.org/svn/wg/netmod/yang-1.1/issues.html#sec-20 However, you have to use YANG 1.0 for the time being anyway. Lada > =20 >=20 > Dean >=20 > On Sep 30, 2014, at 11:27 AM, Ladislav Lhotka wrote: >=20 >> Hi Dean, >>=20 >> On 30 Sep 2014, at 17:05, Dean Bogdanovic wrote: >>=20 >>> Hi, >>>=20 >>> I'm trying to figure out a must statement, where entries have to be = in the same address family. Here is the example below >>=20 >> Such a constraint is used in the ietf-routing module, see the = definition of =93default-rib=94. I am not sure though that this is what = you want. >>=20 >>>=20 >>> import ietf-inet-types { >>> prefix "types"; =20 >>> } >>>=20 >>> import ietf-acl { >>> prefix "ietf-acl"; >>> } >>>=20 >>> augment = "/ietf-acl:access-list/ietf-acl:access-list-entries/ietf-acl:matches" { >>> choice route-prefix{ >>> description "Define route filter match criteria"; >>> case range { >>> container range { >>> leaf lower_bound { >>> type types:ip-prefix; >>> mandatory true; >>> } >>> leaf upper_bound { >>> type types:ip-prefix; >>> must "if lower_bound address family current() !=3D = upper_bound address family" >>> error-message "The upper_bound value has to be the same = address family as lower_bound" >>> mandatory true; >>> } >>> } >>> } >>> } >>>=20 >>> Trying to find out if there is ability to extract the pattern = constraints from a type and then apply it. Or something like = type.pattern() so something like ip:ip-prefix.pattern(current()) >>=20 >> One of the XPath extension functions proposed for YANG 1.1 is = re-match, see the expired draft >>=20 >> = http://tools.ietf.org/html/draft-bjorklund-netmod-yang-xpath-extensions-00= #section-4.5 >>=20 >> I am not sure why you need to extract type patterns and apply them in = XPath expressions but this in not possible in YANG 1.0 and won=92t be in = 1.1 either. >>=20 >> Lada >>=20 >>>=20 >>> thx >>>=20 >>> Dean >>>=20 >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >>=20 >>=20 >>=20 >>=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C