From nobody Wed Jan 4 08:31:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EEF8129958 for ; Wed, 4 Jan 2017 08:31:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFrdPTyyJEhY for ; Wed, 4 Jan 2017 08:31:05 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89957129615 for ; Wed, 4 Jan 2017 08:31:05 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id u144so109466907wmu.1 for ; Wed, 04 Jan 2017 08:31:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-transfer-encoding:thread-index:content-language :disposition-notification-to; bh=JIPNUIsXceQFYp6uwDRX0WiPQQr4XqDHrdbHIieZRXU=; b=BvkL5oP5gZA5CjfpI7qITkHJAJ69FIcsQ+97gm7FhqimYMBFLLQM0gv1Kt8BXOMYC7 8qgWP/fvkI8ddlSNYywlV0oAhWSk2ToENtg3XFnr7kORgJEZ5b7TY4sSPv6662sf+Da+ sq5FC3JhGSaU4o4Ajb2iuqQxgjqtNc00nw/sIvt4E5NfPQy0PQnzcQfKbOtrcI9UAsy2 +UfV8lp6DE7xuC7h9JVc12C6AIzgv97+Y8x8TCJKB7NcjznJYzLH8QEBvXOBPtEma3wM BwNbxRUNM3HkvEEDlkgPdX2Z0/KAs6SVGZMe1WZF3XbI65nk5b6cEbAQoRA1myG0bA9L XSig== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=JIPNUIsXceQFYp6uwDRX0WiPQQr4XqDHrdbHIieZRXU=; b=QSRa65FNfWFIcsDP2VRxnuzxr/VHtSefzmw5RkXot6Y4ZQ0giAo1WhbY4N2fv3Ywav J0eSVxKHZFHXnHtWlGqio0v7mCnMh7ykWmhRPjp4shBgKV4fAnrBowbjMljJkO+8dn+d 31DJkPfl6asWsNpokdIQMhsixRILb8P8lfHrQCdgcShss1yQWbtpgLEQF+o9O0mX2fVe VQqYZFxmvFD2WBQ8CciARPiJIs2CmSOUWCP4QsW2dl7CxJUQ/aHOl999gUtZkziqw487 +SfIohyQPo0W0czd9W8YEa2otmAcJDaucJcNxtQSja/mTbgH0/5jmPfLlGSEnvbdgTYn tWoQ== X-Gm-Message-State: AIkVDXIymuVVzbjh+k5ZQ8vO9YpxO49d8WZrKoWM110qwXIbMDAnufxy/9FYpyJW4+YSTA== X-Received: by 10.28.209.7 with SMTP id i7mr62802447wmg.62.1483547463803; Wed, 04 Jan 2017 08:31:03 -0800 (PST) Received: from DESKTOPFLHJVQJ ([93.204.104.25]) by smtp.gmail.com with ESMTPSA id ef10sm99039942wjd.22.2017.01.04.08.31.02 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Jan 2017 08:31:03 -0800 (PST) From: "Mehmet Ersue" To: "'Netconf'" References: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> In-Reply-To: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> Date: Wed, 4 Jan 2017 17:30:52 +0100 Message-ID: <027901d266a7$f06be4a0$d143ade0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQI7shXjy7Pc9y+6GF+ynJ5egGwA+aBV6mmw Content-Language: de X-AVK-Virus-Check: AVA 25.9819;2DC73FAF X-AVK-Spam-Check: 1; str=0001.0A0C0205.586D2347.0089,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jan 2017 16:31:07 -0000 Dear All, we assume now the WG support for the adoption of draft-bierman-netconf-rfc6536bis. Authors please submit as draft-ietf-netconf-rfc6536bis-00. Thanks. Mehmet & Mahesh -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mehmet Ersue Sent: Wednesday, December 14, 2016 10:20 PM To: 'Netconf' Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft Dear NETCONF WG, for the potential topics to add we only got comments from Martin. We assume now there are no other comments. This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis to adopt as NETCONF WG item. Please state your opinion on the mail list by December 30, 2016 with "yes/support" or "no support". If you support, please let us know what you would like to address additionally. If you don't support, please elaborate your reasons. Thank you, Mehmet & Mahesh -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Wednesday, December 7, 2016 9:20 AM To: mersue@gmail.com Cc: andy@yumaworks.com; netconf@ietf.org Subject: Re: [Netconf] new NACM draft MehmetErsue > wrote: > Hi Andy, Martin, > > thank you for the initial draft. > > We discussed in IETF 97 different issues and the additional sections > we could add. Ok. But do we have to resolve all issues before adopting this document? I think the current document is ready for adoption, and then the WG can work on fixing any open issues. > IIRC the list was: > - schema-mount related text into schema-mount or the NACM draft, I think schema mount needs to discuss how it works with NACM. This should be an open issue in schema mount. > - assigning priorities to clients, I don't believe this is a NACM issue. > - access control on dynamic datastores (e.g. I2RS), The text in 3.2 probably need to be relaxed a bit to allow NACM to be applied to other datastores. > - the issue from RFC 6536 with parent/child relationships which is > important for RESTCONF. Can you elaborate on this? /martin > > I would like to suggest to have a discussion on these issues and > understand whether they should be included. > > Mehmet > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > Hi, > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > We would like this draft to be adopted as the starting point for > > item #5 in the current NETCONF charter. > > > > > > > > Andy and Martin > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > -- > Cheers, > Mehmet _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jan 5 10:26:48 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5A6AC129A08 for ; Thu, 5 Jan 2017 10:26:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id POBehYLppoxR for ; Thu, 5 Jan 2017 10:26:46 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE90C1294EA for ; Thu, 5 Jan 2017 10:26:45 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id l7so9211414qtd.1 for ; Thu, 05 Jan 2017 10:26:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/4xQYvxDz6axN+MlpBTXshC5zKKuJEjU4imT7pTwhtA=; b=t5efwlPVlBaP9kEsIMBd3KAPNI5naYh7WO7gTT8GLZ4kP5vW8pzs+Qfvdxp4KmyvTG k6Qit9AOPP34JM6UipgR93WYyVtr2TCw3UZ0LbAaE9rBFOlBYFwxqPkO34/fc8zirCTq 1i0pWUllQXPnew3wyTOEuig0VC3kWGqU4r6zRoCVWNwK+6FeBolbC7P2XLeMxpHWKwkM rgYtspneUme2aa+XOiy9YI/AB7lMFgjZqcAUw1QPWhmIgddQEPj2CAnXBlI7yKdaCONQ MMRZ6OdN8mOR3Ns2bpfJCTIpD/cvQDjjelcfEgJMxsNc51n8JeIfQiCJoROcdFwVOPQT D+iA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/4xQYvxDz6axN+MlpBTXshC5zKKuJEjU4imT7pTwhtA=; b=apUteabcuCVvIzxTXMWp6Wy8dGyf8ke+zTFmCY+gQj2X2vJ3DrIgOjbJrYzB39JoUz fY9HvJHMfzdcuJnXhwTvCI051JGPdq3zCzA0RUJdIUZFvQps5pLU7Sp2/ua1xW4Prk1k PORD5VdNtpxw4RtQ6dH/wxiPu6c8GyPSFoKvblXghlDDF1TMRoItjIk7EWkhIRljgJMe y37Zamzb8vtKq7IT0AJRFiWTixlHqF96e3a66GODE4rF1Gbzl42Kkg1P03nTMPXsc71F CLXBLX7M2a160fhSKLlnKKsZ6MRvtJjRcCdsy7owKuPSuyHXDOhs223yZsNBJZMxGcou Tdcg== X-Gm-Message-State: AIkVDXKuS6mDkodX60uQYxfrkWqFtQgN0SQ+X1sQ+Ngg5mmtr6A3CMPbXpG9Ky2MCD/HXyuzefBr97F5bXDCEA== X-Received: by 10.237.57.137 with SMTP id m9mr72259912qte.35.1483640805033; Thu, 05 Jan 2017 10:26:45 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Thu, 5 Jan 2017 10:26:44 -0800 (PST) In-Reply-To: <027901d266a7$f06be4a0$d143ade0$@gmail.com> References: <03ce01d2564f$d3c23150$7b4693f0$@gmail.com> <027901d266a7$f06be4a0$d143ade0$@gmail.com> From: Andy Bierman Date: Thu, 5 Jan 2017 10:26:44 -0800 Message-ID: To: Mehmet Ersue Content-Type: multipart/alternative; boundary=001a11410e62289fc905455d0be4 Archived-At: Cc: Netconf Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 18:26:48 -0000 --001a11410e62289fc905455d0be4 Content-Type: text/plain; charset=UTF-8 On Wed, Jan 4, 2017 at 8:30 AM, Mehmet Ersue wrote: > Dear All, > > we assume now the WG support for the adoption of > draft-bierman-netconf-rfc6536bis. > Authors please submit as draft-ietf-netconf-rfc6536bis-00. Thanks. > > done > Mehmet & Mahesh > Andy > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mehmet Ersue > Sent: Wednesday, December 14, 2016 10:20 PM > To: 'Netconf' > Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis > WAS:FW: new NACM draft > > Dear NETCONF WG, > > for the potential topics to add we only got comments from Martin. We assume > now there are no other comments. > > This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis to > adopt as NETCONF WG item. > > Please state your opinion on the mail list by December 30, 2016 with > "yes/support" or "no support". > > If you support, please let us know what you would like to address > additionally. > If you don't support, please elaborate your reasons. > > Thank you, > Mehmet & Mahesh > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, December 7, 2016 9:20 AM > To: mersue@gmail.com > Cc: andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] new NACM draft > > MehmetErsue > wrote: > > Hi Andy, Martin, > > > > thank you for the initial draft. > > > > We discussed in IETF 97 different issues and the additional sections > > we could add. > > Ok. But do we have to resolve all issues before adopting this document? I > think the current document is ready for adoption, and then the WG can work > on fixing any open issues. > > > IIRC the list was: > > - schema-mount related text into schema-mount or the NACM draft, > > I think schema mount needs to discuss how it works with NACM. This should > be an open issue in schema mount. > > > - assigning priorities to clients, > > I don't believe this is a NACM issue. > > > - access control on dynamic datastores (e.g. I2RS), > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > applied to other datastores. > > > - the issue from RFC 6536 with parent/child relationships which is > > important for RESTCONF. > > Can you elaborate on this? > > > /martin > > > > > > > I would like to suggest to have a discussion on these issues and > > understand whether they should be included. > > > > Mehmet > > > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > > > Hi, > > > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > > > > We would like this draft to be adopted as the starting point for > > > item #5 in the current NETCONF charter. > > > > > > > > > > > > Andy and Martin > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > Cheers, > > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a11410e62289fc905455d0be4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 4, 2017 at 8:30 AM, Mehmet Ersue <mersue@gmail.com><= /span> wrote:
Dear All,

we assume now the WG support for the adoption of
draft-bierman-netconf-rfc6536bis.
Authors please submit as draft-ietf-netconf-rfc6536bis-00. Thanks.


done

=C2=A0
Mehmet & Mahesh


Andy=
=C2=A0

-----Original Message-----
From: Netconf [mailto:netconf-b= ounces@ietf.org] On Behalf Of Mehmet Ersue
Sent: Wednesday, December 14, 2016 10:20 PM
To: 'Netconf' <netconf@ietf.= org>
Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536b= is
WAS:FW: new NACM draft

Dear NETCONF WG,

for the potential topics to add we only got comments from Martin. We assume=
now there are no other comments.

This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bi= s to
adopt as NETCONF WG item.

Please state your opinion on the mail list by December 30, 2016 with
"yes/support" or "no support".

If you support, please let us know what you would like to address
additionally.
If you don't support, please elaborate your reasons.

Thank you,
Mehmet & Mahesh


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f= .com]
Sent: Wednesday, December 7, 2016 9:20 AM
To: mersue@gmail.com
Cc: andy@yumaworks.com; netconf@ietf.org
Subject: Re: [Netconf] new NACM draft

MehmetErsue <mersue@gmail.com &l= t;mailto:mersue@gmail.com> > = wrote:
> Hi Andy, Martin,
>
> thank you for the initial draft.
>
> We discussed in IETF 97 different issues and the additional sections > we could add.

Ok.=C2=A0 But do we have to resolve all issues before adopting this documen= t?=C2=A0 I
think the current document is ready for adoption, and then the WG can work<= br> on fixing any open issues.

> IIRC the list was:
> - schema-mount related text into schema-mount or the NACM draft,

I think schema mount needs to discuss how it works with NACM.=C2=A0 This sh= ould
be an open issue in schema mount.

> - assigning priorities to clients,

I don't believe this is a NACM issue.

> - access control on dynamic datastores (e.g. I2RS),

The text in 3.2 probably need to be relaxed a bit to allow NACM to be
applied to other datastores.

> - the issue from RFC 6536 with parent/child relationships which is
> important for RESTCONF.

Can you elaborate on this?


/martin



>
> I would like to suggest to have a discussion on these issues and
> understand whether they should be included.
>
> Mehmet
>
> On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman <andy@yumaworks.com
<mailto:andy@yumaworks.com>= > wrote:
>
> > Hi,
> >
> > A new version of draft-bierman-netconf-rfc6536bis has been p= osted:
> > https://www.ietf.org/id/dra= ft-bierman-netconf-rfc6536bis-01.txt
> >
> >
> > We would like this draft to be adopted as the starting point for<= br> > > item #5 in the current NETCONF charter.
> >
> >
> >
> > Andy and Martin
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org <mail= to:Netconf@ietf.org>
> > https://www.ietf.org/mailman/listinfo/ne= tconf
> >
> >
>
>
> --
> Cheers,
> Mehmet

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

--001a11410e62289fc905455d0be4-- From nobody Thu Jan 5 12:08:37 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 026A1129574; Thu, 5 Jan 2017 12:08:36 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148364691597.20611.11287756431422600842.idtracker@ietfa.amsl.com> Date: Thu, 05 Jan 2017 12:08:35 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-rfc6536bis-00.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 20:08:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Network Configuration Protocol (NETCONF) Access Control Model Authors : Andy Bierman Martin Bjorklund Filename : draft-ietf-netconf-rfc6536bis-00.txt Pages : 52 Date : 2017-01-05 Abstract: The standardization of network configuration interfaces for use with the Network Configuration Protocol (NETCONF) or RESTCONF protocol requires a structured and secure operating environment that promotes human usability and multi-vendor interoperability. There is a need for standard mechanisms to restrict NETCONF or RESTCONF protocol access for particular users to a pre-configured subset of all available NETCONF or RESTCONF protocol operations and content. This document defines such an access control model. This document obsoletes RFC 6536. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-rfc6536bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-rfc6536bis-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Jan 5 14:24:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15C6B1296D3 for ; Thu, 5 Jan 2017 14:24:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PWaD1Vzle7V6 for ; Thu, 5 Jan 2017 14:24:41 -0800 (PST) Received: from mail-qt0-x22f.google.com (mail-qt0-x22f.google.com [IPv6:2607:f8b0:400d:c0d::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C7A01296D4 for ; Thu, 5 Jan 2017 14:24:41 -0800 (PST) Received: by mail-qt0-x22f.google.com with SMTP id l7so14901035qtd.1 for ; Thu, 05 Jan 2017 14:24:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=tix8oD6Srkahm9DqE+7QnRFKzmVeZC/gEotC/geP/1s=; b=Pkz542XCz0Cu7U8BBa+VwUdZFW4vQG+A+SmOQ2kwG62gGdiBy809ofRkOvuScGbCx9 xsSwMtm/64+Z1yEA24Fex0FxYB1+lsk0j0Bl5zyKV5kTYkpz7cpJSTqQSttW0IHAvmkC VmZ6tu93NMsjVsBLFIAdhI+Y8BuqaGX57yldfjf5DdrVnHHlY+/e/JtpTV+idnKXhBI+ k3aSXlHDnOZpTMvf544KuPoB1iWlLyowcAJhWn4hJlk++qgS1jyJdUoVA/+3ycdeco1j T6KhCUC6GjijmgmtMaLgO0ZhRTuZPvs/zI9vxNpaN+b0HkRViWmoGpGiEsi5vVgFr7yd rKYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=tix8oD6Srkahm9DqE+7QnRFKzmVeZC/gEotC/geP/1s=; b=ZJpwHGc3ENvxfjeDCkaSYdp8gAYiQQf24RUwF/BHHp9oaQjpuAScHQZd3kRAOzflvx gYNsDWYMYXmvZBuhUGLSUGKeqLy1AADvNpfjheYfJJiJtdc+wVxnoi5AjdmPkiYICTIu eUdnGROy5KqxhDvFg9RJKuti2GNgR9hCVrCKj6hUhIGpKd2MhAHZ0gYnAhpzYhpplNqo iMMSEtmCZeJQMKYrVV5KXiG9BngPdCWLcwlg76obTwPkmwslew/SFuKON14vJCjQ+wv7 3QnRoML4vm6CXG6oAliQqGisM+Qec59EO0fu+62aofcCOIRCpRVKEEQ7lGK90uhdhI4e ShXw== X-Gm-Message-State: AIkVDXI3X2eq311hwvoiQA9AdOE6TqA+GGLR2K2+TICESIn8/CJ2il9rIqjAKc9KXMwwwmTGJ7Ss0SAwY5k+Tw== X-Received: by 10.200.40.245 with SMTP id j50mr4476649qtj.72.1483655079990; Thu, 05 Jan 2017 14:24:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Thu, 5 Jan 2017 14:24:39 -0800 (PST) From: Andy Bierman Date: Thu, 5 Jan 2017 14:24:39 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a1146f7620336190545605ef5 Archived-At: Subject: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jan 2017 22:24:44 -0000 --001a1146f7620336190545605ef5 Content-Type: text/plain; charset=UTF-8 Hi, I would like some text in RFC 7950 to be reinterpreted. The text implies each notification message can only describe 1 instance of 1 event type. RFC 7950, sec 7.16.2 The innermost container or list contains an XML element that carries the name of the defined notification. There are 3 corner-cases that should be considered in order to minimize network overhead for notifications in 5277bis. Replicating the node/key hierarchy could be expensive and events occurring at the same time could be correlated. Duplicating the notification messages is inefficient, but processing multiple events per message makes filtering and parsing more complicated. I am curious if the WG thinks notification overhead is a concern and if it needs to be addressed somehow in 5277bis. 1) multiple non-sibling events in same subtree * * * 42* * * eth0 * * * auto* * * 2) multiple sibling events in the same subtree eth0 * * * auto* * * * * * admin* * * 3) multiple non-sibling events in different subtrees * * * 42* * * eth0 * * * auto* * * Andy --001a1146f7620336190545605ef5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I would like some text in RFC 7950 = to be reinterpreted. The text implies each
notification message c= an only describe 1 instance of 1 event type.

RFC 7= 950, sec 7.16.2

   The innermost container or list contains an XML
   element that carries the name of the defined notification.


There are = 3 corner-cases that should be considered in order
to minimize network ov= erhead for notifications in 5277bis.
Replicating the node/key hierarchy = could be expensive
and events occurring at the same time could be correl= ated.

Duplicating the notification messages is ine= fficient,
but processing multiple events per message makes
<= div>filtering and parsing more complicated.

I am c= urious if the WG thinks notification overhead is a concern and
if= it needs to be addressed somehow in 5277bis.


1) multiple non-sibling ev=
ents in same subtree

  <notification>
    <interfaces>
      <my-top-event>
        <my-data&g=
t;42</my-data>
      </my-top-event>
      <interface>
        <name>eth0=
</name>
        <my-interface-event>
              <if-data>auto</if-data>=
;
      </interface>
    </interfaces>
  </notifi=
cation>
=


2) multiple sibling events in the same subt=
ree

  <notification>
    <interfaces>
      <interface>
        <name>eth0</name>
        <my-interface-event>
              <if-data>auto</if-dat=
a>
        =
</my-interface-event>
        <interface-enabled>
           <by-user>admin</by-user>
        </interface-enabl=
ed>  
      </inte=
rface>
    </interface=
s>
  </notification>=
;


3) multiple non-sibling e=
vents in different subtrees

  <notification>
    <system>
=
      <my-system-event>
            <my-data>42</my-data>
      </my-system-event>
=

    </system>
    <interfaces=
>
      =
<interface>
        <name>eth0</name>
        <my-interface-event>=

              <=
;if-data>auto</if-data>
        </my-interface-event>=

      <=
/interface>
    </interfaces>
  </notification>



Andy

--001a1146f7620336190545605ef5-- From nobody Thu Jan 5 17:16:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDB9A129477 for ; Thu, 5 Jan 2017 17:16:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.621 X-Spam-Level: X-Spam-Status: No, score=-17.621 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WpRulEcBpnK5 for ; Thu, 5 Jan 2017 17:16:53 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C61A8129479 for ; Thu, 5 Jan 2017 17:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=26820; q=dns/txt; s=iport; t=1483665412; x=1484875012; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=oNXXf2EgYAoBkcmvKHbWhzTcXYaaOm2n2lZqaPkVPvg=; b=Mw4EkkwNScXl2HmCMiSBcmuOfUISEjg8TOWtOKM2JtFPe/3rPjYttxBr xveCEkjlAZ1Gpstfk02AoRnRKTvQzgO9HSiMNWSsaPWS/R9kMtVobr437 JiO69LrOGtz5lHnEIgkbHDOBPOaVLYQytziP6uL/tbcglKI/YKhAGwjau s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCm725Y/4MNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnFHAQEBAQEfX4EMB41QlEWVJoIJgmyDNgIagTM/FAECAQEBAQE?= =?us-ascii?q?BAWMohGgBAQEEIwo6EBICAQgRBAEBIQcDAgICMBQJCAIEARIIiGivbYIlihoBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEdhkWEYYR8glKCXgWPE4t9AYlph1GQY5JGAR8?= =?us-ascii?q?4NYEGFTOGI3OHWYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,323,1477958400"; d="scan'208,217";a="189100483" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2017 01:16:34 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v061GXAZ002493 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 01:16:34 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 5 Jan 2017 20:16:33 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 5 Jan 2017 20:16:32 -0500 From: "Eric Voit (evoit)" To: Andy Bierman , Netconf Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KI87NiViNDDkG9WNSE0h61kKEqeKNA Date: Fri, 6 Jan 2017 01:16:32 +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: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_e8007d23234a4c8aba08c4a44178c091XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 01:16:55 -0000 --_000_e8007d23234a4c8aba08c4a44178c091XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0K4oCcVGhlIGlubmVybW9zdCBjb250YWluZXIgb3IgbGlzdOKAnSB0ZXh0IGlz IHNpbWlsYXIgdG8gdGhhdCBmb3IgYWN0aW9ucyBpbiBzZWN0aW9uIDcuMTUuMi4gICBQZXJoYXBz IHRoZSBtZW50YWwgbW9kZWwgb2Ygb25lIHRhcmdldCBmb3IgYW4gYWN0aW9uIHdhcyByZXBsaWNh dGVkPw0KDQpJIGhhZCBub3QgY29uc2lkZXJlZCB0aGF0IFlBTkcgMS4x4oCZcyBkZWZpbml0aW9u IG1pZ2h0IGZvcmNlIHRoZSBicmVha3VwIG9mIGEgdmVyYm9zZSBzb2Z0d2FyZSBjb21wb25lbnQg Z2VuZXJhdGVkIG5vdGlmaWNhdGlvbiBpbnRvIG11bHRpcGxlIHB1c2hlZCBub3RpZmljYXRpb24g bWVzc2FnZXMuICBMb29raW5nIGF0IHRoZSB0aHJlZSBjYXNlcyBiZWxvdywgSSBkb27igJl0IHRo aW5rIHRoYXQgYXJiaXRyYXJ5IGNob2ljZXMgbWFkZSBpbiBZQU5HIG1vZGVsIHN0cnVjdHVyZSBz aG91bGQgaW1wYWN0IHdoYXQgY291bGQgb3IgY291bGRu4oCZdCBiZSBpbiBlbmNvZGVkIHdpdGhp biBhbnkgc2luZ2xlIG5vdGlmaWNhdGlvbi4gIFNvIG15IHByZWZlcmVuY2Ugd291bGQgYmUgdGhh dCBhbGwgdGhyZWUgdmFyaWFudHMgYmVsb3cgc2hvdWxkIHN1cHBvcnRhYmxlIGlmIHRoYXQgaXMg aG93IHRoZSBzeXN0ZW0gcGFzc2VkIHRoZW0gdG8gYmUgZW5jb2RlZCBhcyBwYXJ0IG9mIGFuIGV2 ZW50Lg0KDQpXaGF0IGlmIHRoZSByZWludGVycHJldGF0aW9uIHdlcmUgYXMgc2ltcGxlIGFzIOKA nEFuIGlubmVybW9zdOKAnSBvciDigJxUaGUgZmlyc3QgaW5uZXJtb3N04oCdPw0KDQpFcmljDQoN CkZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFs ZiBPZiBBbmR5IEJpZXJtYW4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcgNToyNSBQ TQ0KVG86IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbTmV0Y29uZl0gbmVz dGVkIG5vdGlmaWNhdGlvbnMNCg0KSGksDQoNCkkgd291bGQgbGlrZSBzb21lIHRleHQgaW4gUkZD IDc5NTAgdG8gYmUgcmVpbnRlcnByZXRlZC4gVGhlIHRleHQgaW1wbGllcyBlYWNoDQpub3RpZmlj YXRpb24gbWVzc2FnZSBjYW4gb25seSBkZXNjcmliZSAxIGluc3RhbmNlIG9mIDEgZXZlbnQgdHlw ZS4NCg0KUkZDIDc5NTAsIHNlYyA3LjE2LjINCg0KDQogICBUaGUgaW5uZXJtb3N0IGNvbnRhaW5l ciBvciBsaXN0IGNvbnRhaW5zIGFuIFhNTA0KDQogICBlbGVtZW50IHRoYXQgY2FycmllcyB0aGUg bmFtZSBvZiB0aGUgZGVmaW5lZCBub3RpZmljYXRpb24uDQoNCg0KVGhlcmUgYXJlIDMgY29ybmVy LWNhc2VzIHRoYXQgc2hvdWxkIGJlIGNvbnNpZGVyZWQgaW4gb3JkZXINCnRvIG1pbmltaXplIG5l dHdvcmsgb3ZlcmhlYWQgZm9yIG5vdGlmaWNhdGlvbnMgaW4gNTI3N2Jpcy4NClJlcGxpY2F0aW5n IHRoZSBub2RlL2tleSBoaWVyYXJjaHkgY291bGQgYmUgZXhwZW5zaXZlDQphbmQgZXZlbnRzIG9j Y3VycmluZyBhdCB0aGUgc2FtZSB0aW1lIGNvdWxkIGJlIGNvcnJlbGF0ZWQuDQoNCkR1cGxpY2F0 aW5nIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZXMgaXMgaW5lZmZpY2llbnQsDQpidXQgcHJvY2Vz c2luZyBtdWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2UgbWFrZXMNCmZpbHRlcmluZyBhbmQgcGFy c2luZyBtb3JlIGNvbXBsaWNhdGVkLg0KDQpJIGFtIGN1cmlvdXMgaWYgdGhlIFdHIHRoaW5rcyBu b3RpZmljYXRpb24gb3ZlcmhlYWQgaXMgYSBjb25jZXJuIGFuZA0KaWYgaXQgbmVlZHMgdG8gYmUg YWRkcmVzc2VkIHNvbWVob3cgaW4gNTI3N2Jpcy4NCg0KDQoNCjEpIG11bHRpcGxlIG5vbi1zaWJs aW5nIGV2ZW50cyBpbiBzYW1lIHN1YnRyZWUNCg0KDQogIDxub3RpZmljYXRpb24+DQoNCiAgICA8 aW50ZXJmYWNlcz4NCg0KICAgICAgPG15LXRvcC1ldmVudD4NCg0KICAgICAgICA8bXktZGF0YT40 MjwvbXktZGF0YT4NCg0KICAgICAgPC9teS10b3AtZXZlbnQ+DQoNCiAgICAgIDxpbnRlcmZhY2U+ DQoNCiAgICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4NCg0KICAgICAgICA8bXktaW50ZXJmYWNlLWV2 ZW50Pg0KDQogICAgICAgICAgICAgIDxpZi1kYXRhPmF1dG88L2lmLWRhdGE+DQoNCiAgICAgICAg PC9teS1pbnRlcmZhY2UtZXZlbnQ+DQoNCiAgICAgIDwvaW50ZXJmYWNlPg0KDQogICAgPC9pbnRl cmZhY2VzPg0KDQogIDwvbm90aWZpY2F0aW9uPg0KDQoNCg0KMikgbXVsdGlwbGUgc2libGluZyBl dmVudHMgaW4gdGhlIHNhbWUgc3VidHJlZQ0KDQoNCiAgPG5vdGlmaWNhdGlvbj4NCg0KICAgIDxp bnRlcmZhY2VzPg0KDQogICAgICA8aW50ZXJmYWNlPg0KDQogICAgICAgIDxuYW1lPmV0aDA8L25h bWU+DQoNCiAgICAgICAgPG15LWludGVyZmFjZS1ldmVudD4NCg0KICAgICAgICAgICAgICA8aWYt ZGF0YT5hdXRvPC9pZi1kYXRhPg0KDQogICAgICAgIDwvbXktaW50ZXJmYWNlLWV2ZW50Pg0KDQog ICAgICAgIDxpbnRlcmZhY2UtZW5hYmxlZD4NCg0KICAgICAgICAgICA8YnktdXNlcj5hZG1pbjwv YnktdXNlcj4NCg0KICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KDQogICAgICA8L2ludGVy ZmFjZT4NCg0KICAgIDwvaW50ZXJmYWNlcz4NCg0KICA8L25vdGlmaWNhdGlvbj4NCg0KDQoNCg0K MykgbXVsdGlwbGUgbm9uLXNpYmxpbmcgZXZlbnRzIGluIGRpZmZlcmVudCBzdWJ0cmVlcw0KDQoN CiAgPG5vdGlmaWNhdGlvbj4NCg0KICAgIDxzeXN0ZW0+DQoNCiAgICAgIDxteS1zeXN0ZW0tZXZl bnQ+DQoNCiAgICAgICAgICAgIDxteS1kYXRhPjQyPC9teS1kYXRhPg0KDQogICAgICA8L215LXN5 c3RlbS1ldmVudD4NCg0KICAgIDwvc3lzdGVtPg0KDQogICAgPGludGVyZmFjZXM+DQoNCiAgICAg IDxpbnRlcmZhY2U+DQoNCiAgICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4NCg0KICAgICAgICA8bXkt aW50ZXJmYWNlLWV2ZW50Pg0KDQogICAgICAgICAgICAgIDxpZi1kYXRhPmF1dG88L2lmLWRhdGE+ DQoNCiAgICAgICAgPC9teS1pbnRlcmZhY2UtZXZlbnQ+DQoNCiAgICAgIDwvaW50ZXJmYWNlPg0K DQogICAgPC9pbnRlcmZhY2VzPg0KDQogIDwvbm90aWZpY2F0aW9uPg0KDQoNCg0KQW5keQ0KDQoN Cg== --_000_e8007d23234a4c8aba08c4a44178c091XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9 InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJHZW5lcmF0b3IiIGNvbnRl bnQ9Ik1pY3Jvc29mdCBXb3JkIDE1IChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxzdHlsZT48IS0tDQov KiBGb250IERlZmluaXRpb25zICovDQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJDYW1icmlh IE1hdGgiOw0KCXBhbm9zZS0xOjIgNCA1IDMgNSA0IDYgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtm b250LWZhbWlseTpDYWxpYnJpOw0KCXBhbm9zZS0xOjIgMTUgNSAyIDIgMiA0IDMgMiA0O30NCkBm b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJcGFub3NlLTE6MiAxMSA2IDkgMiAy IDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29O b3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAx cHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixz ZXJpZjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5 OTsNCgljb2xvcjojMDU2M0MxOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNp dGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsN Cgljb2xvcjojOTU0RjcyOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21z by1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQg Q2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGku bXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0K CW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7 DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5IVE1MUHJlZm9y bWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRl ZCI7DQoJZm9udC1mYW1pbHk6Q29uc29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9u bHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBz cGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4 bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIg ZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4N Cjxib2R5IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiM0NDcyQzQiPkhpIEFuZHksPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDcyQzQiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtj b2xvcjojNDQ3MkM0Ij7igJxUaGUgaW5uZXJtb3N0IGNvbnRhaW5lciBvciBsaXN04oCdIHRleHQg aXMgc2ltaWxhciB0byB0aGF0IGZvciBhY3Rpb25zIGluIHNlY3Rpb24gNy4xNS4yLiZuYnNwOyZu YnNwOyBQZXJoYXBzIHRoZSBtZW50YWwgbW9kZWwgb2Ygb25lIHRhcmdldCBmb3IgYW4gYWN0aW9u IHdhcyByZXBsaWNhdGVkPzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ3MkM0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NzJD NCI+SSBoYWQgbm90IGNvbnNpZGVyZWQgdGhhdCBZQU5HIDEuMeKAmXMgZGVmaW5pdGlvbiBtaWdo dCBmb3JjZSB0aGUgYnJlYWt1cCBvZiBhIHZlcmJvc2Ugc29mdHdhcmUgY29tcG9uZW50IGdlbmVy YXRlZCBub3RpZmljYXRpb24gaW50byBtdWx0aXBsZSBwdXNoZWQgbm90aWZpY2F0aW9uDQogbWVz c2FnZXMuJm5ic3A7IExvb2tpbmcgYXQgdGhlIHRocmVlIGNhc2VzIGJlbG93LCBJIGRvbuKAmXQg dGhpbmsgdGhhdCBhcmJpdHJhcnkgY2hvaWNlcyBtYWRlIGluIFlBTkcgbW9kZWwgc3RydWN0dXJl IHNob3VsZCBpbXBhY3Qgd2hhdCBjb3VsZCBvciBjb3VsZG7igJl0IGJlIGluIGVuY29kZWQgd2l0 aGluIGFueSBzaW5nbGUgbm90aWZpY2F0aW9uLiZuYnNwOyBTbyBteSBwcmVmZXJlbmNlIHdvdWxk IGJlIHRoYXQgYWxsIHRocmVlIHZhcmlhbnRzIGJlbG93IHNob3VsZA0KIHN1cHBvcnRhYmxlIGlm IHRoYXQgaXMgaG93IHRoZSBzeXN0ZW0gcGFzc2VkIHRoZW0gdG8gYmUgZW5jb2RlZCBhcyBwYXJ0 IG9mIGFuIGV2ZW50Lg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy aSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiM0NDcyQzQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ3MkM0 Ij5XaGF0IGlmIHRoZSByZWludGVycHJldGF0aW9uIHdlcmUgYXMgc2ltcGxlIGFzIOKAnEFuIGlu bmVybW9zdOKAnSBvciDigJxUaGUgZmlyc3QgaW5uZXJtb3N04oCdPzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojNDQ3MkM0 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7 LHNhbnMtc2VyaWY7Y29sb3I6IzQ0NzJDNCI+RXJpYzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVm dDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRpdj4NCjxk aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBwdDtwYWRk aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fu cy1zZXJpZiI+RnJvbTo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZiI+IE5ldGNvbmYgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddDQo8Yj5PbiBCZWhhbGYgT2YgPC9iPkFuZHkgQmll cm1hbjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSmFudWFyeSA1LCAyMDE3IDU6MjUgUE08 YnI+DQo8Yj5Ubzo8L2I+IE5ldGNvbmYgJmx0O25ldGNvbmZAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+ U3ViamVjdDo8L2I+IFtOZXRjb25mXSBuZXN0ZWQgbm90aWZpY2F0aW9uczxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhpLDxvOnA+PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB3b3VsZCBsaWtlIHNvbWUgdGV4dCBpbiBSRkMg Nzk1MCB0byBiZSByZWludGVycHJldGVkLiBUaGUgdGV4dCBpbXBsaWVzIGVhY2g8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm5vdGlmaWNhdGlvbiBt ZXNzYWdlIGNhbiBvbmx5IGRlc2NyaWJlIDEgaW5zdGFuY2Ugb2YgMSBldmVudCB0eXBlLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5SRkMgNzk1 MCwgc2VjIDcuMTYuMiA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHByZSBzdHls ZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZu YnNwOyZuYnNwOyBUaGUgaW5uZXJtb3N0IGNvbnRhaW5lciBvciBsaXN0IGNvbnRhaW5zIGFuIFhN TDxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6 YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyBlbGVtZW50IHRo YXQgY2FycmllcyB0aGUgbmFtZSBvZiB0aGUgZGVmaW5lZCBub3RpZmljYXRpb24uPG86cD48L286 cD48L3NwYW4+PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWls eTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDssc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVh c3QtbGFuZ3VhZ2U6RU4tVVMiPjxiciBjbGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NClRoZXJlIGFy ZSAzIGNvcm5lci1jYXNlcyB0aGF0IHNob3VsZCBiZSBjb25zaWRlcmVkIGluIG9yZGVyPGJyPg0K dG8gbWluaW1pemUgbmV0d29yayBvdmVyaGVhZCBmb3Igbm90aWZpY2F0aW9ucyBpbiA1Mjc3Ymlz Ljxicj4NClJlcGxpY2F0aW5nIHRoZSBub2RlL2tleSBoaWVyYXJjaHkgY291bGQgYmUgZXhwZW5z aXZlPGJyPg0KYW5kIGV2ZW50cyBvY2N1cnJpbmcgYXQgdGhlIHNhbWUgdGltZSBjb3VsZCBiZSBj b3JyZWxhdGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5EdXBsaWNhdGluZyB0aGUgbm90aWZpY2F0aW9uIG1lc3NhZ2VzIGlzIGluZWZmaWNp ZW50LDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ YnV0IHByb2Nlc3NpbmcgbXVsdGlwbGUgZXZlbnRzIHBlciBtZXNzYWdlIG1ha2VzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5maWx0ZXJpbmcgYW5k IHBhcnNpbmcgbW9yZSBjb21wbGljYXRlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBhbSBjdXJpb3VzIGlmIHRoZSBXRyB0aGlua3Mgbm90 aWZpY2F0aW9uIG92ZXJoZWFkIGlzIGEgY29uY2VybiBhbmQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmlmIGl0IG5lZWRzIHRvIGJlIGFkZHJlc3Nl ZCBzb21laG93IGluIDUyNzdiaXMuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDs7 Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxiciBjbGVhcj0iYWxsIiBz dHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxwcmUgc3R5bGU9InBh Z2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4xKSBtdWx0 aXBsZSBub24tc2libGluZyBldmVudHMgaW4gc2FtZSBzdWJ0cmVlPG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtD b3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+ PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFu Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyAmbHQ7bm90aWZpY2F0aW9uJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0i Y29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlcyZndDs8bzpwPjwv bzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+ PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgPGI+Jm5ic3A7Jm5i c3A7Jmx0O215LXRvcC1ldmVudCZndDs8L2I+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJl IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtteS1k YXRhJmd0OzQyJmx0Oy9teS1kYXRhJmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVm b3JlOmFsd2F5cyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgJmx0Oy9teS10b3AtZXZlbnQmZ3Q7PC9zcGFuPjwvYj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7bmFtZSZndDtldGgwJmx0Oy9uYW1lJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0K PHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6 YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyA8Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7 bXktaW50ZXJmYWNlLWV2ZW50Jmd0OzwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUg c3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJs YWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2lm LWRhdGEmZ3Q7YXV0byZsdDsvaWYtZGF0YSZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvbXktaW50ZXJmYWNlLWV2ZW50Jmd0 Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9 ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9pbnRlcmZh Y2UmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9 InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJz cDsgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90 Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwi IHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPGJyIGNsZWFyPSJhbGwiIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjIpIG11bHRpcGxl IHNpYmxpbmcgZXZlbnRzIGluIHRoZSBzYW1lIHN1YnRyZWU8bzpwPjwvbzpwPjwvc3Bhbj48L3By ZT4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJp ZXIgTmV3JnF1b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YnIg Y2xlYXI9ImFsbCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8 cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpi bGFjayI+Jm5ic3A7ICZsdDtub3RpZmljYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtpbnRlcmZhY2VzJmd0OzxvOnA+PC9vOnA+ PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3Bh biBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7 aW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7bmFtZSZndDtldGgwJmx0Oy9uYW1l Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZv cmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyA8Yj4mbmJzcDsmbmJzcDsmbmJzcDsmbHQ7bXktaW50ZXJmYWNlLWV2ZW50Jmd0OzwvYj48 bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFs d2F5cyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVv dDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2lmLWRhdGEmZ3Q7YXV0byZsdDsvaWYtZGF0YSZn dDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDsvbXktaW50ZXJmYWNlLWV2ZW50Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNv bG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJl YWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2ludGVyZmFjZS1lbmFibGVkJmd0 Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bhbj48 L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O2J5LXVzZXImZ3Q7YWRtaW4mbHQ7L2J5LXVzZXImZ3Q7 PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+PC9vOnA+PC9zcGFuPjwv cHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48Yj48c3BhbiBzdHls ZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyAmbHQ7L2ludGVyZmFjZS1lbmFibGVkJmd0OyZuYnNwOyA8L3NwYW4+PC9iPjxzcGFuIHN0eWxl PSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdl LWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9pbnRlcmZhY2UmZ3Q7PG86cD48L286cD48 L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFu IHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvaW50ZXJmYWNlcyZn dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3Jl OmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsgJmx0Oy9ub3RpZmljYXRp b24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8ZGl2Pg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9kaXY+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjBw dDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90Oztjb2xvcjpibGFjazttc28tZmFy ZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJhbGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3 YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPjMpIG11bHRpcGxlIG5vbi1zaWJsaW5nIGV2 ZW50cyBpbiBkaWZmZXJlbnQgc3VidHJlZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1 b3Q7O2NvbG9yOmJsYWNrO21zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48YnIgY2xlYXI9ImFs bCIgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+DQo8L3NwYW4+DQo8cHJlIHN0eWxl PSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5i c3A7ICZsdDtub3RpZmljYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDtzeXN0ZW0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+ DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xv cjpibGFjayI+Jm5ic3A7Jm5ic3A7IDxiPiZuYnNwOyZuYnNwOyZuYnNwOyZsdDtteS1zeXN0ZW0t ZXZlbnQmZ3Q7PC9iPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1i cmVhay1iZWZvcmU6YWx3YXlzIj48Yj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyA8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7bXktZGF0YSZndDs0MiZsdDsvbXktZGF0YSZn dDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+ PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuIHN0 eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvbXkt c3lzdGVtLWV2ZW50Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpw PjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5 cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9zeXN0 ZW0mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFrLWJl Zm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 ICZsdDtpbnRlcmZhY2VzJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0i cGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29sb3I6YmxhY2siPiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbHQ7aW50ZXJmYWNlJmd0OzxvOnA+PC9vOnA+PC9z cGFuPjwvcHJlPg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBz dHlsZT0iY29sb3I6YmxhY2siPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyAmbHQ7bmFtZSZndDtldGgwJmx0Oy9uYW1lJmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj48c3BhbiBzdHlsZT0iY29s b3I6YmxhY2siPiZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8Yj4mbmJzcDsm bHQ7bXktaW50ZXJmYWNlLWV2ZW50Jmd0OzwvYj48bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxw cmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PGI+PHNwYW4gc3R5bGU9ImNvbG9y OmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgPC9zcGFuPjwvYj48Yj48c3BhbiBzdHls ZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+ Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0 O2lmLWRhdGEmZ3Q7YXV0byZsdDsvaWYtZGF0YSZndDs8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJj b2xvcjpibGFjayI+PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJy ZWFrLWJlZm9yZTphbHdheXMiPjxiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDsvbXktaW50ZXJmYWNlLWV2ZW50 Jmd0Ozwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj48bzpwPjwvbzpwPjwvc3Bh bj48L3ByZT4NCjxwcmUgc3R5bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5 bGU9ImNvbG9yOmJsYWNrIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0Oy9pbnRl cmZhY2UmZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8cHJlIHN0eWxlPSJwYWdlLWJyZWFr LWJlZm9yZTphbHdheXMiPjxzcGFuIHN0eWxlPSJjb2xvcjpibGFjayI+Jm5ic3A7Jm5ic3A7Jm5i c3A7ICZsdDsvaW50ZXJmYWNlcyZndDs8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmUgc3R5 bGU9InBhZ2UtYnJlYWstYmVmb3JlOmFsd2F5cyI+PHNwYW4gc3R5bGU9ImNvbG9yOmJsYWNrIj4m bmJzcDsgJmx0Oy9ub3RpZmljYXRpb24mZ3Q7PG86cD48L286cD48L3NwYW4+PC9wcmU+DQo8c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90Oztjb2xvcjpibGFjazttc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PGJyIGNsZWFyPSJh bGwiIHN0eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPGJyIGNsZWFyPSJhbGwiIHN0 eWxlPSJwYWdlLWJyZWFrLWJlZm9yZTphbHdheXMiPg0KPC9zcGFuPg0KPHByZSBzdHlsZT0icGFn ZS1icmVhay1iZWZvcmU6YWx3YXlzIj48YnI+QW5keTxvOnA+PC9vOnA+PC9wcmU+DQo8c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m cXVvdDssc2VyaWY7Y29sb3I6YmxhY2s7bXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxiciBj bGVhcj0iYWxsIiBzdHlsZT0icGFnZS1icmVhay1iZWZvcmU6YWx3YXlzIj4NCjwvc3Bhbj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4N CjwvYm9keT4NCjwvaHRtbD4NCg== --_000_e8007d23234a4c8aba08c4a44178c091XCHRTP013ciscocom_-- From nobody Thu Jan 5 18:43:16 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D3AD129855 for ; Thu, 5 Jan 2017 18:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zAzafHV0PxUT for ; Thu, 5 Jan 2017 18:43:13 -0800 (PST) Received: from mail-qt0-x230.google.com (mail-qt0-x230.google.com [IPv6:2607:f8b0:400d:c0d::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 991EF129851 for ; Thu, 5 Jan 2017 18:43:12 -0800 (PST) Received: by mail-qt0-x230.google.com with SMTP id v23so68449929qtb.0 for ; Thu, 05 Jan 2017 18:43:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/luofvSyOXLbN3It5am2F8wmB/YLjMPQ7k7hGe1P9h0=; b=X6XDTOMksHnkgT76LfQoPNc3liyn3Ba4wTD6fMb3DMMADOD5+WP6GppG7ROdPVZPk0 qCXrdOTbx5qea9hUgYkM1w4p/0Sk89xNTnzbJB6x0v9GpNMzezZWLw8ScUq6roAnp8Jq ItpV4ohdNtb6Ccwq1Au/CvTPipvO4Ih8KX3Xt8pTH0Q34p1zZmp64ZQ15oNE1MComoAC hLwqrpfc3EtstjYaToJ+rcuwe+6gH5Q/HcBKpj4rtndZSLa9EPiesbs9KAuTpDTrqdgh 4s4WQv0vP90rXdA1mzMo5+KsTD4D2jgp+Ew1i54Gg6xn++St8kB79+bv7tOxtCMelJP8 mBGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=/luofvSyOXLbN3It5am2F8wmB/YLjMPQ7k7hGe1P9h0=; b=k16y96xcD3hOU+uZrYUvr+9LemCGvNU7LveCyyvtjWjGKE3TnvKSIGtg/560QBT5U5 /GuXXTtMjDRGdOg5FB6pUJkfm/lXhaUiv0MVxEtPyMSB6JmESXvhzd34/EPu/R4kfovW S+g16pYengYRRy7VEI2AUK8KqGrUp+xQXSfOchkOTt7YkPlkcvRDxuCp1MPAJ9Q6ExUZ LJfmtk82oEW9c9rEh7jcuH4zlofUxexkJoFn3F+yydZvReUUSIYXZemVpcWgZZLdlX25 xbMlevzyQdKi+5Iwp7AbHVjzw816tw7PJSTm7heLIIJvIsRzMTD/CQy68U8V+5QiPiZz oKEw== X-Gm-Message-State: AIkVDXIIpfduFDYu3BJyqOXvDfoWJ/fn4Z1Uue2g/ObmxJgquNcHwThNkdzPsAXNjsiXyy8sXQORGjsP1rmvHA== X-Received: by 10.200.36.171 with SMTP id s40mr66724257qts.142.1483670591696; Thu, 05 Jan 2017 18:43:11 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Thu, 5 Jan 2017 18:43:11 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Thu, 5 Jan 2017 18:43:11 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a11403342950acf054563fa37 Archived-At: Cc: Netconf Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 02:43:14 -0000 --001a11403342950acf054563fa37 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) wrote: > Hi Andy, > > > > =E2=80=9CThe innermost container or list=E2=80=9D text is similar to that= for actions in > section 7.15.2. Perhaps the mental model of one target for an action wa= s > replicated? > > > > I had not considered that YANG 1.1=E2=80=99s definition might force the b= reakup of > a verbose software component generated notification into multiple pushed > notification messages. Looking at the three cases below, I don=E2=80=99t= think > that arbitrary choices made in YANG model structure should impact what > could or couldn=E2=80=99t be in encoded within any single notification. = So my > preference would be that all three variants below should supportable if > that is how the system passed them to be encoded as part of an event. > > > I think the WG did not consider these details and assumed they were the sam= e as for action. This would be a MAY for the server and a MUST for the client, so it is not an easy decision. A couple use-cases I have in mind: 1) event broker subscriber is really a broker that may be pre-processing lots of subscriptions or event types within 1 subscription 2) digest (time-based push) Subscriber wants an update every 5 seconds with all the YANG 1.1 event= s for the previous 5 seconds > What if the reinterpretation were as simple as =E2=80=9CAn innermost=E2= =80=9D or =E2=80=9CThe > first innermost=E2=80=9D? > This covers case 2. (Change "The" to "An"). The client would need to check for YANG 1.1 notifications in the same way it checks child nodes already. > > > Eric > > > Andy > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Thursday, January 5, 2017 5:25 PM > *To:* Netconf > *Subject:* [Netconf] nested notifications > > > > Hi, > > > > I would like some text in RFC 7950 to be reinterpreted. The text implies > each > > notification message can only describe 1 instance of 1 event type. > > > > RFC 7950, sec 7.16.2 > > > > The innermost container or list contains an XML > > element that carries the name of the defined notification. > > > > There are 3 corner-cases that should be considered in order > to minimize network overhead for notifications in 5277bis. > Replicating the node/key hierarchy could be expensive > and events occurring at the same time could be correlated. > > > > Duplicating the notification messages is inefficient, > > but processing multiple events per message makes > > filtering and parsing more complicated. > > > > I am curious if the WG thinks notification overhead is a concern and > > if it needs to be addressed somehow in 5277bis. > > > > 1) multiple non-sibling events in same subtree > > > > > > > * * > > * 42* > > * * > > > > eth0 > > * * > > * auto* > > * * > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > eth0 > > * * > > * auto* > > * * > > * * > > * admin* > > * * > > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > * * > > * 42* > > * * > > > > > > > > eth0 > > * * > > * auto* > > * * > > > > > > > > > > > Andy > > > > --001a11403342950acf054563fa37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:

Hi Andy,

=C2=A0

=E2=80=9CThe innermost container or l= ist=E2=80=9D text is similar to that for actions in section 7.15.2.=C2=A0= =C2=A0 Perhaps the mental model of one target for an action was replicated?=

=C2=A0

I had not considered that YANG 1.1=E2= =80=99s definition might force the breakup of a verbose software component = generated notification into multiple pushed notification messages.=C2=A0 Looking at the three cases below, I don=E2=80=99t think th= at arbitrary choices made in YANG model structure should impact what could = or couldn=E2=80=99t be in encoded within any single notification.=C2=A0 So = my preference would be that all three variants below should supportable if that is how the system passed them to be encoded as part of= an event.

=C2=A0

<= /blockquote>


I think the WG did not consi= der these details and assumed they were the same
as for action.

This would be a MAY for the server and a MUST for t= he client, so it is not
an easy decision.

A couple use-cases I have in mind:

=C2=A0 1) eve= nt broker
=C2=A0 =C2=A0 =C2=A0 subscriber is really a broker that= may be pre-processing lots of
=C2=A0 =C2=A0 =C2=A0 subscriptions= or event types within 1 subscription

=C2=A0 =C2= =A02) digest (time-based push)
=C2=A0 =C2=A0 =C2=A0Subscriber wan= ts an update every 5 seconds with all the YANG 1.1 events
=C2=A0 = =C2=A0 for the previous 5 seconds


= =C2=A0

What if the reinterpretation were as = simple as =E2=80=9CAn innermost=E2=80=9D or =E2=80=9CThe first innermost=E2= =80=9D?


This covers = case 2. (Change "The" to "An").
The clien= t would need to check for YANG 1.1 notifications in the
same way = it checks child nodes already.
=C2=A0

=C2=A0

Eric

=C2=A0

<= /blockquote>

Andy
=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.o= rg] On Behalf Of Andy Bierman
Sent: Thursday, January 5, 2017 5:25 PM
To: Netconf <netconf@ietf.org>
Subject: [Netconf] nested notifications

=C2=A0

Hi,

=C2=A0

I would like some text in RFC 7950 to be reinterpret= ed. The text implies each

notification message can only describe 1 instance of= 1 event type.

=C2=A0

RFC 7950, sec 7.16.2

=C2=A0

=C2=A0=
=C2=A0 The innermost container or list contains an XML=

=C2=A0=
=C2=A0 element that carries the name of the defined notification.=


There are 3 corner-cases that should be considered in order
to minimize network overhead for notifications in 5277bis.
Replicating the node/key hierarchy could be expensive
and events occurring at the same time could be correlated.

=C2=A0

Duplicating the notification messages is inefficient= ,

but processing multiple events per message makes<= /u>

filtering and parsing more complicated.

=C2=A0

I am curious if the WG thinks notification overhead = is a concern and

if it needs to be addressed somehow in 5277bis.

=C2=A0


 
1) mult=
iple non-sibling events in same subtree

 
=C2=A0 =
<notification>
=C2=A0=
=C2=A0=C2=A0 <interfaces>
=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0<my-top-event>

=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <my-data>42</my-data>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-top-event>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <interface>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name>


=C2=A0=
=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0<my-interface-event>


=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<if-data>auto</if-data>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event><=
/b>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </interface>


=C2=A0=
=C2=A0=C2=A0 </interfaces>


=C2=A0 =
</notification>







2) mult=
iple sibling events in the same subtree





=C2=A0 =
<notification>


=C2=A0=
=C2=A0=C2=A0 <interfaces>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <interface>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name>


=C2=A0=
=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0<my-interface-event>


=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<if-data>auto</if-data>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event><=
/b>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <interface-enabled>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <by-user>ad=
min</by-user>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </interface-enabled>=C2=A0 


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>


=C2=A0=
=C2=A0=C2=A0 </interfaces>


=C2=A0 =
</notification>




=
=C2=A0







3) mult=
iple non-sibling events in different subtrees





=C2=A0 =
<notification>


=C2=A0=
=C2=A0=C2=A0 <system>


=C2=A0=
=C2=A0 =C2=A0=C2=A0=C2=A0<my-system-event>


=C2=
=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
;my-data>42</my-data>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-system-event>


=C2=A0=
=C2=A0=C2=A0 </system>


=C2=A0=
=C2=A0=C2=A0 <interfaces>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 <interface>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name>


=C2=A0=
=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<my-interface-event>


=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<if-data>auto</if-data>


=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event><=
/b>


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 </interface>


=C2=A0=
=C2=A0=C2=A0 </interfaces>


=C2=A0 =
</notification>








Andy





=C2=A0

--001a11403342950acf054563fa37-- From nobody Fri Jan 6 09:28:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0F3129D2E for ; Fri, 6 Jan 2017 09:28:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.622 X-Spam-Level: X-Spam-Status: No, score=-17.622 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.1, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bG9FJb2kpEph for ; Fri, 6 Jan 2017 09:28:33 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AAF129B73 for ; Fri, 6 Jan 2017 09:28:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6570; q=dns/txt; s=iport; t=1483723712; x=1484933312; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=cC8gAg4rLegT6+E14xhoRAS3thZhoppNMYf2XbYyzOY=; b=l32RV+0pQ46JQ7XUSsA1MvvsPlhlFNM/Fog+xVd+YbsFz8QfoyGRmEXM 37paq2azNasDI8eSPsXirFdk8RxpdY8AeSKQoI4x6RgRRRNblvOyRvi6m KIPS8l7KNvvV1KgImqMV2M3elQ6qqYIyGK6DkoPRGVG5T7Qc92ErnbxRD E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC/0m9Y/4ENJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzkBAQEBAR+BaweNUJIhlSaCCYJsgzYCGoE7PxQBAgEBAQEBAQF?= =?us-ascii?q?jKIRoAQEBAwEjETMQBwsCAQYCEQQBAQECAgkaAwICAjAUAQgIAgQBEgiIYAiTC?= =?us-ascii?q?Z1OgiWKHAEBAQEBAQEBAQEBAQEBAQEBAQEBAR2BC4U6hGGEMIMegl4BBI8VjAA?= =?us-ascii?q?BiWuHUoIAjmSICYpHAR84gTwVNYQpHIFfc4dZgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,325,1477958400"; d="scan'208";a="191219382" Received: from alln-core-9.cisco.com ([173.36.13.129]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 06 Jan 2017 17:28:31 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id v06HSVjn019234 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jan 2017 17:28:31 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 6 Jan 2017 12:28:30 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Fri, 6 Jan 2017 12:28:30 -0500 From: "Eric Voit (evoit)" To: "Andy Bierman (andy@yumaworks.com)" , "netconf@ietf.org" Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KI87NiViNDDkG9WNSE0h61kKEqeKNAgACZJoCAAIaW4IAAADDw Date: Fri, 6 Jan 2017 17:28:30 +0000 Message-ID: References: <39b938d3504f4599bf4e92a48b685a0a@XCH-RTP-013.cisco.com> In-Reply-To: <39b938d3504f4599bf4e92a48b685a0a@XCH-RTP-013.cisco.com> 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: [10.118.56.226] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 17:28:36 -0000 PiBGcm9tOiBBbmR5IEJpZXJtYW4sIEphbnVhcnkgNSwgMjAxNyA5OjQzIFBNDQo+IA0KPiBPbiBU aHUsIEphbiA1LCAyMDE3IGF0IDU6MTYgUE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxtYWlsdG86ZXZv aXRAY2lzY28uY29tPg0KPiB3cm90ZToNCj4gSGkgQW5keSwNCj4gDQo+IOKAnFRoZSBpbm5lcm1v c3QgY29udGFpbmVyIG9yIGxpc3TigJ0gdGV4dCBpcyBzaW1pbGFyIHRvIHRoYXQgZm9yIGFjdGlv bnMgaW4gc2VjdGlvbg0KPiA3LjE1LjIuwqDCoCBQZXJoYXBzIHRoZSBtZW50YWwgbW9kZWwgb2Yg b25lIHRhcmdldCBmb3IgYW4gYWN0aW9uIHdhcyByZXBsaWNhdGVkPw0KPiANCj4gSSBoYWQgbm90 IGNvbnNpZGVyZWQgdGhhdCBZQU5HIDEuMeKAmXMgZGVmaW5pdGlvbiBtaWdodCBmb3JjZSB0aGUg YnJlYWt1cCBvZiBhDQo+IHZlcmJvc2Ugc29mdHdhcmUgY29tcG9uZW50IGdlbmVyYXRlZCBub3Rp ZmljYXRpb24gaW50byBtdWx0aXBsZSBwdXNoZWQNCj4gbm90aWZpY2F0aW9uIG1lc3NhZ2VzLsKg IExvb2tpbmcgYXQgdGhlIHRocmVlIGNhc2VzIGJlbG93LCBJIGRvbuKAmXQgdGhpbmsgdGhhdA0K PiBhcmJpdHJhcnkgY2hvaWNlcyBtYWRlIGluIFlBTkcgbW9kZWwgc3RydWN0dXJlIHNob3VsZCBp bXBhY3Qgd2hhdCBjb3VsZCBvcg0KPiBjb3VsZG7igJl0IGJlIGluIGVuY29kZWQgd2l0aGluIGFu eSBzaW5nbGUgbm90aWZpY2F0aW9uLsKgIFNvIG15IHByZWZlcmVuY2Ugd291bGQNCj4gYmUgdGhh dCBhbGwgdGhyZWUgdmFyaWFudHMgYmVsb3cgc2hvdWxkIHN1cHBvcnRhYmxlIGlmIHRoYXQgaXMg aG93IHRoZSBzeXN0ZW0NCj4gcGFzc2VkIHRoZW0gdG8gYmUgZW5jb2RlZCBhcyBwYXJ0IG9mIGFu IGV2ZW50Lg0KPiANCj4gDQo+IA0KPiBJIHRoaW5rIHRoZSBXRyBkaWQgbm90IGNvbnNpZGVyIHRo ZXNlIGRldGFpbHMgYW5kIGFzc3VtZWQgdGhleSB3ZXJlIHRoZSBzYW1lDQo+IGFzIGZvciBhY3Rp b24uDQo+IA0KPiBUaGlzIHdvdWxkIGJlIGEgTUFZIGZvciB0aGUgc2VydmVyIGFuZCBhIE1VU1Qg Zm9yIHRoZSBjbGllbnQsIHNvIGl0IGlzIG5vdA0KPiBhbiBlYXN5IGRlY2lzaW9uLg0KPiANCj4g QSBjb3VwbGUgdXNlLWNhc2VzIEkgaGF2ZSBpbiBtaW5kOg0KPiANCj4gwqAgMSkgZXZlbnQgYnJv a2VyDQo+IMKgIMKgIMKgIHN1YnNjcmliZXIgaXMgcmVhbGx5IGEgYnJva2VyIHRoYXQgbWF5IGJl IHByZS1wcm9jZXNzaW5nIGxvdHMgb2YNCj4gwqAgwqAgwqAgc3Vic2NyaXB0aW9ucyBvciBldmVu dCB0eXBlcyB3aXRoaW4gMSBzdWJzY3JpcHRpb24NCj4gDQo+IMKgIMKgMikgZGlnZXN0ICh0aW1l LWJhc2VkIHB1c2gpDQo+IMKgIMKgIMKgU3Vic2NyaWJlciB3YW50cyBhbiB1cGRhdGUgZXZlcnkg NSBzZWNvbmRzIHdpdGggYWxsIHRoZSBZQU5HIDEuMSBldmVudHMNCj4gwqAgwqAgZm9yIHRoZSBw cmV2aW91cyA1IHNlY29uZHMNCg0KVGhlc2UgYXJlIGJvdGggcmVhc29uYWJsZSBhcyBjb250cm9s bGVycyBhcmUgcmVxdWlyaW5nIHNjYWxhYmxlIG1ldGhvZHMgb2Ygc3luY2hpbmcgb24gZGV2aWNl IHN0YXR1cy4NCg0KPiBXaGF0IGlmIHRoZSByZWludGVycHJldGF0aW9uIHdlcmUgYXMgc2ltcGxl IGFzIOKAnEFuIGlubmVybW9zdOKAnSBvciDigJxUaGUgZmlyc3QNCj4gaW5uZXJtb3N04oCdPw0K PiANCj4gVGhpcyBjb3ZlcnMgY2FzZSAyLiAoQ2hhbmdlICJUaGUiIHRvICJBbiIpLg0KPiBUaGUg Y2xpZW50IHdvdWxkIG5lZWQgdG8gY2hlY2sgZm9yIFlBTkcgMS4xIG5vdGlmaWNhdGlvbnMgaW4g dGhlDQo+IHNhbWUgd2F5IGl0IGNoZWNrcyBjaGlsZCBub2RlcyBhbHJlYWR5Lg0KDQoiQW55IGlu bmVybW9zdCIuLi4/ICAgQW5kIHllcywgdGhpcyBpcyBhIG1vcmUgc2lnbmlmaWNhbnQgY2hhbmdl IG9uIHRoZSBjbGllbnQuICBCZXlvbmQgdGhpcywgZm9yIHVzZSBjYXNlcyAoMSkgJiAoMiksIGlm IHlvdSBkb24ndCB3YW50IHRvIHN1bW1hcml6ZSB0aGUgZXZlbnRUaW1lLCB0aGUgdGltZSBzaG91 bGQgYmUgcGxhY2VkIHdpdGggZWFjaCBpbm5lcm1vc3QgZXZlbnQuICBJIGFtIG5vdCBzdWdnZXN0 aW5nIHdlIGRvIHRoaXMsIGJ1dCBsaWtlIEFuZHkgSSB3YW50IHRvIGZpZ3VyZSBvdXQgd2hhdCB0 aGUgV0cgbWlnaHQgYmUgd2lsbGluZyB0byBjb25zaWRlciBpbiBzY29wZS4NCg0KRXJpYw0KDQo+ IEVyaWMNCj4gDQo+IA0KPiBBbmR5DQo+IA0KPiBGcm9tOiBOZXRjb25mIFttYWlsdG86bWFpbHRv Om5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFuZHkNCj4gQmllcm1hbg0K PiBTZW50OiBUaHVyc2RheSwgSmFudWFyeSA1LCAyMDE3IDU6MjUgUE0NCj4gVG86IE5ldGNvbmYg PG1haWx0bzpuZXRjb25mQGlldGYub3JnPg0KPiBTdWJqZWN0OiBbTmV0Y29uZl0gbmVzdGVkIG5v dGlmaWNhdGlvbnMNCj4gDQo+IEhpLA0KPiANCj4gSSB3b3VsZCBsaWtlIHNvbWUgdGV4dCBpbiBS RkMgNzk1MCB0byBiZSByZWludGVycHJldGVkLiBUaGUgdGV4dCBpbXBsaWVzIGVhY2gNCj4gbm90 aWZpY2F0aW9uIG1lc3NhZ2UgY2FuIG9ubHkgZGVzY3JpYmUgMSBpbnN0YW5jZSBvZiAxIGV2ZW50 IHR5cGUuDQo+IA0KPiBSRkMgNzk1MCwgc2VjIDcuMTYuMg0KPiANCj4gwqDCoCBUaGUgaW5uZXJt b3N0IGNvbnRhaW5lciBvciBsaXN0IGNvbnRhaW5zIGFuIFhNTA0KPiDCoMKgIGVsZW1lbnQgdGhh dCBjYXJyaWVzIHRoZSBuYW1lIG9mIHRoZSBkZWZpbmVkIG5vdGlmaWNhdGlvbi4NCj4gDQo+IA0K PiBUaGVyZSBhcmUgMyBjb3JuZXItY2FzZXMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJlZCBpbiBv cmRlcg0KPiB0byBtaW5pbWl6ZSBuZXR3b3JrIG92ZXJoZWFkIGZvciBub3RpZmljYXRpb25zIGlu IDUyNzdiaXMuDQo+IFJlcGxpY2F0aW5nIHRoZSBub2RlL2tleSBoaWVyYXJjaHkgY291bGQgYmUg ZXhwZW5zaXZlDQo+IGFuZCBldmVudHMgb2NjdXJyaW5nIGF0IHRoZSBzYW1lIHRpbWUgY291bGQg YmUgY29ycmVsYXRlZC4NCj4gDQo+IER1cGxpY2F0aW5nIHRoZSBub3RpZmljYXRpb24gbWVzc2Fn ZXMgaXMgaW5lZmZpY2llbnQsDQo+IGJ1dCBwcm9jZXNzaW5nIG11bHRpcGxlIGV2ZW50cyBwZXIg bWVzc2FnZSBtYWtlcw0KPiBmaWx0ZXJpbmcgYW5kIHBhcnNpbmcgbW9yZSBjb21wbGljYXRlZC4N Cj4gDQo+IEkgYW0gY3VyaW91cyBpZiB0aGUgV0cgdGhpbmtzIG5vdGlmaWNhdGlvbiBvdmVyaGVh ZCBpcyBhIGNvbmNlcm4gYW5kDQo+IGlmIGl0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBzb21laG93 IGluIDUyNzdiaXMuDQo+IA0KPiANCj4gMSkgbXVsdGlwbGUgbm9uLXNpYmxpbmcgZXZlbnRzIGlu IHNhbWUgc3VidHJlZQ0KPiANCj4gwqAgPG5vdGlmaWNhdGlvbj4NCj4gwqDCoMKgIDxpbnRlcmZh Y2VzPg0KPiDCoMKgwqAgwqDCoDxteS10b3AtZXZlbnQ+DQo+IMKgwqDCoMKgwqDCoMKgIDxteS1k YXRhPjQyPC9teS1kYXRhPg0KPiDCoMKgwqDCoMKgIDwvbXktdG9wLWV2ZW50Pg0KPiDCoMKgwqDC oMKgIDxpbnRlcmZhY2U+DQo+IMKgwqDCoMKgwqDCoMKgIDxuYW1lPmV0aDA8L25hbWU+DQo+IMKg wqDCoCDCoMKgwqDCoDxteS1pbnRlcmZhY2UtZXZlbnQ+DQo+IMKgwqDCoMKgIMKgwqDCoMKgwqDC oMKgwqDCoDxpZi1kYXRhPmF1dG88L2lmLWRhdGE+DQo+IMKgwqDCoMKgwqDCoMKgIDwvbXktaW50 ZXJmYWNlLWV2ZW50Pg0KPiDCoMKgwqDCoMKgIDwvaW50ZXJmYWNlPg0KPiDCoMKgwqAgPC9pbnRl cmZhY2VzPg0KPiDCoCA8L25vdGlmaWNhdGlvbj4NCj4gDQo+IA0KPiAyKSBtdWx0aXBsZSBzaWJs aW5nIGV2ZW50cyBpbiB0aGUgc2FtZSBzdWJ0cmVlDQo+IA0KPiDCoCA8bm90aWZpY2F0aW9uPg0K PiDCoMKgwqAgPGludGVyZmFjZXM+DQo+IMKgwqDCoMKgwqAgPGludGVyZmFjZT4NCj4gwqDCoMKg wqDCoMKgwqAgPG5hbWU+ZXRoMDwvbmFtZT4NCj4gwqDCoMKgwqAgwqDCoMKgPG15LWludGVyZmFj ZS1ldmVudD4NCj4gwqDCoMKgwqAgwqDCoMKgwqDCoMKgwqDCoMKgPGlmLWRhdGE+YXV0bzwvaWYt ZGF0YT4NCj4gwqDCoMKgwqDCoMKgwqAgPC9teS1pbnRlcmZhY2UtZXZlbnQ+DQo+IMKgwqDCoMKg wqDCoMKgIDxpbnRlcmZhY2UtZW5hYmxlZD4NCj4gwqDCoMKgwqDCoMKgwqDCoMKgwqAgPGJ5LXVz ZXI+YWRtaW48L2J5LXVzZXI+DQo+IMKgwqDCoMKgwqDCoMKgIDwvaW50ZXJmYWNlLWVuYWJsZWQ+ DQo+IMKgwqDCoMKgwqDCoDwvaW50ZXJmYWNlPg0KPiDCoMKgwqAgPC9pbnRlcmZhY2VzPg0KPiDC oCA8L25vdGlmaWNhdGlvbj4NCj4gDQo+IA0KPiAzKSBtdWx0aXBsZSBub24tc2libGluZyBldmVu dHMgaW4gZGlmZmVyZW50IHN1YnRyZWVzDQo+IA0KPiDCoCA8bm90aWZpY2F0aW9uPg0KPiDCoMKg wqAgPHN5c3RlbT4NCj4gwqDCoCDCoMKgwqA8bXktc3lzdGVtLWV2ZW50Pg0KPiDCoMKgwqDCoCDC oMKgwqDCoMKgwqDCoDxteS1kYXRhPjQyPC9teS1kYXRhPg0KPiDCoMKgwqDCoMKgIDwvbXktc3lz dGVtLWV2ZW50Pg0KPiDCoMKgwqAgPC9zeXN0ZW0+DQo+IMKgwqDCoCA8aW50ZXJmYWNlcz4NCj4g wqDCoMKgwqDCoCA8aW50ZXJmYWNlPg0KPiDCoMKgwqDCoMKgwqDCoCA8bmFtZT5ldGgwPC9uYW1l Pg0KPiDCoMKgIMKgwqDCoMKgwqA8bXktaW50ZXJmYWNlLWV2ZW50Pg0KPiDCoMKgwqDCoCDCoMKg wqDCoMKgwqDCoMKgwqA8aWYtZGF0YT5hdXRvPC9pZi1kYXRhPg0KPiDCoMKgwqDCoMKgwqDCoCA8 L215LWludGVyZmFjZS1ldmVudD4NCj4gwqDCoMKgwqDCoCA8L2ludGVyZmFjZT4NCj4gwqDCoMKg IDwvaW50ZXJmYWNlcz4NCj4gwqAgPC9ub3RpZmljYXRpb24+DQo+IA0KPiANCj4gDQo+IEFuZHkN Cj4gDQo+IA0KDQo= From nobody Fri Jan 6 10:04:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30FF21295C9; Fri, 6 Jan 2017 10:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aSYtFbfAqVPr; Fri, 6 Jan 2017 10:04:18 -0800 (PST) Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 87899128824; Fri, 6 Jan 2017 10:04:17 -0800 (PST) Received: by mail-wm0-x242.google.com with SMTP id u144so6766952wmu.0; Fri, 06 Jan 2017 10:04:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language:disposition-notification-to; bh=il2hxBZjk7ZB4KVCTrre4FIhpssKsryxNFBaRi8T+6c=; b=UEfhIxN+KTwC3MvxAEmvAaNWc47qV1nxiwfFk0C8phS2xAUrbcvastULP1eGS4O2ns d7jZIL+2OQwvv2+7GA7WrsXVJ/SRIllPuxEpqCKgsKOwTl52KZdW7QefRDoCCq/KRh/J /x3btI6bzPOACLEimQymSC2YgbJ6DDtFI2oP0fvHL97lFnLGgalF/fUHuyOQ/3K8J8wx 8lOcylYi+u13he7PnHGDOjNU9xCaEYF7HAEsjCOcedQC4gb2LBMBDLPW1Gt0u46t1/xE xA9KCdNH2Uz32nMzGbzGjlpq0v10LXCzJmUU/77v+maL22k72Yi2YzxA7AzynGAWANvT U5Qg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language:disposition-notification-to; bh=il2hxBZjk7ZB4KVCTrre4FIhpssKsryxNFBaRi8T+6c=; b=julazoQsDtpalskSLIhXb2xavQZZbmki+oYYgWn+1WJwZbpMoX2Dfi7SUbWWp9IEg6 qLRjzHCVceg4nLkC7YvwhZFYOQLv/SDKk77K2vPuVypeYnR4EH6PAega0PMKO68JU+P2 AkF/IYAwycRKdldJNL/qWhvVZNRiCbjm2DzjYiQAht6D6oDKVwAKPqJeWFkoZlz1ROE9 oVMWfmIQcUdUZCzcijde6hRtbrcuemj4g6W3Mq04WYXLq1ggMRvWvWPjW2R6cWFcSJFp 7f0M4GJvWZ/tM76r1dn5XuA2VEPCHJJ/c/rsEqC/QjAroeMQsg2RGZqvdCbmjonBmijG 6AnA== X-Gm-Message-State: AIkVDXLPO7wCbCWeS+/mkTaa9GMS7bibUT5Lgw0UJJCIxRoBOponi3KToyWF6viULTphpA== X-Received: by 10.28.145.2 with SMTP id t2mr4030101wmd.23.1483725855931; Fri, 06 Jan 2017 10:04:15 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340C74.dip0.t-ipconnect.de. [91.52.12.116]) by smtp.gmail.com with ESMTPSA id ke6sm109931929wjb.21.2017.01.06.10.04.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 10:04:15 -0800 (PST) From: "Mehmet Ersue" To: "'Andy Bierman'" , "'Ladislav Lhotka'" Date: Fri, 6 Jan 2017 19:04:14 +0100 Message-ID: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0192_01D2684F.AC4565E0" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJne0TirCGAmbjyTxuK3L5tumskaw== Content-Language: de X-AVK-Virus-Check: AVA 25.9819;2DC73FAF X-AVK-Spam-Check: 1; str=0001.0A0C0205.586FDC1F.0054,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:04:20 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0192_01D2684F.AC4565E0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi All, =20 [NETMOD CCed as this is relevant to the revised DS draft] =20 > > > > I wrote it already several times: I support(ed) Mehmet's = proposal to make the revised-datastores I-D informative. The document = was adopted as a Standard Track WG item although I didn't see anything = close to rough consensus during the adoption poll. > > > > > > > It appears to me that there is consensus to making this a = standards track solution. > > > > > Where is any evidence of this? > > I think there was approval in the room in Seoul, and it is being = confirmed on the mailing list. It is correct that we agreed in Seoul to start a consensus call on both = maillists for the adoption of the DT draft and executed such an adoption = call. However we did not have any decision on the intended draft status in = Seoul and did not have any agreement during the adoption call. I = explained my concerns on the currently indicated status being standard = track and did not hear any other argument. =20 It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). =20 IMO the intended status of the DS draft is still open and subject to = decide. =20 Regards, Mehmet =20 From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman Sent: Wednesday, December 28, 2016 6:37 PM To: Ladislav Lhotka Cc: Netconf Subject: Re: [Netconf] :candidate, :writable-running and RESTCONF edits =20 =20 =20 On Wed, Dec 28, 2016 at 1:06 AM, Ladislav Lhotka > wrote: > On 27 Dec 2016, at 19:34, Andy Bierman > wrote: > > > > On Tue, Dec 27, 2016 at 10:01 AM, Ladislav Lhotka > wrote: > > > On 27 Dec 2016, at 16:37, Juergen Schoenwaelder = > wrote: > > > > On Tue, Dec 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote: > >> > >>> > >>> A remote API for management applications was our original target = and > >>> this is where YANG is doing well (and we apparently still have = work to > >>> do to improve things). > >> > >> By "management application" I mean a specific implementation with a = fixed set of datastores and precise semantics. I do argue that neither = RFC 6241, nor "revised-datastores" nor any other *specific* setup of = datastores is going to work for all use cases, yet the protocols and = YANG can be pretty universal. > >> > >> We have already seen YANG being used in areas that are, strictly = speaking, not supported by 6020/7950. Rather than tolerating such uses = (which is a slippery slope), I would prefer to make them - within = reasonable limits - officially supported. > >> > > > > This is too abstract for me. What do you suggest to change in the > > revised datastore architecture? I do believe that having a number of > > well defined datastores with specific semantics is necessary for > > having interoperability. > > I wrote it already several times: I support(ed) Mehmet's proposal to = make the revised-datastores I-D informative. The document was adopted as = a Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll. > > > > It appears to me that there is consensus to making this a standards = track solution. Where is any evidence of this? =20 =20 I think there was approval in the room in Seoul, and it is being = confirmed on the mailing list. =20 =20 > > Datastores allow universal concepts about managed data to be = standardized > across multiple protocols. In a protocol, the datastore name serves = as > an input parameter value. It needs to be normative in order for a > standards-track protocol to use it. For the protocol, the RPC parameter needs to be normative, not a = particular datastore name or semantics. > > Changing standards track status never addresses real technical = problems. > I do not understand your objections or alternate proposals. I think this proposal will lead to rather significant changes to the = protocols and YANG, and their extent IMO isn't clear yet. For one, the = draft aims at moving validation from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get how = validation in YANG can be (re)defined to apply also to implementations = that don't have "intended". =20 =20 =20 It should be possible to add new operations to NETCONF and new query parameters to RESTCONF that support the operator requirements, and still preserve existing operations. =20 I am not in favor of rewriting operations that move the validation to = 'intended'. That would not be backward-compatible so it is a non-starter. =20 =20 What I would like to do is to make protocols and YANG work equally well = for all datastore architectures so that the protocols and YANG needn't = be changed each time the current architecture is found to require = adjustments. =20 =20 This does not make sense to me. First, I do not care about non-standard, private architectures, just the standard architecture. Applications cannot be forced to hard-wire all = the details about configuration management. Let's not go back to data silo = architecture. =20 The standards need to expose the details in a common framework to enable data-driven automation tools. That means the protocols and the data = models have to support a standard datastore framework. =20 =20 > > My Applicability Statement concerns are related to developers deciding > if a server implementation needs to expose 'intended' and 'applied'. > I would like a definitive statement like "If an intended value takes = more than 5 seconds > to become applied (due to implementation, not missing hardware), then > the 'intended' and 'applied' datastores SHOULD be supported." > > I think the definitions of the datastores apply to all servers, and = the > set of new datastores is the correct and the semantics are clear. For some servers running-intended-applied is way too complicated, and = good old "running" may be all that's needed. =20 =20 Agreed. These servers do not need to implement the new datastores. The same is true for the 'candidate' and 'startup' datastores already. =20 Lada =20 =20 Andy =20 > > > Lada > > Andy > > > > > > /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: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 =20 ------=_NextPart_000_0192_01D2684F.AC4565E0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

Hi All,

 

[NETMOD CCed as this is relevant to the revised DS = draft]

 

> > > > I wrote it already = several times: I support(ed) Mehmet's proposal to make the = revised-datastores I-D informative. The document was adopted as a = Standard Track WG item although I didn't see anything close to rough = consensus during the adoption poll.
> > > >
> > = > It appears to me that there is consensus to making this a standards = track solution.
> > >
> > Where is any evidence of = this?
>
> I think there was approval in the room in Seoul, = and it is being confirmed on the mailing list.

It is correct that we agreed in Seoul to start a consensus call on both = maillists for the adoption of the DT draft and executed such an adoption = call.

However we did not have any decision on the intended draft status in = Seoul and did not have any agreement during the adoption call. I = explained my concerns on the currently indicated status being standard = track and did not hear any other argument.

 

It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. =C2=A0However = the current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example = in RFC 6244).

As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft).

 

IMO the intended status of the DS draft is still open and subject to = decide.

 

Regards,

Mehmet

 

From:<= /b> = Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Andy = Bierman
Sent: Wednesday, December 28, 2016 6:37 = PM
To: Ladislav Lhotka <lhotka@nic.cz>
Cc: = Netconf <netconf@ietf.org>
Subject: Re: [Netconf] = :candidate, :writable-running and RESTCONF edits

 

 

 

On Wed, = Dec 28, 2016 at 1:06 AM, Ladislav Lhotka <lhotka@nic.cz> = wrote:


> On 27 = Dec 2016, at 19:34, Andy Bierman <andy@yumaworks.com> = wrote:
>
>
>
> On Tue, Dec 27, 2016 at 10:01 AM, = Ladislav Lhotka <lhotka@nic.cz> = wrote:
>
> > On 27 Dec 2016, at 16:37, Juergen = Schoenwaelder <j.schoenwaelder@jaco= bs-university.de> wrote:
> >
> > On Tue, Dec = 27, 2016 at 03:47:10PM +0100, Ladislav Lhotka wrote:
> = >>
> >>>
> >>> A remote API for = management applications was our original target and
> >>> = this is where YANG is doing well (and we apparently still have work = to
> >>> do to improve things).
> >>
> = >> By "management application" I mean a specific = implementation with a fixed set of datastores and precise semantics. I = do argue that neither RFC 6241, nor "revised-datastores" nor = any other *specific* setup of datastores is going to work for all use = cases, yet the protocols and YANG can be pretty universal.
> = >>
> >> We have already seen YANG being used in areas = that are, strictly speaking, not supported by 6020/7950. Rather than = tolerating such uses (which is a slippery slope), I would prefer to make = them - within reasonable limits - officially supported.
> = >>
> >
> > This is too abstract for me. What do = you suggest to change in the
> > revised datastore = architecture? I do believe that having a number of
> > well = defined datastores with specific semantics is necessary for
> > = having interoperability.
>
> I wrote it already several = times: I support(ed) Mehmet's proposal to make the revised-datastores = I-D informative. The document was adopted as a Standard Track WG item = although I didn't see anything close to rough consensus during the = adoption poll.
>
>
>
> It appears to me that = there is consensus to making this a standards track = solution.

Where is any evidence of = this?

 

 

I = think there was approval in the room in Seoul, and it is being confirmed = on the mailing list.

 

 

>
> Datastores allow universal = concepts about managed data to be standardized
> across multiple = protocols.  In a protocol, the datastore name serves as
> an = input parameter value.  It needs to be normative in order for = a
> standards-track protocol to use it.

For the protocol, = the RPC parameter needs to be normative, not a particular datastore name = or semantics.

>
> Changing standards track status never = addresses real technical problems.
> I do not understand your = objections or alternate proposals.

I think this proposal will = lead to rather significant changes to the protocols and YANG, and their = extent IMO isn't clear yet. For one, the draft aims at moving validation = from "running" to "intended". But if = "intended" is optional to implement (sec. 6.1), I don't get = how validation in YANG can be (re)defined to apply also to = implementations that don't have = "intended".

 

 

 

It should be possible to add new operations to NETCONF = and

new query parameters = to RESTCONF that support the operator = requirements,

and still = preserve existing operations.

 

I = am not in favor of rewriting operations that move the validation to = 'intended'.

That would not = be backward-compatible so it is a = non-starter.

 

 


What I = would like to do is to make protocols and YANG work equally well for all = datastore architectures so that the protocols and YANG needn't be = changed each time the current architecture is found to require = adjustments.

 

 

This does not make sense to = me.

First, I do not care = about non-standard, private architectures, just = the

standard = architecture.  Applications cannot be forced to hard-wire all = the

details about = configuration management.  Let's not go back to data silo = architecture.

 

The standards need to expose the details in a common = framework to enable

data-driven automation tools.  That means the = protocols and the data models

have to support a standard datastore = framework.

 

 

>
> My Applicability Statement = concerns are related to developers deciding
> if a server = implementation needs to expose 'intended' and 'applied'.
> I would = like a definitive statement like "If an intended value takes more = than 5 seconds
> to become applied (due to implementation, not = missing hardware), then
> the 'intended' and 'applied' datastores = SHOULD be supported."
>
> I think the definitions of = the datastores apply to all servers, and the
> set of new = datastores is the correct and the semantics are clear.

For some = servers running-intended-applied is way too complicated, and good old = "running" may be all that's = needed.

 

 

Agreed.  These servers do not need to implement = the new datastores.

The = same is true for the 'candidate' and 'startup' datastores = already.

 


Lada

<= p class=3DMsoNormal> 

 

Andy

 

>
>
> Lada
>
> = Andy
>
>
> >
> > /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/>
>
>= ; --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: = 0xB8F92B08A9F76C67

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key = ID: = 0xB8F92B08A9F76C67




<= p class=3DMsoNormal> 

------=_NextPart_000_0192_01D2684F.AC4565E0-- From nobody Fri Jan 6 10:45:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A998129D99; Fri, 6 Jan 2017 10:45:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.3 X-Spam-Level: X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 GWcqTNs8JG4g; Fri, 6 Jan 2017 10:45:13 -0800 (PST) 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 5BB76129628; Fri, 6 Jan 2017 10:45:13 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id BAE1370D; Fri, 6 Jan 2017 19:45:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q0pIidqqd-cI; Fri, 6 Jan 2017 19:45:08 +0100 (CET) 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, 6 Jan 2017 19:45:11 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 73FEF20086; Fri, 6 Jan 2017 19:45:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vpsBm1jP5dIk; Fri, 6 Jan 2017 19:45:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2C45220085; Fri, 6 Jan 2017 19:45:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7B5353E03CC0; Fri, 6 Jan 2017 19:45:13 +0100 (CET) Date: Fri, 6 Jan 2017 19:45:13 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20170106184513.GA11816@elstar.local> Mail-Followup-To: Mehmet Ersue , 'Netconf' , 'NetMod WG' References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 18:45:15 -0000 On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > It is correct that we need a standard track document for the new DS framework - to provide a basis for other RFCs to develope. However the current DT solution draft has not been prepared as a standard track document nor it has standard relevant content. Such concept description is usually prepared as an architecture document (see example in RFC 6244). > > As I stated earlier I believe “a new protocol- and language-independent standard document†should be prepared defining the generic datastore framework (based on and following the concept in the DT solution draft). > To me, this sounds like duplicate work for no real technical value. If the existance of two WG results into actions like this, we should seriously consider the option to merge NETMOD and NETCONF into one WG. /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 Jan 6 11:05:28 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75934129BB0; Fri, 6 Jan 2017 11:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RZlwHeVxVlcq; Fri, 6 Jan 2017 11:05:21 -0800 (PST) Received: from mail-wm0-x244.google.com (mail-wm0-x244.google.com [IPv6:2a00:1450:400c:c09::244]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEA5E129BAE; Fri, 6 Jan 2017 11:05:20 -0800 (PST) Received: by mail-wm0-x244.google.com with SMTP id l2so7160644wml.2; Fri, 06 Jan 2017 11:05:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=XsJSqAzgPXgeMldoAiK8yHy1STtw3kzPXhJOnGdgjSk=; b=ndzVLfx/GsT3bF/2KxnbDsbmjJD9KXAaENT32ziVQ749O/AqhwTJXdfBXuUkUVKkSs nhotslw4yQYFGXcQcJhlitK+vG4+2o1OJ4EfYCSYWYuOe54Ed5BsgN43vDSWtg2Z/DFo Hy3wjfHngU5dJia2ORJHswdXkDF8QoKj4xKqg0yNqEo562/KXF0ZzcKXdDK12q52hfga h8kE5Bl0jCkwj0Skmnej2s0Yg3AVcb+poZuMU45A+6T9exRX0DPgd1SwPuSB4m/yCZVb i1TWEpEoKPCvEIzvJSdfqn1a2cJ6AK0JMMnHLpc2g07GX6rBDywYwn4N7H6pOrnq9JZU UaXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=XsJSqAzgPXgeMldoAiK8yHy1STtw3kzPXhJOnGdgjSk=; b=S7SV1d71lNTxRkH+UDhOiuYerUPh7IsZqTOyskKbGrHeUK15NfNOXiG5ya5UKor08E FtLdchDL1WvRWBolmsgH/mjceKKGGV/pbnLUM+GqDCCWyVCVH11b4CLufpNe6ZqiEcbx gMR2bO5TlPYpHHN5UEbCJrzMRTzvgztdJpcxxjWe3FJ4fO1xatWdXa5Tcxztv9o5lhXD VWt4ziKbQ7lA0Bo6V4Q3HkW61kavKUKe/5PRFhnpJczn4XjVzPshEQpLwxISHpKsoe4I iSyUTUlQdbmr79v4FUZKo+vBelCjHYIi9W54seYwBRYHjfEjLATQ6l/ipSSS3spaLDst mtHA== X-Gm-Message-State: AIkVDXJsr8ix4MVuqrRFtNAKmp9veZD0hf0QFgsYEmR7De3/nxLBizV6dfNWn5KR0DQRaA== X-Received: by 10.223.165.138 with SMTP id g10mr2324823wrc.157.1483729519222; Fri, 06 Jan 2017 11:05:19 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340C74.dip0.t-ipconnect.de. [91.52.12.116]) by smtp.gmail.com with ESMTPSA id m10sm10623073wjg.45.2017.01.06.11.05.18 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 06 Jan 2017 11:05:18 -0800 (PST) From: "Mehmet Ersue" To: "'Juergen Schoenwaelder'" References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> In-Reply-To: <20170106184513.GA11816@elstar.local> Date: Fri, 6 Jan 2017 20:05:17 +0100 Message-ID: <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQM68I+vWqVG6862+ZiAo2vzjtZG8wFL/2G6nlBdjpA= Content-Language: de X-AVK-Virus-Check: AVA 25.9819;2DC73FAF X-AVK-Spam-Check: 1; str=0001.0A0C0208.586FEA6E.0066,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: 'Netconf' , 'NetMod WG' Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:05:22 -0000 Hi Juergen, I don't think it is duplicate work. One is as I understand the = architecture and concept document you were asking for=20 and the other draft is the standard DS framework RFC to be used as the = basis for different documents. Cheers, Mehmet -----Original Message----- From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Friday, January 6, 2017 7:45 PM To: Mehmet Ersue Cc: 'Netconf' ; 'NetMod WG' Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS = Draft WAS:RE: :candidate, :writable-running and RESTCONF edits On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: >=20 > It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). >=20 > As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). >=20 To me, this sounds like duplicate work for no real technical value. If = the existance of two WG results into actions like this, we should = seriously consider the option to merge NETMOD and NETCONF into one WG. /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 Jan 6 11:57:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7740E129625 for ; Fri, 6 Jan 2017 11:57:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A3kFoHP4n2gQ for ; Fri, 6 Jan 2017 11:57:45 -0800 (PST) Received: from mail-qk0-x233.google.com (mail-qk0-x233.google.com [IPv6:2607:f8b0:400d:c09::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83856129407 for ; Fri, 6 Jan 2017 11:57:45 -0800 (PST) Received: by mail-qk0-x233.google.com with SMTP id u25so469930099qki.2 for ; Fri, 06 Jan 2017 11:57:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QoQqQ36oH6gMwkH0RTvlWFzRcsy1rWOsF8z3Fl7iQCA=; b=SIkZhMzff5ie6qjQsM7yw9JZBQomVcHJjBwN7Qe5Wenu1LhCqqNB/2jC7aq5pnwY8h 0ahQ8CboTQCnGlZ4jBqLT1/UgOcPXo3i5YLDiGWDehlAk/pZGOnUkgmIqmM+Unl6tEiQ 20tBaVG77OclAtk6FUjTUtmStBi8ifQY0hc9CKp/6EYs8gH+UIay3jYPXkRZWO7kQGbm JJVb6sDhah9OjL2avO5SEMl7DIZaLcmjb3BORPq0xQwvHicB33KlQhkMXdV427RKOv20 I/kOTdbQV88YCL/wOqgrolR4aCka/k+NWGYZhbC0Q9POoFS6TfhxXKd5ntXJcFAqXqbo ttyw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=QoQqQ36oH6gMwkH0RTvlWFzRcsy1rWOsF8z3Fl7iQCA=; b=rP4HWeshY5U7jEsIx+JDmLmNfWbDMLLVhJmIazooye+O3H8CrpD4QeNiUbissyw89D fO8wEdiTvWPVqj3i6KmdVGT47/iSJXwLXF2iMCQIcCqB1nQ1PamfcJAgDw9HgJjoMHy+ UVvJwAIDVJVHGpFj4vyWwQ5Jfam0S9PdCV2QZEr6jCUr10yuI9/oRtGw2gC/GAgdghs6 GwXXsZlQ0ngEB3gzHcD68awdDTMxAsMClST4nv+Y/0OXjY3q9zMjUKGf3JnrQYQ/ed6v Q+deeuJs2lyEqDrP+HEMM/Jn0fdnUYWFTUMlOuClczWEt/jhP2WPqZC4Lv+vF2LfWp1I wAlA== X-Gm-Message-State: AIkVDXLzcqEzZQfZEH/fTRMO8kOn7eCsAv/PoyH1lslB4TEXD5wE9NEwYWFpH8qeRJ6uzWFc/PpgmtuPYVcTmg== X-Received: by 10.55.20.137 with SMTP id 9mr6547317qku.237.1483732664698; Fri, 06 Jan 2017 11:57:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Fri, 6 Jan 2017 11:57:44 -0800 (PST) In-Reply-To: <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> From: Andy Bierman Date: Fri, 6 Jan 2017 11:57:44 -0800 Message-ID: To: Mehmet Ersue Content-Type: multipart/alternative; boundary=001a1144d2266be35c0545726efa Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 06 Jan 2017 19:57:48 -0000 --001a1144d2266be35c0545726efa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue wrote: > Hi Juergen, > > I don't think it is duplicate work. One is as I understand the > architecture and concept document you were asking for > and the other draft is the standard DS framework RFC to be used as the > basis for different documents. > > I do not understand the difference between these 2 documents. There should be 1 document that is protocol-independent that includes: - definition of datastores - discussion of interactions between datastores - use-cases in scope for new datastores - applicability guidance for server developers Each protocol that wants to use these new datastores needs to define mechanisms to do that in a separate document. Cheers, > Mehmet > Andy > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, January 6, 2017 7:45 PM > To: Mehmet Ersue > Cc: 'Netconf' ; 'NetMod WG' > Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS > Draft WAS:RE: :candidate, :writable-running and RESTCONF edits > > On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > > > It is correct that we need a standard track document for the new DS > framework - to provide a basis for other RFCs to develope. However the > current DT solution draft has not been prepared as a standard track > document nor it has standard relevant content. Such concept description i= s > usually prepared as an architecture document (see example in < > https://tools.ietf.org/html/rfc6244> RFC 6244). > > > > As I stated earlier I believe =E2=80=9Ca new protocol- and language-ind= ependent > standard document=E2=80=9D should be prepared defining the generic datast= ore > framework (based on and following the concept in the DT solution draft). > > > > To me, this sounds like duplicate work for no real technical value. If th= e > existance of two WG results into actions like this, we should seriously > consider the option to merge NETMOD and NETCONF into one WG. > > /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 > --001a1144d2266be35c0545726efa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue <mersue@gmail.com>= wrote:
Hi Juergen,

I don't think it is duplicate work. One is as I understand the architec= ture and concept document you were asking for
and the other draft is the standard DS framework RFC to be used as the basi= s for different documents.


I do not understand the difference bet= ween these 2 documents.

There should be 1 document= that is protocol-independent that includes:
=C2=A0 =C2=A0- defin= ition of datastores
=C2=A0 =C2=A0- discussion of interactions bet= ween datastores
=C2=A0 =C2=A0- use-cases in scope for new datasto= res
=C2=A0 =C2=A0- applicability guidance for server developers

Each protocol that wants to use these new datastore= s needs to define
mechanisms to do that in a separate document.




Cheers,
Mehmet


Andy
= =C2=A0

-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
Sent: Friday, January 6, 2017 7:45 PM
To: Mehmet Ersue <mersue@gmail.com>
Cc: 'Netconf' <netconf@ietf.= org>; 'NetMod WG' <net= mod@ietf.org>
Subject: Re: [Netconf] Decision on the Intended Status of the Revised DS Dr= aft WAS:RE: :candidate, :writable-running and RESTCONF edits

On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote:
>
> It is correct that we need a standard track document for the new DS fr= amework - to provide a basis for other RFCs to develope.=C2=A0 However the = current DT solution draft has not been prepared as a standard track documen= t nor it has standard relevant content. Such concept description is usually= prepared as an architecture document (see example in=C2=A0 <h= ttps://tools.ietf.org/html/rfc6244> RFC 6244).
>
> As I stated earlier I believe =E2=80=9Ca new protocol- and language-in= dependent standard document=E2=80=9D should be prepared defining the generi= c datastore framework (based on and following the concept in the DT solutio= n draft).
>

To me, this sounds like duplicate work for no real technical value. If the = existance of two WG results into actions like this, we should seriously con= sider the option to merge NETMOD and NETCONF into one WG.

/js

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

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

--001a1144d2266be35c0545726efa-- From nobody Fri Jan 6 20:22:02 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78760129785 for ; Fri, 6 Jan 2017 20:22:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zlfk6saTq2vC for ; Fri, 6 Jan 2017 20:21:59 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C8D129739 for ; Fri, 6 Jan 2017 20:21:59 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l7so46815325qtd.1 for ; Fri, 06 Jan 2017 20:21:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=NoFCfNgKmA7JFhNctRA6V/YXiXR1JzzWt6X1c5URGk8=; b=2Horhk1OWRMehSrmJrv06iMBbWeIDB6bzFe9NkM610wizgqDCVRhKpXZh5B212O0HS PgzDAa+Mm9IrwOPrjTARuHeDjhZiyjzwymGT44GAa3GFAQNzud3c+q3WzVF1WplMAqoH jeJD2T62Vlo67rmI+bT4K+HlBj1J+7a49VkQ37T8twLkTmP1s1Nr94tkMCzksCpedeSg ff6LPCofiXJ5xZBcGXRrykSN0WqP7wWyHpod5h5pz7e2HByVbpOQUKG9CG4aXHFhd5QM GGsqtfas9dH0NYj+Xg9E8vJwuBe6tWUd3TEzfETCChR+hfzALEQVDqQQaBZhJcbC1AMh BvEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=NoFCfNgKmA7JFhNctRA6V/YXiXR1JzzWt6X1c5URGk8=; b=MlQBeivgKkC2PFlhDsNw1TgRzOw8XKbm4XwX0PoSuQvo95xCLV0uMHQqAPPt9xKzhb 2ie5Lx+MK7KM5OJ8AK5slhC8VDsE+KIYMELnhWzJquBOCbag6CBsye7+tydRXhGeFkzo DMYmoryiOO/WZRjWXNf1CoJ9T4ttKYVlIu0odGT+BWfxztY1rT7Kl4wqAdlSiht1Fpsj mYcM8vlAiBLpYfzA7ZMtopXk1mJQv3JAMlbkPZypXEXINNOUB1qx6szse07JhjDaW94p OKvZqMjMjtDDLq6fFfAMe6z8r3CVKOsBWFH5OLlhyOHh38jz/HlvgyCq8mEI5V6Sgpbg luOA== X-Gm-Message-State: AIkVDXIBRsNCQIXYo6LR5+sHCD95MklGzGEt9L9RudEedb651tiLPewh3BxnLPRu2Vrj3S2zYULSZgW6RIqVVg== X-Received: by 10.237.34.239 with SMTP id q44mr2969839qtc.18.1483762918375; Fri, 06 Jan 2017 20:21:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Fri, 6 Jan 2017 20:21:57 -0800 (PST) In-Reply-To: References: <39b938d3504f4599bf4e92a48b685a0a@XCH-RTP-013.cisco.com> From: Andy Bierman Date: Fri, 6 Jan 2017 20:21:57 -0800 Message-ID: To: "Eric Voit (evoit)" Content-Type: multipart/alternative; boundary=001a113e7aeeae56ca05457979ea Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 07 Jan 2017 04:22:01 -0000 --001a113e7aeeae56ca05457979ea Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) wrote: > > From: Andy Bierman, January 5, 2017 9:43 PM > > > > On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) evoit@cisco.com> > > wrote: > > Hi Andy, > > > > =E2=80=9CThe innermost container or list=E2=80=9D text is similar to th= at for actions in > section > > 7.15.2. Perhaps the mental model of one target for an action was > replicated? > > > > I had not considered that YANG 1.1=E2=80=99s definition might force the= breakup > of a > > verbose software component generated notification into multiple pushed > > notification messages. Looking at the three cases below, I don=E2=80= =99t think > that > > arbitrary choices made in YANG model structure should impact what could > or > > couldn=E2=80=99t be in encoded within any single notification. So my p= reference > would > > be that all three variants below should supportable if that is how the > system > > passed them to be encoded as part of an event. > > > > > > > > I think the WG did not consider these details and assumed they were the > same > > as for action. > > > > This would be a MAY for the server and a MUST for the client, so it is > not > > an easy decision. > > > > A couple use-cases I have in mind: > > > > 1) event broker > > subscriber is really a broker that may be pre-processing lots of > > subscriptions or event types within 1 subscription > > > > 2) digest (time-based push) > > Subscriber wants an update every 5 seconds with all the YANG 1.1 > events > > for the previous 5 seconds > > These are both reasonable as controllers are requiring scalable methods o= f > synching on device status. > > > What if the reinterpretation were as simple as =E2=80=9CAn innermost=E2= =80=9D or =E2=80=9CThe > first > > innermost=E2=80=9D? > > > > This covers case 2. (Change "The" to "An"). > > The client would need to check for YANG 1.1 notifications in the > > same way it checks child nodes already. > > "Any innermost"...? And yes, this is a more significant change on the > client. Beyond this, for use cases (1) & (2), if you don't want to > summarize the eventTime, the time should be placed with each innermost > event. I am not suggesting we do this, but like Andy I want to figure ou= t > what the WG might be willing to consider in scope. > > There was actually a lot of discussion about "eventTime" in the NETCONF WG when RFC 5277 was done. Lots of disagreement on what it means. The RFC offers little guidance or hint of the discussion: eventTime: The time the event was generated by the event source. It may take the server some time to detect the event after it occurs. It may take some time to save the event for replay and transmission. Which of these 3 different times is it? (Out of scope I think) Adding more timestamps is an interesting idea. But I think something like this could be done without a client MUST. The client MAY request 'bulk-encoding' and if the server supports it, a more optimized structure would be sent instead of the normal message. The receiver MAY extract individual messages from the bulk format (maybe binary) into other formats (like XML or JSON). I am trying to plan ahead for when YANG Push turns out to be a slow network hog :-) Eric > > Andy > Eric > > > > > > Andy > > > > From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On Behalf Of And= y > > Bierman > > Sent: Thursday, January 5, 2017 5:25 PM > > To: Netconf > > Subject: [Netconf] nested notifications > > > > Hi, > > > > I would like some text in RFC 7950 to be reinterpreted. The text implie= s > each > > notification message can only describe 1 instance of 1 event type. > > > > RFC 7950, sec 7.16.2 > > > > The innermost container or list contains an XML > > element that carries the name of the defined notification. > > > > > > There are 3 corner-cases that should be considered in order > > to minimize network overhead for notifications in 5277bis. > > Replicating the node/key hierarchy could be expensive > > and events occurring at the same time could be correlated. > > > > Duplicating the notification messages is inefficient, > > but processing multiple events per message makes > > filtering and parsing more complicated. > > > > I am curious if the WG thinks notification overhead is a concern and > > if it needs to be addressed somehow in 5277bis. > > > > > > 1) multiple non-sibling events in same subtree > > > > > > > > > > 42 > > > > > > eth0 > > > > auto > > > > > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > > eth0 > > > > auto > > > > > > admin > > > > > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > > > > 42 > > > > > > > > > > eth0 > > > > auto > > > > > > > > > > > > > > > > Andy > > > > > > --001a113e7aeeae56ca05457979ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) <= ;evoit@cisco.com&g= t; wrote:
> From: Andy Bierman, January 5, 20= 17 9:43 PM
>
> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) <mailto:evoit@cisco.com>
> wrote:
> Hi Andy,
>
> =E2=80=9CThe innermost container or list=E2=80=9D text is similar to t= hat for actions in section
> 7.15.2.=C2=A0=C2=A0 Perhaps the mental model of one target for an acti= on was replicated?
>
> I had not considered that YANG 1.1=E2=80=99s definition might force th= e breakup of a
> verbose software component generated notification into multiple pushed=
> notification messages.=C2=A0 Looking at the three cases below, I don= =E2=80=99t think that
> arbitrary choices made in YANG model structure should impact what coul= d or
> couldn=E2=80=99t be in encoded within any single notification.=C2=A0 S= o my preference would
> be that all three variants below should supportable if that is how the= system
> passed them to be encoded as part of an event.
>
>
>
> I think the WG did not consider these details and assumed they were th= e same
> as for action.
>
> This would be a MAY for the server and a MUST for the client, so it is= not
> an easy decision.
>
> A couple use-cases I have in mind:
>
> =C2=A0 1) event broker
> =C2=A0 =C2=A0 =C2=A0 subscriber is really a broker that may be pre-pro= cessing lots of
> =C2=A0 =C2=A0 =C2=A0 subscriptions or event types within 1 subscriptio= n
>
> =C2=A0 =C2=A02) digest (time-based push)
> =C2=A0 =C2=A0 =C2=A0Subscriber wants an update every 5 seconds with al= l the YANG 1.1 events
> =C2=A0 =C2=A0 for the previous 5 seconds

These are both reasonable as controllers are requiring scalable methods of = synching on device status.

> What if the reinterpretation were as simple as =E2=80=9CAn innermost= =E2=80=9D or =E2=80=9CThe first
> innermost=E2=80=9D?
>
> This covers case 2. (Change "The" to "An").
> The client would need to check for YANG 1.1 notifications in the
> same way it checks child nodes already.

"Any innermost"...?=C2=A0 =C2=A0And yes, this is a more significa= nt change on the client.=C2=A0 Beyond this, for use cases (1) & (2), if= you don't want to summarize the eventTime, the time should be placed w= ith each innermost event.=C2=A0 I am not suggesting we do this, but like An= dy I want to figure out what the WG might be willing to consider in scope.<= br>


There was actually a lo= t of discussion about "eventTime" in the NETCONF WG when RFC 5277= was done.
Lots of disagreement on what it means.=C2=A0 The RFC o= ffers little guidance or hint of the discussion:

<= br>
=C2=A0 =C2=A0 eventTime:
=C2=A0 =C2=A0 =C2=A0 =C2=A0The time the event wa= s generated by the event source.

It may tak= e the server some time to detect the event after it occurs.
It ma= y take some time to save the event for replay and transmission.
W= hich of these 3 different times is it? (Out of scope I think)
Adding more timestamps is an interesting idea.

But I think something like this could be done without a client MUS= T.
The client MAY request 'bulk-encoding' and if the serv= er supports it,
a more optimized structure would be sent instead = of the normal message.
The receiver MAY extract individual messag= es from the bulk format (maybe binary)
into other formats (like X= ML or JSON).

I am trying to plan ahead for when YA= NG Push turns out to be a slow network hog :-)

Eric


=C2=A0Andy

> Eric
>
>
> Andy
>
> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On Beha= lf Of Andy
> Bierman
> Sent: Thursday, January 5, 2017 5:25 PM
> To: Netconf <mailto:netconf@iet= f.org>
> Subject: [Netconf] nested notifications
>
> Hi,
>
> I would like some text in RFC 7950 to be reinterpreted. The text impli= es each
> notification message can only describe 1 instance of 1 event type.
>
> RFC 7950, sec 7.16.2
>
> =C2=A0=C2=A0 The innermost container or list contains an XML
> =C2=A0=C2=A0 element that carries the name of the defined notification= .
>
>
> There are 3 corner-cases that should be considered in order
> to minimize network overhead for notifications in 5277bis.
> Replicating the node/key hierarchy could be expensive
> and events occurring at the same time could be correlated.
>
> Duplicating the notification messages is inefficient,
> but processing multiple events per message makes
> filtering and parsing more complicated.
>
> I am curious if the WG thinks notification overhead is a concern and > if it needs to be addressed somehow in 5277bis.
>
>
> 1) multiple non-sibling events in same subtree
>
> =C2=A0 <notification>
> =C2=A0=C2=A0=C2=A0 <interfaces>
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0<my-top-event>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <my-data>42</my-da= ta>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-top-event>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <interface>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name&g= t;
> =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0<my-interface-event><= br> > =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<if-data>auto</if-data>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event>=
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </interface>
> =C2=A0=C2=A0=C2=A0 </interfaces>
> =C2=A0 </notification>
>
>
> 2) multiple sibling events in the same subtree
>
> =C2=A0 <notification>
> =C2=A0=C2=A0=C2=A0 <interfaces>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <interface>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name&g= t;
> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0<my-interface-event><= br> > =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<if-data>auto</if-data>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event>=
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <interface-enabled> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <by-us= er>admin</by-user>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </interface-enabled><= br> > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</interface>
> =C2=A0=C2=A0=C2=A0 </interfaces>
> =C2=A0 </notification>
>
>
> 3) multiple non-sibling events in different subtrees
>
> =C2=A0 <notification>
> =C2=A0=C2=A0=C2=A0 <system>
> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0<my-system-event>
> =C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<= ;my-data>42</my-data>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-system-event>
> =C2=A0=C2=A0=C2=A0 </system>
> =C2=A0=C2=A0=C2=A0 <interfaces>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <interface>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 <name>eth0</name&g= t;
> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<my-interface-event><= br> > =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<if-data>auto</if-data>
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </my-interface-event>=
> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 </interface>
> =C2=A0=C2=A0=C2=A0 </interfaces>
> =C2=A0 </notification>
>
>
>
> Andy
>
>


--001a113e7aeeae56ca05457979ea-- From nobody Mon Jan 9 04:24:44 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25A53129C59; Mon, 9 Jan 2017 04:24:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 12xJmiRRhu2X; Mon, 9 Jan 2017 04:24:39 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3515129C56; Mon, 9 Jan 2017 04:24:30 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec] (unknown [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec]) by mail.nic.cz (Postfix) with ESMTPSA id 9306860091; Mon, 9 Jan 2017 13:24:29 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483964669; bh=BXFYYSLU9g+QpJzAZo0qrI8cKw+WY8QEN5JUpwsUaRA=; h=From:Date:To; b=wu9pLl/GgSNK/ULaSILUdflohSWYwUvJTC4u+yCVYOHSpXpKlQCAU4Kww2stRHxV+ ymGhSlu+/sksaMDrGE9pIAlHhmIA4cXrSWrdUaaqloTjovZNJMR03g32xsqF4gR6Ei +50jckyQKxdKfpnYJgXlogUH1XCEz9wcFZlNnAUU= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Jan 2017 13:24:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:24:41 -0000 > On 6 Jan 2017, at 20:57, Andy Bierman wrote: >=20 >=20 >=20 > On Fri, Jan 6, 2017 at 11:05 AM, Mehmet Ersue = wrote: > Hi Juergen, >=20 > I don't think it is duplicate work. One is as I understand the = architecture and concept document you were asking for > and the other draft is the standard DS framework RFC to be used as the = basis for different documents. >=20 >=20 > I do not understand the difference between these 2 documents. >=20 > There should be 1 document that is protocol-independent that includes: > - definition of datastores > - discussion of interactions between datastores > - use-cases in scope for new datastores > - applicability guidance for server developers The current document involves quite a lot of hand-waving, and that's why = I was also reluctant to accept it as a WG standard-track deliverable. I = don't care that much about the number of documents that depend on it = because any mistakes may be pretty expensive here. I pointed out some = gaps in my previous review, e.g. it talks about templates without = defining what they are. If running contains templates, does it mean it = needn't be valid according to the data model? >=20 > Each protocol that wants to use these new datastores needs to define > mechanisms to do that in a separate document. >=20 That's one part, the other are changes inflicted to YANG. I think the = best way would be to make YANG independent of a particular setup of = datastores and their semantics. Then I2RS or anybody else can do = whatever they need without affecting YANG spec any more. I believe this wouldn't be a terribly difficult thing to do, but Juergen = wants me to write a meta-model document first. Lada >=20 >=20 >=20 > Cheers, > Mehmet >=20 >=20 > Andy > =20 >=20 > -----Original Message----- > From: Juergen Schoenwaelder = [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Friday, January 6, 2017 7:45 PM > To: Mehmet Ersue > Cc: 'Netconf' ; 'NetMod WG' > Subject: Re: [Netconf] Decision on the Intended Status of the Revised = DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits >=20 > On Fri, Jan 06, 2017 at 07:04:14PM +0100, Mehmet Ersue wrote: > > > > It is correct that we need a standard track document for the new DS = framework - to provide a basis for other RFCs to develope. However the = current DT solution draft has not been prepared as a standard track = document nor it has standard relevant content. Such concept description = is usually prepared as an architecture document (see example in = RFC 6244). > > > > As I stated earlier I believe =E2=80=9Ca new protocol- and = language-independent standard document=E2=80=9D should be prepared = defining the generic datastore framework (based on and following the = concept in the DT solution draft). > > >=20 > To me, this sounds like duplicate work for no real technical value. If = the existance of two WG results into actions like this, we should = seriously consider the option to merge NETMOD and NETCONF into one WG. >=20 > /js >=20 > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 04:38:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC407129453 for ; Mon, 9 Jan 2017 04:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.657 X-Spam-Level: X-Spam-Status: No, score=-2.657 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, RCVD_IN_MSPIKE_H2=-1.156, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OjSuD-lmIi32 for ; Mon, 9 Jan 2017 04:38:19 -0800 (PST) Received: from gproxy5-pub.mail.unifiedlayer.com (gproxy5-pub.mail.unifiedlayer.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 39275129C21 for ; Mon, 9 Jan 2017 04:38:19 -0800 (PST) Received: (qmail 30363 invoked by uid 0); 9 Jan 2017 12:38:17 -0000 Received: from unknown (HELO cmgw3) (10.0.90.84) by gproxy5.mail.unifiedlayer.com with SMTP; 9 Jan 2017 12:38:17 -0000 Received: from box313.bluehost.com ([69.89.31.113]) by cmgw3 with id WCeD1u00Y2SSUrH01CeGW0; Mon, 09 Jan 2017 05:38:17 -0700 X-Authority-Analysis: v=2.1 cv=YpOcGeoX c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=kj9zAlcOel0A:10 a=IgFoBzBjUZAA:10 a=oJz0gAw5pYE2X979_FIA:9 a=CjuIK1q_8ugA:10 a=NBv74QYyziwA:10 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:CC:To:From; bh=JGRqTlhAGLB4rQ5r3xVZ0jVcjYebXj6qchg21VR7+BI=; b=Xbmo3mFw+z8Pus1D4Va2RDegHd Keo+fPLyC0/0X36gw10Ay9Fqkcm4ku9e+OJ8emxKz04W0jFaZIS89HTSQqZGou82YH4rG50+TVCFX AeGUUPfV6GZOfRGrhCPuqq+Fh; Received: from pool-100-15-85-191.washdc.fios.verizon.net ([100.15.85.191]:46561 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1cQZDJ-00055h-8p; Mon, 09 Jan 2017 05:38:13 -0700 From: Lou Berger To: Ladislav Lhotka , Andy Bierman Date: Mon, 09 Jan 2017 07:38:11 -0500 Message-ID: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> In-Reply-To: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> User-Agent: AquaMail/1.7.1-88 (build: 100700100) MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="us-ascii" Content-Transfer-Encoding: 8bit X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - box313.bluehost.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-BWhitelist: no X-Source-IP: 100.15.85.191 X-Exim-ID: 1cQZDJ-00055h-8p X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: pool-100-15-85-191.washdc.fios.verizon.net ([11.4.0.238]) [100.15.85.191]:46561 X-Source-Auth: lberger@labn.net X-Email-Count: 1 X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ== Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:38:21 -0000 On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > > The current document involves quite a lot of hand-waving, and that's why I > was also reluctant to accept it as a WG standard-track deliverable. IMO I think we should do and document the work and then, once the is general agreement, worry about number and publication status of documents. Lou From nobody Mon Jan 9 04:50:50 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 103DF129C5E; Mon, 9 Jan 2017 04:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQQV_3g3LmyK; Mon, 9 Jan 2017 04:50:48 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30590129C5C; Mon, 9 Jan 2017 04:50:47 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec] (unknown [IPv6:2a01:5e0:29:fffe:4589:6a62:5975:ccec]) by mail.nic.cz (Postfix) with ESMTPSA id 227BF60963; Mon, 9 Jan 2017 13:50:46 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483966246; bh=ZUcP8X8+ftRaSAbtmVvGil2Mj+98s7GNAHEduO+b3w4=; h=From:Date:To; b=QKZn9CrcO/AUSowUjWVVmt4KYsBuqXKVcxC8Z8vfvGe2cGLCIHYcUwt+JUacq155+ FCQk1Egd++J+lMFqz145BhSU/hUDzDGwIWMciSiIjzuZRlcvQOJIKpnIJrHigr7Unw FcwUyCkJ4bDXjfQsmSeA25LyCu2zleYCPWdDADNI= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Date: Mon, 9 Jan 2017 13:50:45 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> To: Lou Berger X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 12:50:49 -0000 > On 9 Jan 2017, at 13:38, Lou Berger wrote: >=20 >=20 >=20 > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: >>=20 >> The current document involves quite a lot of hand-waving, and that's = why I was also reluctant to accept it as a WG standard-track = deliverable. >=20 > IMO I think we should do and document the work and then, once the is = general agreement, worry about number and publication status of = documents. I agree, but we have to accept it will take some time. The problem I see = is that quite a few people already work with the solution. Lada=20 >=20 > Lou >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 10:37:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10B41129851 for ; Mon, 9 Jan 2017 10:37:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A1EH83pTZ2lq for ; Mon, 9 Jan 2017 10:37:17 -0800 (PST) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BC1E12984C for ; Mon, 9 Jan 2017 10:37:17 -0800 (PST) Received: by mail-qt0-x231.google.com with SMTP id l7so95116188qtd.1 for ; Mon, 09 Jan 2017 10:37:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MX6yOnVUFSGwiHUfxMVAH8/48agyYRKJ+Usifm+uoZo=; b=dJvYP/TnBC8ohWm95hon++6Wkm8YSn/GivpwuMj46D9a1QDE7FxTUuqNrJiy6YNl98 YPjC4VWHYHrA2LaQrYtYR6oqyzPw4CY+kcZ3WGjvc2QmFQxbwg+9wLxwsxKhQExNnVuq Urjk8zVdp9UGEYsvSz+gCqXKZiVjIUhDp+IChU+tLHzOn9ZHlmTKGtPcCm2o7vzsbcBy Sux6nGMP977gnM2t+GXOi70g5nWlp0km2xz6ienxR3rMVm8Ue9rbGdjwjzCFhThfJTpN XAb5lQ1rtNau88QXe4LB7+995elt4+i6+BoWbuZN+qnbufkBidOsI5DpoHf+Lj4g8OEy 2taA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MX6yOnVUFSGwiHUfxMVAH8/48agyYRKJ+Usifm+uoZo=; b=fW0QgSSmT6vmtHTJzCfE9EAUcZp9+aoOs1lJPo7rUi+O1Qv1MIkK8jIE2idKW3IFLX v6ByFcrDiDFJKXljG+h9x9vJpDyn1X1LC9EoZs/7S16a7x+XpwCYmHi62SwoqU80eUAG ltPU67jpe5f0Y3G9Ei1UhycIMIAZF5mOHlHjsqfqmmcoDSL4T9aTrJok48qVCWKqng7p 7C7lpvmQ3uv60cX04XXxSmorTRnRRLS9QnqDtAw58kvyaT8QGylsm85/BQGMMVDaAWPZ q14kIyydLdnf9+8Edho9cE29ze3B3myHr0IboIVPmWyiNAJPN4s48SGOpFRoDy9js9jn rZAw== X-Gm-Message-State: AIkVDXJ1wk1RzWGXVXyKpUFsxf0IoPUS+x13Xgve1C7SNp+B4Mf01jDMc2WMIITjQK/6Lm78CQf1f/rEI3qN9A== X-Received: by 10.237.34.239 with SMTP id q44mr12276095qtc.18.1483987036426; Mon, 09 Jan 2017 10:37:16 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 10:37:16 -0800 (PST) In-Reply-To: <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> From: Andy Bierman Date: Mon, 9 Jan 2017 10:37:16 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a113e7aee2875c70545ada855 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 18:37:19 -0000 --001a113e7aee2875c70545ada855 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka wrote: > > > On 9 Jan 2017, at 13:38, Lou Berger wrote: > > > > > > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > >> > >> The current document involves quite a lot of hand-waving, and that's > why I was also reluctant to accept it as a WG standard-track deliverable. > > > I do not agree with this hand-waving assessment. What are the show-shoppers? I agree the draft is light on use-cases. There are no standard mechanisms that cause to be different from , so I would agree the intended datastore needs a lot more standards support before it is useful. > > IMO I think we should do and document the work and then, once the is > general agreement, worry about number and publication status of documents. > > I agree, but we have to accept it will take some time. The problem I see > is that quite a few people already work with the solution. > > The solutions I've seen were not very good, so they need a lot of work. I expect that the operational datastore will be more widely implemented than any of the others. Designing a replacement is not that difficult. Lada > Andy > > > > > Lou > > > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a113e7aee2875c70545ada855 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:

> On 9 Jan 2017, at 13:38, Lou Berger <lberger@labn.net> wrote:
>
>
>
> On January 9, 2017 7:25:24 AM Ladislav Lhotka <lhotka@nic.cz> wrote:
>>
>> The current document involves quite a lot of hand-waving, and that= 's why I was also reluctant to accept it as a WG standard-track deliver= able.
>


I do not agree with= this hand-waving assessment.
What are the show-shoppers?

I agree the draft is light on use-cases.
There = are no standard mechanisms that cause <running> to be
diffe= rent from <intended>, so I would agree the intended datastore
needs a lot more standards support before it is useful.


=C2=A0
> IMO I think we should do and document the work and then, once the is g= eneral agreement,=C2=A0 worry about number and publication status of docume= nts.

I agree, but we have to accept it will take some time. The problem I see is= that quite a few people already work with the solution.


The solutions I've seen were not v= ery good, so they need a lot of work.
I expect that the operation= al datastore will be more widely implemented
than any of the othe= rs.=C2=A0 Designing a <get> replacement is not that difficult.
<= div>


Lada

Andy
=C2=A0

>
> Lou
>
>

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






--001a113e7aee2875c70545ada855-- From nobody Mon Jan 9 12:18:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14359129631; Mon, 9 Jan 2017 12:18:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V4dVAcSsBoHH; Mon, 9 Jan 2017 12:18:49 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B675E1295B0; Mon, 9 Jan 2017 12:18:48 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:4c91:54e5:3faf:470f] (unknown [IPv6:2a01:5e0:29:fffe:4c91:54e5:3faf:470f]) by mail.nic.cz (Postfix) with ESMTPSA id 44DDC61366; Mon, 9 Jan 2017 21:18:47 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1483993127; bh=S0WvRVzvIb2uE7wfCTG4BNfdPsQ+YhPVFquypgO49rM=; h=From:Date:To; b=EWTzFfRDZAnt0O9crEujCkD0Guk/mLBQjMgQvU2baEjNtjDYFT7tjNxADzuyUf+DX nehaVBUWwYjiIHocOAantFktqnLK4HHuaK6MSS0UrcK+ltU2ag/7Yl6bq9MIPjzBdP 2osmid/vVzeeG4upoE7aYQV2+qFZkkCUgTHVrWY0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 9 Jan 2017 21:18:46 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:18:51 -0000 > On 9 Jan 2017, at 19:37, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Jan 9, 2017 at 4:50 AM, Ladislav Lhotka wrote: >=20 > > On 9 Jan 2017, at 13:38, Lou Berger wrote: > > > > > > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: > >> > >> The current document involves quite a lot of hand-waving, and = that's why I was also reluctant to accept it as a WG standard-track = deliverable. > > >=20 >=20 > I do not agree with this hand-waving assessment. > What are the show-shoppers? >=20 > I agree the draft is light on use-cases. I am more concerned about use cases that are not known so far, and so I = am against standardizing this (or any other) workflow as the only one = supported by NETCONF/RESTCONF and YANG. I believe both the protocols and = YANG can work with any set of datastores, but their choice depends on = the use case at hand. Why should IoT developers be exposed to the = running-intended-applied complexity, even if they are allowed to lump = all three into one? =20 > There are no standard mechanisms that cause to be > different from , so I would agree the intended datastore > needs a lot more standards support before it is useful. >=20 The only difference seems to be the presence of templates but I don't = know what they are. Lada >=20 > =20 > > IMO I think we should do and document the work and then, once the is = general agreement, worry about number and publication status of = documents. >=20 > I agree, but we have to accept it will take some time. The problem I = see is that quite a few people already work with the solution. >=20 >=20 > The solutions I've seen were not very good, so they need a lot of = work. > I expect that the operational datastore will be more widely = implemented > than any of the others. Designing a replacement is not that = difficult. >=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > Lou > > > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 >=20 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 9 12:51:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DEAAE1295B7; Mon, 9 Jan 2017 12:51:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 oaEdi9JNwjfn; Mon, 9 Jan 2017 12:51:15 -0800 (PST) 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 D47771294B6; Mon, 9 Jan 2017 12:51:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D2AB36CE; Mon, 9 Jan 2017 21:51:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id w1-yI4yVqttT; Mon, 9 Jan 2017 21:51:11 +0100 (CET) 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, 9 Jan 2017 21:51:12 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4F1DF2008C; Mon, 9 Jan 2017 21:51:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9bPT3Df__RAE; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3D15120089; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3962B3E072CB; Mon, 9 Jan 2017 21:51:11 +0100 (CET) Date: Mon, 9 Jan 2017 21:51:11 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170109205109.GA15144@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 20:51:18 -0000 On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > I am more concerned about use cases that are not known so far, and so I am against standardizing this (or any other) workflow as the only one supported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work with any set of datastores, but their choice depends on the use case at hand. Why should IoT developers be exposed to the running-intended-applied complexity, even if they are allowed to lump all three into one? > Please point me to the statement in the I-D that makes you believe an implementation is required to support all datastores. > > There are no standard mechanisms that cause to be > > different from , so I would agree the intended datastore > > needs a lot more standards support before it is useful. > > > > The only difference seems to be the presence of templates but I don't know what they are. > The I-D says: | // e.g., removal of 'inactive' | // nodes, expansion of templates So it is not just templates. And yes, these are things several real-world implementations can do but where the IETF did not yet managed to standardize anything. The basic question is whether we want a model that is (a) capable to match real-world implementation and that allows for future standards of existing proprietary technology or (b) we go with what we have today (either chartered or published) and we keep revising the model as we move ahead. /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 Jan 9 13:17:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F64B129522 for ; Mon, 9 Jan 2017 13:17:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-gbBQbKgx5y for ; Mon, 9 Jan 2017 13:17:11 -0800 (PST) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5DEF1295D8 for ; Mon, 9 Jan 2017 13:17:10 -0800 (PST) Received: by mail-qt0-x235.google.com with SMTP id x49so82184799qtc.2 for ; Mon, 09 Jan 2017 13:17:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7/ywd0bSWTmjlsMyk+YbgF2MueENh23gG7QaiOoWQIY=; b=LddZl/0XnajepTLf8QUovLc0LugRJCgh9KS+MCuh/L124DuKXIlKNGQU/iXhqFqiXJ JozwdgDJrNrSIjihKOajX0rRz/QeTOkAKJMZwO0zM1a3uuoBLQ2nHjaq6Ym4GVENusUM o/OPjcbRalqYniv/xgresjN7nU0B4vz3w5+zVJ+hAilP0qb4FtULMTWmAOnipC5jIjNd iVXYeIjp5DbFVNxyU9b2fb3bKsc2JZ1XuKAQRnaqGHOoX8I+dSdasrMYTVZXNno6awpr LQNN+2MxQ3jXX2c+4ecIwumy4eSdKxB0j11B7GHo15WBQs4UxtoFkIkfPvJEFGsbQuky cbpg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7/ywd0bSWTmjlsMyk+YbgF2MueENh23gG7QaiOoWQIY=; b=o3YbYjYlKRPMt0HHeYxTOX7lT/L2e3h9nGKx+76WxZ97GMEvLwUUpIPx8xd3LkDlyN kLiqm9bmKr0oeC4UAllh5wYoFhZgKc72etwW3A5WvqbAdSHW6FIizbGhWxP5mY3eRDeu 1FXGi/CujwCY6jurY89949xMI0D/gbzWxHaPhgM1/fBXDUf9HstB3mJHALQbflIBD/x7 6dc80w37SgOfcJzQ2umx0TZVG4MdeUBWP8PfBTg6CfoVP6DMSM+R+CbIK82JCBDvVa7r 3eIujBi8rDcB0SU3S3qYiUP3iqNLOxIRP9v9wsOx49g/Tj+R38SIQfjeDXJ8BwYsO0Le 4+Bw== X-Gm-Message-State: AIkVDXIWSkoAo2xvxC38kYjqP+9vxaZxKpqG7k5zxOcqwaGz9PGN/TpGVC4isAt7lAS05kXtkzEnoN9hnuBAHg== X-Received: by 10.200.40.245 with SMTP id j50mr21677281qtj.72.1483996629761; Mon, 09 Jan 2017 13:17:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Mon, 9 Jan 2017 13:17:09 -0800 (PST) In-Reply-To: <20170109205109.GA15144@elstar.local> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> From: Andy Bierman Date: Mon, 9 Jan 2017 13:17:09 -0800 Message-ID: To: Juergen Schoenwaelder , Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a1146f762f729510545afe310 Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Jan 2017 21:17:13 -0000 --001a1146f762f729510545afe310 Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > > > I am more concerned about use cases that are not known so far, and so I > am against standardizing this (or any other) workflow as the only one > supported by NETCONF/RESTCONF and YANG. I believe both the protocols and > YANG can work with any set of datastores, but their choice depends on the > use case at hand. Why should IoT developers be exposed to the > running-intended-applied complexity, even if they are allowed to lump all > three into one? > > > > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. > > > > There are no standard mechanisms that cause to be > > > different from , so I would agree the intended datastore > > > needs a lot more standards support before it is useful. > > > > > > > The only difference seems to be the presence of templates but I don't > know what they are. > > > > The I-D says: > > | // e.g., removal of 'inactive' > | // nodes, expansion of templates > > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. > > I think itt is not realistic to say that datastores are optional. e.g. leaf: If there is a standard way to enable/disable config then individual "enabled" leafs are redundant. However XPath (must/when) has no way to describe if the subtree is enabled (which is a show-stopper) vs . If the applied or operational datastore is assumed, then there is no need to model the redundant config-as-operstate. If this is left out of the model, then the datastore becomes mandatory. If it is left in the model, the datasore becomes redundant. The basic premise that these datastores are optional is flawed. One cannot design a YANG module assuming the datastores are present if they are in fact optional. /js > > Andy > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a1146f762f729510545afe310 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav L= hotka wrote:
>
> I am more concerned about use cases that are not known so far, and so = I am against standardizing this (or any other) workflow as the only one sup= ported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG = can work with any set of datastores, but their choice depends on the use ca= se at hand. Why should IoT developers be exposed to the running-intended-ap= plied complexity, even if they are allowed to lump all three into one?
>

Please point me to the statement in the I-D that makes you believe an
implementation is required to support all datastores.

> > There are no standard mechanisms that cause <running> to be=
> > different from <intended>, so I would agree the intended da= tastore
> > needs a lot more standards support before it is useful.
> >
>
> The only difference seems to be the presence of templates but I don= 9;t know what they are.
>

The I-D says:

=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 // e.g., removal of &= #39;inactive'
=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 // nodes, expansion o= f templates

So it is not just templates. And yes, these are things several
real-world implementations can do but where the IETF did not yet
managed to standardize anything. The basic question is whether we want
a model that is (a) capable to match real-world implementation and
that allows for future standards of existing proprietary technology or
(b) we go with what we have today (either chartered or published) and
we keep revising the model as we move ahead.



I think itt is not realistic to say t= hat datastores are optional.

e.g. <enabled> = leaf: =C2=A0If there is a standard way to enable/disable config
t= hen individual "enabled" leafs are redundant. However XPath (must= /when)
has no way to describe if the subtree is enabled (which is= a show-stopper)

<foo-config> vs <foo-ope= r>.=C2=A0 If the applied or operational datastore is assumed,
= then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is f= lawed.
One cannot design a YANG module assuming the datastores ar= e present
if they are in fact optional.

=
/js


Andy

=C2=A0
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a1146f762f729510545afe310-- From nobody Mon Jan 9 23:21:07 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D29DE129B0E; Mon, 9 Jan 2017 23:21:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 EYJuDJETxp78; Mon, 9 Jan 2017 23:21:03 -0800 (PST) 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 80AF5129B09; Mon, 9 Jan 2017 23:21:03 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D95C775C; Tue, 10 Jan 2017 08:21:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oMd8Ei57x-bR; Tue, 10 Jan 2017 08:21:00 +0100 (CET) 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, 10 Jan 2017 08:21:01 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 89CD02008D; Tue, 10 Jan 2017 08:21:01 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id tH4epit3K4zZ; Tue, 10 Jan 2017 08:21:01 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 329972008C; Tue, 10 Jan 2017 08:21:01 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A6F963E078C4; Tue, 10 Jan 2017 08:21:03 +0100 (CET) Date: Tue, 10 Jan 2017 08:21:03 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170110072103.GA16120@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 07:21:06 -0000 On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > I think itt is not realistic to say that datastores are optional. > > e.g. leaf: If there is a standard way to enable/disable config > then individual "enabled" leafs are redundant. However XPath (must/when) > has no way to describe if the subtree is enabled (which is a show-stopper) I may not understand what you are saying. From what I know, there are implementations that allow to 'comment out' nodes and subtrees and that work with clients in a backwards compatible way. > vs . If the applied or operational datastore is > assumed, > then there is no need to model the redundant config-as-operstate. > If this is left out of the model, then the datastore becomes mandatory. > If it is left in the model, the datasore becomes redundant. > > The basic premise that these datastores are optional is flawed. > One cannot design a YANG module assuming the datastores are present > if they are in fact optional. The claim that all datastores are mandatory is equally flawed. /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 Jan 10 00:20:44 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC8DC129B4E; Tue, 10 Jan 2017 00:20:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DZNzfjC_GyQl; Tue, 10 Jan 2017 00:20:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A773127058; Tue, 10 Jan 2017 00:20:37 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e] (unknown [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e]) by mail.nic.cz (Postfix) with ESMTPSA id B760960CAE; Tue, 10 Jan 2017 09:20:35 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484036435; bh=2FQhYzeXF8eynKSdK6lUIDeoKEuDyLHIfRIlfEXQ+E8=; h=From:Date:To; b=Wu1dpL5b0adJBIQGr1/4pcUF5guCgWQ2Mp/Gcnl2iTDgEPHHJDiwRInKVF56z2eyk Y+z8SQchTSTjgfmq23nhGnQcnG3gZPyh3iYBBFTGOyAC5vSMh7+XEaMaJddg71arzI drnOp4UaqMf/F1zicE/kxZs3wXbvuf2x5yejGfxs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170109205109.GA15144@elstar.local> Date: Tue, 10 Jan 2017 09:20:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:20:40 -0000 > On 9 Jan 2017, at 21:51, Juergen Schoenwaelder = wrote: >=20 > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: >>=20 >> I am more concerned about use cases that are not known so far, and so = I am against standardizing this (or any other) workflow as the only one = supported by NETCONF/RESTCONF and YANG. I believe both the protocols and = YANG can work with any set of datastores, but their choice depends on = the use case at hand. Why should IoT developers be exposed to the = running-intended-applied complexity, even if they are allowed to lump = all three into one? =20 >>=20 >=20 > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. Sec. 6.3: "YANG currently describes validation in terms of the = configuration datastore while it really happens on the = configuration datastore." This seems to indicate that and are required, at = least conceptually. The original datastore model (sec. 4) was hardwired into NETCONF and = YANG specs but it was found insufficient for some use cases. So now we = come up with another datastore model, and I am against doing the same = mistake again. What if some future use cases again need something else? We could instead define the protocols and YANG in terms of reasonable = abstractions (e.g. resource and data tree), and use a run-time = specification of the datastore model (there could also be several = standardized alternatives). To some extent, we do it already now by = using capabilites such as "candidate", "startup" and "writable-running". >=20 >>> There are no standard mechanisms that cause to be >>> different from , so I would agree the intended datastore >>> needs a lot more standards support before it is useful. >>>=20 >>=20 >> The only difference seems to be the presence of templates but I don't = know what they are. >>=20 >=20 > The I-D says: >=20 > | // e.g., removal of 'inactive' > | // nodes, expansion of templates >=20 > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. I think we need protocol and YANG specs that are not tied to any = particular model and that are thus capable of matching unforeseen = real-world implementations. This is no sci-fi, HTTP and XML schema = languages work this way. 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: 0xB8F92B08A9F76C67 From nobody Tue Jan 10 00:39:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 522FD129B7E; Tue, 10 Jan 2017 00:39:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 T6evzwb9ntZV; Tue, 10 Jan 2017 00:39:44 -0800 (PST) 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 D28E4129B59; Tue, 10 Jan 2017 00:39:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 81E83791; Tue, 10 Jan 2017 09:39:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id GEqsfH9bt1Z0; Tue, 10 Jan 2017 09:39:41 +0100 (CET) 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, 10 Jan 2017 09:39:42 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B16A2008C; Tue, 10 Jan 2017 09:39:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DOM-z_iPEEbh; Tue, 10 Jan 2017 09:39:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DE87C20089; Tue, 10 Jan 2017 09:39:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A162F3E07C3A; Tue, 10 Jan 2017 09:39:43 +0100 (CET) Date: Tue, 10 Jan 2017 09:39:43 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170110083942.GC16255@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 08:39:45 -0000 On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > > I think we need protocol and YANG specs that are not tied to any particular model and that are thus capable of matching unforeseen real-world implementations. This is no sci-fi, HTTP and XML schema languages work this way. > I disagree that HTTP and XML schema languages do the same thing. Our goal is interoperable configuration of network devices; the notion of configuration datastore validation and specification of semantics goes well beyond what you usually find in web interactions, where typically all semantics are left to the implementor of a service. We validate configurations (residing in datastores), not the syntactic aspects of protocol messages. But yes, I am looking forward to a concrete I-D. /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 Jan 10 01:20:43 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC72D129BA5; Tue, 10 Jan 2017 01:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aMjwxLhQMSWY; Tue, 10 Jan 2017 01:20:37 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1AFA5129B94; Tue, 10 Jan 2017 01:20:36 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e] (unknown [IPv6:2a01:5e0:29:fffe:a482:2948:cd7d:d9e]) by mail.nic.cz (Postfix) with ESMTPSA id C4DB5600BE; Tue, 10 Jan 2017 10:20:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484040034; bh=xazYos30vLENnxtxr2O1elEh3e1kM5+ldNQDB9tao0g=; h=From:Date:To; b=FIR8NSr74Cp/l5wCfa2RKMh9L77DFM74+tjXzN2eclgQbwxAtA+Z1V2wtZLe9RRB9 NhsZV99+c4u4PdnnYnYSJPd7cyxVRtC20sRQbz4lr/rnwkMBjP3DhHAiwoU+PHYG6e tCnDBvw+uDEkICxnMzNjnl/eVcll1GIsxXICD7jo= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170110083942.GC16255@elstar.local> Date: Tue, 10 Jan 2017 10:20:35 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:20:39 -0000 > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder = wrote: >=20 > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>=20 >> I think we need protocol and YANG specs that are not tied to any = particular model and that are thus capable of matching unforeseen = real-world implementations. This is no sci-fi, HTTP and XML schema = languages work this way. >>=20 >=20 > I disagree that HTTP and XML schema languages do the same thing. Our > goal is interoperable configuration of network devices; the notion of Even now, a client that's programmed to write straight to running isn't = interoperable with a server that has candidate and read-only running. A = RESTCONF server that supports only JSON isn't interoperable with a = client that supports only XML. We are not in a situation that every pair of a randomly chosen server = and client need to be interoperable. It's IMO perfectly fine if IoT and = ISP networks use different clients. Yet, both can still use the same = RESTCONF, same YANG, and even same YANG modules.=20 > configuration datastore validation and specification of semantics goes > well beyond what you usually find in web interactions, where typically > all semantics are left to the implementor of a service. We validate > configurations (residing in datastores), not the syntactic aspects of > protocol messages. But yes, I am looking forward to a concrete I-D. Where did I write anything about syntactic aspects of protocol messages? = Of course we need to validate datastores. In the case of YANG, my point = is that its spec could just define what a valid datastore (data tree) = is. What it needn't state is that running, intended or whatever MUST be = valid - it can be said elsewhere. 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: 0xB8F92B08A9F76C67 From nobody Tue Jan 10 01:34:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4771C1296A7; Tue, 10 Jan 2017 01:34:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 YzeUY1H5zqH4; Tue, 10 Jan 2017 01:34:21 -0800 (PST) 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 8F6511279EB; Tue, 10 Jan 2017 01:34:21 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 6571D6C8; Tue, 10 Jan 2017 10:34:20 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UdjBgVddHOia; Tue, 10 Jan 2017 10:34:18 +0100 (CET) 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, 10 Jan 2017 10:34:19 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id E45632008D; Tue, 10 Jan 2017 10:34:19 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id znFrCYv2Xfcq; Tue, 10 Jan 2017 10:34:19 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B3D82008C; Tue, 10 Jan 2017 10:34:19 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0205B3E07E38; Tue, 10 Jan 2017 10:34:21 +0100 (CET) Date: Tue, 10 Jan 2017 10:34:21 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170110093421.GC16426@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 09:34:23 -0000 On Tue, Jan 10, 2017 at 10:20:35AM +0100, Ladislav Lhotka wrote: > > > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder wrote: > > > > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >> > >> I think we need protocol and YANG specs that are not tied to any particular model and that are thus capable of matching unforeseen real-world implementations. This is no sci-fi, HTTP and XML schema languages work this way. > >> > > > > I disagree that HTTP and XML schema languages do the same thing. Our > > goal is interoperable configuration of network devices; the notion of > > Even now, a client that's programmed to write straight to running isn't interoperable with a server that has candidate and read-only running. A RESTCONF server that supports only JSON isn't interoperable with a client that supports only XML. > > We are not in a situation that every pair of a randomly chosen server and client need to be interoperable. It's IMO perfectly fine if IoT and ISP networks use different clients. Yet, both can still use the same RESTCONF, same YANG, and even same YANG modules. > Yes, there are optional protocol features and the protocols support negotiations of protocol features. Not a big deal. HTTP is full of this as well. The point is that writing to candidate has a well defined meaning because we defined how candidate behaves and interacts with the other datastores. If a client commits candidate, it knows what kind of changes it can expect to see in other datastores. If you want to do away with well-known datastores, you (a) either provide all the semantics we currently have hard-wired into well-known datastores as meta-data at runting (and you require that every client is able to interpret this meta-information correctly) or (b) you significantly loose functionality and we end up with generic editing protocols that unfortunately do not help much with configuration management (since we lost how information in differnet datastores interacts). In case I completely mis-understand you, consider to write an I-D. /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 Jan 10 06:33:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 136C0129CE4; Tue, 10 Jan 2017 06:33:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nuRMyQuVaK-4; Tue, 10 Jan 2017 06:33:29 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 529931294A3; Tue, 10 Jan 2017 06:33:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13891; q=dns/txt; s=iport; t=1484058808; x=1485268408; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=d6x5f20b1NJjFA54UIRr5jIbkKiMqZYwRGUD8IT2b8M=; b=AbVsuYbynopzHTlkSLQWKdxUtzHDkVZz6/TRbCoyG7GFE3ZFvR9Dw5Xa yEUgf6xhRN3MxODW9aP2AEKntKivDqrpJqUyRn4sLUWkTteugPALENZfj rCFfflEJs9LMYMPn+rn8q8XRbGiupkMvqQraj+jcl3TfPVOvGmhIdNXz1 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQD/73RY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMsDgEBAQEBfgMsXo1XcpE1j3yFK4ILHwEKhB6BEEoCgjwUAQI?= =?us-ascii?q?BAQEBAQEBYyiEaQEBAQMBAQFsGQILEAgjBAcbDB8RBgEMBgIBAReITQgOskwri?= =?us-ascii?q?XcBAQEBAQEBAQEBAQEBAQEBAQEBAQEdBYZAggIIgleEZyaCB4MYBZUjhgCRUgK?= =?us-ascii?q?BdYULgyqGNYpjh3sfODZcEgcVFTiDejgcGIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="649678742" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 14:33:24 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0AEXNYJ021844; Tue, 10 Jan 2017 14:33:23 GMT To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Netconf , NetMod WG References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> From: Robert Wilton Message-ID: <77552791-5c65-23ca-0a2f-6af82d4cbd9e@cisco.com> Date: Tue, 10 Jan 2017 14:31:56 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EFBB52BABCFC9CF2A012F79E" Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:33:37 -0000 This is a multi-part message in MIME format. --------------EFBB52BABCFC9CF2A012F79E Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi, On 09/01/2017 21:17, Andy Bierman wrote: > > > On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote: > > > > I am more concerned about use cases that are not known so far, > and so I am against standardizing this (or any other) workflow as > the only one supported by NETCONF/RESTCONF and YANG. I believe > both the protocols and YANG can work with any set of datastores, > but their choice depends on the use case at hand. Why should IoT > developers be exposed to the running-intended-applied complexity, > even if they are allowed to lump all three into one? > > > > Please point me to the statement in the I-D that makes you believe an > implementation is required to support all datastores. > > > > There are no standard mechanisms that cause to be > > > different from , so I would agree the intended datastore > > > needs a lot more standards support before it is useful. > > > > > > > The only difference seems to be the presence of templates but I > don't know what they are. > > > > The I-D says: > > | // e.g., removal of 'inactive' > | // nodes, expansion of templates > > So it is not just templates. And yes, these are things several > real-world implementations can do but where the IETF did not yet > managed to standardize anything. The basic question is whether we want > a model that is (a) capable to match real-world implementation and > that allows for future standards of existing proprietary technology or > (b) we go with what we have today (either chartered or published) and > we keep revising the model as we move ahead. > > > > I think itt is not realistic to say that datastores are optional. > > e.g. leaf: If there is a standard way to enable/disable config > then individual "enabled" leafs are redundant. However XPath (must/when) > has no way to describe if the subtree is enabled (which is a show-stopper) > > vs . If the applied or operational datastore > is assumed, > then there is no need to model the redundant config-as-operstate. > If this is left out of the model, then the datastore becomes mandatory. > If it is left in the model, the datasore becomes redundant. > > The basic premise that these datastores are optional is flawed. > One cannot design a YANG module assuming the datastores are present > if they are in fact optional. I agree that these datastores are not all really optional. Current YANG models are structured assuming that there is no operational state datastore. They could be used on devices that support an operational state datastore, but there would likely be duplication of some of the data because it is represented in two places. But to design clean models with combined config and state, it is necessary to assume support for both "running" and also "operational state" datatstores. Such models could theoretically be used by devices that don't support the operational state datastore, but key information would be unavailable, so this doesn't feel like a pragmatic solution. However, it would to straight forward to write tooling (i.e. a plugin to pyang) that takes a YANG module designed assuming an operational state datastore and generate the missing config false leaves so that the model could also be used on devices that don't support an operational state datastore. This raises the question, or how do you know whether a model has been designed assuming support for an operational state datastore? For me the simplest solution appears to be to mark the models as YANG version 2.0. I would also propose revising NETCONF and RESTCONF to version 2, allowing the protocols to change to support an operational state datastore in a clean way. E.g. if a device supports an operational state datastore then it doesn't really make sense to continue to support the existing NETCONF GET operation. Thanks, Rob > > > /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 --------------EFBB52BABCFC9CF2A012F79E Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit

Hi,


On 09/01/2017 21:17, Andy Bierman wrote:


On Mon, Jan 9, 2017 at 12:51 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 09:18:46PM +0100, Ladislav Lhotka wrote:
>
> I am more concerned about use cases that are not known so far, and so I am against standardizing this (or any other) workflow as the only one supported by NETCONF/RESTCONF and YANG. I believe both the protocols and YANG can work with any set of datastores, but their choice depends on the use case at hand. Why should IoT developers be exposed to the running-intended-applied complexity, even if they are allowed to lump all three into one?
>

Please point me to the statement in the I-D that makes you believe an
implementation is required to support all datastores.

> > There are no standard mechanisms that cause <running> to be
> > different from <intended>, so I would agree the intended datastore
> > needs a lot more standards support before it is useful.
> >
>
> The only difference seems to be the presence of templates but I don't know what they are.
>

The I-D says:

                            |        // e.g., removal of 'inactive'
                            |        // nodes, expansion of templates

So it is not just templates. And yes, these are things several
real-world implementations can do but where the IETF did not yet
managed to standardize anything. The basic question is whether we want
a model that is (a) capable to match real-world implementation and
that allows for future standards of existing proprietary technology or
(b) we go with what we have today (either chartered or published) and
we keep revising the model as we move ahead.



I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:  If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a show-stopper)

<foo-config> vs <foo-oper>.  If the applied or operational datastore is assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.

I agree that these datastores are not all really optional.

Current YANG models are structured assuming that there is no operational state datastore.  They could be used on devices that support an operational state datastore, but there would likely be duplication of some of the data because it is represented in two places.

But to design clean models with combined config and state, it is necessary to assume support for both "running" and also "operational state" datatstores.  Such models could theoretically be used by devices that don't support the operational state datastore, but key information would be unavailable, so this doesn't feel like a pragmatic solution.  However, it would to straight forward to write tooling (i.e. a plugin to pyang) that takes a YANG module designed assuming an operational state datastore and generate the missing config false leaves so that the model could also be used on devices that don't support an operational state datastore.

This raises the question, or how do you know whether a model has been designed assuming support for an operational state datastore?  For me the simplest solution appears to be to mark the models as YANG version 2.0.  I would also propose revising NETCONF and RESTCONF to version 2, allowing the protocols to change to support an operational state datastore in a clean way.  E.g. if a device supports an operational state datastore then it doesn't really make sense to continue to support the existing NETCONF GET operation.

Thanks,
Rob




/js


Andy

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



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

--------------EFBB52BABCFC9CF2A012F79E-- From nobody Tue Jan 10 06:44:57 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F052D1294E6; Tue, 10 Jan 2017 06:44:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N0Ye8UHvxLb5; Tue, 10 Jan 2017 06:44:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 548EB1294D2; Tue, 10 Jan 2017 06:44:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1171; q=dns/txt; s=iport; t=1484059487; x=1485269087; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=9B7jdtpg0eBBFmmf06Mx7nk35PrBImEGflpKp1+xkhs=; b=eQOtznmY3vux101tuqMv+9O+5LcW0Ussdhay+u0AD3bcmz99rNmgLvjS jbyfNUE0nJrVC7HTchD85B7lUrOMtJZWPhmKgtQDlVZ9gvYHmlqgomptT +WARhOMCn9cQxL99HRgQvf+YZgfiJuao79eD1z47bD8CiD80VyJBIYf/T g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ASAQBZ8nRY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzoBAQEBAX4DLF6NV3KRNZUnggsfC4UuSgKCPRQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALDgojCycwBgEMBgIBAReITQgOslKKIgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBARgFhkWCAgiCV4osBZsjkVKKLIY1imOHex84gRISBxUVOIR?= =?us-ascii?q?mgUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="649679126" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 14:44:43 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0AEigSH025464; Tue, 10 Jan 2017 14:44:42 GMT To: Lou Berger , Ladislav Lhotka , Andy Bierman References: <019101d26847$4a7eb3f0$df7c1bd0$@gmail.com> <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> From: Robert Wilton Message-ID: Date: Tue, 10 Jan 2017 14:43:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 14:44:51 -0000 On 09/01/2017 12:38, Lou Berger wrote: > > > On January 9, 2017 7:25:24 AM Ladislav Lhotka wrote: >> >> The current document involves quite a lot of hand-waving, and that's >> why I was also reluctant to accept it as a WG standard-track >> deliverable. > > IMO I think we should do and document the work and then, once the is > general agreement, worry about number and publication status of > documents. +1 I would like to get on with the interesting work of actually working out the solution. Personally, I think that having it in one document makes it easier to review/discuss/etc. I also think that it would help this work progress more quickly which I still regard as being particularly important. I do also agree with Mehmet's suggestion of restructuring the existing YANG docs to make them more consistent, but I think that it would be a mistake to slow down this important work to what seems like a documentation cleanup task. Rob > > Lou > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Tue Jan 10 07:30:55 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DFC129D05 for ; Tue, 10 Jan 2017 07:30:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RtftLxd1k2aN for ; Tue, 10 Jan 2017 07:30:53 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DBBAE129CF4 for ; Tue, 10 Jan 2017 07:30:52 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id v23so168372486qtb.0 for ; Tue, 10 Jan 2017 07:30:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=oqmPqaEMwErmf3hCrG9ogF/wBassD/oXkECv0Dwpjq8=; b=hGYh9vqeP1tq5bIVZ8SY93pltnfmrn6Wu7ipD9EE18LVMmiUHapgRyhcYZBnhkNL2+ fFvp6Ej8LcKI0MNz2tWDHX4hEaoCGghUX08FlUqr7pkL7TGkU7sqVP/hwo/8aQMRiSQC bHzTTaMzqB/0RuwaeLInllBB5W/ag94T9ly9Tlfl5HZHeXq13XHzKSqwirPwUin+GSm6 B1yjTnPiyaooyVMRtzh6Si9BqpLlLidjqGmEDdfFY5nNGpXleBhLXHCRVuzhALgtlZOe ol61xzSgwwVwITIYebFQLXPsqFx6e/3PjbeKuGgccjS0/Pm2qYxk9NzT3F7pLTpobv5L jiZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=oqmPqaEMwErmf3hCrG9ogF/wBassD/oXkECv0Dwpjq8=; b=V5ufpJrlwjLUJA53bGBbJYQkyxQ1szRAGkdkxHScde+Z6d4Knefb0nXTITOivMltoD mld1FAiE6PSa+WcQgb/6pN9z2sjm3I3QVHCSjOH4FA2GBRwd4Q27azHoHC3cUFEP8wE9 XYqZzxHBqs4QVrmG/wl0c1oM17dQcAQYllgotOf8Nt7qLLRQwAljQVXOHsI5HmWFNFES FU/CW9hoNK8fUW3z4WjFkdVzJaajY7HZGwnx0zkQZA06lFulAI9p9PFsvEtNZ1jUmeSx Nfn3xJQaqMmzWRAUShOscwBLnxk0kc6MsmiJBZ57nHoRGGElql5VEgkicNSwVMMJ5r2Q Y0nQ== X-Gm-Message-State: AIkVDXL2H+tbtpgQXf+xoKfxVUe4LdF4LP3Su/DaVHs7vt3RH8u3cRDr6mBj/B2uv42Lkl0y8yu+4kdUOhodXg== X-Received: by 10.200.36.171 with SMTP id s40mr3057199qts.142.1484062251945; Tue, 10 Jan 2017 07:30:51 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 07:30:51 -0800 (PST) In-Reply-To: <20170110072103.GA16120@elstar.local> References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 07:30:51 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114033425a2e1c0545bf2b8a Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 15:30:54 -0000 --001a114033425a2e1c0545bf2b8a Content-Type: text/plain; charset=UTF-8 On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > I think itt is not realistic to say that datastores are optional. > > > > e.g. leaf: If there is a standard way to enable/disable config > > then individual "enabled" leafs are redundant. However XPath (must/when) > > has no way to describe if the subtree is enabled (which is a > show-stopper) > > I may not understand what you are saying. From what I know, there are > implementations that allow to 'comment out' nodes and subtrees and > that work with clients in a backwards compatible way. > > > vs . If the applied or operational datastore is > > assumed, > > then there is no need to model the redundant config-as-operstate. > > If this is left out of the model, then the datastore becomes mandatory. > > If it is left in the model, the datasore becomes redundant. > > > > The basic premise that these datastores are optional is flawed. > > One cannot design a YANG module assuming the datastores are present > > if they are in fact optional. > > The claim that all datastores are mandatory is equally flawed. > > correct -- nobody is saying that. The reason this is different is that the YANG objects are impacted. Candidate vs. running has no impact whatsoever on the set of YANG modules. The protocol is not self-selecting some objects and making other objects invisible. But if I want to model , I will soon have to decide to use and allow all protocols to read it or model get-state(foo) and require a different module for each protocol. /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114033425a2e1c0545bf2b8a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierm= an wrote:
>
> I think itt is not realistic to say that datastores are optional.
>
> e.g. <enabled> leaf:=C2=A0 If there is a standard way to enable/= disable config
> then individual "enabled" leafs are redundant. However XPath= (must/when)
> has no way to describe if the subtree is enabled (which is a show-stop= per)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and<= br> that work with clients in a backwards compatible way.

> <foo-config> vs <foo-oper>.=C2=A0 If the applied or operat= ional datastore is
> assumed,
> then there is no need to model the redundant config-as-operstate.
> If this is left out of the model, then the datastore becomes mandatory= .
> If it is left in the model, the datasore becomes redundant.
>
> The basic premise that these datastores are optional is flawed.
> One cannot design a YANG module assuming the datastores are present > if they are in fact optional.

The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.


The reason this is different is that the YANG objects= are impacted.
Candidate vs. running has no impact whatsoever on = the set of
YANG modules.=C2=A0 The protocol is not self-selecting= some objects
and making other objects invisible.

<= /div>
But if I want to model <foo-state>, I will soon have to dec= ide
to use <foo-state> and allow all protocols to read it o= r
model get-state(foo) and require a different module for each
protocol.


/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114033425a2e1c0545bf2b8a-- From nobody Tue Jan 10 08:11:49 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3041D1295D9; Tue, 10 Jan 2017 08:11:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dvv8i0QAWXdK; Tue, 10 Jan 2017 08:11:42 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD54A129BDD; Tue, 10 Jan 2017 08:11:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9248; q=dns/txt; s=iport; t=1484064691; x=1485274291; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=gcWZpBCNP3H6FuKSTalZsJ3VHZtgdxFPiZRAmP3gT5o=; b=Q+OG11vQYAEyt9NZIhxQqLH5edJi4EY65PdBfUO9XF6vaW0i8YT6D2pS HT0AHw+x6hNHPkgfsWP1ytNtfsCXZxHTT6Nw4V6eH1M11nDVcD1+fzNlE ig/V//zECYaRYVyrGpATQIBDanrjtXlQSvT7yb/4upUIEgnftyvrPpxHt Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AVAQCyBnVY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM6AQEBAQF+AyxejVdykTSPfIUrggsfAQqEHoEQSgKCQRQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAEBbBkCCxAIIwQHGwwfEQYBDAYCAQGIbA6yZSuJeAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR0FhkCCAoJfhGcmggeDGAWVI4YAkVKBd4g1I4Y?= =?us-ascii?q?SimOHex84gRISBxUVOIN6bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="648660618" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 16:11:27 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0AGBQAc022998; Tue, 10 Jan 2017 16:11:27 GMT To: Andy Bierman , Juergen Schoenwaelder , Ladislav Lhotka , Netconf , NetMod WG References: <20170106184513.GA11816@elstar.local> <01d401d2684f$d1e81a40$75b84ec0$@gmail.com> <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> From: Robert Wilton Message-ID: Date: Tue, 10 Jan 2017 16:11:21 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------AE56B3AA3639E1D0FC4B9D98" Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:11:44 -0000 This is a multi-part message in MIME format. --------------AE56B3AA3639E1D0FC4B9D98 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 10/01/2017 15:30, Andy Bierman wrote: > > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder > > wrote: > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > I think itt is not realistic to say that datastores are optional. > > > > e.g. leaf: If there is a standard way to > enable/disable config > > then individual "enabled" leafs are redundant. However XPath > (must/when) > > has no way to describe if the subtree is enabled (which is a > show-stopper) > > I may not understand what you are saying. From what I know, there are > implementations that allow to 'comment out' nodes and subtrees and > that work with clients in a backwards compatible way. > > > vs . If the applied or operational > datastore is > > assumed, > > then there is no need to model the redundant config-as-operstate. > > If this is left out of the model, then the datastore becomes > mandatory. > > If it is left in the model, the datasore becomes redundant. > > > > The basic premise that these datastores are optional is flawed. > > One cannot design a YANG module assuming the datastores are present > > if they are in fact optional. > > The claim that all datastores are mandatory is equally flawed. > > > correct -- nobody is saying that. > > > The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. > > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. The same module can be used for the set of protocols that are conceptually built around the same set of mandatory datastores. I.e. it isn't necessary to have a separate module for each protocol, and that hasn't been proposed. Rob > > > /js > > > > Andy > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------AE56B3AA3639E1D0FC4B9D98 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 10/01/2017 15:30, Andy Bierman wrote:


On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
>
> I think itt is not realistic to say that datastores are optional.
>
> e.g. <enabled> leaf:  If there is a standard way to enable/disable config
> then individual "enabled" leafs are redundant. However XPath (must/when)
> has no way to describe if the subtree is enabled (which is a show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.

> <foo-config> vs <foo-oper>.  If the applied or operational datastore is
> assumed,
> then there is no need to model the redundant config-as-operstate.
> If this is left out of the model, then the datastore becomes mandatory.
> If it is left in the model, the datasore becomes redundant.
>
> The basic premise that these datastores are optional is flawed.
> One cannot design a YANG module assuming the datastores are present
> if they are in fact optional.

The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.


The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.  The protocol is not self-selecting some objects
and making other objects invisible.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.

The same module can be used for the set of protocols that are conceptually built around the same set of mandatory datastores.  I.e. it isn't necessary to have a separate module for each protocol, and that hasn't been proposed.

Rob



/js


Andy
 

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



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

--------------AE56B3AA3639E1D0FC4B9D98-- From nobody Tue Jan 10 08:17:18 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2403129D1A; Tue, 10 Jan 2017 08:17:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 aMpQuxK5BXoO; Tue, 10 Jan 2017 08:17:08 -0800 (PST) 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 3535D129D27; Tue, 10 Jan 2017 08:16:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8B4C7769; Tue, 10 Jan 2017 17:16:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EDpI-wANQ-tB; Tue, 10 Jan 2017 17:16:40 +0100 (CET) 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, 10 Jan 2017 17:16:42 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0F48F20090; Tue, 10 Jan 2017 17:16:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WAViZKz9uQkU; Tue, 10 Jan 2017 17:16:41 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 843E02008E; Tue, 10 Jan 2017 17:16:41 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0A9D33E08616; Tue, 10 Jan 2017 17:16:44 +0100 (CET) Date: Tue, 10 Jan 2017 17:16:43 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170110161643.GE17035@elstar.local> Mail-Followup-To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 16:17:11 -0000 On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > > > I think itt is not realistic to say that datastores are optional. > > > > > > e.g. leaf: If there is a standard way to enable/disable config > > > then individual "enabled" leafs are redundant. However XPath (must/when) > > > has no way to describe if the subtree is enabled (which is a > > show-stopper) > > > > I may not understand what you are saying. From what I know, there are > > implementations that allow to 'comment out' nodes and subtrees and > > that work with clients in a backwards compatible way. > > > > > vs . If the applied or operational datastore is > > > assumed, > > > then there is no need to model the redundant config-as-operstate. > > > If this is left out of the model, then the datastore becomes mandatory. > > > If it is left in the model, the datasore becomes redundant. > > > > > > The basic premise that these datastores are optional is flawed. > > > One cannot design a YANG module assuming the datastores are present > > > if they are in fact optional. > > > > The claim that all datastores are mandatory is equally flawed. > > > > > correct -- nobody is saying that. Well, I originally commented on the statement that intened would be required and adding complexity - it does not. > The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. Yes. And the same is true for intended as long as an implementation does not support templates or inactive configuration objects. > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. If you do /foo and /foo-state, things will just work with or without an operational state datastore. If you have only /foo, then an operational state datastore may come in handy if you have to support config and state with different lifetimes. /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 Jan 10 09:08:03 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFFC12967D; Tue, 10 Jan 2017 09:08:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uPAIHGUJ47mD; Tue, 10 Jan 2017 09:08:01 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 56BCE129666; Tue, 10 Jan 2017 09:08:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3656; q=dns/txt; s=iport; t=1484068080; x=1485277680; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=PiFSH8al9uOmNpmayKqAxnb0hsrqfcHHTHMSpn3o3tM=; b=Cq0wi1v96lMuGVzQsyOV6VzvsTtIz00N2I3q8FLF37qDlGoh2BBqLC1f tUPlu8vzNCmVo3DeYQk+W7FqFwGUh+toqrIE3vZSdmj44uP9DhT7y47J1 8QuF85KWrugV841OWRBa20VBQINRjf0e3olJduRWkcbhGcoPXck9+VJ48 M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B9AQBHFHVY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywOAQEBAQGBASxejVdykTSTGIIPgguGIgKCQRQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwE4RgsLEAgjC1cGAQwGAgEBiGQIsniKFgEBAQEBAQEBAgEBAQEBA?= =?us-ascii?q?SKGRYICgl+KLAWbI5FSgXeINSOGEopjh3sfOIESEgcVFYUegUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208";a="651502814" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 17:07:55 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0AH7tt9011033; Tue, 10 Jan 2017 17:07:55 GMT To: Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> From: Robert Wilton Message-ID: <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> Date: Tue, 10 Jan 2017 17:07:54 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20170110161643.GE17035@elstar.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:08:02 -0000 On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>> I think itt is not realistic to say that datastores are optional. >>>> >>>> e.g. leaf: If there is a standard way to enable/disable config >>>> then individual "enabled" leafs are redundant. However XPath (must/when) >>>> has no way to describe if the subtree is enabled (which is a >>> show-stopper) >>> >>> I may not understand what you are saying. From what I know, there are >>> implementations that allow to 'comment out' nodes and subtrees and >>> that work with clients in a backwards compatible way. >>> >>>> vs . If the applied or operational datastore is >>>> assumed, >>>> then there is no need to model the redundant config-as-operstate. >>>> If this is left out of the model, then the datastore becomes mandatory. >>>> If it is left in the model, the datasore becomes redundant. >>>> >>>> The basic premise that these datastores are optional is flawed. >>>> One cannot design a YANG module assuming the datastores are present >>>> if they are in fact optional. >>> The claim that all datastores are mandatory is equally flawed. >>> >>> >> correct -- nobody is saying that. > Well, I originally commented on the statement that intened would be > required and adding complexity - it does not. > >> The reason this is different is that the YANG objects are impacted. >> Candidate vs. running has no impact whatsoever on the set of >> YANG modules. The protocol is not self-selecting some objects >> and making other objects invisible. > Yes. And the same is true for intended as long as an implementation > does not support templates or inactive configuration objects. > >> But if I want to model , I will soon have to decide >> to use and allow all protocols to read it or >> model get-state(foo) and require a different module for each >> protocol. > If you do /foo and /foo-state, things will just work with or without > an operational state datastore. True, but there would also be an undesirable duplication of data in the data tree. > If you have only /foo, then an > operational state datastore may come in handy if you have to support > config and state with different lifetimes. I think that this may be more than "come in handy". I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore. Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured. Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use. Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured. If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using one of the with-default query parameters. Rob > > /js > From nobody Tue Jan 10 09:25:16 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82B0412947F for ; Tue, 10 Jan 2017 09:25:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CvtTSYcnCjbu for ; Tue, 10 Jan 2017 09:25:10 -0800 (PST) Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com [IPv6:2607:f8b0:400d:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95606129515 for ; Tue, 10 Jan 2017 09:25:10 -0800 (PST) Received: by mail-qk0-x22c.google.com with SMTP id s140so158950048qke.0 for ; Tue, 10 Jan 2017 09:25:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kPNurlDI0+M3diSPTeEqBal7VM+HQg7VF9Db62UMWr0=; b=kJTa5brh1o5lq9MDVbAtChH5hIcC1LYKLB3pzgwxIM3mU3io5/gsGwgqx+sgra+NU6 mdovapvIQxliAj4Dn5p1b66YbHOq2w9Zv4tKgBzVutfuOPjZwpPWcqN1pEsQfXvaxagM zuqlbvHvpQRFJw55JquxwJHOcOS18VY3h+SzG/YhmjjDL0t3Th6W9RuBbUai9dtnlDOz MwmvUWwW1BrP9//xkPq7vmNeM3DF4cBtiYBAVYZQZxf1J33P+V5D+h4uEen63p9vtkM9 GXX57qdplofJwKkfYEgXqI7sQeeLl159mKSHZU488tm719czyBymjHAJsbDg/Y5y7SQ6 GVpQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kPNurlDI0+M3diSPTeEqBal7VM+HQg7VF9Db62UMWr0=; b=n7BLzIJX+CkD77hM3iiF6ylNluE0/jAOwjCjSA9YJFzDfvMuBCU9kVBzt2w3ZKCJoo AZSwzzSim6a6Nvk9L7RhEDXF7J8TeVx4FlDoJm4fB7dhggwNvOpw0BrS4y9VMOclfNFp Liwa1g3au/TFtU48a/41iIHzUTpzZ5IF/Yy2blZdb5AY9A7AyJxpAzdrJaajFyLcAeba RfhLSeh7/UZkb1/lckq321KnlKDcNy+BevljuNkPwqpxPfxsg5RAfoSqiqQUM0uTGD1t 0FNuEv4E6n09Y8I/DT2WZCVTkAOANnjGPfC7ZZIdG0ZMTUjDIBZodR1rbJ+hcaXM4DfP udMA== X-Gm-Message-State: AIkVDXKQTQjwl2Xi8OR4epidsQ+xE9gawrnUofFsyfxSUCV7yC4SEMJtZEZ3D2gKG1YrtgzmEI+puGrl7PEe+Q== X-Received: by 10.55.135.197 with SMTP id j188mr3901396qkd.71.1484069109589; Tue, 10 Jan 2017 09:25:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 09:25:08 -0800 (PST) In-Reply-To: <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> From: Andy Bierman Date: Tue, 10 Jan 2017 09:25:08 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=94eb2c0777e6198c5c0545c0c4ee Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 17:25:12 -0000 --94eb2c0777e6198c5c0545c0c4ee Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton wrote: > > > On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > >> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >> >>> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>> >>>>> I think itt is not realistic to say that datastores are optional. >>>>> >>>>> e.g. leaf: If there is a standard way to enable/disable >>>>> config >>>>> then individual "enabled" leafs are redundant. However XPath >>>>> (must/when) >>>>> has no way to describe if the subtree is enabled (which is a >>>>> >>>> show-stopper) >>>> >>>> I may not understand what you are saying. From what I know, there are >>>> implementations that allow to 'comment out' nodes and subtrees and >>>> that work with clients in a backwards compatible way. >>>> >>>> vs . If the applied or operational datastore is >>>>> assumed, >>>>> then there is no need to model the redundant config-as-operstate. >>>>> If this is left out of the model, then the datastore becomes mandatory. >>>>> If it is left in the model, the datasore becomes redundant. >>>>> >>>>> The basic premise that these datastores are optional is flawed. >>>>> One cannot design a YANG module assuming the datastores are present >>>>> if they are in fact optional. >>>>> >>>> The claim that all datastores are mandatory is equally flawed. >>>> >>>> >>>> correct -- nobody is saying that. >>> >> Well, I originally commented on the statement that intened would be >> required and adding complexity - it does not. >> >> >>> The reason this is different is that the YANG objects are impacted. >>> Candidate vs. running has no impact whatsoever on the set of >>> YANG modules. The protocol is not self-selecting some objects >>> and making other objects invisible. >>> >> Yes. And the same is true for intended as long as an implementation >> does not support templates or inactive configuration objects. >> >> But if I want to model , I will soon have to decide >>> to use and allow all protocols to read it or >>> model get-state(foo) and require a different module for each >>> protocol. >>> >> If you do /foo and /foo-state, things will just work with or without >> an operational state datastore. >> > True, but there would also be an undesirable duplication of data in the > data tree. > > > If you have only /foo, then an >> operational state datastore may come in handy if you have to support >> config and state with different lifetimes. >> > I think that this may be more than "come in handy". I think that there > would be key information that clients would expect to be available in a > model but wouldn't be easily retrievable without supporting the operational > state datastore. Specifically you lose the ability to easily query an > operational property of a system that can be configured, but hasn't been > configured. > > Example: Consider an Ethernet interface speed leaf that in the running ds > represents the configured speed, and in the operational state ds represents > the actual operational speed in use. Normally, the operational speed would > default to the maximum speed supported by the hardware (or the negotiated > value if auto-neg is in effect). If a device doesn't support the > operational state datastore then you wouldn't be able to query the > operational speed of an interface if it hasn't also been configured. > This is my concern -- that data modelers will put in the leaf to make sure all protocols (including existing NETCONF) can retrieve the oper-value. For many decades, this has been the design approach. There have not been many leafs where interactions with control-plane protocols is a factor. The SNMP-style solution is ad-hoc, but the problem is somewhat rare, so it didn't really matter. The premise now seems to be that the problem is no longer rare and lots of type of data is needed. I am not even sure this will be true if I2RS is constrained to RIB data (as the charter dictates). Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed) > If the device support the with-defaults extension and appropriate options > then they could presumably retrieve the "complex default" value from the > device using one of the with-default query parameters. > with-defaults is a bit different because the YANG module can provide the default even if the server won't. > > Rob > > > >> /js >> >> > Andy --94eb2c0777e6198c5c0545c0c4ee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j= .schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:=C2=A0 If there is a standard way to enable/disab= le config
then individual "enabled" leafs are redundant. However XPath (mus= t/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and<= br> that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.=C2=A0 If the applied or operational= datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
=C2=A0
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.=C2=A0 The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the dat= a tree.


=C2=A0 If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".=C2=A0 I think= that there would be key information that clients would expect to be availa= ble in a model but wouldn't be easily retrievable without supporting th= e operational state datastore.=C2=A0 Specifically you lose the ability to e= asily query an operational property of a system that can be configured, but= hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds r= epresents the configured speed, and in the operational state ds represents = the actual operational speed in use.=C2=A0 Normally, the operational speed = would default to the maximum speed supported by the hardware (or the negoti= ated value if auto-neg is in effect). If a device doesn't support the o= perational state datastore then you wouldn't be able to query the opera= tional speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will = put in the <oper-speed> leaf to make sure
all protocols (in= cluding existing NETCONF) can retrieve the oper-value.

=
For many decades, this has been the design approach.
There h= ave not been many leafs where interactions with control-plane protocols
is a factor.=C2=A0 The SNMP-style solution is ad-hoc, but the proble= m is somewhat rare,
so it didn't really matter.
The premise now seems to be that the problem is no longer rare<= /div>
and lots of <oper-speed> type of data is needed.=C2=A0 I am= not even sure this will
be true if I2RS is constrained to RIB da= ta (as the charter dictates).

Presumably, the same= instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)=



If the device support the with-defaults extension and appropriate options t= hen they could presumably retrieve the "complex default" value fr= om the device using one of the with-default query parameters.

with-defaults is a bit different because the YANG mo= dule can provide the default
even if the server won't.
<= div>
=C2=A0

Rob



/js



Andy

--94eb2c0777e6198c5c0545c0c4ee-- From nobody Tue Jan 10 10:17:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4155A129D7B for ; Tue, 10 Jan 2017 10:17:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xyExylSdrsvH for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) Received: from mail-qk0-x232.google.com (mail-qk0-x232.google.com [IPv6:2607:f8b0:400d:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2718F129D53 for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) Received: by mail-qk0-x232.google.com with SMTP id s140so160636100qke.0 for ; Tue, 10 Jan 2017 10:17:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=jedrU6XdZiNnWnAEKjijLjH7FLmuAtwLGh7uhyf5ikg=; b=yJAgsR/G2OBy33YcQjdogT8o9Nw7ohm49MoGBRoyk87tCQ8ga8InAYBOJK5RdvVLjz eQXm1b1yefCJXmK4Mz6KGH/L42G6VZCNqcL5Oc3hed2zUlNwSI5LeSIP86mnJnCph2np UhBx8bCV/HeJAYOT49amHrYSO+F1Lkcg+BuBj4+vTzoiVDCtUgsPnE+VgE6mx4x7+1V4 3m/BC1KbMTi2Gtmj1I9KwQiOghC4vMpO8nLo/HhXwJGm1Z7QDMl1WniGCkDrBOuMuLK1 gNzlkuR5D6YXh4Y6cwCBFtg/32yAS0P62I3mtLg7be4sQvVmskj9ARHuC7ClAjpPUtMt Mdcg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=jedrU6XdZiNnWnAEKjijLjH7FLmuAtwLGh7uhyf5ikg=; b=Vi2JVerHWmnSNN8JbRCXUf/+uIYWtTHbVpc4A1ugIZy7eybkAvE19pExYqgTOYHezT u14VjVqelbOVIexRIYpJj6yZ2p02E2dPMYl8YqzdQa9/aA5fXIi8Fs1UMlToGLQTn9MN RcmegKefM47rgmr5+2q+BlgbEYjuCIe3XBTFTx1At5lvHzg61L+ikuoAlYaByPb85eK4 Y0Rg810YKjlhJYYNapV0lzXVZjhco+aUUDHUfoMyu1SkYYskp4PAuWkqJ3wE1HZqUZ4x P3DSDdxeogFXLBBO1h8eShIRCA4tpIhLo+iMm2OfOLwrAPr8w1k0dT2T6NHpj/R4i0y4 Yf9Q== X-Gm-Message-State: AIkVDXI93ZfR68Md936zk/eB9vW8MWlT3+LFB5hzIBoPkJ7Hz9I42InefitlstEOE2ecZh1Y+NUnL5zPrHyRhg== X-Received: by 10.55.7.2 with SMTP id 2mr4800001qkh.228.1484072267291; Tue, 10 Jan 2017 10:17:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 10:17:46 -0800 (PST) In-Reply-To: <20170110161643.GE17035@elstar.local> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 10:17:46 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Ladislav Lhotka , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=001a114c877c502f990545c1809e Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:17:50 -0000 --001a114c877c502f990545c1809e Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 8:16 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: > > > > > > > > I think itt is not realistic to say that datastores are optional. > > > > > > > > e.g. leaf: If there is a standard way to enable/disable > config > > > > then individual "enabled" leafs are redundant. However XPath > (must/when) > > > > has no way to describe if the subtree is enabled (which is a > > > show-stopper) > > > > > > I may not understand what you are saying. From what I know, there are > > > implementations that allow to 'comment out' nodes and subtrees and > > > that work with clients in a backwards compatible way. > > > > > > > vs . If the applied or operational datastore > is > > > > assumed, > > > > then there is no need to model the redundant config-as-operstate. > > > > If this is left out of the model, then the datastore becomes > mandatory. > > > > If it is left in the model, the datasore becomes redundant. > > > > > > > > The basic premise that these datastores are optional is flawed. > > > > One cannot design a YANG module assuming the datastores are present > > > > if they are in fact optional. > > > > > > The claim that all datastores are mandatory is equally flawed. > > > > > > > > correct -- nobody is saying that. > > Well, I originally commented on the statement that intened would be > required and adding complexity - it does not. > > > The reason this is different is that the YANG objects are impacted. > > Candidate vs. running has no impact whatsoever on the set of > > YANG modules. The protocol is not self-selecting some objects > > and making other objects invisible. > > Yes. And the same is true for intended as long as an implementation > does not support templates or inactive configuration objects. > > > But if I want to model , I will soon have to decide > > to use and allow all protocols to read it or > > model get-state(foo) and require a different module for each > > protocol. > > If you do /foo and /foo-state, things will just work with or without > an operational state datastore. If you have only /foo, then an > operational state datastore may come in handy if you have to support > config and state with different lifetimes. > Will they really work without /foo-state? How will I write XPath must/when/leafref statements for foo-state if it doesn't exist? (BTW, why do I need foo-state in both applied and operational datastores? This part is not clear) If the solution is to introduce an XPath function like operational-value(/top/speed) then this is both complicated and mandatory (YANG designers need the same XPath function set on every server) > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a114c877c502f990545c1809e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 8:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierm= an wrote:
> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
> > >
> > > I think itt is not realistic to say that datastores are opti= onal.
> > >
> > > e.g. <enabled> leaf:=C2=A0 If there is a standard way = to enable/disable config
> > > then individual "enabled" leafs are redundant. How= ever XPath (must/when)
> > > has no way to describe if the subtree is enabled (which is a=
> > show-stopper)
> >
> > I may not understand what you are saying. From what I know, there= are
> > implementations that allow to 'comment out' nodes and sub= trees and
> > that work with clients in a backwards compatible way.
> >
> > > <foo-config> vs <foo-oper>.=C2=A0 If the applied= or operational datastore is
> > > assumed,
> > > then there is no need to model the redundant config-as-opers= tate.
> > > If this is left out of the model, then the datastore becomes= mandatory.
> > > If it is left in the model, the datasore becomes redundant.<= br> > > >
> > > The basic premise that these datastores are optional is flaw= ed.
> > > One cannot design a YANG module assuming the datastores are = present
> > > if they are in fact optional.
> >
> > The claim that all datastores are mandatory is equally flawed. > >
> >
> correct -- nobody is saying that.

Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.

> The reason this is different is that the YANG objects are impacted. > Candidate vs. running has no impact whatsoever on the set of
> YANG modules.=C2=A0 The protocol is not self-selecting some objects > and making other objects invisible.

Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

> But if I want to model <foo-state>, I will soon have to decide > to use <foo-state> and allow all protocols to read it or
> model get-state(foo) and require a different module for each
> protocol.

If you do /foo and /foo-state, things will just work with or without
an operational state datastore. If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.

<= div>Will they really work without /foo-state?

How = will I write XPath must/when/leafref statements for foo-state if it doesn&#= 39;t exist?

(BTW, why do I need foo-state in both = applied and operational datastores?
This part is not clear)
=

If the solution is to introduce an XPath function like = operational-value(/top/speed)
then this is both complicated and m= andatory (YANG designers need the same
XPath function set on ever= y server)




=

/js


Andy
=C2=A0
=
--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--001a114c877c502f990545c1809e-- From nobody Tue Jan 10 10:18:34 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2240A129D7F; Tue, 10 Jan 2017 10:18:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R9rZm12W28qS; Tue, 10 Jan 2017 10:18:27 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77387129D80; Tue, 10 Jan 2017 10:18:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21348; q=dns/txt; s=iport; t=1484072300; x=1485281900; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=anzoJpP7MNxYVw00Ly4quwTi9M+tNPbkAQxDUWk4DuE=; b=SsdeMyfwRLVZYRj2LdGijW/BMPOhKIH55vnFSNAX6U7ce3JGGr708uHn yeVPeVvXpyI/EEX9udK+8j7iJ3jXK8/zAynSuG39gkFn2pWZl58zJsJ5k HIj3jopCHAyms+Of5ZywoMFJlSoyxRNMjTxK8tCFjEfxH3ijHYcsGh1R/ Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CRAQC9JHVY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywOAQEBAQGBASxeg0+KCHKRNZMYgg+CC4YiAoJCFAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEDASNWEAsQCCMEAwICRhEGDQYCAQEXiE0IsF+CJSuJawEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAR2GRYICCIJXhDCDHoJeBYhuh3GKRJFSgXeINSOGEop?= =?us-ascii?q?jh3sfOIESEgcVFYUegUc+NYhmAQEB?= X-IronPort-AV: E=Sophos;i="5.33,344,1477958400"; d="scan'208,217";a="651504373" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2017 18:18:15 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0AIIFFR024475; Tue, 10 Jan 2017 18:18:15 GMT To: Andy Bierman References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> From: Robert Wilton Message-ID: <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> Date: Tue, 10 Jan 2017 18:18:15 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------CFD0D02E2419FAC63CAAF3FD" Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:18:29 -0000 This is a multi-part message in MIME format. --------------CFD0D02E2419FAC63CAAF3FD Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit On 10/01/2017 17:25, Andy Bierman wrote: > > > On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton > wrote: > > > > On 10/01/2017 16:16, Juergen Schoenwaelder wrote: > > On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: > > On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de > > wrote: > > On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman > wrote: > > I think itt is not realistic to say that > datastores are optional. > > e.g. leaf: If there is a standard way > to enable/disable config > then individual "enabled" leafs are redundant. > However XPath (must/when) > has no way to describe if the subtree is enabled > (which is a > > show-stopper) > > I may not understand what you are saying. From what I > know, there are > implementations that allow to 'comment out' nodes and > subtrees and > that work with clients in a backwards compatible way. > > vs . If the applied or > operational datastore is > assumed, > then there is no need to model the redundant > config-as-operstate. > If this is left out of the model, then the > datastore becomes mandatory. > If it is left in the model, the datasore becomes > redundant. > > The basic premise that these datastores are > optional is flawed. > One cannot design a YANG module assuming the > datastores are present > if they are in fact optional. > > The claim that all datastores are mandatory is equally > flawed. > > > correct -- nobody is saying that. > > Well, I originally commented on the statement that intened > would be > required and adding complexity - it does not. > > The reason this is different is that the YANG objects are > impacted. > Candidate vs. running has no impact whatsoever on the set of > YANG modules. The protocol is not self-selecting some objects > and making other objects invisible. > > Yes. And the same is true for intended as long as an > implementation > does not support templates or inactive configuration objects. > > But if I want to model , I will soon have to decide > to use and allow all protocols to read it or > model get-state(foo) and require a different module for each > protocol. > > If you do /foo and /foo-state, things will just work with or > without > an operational state datastore. > > True, but there would also be an undesirable duplication of data > in the data tree. > > > If you have only /foo, then an > operational state datastore may come in handy if you have to > support > config and state with different lifetimes. > > I think that this may be more than "come in handy". I think that > there would be key information that clients would expect to be > available in a model but wouldn't be easily retrievable without > supporting the operational state datastore. Specifically you lose > the ability to easily query an operational property of a system > that can be configured, but hasn't been configured. > > Example: Consider an Ethernet interface speed leaf that in the > running ds represents the configured speed, and in the operational > state ds represents the actual operational speed in use. > Normally, the operational speed would default to the maximum speed > supported by the hardware (or the negotiated value if auto-neg is > in effect). If a device doesn't support the operational state > datastore then you wouldn't be able to query the operational speed > of an interface if it hasn't also been configured. > > > This is my concern -- that data modelers will put in the > leaf to make sure > all protocols (including existing NETCONF) can retrieve the oper-value. I think that there may be a better way here: The data modelers design the model on the assumption that an operational state datastore will be present. We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees. E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed. I've been playing around with pyang and I don't think that this would be too hard to do. > > For many decades, this has been the design approach. > There have not been many leafs where interactions with control-plane > protocols > is a factor. The SNMP-style solution is ad-hoc, but the problem is > somewhat rare, > so it didn't really matter. Yes, OK. But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state. > > The premise now seems to be that the problem is no longer rare > and lots of type of data is needed. I am not even sure > this will > be true if I2RS is constrained to RIB data (as the charter dictates). I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well. > > Presumably, the same instrumentation gets invoked for get(oper-speed) > as get-state(admin-speed) Yes, in the general case, I think that using the same instrumentation would be a valid implementation. But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same). If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation. > > > > If the device support the with-defaults extension and appropriate > options then they could presumably retrieve the "complex default" > value from the device using one of the with-default query parameters. > > > with-defaults is a bit different because the YANG module can provide > the default > even if the server won't. I was thinking of the "report-all" option. Wouldn't that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)? Rob > > > Rob > > > > /js > > > > Andy > --------------CFD0D02E2419FAC63CAAF3FD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 10/01/2017 17:25, Andy Bierman wrote:


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:  If there is a standard way to enable/disable config
then individual "enabled" leafs are redundant. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nodes and subtrees and
that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.  If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
 
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.  The protocol is not self-selecting some objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the data tree.


  If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".  I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore.  Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use.  Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will put in the <oper-speed> leaf to make sure
all protocols (including existing NETCONF) can retrieve the oper-value.
I think that there may be a better way here:  The data modelers design the model on the assumption that an operational state datastore will be present.  We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees.  E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed.  I've been playing around with pyang and I don't think that this would be too hard to do.


For many decades, this has been the design approach.
There have not been many leafs where interactions with control-plane protocols
is a factor.  The SNMP-style solution is ad-hoc, but the problem is somewhat rare,
so it didn't really matter.
Yes, OK.  But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state.



The premise now seems to be that the problem is no longer rare
and lots of <oper-speed> type of data is needed.  I am not even sure this will
be true if I2RS is constrained to RIB data (as the charter dictates).
I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well.



Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)
Yes, in the general case, I think that using the same instrumentation would be a valid implementation.

But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same).

If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation.




If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using one of the with-default query parameters.

with-defaults is a bit different because the YANG module can provide the default
even if the server won't.
I was thinking of the "report-all" option.  Wouldn't that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)?

Rob


 

Rob



/js



Andy


--------------CFD0D02E2419FAC63CAAF3FD-- From nobody Tue Jan 10 10:31:59 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFE412940A for ; Tue, 10 Jan 2017 10:31:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YHlQu0Zk0C5E for ; Tue, 10 Jan 2017 10:31:52 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C7F9912955D for ; Tue, 10 Jan 2017 10:31:51 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id l7so124811509qtd.1 for ; Tue, 10 Jan 2017 10:31:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jqSuNMPHWNSwrIlbOnxq4WgZGb7ulncVHq6I10mol7s=; b=koylWTXVDGMwEasWTzhNZebVpxfRLTeyvCkwJd/bLkr0mS2OJnqqnS+jG2Kh5FmQYD kcUbdB7Ul0MWwCJLCKWmc9tbmsD4mFkr9oh/FmQhvmKMZF/ExUmXVzc/ypN9pONl/zPs 2ukNCg3zoRDhBdf2kAfLVm+XlALKB+2EO3Hs+pYjHWtelQgNlVfKMEV7U1Clm3fpvu9W IunUKF20TMXFSHhGNq0QrNcC+J/EVcGBiUI4ZmJpnD6WjrgPx/RkF6rOtiljih1IhKvT kFabUPIlI0bUGXrLOUUoM1Ueqx8+IgF6Ui5ovh4pz1aKpgijF2jRNlT7ytl3T+Tw8TX1 lXTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jqSuNMPHWNSwrIlbOnxq4WgZGb7ulncVHq6I10mol7s=; b=FBmW3a3Uv+LkcHR44Bn/uqwjktyK7WujVXfn4Wo2Y3LVq4BOL4q98Olcfi9xtKpi2r 5Elr7MS+wTJLlQJJDa9QObemS4YyKe8coo4WlqdNDy/SmE0NX5qBcAySFZXrkwyxWbd0 9bfzQ2L4TKGEVDTPEY/Aw+OQTzNsnNnAstieg54TH/nUrYM6BjJ5nptHu96moz9ZF2gW zXYzkTegHKbP4N7aQPkyp1Lzi2g034e/NS1mgg11P9gbA2PI5IxG1GDCWX+E+psWxWAN BkJ7uS8HYaVRSgFyrJpMGLpY50y4kfpJcNxudp7Byd04YHqp3uIYZ5Lps4erqM9Jz6Vd g9Xg== X-Gm-Message-State: AIkVDXJFkNesQBtiiBCrOnHP48+1Log//Q6cvughxOCgCpgXHJOE95S7Nbn4dsg/ROK8ywS2lWWDA/gx9KOp7w== X-Received: by 10.237.57.137 with SMTP id m9mr4253540qte.35.1484073110850; Tue, 10 Jan 2017 10:31:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 10:31:49 -0800 (PST) In-Reply-To: <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> From: Andy Bierman Date: Tue, 10 Jan 2017 10:31:49 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a11410e6297ff4c0545c1b235 Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 18:31:54 -0000 --001a11410e6297ff4c0545c1b235 Content-Type: text/plain; charset=UTF-8 On Tue, Jan 10, 2017 at 10:18 AM, Robert Wilton wrote: > > > On 10/01/2017 17:25, Andy Bierman wrote: > > > > On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton wrote: > >> >> >> On 10/01/2017 16:16, Juergen Schoenwaelder wrote: >> >>> On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote: >>> >>>> On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>> >>>> On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote: >>>>> >>>>>> I think itt is not realistic to say that datastores are optional. >>>>>> >>>>>> e.g. leaf: If there is a standard way to enable/disable >>>>>> config >>>>>> then individual "enabled" leafs are redundant. However XPath >>>>>> (must/when) >>>>>> has no way to describe if the subtree is enabled (which is a >>>>>> >>>>> show-stopper) >>>>> >>>>> I may not understand what you are saying. From what I know, there are >>>>> implementations that allow to 'comment out' nodes and subtrees and >>>>> that work with clients in a backwards compatible way. >>>>> >>>>> vs . If the applied or operational datastore is >>>>>> assumed, >>>>>> then there is no need to model the redundant config-as-operstate. >>>>>> If this is left out of the model, then the datastore becomes >>>>>> mandatory. >>>>>> If it is left in the model, the datasore becomes redundant. >>>>>> >>>>>> The basic premise that these datastores are optional is flawed. >>>>>> One cannot design a YANG module assuming the datastores are present >>>>>> if they are in fact optional. >>>>>> >>>>> The claim that all datastores are mandatory is equally flawed. >>>>> >>>>> >>>>> correct -- nobody is saying that. >>>> >>> Well, I originally commented on the statement that intened would be >>> required and adding complexity - it does not. >>> >>> >>>> The reason this is different is that the YANG objects are impacted. >>>> Candidate vs. running has no impact whatsoever on the set of >>>> YANG modules. The protocol is not self-selecting some objects >>>> and making other objects invisible. >>>> >>> Yes. And the same is true for intended as long as an implementation >>> does not support templates or inactive configuration objects. >>> >>> But if I want to model , I will soon have to decide >>>> to use and allow all protocols to read it or >>>> model get-state(foo) and require a different module for each >>>> protocol. >>>> >>> If you do /foo and /foo-state, things will just work with or without >>> an operational state datastore. >>> >> True, but there would also be an undesirable duplication of data in the >> data tree. >> >> >> If you have only /foo, then an >>> operational state datastore may come in handy if you have to support >>> config and state with different lifetimes. >>> >> I think that this may be more than "come in handy". I think that there >> would be key information that clients would expect to be available in a >> model but wouldn't be easily retrievable without supporting the operational >> state datastore. Specifically you lose the ability to easily query an >> operational property of a system that can be configured, but hasn't been >> configured. >> >> Example: Consider an Ethernet interface speed leaf that in the running ds >> represents the configured speed, and in the operational state ds represents >> the actual operational speed in use. Normally, the operational speed would >> default to the maximum speed supported by the hardware (or the negotiated >> value if auto-neg is in effect). If a device doesn't support the >> operational state datastore then you wouldn't be able to query the >> operational speed of an interface if it hasn't also been configured. >> > > This is my concern -- that data modelers will put in the leaf > to make sure > all protocols (including existing NETCONF) can retrieve the oper-value. > > I think that there may be a better way here: The data modelers design the > model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the split > config/state trees. E.g. if it finds a config leaf in foo/speed it creates > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > This is a real hack. I liked the if-feature approach much better e.g. leaf oper-speed { if-feature "not operational-datastore"; ... } > For many decades, this has been the design approach. > There have not been many leafs where interactions with control-plane > protocols > is a factor. The SNMP-style solution is ad-hoc, but the problem is > somewhat rare, > so it didn't really matter. > > Yes, OK. But I think that SNMP failed for programmatic configuration, it > only seemed to get traction returning operational state. > > It failed because there are no transactions, not because the oper-speed leaf exists or not. > > > The premise now seems to be that the problem is no longer rare > and lots of type of data is needed. I am not even sure this > will > be true if I2RS is constrained to RIB data (as the charter dictates). > > I think that I2RS is orthogonal to what the operational state datastore is > really solving, it just happens to help for I2RS as well. > > OK -- Joel informs me the I2RS charter is not constrained to RIB data at all. > > > Presumably, the same instrumentation gets invoked for get(oper-speed) as > get-state(admin-speed) > > Yes, in the general case, I think that using the same instrumentation > would be a valid implementation. > > But you may also be able to optimize this to fetching the information from > the running configuration datastore (if you know for sure that the value > will be the same). > > If the additional metadata is being supported and returned then it may > also need to compare the operational value with the configured value and > schema default to choose the correct metadata annotation. > > > > >> If the device support the with-defaults extension and appropriate options >> then they could presumably retrieve the "complex default" value from the >> device using one of the with-default query parameters. >> > > with-defaults is a bit different because the YANG module can provide the > default > even if the server won't. > > I was thinking of the "report-all" option. Wouldn't that mean that the > server would have to return the actual value for a config leaf that had a > complex default value (i.e. based on the hardware present)? > basic=report-all just means the server never suppresses defaults. It always returns them in messages. > > Rob > Andy > > > > >> >> Rob >> >> >> >>> /js >>> >>> >> > Andy > > > --001a11410e6297ff4c0545c1b235 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 10:18 AM, Robert Wilton <<= a href=3D"mailto:rwilton@cisco.com" target=3D"_blank">rwilton@cisco.com= > wrote:
=20 =20 =20



On 10/01/2017 17:25= , Andy Bierman wrote:
=20


On Tue, Jan 10, 2017 at 9:07 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 10/01/2017 16:16, Juergen Schoenwaelder wrote:
On Tue, Jan 10, 2017 at 07:30:51AM -0800, Andy Bierman wrote:
On Mon, Jan 9, 2017 at 11:21 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

On Mon, Jan 09, 2017 at 01:17:09PM -0800, Andy Bierman wrote:
I think itt is not realistic to say that datastores are optional.

e.g. <enabled> leaf:=C2=A0 If there is a standa= rd way to enable/disable config
then individual "enabled" leafs are redunda= nt. However XPath (must/when)
has no way to describe if the subtree is enabled (which is a
show-stopper)

I may not understand what you are saying. From what I know, there are
implementations that allow to 'comment out' nod= es and subtrees and
that work with clients in a backwards compatible way.

<foo-config> vs <foo-oper>.=C2=A0 If the applied or operational datastore is
assumed,
then there is no need to model the redundant config-as-operstate.
If this is left out of the model, then the datastore becomes mandatory.
If it is left in the model, the datasore becomes redundant.

The basic premise that these datastores are optional is flawed.
One cannot design a YANG module assuming the datastores are present
if they are in fact optional.
The claim that all datastores are mandatory is equally flawed.


correct -- nobody is saying that.
Well, I originally commented on the statement that intened would be
required and adding complexity - it does not.
=C2=A0
The reason this is different is that the YANG objects are impacted.
Candidate vs. running has no impact whatsoever on the set of
YANG modules.=C2=A0 The protocol is not self-selecting so= me objects
and making other objects invisible.
Yes. And the same is true for intended as long as an implementation
does not support templates or inactive configuration objects.

But if I want to model <foo-state>, I will soon have to decide
to use <foo-state> and allow all protocols to read it or
model get-state(foo) and require a different module for each
protocol.
If you do /foo and /foo-state, things will just work with or without
an operational state datastore.
True, but there would also be an undesirable duplication of data in the data tree.


=C2=A0 If you have only /foo, then an
operational state datastore may come in handy if you have to support
config and state with different lifetimes.
I think that this may be more than "come in handy".= =C2=A0 I think that there would be key information that clients would expect to be available in a model but wouldn't be easily retrievable without supporting the operational state datastore.=C2=A0 Specifically you lose the ability to easily query an operational property of a system that can be configured, but hasn't been configured.

Example: Consider an Ethernet interface speed leaf that in the running ds represents the configured speed, and in the operational state ds represents the actual operational speed in use.=C2=A0 Normally, the operational speed would default to the maximum speed supported by the hardware (or the negotiated value if auto-neg is in effect). If a device doesn't support the operational state datastore then you wouldn't be able to query the operational speed of an interface if it hasn't also been configured.

This is my concern -- that data modelers will put in the <oper-speed> leaf to make sure
all protocols (including existing NETCONF) can retrieve the oper-value.
I think that there may be a better way here:=C2=A0 The data modelers design the model on the assumption that an operational state datastore will be present.=C2=A0 We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees.=C2=A0 E.g. if = it finds a config leaf in foo/speed it creates a module that contains foo-state/speed.=C2=A0 I've been playing around with pyang and I do= n't think that this would be too hard to do.




This is a real hack.

I liked the if-feature approach much better
e.g.

=C2=A0 =C2=A0leaf oper-speed {
=C2=A0 =C2=A0 =C2= =A0 =C2=A0if-feature "not operational-datastore";
=C2= =A0 =C2=A0 =C2=A0 =C2=A0...
=C2=A0 =C2=A0}

=C2=A0
For many decades, this has been the design approach.
There have not been many leafs where interactions with control-plane protocols
is a factor.=C2=A0 The SNMP-style solution is ad-hoc, but the problem is somewhat rare,
so it didn't really matter.
Yes, OK.=C2=A0 But I think that SNMP failed for programmatic configuration, it only seemed to get traction returning operational state.



It failed bec= ause there are no transactions,
not because the oper-speed leaf e= xists or not.

=C2=A0


The premise now seems to be that the problem is no longer rare
and lots of <oper-speed> type of data is needed.=C2= =A0 I am not even sure this will
be true if I2RS is constrained to RIB data (as the charter dictates).
I think that I2RS is orthogonal to what the operational state datastore is really solving, it just happens to help for I2RS as well.


OK -- Joel informs me the I2= RS charter is not constrained to RIB data at all.

= =C2=A0


Presumably, the same instrumentation gets invoked for get(oper-speed) as get-state(admin-speed)
Yes, in the general case, I think that using the same instrumentation would be a valid implementation.

But you may also be able to optimize this to fetching the information from the running configuration datastore (if you know for sure that the value will be the same).

If the additional metadata is being supported and returned then it may also need to compare the operational value with the configured value and schema default to choose the correct metadata annotation.




If the device support the with-defaults extension and appropriate options then they could presumably retrieve the "complex default" value from the device using o= ne of the with-default query parameters.

with-defaults is a bit different because the YANG module can provide the default
even if the server won't.
I was thinking of the "report-all" option.=C2=A0 Wouldn't= that mean that the server would have to return the actual value for a config leaf that had a complex default value (i.e. based on the hardware present)?

basic=3Dreport-all = just means the server never suppresses defaults.
It always return= s them in <rpc-reply> messages.

=C2=A0
=

Rob

Andy
=C2=A0


=C2=A0

Rob



/js



Andy



--001a11410e6297ff4c0545c1b235-- From nobody Tue Jan 10 11:09:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A86612954C; Tue, 10 Jan 2017 11:09:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.057 X-Spam-Level: X-Spam-Status: No, score=-3.057 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kmz8k75lA41b; Tue, 10 Jan 2017 11:08:58 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0113.outbound.protection.outlook.com [104.47.38.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 441C012950B; Tue, 10 Jan 2017 11:08:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=XCiuURfbkuC+AP9cw8Ya7Uu1SC98aLj8TVE8EliDKKQ=; b=j401j67P8QBDOT5GyllH8dvwLQirOaLgjX1ARlIHo+7fxbWwQ1i0p4IIlWiGT9+n3bJs5cY2miVCc3O+wXjL4HMtPArVyO3Er3LQOvSNQu65S5ui1O5uUCId+OIUhI1MwUy/CBeuB18IVi7ibnecuwDUL6g5NUFoCRH5OvBsmhs= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 19:08:48 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 19:08:48 +0000 From: Kent Watsen To: Andy Bierman , Robert Wilton Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa2aD89RzNHtVJkqt3M8SCXRmh6EyBQSAgAADy4D//7aBAA== Date: Tue, 10 Jan 2017 19:08:47 +0000 Message-ID: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: ea6e7eb4-ea5f-4997-205f-08d4398c1b2d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:z6KKg2XgpMFAGVuhUKhlrKFs7vkOQE7JW6TlyZMeu9Fgs6GSlBebdwubDo3uE7p2cEiny7d9FoXwgR9mxBmoNmcEmEiokZyIAS6vQtnjPO7w8XtcLQ4h1qInCRtkhwblLdYxeOVWmutwCWyt9UdXXPDCtfrm0Qd5QIYReEM3Iqu9UfYvKwOHH1Gn/BCtuTjUh35rnaTlovpUbH/43r2pWf/A/mPCCpI1E6Pg+R00ZJocHQwOuSEMlZfD8mCqA6KGcMNG4IMroBKEobXflN2EfpgggUQWFm/6u4QSvZ0IL7G4rLrmeuyIm9dOk4VXb81ctSB5nn61UjpG7iVTfxayUkWEwNh85m6YyRIe0tMvbWQJzA9TzL3/ZcdAdKPysiPvVWge21WCKkU3wK/QcdHjf7SXxtWOWQewrANqHWpgrd8siR1elzcESJ+wjgQgvyXMszHvktDM/07cripWfJwvTQ== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(150554046322364)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39860400002)(39450400003)(39840400002)(51444003)(199003)(189002)(7736002)(105586002)(106356001)(106116001)(54906002)(2950100002)(76176999)(50986999)(54356999)(101416001)(68736007)(6116002)(33656002)(8936002)(5660300001)(81166006)(561944003)(81156014)(3846002)(66066001)(93886004)(102836003)(36756003)(8676002)(99286003)(2900100001)(6512007)(6306002)(54896002)(4001350100001)(189998001)(6506006)(77096006)(122556002)(6486002)(6436002)(229853002)(86362001)(38730400001)(3280700002)(92566002)(82746002)(3660700001)(83506001)(97736004)(5001770100001)(25786008)(4326007)(83716003)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 19:08:47.8368 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 19:09:00 -0000 --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0aGluayB0aGF0IHRoZXJlIG1heSBiZSBhIGJldHRlciB3YXkgaGVyZTogIFRoZSBkYXRhIG1v ZGVsZXJzIGRlc2lnbiB0aGUgbW9kZWwgb24gdGhlIGFzc3VtcHRpb24gdGhhdCBhbiBvcGVyYXRp b25hbCBzdGF0ZSBkYXRhc3RvcmUgd2lsbCBiZSBwcmVzZW50LiAgV2UgY2FuIHRoZW4gdXNlIGEg cHlhbmcgcGx1Z2luIHRvIGdlbmVyYXRlIGFuIGV4dHJhIFlBTkcgbW9kZWwgdGhhdCBjb250YWlu cyB0aGUgbWlzc2luZyBzdGF0ZSBsZWF2ZXMgdGhhdCB3b3VsZCBiZSByZXF1aXJlZCBmb3IgdGhl IHNwbGl0IGNvbmZpZy9zdGF0ZSB0cmVlcy4gIEUuZy4gaWYgaXQgZmluZHMgYSBjb25maWcgbGVh ZiBpbiBmb28vc3BlZWQgaXQgY3JlYXRlcyBhIG1vZHVsZSB0aGF0IGNvbnRhaW5zIGZvby1zdGF0 ZS9zcGVlZC4gIEkndmUgYmVlbiBwbGF5aW5nIGFyb3VuZCB3aXRoIHB5YW5nIGFuZCBJIGRvbid0 IHRoaW5rIHRoYXQgdGhpcyB3b3VsZCBiZSB0b28gaGFyZCB0byBkby4NCg0KSSBnZW5lcmFsbHkg c3VwcG9ydCB0aGlzIGFwcHJvYWNoIGFzIHN0b3AtZ2FwIHNvbHV0aW9uIHdoaWxlIHRoZSBpbmR1 c3RyeSBnb2VzIHRocnUgdGhlIHRyYW5zaXRpb24uICBIb3dldmVyLCBJIHJlY29tbWVuZCBhIHZh cmlhbnQgd2hlcmVieSB0aGUgcHlhbmcgcGx1Z2luIG9ubHkgbWlncmF0ZXMgdGhlIGNvbmZpZyBm YWxzZSB2YWx1ZXMgKG5vdCBhbHNvIHRoZSBjb25maWcgdHJ1ZSB2YWx1ZXMpLiAgVGhlIHJlYXNv biBmb3IgdGhpcyBpcyBhcyBmb2xsb3dzOg0KDQpNaWdyYXRpbmcgb25seSB0aGUgY29uZmlnIGZh bHNlIHZhbHVlcyBpcyBzdWZmaWNpZW50IGZvciBtYXRjaGluZyBleGlzdGluZyBmdW5jdGlvbmFs aXR5IChyZWFkOiBhIG11c3QtaGF2ZSByZXF1aXJlbWVudCk7IHRoYXQgaXMsIGN1cnJlbnRseSB0 b3AtbGV2ZWwgL2Zvby1zdGF0ZSBpcyB1c2VkIHRvIHN1cHBvcnQgY29udmV5aW5nIHRoZSBvcHN0 YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHRoYXQgaGF2ZSBsaWZldGltZXMgaW5k ZXBlbmRlbnQgb2YgY29uZmlnLg0KDQpNaWdyYXRpbmcgdGhlIGNvbmZpZyB0cnVlIG5vZGVzIGFs c28gaXMgcG9zc2libGUsIGJ1dCBvbmx5IG5lZWRlZCBpZiB3YW50aW5nIHRvIHJlcG9ydCB0aGUg b3BzdGF0ZSB2YWx1ZSBmb3IgY29uZmlnIHRydWUgbm9kZXMgKGUuZy4sIGhvc3RuYW1lKSwgYnV0 IHRoaXMgd291bGQgYmUgYWJvdmUgYW5kIGJleW9uZCB3aGF0IGlzIHBvc3NpYmxlIHRvZGF5IChy ZWFkOiBhIG5pY2UtdG8taGF2ZSByZXF1aXJlbWVudCksIGFuZCBoZW5jZSBJ4oCZZCByYXRoZXIg c3RlZXIgZm9sa3MgdG93YXJkcyB0aGUgbmV3IGFwcHJvYWNoIHJhdGhlciB0aGFuIGRvdWJsZS1k b3duIG9uIHRoZSBhcHByb2FjaCB3ZeKAmXJlIHRyeWluZyB0byBnZXQgYXdheSBmcm9tLg0KDQoN Cg0KPiBUaGlzIGlzIGEgcmVhbCBoYWNrLg0KPg0KPiBJIGxpa2VkIHRoZSBpZi1mZWF0dXJlIGFw cHJvYWNoIG11Y2ggYmV0dGVyDQo+IGUuZy4NCj4NCj4gICBsZWFmIG9wZXItc3BlZWQgew0KPiAg ICAgICBpZi1mZWF0dXJlICJub3Qgb3BlcmF0aW9uYWwtZGF0YXN0b3JlIjsNCj4gICAgICAgLi4u DQo+ICAgfQ0KDQpJcyB5b3VyIHByb3Bvc2FsIGZvciB0aGUgWUFORyBtb2R1bGVzIHRvIHNpbXVs dGFuZW91c2x5IGRlZmluZSBib3RoIG9wc3RhdGUtYXdhcmUgYW5kIG9wc3RhdGUtdW5hd2FyZSB0 cmVlcz8gIFdvdWxkbuKAmXQgdGhhdCBtYWtlIHRoZSBtb2R1bGVzIGxlc3MgcmVhZGFibGUsIGxh cmdlbHkgcmVkdW5kYW50LCBhbmQgcmlwZSBmb3IgaW5jb25zaXN0ZW5jaWVzPw0KDQoNCg0KS2Vu dCAgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCg== --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnANCgl7bXNvLXN0 eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0Kc3Bh bi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1m YW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6 d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25l IG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHls ZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rp b24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBp bjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+ DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUi IHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDoxMS41NXB0Ij5JIHRoaW5rIHRoYXQgdGhlcmUg bWF5IGJlIGEgYmV0dGVyIHdheSBoZXJlOiZuYnNwOyBUaGUgZGF0YSBtb2RlbGVycyBkZXNpZ24g dGhlIG1vZGVsIG9uIHRoZSBhc3N1bXB0aW9uIHRoYXQgYW4gb3BlcmF0aW9uYWwgc3RhdGUgZGF0 YXN0b3JlIHdpbGwgYmUgcHJlc2VudC4mbmJzcDsgV2UgY2FuIHRoZW4gdXNlIGEgcHlhbmcgcGx1 Z2luIHRvIGdlbmVyYXRlIGFuIGV4dHJhIFlBTkcNCiBtb2RlbCB0aGF0IGNvbnRhaW5zIHRoZSBt aXNzaW5nIHN0YXRlIGxlYXZlcyB0aGF0IHdvdWxkIGJlIHJlcXVpcmVkIGZvciB0aGUgc3BsaXQg Y29uZmlnL3N0YXRlIHRyZWVzLiZuYnNwOyBFLmcuIGlmIGl0IGZpbmRzIGEgY29uZmlnIGxlYWYg aW4gZm9vL3NwZWVkIGl0IGNyZWF0ZXMgYSBtb2R1bGUgdGhhdCBjb250YWlucyBmb28tc3RhdGUv c3BlZWQuJm5ic3A7IEkndmUgYmVlbiBwbGF5aW5nIGFyb3VuZCB3aXRoIHB5YW5nIGFuZCBJIGRv bid0IHRoaW5rIHRoYXQNCiB0aGlzIHdvdWxkIGJlIHRvbyBoYXJkIHRvIGRvLjxvOnA+PC9vOnA+ PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBnZW5lcmFsbHkgc3VwcG9ydCB0aGlzIGFwcHJvYWNoIGFz IHN0b3AtZ2FwIHNvbHV0aW9uIHdoaWxlIHRoZSBpbmR1c3RyeSBnb2VzIHRocnUgdGhlIHRyYW5z aXRpb24uJm5ic3A7IEhvd2V2ZXIsIEkgcmVjb21tZW5kIGEgdmFyaWFudCB3aGVyZWJ5IHRoZSBw eWFuZyBwbHVnaW4gb25seSBtaWdyYXRlcyB0aGUgY29uZmlnIGZhbHNlIHZhbHVlcyAobm90IGFs c28gdGhlIGNvbmZpZyB0cnVlIHZhbHVlcykuJm5ic3A7IFRoZSByZWFzb24NCiBmb3IgdGhpcyBp cyBhcyBmb2xsb3dzOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NaWdyYXRpbmcgb25seSB0aGUg Y29uZmlnIGZhbHNlIHZhbHVlcyBpcyBzdWZmaWNpZW50IGZvciBtYXRjaGluZyBleGlzdGluZyBm dW5jdGlvbmFsaXR5IChyZWFkOiBhIG11c3QtaGF2ZSByZXF1aXJlbWVudCk7IHRoYXQgaXMsIGN1 cnJlbnRseSB0b3AtbGV2ZWwgL2Zvby1zdGF0ZSBpcyB1c2VkIHRvIHN1cHBvcnQgY29udmV5aW5n IHRoZSBvcHN0YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHRoYXQNCiBoYXZlIGxp ZmV0aW1lcyBpbmRlcGVuZGVudCBvZiBjb25maWcuJm5ic3A7IDxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj5NaWdyYXRpbmcgdGhlIGNvbmZpZyB0cnVlIG5vZGVzIGFsc28gaXMgcG9zc2libGUsIGJ1 dCBvbmx5IG5lZWRlZCBpZiB3YW50aW5nIHRvIHJlcG9ydCB0aGUgb3BzdGF0ZSB2YWx1ZSBmb3Ig Y29uZmlnIHRydWUgbm9kZXMgKGUuZy4sIGhvc3RuYW1lKSwgYnV0IHRoaXMgd291bGQgYmUgYWJv dmUgYW5kIGJleW9uZCB3aGF0IGlzIHBvc3NpYmxlIHRvZGF5IChyZWFkOiBhIG5pY2UtdG8taGF2 ZSByZXF1aXJlbWVudCksDQogYW5kIGhlbmNlIEnigJlkIHJhdGhlciBzdGVlciBmb2xrcyB0b3dh cmRzIHRoZSBuZXcgYXBwcm9hY2ggcmF0aGVyIHRoYW4gZG91YmxlLWRvd24gb24gdGhlIGFwcHJv YWNoIHdl4oCZcmUgdHJ5aW5nIHRvIGdldCBhd2F5IGZyb20uDQo8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsg VGhpcyBpcyBhIHJlYWwgaGFjay48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDs8bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSSBsaWtlZCB0aGUgaWYtZmVhdHVyZSBhcHByb2Fj aCBtdWNoIGJldHRlcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+Jmd0OyBlLmcuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7IDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAmbmJzcDtsZWFmIG9wZXItc3BlZWQgezxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwO2lmLWZlYXR1cmUgJnF1b3Q7bm90IG9wZXJhdGlvbmFsLWRhdGFz dG9yZSZxdW90Ozs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsuLi48bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsmbmJzcDsgJm5ic3A7fTxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklzIHlvdXIgcHJvcG9zYWwgZm9yIHRoZSBZ QU5HIG1vZHVsZXMgdG8gc2ltdWx0YW5lb3VzbHkgZGVmaW5lIGJvdGggb3BzdGF0ZS1hd2FyZSBh bmQgb3BzdGF0ZS11bmF3YXJlIHRyZWVzPyZuYnNwOyBXb3VsZG7igJl0IHRoYXQgbWFrZSB0aGUg bW9kdWxlcyBsZXNzIHJlYWRhYmxlLCBsYXJnZWx5IHJlZHVuZGFudCwgYW5kIHJpcGUgZm9yIGlu Y29uc2lzdGVuY2llcz88bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48 L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPktlbnQmbmJzcDsgLy8gYXMgYSBjb250cmlidXRvcjxvOnA+PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1s Pg0K --_000_0A89256A35FA4FC395FF0C88A9B5F4ECjunipernet_-- From nobody Tue Jan 10 12:01:05 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2FD86129865 for ; Tue, 10 Jan 2017 12:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LW-t5wfWAxuV for ; Tue, 10 Jan 2017 12:00:59 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EFBDD129D8E for ; Tue, 10 Jan 2017 12:00:43 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id 11so87940113qkl.3 for ; Tue, 10 Jan 2017 12:00:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OaWJtltIJmZr6QRPK8p8efmP/B3fcxTYEcgfgQwQXUY=; b=gRfwV9BWWNkFVr1Ti8J13Ufn1WotIJvci7cBwt9sKwbWtuWiwx2GrJk939OOt0Tnow 7geUf+9XQtpuDJoFU9q0xKGIzaucKX7JVZirW36IkPjXWtdWDY+KstCA2OzyRPjVP+A/ NXcVj95dLgUNr3wr3cNinYKV2G8DUmmJEmMqHU3D88oCXNTzt/HzGaiGmESz/EngvrF/ hiA9iLDXQQ1zPid410x9iAMCk2I/F6Pi82lo/zJESGIaUm9dZsC5HvYtxClH3QI2hlIb 1iCcDrxkTLcvelIZPwXWvmmoC1TIxUOmd7k0P1mhbNhn+WlaaHlmtued0IHJl2lw2ZPC iKUA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OaWJtltIJmZr6QRPK8p8efmP/B3fcxTYEcgfgQwQXUY=; b=rkdNjKPBqOq/dgwCtHrKYIz4ZQxmWg/P+fA6Z/kz3C7j2ChveiXzoPGLRfYT87lwNp K9WpPMjjE6fQsJaMG1HLFOYTyT2wNn8oYKlVx1W3q7ERMsmV/uAhxgud71jsZ4wkdT7K j7uGpGsxfbytM/ehXfkjserNgaG3Bac5J16uPzvDRX9PgYsnYm/v5S+P1FIK+B7a05dB qm2tDnJScfyLFIDg7lKT1iid4RVCov53RuWr5Dv/Y7T36dxEnMqP5l0AXKhNpXC3KaME a2ggoTvhGDa69yy5CjoIpAVKIWolYqXuMETxps4/InENWbsmWcIYe7xF0fyIGrwP9fZn wXdg== X-Gm-Message-State: AIkVDXIFvCchyv7foRsRXSmLJB3Wub2VNIRaeYC7jPU6ApM/4SNfNJ6kVklAqMAu4z2twt061IGbuKnV6SsIUw== X-Received: by 10.55.20.137 with SMTP id 9mr4378065qku.237.1484078441906; Tue, 10 Jan 2017 12:00:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 12:00:40 -0800 (PST) In-Reply-To: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> From: Andy Bierman Date: Tue, 10 Jan 2017 12:00:40 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1144d226599e0c0545c2f0fe Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 20:01:00 -0000 --001a1144d226599e0c0545c2f0fe Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 11:08 AM, Kent Watsen wrote: > I think that there may be a better way here: The data modelers design th= e > model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the spl= it > config/state trees. E.g. if it finds a config leaf in foo/speed it creat= es > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > > I generally support this approach as stop-gap solution while the industry > goes thru the transition. However, I recommend a variant whereby the pya= ng > plugin only migrates the config false values (not also the config true > values). The reason for this is as follows: > > > > Migrating only the config false values is sufficient for matching existin= g > functionality (read: a must-have requirement); that is, currently top-lev= el > /foo-state is used to support conveying the opstate for system-generated > objects, that have lifetimes independent of config. > > > > Migrating the config true nodes also is possible, but only needed if > wanting to report the opstate value for config true nodes (e.g., hostname= ), > but this would be above and beyond what is possible today (read: a > nice-to-have requirement), and hence I=E2=80=99d rather steer folks towar= ds the new > approach rather than double-down on the approach we=E2=80=99re trying to = get away > from. > > > > > > > > > This is a real hack. > > > > > > I liked the if-feature approach much better > > > e.g. > > > > > > leaf oper-speed { > > > if-feature "not operational-datastore"; > > > ... > > > } > > > > Is your proposal for the YANG modules to simultaneously define both > opstate-aware and opstate-unaware trees? Wouldn=E2=80=99t that make the = modules > less readable, largely redundant, and ripe for inconsistencies? > > > > > I think it is better to have a human decide what is in the module instead of relying on a pyang plugin to generate some additional module that follows some simplistic pattern. Of course this solution only works if the value-set of operational data is exactly the same as the configurable value-set (which is sometimes not the case at all). What is an "opstate-aware tree". The point of this work is that the opstate tree goes away and is replaced b= y a protocol operation instead. In fact, there are no new datastores needed whatsoever to add the RPC , or even . > > Kent // as a contributor > > > > > Andy --001a1144d226599e0c0545c2f0fe Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 11:08 AM, Kent Watsen <kwatsen@juniper.net> wrote:

I think that there may= be a better way here:=C2=A0 The data modelers design the model on the assu= mption that an operational state datastore will be present.=C2=A0 We can th= en use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for th= e split config/state trees.=C2=A0 E.g. if it finds a config leaf in foo/spe= ed it creates a module that contains foo-state/speed.=C2=A0 I've been p= laying around with pyang and I don't think that this would be too hard to do.

=C2=A0

I generally support this approach as stop-gap soluti= on while the industry goes thru the transition.=C2=A0 However, I recommend = a variant whereby the pyang plugin only migrates the config false values (n= ot also the config true values).=C2=A0 The reason for this is as follows:

=C2=A0

Migrating only the config false values is sufficient= for matching existing functionality (read: a must-have requirement); that = is, currently top-level /foo-state is used to support conveying the opstate= for system-generated objects, that have lifetimes independent of config.=C2=A0

=C2=A0

Migrating the config true nodes also is possible, bu= t only needed if wanting to report the opstate value for config true nodes = (e.g., hostname), but this would be above and beyond what is possible today= (read: a nice-to-have requirement), and hence I=E2=80=99d rather steer folks towards the new approach rather t= han double-down on the approach we=E2=80=99re trying to get away from.

=C2=A0

=C2=A0

=C2=A0

> This is a real hack.

>=C2=A0

> I liked the if-feature approach much better<= /u>

> e.g.

>

>=C2=A0 =C2=A0leaf oper-speed {

>=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not = operational-datastore";

>=C2=A0 =C2=A0 =C2=A0 =C2=A0...

>=C2=A0 =C2=A0}

=C2=A0

Is your proposal for the YANG modules to simultaneou= sly define both opstate-aware and opstate-unaware trees?=C2=A0 Wouldn=E2=80= =99t that make the modules less readable, largely redundant, and ripe for i= nconsistencies?

=C2=A0

=C2=A0


<= /div>

I think it is better to have a human decide what i= s in the module
instead of relying on a pyang plugin to generate = some additional module
that follows some simplistic pattern.

Of course this solution only works if the value-set of= operational data
is exactly the same as the configurable value-s= et (which is sometimes
not the case at all).

=
What is an =C2=A0"opstate-aware tree".

The point of this work is that the opstate tree goes away and is re= placed by
a protocol operation instead.

= In fact, there are no new datastores needed whatsoever to
add the= RPC <resource-ready>, or even <get-operational>.


=C2=A0

Kent=C2=A0 // as a contributor

=C2=A0

=C2=A0


<= /div>

Andy
=C2=A0

--001a1144d226599e0c0545c2f0fe-- From nobody Tue Jan 10 13:20:10 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCA37129DA9; Tue, 10 Jan 2017 13:20:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZzU0e_aCgFvg; Tue, 10 Jan 2017 13:20:07 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0120.outbound.protection.outlook.com [104.47.33.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D80531295B0; Tue, 10 Jan 2017 13:20:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=nllfPif2a7IGl8DlSH0J5MKQOvukznkh6VwbUBCkZN8=; b=ZidRpmzqwaLLCVHlVSxlAVWT08qnapvLnK9wksIWxd5nr6MrN3aZkTiRibQDME93LGBZSsgBw+qMU8G3GNQuMUsG5APb6Kiu6kw3mAlRN5kEbJcSsdJxYB8eo1TbY1ufwke123HlmGWmSPh0I1PHgEMfZ8FkcRcQ1nKBcZXA6v0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Tue, 10 Jan 2017 21:20:04 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Tue, 10 Jan 2017 21:20:04 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa2aD89RzNHtVJkqt3M8SCXRmh6EyBQSAgAADy4D//7aBAIAAYlIA///CXIA= Date: Tue, 10 Jan 2017 21:20:04 +0000 Message-ID: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 71b1e4a4-b19d-4973-e01e-08d4399e71c6 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:7nAWm9zTBjpqTZfudvM8iCGyQtkuS1E6+AuNGow4bcybmNy8OqzRjPlM3tToqYXld9ArAjAVrcx3wy15Orjb7+NqmJ3/dSakTkQrO16sBrn1GzLVShz/G9XHm2hCzLeoi2zqOqWHWO8mnpkdVFKjS6RThFZWCmpE/1eRVTY8Mn49dcll77QR3vsD/5cOLi67Lg1KBielUfU6eUTD1Avit0CdKfkOJCQjqTrlyHLfvb+JJCPUid99oLShk/duH97UFyQxKMOny1aZC/5GtScBwBziIxcUBo6roB9Dr/QPas5XJ11VFVVXCpIRpDRXHhlLt/B/X5XGdxer45GwTzmnlzsBj3dC0AHyGTckmKraWcW8w+mCa2D2xqVQp04/rRx6eT75gPzwB6JK3zULsf66okUeIcxUj7MDPQw2d5tYulFQJLScJwzls3F8VK9TRjbVXKV7wdVMWMqw/OE9ct5N/A== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(150554046322364); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01834E39B7 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(199003)(189002)(2950100002)(305945005)(7736002)(110136003)(106356001)(106116001)(54906002)(105586002)(76176999)(50986999)(54356999)(6916009)(101416001)(68736007)(6116002)(33656002)(5660300001)(8936002)(81166006)(81156014)(3846002)(66066001)(93886004)(102836003)(36756003)(8676002)(99286003)(2900100001)(6512007)(4001350100001)(189998001)(77096006)(6506006)(122556002)(6486002)(6436002)(229853002)(86362001)(38730400001)(3280700002)(82746002)(3660700001)(92566002)(83506001)(97736004)(25786008)(83716003)(4326007)(2906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Jan 2017 21:20:04.1196 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 21:20:09 -0000 DQo+IEkgdGhpbmsgaXQgaXMgYmV0dGVyIHRvIGhhdmUgYSBodW1hbiBkZWNpZGUgd2hhdCBpcyBp biB0aGUgbW9kdWxlDQo+IGluc3RlYWQgb2YgcmVseWluZyBvbiBhIHB5YW5nIHBsdWdpbiB0byBn ZW5lcmF0ZSBzb21lIGFkZGl0aW9uYWwgbW9kdWxlDQo+IHRoYXQgZm9sbG93cyBzb21lIHNpbXBs aXN0aWMgcGF0dGVybi4NCg0KSXQgbWF5IGJlIHNpbXBsZSwgYnV0IEnigJltIHRoaW5raW5nIHRo YXTigJlzIG9ubHkgYmVjYXVzZSBpdOKAmXMgbm90IHRyaWNreSAgOykNCg0KDQo+IE9mIGNvdXJz ZSB0aGlzIHNvbHV0aW9uIG9ubHkgd29ya3MgaWYgdGhlIHZhbHVlLXNldCBvZiBvcGVyYXRpb25h bCBkYXRhDQo+IGlzIGV4YWN0bHkgdGhlIHNhbWUgYXMgdGhlIGNvbmZpZ3VyYWJsZSB2YWx1ZS1z ZXQgKHdoaWNoIGlzIHNvbWV0aW1lcw0KPiBub3QgdGhlIGNhc2UgYXQgYWxsKS4NCg0KVGhlIHZh bHVlLXNldCBvZiB0aGUgb3BlcmF0aW9uYWwgZGF0YSB3b3VsZCBiZSB0aGUgY29tYmluYXRpb24g b2YgYm90aCB0aGUgY29uZmlnIHRydWUgYW5kIGNvbmZpZyBmYWxzZSBub2Rlcy4gICBbRGlkIHlv dSBzZWUgdGhpcyBpbiBteSBsYXN0IHJlc3BvbnNlPyBJIHJlY2VpdmVkIGFuIG9mZmxpbmUgbWVz c2FnZSBpbmRpY2F0aW5nIHRoYXQgbXkgcHJldmlvdXMgcmVzcG9uc2Ugd2FzIHNvbWV3aGF0IG1h bGZvcm1lZCwgc28geW91IG1pZ2h04oCZdmUgbWlzc2VkIGl0Li4uXS4gICBUaGUgY29uZmlnIGZh bHNlIG5vZGVzIGFyZSBvYnZpb3VzbHkgcGFydCBvZiB0aGUgb3BlcmF0aW9uYWwgZGF0YS4gIEZv ciB0aGUgY29uZmlnIHRydWUgbm9kZXMsIEnigJl2ZSBiZWVuIHN3YXllZCB0byBiZWxpZXZlIHRo YXQgZXZlcnkgY29uZmlnIHRydWUgbm9kZSBjYW4gYWxzbyBoYXZlIGFuIG9wZXJhdGlvbmFsIHZh bHVlLiAgSSBkaWRu4oCZdCB0aGluayBzbyBhdCBmaXJzdCwgdXNpbmcg4oCYaG9zdG5hbWXigJkg YXMgYW4gZXhhbXBsZSB0byBtYWtlIG15IHBvaW50LCBidXQgaXQgd2FzIHBvaW50ZWQgb3V0IHRo YXQgdGhlIGFkbWluIG1pZ2h0IGNpcmN1bXZlbnQgdGhlIFlBTkctZHJpdmVuIGNvbmZpZyBlbmdp bmUgY29tcGxldGVseSBhbmQgc2V0IHRoZSBob3N0bmFtZSB2aWEgdGhlIFVOSVggY29tbWFuZCBs aW5lIGluc3RlYWQuICBJbiB0aGlzIGNhc2UsIHRoZSBpbnRlbmRlZCBob3N0bmFtZSB2YWx1ZSBt aWdodCBkaWZmZXIgZnJvbSB0aGUgb3BlcmF0aW9uYWwgaG9zdG5hbWUgdmFsdWUuICBFdmVuIGZv ciBub2RlcyB3aGVyZSB3ZeKAmXJlIGNvbnZpbmNlZCB0aGVyZSBjYW4gbmV2ZXIgYmUgYW4gb3Bl cmF0aW9uYWwgdmFsdWUgdGhhdCBkaWZmZXJzIGZyb20gdGhlIGludGVuZGVkIHZhbHVlLCB0aGVy ZSBzdGlsbCBtaWdodCBiZSBhIHByb3BhZ2F0aW9uIGRlbGF5IHRoYXQgY2F1c2VzIGEgZGlmZmVy ZW5jZSB0byBiZSBwZXJjZWl2ZWQgaW4gdGltZS4gIEFsbCB0aGlzIHBvaW50cyB0byBhIHJhdGhl ciBjb25zZXJ2YXRpdmUgYW5kIHRoYW5rZnVsbHkgc2ltcGxlIHNvbHV0aW9uIHRoYXQgdGhlIHZh bHVlLXNldCBvZiBvcHN0YXRlIGlzIHRoZSBjb21iaW5hdGlvbiBvZiAqYWxsKiB0aGUgY29uZmln IHRydWUgYW5kIGNvbmZpZyBmYWxzZSBub2Rlcy4NCg0KDQoNCj4gV2hhdCBpcyBhbiAib3BzdGF0 ZS1hd2FyZSB0cmVlIi4NCg0KSSBzaG91bGTigJl2ZSB3cml0dGVuIOKAnG9wc3RhdGUtYXdhcmUg ZGF0YSBtb2RlbOKAnS4gICANCg0KVG8gYmUgY2xlYXIsIGJ5IOKAnG9wc3RhdGUtYXdhcmUgdHJl ZeKAnSwgSSBtZWFudCB0aGUgWUFORyBtb2R1bGUgd291bGQgb25seSBoYXZlIGEgdG9wLWxldmVs IC9mb28gdHJlZSB0aGF0IGhhcyBib3RoIGNvbmZpZyB0cnVlIGFuZCBjb25maWcgZmFsc2Ugbm9k ZXMsIHdpdGggdGhlIGV4cGVjdGF0aW9uIHRoYXQgdGhlIHNvbHV0aW9uIHByb3ZpZGVkIGJ5IGRy YWZ0LWlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3JlcyBlbmFibGVzIDEpIG9wc3RhdGUgZm9y IGJvdGggc3lzdGVtLWdlbmVyYXRlZCBvYmplY3RzIGFzIHdlbGwgYXMgZm9yIGNvbmZpZyB0cnVl IG5vZGVzIGFuZCAyKSBvcHN0YXRlIGZvciBhbGwgY29uZmlnIHRydWUgbm9kZXMgYWxzbyAobm90 ZTogdGhpcyBkb2VzbuKAmXQgcmVtb3ZlIHRoZSBuZWVkIGZvciBleHBsaWNpdCBjb25maWcgZmFs c2Ugbm9kZXMgZm9yIG5lZ290aWF0ZWQgdmFsdWVzIGxpa2UgTVRVKS4NCg0KU2ltaWxhcmx5LCBi eSDigJxvcHN0YXRlLXVuYXdhcmUgdHJlZeKAnSwgSSBtZWFudCB0aGUgWUFORyBtb2R1bGUgd291 bGQgaGF2ZSBib3RoIHRvcC1sZXZlbCAvZm9vIGFuZCAvZm9vLXN0YXRlIHRyZWVzLiAgRXNzZW50 aWFsbHksIHdoYXQgd2UgaGF2ZSB0b2RheSwgd2hpY2ggd2XigJlyZSB0cnlpbmcgdG8gZ2V0IGF3 YXkgZnJvbS4NCg0KDQo+IFRoZSBwb2ludCBvZiB0aGlzIHdvcmsgaXMgdGhhdCB0aGUgb3BzdGF0 ZSB0cmVlIGdvZXMgYXdheSBhbmQgaXMgcmVwbGFjZWQgYnkNCj4gYSBwcm90b2NvbCBvcGVyYXRp b24gaW5zdGVhZC4NCg0KQ29ycmVjdCwgdGhlIGhvcGUgaXMgdGhhdCB0aGUgdG9wLWxldmVsIC9m b28tc3RhdGUgdHJlZSBubyBsb25nZXIgbmVlZHMgdG8gYmUgZGVmaW5lZCBpbiBZQU5HIG1vZHVs ZXMuICBUaGlzIGlzIHRoZSBnb2FsIGFzIHdlIGJlbGlldmUgaXQgd2lsbCBtYWtlIFlBTkcgbW9k dWxlcyBlYXNpZXIgdG8gcmVhZCBhbmQgd3JpdGUuDQoNCg0KPiBJbiBmYWN0LCB0aGVyZSBhcmUg bm8gbmV3IGRhdGFzdG9yZXMgbmVlZGVkIHdoYXRzb2V2ZXIgdG8NCj4gYWRkIHRoZSBSUEMgPHJl c291cmNlLXJlYWR5Piwgb3IgZXZlbiA8Z2V0LW9wZXJhdGlvbmFsPi4NCg0KSeKAmW0gbm90IHN1 cmUgd2hhdCB5b3UgbWVhbiBieSBSUEMgPHJlc291cmNlLXJlYWR5Pi4gIFRydWUsIGEgPGdldC1v cGVyYXRpb25hbD4gUlBDIGNvdWxkIGJlIGRlZmluZWQgbm93LCBidXQgd2XigJlkIHN0aWxsIHdh bnQgdGhlIFlBTkcgbW9kdWxlcyB0byBiZSBhIGNlcnRhaW4gd2F5IGFuZCB3ZeKAmWQgc3RpbGwg d2FudCB0byBkZWZpbmUgYSBjb25jZXB0dWFsIG9wZXJhdGlvbmFsLXN0YXRlIGRhdGFzdG9yZSBz byB0aGF0IHdlIGNvdWxkIGRlc2NyaWJlIGl0IHVuYW1iaWd1b3VzbHkuDQoNCg0KS2VudCAvLyBh cyBhIGNvbnRyaWJ1dG9yDQoNCg0K From nobody Tue Jan 10 14:23:27 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C1FE1295EA for ; Tue, 10 Jan 2017 14:23:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JmgrvEyW3BVA for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB6C21294BC for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id s140so167705546qke.0 for ; Tue, 10 Jan 2017 14:23:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=88qnGhPZ24csPvO5kEq28rtGhI0d12GPmRXonJYMwj0=; b=q1LyuQgyzAXdK04YCw9N3PaMWKzPhRIrucMCXeWlXvffAvxjbkDJLDSKqYAvLXHL8A mLe77Gkqh64KNX+ljn7St8yFih6u4eGtskl4BBMD9h1/UfM6tIIRzTeq0JmHIwFQ/ieA hCalsj7Rjpch4K5bJ82sYyg95iemHKMUdX6Jkgem1RS+M27rZ4fuqSpWrDyyKE4MxwLM 1PgXMGEf+9Z5rWWtWbO5VkPNlQfS7FzFIQ2k+wINtcGBAApI0NRClWaVP2rBRpDL6vri DjChFI7C1VPh40s/c8t3EOuas06vzKNXql1+kapHVt82C4I4Ki8l3oNbWern1bu48dn9 nHKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=88qnGhPZ24csPvO5kEq28rtGhI0d12GPmRXonJYMwj0=; b=uKWZTUjJkL+pmRCAzEWNTpatO/Xl2NDY4GwHJQyIsrnv1zWCRHd4o5fGu8tN2v49G1 c19ZXb3veTjJa4XGR3BJLIdokl1rVA09KPh5XBuHKtCpji8nkviWQA9L+Qzj+AA8KHvi R0VXNQh/lah35O7VIphpaP4jt2UYUdjBGQBI4CB/EKDCIVWIyM/gG/RbXkxK4l/QZRcc rPQ9e0JohD0cgd7o5f4fzYjNizvxY/A6WnAffLGzOtsdX9vfhQBjQJdaK56KzO4URmcl 9DfKGtssOtFvrLwaITGFU9a9IUdrR47snKg01wSEObG03srta4Ap1ae0hu6/GiLxAvBJ IsKA== X-Gm-Message-State: AIkVDXI7ZFMr1maJ2hHjZn7wDSQ0kS38QmW7aZy8PuHmPuNEmoMaYyTkppQNUYnwJeLncAKJNgkR8k5xfLxyrQ== X-Received: by 10.55.152.4 with SMTP id a4mr4980500qke.69.1484087003896; Tue, 10 Jan 2017 14:23:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 14:23:23 -0800 (PST) In-Reply-To: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> References: <5ECFBE11-58AF-4447-BFF2-72105067A8FF@nic.cz> <159833c6738.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <4C501719-B84F-41E4-9064-1E9BFE82A9E0@nic.cz> <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> From: Andy Bierman Date: Tue, 10 Jan 2017 14:23:23 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c07ecfaaef0ab0545c4ee9d Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 22:23:26 -0000 --94eb2c07ecfaaef0ab0545c4ee9d Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen wrote: > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional module > > that follows some simplistic pattern. > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky ;) > > The client and server developers still need to know about this auto-generated module and implement it. Operators might have to know about it to use it. > > Of course this solution only works if the value-set of operational data > > is exactly the same as the configurable value-set (which is sometimes > > not the case at all). > > The value-set of the operational data would be the combination of both th= e > config true and config false nodes. [Did you see this in my last > response? I received an offline message indicating that my previous > response was somewhat malformed, so you might=E2=80=99ve missed it...]. = The > config false nodes are obviously part of the operational data. For the > config true nodes, I=E2=80=99ve been swayed to believe that every config = true node > can also have an operational value. I didn=E2=80=99t think so at first, = using > =E2=80=98hostname=E2=80=99 as an example to make my point, but it was poi= nted out that the > admin might circumvent the YANG-driven config engine completely and set t= he > hostname via the UNIX command line instead. In this case, the intended > hostname value might differ from the operational hostname value. Even fo= r > nodes where we=E2=80=99re convinced there can never be an operational val= ue that > differs from the intended value, there still might be a propagation delay > that causes a difference to be perceived in time. All this points to a > rather conservative and thankfully simple solution that the value-set of > opstate is the combination of *all* the config true and config false node= s. > > But the foo-state node is being omitted from the module. How does the pyang plugin know how to produce the extra values so the auto-generated foo-state node has all the combined values? > > > What is an "opstate-aware tree". > > I should=E2=80=99ve written =E2=80=9Copstate-aware data model=E2=80=9D. > > To be clear, by =E2=80=9Copstate-aware tree=E2=80=9D, I meant the YANG mo= dule would only > have a top-level /foo tree that has both config true and config false > nodes, with the expectation that the solution provided by > draft-ietf-netmod-revised-datastores enables 1) opstate for both > system-generated objects as well as for config true nodes and 2) opstate > for all config true nodes also (note: this doesn=E2=80=99t remove the nee= d for > explicit config false nodes for negotiated values like MTU). > > Similarly, by =E2=80=9Copstate-unaware tree=E2=80=9D, I meant the YANG mo= dule would have > both top-level /foo and /foo-state trees. Essentially, what we have toda= y, > which we=E2=80=99re trying to get away from. > > > > The point of this work is that the opstate tree goes away and is > replaced by > > a protocol operation instead. > > Correct, the hope is that the top-level /foo-state tree no longer needs t= o > be defined in YANG modules. This is the goal as we believe it will make > YANG modules easier to read and write. > > > > In fact, there are no new datastores needed whatsoever to > > add the RPC , or even . > > I=E2=80=99m not sure what you mean by RPC . True, a > RPC could be defined now, but we=E2=80=99d still want t= he YANG > modules to be a certain way and we=E2=80=99d still want to define a conce= ptual > operational-state datastore so that we could describe it unambiguously. > > I could have an RPC that tested a config subtree. It would return 'true' if intended=3Dapplied for that subtree. I agree it is good to have clear definitions that are widely understood. It would be nice to have any clear definition of config=3Dfalse YANG nodes, whether datastores are used or not. (e.g., does operational state include counters?) > Kent // as a contributor > > > Andy --94eb2c07ecfaaef0ab0545c4ee9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable --94eb2c07ecfaaef0ab0545c4ee9d-- From nobody Tue Jan 10 15:54:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAB01293F4; Tue, 10 Jan 2017 15:54:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 8bE7Tkhgd-DT; Tue, 10 Jan 2017 15:54:17 -0800 (PST) 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 0B1AF126D74; Tue, 10 Jan 2017 15:54:17 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 61BF07BB; Wed, 11 Jan 2017 00:54:15 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id bbj6J_pEy5-N; Wed, 11 Jan 2017 00:54:13 +0100 (CET) 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, 11 Jan 2017 00:54:14 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E670C2008D; Wed, 11 Jan 2017 00:54:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SEMIlGAFQw9f; Wed, 11 Jan 2017 00:54:13 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF9D42008C; Wed, 11 Jan 2017 00:54:13 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C781A3E08EA2; Wed, 11 Jan 2017 00:54:14 +0100 (CET) Date: Wed, 11 Jan 2017 00:54:13 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170110235411.GA18000@elstar.local> Mail-Followup-To: Kent Watsen , Andy Bierman , Robert Wilton , Netconf , NetMod WG References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: NetMod WG , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Jan 2017 23:54:19 -0000 I believe that shortening tranistion pain is in the longer term better than prociding tools that at the end just extend the transition pain. /js On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote: > I think that there may be a better way here: The data modelers design the model on the assumption that an operational state datastore will be present. We can then use a pyang plugin to generate an extra YANG model that contains the missing state leaves that would be required for the split config/state trees. E.g. if it finds a config leaf in foo/speed it creates a module that contains foo-state/speed. I've been playing around with pyang and I don't think that this would be too hard to do. > > I generally support this approach as stop-gap solution while the industry goes thru the transition. However, I recommend a variant whereby the pyang plugin only migrates the config false values (not also the config true values). The reason for this is as follows: > > Migrating only the config false values is sufficient for matching existing functionality (read: a must-have requirement); that is, currently top-level /foo-state is used to support conveying the opstate for system-generated objects, that have lifetimes independent of config. > > Migrating the config true nodes also is possible, but only needed if wanting to report the opstate value for config true nodes (e.g., hostname), but this would be above and beyond what is possible today (read: a nice-to-have requirement), and hence I’d rather steer folks towards the new approach rather than double-down on the approach we’re trying to get away from. > > > > > This is a real hack. > > > > I liked the if-feature approach much better > > e.g. > > > > leaf oper-speed { > > if-feature "not operational-datastore"; > > ... > > } > > Is your proposal for the YANG modules to simultaneously define both opstate-aware and opstate-unaware trees? Wouldn’t that make the modules less readable, largely redundant, and ripe for inconsistencies? > > > > Kent // as a contributor > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Tue Jan 10 16:34:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 428171293D8 for ; Tue, 10 Jan 2017 16:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T6rdhTv_LxBl for ; Tue, 10 Jan 2017 16:34:46 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C825A129640 for ; Tue, 10 Jan 2017 16:34:45 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id 11so94568420qkl.3 for ; Tue, 10 Jan 2017 16:34:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=CrozdQJ+YmaOHloBJkEFVAI7qll7TY0f1EUVl35XT2w=; b=dEYqdP3KsyjNC44Hml8qY343JyZU7xOMIgr2+DksxsA21+kPh+3I7uDwBN6kyRbwBV WAcv55Rrdi9jszviDQ4gsweJMDMtr4WnvES002S/RuZIMFMhIZ/iDI+3G8DXsydH5Q0r Whaojra5UrlqJxUOJsGjQvGEPr4bxYm9qVc8kChv/h8TbjWNW/T2Bbl/HBU5YGHxXcer dly7xP+9y2zjmUef8+H4hSR3AFjo8MgN2b8bH4M0zINByDjGLzmNE76vPnmnH8EWN7AY 4B8yKK7EoIiKlEf5TE51gpjMZ1IzdMytm1LthcyNR9fjuN3T5QROPqUCBp6cJAZDU0Sx 4W6Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=CrozdQJ+YmaOHloBJkEFVAI7qll7TY0f1EUVl35XT2w=; b=EccmVUgDiVKieeVqvGGFoZoZf6uefNt5sm5MvjZUTQTYmr86ehrvLD4p/s7rDx02EG e9loJFCQjdxEzUWcQdEMh6A15pVXHJlMoFWjMsWDCybZvPifslTSPgglF6FNBOB0zm8X fUNWNjkE+mNDAe9HaEndNy11itzIvuMgbMAgVpKRnQGK79uBoLObhfY2xieq6tYm1A0P dG1Rm70XkVHDJEnmCzk18S8hvRRVfY5jagNJvYWJz0i9rV8gl1lnbAaIVTumMKpOt50Y KYDp3TTI744HOEM5ft1na4Mb0vz1qnhBhewIQJAQyF2x09EMGlOYOOODOSf65oCvNC8+ xiNw== X-Gm-Message-State: AIkVDXLmQFPvAmokmJIclpXBpZ+vi8tiFirJjHEhT4ibwCwAE6isZR2x6+mCugzmePYFzn7/NGHp62H861Xcbw== X-Received: by 10.55.166.77 with SMTP id p74mr5541736qke.314.1484094884881; Tue, 10 Jan 2017 16:34:44 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 16:34:43 -0800 (PST) In-Reply-To: <20170110235411.GA18000@elstar.local> References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 16:34:43 -0800 Message-ID: To: Juergen Schoenwaelder , Kent Watsen , Andy Bierman , Robert Wilton , Netconf , NetMod WG Content-Type: multipart/alternative; boundary=94eb2c06ed9a6d74e80545c6c4dc Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:34:50 -0000 --94eb2c06ed9a6d74e80545c6c4dc Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 3:54 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > I believe that shortening tranistion pain is in the longer term better > than prociding tools that at the end just extend the transition pain. > > That is a good goal, but ending up with a stable and useful solution is more important. The WG decided that an RPC-based solution was preferrred under the assumption that the data model design would not be impacted and existing YANG modules could report intended vs. actual values without any changes. I certainly agree with Kent that real systems can override config values in ways that were not anticipated at module design-time. All the more reason for an RPC-based solution. I am willing to accept the design team output as the architectural model. I liked Phil's approach -- identify all the state transitions and decide which ones need to be exposed in the standard. I don't see how tweaking this mode= l will have any impact on the transition pain of the solution path. Until the basic show-stoppers are solved, the redundant opstate objects are not important. Removing the foo-state objects means they are now invisible wrt/ YANG constraints (must, when, leafref, min/max, etc). IMO this is a show-shopper. YANG can only cross-reference YANG statements. Invisible opstate hiding behind a datastore label seems elegant wrt/ , but it looks like a disaster wrt/ YANG. /js > Andy > > On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote: > > I think that there may be a better way here: The data modelers design > the model on the assumption that an operational state datastore will be > present. We can then use a pyang plugin to generate an extra YANG model > that contains the missing state leaves that would be required for the spl= it > config/state trees. E.g. if it finds a config leaf in foo/speed it creat= es > a module that contains foo-state/speed. I've been playing around with > pyang and I don't think that this would be too hard to do. > > > > I generally support this approach as stop-gap solution while the > industry goes thru the transition. However, I recommend a variant whereb= y > the pyang plugin only migrates the config false values (not also the conf= ig > true values). The reason for this is as follows: > > > > Migrating only the config false values is sufficient for matching > existing functionality (read: a must-have requirement); that is, currentl= y > top-level /foo-state is used to support conveying the opstate for > system-generated objects, that have lifetimes independent of config. > > > > Migrating the config true nodes also is possible, but only needed if > wanting to report the opstate value for config true nodes (e.g., hostname= ), > but this would be above and beyond what is possible today (read: a > nice-to-have requirement), and hence I=E2=80=99d rather steer folks towar= ds the new > approach rather than double-down on the approach we=E2=80=99re trying to = get away > from. > > > > > > > > > This is a real hack. > > > > > > I liked the if-feature approach much better > > > e.g. > > > > > > leaf oper-speed { > > > if-feature "not operational-datastore"; > > > ... > > > } > > > > Is your proposal for the YANG modules to simultaneously define both > opstate-aware and opstate-unaware trees? Wouldn=E2=80=99t that make the = modules > less readable, largely redundant, and ripe for inconsistencies? > > > > > > > > Kent // as a contributor > > > > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c06ed9a6d74e80545c6c4dc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional modul= e
> that follows some simplistic pattern.

It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky=C2=A0 ;)


The client and server developers still= need to know about this auto-generated module
and implement it.= =C2=A0 Operators might have to know about it to use it.=C2=A0

> Of course this solution only works if the value-set of operational dat= a
> is exactly the same as the configurable value-set (which is sometimes<= br> > not the case at all).

The value-set of the operational data would be the combination of both the = config true and config false nodes.=C2=A0 =C2=A0[Did you see this in my las= t response? I received an offline message indicating that my previous respo= nse was somewhat malformed, so you might=E2=80=99ve missed it...].=C2=A0 = =C2=A0The config false nodes are obviously part of the operational data.=C2= =A0 For the config true nodes, I=E2=80=99ve been swayed to believe that eve= ry config true node can also have an operational value.=C2=A0 I didn=E2=80= =99t think so at first, using =E2=80=98hostname=E2=80=99 as an example to m= ake my point, but it was pointed out that the admin might circumvent the YA= NG-driven config engine completely and set the hostname via the UNIX comman= d line instead.=C2=A0 In this case, the intended hostname value might diffe= r from the operational hostname value.=C2=A0 Even for nodes where we=E2=80= =99re convinced there can never be an operational value that differs from t= he intended value, there still might be a propagation delay that causes a d= ifference to be perceived in time.=C2=A0 All this points to a rather conser= vative and thankfully simple solution that the value-set of opstate is the = combination of *all* the config true and config false nodes.



But the foo-state node = is being omitted from the module.
How does the pyang plugin know = how to produce the extra values so the
auto-generated foo-state n= ode has all the combined values?




> What is an "opstate-aware tree".

I should=E2=80=99ve written =E2=80=9Copstate-aware data model=E2=80=9D.

To be clear, by =E2=80=9Copstate-aware tree=E2=80=9D, I meant the YANG modu= le would only have a top-level /foo tree that has both config true and conf= ig false nodes, with the expectation that the solution provided by draft-ie= tf-netmod-revised-datastores enables 1) opstate for both system-genera= ted objects as well as for config true nodes and 2) opstate for all config = true nodes also (note: this doesn=E2=80=99t remove the need for explicit co= nfig false nodes for negotiated values like MTU).

Similarly, by =E2=80=9Copstate-unaware tree=E2=80=9D, I meant the YANG modu= le would have both top-level /foo and /foo-state trees.=C2=A0 Essentially, = what we have today, which we=E2=80=99re trying to get away from.


> The point of this work is that the opstate tree goes away and is repla= ced by
> a protocol operation instead.

Correct, the hope is that the top-level /foo-state tree no longer needs to = be defined in YANG modules.=C2=A0 This is the goal as we believe it will ma= ke YANG modules easier to read and write.


> In fact, there are no new datastores needed whatsoever to
> add the RPC <resource-ready>, or even <get-operational>.
I=E2=80=99m not sure what you mean by RPC <resource-ready>.=C2=A0 Tru= e, a <get-operational> RPC could be defined now, but we=E2=80=99d sti= ll want the YANG modules to be a certain way and we=E2=80=99d still want to= define a conceptual operational-state datastore so that we could describe = it unambiguously.



I could have an RPC tha= t tested a config subtree.
It would return 'true' if inte= nded=3Dapplied for that subtree.

=C2=A0
=
I agree it is good to have clear definitions that are widely= understood.
It would be nice to have any clear definition of con= fig=3Dfalse YANG nodes,
whether datastores are used or not. =C2= =A0(e.g., does operational state
include counters?)


Kent // as a contributor







On Tue, Jan 10, 2017 at 3:54 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
I believe that shortening tranistion pain is in the = longer term better
than prociding tools that at the end just extend the transition pain.



That is a good goal, bu= t ending up with a stable and useful solution
is more important.<= /div>

The WG decided that an RPC-based solution was pref= errred under the assumption
that the data model design would not = be impacted and existing YANG modules could
report intended vs. a= ctual values without any changes.

I certainly agre= e with Kent that real systems can override config values in ways
= that were not anticipated at module design-time. =C2=A0 All the more reason= for
an RPC-based solution.

I am willing= to accept the design team output as the architectural model.
I l= iked Phil's approach -- identify all the state transitions and decide w= hich
ones need to be exposed in the standard. I don't see how= tweaking this model
will have any impact on the transition pain = of the solution path.

Until the basic show-stopper= s are solved, the redundant opstate objects are not important.
Re= moving the foo-state objects means they are now invisible wrt/ YANG constra= ints
(must, when, leafref, min/max, etc).=C2=A0 IMO this is a sho= w-shopper.=C2=A0 YANG can only cross-reference
YANG statements.= =C2=A0 Invisible opstate hiding behind a datastore label seems elegant
wrt/ <get>, but it looks like a disaster wrt/ YANG.
<= br>

/js


Andy
=C2= =A0

On Tue, Jan 10, 2017 at 07:08:47PM +0000, Kent Watsen wrote:
> I think that there may be a better way here:=C2=A0 The data modelers d= esign the model on the assumption that an operational state datastore will = be present.=C2=A0 We can then use a pyang plugin to generate an extra YANG = model that contains the missing state leaves that would be required for the= split config/state trees.=C2=A0 E.g. if it finds a config leaf in foo/spee= d it creates a module that contains foo-state/speed.=C2=A0 I've been pl= aying around with pyang and I don't think that this would be too hard t= o do.
>
> I generally support this approach as stop-gap solution while the indus= try goes thru the transition.=C2=A0 However, I recommend a variant whereby = the pyang plugin only migrates the config false values (not also the config= true values).=C2=A0 The reason for this is as follows:
>
> Migrating only the config false values is sufficient for matching exis= ting functionality (read: a must-have requirement); that is, currently top-= level /foo-state is used to support conveying the opstate for system-genera= ted objects, that have lifetimes independent of config.
>
> Migrating the config true nodes also is possible, but only needed if w= anting to report the opstate value for config true nodes (e.g., hostname), = but this would be above and beyond what is possible today (read: a nice-to-= have requirement), and hence I=E2=80=99d rather steer folks towards the new= approach rather than double-down on the approach we=E2=80=99re trying to g= et away from.
>
>
>
> > This is a real hack.
> >
> > I liked the if-feature approach much better
> > e.g.
> >
> >=C2=A0 =C2=A0leaf oper-speed {
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0if-feature "not operational-datast= ore";
> >=C2=A0 =C2=A0 =C2=A0 =C2=A0...
> >=C2=A0 =C2=A0}
>
> Is your proposal for the YANG modules to simultaneously define both op= state-aware and opstate-unaware trees?=C2=A0 Wouldn=E2=80=99t that make the= modules less readable, largely redundant, and ripe for inconsistencies? >
>
>
> Kent=C2=A0 // as a contributor
>
>

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


--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c06ed9a6d74e80545c6c4dc-- From nobody Tue Jan 10 16:53:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DECCC12949B; Tue, 10 Jan 2017 16:53:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id if6PUgnyhQOr; Tue, 10 Jan 2017 16:53:35 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0092.outbound.protection.outlook.com [104.47.33.92]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE303129454; Tue, 10 Jan 2017 16:53:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=/BRfLNYnPaNYvRIhuiubFEO3Jch3/bqDwIhuM1/Mqro=; b=YGHMhf0eH1kvE2zCUQAP72KqO863uNriebXj6hb0KZRsL2qTLXEs7SuAatRO9tpE6u+55iOlDQ3S0CD2AX4fQUCxIO6dFTQMXJSfhZgDMo5OEbd1ZbKDN8m63/ONxdOxIj6QTNFRrLbSAhpyqMKc8b7x7mArXtASdvjSk7oucxE= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.3; Wed, 11 Jan 2017 00:53:33 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 00:53:32 +0000 From: Kent Watsen To: Andy Bierman , Juergen Schoenwaelder , Robert Wilton , Netconf , NetMod WG Thread-Topic: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSa5zb9rU+yryOKESiKoFr4nGJlaEybceA//+xcAA= Date: Wed, 11 Jan 2017 00:53:32 +0000 Message-ID: References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 4dc899f5-f5e7-45b3-81d2-08d439bc4455 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:sXDeIH1cH/LJw98HON8rQIghO341E678r0svg8gihuQqYRqYTOBy8KmK/ZP4yXYSwiiqnOcae7cioq9BDo/nVIw2Vi1zfbEClWauUZlV42TPRGvv76r3APKdz9MtumTQqSTuyoOyKjt3tph9wRMYQpD9rAhLnkzt9o+G/TxyUdhfwfhw66YbQQvn5WbSXk083Di+LuCflgNBaNZF5ndnHwcgaswAwIeU982IvUmamqFO9WbJ9kXKvmFxNGMoaXOGRg5UxEQx3okL7phpEfBBeCAqDSmPACqwy9uZKrVO62XIzTk4aPayYf0YreqccGwf4ZdrZ5KlfgfJ7qQOG9moNDOkVpKnA5tGek3iEDp/X3nvs+9YKnLl0G5l1JHbyV/U7WFVsQxgsieKg6okH+CedtdKx1PQMeFGqgFBjzyRYApoP/jga0+COSeoaPsDvDHKpmVZwzOGPAsFA6n3J0IXJA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39850400002)(39410400002)(199003)(189002)(4001350100001)(6506006)(77096006)(6486002)(122556002)(189998001)(2900100001)(99286003)(6306002)(54896002)(6512007)(83506001)(97736004)(3660700001)(82746002)(92566002)(2906002)(5001770100001)(25786008)(83716003)(86362001)(229853002)(6436002)(3280700002)(38730400001)(54356999)(50986999)(101416001)(7736002)(76176999)(2950100002)(105586002)(106356001)(106116001)(9326002)(81156014)(107886002)(102836003)(93886004)(8676002)(36756003)(66066001)(3846002)(33656002)(68736007)(6116002)(81166006)(8936002)(5660300001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 00:53:32.8531 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:53:37 -0000 --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KPiBVbnRpbCB0aGUgYmFzaWMgc2hvdy1zdG9wcGVycyBhcmUgc29sdmVkLCB0 aGUgcmVkdW5kYW50IG9wc3RhdGUgb2JqZWN0cyBhcmUgbm90IGltcG9ydGFudC4NCj4gUmVtb3Zp bmcgdGhlIGZvby1zdGF0ZSBvYmplY3RzIG1lYW5zIHRoZXkgYXJlIG5vdyBpbnZpc2libGUgd3J0 LyBZQU5HIGNvbnN0cmFpbnRzDQo+IChtdXN0LCB3aGVuLCBsZWFmcmVmLCBtaW4vbWF4LCBldGMp LiAgSU1PIHRoaXMgaXMgYSBzaG93LXNob3BwZXIuICBZQU5HIGNhbiBvbmx5IGNyb3NzLXJlZmVy ZW5jZQ0KPiBZQU5HIHN0YXRlbWVudHMuICBJbnZpc2libGUgb3BzdGF0ZSBoaWRpbmcgYmVoaW5k IGEgZGF0YXN0b3JlIGxhYmVsIHNlZW1zIGVsZWdhbnQNCj4gd3J0LyA8Z2V0PiwgYnV0IGl0IGxv b2tzIGxpa2UgYSBkaXNhc3RlciB3cnQvIFlBTkcuDQoNCk5vdGhpbmcgaGFzIGJlZW4gcmVtb3Zl ZC4gIEFsbCB0aGUgY29uZmlnIGZhbHNlIG5vZGVzIGFyZSBzdGlsbCBhdmFpbGFibGUsIGJ1dCBu b3cgdGhleeKAmXJlIG5vIGxvbmdlciBzZXBhcmF0ZWQgaW50byBhIHRvcC1sZXZlbCAvZm9vLXN0 YXRlIHRyZWUgZm9yIHRoZSBzb2xlIHB1cnBvc2Ugb2YgYmVpbmcgYWJsZSB0byByZXBvcnQgb3Bz dGF0ZSBmb3Igc3lzdGVtLWdlbmVyYXRlZCBvYmplY3RzLiAgTGlrZXdpc2UsIGFsbCBZQU5HIGNv bnN0cmFpbnRzIGNvbnRpbnVlIHRvIHdvcmssIGJ1dCByYXRoZXIgdGhhbiByZWZlcmVuY2Ugbm9k ZXMgaW4gL2Zvby1zdGF0ZSwgdGhleeKAmWxsIG5vdyByZWZlcmVuY2Ugbm9kZXMgaW4gL2Zvby4g ICBEb2VzIHRoaXMgbWFrZSBzZW5zZT8gIERvIHlvdSBzdGlsbCBoYXZlIGFuIGlzc3VlPw0KDQoN CktlbnQgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCg== --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy aTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFpbXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsN Cgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVy dGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhw b3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGlu ZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6 OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8 Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJw bGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5IaSBBbmR5LDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PiZndDsgVW50aWwgdGhlIGJhc2ljIHNob3ctc3RvcHBlcnMgYXJlIHNvbHZlZCwgdGhlIHJlZHVu ZGFudCBvcHN0YXRlIG9iamVjdHMgYXJlIG5vdCBpbXBvcnRhbnQuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFJlbW92aW5nIHRoZSBmb28t c3RhdGUgb2JqZWN0cyBtZWFucyB0aGV5IGFyZSBub3cgaW52aXNpYmxlIHdydC8gWUFORyBjb25z dHJhaW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Jmd0OyAobXVzdCwgd2hlbiwgbGVhZnJlZiwgbWluL21heCwgZXRjKS4mbmJzcDsgSU1PIHRo aXMgaXMgYSBzaG93LXNob3BwZXIuJm5ic3A7IFlBTkcgY2FuIG9ubHkgY3Jvc3MtcmVmZXJlbmNl PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7 IFlBTkcgc3RhdGVtZW50cy4mbmJzcDsgSW52aXNpYmxlIG9wc3RhdGUgaGlkaW5nIGJlaGluZCBh IGRhdGFzdG9yZSBsYWJlbCBzZWVtcyBlbGVnYW50PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IHdydC8gJmx0O2dldCZndDssIGJ1dCBpdCBs b29rcyBsaWtlIGEgZGlzYXN0ZXIgd3J0LyBZQU5HLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Tm90aGluZyBoYXMgYmVlbiByZW1vdmVkLiZu YnNwOyBBbGwgdGhlIGNvbmZpZyBmYWxzZSBub2RlcyBhcmUgc3RpbGwgYXZhaWxhYmxlLCBidXQg bm93IHRoZXnigJlyZSBubyBsb25nZXIgc2VwYXJhdGVkIGludG8gYSB0b3AtbGV2ZWwgL2Zvby1z dGF0ZSB0cmVlIGZvciB0aGUgc29sZSBwdXJwb3NlIG9mIGJlaW5nIGFibGUgdG8gcmVwb3J0IG9w c3RhdGUgZm9yIHN5c3RlbS1nZW5lcmF0ZWQgb2JqZWN0cy4mbmJzcDsgTGlrZXdpc2UsDQogYWxs IFlBTkcgY29uc3RyYWludHMgY29udGludWUgdG8gd29yaywgYnV0IHJhdGhlciB0aGFuIHJlZmVy ZW5jZSBub2RlcyBpbiAvZm9vLXN0YXRlLCB0aGV54oCZbGwgbm93IHJlZmVyZW5jZSBub2RlcyBp biAvZm9vLiZuYnNwOyZuYnNwOyBEb2VzIHRoaXMgbWFrZSBzZW5zZT8mbmJzcDsgRG8geW91IHN0 aWxsIGhhdmUgYW4gaXNzdWU/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCAvLyBhcyBhIGNvbnRyaWJ1dG9yPG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp dj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_E3A712FFE21741A3997A67117F5EB9FCjunipernet_-- From nobody Tue Jan 10 16:57:41 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F213129640 for ; Tue, 10 Jan 2017 16:57:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ut3uLNc0As6n for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F7D4129455 for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) Received: by mail-qk0-x236.google.com with SMTP id u25so577520488qki.2 for ; Tue, 10 Jan 2017 16:57:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ZDiWtuVO799VaJvU40YqGPPRGDZWFrnqvoORxwETquM=; b=mNfwF048K2Iwxx8Dm0QPWs/P9aTWJadbsEKG39bQ/Bgakgsyn4gbHsTZRm+/+0ua1B OOqHkb6Hdyhl3EiPjIPOrESFhid20Sy+CMsAs229Ponu5rqKfDpaPp7N0HYXEl6BR09d AXuyhEQHl005cFlrF8ppm8BlR3oDq9nabrW8eTeRr00hqdL7P179OwJnJ+6wF2DAsjPH VieYHBM1RNH2CS1K+nB1ej2A32aEegI2RUpHN6A1EoctC7Untg4TaG2WFjiqqFmb2ML6 ORKSDoSgBKGzH9kjiBn2ghmB9TdWnhAtRguWtDpxDLjyl56wqg11cGesx3xKxIP193Fh bBvw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=ZDiWtuVO799VaJvU40YqGPPRGDZWFrnqvoORxwETquM=; b=mfCQRm82S5gQgvdFjabhJavj6LTPY3lv8/XafQFz4vp3xtuwjpv+FfpRITPGx/wODl StbI23R1njZc6vVQK+KwFwZSAagFIkq7EoVyAz1xPjgyP7Vtg3OiXyFYeN/M9q/IExpo 69wpzqHSqlBhh430EWdOoetvU8AuAd3rQkqqyCFdN1gUglUvGPBmeZNLiJ9Murnh0Cyw utD5P4cEzC82Zid0Y1X0G31qHQuAWcKMLEL0ow/Y/osnbV5ZOV9TRnUu+r+So9cxEhUv CnuD2lJ3wqkDzjYRQJ8kc5cso4ZRm9KfWSnD0Lp7Uc46BVmNFXSRT0YGD9muuuvw0Wul snIQ== X-Gm-Message-State: AIkVDXKShFbMpadcp42Wa/jBf59skijthPuyixJ1GArfWkzq7auffVjxlB5Dz9vJwKd/Zr68NJ0NpaXfNRBz4w== X-Received: by 10.55.135.197 with SMTP id j188mr5658348qkd.71.1484096259327; Tue, 10 Jan 2017 16:57:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Tue, 10 Jan 2017 16:57:38 -0800 (PST) In-Reply-To: References: <20170109205109.GA15144@elstar.local> <20170110072103.GA16120@elstar.local> <20170110161643.GE17035@elstar.local> <8f0b1abe-b00e-95d1-f62f-7bc99d414bc6@cisco.com> <0f607346-cb4e-1e10-9956-956cb24dc49e@cisco.com> <0A89256A-35FA-4FC3-95FF-0C88A9B5F4EC@juniper.net> <20170110235411.GA18000@elstar.local> From: Andy Bierman Date: Tue, 10 Jan 2017 16:57:38 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c0777e659b8050545c716ba Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 00:57:41 -0000 --94eb2c0777e659b8050545c716ba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen wrote: > Hi Andy, > > > > > Until the basic show-stoppers are solved, the redundant opstate objects > are not important. > > > Removing the foo-state objects means they are now invisible wrt/ YANG > constraints > > > (must, when, leafref, min/max, etc). IMO this is a show-shopper. YANG > can only cross-reference > > > YANG statements. Invisible opstate hiding behind a datastore label > seems elegant > > > wrt/ , but it looks like a disaster wrt/ YANG. > > > > Nothing has been removed. All the config false nodes are still available= , > but now they=E2=80=99re no longer separated into a top-level /foo-state t= ree for > the sole purpose of being able to report opstate for system-generated > objects. Likewise, all YANG constraints continue to work, but rather tha= n > reference nodes in /foo-state, they=E2=80=99ll now reference nodes in /fo= o. Does > this make sense? Do you still have an issue? > > > > > This does not work. There are no config=3Dfalse nodes if they are overlaid onto the config=3Dtrue nodes. There is no way to say in the YANG XPath that you mean the configured value of /foo vs. the operational value of /foo. There is just 1 leaf that YANG says has 0 or 1 instance (and therefore 0 or 1 value). > Kent // as a contributor > > > > > Andy --94eb2c0777e659b8050545c716ba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen <kwatsen@juniper.net> wrote:

Hi Andy,<= u>

=C2=A0

> Until the basic show-stoppers are solved, the r= edundant opstate objects are not important.

> Removing the foo-state objects means they are n= ow invisible wrt/ YANG constraints

> (must, when, leafref, min/max, etc).=C2=A0 IMO = this is a show-shopper.=C2=A0 YANG can only cross-reference

> YANG statements.=C2=A0 Invisible opstate hiding= behind a datastore label seems elegant

> wrt/ <get>, but it looks like a disaster = wrt/ YANG.

=C2=A0

Nothing has been removed.=C2=A0 All the config false= nodes are still available, but now they=E2=80=99re no longer separated int= o a top-level /foo-state tree for the sole purpose of being able to report = opstate for system-generated objects.=C2=A0 Likewise, all YANG constraints continue to work, but rather than reference nodes in = /foo-state, they=E2=80=99ll now reference nodes in /foo.=C2=A0=C2=A0 Does t= his make sense?=C2=A0 Do you still have an issue?

=C2=A0

=C2=A0


This does not work. There are no config=3Dfalse nodes= if they are overlaid onto the config=3Dtrue nodes.
There is no w= ay to say in the YANG XPath that you mean the configured value of /foo
vs. the operational value of /foo.=C2=A0 There is just 1 leaf that YA= NG says has 0 or 1 instance
(and therefore 0 or 1 value).

=C2=A0

Kent // as a contributor

=C2=A0

=C2=A0


Andy
=C2=A0

--94eb2c0777e659b8050545c716ba-- From nobody Wed Jan 11 01:22:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 057E7129AC6; Wed, 11 Jan 2017 01:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 vWon6eHHxRTu; Wed, 11 Jan 2017 01:22:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 29774129ACB; Wed, 11 Jan 2017 01:22:11 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 65C031AE02BA; Wed, 11 Jan 2017 10:22:09 +0100 (CET) Date: Wed, 11 Jan 2017 10:22:09 +0100 (CET) Message-Id: <20170111.102209.310040071380723970.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:22:16 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIEphbiAx MCwgMjAxNyBhdCAxOjIwIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+DQo+ID4gPiBJIHRoaW5rIGl0IGlzIGJldHRlciB0byBoYXZlIGEgaHVtYW4g ZGVjaWRlIHdoYXQgaXMgaW4gdGhlIG1vZHVsZQ0KPiA+ID4gaW5zdGVhZCBvZiByZWx5aW5nIG9u IGEgcHlhbmcgcGx1Z2luIHRvIGdlbmVyYXRlIHNvbWUgYWRkaXRpb25hbCBtb2R1bGUNCj4gPiA+ IHRoYXQgZm9sbG93cyBzb21lIHNpbXBsaXN0aWMgcGF0dGVybi4NCj4gPg0KPiA+IEl0IG1heSBi ZSBzaW1wbGUsIGJ1dCBJ4oCZbSB0aGlua2luZyB0aGF04oCZcyBvbmx5IGJlY2F1c2UgaXTigJlz IG5vdCB0cmlja3kgIDspDQo+ID4NCj4gPg0KPiBUaGUgY2xpZW50IGFuZCBzZXJ2ZXIgZGV2ZWxv cGVycyBzdGlsbCBuZWVkIHRvIGtub3cgYWJvdXQgdGhpcw0KPiBhdXRvLWdlbmVyYXRlZCBtb2R1 bGUNCj4gYW5kIGltcGxlbWVudCBpdC4gIE9wZXJhdG9ycyBtaWdodCBoYXZlIHRvIGtub3cgYWJv dXQgaXQgdG8gdXNlIGl0Lg0KDQpFeGFjdGx5LiAgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSByZWFs IGhhY2suICBJbXBsZW1lbnRhdGlvbnMgY2FuIHVzZQ0Kd2hhdGV2ZXIgdHJhbnNmb3JtYXRpb24g dHJpY2tzIHRoZXkgd2FudCBpbiBvcmRlciB0byBjb21wbHkgd2l0aA0KZGlmZmVyZW50IHN0YW5k YXJkcywgYnV0IHRoZSBzdGFuZGFyZCBtb2R1bGVzIHNob3VsZCBiZSB2ZXJ5IGNsZWFyLg0KDQoN Ci9tYXJ0aW4NCg== From nobody Wed Jan 11 01:27:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 524D4129ACF; Wed, 11 Jan 2017 01:27:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 54B4hC5-4YHK; Wed, 11 Jan 2017 01:27:31 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 02AAE129ACE; Wed, 11 Jan 2017 01:27:30 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id D34AB1AE02BA; Wed, 11 Jan 2017 10:27:29 +0100 (CET) Date: Wed, 11 Jan 2017 10:27:29 +0100 (CET) Message-Id: <20170111.102729.1180268284224378559.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:27:32 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUdWUsIEphbiAx MCwgMjAxNyBhdCA0OjUzIFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4gd3Jv dGU6DQo+IA0KPiA+IEhpIEFuZHksDQo+ID4NCj4gPg0KPiA+DQo+ID4gPiBVbnRpbCB0aGUgYmFz aWMgc2hvdy1zdG9wcGVycyBhcmUgc29sdmVkLCB0aGUgcmVkdW5kYW50IG9wc3RhdGUgb2JqZWN0 cw0KPiA+IGFyZSBub3QgaW1wb3J0YW50Lg0KPiA+DQo+ID4gPiBSZW1vdmluZyB0aGUgZm9vLXN0 YXRlIG9iamVjdHMgbWVhbnMgdGhleSBhcmUgbm93IGludmlzaWJsZSB3cnQvIFlBTkcNCj4gPiBj b25zdHJhaW50cw0KPiA+DQo+ID4gPiAobXVzdCwgd2hlbiwgbGVhZnJlZiwgbWluL21heCwgZXRj KS4gIElNTyB0aGlzIGlzIGEgc2hvdy1zaG9wcGVyLiAgWUFORw0KPiA+IGNhbiBvbmx5IGNyb3Nz LXJlZmVyZW5jZQ0KPiA+DQo+ID4gPiBZQU5HIHN0YXRlbWVudHMuICBJbnZpc2libGUgb3BzdGF0 ZSBoaWRpbmcgYmVoaW5kIGEgZGF0YXN0b3JlIGxhYmVsDQo+ID4gc2VlbXMgZWxlZ2FudA0KPiA+ DQo+ID4gPiB3cnQvIDxnZXQ+LCBidXQgaXQgbG9va3MgbGlrZSBhIGRpc2FzdGVyIHdydC8gWUFO Ry4NCj4gPg0KPiA+DQo+ID4NCj4gPiBOb3RoaW5nIGhhcyBiZWVuIHJlbW92ZWQuICBBbGwgdGhl IGNvbmZpZyBmYWxzZSBub2RlcyBhcmUgc3RpbGwgYXZhaWxhYmxlLA0KPiA+IGJ1dCBub3cgdGhl eeKAmXJlIG5vIGxvbmdlciBzZXBhcmF0ZWQgaW50byBhIHRvcC1sZXZlbCAvZm9vLXN0YXRlIHRy ZWUgZm9yDQo+ID4gdGhlIHNvbGUgcHVycG9zZSBvZiBiZWluZyBhYmxlIHRvIHJlcG9ydCBvcHN0 YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkDQo+ID4gb2JqZWN0cy4gIExpa2V3aXNlLCBhbGwgWUFO RyBjb25zdHJhaW50cyBjb250aW51ZSB0byB3b3JrLCBidXQgcmF0aGVyIHRoYW4NCj4gPiByZWZl cmVuY2Ugbm9kZXMgaW4gL2Zvby1zdGF0ZSwgdGhleeKAmWxsIG5vdyByZWZlcmVuY2Ugbm9kZXMg aW4gL2Zvby4gICBEb2VzDQo+ID4gdGhpcyBtYWtlIHNlbnNlPyAgRG8geW91IHN0aWxsIGhhdmUg YW4gaXNzdWU/DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0KPiANCj4gVGhpcyBkb2VzIG5vdCB3 b3JrLiBUaGVyZSBhcmUgbm8gY29uZmlnPWZhbHNlIG5vZGVzIGlmIHRoZXkgYXJlIG92ZXJsYWlk DQo+IG9udG8gdGhlIGNvbmZpZz10cnVlIG5vZGVzLg0KPiBUaGVyZSBpcyBubyB3YXkgdG8gc2F5 IGluIHRoZSBZQU5HIFhQYXRoIHRoYXQgeW91IG1lYW4gdGhlIGNvbmZpZ3VyZWQgdmFsdWUNCj4g b2YgL2Zvbw0KPiB2cy4gdGhlIG9wZXJhdGlvbmFsIHZhbHVlIG9mIC9mb28uICBUaGVyZSBpcyBq dXN0IDEgbGVhZiB0aGF0IFlBTkcgc2F5cyBoYXMNCj4gMCBvciAxIGluc3RhbmNlDQo+IChhbmQg dGhlcmVmb3JlIDAgb3IgMSB2YWx1ZSkuDQoNClRoaXMgaXMgY29ycmVjdC4gIEJ1dCBub3RlIHRo YXQgWUFORyBkb2Vzbid0IGFsbG93IGNvbmZpZyB0cnVlIG5vZGVzDQp0byByZWZlciB0byBjb25m aWcgZmFsc2Ugbm9kZXMgYW55d2F5LCBzbyB0aGlzIGlzIGxlc3Mgb2YgYW4gaXNzdWUuDQpBbHNv IG5vdGUgdGhhdCBkcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMDAgcHJvcG9z ZXMgdGhhdA0Kc2VtYW50aWMgY29uc3RyYWludHMgZG9uJ3QgYXBwbHkgdG8gdGhlIG9wZXJhdGlv bmFsLXN0YXRlIGRhdGFzdG9yZQ0KKHNlZSBzZWN0aW9uIDUuMykuDQoNCkJUVywgaXQgaGFzIGJl ZW4gc3VnZ2VzdGVkIGJlZm9yZSB0byBhZGQgYSBmdW5jdGlvbiBzaW1pbGFyIHRvIHRoZQ0KWFNM VCAxLjAgZnVuY3Rpb24gImRvY3VtZW50IiwgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIHJlZmVyIHRv IG5vZGVzIGluDQpvdGhlciBkb2N1bWVudHMgKG9yIHJhdGhlciBvdGhlciBkYXRhc3RvcmVzIGlu IG91ciBjYXNlKS4NCg0KDQovbWFydGluDQo= From nobody Wed Jan 11 01:36:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C084129AD9; Wed, 11 Jan 2017 01:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 IdatYyczuZ2t; Wed, 11 Jan 2017 01:36:15 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D6AAA129AD5; Wed, 11 Jan 2017 01:36:14 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 17E2B1AE02BA; Wed, 11 Jan 2017 10:36:14 +0100 (CET) Date: Wed, 11 Jan 2017 10:36:13 +0100 (CET) Message-Id: <20170111.103613.452189352000719595.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> References: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 09:36:16 -0000 Ladislav Lhotka wrote: > > > On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > > wrote: > > > > On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >> > >> I think we need protocol and YANG specs that are not tied to any > >> particular model and that are thus capable of matching unforeseen > >> real-world implementations. This is no sci-fi, HTTP and XML schema > >> languages work this way. > >> > > > > I disagree that HTTP and XML schema languages do the same thing. Our > > goal is interoperable configuration of network devices; the notion of > > Even now, a client that's programmed to write straight to running > isn't interoperable with a server that has candidate and read-only > running. A RESTCONF server that supports only JSON isn't interoperable > with a client that supports only XML. > > We are not in a situation that every pair of a randomly chosen server > and client need to be interoperable. It's IMO perfectly fine if IoT > and ISP networks use different clients. Yet, both can still use the > same RESTCONF, same YANG, and even same YANG modules. The fact is that that data models are written with a certain set of protocol features and datastores in mind (the "meta-model"). Some examples: If we had an "operational-state" datastore like the one proposed, we would not see the /foo vs /foo-state split. If SNMP would have had a CREATE operation, MIBs would not have used RowStatus. If NETCONF didn't have a way to create instances, we would have seen something similar in YANG models. If NETCONF had a way to add comments to any node in a datastore, we wouldn't have "leaf description" sprinkled throughout the models. If NETCONF didn't have a generic way to filter retreived data, we'd see lots of specific get-* rpcs in YANG models. /martin From nobody Wed Jan 11 03:05:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE8AF129B8B; Wed, 11 Jan 2017 03:05:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P76Gen44L5wr; Wed, 11 Jan 2017 03:05:00 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A51EA129B99; Wed, 11 Jan 2017 03:05:00 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e] (unknown [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e]) by mail.nic.cz (Postfix) with ESMTPSA id 42BF660FDA; Wed, 11 Jan 2017 12:04:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484132698; bh=Qa9+RKxakDRa43Y7JIpL4H2V6l169PnKmeL2dPgObwU=; h=From:Date:To; b=lhC6robjq2IEnkLf8kb41wVFlvjNPrbDaYs96B7+dD4Sj9PsW31oEjhkvzUNcPnJa xtf8FkpVx9lmgDX1f1fONQ+0zx3lkWtf2gC/03Sk8Lz1A/3dHU4Qo2P6Dibo1fXID8 vqG6tsBPjwc2kaN7c1shdKCMLnxxfeCmMSkigFiA= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.103613.452189352000719595.mbj@tail-f.com> Date: Wed, 11 Jan 2017 12:05:00 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <3DFB70DC-010A-4CD0-BBBB-1478AC814923@nic.cz> <20170110083942.GC16255@elstar.local> <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:05:08 -0000 > On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>=20 >>>> I think we need protocol and YANG specs that are not tied to any >>>> particular model and that are thus capable of matching unforeseen >>>> real-world implementations. This is no sci-fi, HTTP and XML schema >>>> languages work this way. >>>>=20 >>>=20 >>> I disagree that HTTP and XML schema languages do the same thing. Our >>> goal is interoperable configuration of network devices; the notion = of >>=20 >> Even now, a client that's programmed to write straight to running >> isn't interoperable with a server that has candidate and read-only >> running. A RESTCONF server that supports only JSON isn't = interoperable >> with a client that supports only XML. >>=20 >> We are not in a situation that every pair of a randomly chosen server >> and client need to be interoperable. It's IMO perfectly fine if IoT >> and ISP networks use different clients. Yet, both can still use the >> same RESTCONF, same YANG, and even same YANG modules. >=20 > The fact is that that data models are written with a certain set of > protocol features and datastores in mind (the "meta-model"). Some > examples: >=20 > If we had an "operational-state" datastore like the one proposed, we > would not see the /foo vs /foo-state split. Yes, but I assume this will go away anyway. However, we can still have = YANG modules (and complete schemas) designed for the operational = datastore. The important property of the "meta-model" so far has been = that config and state data are separate, and this is not going to = change. >=20 > If SNMP would have had a CREATE operation, MIBs would not have used > RowStatus. If NETCONF didn't have a way to create instances, we would > have seen something similar in YANG models. >=20 > If NETCONF had a way to add comments to any node in a datastore, we > wouldn't have "leaf description" sprinkled throughout the models. >=20 > If NETCONF didn't have a generic way to filter retreived data, we'd > see lots of specific get-* rpcs in YANG models. Maybe, but are the last three points relevant to this discussion? Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 03:16:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22CFD129D83; Wed, 11 Jan 2017 03:16:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 2gomculRQaqA; Wed, 11 Jan 2017 03:16:17 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A2893129B81; Wed, 11 Jan 2017 03:16:17 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 14A491AE02BA; Wed, 11 Jan 2017 12:16:16 +0100 (CET) Date: Wed, 11 Jan 2017 12:16:15 +0100 (CET) Message-Id: <20170111.121615.1087515400647852978.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:16:19 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>> wrote: > >>> > >>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>> > >>>> I think we need protocol and YANG specs that are not tied to any > >>>> particular model and that are thus capable of matching unforeseen > >>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>> languages work this way. > >>>> > >>> > >>> I disagree that HTTP and XML schema languages do the same thing. Our > >>> goal is interoperable configuration of network devices; the notion of > >> > >> Even now, a client that's programmed to write straight to running > >> isn't interoperable with a server that has candidate and read-only > >> running. A RESTCONF server that supports only JSON isn't interoperable > >> with a client that supports only XML. > >> > >> We are not in a situation that every pair of a randomly chosen server > >> and client need to be interoperable. It's IMO perfectly fine if IoT > >> and ISP networks use different clients. Yet, both can still use the > >> same RESTCONF, same YANG, and even same YANG modules. > > > > The fact is that that data models are written with a certain set of > > protocol features and datastores in mind (the "meta-model"). Some > > examples: > > > > If we had an "operational-state" datastore like the one proposed, we > > would not see the /foo vs /foo-state split. > > Yes, but I assume this will go away anyway. However, we can still have > YANG modules (and complete schemas) designed for the operational > datastore. The important property of the "meta-model" so far has been > that config and state data are separate, and this is not going to > change. > > > > > If SNMP would have had a CREATE operation, MIBs would not have used > > RowStatus. If NETCONF didn't have a way to create instances, we would > > have seen something similar in YANG models. > > > > If NETCONF had a way to add comments to any node in a datastore, we > > wouldn't have "leaf description" sprinkled throughout the models. > > > > If NETCONF didn't have a generic way to filter retreived data, we'd > > see lots of specific get-* rpcs in YANG models. > > Maybe, but are the last three points relevant to this discussion? The point is that data models are designed with some meta-model in mind. The meta-model includes (some) datastores. You wrote: I believe both the protocols and YANG can work with any set of datastores [...] And I don't think that this is true (practically). For example, a YANG module that is designed with the new operational state datastore in mind will be of limited use in a legacy NETCONF server. /martin From nobody Wed Jan 11 03:43:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BEB129DF4; Wed, 11 Jan 2017 03:43:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I4Hdnjkl78Nn; Wed, 11 Jan 2017 03:43:43 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99FA5129DF2; Wed, 11 Jan 2017 03:43:41 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e] (unknown [IPv6:2a01:5e0:29:fffe:2914:3b97:4da6:fc1e]) by mail.nic.cz (Postfix) with ESMTPSA id E0A9060ACD; Wed, 11 Jan 2017 12:43:38 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484135019; bh=KSaqK619JkpNV3lab24bR/PU/aSiOh584iVwXl2VCVw=; h=From:Date:To; b=rIuLf3a+MKASi+cStceNDu9Hjs6QvjHbF1hQdkuDCtYJryNnugQ4PPxOeIrW6YDeu /OGK1GpZV3hB0D5rKe9HKE1W7hSyIoSTtMIg/+rhVt56KK7ZosdxEOIIncq99puLXz 4G9oWtFqswsXrW3kwZe2zjA6AwhLcerWoO905pCE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.121615.1087515400647852978.mbj@tail-f.com> Date: Wed, 11 Jan 2017 12:43:40 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> References: <2D981A38-CBE9-4F2D-A7A8-A366DE3A95CB@nic.cz> <20170111.103613.452189352000719595.mbj@tail-f.com> <20170111.121615.1087515400647852978.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 11:43:45 -0000 > On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>> wrote: >>>>>=20 >>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>>>=20 >>>>>> I think we need protocol and YANG specs that are not tied to any >>>>>> particular model and that are thus capable of matching unforeseen >>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>> languages work this way. >>>>>>=20 >>>>>=20 >>>>> I disagree that HTTP and XML schema languages do the same thing. = Our >>>>> goal is interoperable configuration of network devices; the notion = of >>>>=20 >>>> Even now, a client that's programmed to write straight to running >>>> isn't interoperable with a server that has candidate and read-only >>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>> with a client that supports only XML. >>>>=20 >>>> We are not in a situation that every pair of a randomly chosen = server >>>> and client need to be interoperable. It's IMO perfectly fine if IoT >>>> and ISP networks use different clients. Yet, both can still use the >>>> same RESTCONF, same YANG, and even same YANG modules. >>>=20 >>> The fact is that that data models are written with a certain set of >>> protocol features and datastores in mind (the "meta-model"). Some >>> examples: >>>=20 >>> If we had an "operational-state" datastore like the one proposed, we >>> would not see the /foo vs /foo-state split. >>=20 >> Yes, but I assume this will go away anyway. However, we can still = have >> YANG modules (and complete schemas) designed for the operational >> datastore. The important property of the "meta-model" so far has been >> that config and state data are separate, and this is not going to >> change. >>=20 >>>=20 >>> If SNMP would have had a CREATE operation, MIBs would not have used >>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>> have seen something similar in YANG models. >>>=20 >>> If NETCONF had a way to add comments to any node in a datastore, we >>> wouldn't have "leaf description" sprinkled throughout the models. >>>=20 >>> If NETCONF didn't have a generic way to filter retreived data, we'd >>> see lots of specific get-* rpcs in YANG models. >>=20 >> Maybe, but are the last three points relevant to this discussion? >=20 > The point is that data models are designed with some meta-model in > mind. The meta-model includes (some) datastores. You wrote: But where and how is this reflected in existing YANG modules (except for = the foo and foo-state split, which is IMO a minor issue)? >=20 > I believe both the protocols and YANG can work with any set of > datastores [...] >=20 > And I don't think that this is true (practically). For example, a > YANG module that is designed with the new operational state datastore > in mind will be of limited use in a legacy NETCONF server. Please explain. My idea what could be done e.g. with ietf-interfaces is = this: 1. Split it into two modules, say ietf-interfaces-config and = ietf-interfaces-state. The former would contain exactly what's now = inside "interfaces", and the latter will augment it with extra state = data that are now under "interfaces-state". 2. The data model for configuration datastores will be defined to = contain only ietf-interfaces-config whereas for operational-state = datastore it will be ietf-interfaces-config *and* ietf-interfaces-state. Am I completely misguided here? If not, then I don't see where the new = modules refer to any particular datastore model. Yes, they do reflect = that there is configuration and state data, but we don't want to get rid = of this distinction, right? Lada >=20 >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 04:28:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BC18129E4D; Wed, 11 Jan 2017 04:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 QJUe3U81edEv; Wed, 11 Jan 2017 04:28:06 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 7E70D129BE8; Wed, 11 Jan 2017 04:28:00 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id BD7BD1AE02BA; Wed, 11 Jan 2017 13:27:59 +0100 (CET) Date: Wed, 11 Jan 2017 13:27:59 +0100 (CET) Message-Id: <20170111.132759.746322711124349871.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> References: <20170111.121615.1087515400647852978.mbj@tail-f.com> <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:28:08 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>> wrote: > >>>>> > >>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>> > >>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>> particular model and that are thus capable of matching unforeseen > >>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>> languages work this way. > >>>>>> > >>>>> > >>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>> goal is interoperable configuration of network devices; the notion of > >>>> > >>>> Even now, a client that's programmed to write straight to running > >>>> isn't interoperable with a server that has candidate and read-only > >>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>> with a client that supports only XML. > >>>> > >>>> We are not in a situation that every pair of a randomly chosen server > >>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>> and ISP networks use different clients. Yet, both can still use the > >>>> same RESTCONF, same YANG, and even same YANG modules. > >>> > >>> The fact is that that data models are written with a certain set of > >>> protocol features and datastores in mind (the "meta-model"). Some > >>> examples: > >>> > >>> If we had an "operational-state" datastore like the one proposed, we > >>> would not see the /foo vs /foo-state split. > >> > >> Yes, but I assume this will go away anyway. However, we can still have > >> YANG modules (and complete schemas) designed for the operational > >> datastore. The important property of the "meta-model" so far has been > >> that config and state data are separate, and this is not going to > >> change. > >> > >>> > >>> If SNMP would have had a CREATE operation, MIBs would not have used > >>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>> have seen something similar in YANG models. > >>> > >>> If NETCONF had a way to add comments to any node in a datastore, we > >>> wouldn't have "leaf description" sprinkled throughout the models. > >>> > >>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>> see lots of specific get-* rpcs in YANG models. > >> > >> Maybe, but are the last three points relevant to this discussion? > > > > The point is that data models are designed with some meta-model in > > mind. The meta-model includes (some) datastores. You wrote: > > But where and how is this reflected in existing YANG modules (except > for the foo and foo-state split, which is IMO a minor issue)? I don't this split is a minor issue. For the openconfig group, this is one of the major problems with YANG, leading to their design with duplicate leafs. The reason for adding the operational state datastore in the form we propose in the draft it to be able to get rid of this split. > > I believe both the protocols and YANG can work with any set of > > datastores [...] > > > > And I don't think that this is true (practically). For example, a > > YANG module that is designed with the new operational state datastore > > in mind will be of limited use in a legacy NETCONF server. > > Please explain. If a YANG module is designed with this new architecture in mind, it will have a single top-level tree, which can support pre-configuration and different instances in the config and operational state. If such a module is implemented in a legacy NETCONF server, the only way to get the operational state is to used . But will return the union between running and operational state. The client can't tell if an instance is really present in the operational state, or just in the config. My idea what could be done e.g. with ietf-interfaces > is this: > > 1. Split it into two modules, say ietf-interfaces-config and > ietf-interfaces-state. The former would contain exactly what's now > inside "interfaces", and the latter will augment it with extra state > data that are now under "interfaces-state". > > 2. The data model for configuration datastores will be defined to > contain only ietf-interfaces-config whereas for operational-state > datastore it will be ietf-interfaces-config *and* > ietf-interfaces-state. If we do this for all modules then we haven't gained anything; we still have duplicate definitions. /martin > Am I completely misguided here? If not, then I don't see where the new > modules refer to any particular datastore model. Yes, they do reflect > that there is configuration and state data, but we don't want to get > rid of this distinction, right? > > Lada > > > > > > > > > /martin > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Jan 11 04:45:34 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D71A1129E71; Wed, 11 Jan 2017 04:45:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BdlrATxI70rK; Wed, 11 Jan 2017 04:45:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0A64127077; Wed, 11 Jan 2017 04:45:28 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 406F360ABE; Wed, 11 Jan 2017 13:45:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484138727; bh=p9M3pCPC6UgV7XcEt9C+MPRAiODCj9NFb0GMTTLBq/8=; h=From:Date:To; b=bn2iemxWOmrRs3TQ8L6et0ZWfrW7JF8CuMq8+plrcEihd+wG3HR+w5l+c/gO0b1r5 B8LwHeO66+3BzHcMFFWxQOQgFowvaBURVGt27uIMvYxRNDeoXBkm2ElhaxAw8zBy6p e7pPK5uNXNIX/GuLf12fRiBu/x2HTploEQ6OBZZk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.132759.746322711124349871.mbj@tail-f.com> Date: Wed, 11 Jan 2017 13:45:29 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> References: <20170111.121615.1087515400647852978.mbj@tail-f.com> <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:45:31 -0000 > On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>> wrote: >>>>>>>=20 >>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>> languages work this way. >>>>>>>>=20 >>>>>>>=20 >>>>>>> I disagree that HTTP and XML schema languages do the same thing. = Our >>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>=20 >>>>>> Even now, a client that's programmed to write straight to running >>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>> with a client that supports only XML. >>>>>>=20 >>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>> and client need to be interoperable. It's IMO perfectly fine if = IoT >>>>>> and ISP networks use different clients. Yet, both can still use = the >>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>=20 >>>>> The fact is that that data models are written with a certain set = of >>>>> protocol features and datastores in mind (the "meta-model"). Some >>>>> examples: >>>>>=20 >>>>> If we had an "operational-state" datastore like the one proposed, = we >>>>> would not see the /foo vs /foo-state split. >>>>=20 >>>> Yes, but I assume this will go away anyway. However, we can still = have >>>> YANG modules (and complete schemas) designed for the operational >>>> datastore. The important property of the "meta-model" so far has = been >>>> that config and state data are separate, and this is not going to >>>> change. >>>>=20 >>>>>=20 >>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>>>> have seen something similar in YANG models. >>>>>=20 >>>>> If NETCONF had a way to add comments to any node in a datastore, = we >>>>> wouldn't have "leaf description" sprinkled throughout the models. >>>>>=20 >>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>> see lots of specific get-* rpcs in YANG models. >>>>=20 >>>> Maybe, but are the last three points relevant to this discussion? >>>=20 >>> The point is that data models are designed with some meta-model in >>> mind. The meta-model includes (some) datastores. You wrote: >>=20 >> But where and how is this reflected in existing YANG modules (except >> for the foo and foo-state split, which is IMO a minor issue)? >=20 > I don't this split is a minor issue. For the openconfig group, this > is one of the major problems with YANG, leading to their design with > duplicate leafs. The reason for adding the operational state > datastore in the form we propose in the draft it to be able to get rid > of this split. >=20 >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>>=20 >>> And I don't think that this is true (practically). For example, a >>> YANG module that is designed with the new operational state = datastore >>> in mind will be of limited use in a legacy NETCONF server. >>=20 >> Please explain. >=20 > If a YANG module is designed with this new architecture in mind, it > will have a single top-level tree, which can support pre-configuration > and different instances in the config and operational state. >=20 > If such a module is implemented in a legacy NETCONF server, the only > way to get the operational state is to used . But will > return the union between running and operational state. The client > can't tell if an instance is really present in the operational state, > or just in the config. >=20 >=20 > My idea what could be done e.g. with ietf-interfaces >> is this: >>=20 >> 1. Split it into two modules, say ietf-interfaces-config and >> ietf-interfaces-state. The former would contain exactly what's now >> inside "interfaces", and the latter will augment it with extra state >> data that are now under "interfaces-state". >>=20 >> 2. The data model for configuration datastores will be defined to >> contain only ietf-interfaces-config whereas for operational-state >> datastore it will be ietf-interfaces-config *and* >> ietf-interfaces-state. >=20 > If we do this for all modules then we haven't gained anything; we > still have duplicate definitions. Show me a single YANG data node definition that's duplicate in my = concept above. But then maybe I didn't explain it properly. Note also that you slightly misinterpreted my statement that you cited: I believe both the protocols and YANG can work with any set of datastores [...] I didn't say that there cannot be *modules* that are somehow designed = for a particular datastore model - I meant YANG the language.=20 Lada >=20 >=20 > /martin >=20 >=20 >> Am I completely misguided here? If not, then I don't see where the = new >> modules refer to any particular datastore model. Yes, they do reflect >> that there is configuration and state data, but we don't want to get >> rid of this distinction, right? >>=20 >> Lada >>=20 >>>=20 >>>=20 >>>=20 >>> /martin >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 04:54:06 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2BAE6129BE7; Wed, 11 Jan 2017 04:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 ndebAYZecZ5P; Wed, 11 Jan 2017 04:54:00 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 56145129BDC; Wed, 11 Jan 2017 04:54:00 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 285491AE02BA; Wed, 11 Jan 2017 13:53:59 +0100 (CET) Date: Wed, 11 Jan 2017 13:53:59 +0100 (CET) Message-Id: <20170111.135359.1145355019648401300.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 12:54:02 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>>>> wrote: > >>>>>>> > >>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>>>> > >>>>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>>>> particular model and that are thus capable of matching unforeseen > >>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>>>> languages work this way. > >>>>>>>> > >>>>>>> > >>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>>>> goal is interoperable configuration of network devices; the notion of > >>>>>> > >>>>>> Even now, a client that's programmed to write straight to running > >>>>>> isn't interoperable with a server that has candidate and read-only > >>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>>>> with a client that supports only XML. > >>>>>> > >>>>>> We are not in a situation that every pair of a randomly chosen server > >>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>>>> and ISP networks use different clients. Yet, both can still use the > >>>>>> same RESTCONF, same YANG, and even same YANG modules. > >>>>> > >>>>> The fact is that that data models are written with a certain set of > >>>>> protocol features and datastores in mind (the "meta-model"). Some > >>>>> examples: > >>>>> > >>>>> If we had an "operational-state" datastore like the one proposed, we > >>>>> would not see the /foo vs /foo-state split. > >>>> > >>>> Yes, but I assume this will go away anyway. However, we can still have > >>>> YANG modules (and complete schemas) designed for the operational > >>>> datastore. The important property of the "meta-model" so far has been > >>>> that config and state data are separate, and this is not going to > >>>> change. > >>>> > >>>>> > >>>>> If SNMP would have had a CREATE operation, MIBs would not have used > >>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>>>> have seen something similar in YANG models. > >>>>> > >>>>> If NETCONF had a way to add comments to any node in a datastore, we > >>>>> wouldn't have "leaf description" sprinkled throughout the models. > >>>>> > >>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>>>> see lots of specific get-* rpcs in YANG models. > >>>> > >>>> Maybe, but are the last three points relevant to this discussion? > >>> > >>> The point is that data models are designed with some meta-model in > >>> mind. The meta-model includes (some) datastores. You wrote: > >> > >> But where and how is this reflected in existing YANG modules (except > >> for the foo and foo-state split, which is IMO a minor issue)? > > > > I don't this split is a minor issue. For the openconfig group, this > > is one of the major problems with YANG, leading to their design with > > duplicate leafs. The reason for adding the operational state > > datastore in the form we propose in the draft it to be able to get rid > > of this split. > > > >>> I believe both the protocols and YANG can work with any set of > >>> datastores [...] > >>> > >>> And I don't think that this is true (practically). For example, a > >>> YANG module that is designed with the new operational state datastore > >>> in mind will be of limited use in a legacy NETCONF server. > >> > >> Please explain. > > > > If a YANG module is designed with this new architecture in mind, it > > will have a single top-level tree, which can support pre-configuration > > and different instances in the config and operational state. > > > > If such a module is implemented in a legacy NETCONF server, the only > > way to get the operational state is to used . But will > > return the union between running and operational state. The client > > can't tell if an instance is really present in the operational state, > > or just in the config. > > > > > > My idea what could be done e.g. with ietf-interfaces > >> is this: > >> > >> 1. Split it into two modules, say ietf-interfaces-config and > >> ietf-interfaces-state. The former would contain exactly what's now > >> inside "interfaces", and the latter will augment it with extra state > >> data that are now under "interfaces-state". > >> > >> 2. The data model for configuration datastores will be defined to > >> contain only ietf-interfaces-config whereas for operational-state > >> datastore it will be ietf-interfaces-config *and* > >> ietf-interfaces-state. > > > > If we do this for all modules then we haven't gained anything; we > > still have duplicate definitions. > > Show me a single YANG data node definition that's duplicate in my > concept above. But then maybe I didn't explain it properly. The interface's "type" leaf. With the new operational-state datastore, /interfaces/interface/type in operational-state and /interfaces-state/interface/type are duplicate. > Note also that you slightly misinterpreted my statement that you > cited: > > I believe both the protocols and YANG can work with any set of > datastores [...] > > I didn't say that there cannot be *modules* that are somehow designed > for a particular datastore model - I meant YANG the language. Ok. Yes, you're right, but then we'd probably need some new statement in each module that tells which meta-model the YANG module is written for. /martin > > Lada > > > > > > > /martin > > > > > >> Am I completely misguided here? If not, then I don't see where the new > >> modules refer to any particular datastore model. Yes, they do reflect > >> that there is configuration and state data, but we don't want to get > >> rid of this distinction, right? > >> > >> Lada > >> > >>> > >>> > >>> > >>> /martin > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: 0xB8F92B08A9F76C67 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > From nobody Wed Jan 11 05:05:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE4EA12007C; Wed, 11 Jan 2017 05:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3c5gFiyl-uKz; Wed, 11 Jan 2017 05:05:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2736129BEB; Wed, 11 Jan 2017 05:05:14 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 0E69E6114F; Wed, 11 Jan 2017 14:05:12 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484139912; bh=/MOse1kvZdMHX0VM7wUkV8Qw5PMdPkS+w8oVE9sYMqg=; h=From:Date:To; b=Hq6SKDBu7/voOgxcPpmJ3kTkh01I03EV2AO3vSxqSgt7+HcYBDO2GZOKA/s2kH04X nscY46G0Wyb2KDvDw29Hr8cnCSak9GUZL7agN5y76tTmVeRKIbvGo1KjNeuq16ToUX +9lsH3CgDatxgSkSLHwEMNJzLeXGs3E9BrOKUdvk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.135359.1145355019648401300.mbj@tail-f.com> Date: Wed, 11 Jan 2017 14:05:13 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 13:05:18 -0000 > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>> wrote: >>>>>>>>>=20 >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>=20 >>>>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>> languages work this way. >>>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>=20 >>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>> with a client that supports only XML. >>>>>>>>=20 >>>>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if = IoT >>>>>>>> and ISP networks use different clients. Yet, both can still use = the >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>=20 >>>>>>> The fact is that that data models are written with a certain set = of >>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>> examples: >>>>>>>=20 >>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>> would not see the /foo vs /foo-state split. >>>>>>=20 >>>>>> Yes, but I assume this will go away anyway. However, we can still = have >>>>>> YANG modules (and complete schemas) designed for the operational >>>>>> datastore. The important property of the "meta-model" so far has = been >>>>>> that config and state data are separate, and this is not going to >>>>>> change. >>>>>>=20 >>>>>>>=20 >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we = would >>>>>>> have seen something similar in YANG models. >>>>>>>=20 >>>>>>> If NETCONF had a way to add comments to any node in a datastore, = we >>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>=20 >>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>=20 >>>>>> Maybe, but are the last three points relevant to this discussion? >>>>>=20 >>>>> The point is that data models are designed with some meta-model in >>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>=20 >>>> But where and how is this reflected in existing YANG modules = (except >>>> for the foo and foo-state split, which is IMO a minor issue)? >>>=20 >>> I don't this split is a minor issue. For the openconfig group, this >>> is one of the major problems with YANG, leading to their design with >>> duplicate leafs. The reason for adding the operational state >>> datastore in the form we propose in the draft it to be able to get = rid >>> of this split. >>>=20 >>>>> I believe both the protocols and YANG can work with any set of >>>>> datastores [...] >>>>>=20 >>>>> And I don't think that this is true (practically). For example, a >>>>> YANG module that is designed with the new operational state = datastore >>>>> in mind will be of limited use in a legacy NETCONF server. >>>>=20 >>>> Please explain. >>>=20 >>> If a YANG module is designed with this new architecture in mind, it >>> will have a single top-level tree, which can support = pre-configuration >>> and different instances in the config and operational state. >>>=20 >>> If such a module is implemented in a legacy NETCONF server, the only >>> way to get the operational state is to used . But will >>> return the union between running and operational state. The client >>> can't tell if an instance is really present in the operational = state, >>> or just in the config. >>>=20 >>>=20 >>> My idea what could be done e.g. with ietf-interfaces >>>> is this: >>>>=20 >>>> 1. Split it into two modules, say ietf-interfaces-config and >>>> ietf-interfaces-state. The former would contain exactly what's now >>>> inside "interfaces", and the latter will augment it with extra = state >>>> data that are now under "interfaces-state". >>>>=20 >>>> 2. The data model for configuration datastores will be defined to >>>> contain only ietf-interfaces-config whereas for operational-state >>>> datastore it will be ietf-interfaces-config *and* >>>> ietf-interfaces-state. >>>=20 >>> If we do this for all modules then we haven't gained anything; we >>> still have duplicate definitions. >>=20 >> Show me a single YANG data node definition that's duplicate in my >> concept above. But then maybe I didn't explain it properly. >=20 > The interface's "type" leaf. With the new operational-state > datastore, /interfaces/interface/type in operational-state and > /interfaces-state/interface/type are duplicate. As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >=20 >> Note also that you slightly misinterpreted my statement that you >> cited: >>=20 >> I believe both the protocols and YANG can work with any set of >> datastores [...] >>=20 >> I didn't say that there cannot be *modules* that are somehow designed >> for a particular datastore model - I meant YANG the language. >=20 > Ok. Yes, you're right, but then we'd probably need some new statement > in each module that tells which meta-model the YANG module is written > for. I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. Lada >=20 >=20 > /martin >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>> Am I completely misguided here? If not, then I don't see where the = new >>>> modules refer to any particular datastore model. Yes, they do = reflect >>>> that there is configuration and state data, but we don't want to = get >>>> rid of this distinction, right? >>>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>>=20 >>>>>=20 >>>>> /martin >>>>=20 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 05:20:05 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDAEF129C12; Wed, 11 Jan 2017 05:20:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sQqvZEejHpJZ; Wed, 11 Jan 2017 05:19:59 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18EC4129C13; Wed, 11 Jan 2017 05:19:59 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id C3B7260A57; Wed, 11 Jan 2017 14:19:57 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484140797; bh=31QZlLtJVmwEX3PsgArISf8FsPVOIqY/snrtUkpllIw=; h=From:Date:To; b=ejsrfZjOuyuKZl79rDeC92tubWZ6CMC6u9OvbQ+3Pci03NAuVEFE0+BUYA9J7CSjE LCVcq4WBPmh1ParFL5MVRO+v1iP1sRGnKLeiMBkmuBk/S5XWK+1ZwgFUeueH7DKPGn sjEoBhxtW+o11Afccck6G/xnEftpqbnbgGPm65iw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> Date: Wed, 11 Jan 2017 14:19:59 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <43102666-6730-4AD9-9E4E-CEAF86C8C5F0@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 13:20:02 -0000 > On 11 Jan 2017, at 14:05, Ladislav Lhotka wrote: >=20 >>=20 >> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>=20 >> Ladislav Lhotka wrote: >>>=20 >>>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>>=20 >>>> Ladislav Lhotka wrote: >>>>>=20 >>>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund = wrote: >>>>>>=20 >>>>>> Ladislav Lhotka wrote: >>>>>>>=20 >>>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>>=20 >>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>=20 >>>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>>=20 >>>>>>>>>>> I think we need protocol and YANG specs that are not tied to = any >>>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>>> languages work this way. >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>>=20 >>>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>>> with a client that supports only XML. >>>>>>>>>=20 >>>>>>>>> We are not in a situation that every pair of a randomly chosen = server >>>>>>>>> and client need to be interoperable. It's IMO perfectly fine = if IoT >>>>>>>>> and ISP networks use different clients. Yet, both can still = use the >>>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>>=20 >>>>>>>> The fact is that that data models are written with a certain = set of >>>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>>> examples: >>>>>>>>=20 >>>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>>> would not see the /foo vs /foo-state split. >>>>>>>=20 >>>>>>> Yes, but I assume this will go away anyway. However, we can = still have >>>>>>> YANG modules (and complete schemas) designed for the operational >>>>>>> datastore. The important property of the "meta-model" so far has = been >>>>>>> that config and state data are separate, and this is not going = to >>>>>>> change. >>>>>>>=20 >>>>>>>>=20 >>>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>>> RowStatus. If NETCONF didn't have a way to create instances, = we would >>>>>>>> have seen something similar in YANG models. >>>>>>>>=20 >>>>>>>> If NETCONF had a way to add comments to any node in a = datastore, we >>>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>>=20 >>>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>>=20 >>>>>>> Maybe, but are the last three points relevant to this = discussion? >>>>>>=20 >>>>>> The point is that data models are designed with some meta-model = in >>>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>>=20 >>>>> But where and how is this reflected in existing YANG modules = (except >>>>> for the foo and foo-state split, which is IMO a minor issue)? >>>>=20 >>>> I don't this split is a minor issue. For the openconfig group, = this >>>> is one of the major problems with YANG, leading to their design = with >>>> duplicate leafs. The reason for adding the operational state >>>> datastore in the form we propose in the draft it to be able to get = rid >>>> of this split. >>>>=20 >>>>>> I believe both the protocols and YANG can work with any set of >>>>>> datastores [...] >>>>>>=20 >>>>>> And I don't think that this is true (practically). For example, = a >>>>>> YANG module that is designed with the new operational state = datastore >>>>>> in mind will be of limited use in a legacy NETCONF server. >>>>>=20 >>>>> Please explain. >>>>=20 >>>> If a YANG module is designed with this new architecture in mind, it >>>> will have a single top-level tree, which can support = pre-configuration >>>> and different instances in the config and operational state. >>>>=20 >>>> If such a module is implemented in a legacy NETCONF server, the = only >>>> way to get the operational state is to used . But = will >>>> return the union between running and operational state. The client >>>> can't tell if an instance is really present in the operational = state, >>>> or just in the config. >>>>=20 >>>>=20 >>>> My idea what could be done e.g. with ietf-interfaces >>>>> is this: >>>>>=20 >>>>> 1. Split it into two modules, say ietf-interfaces-config and >>>>> ietf-interfaces-state. The former would contain exactly what's now >>>>> inside "interfaces", and the latter will augment it with extra = state >>>>> data that are now under "interfaces-state". >>>>>=20 >>>>> 2. The data model for configuration datastores will be defined to >>>>> contain only ietf-interfaces-config whereas for operational-state >>>>> datastore it will be ietf-interfaces-config *and* >>>>> ietf-interfaces-state. >>>>=20 >>>> If we do this for all modules then we haven't gained anything; we >>>> still have duplicate definitions. >>>=20 >>> Show me a single YANG data node definition that's duplicate in my >>> concept above. But then maybe I didn't explain it properly. >>=20 >> The interface's "type" leaf. With the new operational-state >> datastore, /interfaces/interface/type in operational-state and >> /interfaces-state/interface/type are duplicate. >=20 > As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >=20 >>=20 >>> Note also that you slightly misinterpreted my statement that you >>> cited: >>>=20 >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>>=20 >>> I didn't say that there cannot be *modules* that are somehow = designed >>> for a particular datastore model - I meant YANG the language. >>=20 >> Ok. Yes, you're right, but then we'd probably need some new = statement >> in each module that tells which meta-model the YANG module is written >> for. >=20 > I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. BTW, this approach could also solve the issue of different "levels" of = data that Rob asked about previously: https://www.ietf.org/mail-archive/web/netmod/current/msg17125.html A server could then provide additional operational-state datastores, for = example "operational-state-diagnostics" and = "operational-state-registers". This is IMO quite a clean solution. Lada >=20 > Lada >=20 >>=20 >>=20 >> /martin >>=20 >>=20 >>>=20 >>> Lada >>>=20 >>>>=20 >>>>=20 >>>> /martin >>>>=20 >>>>=20 >>>>> Am I completely misguided here? If not, then I don't see where the = new >>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>> that there is configuration and state data, but we don't want to = get >>>>> rid of this distinction, right? >>>>>=20 >>>>> Lada >>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>=20 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>=20 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 06:18:30 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE0F3129C84; Wed, 11 Jan 2017 06:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8CbXXyXzi6O8; Wed, 11 Jan 2017 06:18:22 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 484B5129C7A; Wed, 11 Jan 2017 06:18:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2736; q=dns/txt; s=iport; t=1484144302; x=1485353902; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=hl8ArC+/IJddqntZ2aVOiri068u1/Moj1KJBrixmoho=; b=WlmOUMTb8sD7oVIE8dqX6kunzszEa64ZVnVHLl6K09d/6ku23YGNgN7k MR4Xilzb5pcZ0thBjj2vhZ+KNumk/qfnKsNi2bZZ20Ly79ALFdYDytE+O Q5sLqQfDsMbPEjpquX3+kAL682tKd0FZqkz5wYDjFYTiINbx4jtwMM4d6 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQDuPXZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6NV3KRIZUnggsfC4UuSgKCOBQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALGCMLJzAGAQwGAgEBiHQIDrJkihYBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEYBYZFggKCX4osBZsqkVOBd4g2I4YVimaHex84Nl0SBxUVOoQ?= =?us-ascii?q?0HBiBRz41iGYBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="651530567" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 14:18:19 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0BEIJix010465; Wed, 11 Jan 2017 14:18:19 GMT To: Ladislav Lhotka , =?UTF-8?Q?Martin_Bj=c3=b6rklund?= References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> From: Robert Wilton Message-ID: Date: Wed, 11 Jan 2017 14:18:19 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:18:25 -0000 Hi, On 11/01/2017 13:05, Ladislav Lhotka wrote: >> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >> >> Ladislav Lhotka wrote: >>> Show me a single YANG data node definition that's duplicate in my >>> concept above. But then maybe I didn't explain it properly. >> The interface's "type" leaf. With the new operational-state >> datastore, /interfaces/interface/type in operational-state and >> /interfaces-state/interface/type are duplicate. > As I said, ietf-interfaces-state state would consist of augments containing extra state nodes (i.e. those that are not in configuration). So "type" won't be there. I think that this effectively just achieves the same thing that the "config: true|false" statement indicates in a combined config/state tree. Personally, I think that a file of augmentations is probably going to be harder to read than having the config and state schema in one tree in one file. The models may also be slightly more inconvenient to use because the state tree leaves would presumably be in a different namespace from the configuration? If you wanted this file level split then using submodules would allow for separate config/state files but still be managed as a single combined module. Rob > >>> Note also that you slightly misinterpreted my statement that you >>> cited: >>> >>> I believe both the protocols and YANG can work with any set of >>> datastores [...] >>> >>> I didn't say that there cannot be *modules* that are somehow designed >>> for a particular datastore model - I meant YANG the language. >> Ok. Yes, you're right, but then we'd probably need some new statement >> in each module that tells which meta-model the YANG module is written >> for. > I would prefer to have it as state data, basically separate YANG libraries for configuration datastores and operational-state. > > Lada > >> >> /martin >> >> >>> Lada >>> >>>> >>>> /martin >>>> >>>> >>>>> Am I completely misguided here? If not, then I don't see where the new >>>>> modules refer to any particular datastore model. Yes, they do reflect >>>>> that there is configuration and state data, but we don't want to get >>>>> rid of this distinction, right? >>>>> >>>>> Lada >>>>> >>>>>> >>>>>> >>>>>> /martin >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > . > From nobody Wed Jan 11 06:37:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B41A6129ED7; Wed, 11 Jan 2017 06:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 B9G1U03KtrMq; Wed, 11 Jan 2017 06:37:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B7CC8129CA4; Wed, 11 Jan 2017 06:37:04 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 008B51AE02BA; Wed, 11 Jan 2017 15:37:03 +0100 (CET) Date: Wed, 11 Jan 2017 15:37:03 +0100 (CET) Message-Id: <20170111.153703.778626501770378439.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> References: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:37:07 -0000 Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: > > > > Ladislav Lhotka wrote: > >> > >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > >>> > >>> Ladislav Lhotka wrote: > >>>> > >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > >>>>> > >>>>> Ladislav Lhotka wrote: > >>>>>> > >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > >>>>>>> > >>>>>>> Ladislav Lhotka wrote: > >>>>>>>> > >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > >>>>>>>>> wrote: > >>>>>>>>> > >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > >>>>>>>>>> > >>>>>>>>>> I think we need protocol and YANG specs that are not tied to any > >>>>>>>>>> particular model and that are thus capable of matching unforeseen > >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > >>>>>>>>>> languages work this way. > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > >>>>>>>>> goal is interoperable configuration of network devices; the notion of > >>>>>>>> > >>>>>>>> Even now, a client that's programmed to write straight to running > >>>>>>>> isn't interoperable with a server that has candidate and read-only > >>>>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > >>>>>>>> with a client that supports only XML. > >>>>>>>> > >>>>>>>> We are not in a situation that every pair of a randomly chosen server > >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > >>>>>>>> and ISP networks use different clients. Yet, both can still use the > >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. > >>>>>>> > >>>>>>> The fact is that that data models are written with a certain set of > >>>>>>> protocol features and datastores in mind (the "meta-model"). Some > >>>>>>> examples: > >>>>>>> > >>>>>>> If we had an "operational-state" datastore like the one proposed, we > >>>>>>> would not see the /foo vs /foo-state split. > >>>>>> > >>>>>> Yes, but I assume this will go away anyway. However, we can still have > >>>>>> YANG modules (and complete schemas) designed for the operational > >>>>>> datastore. The important property of the "meta-model" so far has been > >>>>>> that config and state data are separate, and this is not going to > >>>>>> change. > >>>>>> > >>>>>>> > >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have used > >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > >>>>>>> have seen something similar in YANG models. > >>>>>>> > >>>>>>> If NETCONF had a way to add comments to any node in a datastore, we > >>>>>>> wouldn't have "leaf description" sprinkled throughout the models. > >>>>>>> > >>>>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > >>>>>>> see lots of specific get-* rpcs in YANG models. > >>>>>> > >>>>>> Maybe, but are the last three points relevant to this discussion? > >>>>> > >>>>> The point is that data models are designed with some meta-model in > >>>>> mind. The meta-model includes (some) datastores. You wrote: > >>>> > >>>> But where and how is this reflected in existing YANG modules (except > >>>> for the foo and foo-state split, which is IMO a minor issue)? > >>> > >>> I don't this split is a minor issue. For the openconfig group, this > >>> is one of the major problems with YANG, leading to their design with > >>> duplicate leafs. The reason for adding the operational state > >>> datastore in the form we propose in the draft it to be able to get rid > >>> of this split. > >>> > >>>>> I believe both the protocols and YANG can work with any set of > >>>>> datastores [...] > >>>>> > >>>>> And I don't think that this is true (practically). For example, a > >>>>> YANG module that is designed with the new operational state datastore > >>>>> in mind will be of limited use in a legacy NETCONF server. > >>>> > >>>> Please explain. > >>> > >>> If a YANG module is designed with this new architecture in mind, it > >>> will have a single top-level tree, which can support pre-configuration > >>> and different instances in the config and operational state. > >>> > >>> If such a module is implemented in a legacy NETCONF server, the only > >>> way to get the operational state is to used . But will > >>> return the union between running and operational state. The client > >>> can't tell if an instance is really present in the operational state, > >>> or just in the config. > >>> > >>> > >>> My idea what could be done e.g. with ietf-interfaces > >>>> is this: > >>>> > >>>> 1. Split it into two modules, say ietf-interfaces-config and > >>>> ietf-interfaces-state. The former would contain exactly what's now > >>>> inside "interfaces", and the latter will augment it with extra state > >>>> data that are now under "interfaces-state". > >>>> > >>>> 2. The data model for configuration datastores will be defined to > >>>> contain only ietf-interfaces-config whereas for operational-state > >>>> datastore it will be ietf-interfaces-config *and* > >>>> ietf-interfaces-state. > >>> > >>> If we do this for all modules then we haven't gained anything; we > >>> still have duplicate definitions. > >> > >> Show me a single YANG data node definition that's duplicate in my > >> concept above. But then maybe I didn't explain it properly. > > > > The interface's "type" leaf. With the new operational-state > > datastore, /interfaces/interface/type in operational-state and > > /interfaces-state/interface/type are duplicate. > > As I said, ietf-interfaces-state state would consist of augments > containing extra state nodes (i.e. those that are not in > configuration). So "type" won't be there. So how would a client learn the type of a system-controlled interface? > >> Note also that you slightly misinterpreted my statement that you > >> cited: > >> > >> I believe both the protocols and YANG can work with any set of > >> datastores [...] > >> > >> I didn't say that there cannot be *modules* that are somehow designed > >> for a particular datastore model - I meant YANG the language. > > > > Ok. Yes, you're right, but then we'd probably need some new statement > > in each module that tells which meta-model the YANG module is written > > for. > > I would prefer to have it as state data, basically separate YANG > libraries for configuration datastores and operational-state. But the use case is that a particular module is designed for a certain datastore model (which you wrote above). This is a design-time property, not a rum-time property, so state data (run-time) is not the right solution. If a module is designed for a certain datastore model, that module cannot be implemented in a server with some other datastore model. /martin From nobody Wed Jan 11 06:43:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67E89129CAF; Wed, 11 Jan 2017 06:43:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 bjd7daW9y4Um; Wed, 11 Jan 2017 06:43:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id B5EB9129CAE; Wed, 11 Jan 2017 06:43:18 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 03D0D1AE02BA; Wed, 11 Jan 2017 15:43:18 +0100 (CET) Date: Wed, 11 Jan 2017 15:43:17 +0100 (CET) Message-Id: <20170111.154317.387424575739598718.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <20170111.153703.778626501770378439.mbj@tail-f.com> References: <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <20170111.153703.778626501770378439.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:43:20 -0000 Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: > > > > > > Ladislav Lhotka wrote: > > >> > > >>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: > > >>> > > >>> Ladislav Lhotka wrote: > > >>>> > > >>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund wrote: > > >>>>> > > >>>>> Ladislav Lhotka wrote: > > >>>>>> > > >>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund wrote: > > >>>>>>> > > >>>>>>> Ladislav Lhotka wrote: > > >>>>>>>> > > >>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder > > >>>>>>>>> wrote: > > >>>>>>>>> > > >>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka wrote: > > >>>>>>>>>> > > >>>>>>>>>> I think we need protocol and YANG specs that are not tied to any > > >>>>>>>>>> particular model and that are thus capable of matching unforeseen > > >>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML schema > > >>>>>>>>>> languages work this way. > > >>>>>>>>>> > > >>>>>>>>> > > >>>>>>>>> I disagree that HTTP and XML schema languages do the same thing. Our > > >>>>>>>>> goal is interoperable configuration of network devices; the notion of > > >>>>>>>> > > >>>>>>>> Even now, a client that's programmed to write straight to running > > >>>>>>>> isn't interoperable with a server that has candidate and read-only > > >>>>>>>> running. A RESTCONF server that supports only JSON isn't interoperable > > >>>>>>>> with a client that supports only XML. > > >>>>>>>> > > >>>>>>>> We are not in a situation that every pair of a randomly chosen server > > >>>>>>>> and client need to be interoperable. It's IMO perfectly fine if IoT > > >>>>>>>> and ISP networks use different clients. Yet, both can still use the > > >>>>>>>> same RESTCONF, same YANG, and even same YANG modules. > > >>>>>>> > > >>>>>>> The fact is that that data models are written with a certain set of > > >>>>>>> protocol features and datastores in mind (the "meta-model"). Some > > >>>>>>> examples: > > >>>>>>> > > >>>>>>> If we had an "operational-state" datastore like the one proposed, we > > >>>>>>> would not see the /foo vs /foo-state split. > > >>>>>> > > >>>>>> Yes, but I assume this will go away anyway. However, we can still have > > >>>>>> YANG modules (and complete schemas) designed for the operational > > >>>>>> datastore. The important property of the "meta-model" so far has been > > >>>>>> that config and state data are separate, and this is not going to > > >>>>>> change. > > >>>>>> > > >>>>>>> > > >>>>>>> If SNMP would have had a CREATE operation, MIBs would not have used > > >>>>>>> RowStatus. If NETCONF didn't have a way to create instances, we would > > >>>>>>> have seen something similar in YANG models. > > >>>>>>> > > >>>>>>> If NETCONF had a way to add comments to any node in a datastore, we > > >>>>>>> wouldn't have "leaf description" sprinkled throughout the models. > > >>>>>>> > > >>>>>>> If NETCONF didn't have a generic way to filter retreived data, we'd > > >>>>>>> see lots of specific get-* rpcs in YANG models. > > >>>>>> > > >>>>>> Maybe, but are the last three points relevant to this discussion? > > >>>>> > > >>>>> The point is that data models are designed with some meta-model in > > >>>>> mind. The meta-model includes (some) datastores. You wrote: > > >>>> > > >>>> But where and how is this reflected in existing YANG modules (except > > >>>> for the foo and foo-state split, which is IMO a minor issue)? > > >>> > > >>> I don't this split is a minor issue. For the openconfig group, this > > >>> is one of the major problems with YANG, leading to their design with > > >>> duplicate leafs. The reason for adding the operational state > > >>> datastore in the form we propose in the draft it to be able to get rid > > >>> of this split. > > >>> > > >>>>> I believe both the protocols and YANG can work with any set of > > >>>>> datastores [...] > > >>>>> > > >>>>> And I don't think that this is true (practically). For example, a > > >>>>> YANG module that is designed with the new operational state datastore > > >>>>> in mind will be of limited use in a legacy NETCONF server. > > >>>> > > >>>> Please explain. > > >>> > > >>> If a YANG module is designed with this new architecture in mind, it > > >>> will have a single top-level tree, which can support pre-configuration > > >>> and different instances in the config and operational state. > > >>> > > >>> If such a module is implemented in a legacy NETCONF server, the only > > >>> way to get the operational state is to used . But will > > >>> return the union between running and operational state. The client > > >>> can't tell if an instance is really present in the operational state, > > >>> or just in the config. > > >>> > > >>> > > >>> My idea what could be done e.g. with ietf-interfaces > > >>>> is this: > > >>>> > > >>>> 1. Split it into two modules, say ietf-interfaces-config and > > >>>> ietf-interfaces-state. The former would contain exactly what's now > > >>>> inside "interfaces", and the latter will augment it with extra state > > >>>> data that are now under "interfaces-state". > > >>>> > > >>>> 2. The data model for configuration datastores will be defined to > > >>>> contain only ietf-interfaces-config whereas for operational-state > > >>>> datastore it will be ietf-interfaces-config *and* > > >>>> ietf-interfaces-state. > > >>> > > >>> If we do this for all modules then we haven't gained anything; we > > >>> still have duplicate definitions. > > >> > > >> Show me a single YANG data node definition that's duplicate in my > > >> concept above. But then maybe I didn't explain it properly. > > > > > > The interface's "type" leaf. With the new operational-state > > > datastore, /interfaces/interface/type in operational-state and > > > /interfaces-state/interface/type are duplicate. > > > > As I said, ietf-interfaces-state state would consist of augments > > containing extra state nodes (i.e. those that are not in > > configuration). So "type" won't be there. > > So how would a client learn the type of a system-controlled interface? Never mind; I misread your proposal, sorry about that. But I agree with Rob; how is the proposal with two modules different than having them in the same module (apart from the additional namespace required)? /martin From nobody Wed Jan 11 06:48:12 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6112A129B3A; Wed, 11 Jan 2017 06:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Sjr43PdRjPsh; Wed, 11 Jan 2017 06:48:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 55D4D129518; Wed, 11 Jan 2017 06:48:06 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id EAE3360ABB; Wed, 11 Jan 2017 15:48:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484146085; bh=hlOqx2zwI0DT8F/z60z+OeHiCS+mVpW81qfYgPest88=; h=From:Date:To; b=XupAButoxATWq1Hin752hkpHPpnbp94o37QR/IWbi6hZESxHdb4rMn8fE3x+h4VU0 tKxX+VOpeYB5GfbinGLF8QA8j8YrhGgKufHhAUl4NAQGVQWfU4BkfBXx4kxq5amSku 57dPgd+wnN3C08kEDkig8TvJrL8bMKcNLomnJ1xk= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 11 Jan 2017 15:48:06 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 14:48:08 -0000 > On 11 Jan 2017, at 15:18, Robert Wilton wrote: >=20 > Hi, >=20 > On 11/01/2017 13:05, Ladislav Lhotka wrote: >>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: > >>>> Show me a single YANG data node definition that's duplicate in my >>>> concept above. But then maybe I didn't explain it properly. >>> The interface's "type" leaf. With the new operational-state >>> datastore, /interfaces/interface/type in operational-state and >>> /interfaces-state/interface/type are duplicate. >> As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. > I think that this effectively just achieves the same thing that the = "config: true|false" statement indicates in a combined config/state = tree. >=20 > Personally, I think that a file of augmentations is probably going to = be harder to read than having the config and state schema in one tree in = one file. Possibly we could also use schema mount. On the other hand, it doesn't = enforce the use of operational-state datastore. A simple device like a = WiFi-controlled electric socket could easily use just = ietf-interfaces-config (and ietf-ip-config), i.e. no state data. Another example I am dealing with now is OpenWRT: with some effort, it = would be possible to translate our nice configuration data into UCI = files without touching the OpenWRT system itself. On the other hand, = serving state data according to our YANG modules is a non-starter. >=20 > The models may also be slightly more inconvenient to use because the = state tree leaves would presumably be in a different namespace from the = configuration? >=20 Yes, but I don't think it is a big problem - even for human readers. > If you wanted this file level split then using submodules would allow = for separate config/state files but still be managed as a single = combined module. But it means you have to implement both. Lada >=20 > Rob >=20 >=20 >>=20 >>>> Note also that you slightly misinterpreted my statement that you >>>> cited: >>>>=20 >>>> I believe both the protocols and YANG can work with any set of >>>> datastores [...] >>>>=20 >>>> I didn't say that there cannot be *modules* that are somehow = designed >>>> for a particular datastore model - I meant YANG the language. >>> Ok. Yes, you're right, but then we'd probably need some new = statement >>> in each module that tells which meta-model the YANG module is = written >>> for. >> I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. >=20 >=20 >>=20 >> Lada >>=20 >>>=20 >>> /martin >>>=20 >>>=20 >>>> Lada >>>>=20 >>>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>> Am I completely misguided here? If not, then I don't see where = the new >>>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>>> that there is configuration and state data, but we don't want to = get >>>>>> rid of this distinction, right? >>>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>>=20 >>>>>>>=20 >>>>>>> /martin >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 07:10:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16338129493; Wed, 11 Jan 2017 07:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KKVDsH6qPbwd; Wed, 11 Jan 2017 07:10:17 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2373A12948C; Wed, 11 Jan 2017 07:10:17 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 7431060CAC; Wed, 11 Jan 2017 16:10:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484147415; bh=b0QaPQqdZ6zFWWhvEr68L7bdFFGSKSOC+dLmphKL/ls=; h=From:Date:To; b=c7bVOehlbNuHXrZ1ymjFCpJbz4dsBJlXeu1e1U63EsXwZ4C+eThY+x2C1YK5SnKoe eXUIh3q4hbWYuzrksuIQfob0ybcFuWe+9/FskHPbaHwOqRNAltyvBWcDEY0xGQhMBG /73s1wwjsu+44zUTkFdT0UQdExrLRda20BFlSzis= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170111.153703.778626501770378439.mbj@tail-f.com> Date: Wed, 11 Jan 2017 16:10:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <91CB84A8-5C90-4971-90A7-F4B68CE041F0@nic.cz> References: <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <20170111.153703.778626501770378439.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:10:19 -0000 > On 11 Jan 2017, at 15:37, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>=20 >>> Ladislav Lhotka wrote: >>>>=20 >>>>> On 11 Jan 2017, at 13:27, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>>>>>=20 >>>>>>> On 11 Jan 2017, at 12:16, Martin Bjorklund = wrote: >>>>>>>=20 >>>>>>> Ladislav Lhotka wrote: >>>>>>>>=20 >>>>>>>>> On 11 Jan 2017, at 10:36, Martin Bjorklund = wrote: >>>>>>>>>=20 >>>>>>>>> Ladislav Lhotka wrote: >>>>>>>>>>=20 >>>>>>>>>>> On 10 Jan 2017, at 09:39, Juergen Schoenwaelder >>>>>>>>>>> wrote: >>>>>>>>>>>=20 >>>>>>>>>>> On Tue, Jan 10, 2017 at 09:20:36AM +0100, Ladislav Lhotka = wrote: >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we need protocol and YANG specs that are not tied = to any >>>>>>>>>>>> particular model and that are thus capable of matching = unforeseen >>>>>>>>>>>> real-world implementations. This is no sci-fi, HTTP and XML = schema >>>>>>>>>>>> languages work this way. >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> I disagree that HTTP and XML schema languages do the same = thing. Our >>>>>>>>>>> goal is interoperable configuration of network devices; the = notion of >>>>>>>>>>=20 >>>>>>>>>> Even now, a client that's programmed to write straight to = running >>>>>>>>>> isn't interoperable with a server that has candidate and = read-only >>>>>>>>>> running. A RESTCONF server that supports only JSON isn't = interoperable >>>>>>>>>> with a client that supports only XML. >>>>>>>>>>=20 >>>>>>>>>> We are not in a situation that every pair of a randomly = chosen server >>>>>>>>>> and client need to be interoperable. It's IMO perfectly fine = if IoT >>>>>>>>>> and ISP networks use different clients. Yet, both can still = use the >>>>>>>>>> same RESTCONF, same YANG, and even same YANG modules. >>>>>>>>>=20 >>>>>>>>> The fact is that that data models are written with a certain = set of >>>>>>>>> protocol features and datastores in mind (the "meta-model"). = Some >>>>>>>>> examples: >>>>>>>>>=20 >>>>>>>>> If we had an "operational-state" datastore like the one = proposed, we >>>>>>>>> would not see the /foo vs /foo-state split. >>>>>>>>=20 >>>>>>>> Yes, but I assume this will go away anyway. However, we can = still have >>>>>>>> YANG modules (and complete schemas) designed for the = operational >>>>>>>> datastore. The important property of the "meta-model" so far = has been >>>>>>>> that config and state data are separate, and this is not going = to >>>>>>>> change. >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> If SNMP would have had a CREATE operation, MIBs would not have = used >>>>>>>>> RowStatus. If NETCONF didn't have a way to create instances, = we would >>>>>>>>> have seen something similar in YANG models. >>>>>>>>>=20 >>>>>>>>> If NETCONF had a way to add comments to any node in a = datastore, we >>>>>>>>> wouldn't have "leaf description" sprinkled throughout the = models. >>>>>>>>>=20 >>>>>>>>> If NETCONF didn't have a generic way to filter retreived data, = we'd >>>>>>>>> see lots of specific get-* rpcs in YANG models. >>>>>>>>=20 >>>>>>>> Maybe, but are the last three points relevant to this = discussion? >>>>>>>=20 >>>>>>> The point is that data models are designed with some meta-model = in >>>>>>> mind. The meta-model includes (some) datastores. You wrote: >>>>>>=20 >>>>>> But where and how is this reflected in existing YANG modules = (except >>>>>> for the foo and foo-state split, which is IMO a minor issue)? >>>>>=20 >>>>> I don't this split is a minor issue. For the openconfig group, = this >>>>> is one of the major problems with YANG, leading to their design = with >>>>> duplicate leafs. The reason for adding the operational state >>>>> datastore in the form we propose in the draft it to be able to get = rid >>>>> of this split. >>>>>=20 >>>>>>> I believe both the protocols and YANG can work with any set of >>>>>>> datastores [...] >>>>>>>=20 >>>>>>> And I don't think that this is true (practically). For example, = a >>>>>>> YANG module that is designed with the new operational state = datastore >>>>>>> in mind will be of limited use in a legacy NETCONF server. >>>>>>=20 >>>>>> Please explain. >>>>>=20 >>>>> If a YANG module is designed with this new architecture in mind, = it >>>>> will have a single top-level tree, which can support = pre-configuration >>>>> and different instances in the config and operational state. >>>>>=20 >>>>> If such a module is implemented in a legacy NETCONF server, the = only >>>>> way to get the operational state is to used . But = will >>>>> return the union between running and operational state. The = client >>>>> can't tell if an instance is really present in the operational = state, >>>>> or just in the config. >>>>>=20 >>>>>=20 >>>>> My idea what could be done e.g. with ietf-interfaces >>>>>> is this: >>>>>>=20 >>>>>> 1. Split it into two modules, say ietf-interfaces-config and >>>>>> ietf-interfaces-state. The former would contain exactly what's = now >>>>>> inside "interfaces", and the latter will augment it with extra = state >>>>>> data that are now under "interfaces-state". >>>>>>=20 >>>>>> 2. The data model for configuration datastores will be defined to >>>>>> contain only ietf-interfaces-config whereas for operational-state >>>>>> datastore it will be ietf-interfaces-config *and* >>>>>> ietf-interfaces-state. >>>>>=20 >>>>> If we do this for all modules then we haven't gained anything; we >>>>> still have duplicate definitions. >>>>=20 >>>> Show me a single YANG data node definition that's duplicate in my >>>> concept above. But then maybe I didn't explain it properly. >>>=20 >>> The interface's "type" leaf. With the new operational-state >>> datastore, /interfaces/interface/type in operational-state and >>> /interfaces-state/interface/type are duplicate. >>=20 >> As I said, ietf-interfaces-state state would consist of augments >> containing extra state nodes (i.e. those that are not in >> configuration). So "type" won't be there. >=20 > So how would a client learn the type of a system-controlled interface? >=20 >=20 >>>> Note also that you slightly misinterpreted my statement that you >>>> cited: >>>>=20 >>>> I believe both the protocols and YANG can work with any set of >>>> datastores [...] >>>>=20 >>>> I didn't say that there cannot be *modules* that are somehow = designed >>>> for a particular datastore model - I meant YANG the language. >>>=20 >>> Ok. Yes, you're right, but then we'd probably need some new = statement >>> in each module that tells which meta-model the YANG module is = written >>> for. >>=20 >> I would prefer to have it as state data, basically separate YANG >> libraries for configuration datastores and operational-state. >=20 > But the use case is that a particular module is designed for a certain > datastore model (which you wrote above). This is a design-time Not necessarily, and certainly not all modules. In my example with = ietf-interfaces, one could still emulate the current situation with = "interfaces" and "interfaces-state" by defining these containers as two = mount points and then schema-mounting the necessary schemas under each. = There are some minor annoyances regarding namespaces but it could IMO = also work fine for a client that uses the "old" datastore model. Lada > property, not a rum-time property, so state data (run-time) is not the > right solution. If a module is designed for a certain datastore > model, that module cannot be implemented in a server with some other > datastore model. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 07:12:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 616FB129468; Wed, 11 Jan 2017 07:12:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FmfRzC6uey2T; Wed, 11 Jan 2017 07:12:48 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB9EC129493; Wed, 11 Jan 2017 07:12:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6367; q=dns/txt; s=iport; t=1484147568; x=1485357168; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=oWJD7mhI2T+ITOFJgkgOqDeJlB94O0t/9NPtoIxEa5Q=; b=MC8d3N7dsXdExco3pLJMyPQmTgTIuNoYiHhJhQ8SMBG6WnYdi1h9gnMd Mdok4/jbG6GfAg+BN1aP34vF4Dy5vsT+OKRzK5fMG8pCi01Z9KGtAcfuF 6RQghlfa3B+iiMMJ/kaNfsPrSBnWegxZVUIwzs5W/ydmlpi+c15+MHWG8 o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BDAQAPS3ZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6DT4oIcpEhlSeCCx8LhS5KAoI5FAECAQEBAQE?= =?us-ascii?q?BAWMohGkBAQEDAQEBIQ8BBTYLBQsLDgoCAh8HAgInMAYBDAYCAQEXiF0IDrBGg?= =?us-ascii?q?iWKFQEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQuFOoICCIJXhDCDHoJeBY8cjA6?= =?us-ascii?q?JcIdjii2GOIpmh3sfOIETEgcVFTqEaIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="649712011" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 15:12:43 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0BFChAu004043; Wed, 11 Jan 2017 15:12:43 GMT To: Martin Bjorklund , andy@yumaworks.com References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> From: Robert Wilton Message-ID: <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> Date: Wed, 11 Jan 2017 15:12:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <20170111.102209.310040071380723970.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:12:50 -0000 On 11/01/2017 09:22, Martin Bjorklund wrote: > Andy Bierman wrote: >> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen wrote: >> >>>> I think it is better to have a human decide what is in the module >>>> instead of relying on a pyang plugin to generate some additional module >>>> that follows some simplistic pattern. >>> It may be simple, but I’m thinking that’s only because it’s not tricky ;) >>> >>> >> The client and server developers still need to know about this >> auto-generated module >> and implement it. Operators might have to know about it to use it. My idea is not to auto generate models on the fly. My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore. The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore. This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today. The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore. I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort. Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices. As an illustration, an RFC published combined ietf-interfaces model may look like this: module: ietf-interfaces-combined +--rw interfaces +--rw interface* [name] +--rw name string +--rw description? string +--rw type identityref +--rw enabled? boolean +--rw link-up-down-trap-enable? enumeration {if-mib}? +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 {if-mib}? +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-ref +--ro lower-layer-if* interface-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 The extra generated model would look like this: module: ietf-interfaces-combined-state +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro description? string +--ro type identityref +--ro enabled? boolean +--ro link-up-down-trap-enable? enumeration {if:if-mib}? +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 {if:if-mib}? +--ro phys-address? yang:phys-address +--ro higher-layer-if* if:interface-ref +--ro lower-layer-if* if:interface-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 Servers that support operational-state would just implement ietf-interfaces-combined Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree. Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree. Of course, Clients may need to support both schemes depending on what types of devices they are interacting with. Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model. I was more thinking about IETF protocols that in the process of working on their YANG models. Rob > Exactly. I agree that this is a real hack. Implementations can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very clear. > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Jan 11 07:18:21 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6762F129485; Wed, 11 Jan 2017 07:18:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4KqN_SJ9pwz; Wed, 11 Jan 2017 07:18:14 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDC43128E19; Wed, 11 Jan 2017 07:18:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4124; q=dns/txt; s=iport; t=1484147894; x=1485357494; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=2OL/15lsPvFtaWxcmUtNPLK9EC9YLEspXI8JZXd5gIM=; b=OQkSVbtDjN9Ah76zie/k4+FMU+IbeWlv91Im7d4SRE/RDjMMciYk2Y5L hM8euAkcrspvGHbMGPVus3D1hGoykZ+v7oliXVTaXksVkgVTzCIupXFet rsCOOBUhy0o/9kTCX9V3fyZ6A3RBhQEKbn5eH1nWRF/CmnxDsS2YicCuq Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AQALTHZY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzsBAQEBAX4DLF6NV3KRIZUnggsfC4UuSgKCORQBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwEBATY2CxALGCMLJzAGDQYCAQGIdAgOsm2KFQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBARgFhkWCAgiCV4osBZsqkVOBd4g2I4YVimaHex84gRMSBxUVOoQ?= =?us-ascii?q?0HBiBRz41iGYBAQE?= X-IronPort-AV: E=Sophos;i="5.33,346,1477958400"; d="scan'208";a="691253264" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 15:18:09 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0BFI98I005560; Wed, 11 Jan 2017 15:18:09 GMT To: Ladislav Lhotka References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> From: Robert Wilton Message-ID: <3d286f25-f383-8029-639c-5091838190c6@cisco.com> Date: Wed, 11 Jan 2017 15:18:09 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:18:16 -0000 On 11/01/2017 14:48, Ladislav Lhotka wrote: >> On 11 Jan 2017, at 15:18, Robert Wilton wrote: >> >> Hi, >> >> On 11/01/2017 13:05, Ladislav Lhotka wrote: >>>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>> >>>> Ladislav Lhotka wrote: >> >>>>> Show me a single YANG data node definition that's duplicate in my >>>>> concept above. But then maybe I didn't explain it properly. >>>> The interface's "type" leaf. With the new operational-state >>>> datastore, /interfaces/interface/type in operational-state and >>>> /interfaces-state/interface/type are duplicate. >>> As I said, ietf-interfaces-state state would consist of augments containing extra state nodes (i.e. those that are not in configuration). So "type" won't be there. >> I think that this effectively just achieves the same thing that the "config: true|false" statement indicates in a combined config/state tree. >> >> Personally, I think that a file of augmentations is probably going to be harder to read than having the config and state schema in one tree in one file. > Possibly we could also use schema mount. On the other hand, it doesn't enforce the use of operational-state datastore. A simple device like a WiFi-controlled electric socket could easily use just ietf-interfaces-config (and ietf-ip-config), i.e. no state data. > > Another example I am dealing with now is OpenWRT: with some effort, it would be possible to translate our nice configuration data into UCI files without touching the OpenWRT system itself. On the other hand, serving state data according to our YANG modules is a non-starter. Isn't the proper answer here to generate deviations to remove the state leaves that won't be implemented. > >> The models may also be slightly more inconvenient to use because the state tree leaves would presumably be in a different namespace from the configuration? >> > Yes, but I don't think it is a big problem - even for human readers. I'm not sure. I think that you might end up with a variation of the OpenConfig models, and based on experience I would say that those models are hard to read if they haven't been compiled first to expand the groupings and reveal the actual structure. Rob > >> If you wanted this file level split then using submodules would allow for separate config/state files but still be managed as a single combined module. > But it means you have to implement both. > > Lada > >> Rob >> >> >>>>> Note also that you slightly misinterpreted my statement that you >>>>> cited: >>>>> >>>>> I believe both the protocols and YANG can work with any set of >>>>> datastores [...] >>>>> >>>>> I didn't say that there cannot be *modules* that are somehow designed >>>>> for a particular datastore model - I meant YANG the language. >>>> Ok. Yes, you're right, but then we'd probably need some new statement >>>> in each module that tells which meta-model the YANG module is written >>>> for. >>> I would prefer to have it as state data, basically separate YANG libraries for configuration datastores and operational-state. >> >>> Lada >>> >>>> /martin >>>> >>>> >>>>> Lada >>>>> >>>>>> /martin >>>>>> >>>>>> >>>>>>> Am I completely misguided here? If not, then I don't see where the new >>>>>>> modules refer to any particular datastore model. Yes, they do reflect >>>>>>> that there is configuration and state data, but we don't want to get >>>>>>> rid of this distinction, right? >>>>>>> >>>>>>> Lada >>>>>>> >>>>>>>> >>>>>>>> /martin >>>>>>> -- >>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>> -- >>>>> Ladislav Lhotka, CZ.NIC Labs >>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>> -- >>> Ladislav Lhotka, CZ.NIC Labs >>> PGP Key ID: 0xB8F92B08A9F76C67 >>> >>> >>> >>> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> . > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > . > From nobody Wed Jan 11 07:37:27 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C463C1294FC; Wed, 11 Jan 2017 07:37:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nD9i2ic8nwhS; Wed, 11 Jan 2017 07:37:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 675D31294C5; Wed, 11 Jan 2017 07:37:19 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 127B760A76; Wed, 11 Jan 2017 16:37:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484149038; bh=gtiNAr2djj5TwD6rfsDaDGzjraHEFZapiGQyDXx5msM=; h=From:Date:To; b=svygttnLBPuCNJgYm32fGW7PYrCE07E9aIQrkVysi7CdTqWegGFGeJJb/hHtvQLeA LJXCAc49CGwAo37lBpjrvlyUQyD/v9YULOIPN8YH8HrRKN5QskYfyT2lpDNp/8bcy8 39L+FbWJ+WsIM12/DzILVhEZKCWjA3O2VHFL77fs= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <3d286f25-f383-8029-639c-5091838190c6@cisco.com> Date: Wed, 11 Jan 2017 16:37:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <82A87092-828B-4838-B327-C05791FBB8A0@nic.cz> References: <2C96B1C8-3D97-41FF-AD91-44432868C5CF@nic.cz> <20170111.132759.746322711124349871.mbj@tail-f.com> <25050412-8C71-44E7-8865-24320902ED2D@nic.cz> <20170111.135359.1145355019648401300.mbj@tail-f.com> <74141E09-06C2-439E-BA85-81E3FC12DD17@nic.cz> <203F849C-A116-4C48-A3F3-98D2F31D12A8@nic.cz> <3d286f25-f383-8029-639c-5091838190c6@cisco.com> To: Robert Wilton X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , NetMod WG Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 15:37:23 -0000 > On 11 Jan 2017, at 16:18, Robert Wilton wrote: >=20 >=20 >=20 > On 11/01/2017 14:48, Ladislav Lhotka wrote: >>> On 11 Jan 2017, at 15:18, Robert Wilton wrote: >>>=20 >>> Hi, >>>=20 >>> On 11/01/2017 13:05, Ladislav Lhotka wrote: >>>>> On 11 Jan 2017, at 13:53, Martin Bjorklund wrote: >>>>>=20 >>>>> Ladislav Lhotka wrote: >>> >>>>>> Show me a single YANG data node definition that's duplicate in my >>>>>> concept above. But then maybe I didn't explain it properly. >>>>> The interface's "type" leaf. With the new operational-state >>>>> datastore, /interfaces/interface/type in operational-state and >>>>> /interfaces-state/interface/type are duplicate. >>>> As I said, ietf-interfaces-state state would consist of augments = containing extra state nodes (i.e. those that are not in configuration). = So "type" won't be there. >>> I think that this effectively just achieves the same thing that the = "config: true|false" statement indicates in a combined config/state = tree. >>>=20 >>> Personally, I think that a file of augmentations is probably going = to be harder to read than having the config and state schema in one tree = in one file. >> Possibly we could also use schema mount. On the other hand, it = doesn't enforce the use of operational-state datastore. A simple device = like a WiFi-controlled electric socket could easily use just = ietf-interfaces-config (and ietf-ip-config), i.e. no state data. >>=20 >> Another example I am dealing with now is OpenWRT: with some effort, = it would be possible to translate our nice configuration data into UCI = files without touching the OpenWRT system itself. On the other hand, = serving state data according to our YANG modules is a non-starter. > Isn't the proper answer here to generate deviations to remove the = state leaves that won't be implemented. This is of course possible but deviations are generally frowned upon, so = why not use the modularity features for making it a little more = flexible? I know some people will now say that without state data it is = no proper network management but, speaking pragmatically, automated = configuration would be a big boon by itself. >=20 >>=20 >>> The models may also be slightly more inconvenient to use because the = state tree leaves would presumably be in a different namespace from the = configuration? >>>=20 >> Yes, but I don't think it is a big problem - even for human readers. > I'm not sure. I think that you might end up with a variation of the = OpenConfig models, and based on experience I would say that those models = are hard to read if they haven't been compiled first to expand the = groupings and reveal the actual structure. One thing that makes modules really hard to read are augments, and we = already have them all over the place. It's a trade-off between = readability and modularity. Lada >=20 > Rob >=20 >=20 >>=20 >>> If you wanted this file level split then using submodules would = allow for separate config/state files but still be managed as a single = combined module. >> But it means you have to implement both. >>=20 >> Lada >>=20 >>> Rob >>>=20 >>>=20 >>>>>> Note also that you slightly misinterpreted my statement that you >>>>>> cited: >>>>>>=20 >>>>>> I believe both the protocols and YANG can work with any set of >>>>>> datastores [...] >>>>>>=20 >>>>>> I didn't say that there cannot be *modules* that are somehow = designed >>>>>> for a particular datastore model - I meant YANG the language. >>>>> Ok. Yes, you're right, but then we'd probably need some new = statement >>>>> in each module that tells which meta-model the YANG module is = written >>>>> for. >>>> I would prefer to have it as state data, basically separate YANG = libraries for configuration datastores and operational-state. >>>=20 >>>> Lada >>>>=20 >>>>> /martin >>>>>=20 >>>>>=20 >>>>>> Lada >>>>>>=20 >>>>>>> /martin >>>>>>>=20 >>>>>>>=20 >>>>>>>> Am I completely misguided here? If not, then I don't see where = the new >>>>>>>> modules refer to any particular datastore model. Yes, they do = reflect >>>>>>>> that there is configuration and state data, but we don't want = to get >>>>>>>> rid of this distinction, right? >>>>>>>>=20 >>>>>>>> Lada >>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /martin >>>>>>>> -- >>>>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>>> -- >>>>>> Ladislav Lhotka, CZ.NIC Labs >>>>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>> -- >>>> Ladislav Lhotka, CZ.NIC Labs >>>> PGP Key ID: 0xB8F92B08A9F76C67 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing list >>>> Netconf@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netconf >>>> . >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: 0xB8F92B08A9F76C67 >>=20 >>=20 >>=20 >>=20 >>=20 >> . -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 08:56:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21C62129BC5 for ; Wed, 11 Jan 2017 08:56:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AEBJNThOClT6 for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) Received: from mail-qk0-x230.google.com (mail-qk0-x230.google.com [IPv6:2607:f8b0:400d:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3720B129CBA for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) Received: by mail-qk0-x230.google.com with SMTP id a20so215828481qkc.1 for ; Wed, 11 Jan 2017 08:56:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MgKqjg2SESvZtiqDPU1pKJdYMfh7HjCTRlz+WDO/0aw=; b=N8OGmqBaPjJhFEWiNgid4yHPB/ZdqDdjksMnOyGTVQC3Vd7FSzll5Yr/ctZZnDnTM7 lgyuk+ZCXhaoMy21Lr8O7SCTJMoHvRndBKnfT5UVQqyqVv0PCNCpnvDgUCLD0xlCrfta 3Axkr1URfQ57FP80a7mgoUji4vU9OQI5GUgQc1knB1fMihWthtRmnJHe99Jjgy9hT3UU FEHYewI0TH2dIOpBKKRZEfFayxt3UBYKQi7uM/qKaL2DDaKOCAAL+9LB4GikIXHi1dRX eeQ1RNE5Oc/NibXyv9IemOvCKGi5UQWjSBeJ1rd/Yb6HdM8Zt9aszFJnWwZ2dM3LikvC VgiA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MgKqjg2SESvZtiqDPU1pKJdYMfh7HjCTRlz+WDO/0aw=; b=tZaAPXo55zkSU+bVIb+w69E9zX7V4qEbV0DYpAtZjTPwj1Kyx2Hf5/nPUIAknDgP2e 3tyUqUQ5PnyGo6MLOixYBt4nhQD7XZm7jkkxTViNoDBc+sYtbcgK8XbiWbvFzAyJ1msl JIr1InJxyi+ZDkpMNXRhExdJNHxcnILNKFuV2NfBjgteryvu4xv7Q7PVlCl7aU06+dPK q8aEz6iJHlwtihiTMM7D3REjy7Lfc2GQSMifHjIf0QZOT6j0mpEjRWHVctDuhn41yifw BihXmTRqagBm/WG+UPZcMqIvavlTu7LuurRVvs896YCfnUOhBO/1xmrH18PpgGVDfRUA KoiA== X-Gm-Message-State: AIkVDXLZBAHw6YymjqHB6Wfd1jwssQNM99mbhk2O1BPmX62bGjhKtazGrtJXoiL9dXyyFB7wOU7cBLhrAaCM5g== X-Received: by 10.55.7.2 with SMTP id 2mr10347559qkh.228.1484153775264; Wed, 11 Jan 2017 08:56:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 08:56:14 -0800 (PST) In-Reply-To: <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> From: Andy Bierman Date: Wed, 11 Jan 2017 08:56:14 -0800 Message-ID: To: Robert Wilton Content-Type: multipart/alternative; boundary=001a114c877c91307d0545d47a49 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 16:56:19 -0000 --001a114c877c91307d0545d47a49 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton wrote: > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > >> Andy Bierman wrote: >> >>> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen >>> wrote: >>> >>> I think it is better to have a human decide what is in the module >>>>> instead of relying on a pyang plugin to generate some additional modu= le >>>>> that follows some simplistic pattern. >>>>> >>>> It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because= it=E2=80=99s not tricky >>>> ;) >>>> >>>> >>>> The client and server developers still need to know about this >>> auto-generated module >>> and implement it. Operators might have to know about it to use it. >>> >> My idea is not to auto generate models on the fly. > > My aim is to allow folks to start writing models in the desired long term > format (i.e. combined config and state tree) with the model designer bein= g > able to assume the existence of the operational state datastore. > > I am not convinced this "new format" has solved anything. Don't you need separate description-stmts in every node for each datastore? What does the value mean if pre-configured? configured? operational? Will the auto-generated objects be exactly correct and never need any alterations or additional text? They still need to be used by developers and YANG tools. Is is that realistic to force the config structure and operational structur= e to be the same? Seems it is quite common to monitor data structures with additional keys or different keys. This is completely unsupported so separate /foo and /foo-state trees will still exist. IMO this combination of trees needs to be proven. Take ietf-interfaces and show how much better it will work if the /interfaces and /interfaces-state trees were combined. Andy The tooling would be there to statically generate the extra foo-state > config false node modules for servers that don't support the operational > state datastore. This could be done once, and the extra foo-state module= s > committed to the github YANG respository in the same way that models are > extracted from IETF RFCs today. > > The aim here is that the single model being produced by IETF would be > usable both by new client/servers that support an operational state > datastore, and also by existing NETCONF client/servers that don't impleme= nt > an operational state datastore. > > I'm not proposing that as a long term solution, but as a path to make it > easier for folk to migrate, and to not slow down the model writing effort= . > Otherwise, it may be hard to get a protocol model writer to design the YA= NG > model in a way that is not fully usable on any current devices. > > As an illustration, an RFC published combined ietf-interfaces model may > look like this: > > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > The extra generated model would look like this: > > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > Servers that support operational-state would just implement > ietf-interfaces-combined > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, probably not > implementing the duplicate config false leaves under the interfaces confi= g > tree. Deviations could also be auto-generated to remove the config false > leaves from the config tree so that they are only in the state tree. > > Of course, Clients may need to support both schemes depending on what > types of devices they are interacting with. > > Finally, I've illustrated this using ietf-interfaces, but I'm not actuall= y > proposing immediately changing that model. I was more thinking about IET= F > protocols that in the process of working on their YANG models. > > Rob > > > Exactly. I agree that this is a real hack. Implementations can use >> whatever transformation tricks they want in order to comply with >> different standards, but the standard modules should be very clear. >> > > > > > >> >> /martin >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > > --001a114c877c91307d0545d47a49 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,


On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.= com> wrote:


On 11/01/2017 09:22, Martin Bjorklund wrote:
Andy Bierman <an= dy@yumaworks.com> wrote:
On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I think it is better to have a human decide what is in the module
instead of relying on a pyang plugin to generate some additional module
that follows some simplistic pattern.
It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because it= =E2=80=99s not tricky=C2=A0 ;)


The client and server developers still need to know about this
auto-generated module
and implement it.=C2=A0 Operators might have to know about it to use it.
My idea is not to auto generate models on the fly.

My aim is to allow folks to start writing models in the desired long term f= ormat (i.e. combined config and state tree) with the model designer being a= ble to assume the existence of the operational state datastore.



I am not convinced this= "new format" has solved anything.
Don't you need s= eparate description-stmts in every node for each
datastore?=C2=A0= What does the value mean if pre-configured? configured?
operatio= nal?=C2=A0 Will the auto-generated objects be exactly correct
and= never need any alterations or additional text?
They still need t= o be used by developers and YANG tools.

Is is that= realistic to force the config structure and operational structure
to be the same? Seems it is quite common to monitor data structures
=
with additional keys or different keys.=C2=A0 This is completely unsup= ported
so separate /foo and /foo-state trees will still exist.

IMO this combination of trees needs to be proven.
Take ietf-interfaces and show how much better it will work
if the /interfaces and /interfaces-state trees were combined.
<= br>

Andy


The tooling would be there to statically generate the extra foo-state confi= g false node modules for servers that don't support the operational sta= te datastore.=C2=A0 This could be done once, and the extra foo-state module= s committed to the github YANG respository in the same way that models are = extracted from IETF RFCs today.

The aim here is that the single model being produced by IETF would be usabl= e both by new client/servers that support an operational state datastore, a= nd also by existing NETCONF client/servers that don't implement an oper= ational state datastore.

I'm not proposing that as a long term solution, but as a path to make i= t easier for folk to migrate, and to not slow down the model writing effort= .=C2=A0 Otherwise, it may be hard to get a protocol model writer to design = the YANG model in a way that is not fully usable on any current devices.
As an illustration, an RFC published combined ietf-interfaces model may loo= k like this:

module: ietf-interfaces-combined
=C2=A0 =C2=A0 +--rw interfaces
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw interface* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw description?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw enabled?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw link-up-down-trap-enable?=C2=A0 = =C2=A0enumeration {if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro oper-status=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro last-change? yang:date-and-time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro if-index=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro phys-address? yang:phys-address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro higher-layer-if*=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro lower-layer-if*=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro speed?=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro discontinuity-time=C2= =A0 =C2=A0 yang:date-and-time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-broadcast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-multicast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unknown-protos?=C2= =A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-broadcast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-multicast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32

The extra generated model would look like this:

module: ietf-interfaces-combined-state
=C2=A0 =C2=A0 +--ro interfaces-state
=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro interface* [name]
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro name=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro description?=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro type=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro enabled?=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro link-up-down-trap-enable?=C2=A0 = =C2=A0enumeration {if:if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro oper-status=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro last-change? yang:date-and-time =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro if-index=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:if-mib}?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro phys-address? yang:phys-address =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro higher-layer-if* if:interface-ref<= br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro lower-layer-if* if:interface-ref =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro speed?=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro statistics
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro discontinuity-time=C2= =A0 =C2=A0 yang:date-and-time
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-broadcast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-multicast-pkts?=C2= =A0 =C2=A0 yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro in-unknown-protos?=C2= =A0 =C2=A0 yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-octets?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-unicast-pkts?=C2= =A0 =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-broadcast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-multicast-pkts?= =C2=A0 =C2=A0yang:counter64
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-discards?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro out-errors?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32

Servers that support operational-state would just implement ietf-interfaces= -combined

Servers that don't support operational-state could implement ietf-inter= faces-combined and ietf-interfaces-combined-state, probably not implem= enting the duplicate config false leaves under the interfaces config tree.= =C2=A0 Deviations could also be auto-generated to remove the config false l= eaves from the config tree so that they are only in the state tree.

Of course, Clients may need to support both schemes depending on what types= of devices they are interacting with.

Finally, I've illustrated this using ietf-interfaces, but I'm not a= ctually proposing immediately changing that model.=C2=A0 I was more thinkin= g about IETF protocols that in the process of working on their YANG models.=

Rob


Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Implementations can = use
whatever transformation tricks they want in order to comply with
different standards, but the standard modules should be very clear.






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


--001a114c877c91307d0545d47a49-- From nobody Wed Jan 11 09:21:26 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED4FA12960B; Wed, 11 Jan 2017 09:21:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yw_VfXH3cu7W; Wed, 11 Jan 2017 09:21:19 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BBE52129610; Wed, 11 Jan 2017 09:21:18 -0800 (PST) Received: from [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c] (unknown [IPv6:2a01:5e0:29:fffe:284d:7311:9a10:1f9c]) by mail.nic.cz (Postfix) with ESMTPSA id 5261E60CAF; Wed, 11 Jan 2017 18:21:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484155277; bh=U3IOHnchTbxuDyoCYtO8p6ftJuvst5WUq2IlEkVPYUI=; h=From:Date:To; b=bmCtn8zy+UTK8DwN7hzZRM5HLhMekrxP9IKcQ49LqhqfbkL7lLhmM6XSvrMUuYE9J U5hKviRw31wIwezAYAQ3QSxypaRUfu1OgqctoBTkOm++T8W+58I0eBxT2ekFxBS1yP p/QbNA0KEYsb50zpbdW89VpYzCIPYHsbS6P3DWWg= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 11 Jan 2017 18:21:19 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:21:21 -0000 > On 11 Jan 2017, at 17:56, Andy Bierman wrote: >=20 > Hi, >=20 >=20 > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton = wrote: >=20 >=20 > On 11/01/2017 09:22, Martin Bjorklund wrote: > Andy Bierman wrote: > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen = wrote: >=20 > I think it is better to have a human decide what is in the module > instead of relying on a pyang plugin to generate some additional = module > that follows some simplistic pattern. > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because = it=E2=80=99s not tricky ;) >=20 >=20 > The client and server developers still need to know about this > auto-generated module > and implement it. Operators might have to know about it to use it. > My idea is not to auto generate models on the fly. >=20 > My aim is to allow folks to start writing models in the desired long = term format (i.e. combined config and state tree) with the model = designer being able to assume the existence of the operational state = datastore. >=20 >=20 >=20 > I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore? What does the value mean if pre-configured? configured? > operational? Will the auto-generated objects be exactly correct > and never need any alterations or additional text? > They still need to be used by developers and YANG tools. Right, this is one problem of this "deduplication": even if two nodes - = one config and the other state - have the same name or even type (which = is not always the case, as we know), their semantics is often different. = An IP address in configuration means a manually configured address = whereas in state it may come from any source. So writing sensible = descriptions will become tricky. >=20 > Is is that realistic to force the config structure and operational = structure > to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys. This is completely = unsupported > so separate /foo and /foo-state trees will still exist. I agree. Lada >=20 > IMO this combination of trees needs to be proven. > Take ietf-interfaces and show how much better it will work > if the /interfaces and /interfaces-state trees were combined. >=20 >=20 > Andy >=20 >=20 > The tooling would be there to statically generate the extra foo-state = config false node modules for servers that don't support the operational = state datastore. This could be done once, and the extra foo-state = modules committed to the github YANG respository in the same way that = models are extracted from IETF RFCs today. >=20 > The aim here is that the single model being produced by IETF would be = usable both by new client/servers that support an operational state = datastore, and also by existing NETCONF client/servers that don't = implement an operational state datastore. >=20 > I'm not proposing that as a long term solution, but as a path to make = it easier for folk to migrate, and to not slow down the model writing = effort. Otherwise, it may be hard to get a protocol model writer to = design the YANG model in a way that is not fully usable on any current = devices. >=20 > As an illustration, an RFC published combined ietf-interfaces model = may look like this: >=20 > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 >=20 > The extra generated model would look like this: >=20 > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 >=20 > Servers that support operational-state would just implement = ietf-interfaces-combined >=20 > Servers that don't support operational-state could implement = ietf-interfaces-combined and ietf-interfaces-combined-state, probably = not implementing the duplicate config false leaves under the interfaces = config tree. Deviations could also be auto-generated to remove the = config false leaves from the config tree so that they are only in the = state tree. >=20 > Of course, Clients may need to support both schemes depending on what = types of devices they are interacting with. >=20 > Finally, I've illustrated this using ietf-interfaces, but I'm not = actually proposing immediately changing that model. I was more thinking = about IETF protocols that in the process of working on their YANG = models. >=20 > Rob >=20 >=20 > Exactly. I agree that this is a real hack. Implementations can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very clear. >=20 >=20 >=20 >=20 >=20 >=20 > /martin > _______________________________________________ > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Jan 11 09:34:33 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 543BE12953C for ; Wed, 11 Jan 2017 09:34:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQPGeA5UyKps for ; Wed, 11 Jan 2017 09:34:27 -0800 (PST) Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 048A6127078 for ; Wed, 11 Jan 2017 09:34:27 -0800 (PST) Received: by mail-qk0-x231.google.com with SMTP id u25so600097174qki.2 for ; Wed, 11 Jan 2017 09:34:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=yD7Cufkwr889CeKjSVHNK1jYlgkn7u3JH8M03UkdTpM=; b=pzHEXbJYP2MF/0yUlslIfnzWK6zLk+PFMoBjegP7nD9iDfx7aNxQ9kEosNo75pOm4N Oe5jycbcfHQ0TtdmagVwFj0fECBb/Ete49s5YR+3vC18UCF2ZW9/rHQu/se4NRpB8b96 gWiOwuJF0gV9VDvXKRZzHjaTr8lIrzFUfwh2QLEAj8c1bpjwQeRkKZRpWEp9c4V3ERm0 g1B0fgSir2+D6MR2PZWWj81Oyl9k7tCyWziW4Eq3G3bYNUHlfczTfmWhsi99j/SZ3pbH gp4N1e+cLdx4SuaYsGa0JuXeO44SWfr1kf9Uo7BcjqxJ+c5LFUj9PbdD9Ji2YZdvuvHw J3cw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=yD7Cufkwr889CeKjSVHNK1jYlgkn7u3JH8M03UkdTpM=; b=L28rB3/9jURWbS3L2wyfSDA7E7uL6irjVkmzQN8EW29Uiub0P6FWyT4c2naKaeq2vC lJUfFDkjhirZIC6LNqTYs6eDVtPuIWq+BKqVJXfwqqqqgRRBIeqsGLjUEmybsdE96gUs E/zybZqMXhf0lbFvHVWCPNoA8VoHqYlpu/Ve2HPisMR0cD8FMDeqx2YIY+iEL4cX2tYI We6uDJXBuIA7u8UZWhD4d1IrY0SRNEa/WOeEYNyK8R3TMEV2iRiUHlvfEUFCinqH7UXq pJPsGvjY8oTQPRHehcODX8ZJ5YWhvRKxkRh2HzyJveGXUZ0xmXtKHVCPHuOLxWfE3GKy Ditg== X-Gm-Message-State: AIkVDXKdpu56zXxM+bwb92HmAIWxAyNBgwtltFOUH6lDu4WKQ5pmIPhieDK6u33JTXQxrfNH2fVp8nMx9SY9gQ== X-Received: by 10.55.152.4 with SMTP id a4mr8788619qke.69.1484156066192; Wed, 11 Jan 2017 09:34:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 09:34:25 -0800 (PST) In-Reply-To: <20170111.102729.1180268284224378559.mbj@tail-f.com> References: <20170111.102729.1180268284224378559.mbj@tail-f.com> From: Andy Bierman Date: Wed, 11 Jan 2017 09:34:25 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=94eb2c07ecfa1df3990545d503a2 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 17:34:30 -0000 --94eb2c07ecfa1df3990545d503a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 1:27 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen > wrote: > > > > > Hi Andy, > > > > > > > > > > > > > Until the basic show-stoppers are solved, the redundant opstate > objects > > > are not important. > > > > > > > Removing the foo-state objects means they are now invisible wrt/ YA= NG > > > constraints > > > > > > > (must, when, leafref, min/max, etc). IMO this is a show-shopper. > YANG > > > can only cross-reference > > > > > > > YANG statements. Invisible opstate hiding behind a datastore label > > > seems elegant > > > > > > > wrt/ , but it looks like a disaster wrt/ YANG. > > > > > > > > > > > > Nothing has been removed. All the config false nodes are still > available, > > > but now they=E2=80=99re no longer separated into a top-level /foo-sta= te tree > for > > > the sole purpose of being able to report opstate for system-generated > > > objects. Likewise, all YANG constraints continue to work, but rather > than > > > reference nodes in /foo-state, they=E2=80=99ll now reference nodes in= /foo. > Does > > > this make sense? Do you still have an issue? > > > > > > > > > > > > > > > > > > > This does not work. There are no config=3Dfalse nodes if they are overl= aid > > onto the config=3Dtrue nodes. > > There is no way to say in the YANG XPath that you mean the configured > value > > of /foo > > vs. the operational value of /foo. There is just 1 leaf that YANG says > has > > 0 or 1 instance > > (and therefore 0 or 1 value). > > This is correct. But note that YANG doesn't allow config true nodes > to refer to config false nodes anyway, so this is less of an issue. > Also note that draft-ietf-netmod-revised-datastores-00 proposes that > semantic constraints don't apply to the operational-state datastore > (see section 5.3). > So valid YANG constraints applying to config=3Dfalse nodes would now be ignored? Just put in the YANG module to fool people? How can you propose to ignore YANG constraints on operational data? > > BTW, it has been suggested before to add a function similar to the > XSLT 1.0 function "document", that could be used to refer to nodes in > other documents (or rather other datastores in our case). > > So a new version of YANG is needed to support combining config and oper into 1 tree? > > /martin > Andy --94eb2c07ecfa1df3990545d503a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 11, 2017 at 1:27 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 4:53 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> > Hi Andy,
> >
> >
> >
> > > Until the basic show-stoppers are solved, the redundant opst= ate objects
> > are not important.
> >
> > > Removing the foo-state objects means they are now invisible = wrt/ YANG
> > constraints
> >
> > > (must, when, leafref, min/max, etc).=C2=A0 IMO this is a sho= w-shopper.=C2=A0 YANG
> > can only cross-reference
> >
> > > YANG statements.=C2=A0 Invisible opstate hiding behind a dat= astore label
> > seems elegant
> >
> > > wrt/ <get>, but it looks like a disaster wrt/ YANG. > >
> >
> >
> > Nothing has been removed.=C2=A0 All the config false nodes are st= ill available,
> > but now they=E2=80=99re no longer separated into a top-level /foo= -state tree for
> > the sole purpose of being able to report opstate for system-gener= ated
> > objects.=C2=A0 Likewise, all YANG constraints continue to work, b= ut rather than
> > reference nodes in /foo-state, they=E2=80=99ll now reference node= s in /foo.=C2=A0 =C2=A0Does
> > this make sense?=C2=A0 Do you still have an issue?
> >
> >
> >
> >
> >
>
> This does not work. There are no config=3Dfalse nodes if they are over= laid
> onto the config=3Dtrue nodes.
> There is no way to say in the YANG XPath that you mean the configured = value
> of /foo
> vs. the operational value of /foo.=C2=A0 There is just 1 leaf that YAN= G says has
> 0 or 1 instance
> (and therefore 0 or 1 value).

This is correct.=C2=A0 But note that YANG doesn't allow config true nod= es
to refer to config false nodes anyway, so this is less of an issue.
Also note that draft-ietf-netmod-revised-datastores-00 proposes that semantic constraints don't apply to the operational-state datastore
(see section 5.3).


So va= lid YANG constraints applying to config=3Dfalse nodes would now be
ignored?=C2=A0 Just put in the YANG module to fool people?
How = can you propose to ignore YANG constraints on operational data?
= =C2=A0

BTW, it has been suggested before to add a function similar to the
XSLT 1.0 function "document", that could be used to refer to node= s in
other documents (or rather other datastores in our case).


So a new version of YANG is needed to support combin= ing
config and oper into 1 tree?
=C2=A0

/martin


<= /div>
Andy

--94eb2c07ecfa1df3990545d503a2-- From nobody Wed Jan 11 12:32:35 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9EF6A129449 for ; Wed, 11 Jan 2017 12:32:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYuK0FzzgcPr for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) Received: from mail-qk0-x22e.google.com (mail-qk0-x22e.google.com [IPv6:2607:f8b0:400d:c09::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 879A31289B0 for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) Received: by mail-qk0-x22e.google.com with SMTP id s140so199021777qke.0 for ; Wed, 11 Jan 2017 12:32:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6njUCWLqpIBFm8dv/R+vbuCl6eW1/VzdtPIBvf1qEP4=; b=YqIH2dsK2W1yABEwmlppGwFe7KTooi1grlqt3655ZijaVhAe3DnH16mF34IYnH8vTa 6MSfdVMZ5Nrm+7lvyT2m0tNl9oPW63451gZHQDqRyoSWxlfLSbFeRw9HcWXemqbP1Oyx x0bYx681C6DZU+cVmkTPoZezgjAlmJUPP9sz+/EIpXBdS85bwRhwre6ylC2GY/UGnEcw lwRy2zuY+mBma+I7DeDNHvTLdzNYPwC0jy6fr0s/gt5LTGWbgcXrJgb+VqBBG5gcXV7l 7TpuQvhXpXMx1elRs4M8ZyIjAc7hUlvQbzw8tRzqgt022TtHCYj+CLJgiVpQjqYrSd1G qLag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6njUCWLqpIBFm8dv/R+vbuCl6eW1/VzdtPIBvf1qEP4=; b=mvYrUxN6R4NRabBii5i4LmHsPpp2G5GzUdgPI9gcZH4rgsxxctmthQdVrc8ouOm7DN bgNjcul/q1VLIUNozQDrLreCbUY+fmVHujMOGskVlTZI++hOJ2TABC5912CAmdlE/Ucf ReC6S9Ai5gLlb2rr8OjtOQrGHoibx2MPaqNupSBck3AUyiPSsjtfa0OLssSdYUBgshTa KvyMbW8vkqj/IV1ZAspwDJobJahb/ROGra209+RBTGYnXeAZY+1/ZYlznKjq7WH+k2TH Td5J8f5p3lg05IhOJKC0CL2uUEqhT8SGG8KWri/Z0N9F7xPQy5B30RZ4U35gxlqMv0nq jpoA== X-Gm-Message-State: AIkVDXIU77fcVqG3Lf+filDpu/J7v0s9ubkZvPOE9m5dkbOywXERRmjAjdAVgZlSORo0eIt2afWdOvVQx19PQw== X-Received: by 10.55.22.97 with SMTP id g94mr9734388qkh.287.1484166746505; Wed, 11 Jan 2017 12:32:26 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.142.5 with HTTP; Wed, 11 Jan 2017 12:32:25 -0800 (PST) In-Reply-To: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Andy Bierman Date: Wed, 11 Jan 2017 12:32:25 -0800 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=001a114967eab6c6070545d77fb8 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:32:31 -0000 --001a114967eab6c6070545d77fb8 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka wrote: > > > On 11 Jan 2017, at 17:56, Andy Bierman wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional module > > that follows some simplistic pattern. > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because = it=E2=80=99s not tricky > ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired long > term format (i.e. combined config and state tree) with the model designer > being able to assume the existence of the operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two nodes - > one config and the other state - have the same name or even type (which i= s > not always the case, as we know), their semantics is often different. An = IP > address in configuration means a manually configured address whereas in > state it may come from any source. So writing sensible descriptions will > become tricky. > > > > > Is is that realistic to force the config structure and operational > structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra foo-state > config false node modules for servers that don't support the operational > state datastore. This could be done once, and the extra foo-state module= s > committed to the github YANG respository in the same way that models are > extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF would be > usable both by new client/servers that support an operational state > datastore, and also by existing NETCONF client/servers that don't impleme= nt > an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to make i= t > easier for folk to migrate, and to not slow down the model writing effort= . > Otherwise, it may be hard to get a protocol model writer to design the YA= NG > model in a way that is not fully usable on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces model may > look like this: > > > OK -- let me see if I understand the value of combining ietf-interfaces. Here is the starting tree: +--rw interfaces | +--rw interface* [name] | +--rw name string | +--rw description? string | +--rw type identityref | +--rw enabled? boolean | +--rw link-up-down-trap-enable? enumeration +--ro interfaces-state +--ro interface* [name] +--ro name string +--ro type identityref +--ro admin-status enumeration +--ro oper-status enumeration +--ro last-change? yang:date-and-time +--ro if-index int32 +--ro phys-address? yang:phys-address +--ro higher-layer-if* interface-state-ref +--ro lower-layer-if* interface-state-ref +--ro speed? yang:gauge64 +--ro statistics +--ro discontinuity-time yang:date-and-time +--ro in-octets? yang:counter64 +--ro in-unicast-pkts? yang:counter64 +--ro in-broadcast-pkts? yang:counter64 +--ro in-multicast-pkts? yang:counter64 +--ro in-discards? yang:counter32 +--ro in-errors? yang:counter32 +--ro in-unknown-protos? yang:counter32 +--ro out-octets? yang:counter64 +--ro out-unicast-pkts? yang:counter64 +--ro out-broadcast-pkts? yang:counter64 +--ro out-multicast-pkts? yang:counter64 +--ro out-discards? yang:counter32 +--ro out-errors? yang:counter32 So these are the objects that would no longer be duplicated: - name - type Neither one is supposed to have a different value in operational state vs configuration. - enabled - link-up-down-trap-enable These 2 could be different in operational state I suppose. An RPC can provide the operational value without changing the YANG module rpc get-oper-value { input { leaf node { type instance-identifier; description "the config=3Dtrue node to check"; } } output { anydata value { description "contains 1 child node matching the input 'node' parameter. The value of the node is the current operational value." } } } /if:interfaces/if:interface[if:name=3D'eth0']/enabled false I don't need to change the YANG module at all to support operational state. Andy > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, probably not > implementing the duplicate config false leaves under the interfaces confi= g > tree. Deviations could also be auto-generated to remove the config false > leaves from the config tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on what > types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm not > actually proposing immediately changing that model. I was more thinking > about IETF protocols that in the process of working on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --001a114967eab6c6070545d77fb8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <= lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.= com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional modul= e
> that follows some simplistic pattern.
> It may be simple, but I=E2=80=99m thinking that=E2=80=99s only because= it=E2=80=99s not tricky=C2=A0 ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.=C2=A0 Operators might have to know about it to use i= t.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long t= erm format (i.e. combined config and state tree) with the model designer be= ing able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore?=C2=A0 What does the value mean if pre-configured? configure= d?
> operational?=C2=A0 Will the auto-generated objects be exactly correct<= br> > and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two n= odes - one config and the other state - have the same name or even type (wh= ich is not always the case, as we know), their semantics is often different= . An IP address in configuration means a manually configured address wherea= s in state it may come from any source. So writing sensible descriptions wi= ll become tricky.

>
> Is is that realistic to force the config structure and operational str= ucture
> to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys.=C2=A0 This is completely unsup= ported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state = config false node modules for servers that don't support the operationa= l state datastore.=C2=A0 This could be done once, and the extra foo-state m= odules committed to the github YANG respository in the same way that models= are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be = usable both by new client/servers that support an operational state datasto= re, and also by existing NETCONF client/servers that don't implement an= operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to m= ake it easier for folk to migrate, and to not slow down the model writing e= ffort.=C2=A0 Otherwise, it may be hard to get a protocol model writer to de= sign the YANG model in a way that is not fully usable on any current device= s.
>
> As an illustration, an RFC published combined ietf-interfaces model ma= y look like this:
>


OK -- let me see if= I understand the value of combining ietf-interfaces.

<= div>
Here is the starting tree:


= 
     =
+--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-o=
ctets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects tha= t would no longer be duplicated:

=C2=A0 =C2=A0 - n= ame
=C2=A0 =C2=A0 - type

Neither one is = supposed to have a different value in operational state vs configuration.

=C2=A0 =C2=A0- enabled
=C2=A0 =C2=A0- lin= k-up-down-trap-enable

These 2 could be different i= n operational state I suppose.
An RPC can provide the operational= value without changing the YANG module

=C2=A0 =C2= =A0 rpc get-oper-value {
=C2=A0 =C2=A0 =C2=A0 input {
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0leaf node {=C2=A0
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 type instance-identifier;=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "the config= =3Dtrue node to check";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 }=
=C2=A0 =C2=A0 =C2=A0 }
=C2=A0 =C2=A0 =C2=A0 output {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 anydata value {
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description=C2=A0
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0"contains 1 chi= ld node matching the input 'node' parameter.
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The value of the node is the = current operational value."
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 }
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}

=C2=A0 =C2=A0<rpc>
=C2=A0 =C2= =A0 =C2=A0 <get-oper-value>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 <node>/if:interfaces/if:interface[if:name=3D'eth0']/enabl= ed</node>
=C2=A0 =C2=A0 =C2=A0 </get-oper-value>
=C2=A0 =C2=A0</rpc>


=C2= =A0 =C2=A0<rpc-reply>
=C2=A0 =C2=A0 =C2=A0 =C2=A0<value&= gt;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <if:enabled>false<= ;/if:enabled>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 </value>
=
=C2=A0 =C2=A0 =C2=A0</rpc-reply>

I don&= #39;t need to change the YANG module at all to support operational state.


Andy

=C2=A0=
> module: ietf-interfaces-combined
>=C2=A0 =C2=A0 =C2=A0+--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw link-up-down-trap-enable= ?=C2=A0 =C2=A0enumeration {if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? yang:date-a= nd-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? yang:phys-= address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if*=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if*=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontinuity-ti= me=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicast-pkts?= =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadcast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multicast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknown-proto= s?=C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octets?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unicast-pkts= ?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broadcast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multicast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-errors?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>=C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro description?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 identityref=
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro enabled?=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro link-up-down-trap-enable= ?=C2=A0 =C2=A0enumeration {if:if-mib}?
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? yang:date-a= nd-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:if-mib}?<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? yang:phys-= address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if* if:inte= rface-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if* if:inter= face-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:gauge64 >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontinuity-ti= me=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicast-pkts?= =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadcast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multicast-pkt= s?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknown-proto= s?=C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octets?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unicast-pkts= ?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broadcast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multicast-pk= ts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-discards?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-errors?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
> Servers that support operational-state would just implement ietf-inter= faces-combined
>
> Servers that don't support operational-state could implement ietf-= interfaces-combined and ietf-interfaces-combined-state, probably not i= mplementing the duplicate config false leaves under the interfaces config t= ree.=C2=A0 Deviations could also be auto-generated to remove the config fal= se leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what = types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm = not actually proposing immediately changing that model.=C2=A0 I was more th= inking about IETF protocols that in the process of working on their YANG mo= dels.
>
> Rob
>
>
> Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Implementations= can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear. >
>
>
>
>
>
> /martin
> _______________________________________________
> 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

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






--001a114967eab6c6070545d77fb8-- From nobody Wed Jan 11 12:33:29 2017 Return-Path: X-Original-To: netconf@ietf.org Delivered-To: netconf@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 298261289B0; Wed, 11 Jan 2017 12:33:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.40.3 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <148416680016.8123.15881692980518651372.idtracker@ietfa.amsl.com> Date: Wed, 11 Jan 2017 12:33:20 -0800 Archived-At: Cc: netconf@ietf.org Subject: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:33:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Configuration of the IETF. Title : Zero Touch Provisioning for NETCONF or RESTCONF based Management Authors : Kent Watsen Mikael Abrahamsson Filename : draft-ietf-netconf-zerotouch-12.txt Pages : 76 Date : 2017-01-11 Abstract: This draft presents a secure technique for establishing a NETCONF or RESTCONF connection between a newly deployed device, configured with just its factory default settings, and its deployment specific network management system (NMS). The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netconf-zerotouch/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-netconf-zerotouch-12 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netconf-zerotouch-12 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 Wed Jan 11 12:40:57 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 132FA129583 for ; Wed, 11 Jan 2017 12:40:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w9afyo5ngy-l for ; Wed, 11 Jan 2017 12:40:53 -0800 (PST) Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0100.outbound.protection.outlook.com [104.47.41.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 76FB1129449 for ; Wed, 11 Jan 2017 12:40:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=zt44QyYgQGgJ4G4djzdzMsIL+LkXa+len6za0VE06ng=; b=LfGuzPwYmhkTPDvNCKdm/XeScjLGw1RpCRTXhyOPchXbelnVYLYN03l7l1GrwkxvyCs+rTTi5LkNJPIlqvoEWbCOm+kophRg96lmQshiaUFY9Auc1GXUPQIdGkoWW+/I8D92RajJ4zT0V/v1BUlOshnUpK+hEwI30SLklrjUA3A= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.845.6; Wed, 11 Jan 2017 20:40:52 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 20:40:51 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-12.txt Thread-Index: AQHSbEoVc8ZG3QSAjEi/CDZmqFmyWKEzaZiA Date: Wed, 11 Jan 2017 20:40:51 +0000 Message-ID: References: <148416680016.8123.15881692980518651372.idtracker@ietfa.amsl.com> In-Reply-To: <148416680016.8123.15881692980518651372.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 479b94b5-abc1-418b-5fd3-08d43a6221bf x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:eMAHx5VPD9XhewrVyErYwgTHvvdUUNZg+PNjgLI5RXYWAJO0trL0dM4hBK9CF4zSg+y0uZL3zW2u8qDc23QN8GOWSf3AgRVun4fDlK9nARO0bXJP3tKYy97+mx8tP0CEJFEV+PvtLDK0HQ3V/xJ16+chONfCwjpiLL2XjyI60uW3AZEYo/FKXkllf0wJi2E/nstMvvVanTxbemXdalTEJotdLtdo3AfP15lZbBVHLPWURD+a5Ec0kj7s6IAg1R5CReUIn1N/oSx9pphIUwxg7a2DEUkAvRnNwZcHW/X4BOubBZg+Vmf4eVX51x3joL+xFq+owCe9wvRycRmR1OSooIUMNKXrsi88r03G9wbPYlcohqNYgLVtZOLBBmNNIOMWCiLXMUQuLe47+5IR/0SBiwCgqzlS/zJrv0YWMMqfoY+D8QIrjKTZD6802HkV127ROuH5oyLK/taDAno7m3ZpRw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39840400002)(39860400002)(39410400002)(39450400003)(39850400002)(377424004)(199003)(189002)(53754006)(229853002)(101416001)(3846002)(97736004)(6486002)(450100001)(2501003)(77096006)(6506006)(6436002)(4001350100001)(76176999)(82746002)(83506001)(50986999)(2906002)(54356999)(83716003)(6916009)(102836003)(6116002)(2900100001)(92566002)(3660700001)(8936002)(122556002)(189998001)(36756003)(2950100002)(5660300001)(81166006)(8676002)(66066001)(6306002)(230783001)(99286003)(5640700003)(107886002)(6512007)(25786008)(86362001)(2351001)(305945005)(105586002)(7736002)(106356001)(106116001)(38730400001)(3280700002)(81156014)(33656002)(110136003)(1730700003)(68736007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <08524346536DFB42A8236EB2D81BA69D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 20:40:51.1006 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Netconf] I-D Action: draft-ietf-netconf-zerotouch-12.txt X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 20:40:56 -0000 SGkgYWxsLA0KDQpUaGlzIHVwZGF0ZWQgaXMgcHJpbWFyaWx5IG1vdGl2YXRlZCBieSBtZSB3YW50 aW5nIHRvIGNsb3NlIG9uIGFuIGl0ZW0gcmFpc2VkIGR1cmluZyB0aGUgSUVURiA5NyBtZWV0aW5n LCB3aGljaCBpcyBob3cgdG8gZGVmaW5lIHRoZSBlbmNvZGluZyBmb3IgWUFORy1tb2RlbGVkIGFy dGlmYWN0cyAoZS5nLiwgZmlsZXMsIG5vdCB1c2VkIGZvciBjb25maWd1cmF0aW9uKS4gIEhvd2V2 ZXIsIHdoZW4gSSB3ZW50IHRvIGNpdGUgdGhlIGxvY2F0aW9uIGluIHRoZSBkcmFmdCwgSSBkaXNj b3ZlcmVkIHRoYXQgYSB0eXBvIGluIC0xMSBwcmV2ZW50ZWQgdGhlIGV4YW1wbGVzIHRvIGJlIGxv YWRlZCBpbnRvIHRoZSBkcmFmdCwgd2hpY2ggd291bGQgbWFrZSBkaXNjdXNzaW5nIHRoZW0gcmF0 aGVyIGRpZmZpY3VsdC4NCg0KSG93ZXZlciwgaW4gdGhlIGNvdXJzZSBvZiBmaXhpbmcgdGhpcyBp c3N1ZSwgSSBhbHNvIGNoYXNlZCBkb3duIGEgZmV3IG90aGVyIGxvb3NlIGVuZHMuICBIZXJl4oCZ cyB0aGUgY29tcGxldGUgbGlzdDoNCg0KICAgbyAgZml4ZWQgdHlwbyB0aGF0IHByZXZlbnRlZCBB cHBlbmRpeCBCIGZyb20gbG9hZGluZyB0aGUgZXhhbXBsZXMNCiAgICAgIGNvcnJlY3RseS4NCg0K ICAgbyAgZml4ZWQgbW9yZSB5YW5nIHZhbGlkYXRpb24gaXNzdWVzIGZvdW5kIGJ5DQogICAgICBJ RVRGWUFOR1BhZ2VDb21waWxhdGlvbi4gIG5vdGU6IGFnYWluLCB0aGVzZSBpc3N1ZXMgd2VyZSBO T1QgZm91bmQNCiAgICAgIGJ5IHB5YW5nIC0taWV0ZiBvciBieSB0aGUgc3VibWlzc2lvbi10aW1l IHZhbGlkYXRvci4uLg0KDQogICBvICB1cGRhdGVkIGEgZmV3IG9mIHRoZSBub3RpZmljYXRpb24g ZW51bWVyYXRpb25zIHRvIGJlIG1vcmUNCiAgICAgIGNvbnNpc3RlbnQgd2l0aCB0aGUgb3RoZXIg ZW51bWVyYXRpb25zIChmb2xsb3dpbmcgdGhlIHdhcm5pbmcvDQogICAgICBlcnJvciBwYXR0ZXJu KS4NCg0KICAgbyAgdXBkYXRlZCB0aGUgaW5mb3JtYXRpb24gdHlwZSBhcnRpZmFjdCB0byBzdGF0 ZSBob3cgaXQncyBlbmNvZGVkLA0KICAgICAgbWF0Y2hpbmcgdGhlIGxhbmd1YWdlIHRoYXQgd2Fz IGluIEFwcGVuZGl4IEIuDQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KQSBOZXcgSW50ZXJuZXQt RHJhZnQgaXMgYXZhaWxhYmxlIGZyb20gdGhlIG9uLWxpbmUgSW50ZXJuZXQtRHJhZnRzIGRpcmVj dG9yaWVzLg0KVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgTmV0d29yayBDb25maWd1 cmF0aW9uIG9mIHRoZSBJRVRGLg0KDQogICAgICAgIFRpdGxlICAgICAgICAgICA6IFplcm8gVG91 Y2ggUHJvdmlzaW9uaW5nIGZvciBORVRDT05GIG9yIFJFU1RDT05GIGJhc2VkIE1hbmFnZW1lbnQN CiAgICAgICAgQXV0aG9ycyAgICAgICAgIDogS2VudCBXYXRzZW4NCiAgICAgICAgICAgICAgICAg ICAgICAgICAgTWlrYWVsIEFicmFoYW1zc29uDQoJRmlsZW5hbWUgICAgICAgIDogZHJhZnQtaWV0 Zi1uZXRjb25mLXplcm90b3VjaC0xMi50eHQNCglQYWdlcyAgICAgICAgICAgOiA3Ng0KCURhdGUg ICAgICAgICAgICA6IDIwMTctMDEtMTENCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRyYWZ0IHByZXNl bnRzIGEgc2VjdXJlIHRlY2huaXF1ZSBmb3IgZXN0YWJsaXNoaW5nIGEgTkVUQ09ORiBvcg0KICAg UkVTVENPTkYgY29ubmVjdGlvbiBiZXR3ZWVuIGEgbmV3bHkgZGVwbG95ZWQgZGV2aWNlLCBjb25m aWd1cmVkIHdpdGgNCiAgIGp1c3QgaXRzIGZhY3RvcnkgZGVmYXVsdCBzZXR0aW5ncywgYW5kIGl0 cyBkZXBsb3ltZW50IHNwZWNpZmljDQogICBuZXR3b3JrIG1hbmFnZW1lbnQgc3lzdGVtIChOTVMp Lg0KDQoNClRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlz Og0KaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRjb25mLXpl cm90b3VjaC8NCg0KVGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQgdmVyc2lvbiBhdmFpbGFibGUgYXQ6 DQpodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRjb25mLXplcm90b3Vj aC0xMg0KDQpBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6 DQpodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1uZXRjb25mLXpl cm90b3VjaC0xMg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2Yg bWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24NCnVudGlsIHRoZSBodG1saXplZCB2 ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCkludGVy bmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3VzIEZUUCBhdDoNCmZ0cDov L2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvDQoNCl9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQpOZXRjb25mIG1haWxpbmcgbGlzdA0KTmV0Y29uZkBp ZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoN Cg0K From nobody Wed Jan 11 14:32:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1A7D12959D for ; Wed, 11 Jan 2017 14:32:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s8rg359u6VyC for ; Wed, 11 Jan 2017 14:32:13 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0107.outbound.protection.outlook.com [104.47.32.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 963A7129439 for ; Wed, 11 Jan 2017 14:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=fLKM7N7QKkZ65OBUrfnrBgicuz6+ksT2aw3ulTbJtOw=; b=MhhdUTsA0GstoLIsu62DTrJbYfDrXlTYyHMQCdDhzeOuMosx/ZHhUVW8oOYqbpTH54tqddvn7nGfRK3rBSZQwF5hhuTFGthY8N0Ey5zVxPXQtfTdjL/NaWboydLQs0PCEnLrpVYIcbuzD9t7MCmrIGqv2AhZvXSzrOuWtV/C6NU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.829.4; Wed, 11 Jan 2017 22:32:08 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0829.017; Wed, 11 Jan 2017 22:32:08 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbFqKd8kiIonGX0KdwkHayr+msg== Date: Wed, 11 Jan 2017 22:32:07 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 8051fb13-5125-4101-860f-08d43a71ad62 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:DACsfFUOL6URPn72Nq+ToukIjMEofWDcAk2+ZIVkowZXTp7T5KdRXBlqFLsUQLGPK4RnlM7HR+Xk0+X0JCSRmcgkGAi9DTsqoK7/sR0K7iY7zcz4yV6dwfhgW2MFp+FC/N4bGRnID3IqPKSDle9syh+fUb2Hw/sCdBQNP3XYCcCvaM/76FizfSJ9zbuu/YIAw/8EeWgBRwfWQpYX4Dlohin2dfnqhkaXnKErxHf3ZvTGI/mIbU+fYkvOWnKga10L3+8p/SPnMemiQlg7YIWjjPvXMew8WsKCEIKhyfGC7yvbsJAwJ7zoPMnPJ12dluoA5ZBFGGjRK9zGEBslcl5CNg1R60J8/Iv8oadkMsAfPAUztG4Men0iJpTShZcpOl2OGkznvwF1Q6TXQy5bpQhrnSf3F4sZv1QVAaZsUrREXHgHBWIj3d2YYJPRUDrYYbWwO/jWSdkOYF9g6OQ6aEs6Tw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 01842C458A x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(53754006)(189002)(199003)(66066001)(5660300001)(101416001)(92566002)(6916009)(110136003)(2501003)(38730400001)(54356999)(68736007)(33656002)(50986999)(2351001)(189998001)(8676002)(122556002)(8936002)(105586002)(106356001)(81156014)(107886002)(106116001)(81166006)(102836003)(3846002)(6116002)(97736004)(2900100001)(1730700003)(2906002)(305945005)(25786008)(3280700002)(36756003)(3660700001)(6506006)(6512007)(86362001)(83716003)(5640700003)(82746002)(7736002)(99286003)(6436002)(6306002)(83506001)(77096006)(6486002)(450100001)(4001350100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <220C711AAF418E4EB58947E2B6F6E15A@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jan 2017 22:32:07.8761 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Subject: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:32:16 -0000 SGkgQWxsLA0KDQpIZXJlIGlzIHRoZSBpc3N1ZSBtZW50aW9uZWQgaW4gbXkgY29tbWVudHMganVz dCBub3cgd2hlbiBwb3N0aW5nIC0xMiBvZiB0aGUgemVyb3RvdWNoIGRyYWZ0LCB3aGljaCBpcyBo b3cgdG8gZW5jb2RlIFlBTkctbW9kZWxlZCBhcnRpZmFjdHM/IChlLmcuLCBmaWxlcywgbm90IHVz ZWQgZm9yIGNvbmZpZ3VyYXRpb24pLiAgVG8gYmUgY2xlYXIsIGh0dHBzOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLW5ldGNvbmYtemVyb3RvdWNoLTEyI3NlY3Rpb24tNC4xIHNheXM6 DQoNCiAgIFRoZSBpbmZvcm1hdGlvbiB0eXBlIGFydGlmYWN0IGlzIFlBTkcgbW9kZWxlZCBkYXRh IGZvcm1hbGx5IGRlZmluZWQNCiAgIGJ5IHRoZSAiaW5mb3JtYXRpb24tdHlwZSIgY2hvaWNlIG5v ZGUgaW4gU2VjdGlvbiA5LjIgYW5kIGNhbiBiZQ0KICAgZW5jb2RlZCB1c2luZyBhbnkgc3RhbmRh cmQgWUFORyBlbmNvZGluZyAoZS5nLiwgWE1MLCBKU09OKS4gIFRoaXMNCiAgIGFydGlmYWN0IGlz IGZvcm1hdHRlZCB0aGUgc2FtZSBhcyBpZiByZXR1cm5lZCBieSBhIFJFU1RDT05GIHNlcnZlcg0K ICAgZm9yIGFuIEhUVFAgR0VUIHJlcXVlc3QgZm9yIHRoZSBzcGVjaWZpYyBpbmZvcm1hdGlvbi10 eXBlIHJlc291cmNlLg0KICAgRXhhbXBsZXMgb2YgdGhpcyBhcnRpZmFjdCdzIGVuY29kaW5nIGFy ZSBwcm92aWRlZCBpbiBBcHBlbmRpeCBCLg0KDQphbmQgQXBwZW5kaXggQiBwcm92aWRlcyBhbiBl eGFtcGxlIGxpa2U6DQoNCiAgIDxyZWRpcmVjdC1pbmZvcm1hdGlvbg0KICAgICB4bWxucz0idXJu OmlldGY6cGFyYW1zOnhtbDpuczp5YW5nOmlldGYtemVyb3RvdWNoLWJvb3RzdHJhcC1zZXJ2ZXIi Pg0KICAgICA8Ym9vdHN0cmFwLXNlcnZlcj4NCiAgICAgICA8YWRkcmVzcz5waHMxLmV4YW1wbGUu Y29tPC9hZGRyZXNzPg0KICAgICAgIDxwb3J0Pjg0NDM8L3BvcnQ+DQogICAgICAgPHRydXN0LWFu Y2hvcj4NCiAgICAgICAgIC4uLg0KICAgICAgIDwvdHJ1c3QtYW5jaG9yPg0KICAgICA8L2Jvb3Rz dHJhcC1zZXJ2ZXI+DQogICAgIDxib290c3RyYXAtc2VydmVyPg0KICAgICAgIDxhZGRyZXNzPnBo czEuZXhhbXBsZS5jb208L2FkZHJlc3M+DQogICAgICAgPHBvcnQ+ODQ0MzwvcG9ydD4NCiAgICAg ICA8dHJ1c3QtYW5jaG9yPg0KICAgICAgICAgLi4uDQogICAgICAgPC90cnVzdC1hbmNob3I+DQog ICAgIDwvYm9vdHN0cmFwLXNlcnZlcj4NCiAgIDwvcmVkaXJlY3QtaW5mb3JtYXRpb24+DQoNCg0K QW5kIHRoZSBzYW1lIGNvbnN0cnVjdCBpcyB1c2VkIGFnYWluIGluIFNlY3Rpb25zIDQgYW5kIDUg b2YgdGhlIEFOSU1BIHZvdWNoZXIgZHJhZnQgaGVyZTogaHR0cHM6Ly90b29scy5pZXRmLm9yZy9o dG1sL2RyYWZ0LWlldGYtYW5pbWEtdm91Y2hlci0wMC4NCg0KDQoNClVuZm9ydHVuYXRlbHksIFJG QyA3OTUwIHNheXM6DQoNCiAgIFlBTkcgaXMgYSBkYXRhIG1vZGVsaW5nIGxhbmd1YWdlIHVzZWQg dG8gbW9kZWwgY29uZmlndXJhdGlvbiBkYXRhLA0KICAgc3RhdGUgZGF0YSwgUmVtb3RlIFByb2Nl ZHVyZSBDYWxscywgYW5kIG5vdGlmaWNhdGlvbnMgZm9yIG5ldHdvcmsNCiAgIG1hbmFnZW1lbnQg cHJvdG9jb2xzLg0KDQp3aGljaCBpbXBsaWNpdGx5IGV4Y2x1ZGVzIHVzaW5nIFlBTkcgdGhpcyB3 YXkuDQoNCg0KDQpTbywgd2hhdCB0byBkbz8gIEhlcmUgYXJlIHNvbWUgb3B0aW9ucyAoYWRkaXRp b25hbCBvcHRpb25zIHdlbGNvbWVkKToNCg0KMSkgbGVhdmUgdGhlIGRyYWZ0IGxhbmd1YWdlIGFz IGlzIChxdWlya3ksIGJ1dCBleHBlZGllbnQpDQoyKSB3cml0ZSBhIHNob3J0IGRyYWZ0IHRoYXQg ZGVmaW5lcyBob3cgdG8gZG8gdGhpcw0KMykgc3dpdGNoIGZyb20gdXNpbmcgWUFORyB0byBzb21l dGhpbmcgZWxzZSAoc2VlIGJlbG93KQ0KDQpSZWdhcmRpbmcgb3B0aW9uICMzIGFib3ZlOg0KDQpB KSBOb3QgdXNpbmcgWUFORyBpbiB0aGUgQU5JTUEgZHJhZnQgd291bGQgYmUgYSBmYWlybHkgc3Ry YWlnaHRmb3J3YXJkIHRvIGRvLCB0aG91Z2ggaXQgc2hvdWxkIGJlIG5vdGVkIHRoYXQgYSByZWNl bnQgQU5JTUEgRFQgbWVldGluZyBjb25jbHVkZWQgd2l0aCB0aGUgZmVlbGluZyB0aGF0IFlBTkcg U0hPVUxEIGJlIHVzZWQsIHNpbmNlIHRoZXJlIG5vIGJldHRlciBETUwgZm9yIEpTT04gZG9jdW1l bnRzIGFuZCBzaW5jZSBZQU5HIGlzIHByZXZhbGVudCB3aXRoaW4gdGhlIElFVEYuICBGdXJ0aGVy bW9yZSwgaXMgd2FzIGZlbHQgdGhhdCB0aGlzIG1pZ2h0IGJlY29tZSBhIGNvbW1lbnQgbmVlZCBp biB0aW1lLCBhcyBKU09OIGlzIHBvcHVsYXIgaW4gc2V2ZXJhbCBXR3MuDQoNCmIpIE5vdCB1c2lu ZyBZQU5HIGluIHRoZSB6ZXJvdG91Y2ggZHJhZnQgd291bGQgYmUgbWVzc3ksIGFzIFlBTkcgaXMg dXNlZCB0byBkZWZpbmUgdGhlc2UgYXJ0aWZhY3RzIGFsc28gZm9yIHdoZW4gdGhleeKAmXJlIHJl dHVybmVkIGJ5IGEgUkVTVENPTkYgc2VydmVyIChkZWZpbmVkIHZpYSBZQU5HKS4gIFdlIGNvdWxk IHVzZSBhbm90aGVyIERNTCB0byBkZWZpbmUgdGhlc2UgYXJ0aWZhY3RzICpqdXN0KiBmb3Igd2hl biBOT1QgcmV0dXJuZWQgYnkgYSBSRVNUQ09ORiBzZXJ2ZXIsIGJ1dCB0aGF0IHdvdWxkIGJlIHRl cnJpYmx5IHJlZHVuZGFudC4gIFdlIGFsc28gY291bGQgYWxzbyB1c2UgYW5vdGhlciBETUwgdG8g ZGVmaW5lIHRoZXNlIGFydGlmYWN0cyBmb3IgYWxsIHVzZXMsIGFuZCB0aGVuIGZvciB0aGUgUkVT VENPTkYgc2VydmVyLCBkZWZpbmUgdGhlc2UgYXMgaGF2aW5nIHR5cGUgYW55ZGF0YSBvciBiaW5h cnkuDQoNCg0KDQpBbnkgb3RoZXIgaWRlYXM/DQoNCktlbnQNCg0KDQo= From nobody Wed Jan 11 14:59:41 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D6A7129476 for ; Wed, 11 Jan 2017 14:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S-GwdPB4RTMO for ; Wed, 11 Jan 2017 14:59:27 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91BEA1295B2 for ; Wed, 11 Jan 2017 14:59:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=69746; q=dns/txt; s=iport; t=1484175567; x=1485385167; h=from:to:subject:date:message-id:mime-version; bh=45uS3DRBkSKwCVLGDnHLfPUX+cKejuVZsMKdpYUPU34=; b=T5ao2YENFA94O4D5h8mjQJlEATmGLOqX/2cCGEmf8p7lS1fNpceF8NWz Iw8pQSSPWmbHSN8BRaHa+C/XG6a/9GW22g+CNRhvTLempgkaFVLZ5kmKL H3jb5kmBioK0Uwb8S0mWE+8qlJ1kIafG4/LrraT1nrmot9TxBET2yZyF5 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BuAQBRuHZY/5BdJa1DGhoBAQEBAgEBA?= =?us-ascii?q?QEIAQEBAYJxOw8BAQEBAR9fgQ0Hg0iKCKIJgyGCD4INLIYSgW4/FAECAQEBAQE?= =?us-ascii?q?BAWMohRMKXgEtCwgBAwYCBDAmAQQBGhMEiGEOLbBCgiWDVIZFAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBGwWGRYYcgU6BDwsGAWqCADqCXgWbKgGGWoFAiS+CAIUMiWKIEYp?= =?us-ascii?q?PAR84cFEVhG4cgV9zAQSGJQ4XgQqBDQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,347,1477958400"; d="scan'208,217";a="371567717" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Jan 2017 22:59:26 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id v0BMxPAH002273 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 11 Jan 2017 22:59:26 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 11 Jan 2017 17:59:25 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 11 Jan 2017 17:59:24 -0500 From: "Eric Voit (evoit)" To: "netconf@ietf.org" , "'netconf-subscriptions-dt@voit.org'" Thread-Topic: Minutes 11-Jan: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts Thread-Index: AdJsXlMGKmZf7NDjSmaUMrKef85LAQ== Date: Wed, 11 Jan 2017 22:59:24 +0000 Message-ID: <24e0dbe334cf41098e3d5e9695044cea@XCH-RTP-013.cisco.com> 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: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_24e0dbe334cf41098e3d5e9695044ceaXCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Minutes 11-Jan: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 Jan 2017 22:59:39 -0000 --_000_24e0dbe334cf41098e3d5e9695044ceaXCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWludXRlcyBwb3N0ZWQgYXQ6DQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1 c2gvd2lraS9NaW51dGVzLTIwMTctMDItMTENCg0KwrcgICAgICAgIEFzIGFsd2F5cywgb3VyIERl emlnblRNIFRlYW0gaXMgYSBnYXRoZXJpbmcgb2YgaW5kaXZpZHVhbHMgcHJvdmlkaW5nIGluZm9y bWFsIGlucHV0IHRvIE5FVENPTkYuIFdlIGFzayBORVRDT05GIFdHIHRvIGNvbW1lbnQgb24gb3Vy IGRpc2N1c3Npb24gcmVzdWx0cyBhcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29uc2Vuc3Vz LiBQbGVhc2UgYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRp cmVjdGx5IGluIHRoZXNlIG1lZXRpbmdzLg0KDQoNCk1lZXRpbmcgTWF0ZXJpYWxzDQoNCkF0dGVu ZGluZw0KDQpXZWJFeCBSZWNvcmRpbmc8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9sc3IucGhwP1JDSUQ9MTMxZmU4Y2M3NTlmNDVlZWE5ZTg5MzkwZTE4ZDc3NTE+DQpwYXNzd29y ZDoNCmhTdjd1YkY0DQoNCkFuZHkgQmllcm1hbiwgQWxleGFuZGVyIENsZW1tLCBFaW5hciBOaWxz ZW4tTnlnYWFyZCwgRXJpYyBWb2l0LCBUaW0gSmVua2lucywgQmFsYXpzIExlbmd5ZWwsIE1laG1l dCBFcnN1ZSwgQWxiZXJ0byBHb256YWxleg0KDQoodG8tYmUtcmVuYW1lZCkgNTI3N2JpcyBhbmQg TkVUQ09ORiBjaGFydGVyDQoNCiAgKiAgIFNpbmNlIEFwcmlsIHdlIGhhdmUgYmVlbiBnZW5lcmFs aXppbmcgWWFuZy1wdXNoJ3MgY29udHJvbCBwbGFuZSBzbyB0aGF0IGl0IHdvcmtzIGZvciBnZW5l cmFsIG5vdGlmaWNhdGlvbnMgb24gYW55IHRyYW5zcG9ydC4gRm9yIGEgY29tcGxldGUgc29sdXRp b24sIHRoaXMgdGVhbSBhbHNvIGJlbGlldmVzIHdlIHNob3VsZCB3b3JrIG91dCB0aGUgZGF0YSBw bGFuZSBub3RpZmljYXRpb24gaXNzdWVzLiBUaGVyZSBhcmUgZW5vdWdoIHRlY2huaWNhbCBjaGFu Z2VzIHRoYXQgd2UgZG9u4oCZdCB0aGluayB0aGF0IGVuaGFuY2luZyA1Mjc3IGlzIGFuIGFwcHJv cHJpYXRlIGFueW1vcmUuDQogICogICBNZWhtZXQgaGFzIHJldmlld2VkIGNvbW11bmljYXRpb25z IG9uIE5FVENPTkYsIGFuZCBzZWVuIHRoYXQgbm8gb25lIGlzIGFkdm9jYXRpbmcgZm9yIHRoZSDi gJxFbmhhbmNpbmcgNTI3N+KAnSBwYXRoIHdoaWNoIGlzIGN1cnJlbnRseSByZWZsZWN0ZWQgaW4g dGhlIGNoYXJ0ZXIuDQogICogICBNZWhtZXQgd2lsbCBiZSBzZW5kaW5nIGEgY2hhcnRlciByZXF1 ZXN0IGVtYWlsIHRvIE5FVENPTkYgdG8gc2VlIGlmIHdlIHdhbnQgdG8gYWRkIE5vdGlmaWNhdGlv bnMgMi4wIHRvIHRoZSBjaGFydGVyLg0KDQogICAgICogICBJZiB5ZXMsIHRoZW4gTm90aWZpY2F0 aW9ucyAyLjAgbmVlZHMgdG8gYmUgZGVmaW5lZCwgYW5kIHdlIG5lZWQgdG8gZmluYWxpemUgdGhl IGRpc2N1c3Npb24gb24gdGhlIHdvcmsgc3BsaXQgYW5kIHRoZSBkcmFmdHMuIE15IGd1ZXNzIGlz IHRoYXQgaW4gYWRkaXRpb24gdG8gdGhlIGN1cnJlbnQgZm91ciBkcmFmdHMsIHdlIHdvdWxkIGhh dmUgYSBzZXBhcmF0ZSBvbmUgc3BlY2lmaWMgdG8gbm90aWZpY2F0aW9ucy4NCiAgICAgKiAgIElm IG5vLCB0aGVuIHdlIHdvdWxkIHN0aWxsIG5lZWQgdGhlIGRhdGEgcGxhbmUgd29yayBmb3IgeWFu Zy1wdXNoIG5vdGlmaWNhdGlvbnMsIGFuZCBzb21ldGhpbmcgc3BlY2lmaWMgdG8gaXQgd291bGQg cmVzaWRlIGluIHRoYXQgZHJhZnQuIEJleW9uZCB0aGF0LCB0aGUgY3VycmVudCA1Mjc3YmlzIGNh buKAmXQgYmUgc3RhbmQtYWxvbmUsIGFuZCB0aGUgY29udHJvbCBwbGFuZSBnZW5lcmFsaXplZCB0 aGVyZSB3b3VsZCBiZSByZS1mb2xkZWQgYmFjayBpbnRvIHlhbmctcHVzaC4NCg0KICAqICAgT2Jz b2xldGluZyBvciBub24tb2Jzb2xldGluZyA1Mjc3IGlzIGFuIE9ydGhvZ29uYWwgcXVlc3Rpb24g d2hpY2ggY2FuIGJlIGFkZHJlc3NlZCBhdCBhIGxhdGVyIGRhdGUuDQoNClB1dHRpbmcgT3BlbiBJ c3N1ZXMgb24gR2l0aHViDQoNCiAgKiAgIFRpbWUgdG8gcHV0IG91ciBpc3N1ZXMgb250byBHaXRo dWIgc28gdGhhdCB0aGUgcmVzdCBvZiB0aGUgV0cgY2FuIHRyYWNrLiBBdCB0aGlzIHBvaW50LCB0 aGUgbmV3IGlzc3VlcyBhcmU6DQoNCiAgICAgKiAgIEVycm9yIHR5cGVzIHNjcnViYmluZyAoQWxl eCkNCiAgICAgKiAgIERhdGEgcGxhbmUgbm90aWZpY2F0aW9ucyBhbmQgbGF5ZXJlZCBoZWFkZXJz IChBbmR5KQ0KICAgICAqICAgSG93IHRvIGFsbG93IGZvciBzZWFtbGVzcyBpbnRlZ3JhdGlvbiB3 aXRoIEdQQi9HUlBDLiAoRXJpYykNCiAgICAgKiAgIFJldmlzaXQgQ2hhcnRlciBvZiBORVRDT05G IGZvciBOb3RpZmljYXRpb24gMi4wIChNZWhtZXQpDQogICAgICogICBTdWJzY3JpcHRpb24gSUQg YW5kIFNlY3VyaXR5IChFcmljKQ0KICAgICAqICAgTm90LW5vdGlmaWFibGUtb24tY2hhbmdlIChC YWxhenMpDQoNCiAgKiAgIFdlIHdpbGwgaG91c2UgaXNzdWVzIHdoaWNoIHNwYW4gbW9yZSB0aGFu IG9uZSBkcmFmdCAoYW5kIGFsbCBhYm92ZSBkbyB0aGlzKSBoZXJlPGh0dHBzOi8vZ2l0aHViLmNv bS9uZXRjb25mLXdnL3lhbmctcHVzaC9pc3N1ZXM+DQoNCk5vdGlmaWNhdGlvbnMgMi4wDQoNCiAg KiAgIEFuZHkgdGFsa2VkIGFib3V0IG5ldyBjYXBhYmlsaXRpZXMgd2hpY2ggbWlnaHQgYmUgdXNl ZnVsDQoNCiAgICAgKiAgIE11c3QgYmUgZXh0ZW5zaWJsZSB0byBhbGxvdyBuZXcgaGVhZGVyIGlu Zm9ybWF0aW9uIGFuZCBuZXcgdHJhbnNwb3J0cw0KICAgICAqICAgU2hvdWxkIGV4cGxvcmUgYnVu ZGxlIG11bHRpcGxlIHN1YnNjcmlwdGlvbiAob3Igb3RoZXIpIG5vdGlmaWNhdGlvbiBtZXNzYWdl cyBpbnRvIGEgc2luZ2xlIHB1c2hlZCBub3RpZmljYXRpb24NCiAgICAgKiAgIFdvdWxkIGJlIG5p Y2UgdG8gbGltaXQgdGhlIG51bWJlciBvZiBkYXRhIHBsYW5lIHVwZGF0ZSBtZXNzYWdlcyBzZW50 IHRvIGEgcmVjZWl2ZXIgcGVyIHNlY29uZCBhY3Jvc3Mgc3Vic2NyaXB0aW9ucw0KICAgICAqICAg SWRlbnRpZmllciBmb3IgcHJldmlvdXMgbm90aWZpY2F0aW9uIHRvIGhlbHAgdGhlIHJlY2VpdmVy IGRpc2NvdmVyIHdoZXRoZXIgd2UgbG9zdCB0aGUgcHJldmlvdXMgb25lLg0KDQogICogICBFcmlj IHRvIGFnZ3JlZ2F0ZSByZXF1aXJlbWVudHMuIFdoZXJlIGluIHRoZSBkaWZmZXJlbnQgZHJhZnRz IGRvIHRoaW5ncyBoYXZlIHRvIGNoYW5nZQ0KDQpOb3QtTm90aWZpYWJsZQ0KDQogICogICBOb3Rp ZmlhYmxlIG9yIG5vdC1ub3RpZmlhYmxlIGV4dGVuc2lvbnMgYm90aCBzZWVtIG5lY2Vzc2FyeS4g UGx1cyB3ZSB3YW50IGluaGVyaXRhbmNlIHVuZGVyIGEgc3VidHJlZSBmb3IgZWl0aGVyIG5vdC1u b3RpZmlhYmxlIG9yIG5vdGlmaWFibGUgZXh0ZW5zaW9uLg0KDQogICAgICogICBBdCB0aGlzIHBv aW50LCB3ZSB3b27igJl0IHVzZSBhbiBhbm5vdGF0aW9uDQoNCiAgKiAgIE5ldyBpbmZvcm1hdGlv biB3aWxsIGJlIHBsYWNlIG91dHNpZGUgdGhlIG1haW4gbW9kZWwNCiAgKiAgIE5lZWQgdG8gYWRk cmVzcyB3YXlzIG9mIGhhdmluZyBwbGF0Zm9ybSBzb3VyY2VkIHlhbmcgZGF0YSBhdmFpbGFibGUg b2ZmLWxpbmUgZm9yIGRldmVsb3BlcnMNCiAgKiAgIFNob3VsZCB3ZSBkbyB0aGlzIHZpYSBpbnN0 YW5jZSBkYXRhIG9yIG1vZGVsIGRhdGE/IEJhbGF6cyB3aWxsIGZyYW1lIHNvbWV0aGluZyB3aGlj aCBnb2VzIHRvIHRoZSBORVRDT05GIFdHLg0KDQpDb3VudGVycyBmb3IgUGFzcy9Ecm9wDQoNCiAg KiAgIFBlb3BsZSBjb21mb3J0YWJsZSB3aXRoIHByb3Bvc2FsIHdvcmtlZCBpbiBwcmV2aW91cyB3 ZWVrcy4NCg0KRXJyb3IgVHlwZXMNCg0KICAqICAgTmV4dCBjYWxsLg0KDQoNCg== --_000_24e0dbe334cf41098e3d5e9695044ceaXCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNv LXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv TGlzdFBhcmFncmFwaCwgbGkuTXNvTGlzdFBhcmFncmFwaCwgZGl2Lk1zb0xpc3RQYXJhZ3JhcGgN Cgl7bXNvLXN0eWxlLXByaW9yaXR5OjM0Ow0KCW1hcmdpbi10b3A6MGluOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbWFyZ2luLWJvdHRvbTowaW47DQoJbWFyZ2luLWxlZnQ6LjVpbjsNCgltYXJnaW4t Ym90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMg TmV3IFJvbWFuIixzZXJpZjt9DQpzcGFuLkhlYWRpbmcyQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SGVhZGluZyAyIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5r OiJIZWFkaW5nIDIiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0Kc3Bhbi5IZWFkaW5nM0NoYXINCgl7 bXNvLXN0eWxlLW5hbWU6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTsN Cgltc28tc3R5bGUtbGluazoiSGVhZGluZyAzIjsNCglmb250LXdlaWdodDpib2xkO30NCnAubXNv bm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6 bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47 DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQt c2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KcC5t LTUwNzE2NTE3Mjk4OTEzMTQ2ODZtc29saXN0cGFyYWdyYXBoLCBsaS5tLTUwNzE2NTE3Mjk4OTEz MTQ2ODZtc29saXN0cGFyYWdyYXBoLCBkaXYubS01MDcxNjUxNzI5ODkxMzE0Njg2bXNvbGlzdHBh cmFncmFwaA0KCXttc28tc3R5bGUtbmFtZTptXy01MDcxNjUxNzI5ODkxMzE0Njg2bXNvbGlzdHBh cmFncmFwaDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0K CW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNp emU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30NCnNwYW4u RW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJD YWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjMN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMt c2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyNA0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjojMUY0OTdEO30NCnNwYW4uYXBwbGUtY29udmVydGVkLXNwYWNlDQoJe21zby1zdHlsZS1uYW1l OmFwcGxlLWNvbnZlcnRlZC1zcGFjZTt9DQpzcGFuLkVtYWlsU3R5bGUyNg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xv cjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI4DQoJe21zby1zdHlsZS10eXBlOnBlcnNv bmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMjkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsN Cglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1h cmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi8qIExpc3QgRGVmaW5pdGlvbnMgKi8NCkBsaXN0IGwwDQoJe21zby1s aXN0LWlkOjM2NDY5NDQ3Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotMTY2MTU4MzYwO30NCkBs aXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2ZWwyDQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1s ZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJv bWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDps ZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDoxMzg0MjQ3NDM7DQoJbXNv LWxpc3QtdHlwZTpoeWJyaWQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjExNjY1NzE2NiA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4 OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMTpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwxOmxl dmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6 U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDE6bGV2ZWw3DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2 ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9 DQpAbGlzdCBsMTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMg0KCXttc28tbGlzdC1pZDoyNjQwMDA4NTA7DQoJbXNvLWxp c3QtdGVtcGxhdGUtaWRzOi00MDgzNjc1MzI7fQ0KQGxpc3QgbDI6bGV2ZWwxDQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1z by1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwyOmxldmVsMw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0 IGwyOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsNw0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGwyOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwz DQoJe21zby1saXN0LWlkOjI3MTQwNDU4NTsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTUyOTYy MjU1Njt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxl dmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2 ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw2DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDM6bGV2ZWw5 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6MzI0MTYz NjM5Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxNTc3NDM3NzY7fQ0KQGxpc3QgbDQ6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNDpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0 IGw0OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw0OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0 OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw1DQoJe21zby1saXN0LWlkOjQzMjk0MzIyNzsNCgltc28tbGlzdC10ZW1wbGF0 ZS1pZHM6Mzc2MjE0Njc0O30NCkBsaXN0IGw1OmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDou NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0K QGxpc3QgbDU6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNTpsZXZlbDMNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsNTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDcNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsNTpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNTpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNg0KCXttc28tbGlz dC1pZDo3NTcwOTkxNTQ7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE0MDgyODMzODI7fQ0KQGxp c3QgbDY6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9t YW4iO30NCkBsaXN0IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2 OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoz LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw2OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2Omxl dmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjEwNjk4ODQzMjE7DQoJbXNv LWxpc3QtdGVtcGxhdGUtaWRzOjE5OTI5MTcwNjt9DQpAbGlzdCBsNzpsZXZlbDENCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGw3OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJ bXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDc6bGV2ZWwz DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDc6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDc6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDgNCgl7bXNvLWxpc3QtaWQ6MTU1NDI2OTQ2NjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6MTcx OTE3ODIxODt9DQpAbGlzdCBsODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1z by1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpyb21hbi1sb3dlcjsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0 ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6 bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw2DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDg6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3QtaWQ6MTYx MzEyNDcwNjsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTUyMzIxODYwODt9DQpAbGlzdCBsOTps ZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw5OmxldmVsMg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJD b3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0K QGxpc3QgbDk6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw0 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDk6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw4DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1i ZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1z dG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5n ZGluZ3M7fQ0KQGxpc3QgbDEwDQoJe21zby1saXN0LWlkOjE4OTI3Njk1NjU7DQoJbXNvLWxpc3Qt dGVtcGxhdGUtaWRzOjc0MzYxNTI2Njt9DQpAbGlzdCBsMTA6bGV2ZWwxDQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5 bWJvbDt9DQpAbGlzdCBsMTA6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMTA6bGV2ZWwzDQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglm b250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNA0KCXttc28tbGV2ZWwtbnVt YmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWIt c3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2lu Z2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMTA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1i ZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1z aXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVsNw0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDgNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDExDQoJe21zby1saXN0LWlkOjIwNzIxMTg3MDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xODc1MDQ1NjI7fQ0KQGxpc3QgbDExOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDExOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDExOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTE6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDExOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMTpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTE6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDExOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMg0KCXtt c28tbGlzdC1pZDoyMDczNzY4NTczOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMDg1MDUyMTE2 O30NCkBsaXN0IGwxMjpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxMjpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9 DQpAbGlzdCBsMTI6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCglt c28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2kt Zm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEyOmxl dmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjpsZXZlbDYNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTI6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDEyOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMjps ZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0 Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3Np dGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAu MHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpvbA0KCXttYXJnaW4tYm90dG9tOjBpbjt9 DQp1bA0KCXttYXJnaW4tYm90dG9tOjBpbjt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4N CjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1V UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LHNhbnMtc2VyaWYiPk1pbnV0ZXMgcG9zdGVkIGF0Ojwvc3Bhbj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0 OTdEIj48YSBocmVmPSJodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1c2gvd2lr aS9NaW51dGVzLTIwMTctMDItMTEiPmh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lhbmct cHVzaC93aWtpL01pbnV0ZXMtMjAxNy0wMi0xMTwvYT48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWYiPg0KPHNwYW4gc3R5bGU9ImNvbG9y OiMxRjQ5N0QiPiZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTGlzdFBhcmFncmFwaCIgc3R5bGU9InRleHQtaW5kZW50Oi0uMjVpbjttc28tbGlz dDpsMSBsZXZlbDEgbGZvMTtiYWNrZ3JvdW5kOndoaXRlIj4NCjwhW2lmICFzdXBwb3J0TGlzdHNd PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OlN5bWJvbDtjb2xvcjpi bGFjayI+PHNwYW4gc3R5bGU9Im1zby1saXN0Oklnbm9yZSI+wrc8c3BhbiBzdHlsZT0iZm9udDo3 LjBwdCAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPjwvc3Bhbj48L3NwYW4+PCFbZW5kaWZdPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6YmxhY2siPkFzIGFsd2F5cywgb3VyIERlemlnbjxzdXA+VE08L3N1cD4g VGVhbSBpcyBhIGdhdGhlcmluZyBvZiBpbmRpdmlkdWFscyBwcm92aWRpbmcgaW5mb3JtYWwgaW5w dXQgdG8gTkVUQ09ORi4gV2UgYXNrIE5FVENPTkYgV0cgdG8gY29tbWVudCBvbiBvdXIgZGlzY3Vz c2lvbg0KIHJlc3VsdHMgYXMgYSBwcmVwYXJhdGlvbiBmb3IgdGhlIFdHIGNvbnNlbnN1cy4gUGxl YXNlIGFwcHJvYWNoIEVyaWMgVm9pdCBpZiB5b3Ugd2FudCB0byBiZSBpbmNsdWRlZCBkaXJlY3Rs eSBpbiB0aGVzZSBtZWV0aW5ncy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtD YWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMx RjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjx0YWJsZSBjbGFzcz0iTXNvTm9y bWFsVGFibGUiIGJvcmRlcj0iMCIgY2VsbHNwYWNpbmc9IjAiIGNlbGxwYWRkaW5nPSIwIiB3aWR0 aD0iMTQwMCIgc3R5bGU9IndpZHRoOjUyNS4wcHQ7YmFja2dyb3VuZDp3aGl0ZTtib3JkZXItY29s bGFwc2U6Y29sbGFwc2UiPg0KPHRoZWFkPg0KPHRyPg0KPHRkIHN0eWxlPSJib3JkZXI6c29saWQg I0RERERERCAxLjBwdDtwYWRkaW5nOjQuNXB0IDkuNzVwdCA0LjVwdCA5Ljc1cHQiPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCIgYWxpZ249ImNlbnRlciIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0 O3RleHQtYWxpZ246Y2VudGVyIj4NCjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPk1lZXRpbmcgTWF0ZXJpYWxz PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9ImJvcmRlcjpzb2xp ZCAjREREREREIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFkZGluZzo0LjVwdCA5Ljc1cHQgNC41 cHQgOS43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJt YXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRlciI+DQo8Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMz Ij5BdHRlbmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Ro ZWFkPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjx0ZCBz dHlsZT0iYm9yZGVyOnNvbGlkICNEREREREQgMS4wcHQ7Ym9yZGVyLXRvcDpub25lO3BhZGRpbmc6 NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9 ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPjxhIGhyZWY9Imh0 dHBzOi8vY2lzY28ud2ViZXguY29tL2Npc2Nvc2FsZXMvbHNyLnBocD9SQ0lEPTEzMWZlOGNjNzU5 ZjQ1ZWVhOWU4OTM5MGUxOGQ3NzUxIj5XZWJFeCBSZWNvcmRpbmc8L2E+PHNwYW4gc3R5bGU9ImNv bG9yOiMzMzMzMzMiPjxvOnA+PC9vOnA+PC9zcGFuPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxzcGFuIHN0eWxlPSJmb250LWZh bWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPnBhc3N3 b3JkOg0KPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPmhTdjd1YkY0PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyLXRvcDpub25lO2JvcmRlci1s ZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjREREREREIDEuMHB0O2JvcmRlci1yaWdodDpz b2xpZCAjREREREREIDEuMHB0O3BhZGRpbmc6NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdDtib3gt c2l6aW5nOiBib3JkZXItYm94Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t Ym90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1 b3Q7LHNhbnMtc2VyaWYiPkFuZHkgQmllcm1hbiwgQWxleGFuZGVyIENsZW1tLCBFaW5hciBOaWxz ZW4tTnlnYWFyZCwgRXJpYyBWb2l0LCBUaW0gSmVua2lucywgQmFsYXpzIExlbmd5ZWwsIE1laG1l dCBFcnN1ZSwgQWxiZXJ0byBHb256YWxlejxzcGFuIHN0eWxlPSJjb2xvcjojMzMzMzMzIj48bzpw PjwvbzpwPjwvc3Bhbj48L3NwYW4+PC9wPg0KPC90ZD4NCjwvdHI+DQo8L3Rib2R5Pg0KPC90YWJs ZT4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1ib3R0b206c29saWQgI0VFRUVFRSAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gNC4wcHQgMGluIj4NCjxkaXYgc3R5bGU9Im1zby1lbGVtZW50 OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNFRUVFRUUg MS4wcHQ7cGFkZGluZzowaW4gMGluIDQuMHB0IDBpbjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxoMiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJv dHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVyOm5vbmU7 cGFkZGluZzowaW47Ym94LXNpemluZzogYm9yZGVyLWJveDtmb250LXZhcmlhbnQtbGlnYXR1cmVz OiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246 c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp bmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPih0by1iZS1yZW5hbWVkKSA1Mjc3YmlzIGFuZCBORVRD T05GIGNoYXJ0ZXI8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJ JnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PG86cD48L286cD48L3NwYW4+PC9oMj4N CjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvO21zby1saXN0Omw3IGxldmVsMSBsZm84O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemlu ZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZiI+U2luY2UgQXByaWwgd2UgaGF2ZSBiZWVuIGdlbmVyYWxpemluZyBZ YW5nLXB1c2gncyBjb250cm9sIHBsYW5lIHNvIHRoYXQgaXQgd29ya3MgZm9yIGdlbmVyYWwgbm90 aWZpY2F0aW9ucyBvbiBhbnkgdHJhbnNwb3J0LiBGb3IgYSBjb21wbGV0ZSBzb2x1dGlvbiwgdGhp cyB0ZWFtIGFsc28gYmVsaWV2ZXMgd2Ugc2hvdWxkIHdvcmsgb3V0IHRoZSBkYXRhIHBsYW5lIG5v dGlmaWNhdGlvbg0KIGlzc3Vlcy4gVGhlcmUgYXJlIGVub3VnaCB0ZWNobmljYWwgY2hhbmdlcyB0 aGF0IHdlIGRvbuKAmXQgdGhpbmsgdGhhdCBlbmhhbmNpbmcgNTI3NyBpcyBhbiBhcHByb3ByaWF0 ZSBhbnltb3JlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDcgbGV2ZWwxIGxmbzg7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5n OiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmIj5NZWhtZXQgaGFzIHJldmlld2VkIGNvbW11bmljYXRpb25zIG9uIE5F VENPTkYsIGFuZCBzZWVuIHRoYXQgbm8gb25lIGlzIGFkdm9jYXRpbmcgZm9yIHRoZSDigJxFbmhh bmNpbmcgNTI3N+KAnSBwYXRoIHdoaWNoIGlzIGN1cnJlbnRseSByZWZsZWN0ZWQgaW4gdGhlIGNo YXJ0ZXIuPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPk1laG1ldCB3aWxsIGJlIHNlbmRpbmcgYSBjaGFydGVyIHJlcXVlc3QgZW1h aWwgdG8gTkVUQ09ORiB0byBzZWUgaWYgd2Ugd2FudCB0byBhZGQgTm90aWZpY2F0aW9ucyAyLjAg dG8gdGhlIGNoYXJ0ZXIuPG86cD48L286cD48L3NwYW4+PC9saT48L3VsPg0KPHVsIHR5cGU9ImRp c2MiPg0KPHVsIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNv bG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDcgbGV2ZWwyIGxmbzg7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5n OiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZx dW90OyxzYW5zLXNlcmlmIj5JZiB5ZXMsIHRoZW4gTm90aWZpY2F0aW9ucyAyLjAgbmVlZHMgdG8g YmUgZGVmaW5lZCwgYW5kIHdlIG5lZWQgdG8gZmluYWxpemUgdGhlIGRpc2N1c3Npb24gb24gdGhl IHdvcmsgc3BsaXQgYW5kIHRoZSBkcmFmdHMuIE15IGd1ZXNzIGlzIHRoYXQgaW4gYWRkaXRpb24g dG8gdGhlIGN1cnJlbnQgZm91ciBkcmFmdHMsIHdlIHdvdWxkIGhhdmUgYSBzZXBhcmF0ZSBvbmUN CiBzcGVjaWZpYyB0byBub3RpZmljYXRpb25zLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNv LW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDcgbGV2ZWwyIGxmbzg7YmFja2dyb3Vu ZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5JZiBubywgdGhlbiB3ZSB3b3VsZCBz dGlsbCBuZWVkIHRoZSBkYXRhIHBsYW5lIHdvcmsgZm9yIHlhbmctcHVzaCBub3RpZmljYXRpb25z LCBhbmQgc29tZXRoaW5nIHNwZWNpZmljIHRvIGl0IHdvdWxkIHJlc2lkZSBpbiB0aGF0IGRyYWZ0 LiBCZXlvbmQgdGhhdCwgdGhlIGN1cnJlbnQgNTI3N2JpcyBjYW7igJl0IGJlIHN0YW5kLWFsb25l LCBhbmQgdGhlIGNvbnRyb2wNCiBwbGFuZSBnZW5lcmFsaXplZCB0aGVyZSB3b3VsZCBiZSByZS1m b2xkZWQgYmFjayBpbnRvIHlhbmctcHVzaC48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsNyBsZXZlbDEgbGZvODtiYWNrZ3JvdW5kOndo aXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPk9ic29sZXRpbmcgb3Igbm9uLW9ic29sZXRp bmcgNTI3NyBpcyBhbiBPcnRob2dvbmFsIHF1ZXN0aW9uIHdoaWNoIGNhbiBiZSBhZGRyZXNzZWQg YXQgYSBsYXRlciBkYXRlLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9 Im1zby1lbGVtZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNv bGlkICNFRUVFRUUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDQuMHB0IDBpbjtiYWNrZ3JvdW5kOndo aXRlIj4NCjxoMiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1yaWdodDow aW47bWFyZ2luLWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JhY2tncm91bmQ6d2hpdGU7 Ym9yZGVyOm5vbmU7cGFkZGluZzowaW47Ym94LXNpemluZzogYm9yZGVyLWJveDtmb250LXZhcmlh bnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAy O3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBw eDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdv ZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPlB1dHRpbmcgT3BlbiBJc3N1ZXMg b24gR2l0aHViPG86cD48L286cD48L3NwYW4+PC9oMj4NCjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVs MSBsZm85O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+VGltZSB0 byBwdXQgb3VyIGlzc3VlcyBvbnRvIEdpdGh1YiBzbyB0aGF0IHRoZSByZXN0IG9mIHRoZSBXRyBj YW4gdHJhY2suIEF0IHRoaXMgcG9pbnQsIHRoZSBuZXcgaXNzdWVzIGFyZTo8bzpwPjwvbzpwPjwv c3Bhbj48L2xpPjwvdWw+DQo8dWwgdHlwZT0iZGlzYyI+DQo8b2wgc3RhcnQ9IjEiIHR5cGU9Imki Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVs MiBsZm85O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+RXJyb3Ig dHlwZXMgc2NydWJiaW5nIChBbGV4KTxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDggbGV2ZWwyIGxmbzk7YmFja2dyb3VuZDp3aGl0 ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5EYXRhIHBsYW5lIG5vdGlmaWNhdGlvbnMgYW5k IGxheWVyZWQgaGVhZGVycyAoQW5keSk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVsMiBsZm85O2JhY2tncm91bmQ6d2hp dGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+SG93IHRvIGFsbG93IGZvciBzZWFtbGVzcyBp bnRlZ3JhdGlvbiB3aXRoIEdQQi9HUlBDLiAoRXJpYyk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0 O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVsMiBsZm85O2JhY2tn cm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+UmV2aXNpdCBDaGFydGVyIG9m IE5FVENPTkYgZm9yIE5vdGlmaWNhdGlvbiAyLjAgKE1laG1ldCk8bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9w OjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVsMiBsZm85 O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+U3Vic2NyaXB0aW9u IElEIGFuZCBTZWN1cml0eSAoRXJpYyk8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw4IGxldmVsMiBsZm85O2JhY2tncm91bmQ6d2hp dGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+Tm90LW5vdGlmaWFibGUtb24tY2hhbmdlIChC YWxhenMpPG86cD48L286cD48L3NwYW4+PC9saT48L29sPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDggbGV2ZWwxIGxmbzk7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3Jk ZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90Oyxz YW5zLXNlcmlmIj5XZSB3aWxsIGhvdXNlIGlzc3VlcyB3aGljaCBzcGFuIG1vcmUgdGhhbiBvbmUg ZHJhZnQgKGFuZCBhbGwgYWJvdmUgZG8gdGhpcyk8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk LXNwYWNlIj4mbmJzcDs8L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly9naXRodWIuY29tL25ldGNvbmYt d2cveWFuZy1wdXNoL2lzc3VlcyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0MDc4QzAiPmhlcmU8L3Nw YW4+PC9hPjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxkaXYgc3R5bGU9Im1zby1lbGVt ZW50OnBhcmEtYm9yZGVyLWRpdjtib3JkZXI6bm9uZTtib3JkZXItYm90dG9tOnNvbGlkICNFRUVF RUUgMS4wcHQ7cGFkZGluZzowaW4gMGluIDQuMHB0IDBpbjtiYWNrZ3JvdW5kOndoaXRlIj4NCjxo MiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1yaWdodDowaW47bWFyZ2lu LWJvdHRvbToxMi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVyOm5v bmU7cGFkZGluZzowaW47Ym94LXNpemluZzogYm9yZGVyLWJveDtmb250LXZhcmlhbnQtbGlnYXR1 cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDtvcnBoYW5zOiAyO3RleHQtYWxp Z246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw YWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90 OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPk5vdGlmaWNhdGlvbnMgMi4wPG86cD48L286cD48 L3NwYW4+PC9oMj4NCjwvZGl2Pg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3Jt YWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJn aW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxMCBsZXZlbDEgbGZvMTA7YmFja2dyb3VuZDp3 aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5BbmR5IHRhbGtlZCBhYm91dCBuZXcgY2Fw YWJpbGl0aWVzIHdoaWNoIG1pZ2h0IGJlIHVzZWZ1bDxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91 bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29O b3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxMCBsZXZlbDIgbGZvMTA7YmFja2dyb3Vu ZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5NdXN0IGJlIGV4dGVuc2libGUgdG8g YWxsb3cgbmV3IGhlYWRlciBpbmZvcm1hdGlvbiBhbmQgbmV3IHRyYW5zcG9ydHM8bzpwPjwvbzpw Pjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMztt YXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwxMCBs ZXZlbDIgbGZvMTA7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5T aG91bGQgZXhwbG9yZSBidW5kbGUgbXVsdGlwbGUgc3Vic2NyaXB0aW9uIChvciBvdGhlcikgbm90 aWZpY2F0aW9uIG1lc3NhZ2VzIGludG8gYSBzaW5nbGUgcHVzaGVkIG5vdGlmaWNhdGlvbjxvOnA+ PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMz MzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6 bDEwIGxldmVsMiBsZm8xMDtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3gi Pg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2Vy aWYiPldvdWxkIGJlIG5pY2UgdG8gbGltaXQgdGhlIG51bWJlciBvZiBkYXRhIHBsYW5lIHVwZGF0 ZSBtZXNzYWdlcyBzZW50IHRvIGEgcmVjZWl2ZXIgcGVyIHNlY29uZCBhY3Jvc3Mgc3Vic2NyaXB0 aW9uczxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJj b2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 bXNvLWxpc3Q6bDEwIGxldmVsMiBsZm8xMDtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPklkZW50aWZpZXIgZm9yIHByZXZpb3VzIG5vdGlmaWNhdGlvbiB0byBoZWxw IHRoZSByZWNlaXZlciBkaXNjb3ZlciB3aGV0aGVyIHdlIGxvc3QgdGhlIHByZXZpb3VzIG9uZS48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9w OjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMz MzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlz dDpsMTAgbGV2ZWwxIGxmbzEwO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJv eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZiI+RXJpYyB0byBhZ2dyZWdhdGUgcmVxdWlyZW1lbnRzLiBXaGVyZSBpbiB0aGUgZGlmZmVy ZW50IGRyYWZ0cyBkbyB0aGluZ3MgaGF2ZSB0byBjaGFuZ2U8bzpwPjwvbzpwPjwvc3Bhbj48L2xp PjwvdWw+DQo8ZGl2IHN0eWxlPSJtc28tZWxlbWVudDpwYXJhLWJvcmRlci1kaXY7Ym9yZGVyOm5v bmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjRUVFRUVFIDEuMHB0O3BhZGRpbmc6MGluIDBpbiA0LjBw dCAwaW47YmFja2dyb3VuZDp3aGl0ZSI+DQo8aDIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDou MjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBp bjtiYWNrZ3JvdW5kOndoaXRlO2JvcmRlcjpub25lO3BhZGRpbmc6MGluO2JveC1zaXppbmc6IGJv cmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBz OiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRl eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5O b3QtTm90aWZpYWJsZTxvOnA+PC9vOnA+PC9zcGFuPjwvaDI+DQo8L2Rpdj4NCjx1bCB0eXBlPSJk aXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFy Z2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBs ZXZlbDEgbGZvMTE7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5O b3RpZmlhYmxlIG9yIG5vdC1ub3RpZmlhYmxlIGV4dGVuc2lvbnMgYm90aCBzZWVtIG5lY2Vzc2Fy eS4gUGx1cyB3ZSB3YW50IGluaGVyaXRhbmNlIHVuZGVyIGEgc3VidHJlZSBmb3IgZWl0aGVyIG5v dC1ub3RpZmlhYmxlIG9yIG5vdGlmaWFibGUgZXh0ZW5zaW9uLjxvOnA+PC9vOnA+PC9zcGFuPjwv bGk+PC91bD4NCjx1bCB0eXBlPSJkaXNjIj4NCjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0Omw5IGxldmVsMiBsZm8xMTtiYWNr Z3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQt ZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPkF0IHRoaXMgcG9pbnQsIHdl IHdvbuKAmXQgdXNlIGFuIGFubm90YXRpb248bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8 L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDEgbGZvMTE7YmFja2dyb3VuZDp3 aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5OZXcgaW5mb3JtYXRpb24gd2lsbCBiZSBw bGFjZSBvdXRzaWRlIHRoZSBtYWluIG1vZGVsPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xh c3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28t bWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDEgbGZvMTE7YmFja2dyb3Vu ZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5OZWVkIHRvIGFkZHJlc3Mgd2F5cyBv ZiBoYXZpbmcgcGxhdGZvcm0gc291cmNlZCB5YW5nIGRhdGEgYXZhaWxhYmxlIG9mZi1saW5lIGZv ciBkZXZlbG9wZXJzPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDEgbGZvMTE7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6 aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzYW5zLXNlcmlmIj5TaG91bGQgd2UgZG8gdGhpcyB2aWEgaW5zdGFuY2UgZGF0YSBv ciBtb2RlbCBkYXRhPyBCYWxhenMgd2lsbCBmcmFtZSBzb21ldGhpbmcgd2hpY2ggZ29lcyB0byB0 aGUgTkVUQ09ORiBXRy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8aDMgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIu MHB0O21hcmdpbi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1i b3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzMiPkNvdW50ZXJzIGZvciBQYXNzL0Ryb3A8bzpwPjwvbzpwPjwvc3Bhbj48L2gzPg0K PHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMz MzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21z by1saXN0OmwwIGxldmVsMSBsZm8xMjtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRl ci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh bnMtc2VyaWYiPlBlb3BsZSBjb21mb3J0YWJsZSB3aXRoIHByb3Bvc2FsIHdvcmtlZCBpbiBwcmV2 aW91cyB3ZWVrcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8aDMgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0 O21hcmdpbi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3g7 Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7 b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tl LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1 LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMz MzMzMzMiPkVycm9yIFR5cGVzPG86cD48L286cD48L3NwYW4+PC9oMz4NCjx1bCB0eXBlPSJkaXNj Ij4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2lu LXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMTEgbGV2 ZWwxIGxmbzEzO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+TmV4 dCBjYWxsLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjxoMiBzdHlsZT0iYmFja2dyb3Vu ZDp3aGl0ZSI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2ZvbnQtd2VpZ2h0Om5vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9oMj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_24e0dbe334cf41098e3d5e9695044ceaXCHRTP013ciscocom_-- From nobody Thu Jan 12 01:52:13 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E8FD12953F; Thu, 12 Jan 2017 01:52:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PuDOvVqkYGRc; Thu, 12 Jan 2017 01:51:57 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AF9EB1293F8; Thu, 12 Jan 2017 01:51:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=37438; q=dns/txt; s=iport; t=1484214717; x=1485424317; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=3tyQBiPh2EGXGfH1NtvLzofAwFva8TQ+w2ycHQsRvOM=; b=Rye+Ltw3cjmM8udEksYlZ5BOOAZlbq+ff78KCb3AVfAztmxq70sfZmoy laXyqULc1XRFtBKJqdKS06IMfYBoYOEQjQHlA5wqaMJI/CeiT3GK4Ebcw RqtFtpxO7DSsjwYtsl8Axvz0MvEy27V0VMSX6bwhDKn+6QSlISIgTPa1n 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BRAwBcUXdY/xbLJq0aA0AZAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGCcUoBAQEBAX4DgQqDUIoIcpEhlSiCDR8BCoUuSgKCThQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBAwEBARgJSwsFCwkCGCABAgQDAgInHxEGAQwGAgEBF4hdC?= =?us-ascii?q?A6SIkKdToIlK4lnAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGRYICCIJXhDCDHoJ?= =?us-ascii?q?eBY8chgqGBIlwh2aKLYY4immHex84gRUSCBUVOoN8bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="649734349" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 09:51:37 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0C9pb1H001041; Thu, 12 Jan 2017 09:51:37 GMT To: Andy Bierman , Ladislav Lhotka References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Robert Wilton Message-ID: <801aee49-4599-86ae-fe47-7a79980da62f@cisco.com> Date: Thu, 12 Jan 2017 09:51:37 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------0893CB482947FB27EFEAD959" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 09:52:08 -0000 This is a multi-part message in MIME format. --------------0893CB482947FB27EFEAD959 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 20:32, Andy Bierman wrote: > > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka > wrote: > > > > On 11 Jan 2017, at 17:56, Andy Bierman > wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional > module > > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because it’s not > tricky ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two > nodes - one config and the other state - have the same name or > even type (which is not always the case, as we know), their > semantics is often different. An IP address in configuration means > a manually configured address whereas in state it may come from > any source. So writing sensible descriptions will become tricky. > I don't disagree that in some cases there is some nuanced differences between configured values and values that may be learned via other dynamic mechanisms. The pragmatic point solution for these sorts of cases is to add an extra leaf to indicate the source of the value. The existing ietf-ip YANG model already has a "source" leaf to indicate whether the address is static, dhcp, link-layer, random. This type of adhoc mechanism will continue to work with a combined config/state data tree as well. However, draft-ietf-netmod-revised-datastores also provides a generalized solution to this problem, via using origin metadata annotations (sections 5.2 and 8). This allows the server to annotate whether a node in the operational state datastore has been populated via running configuration, or has been acquired via some other mechanism. Yes, the descriptions may have to be written in a slightly different way, but I don't think that it is going to be too tricky to understand that was is in running represents the configuration given to the system, vs what is in the operational state datastore represents what configuration the device is actually running, along with all of the associated other operational state. Rob > > > > > Is is that realistic to force the config structure and > operational structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely > unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF > would be usable both by new client/servers that support an > operational state datastore, and also by existing NETCONF > client/servers that don't implement an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces. > > > Here is the starting tree: > > > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw description? string > | +--rw type identityref > | +--rw enabled? boolean > | +--rw link-up-down-trap-enable? enumeration > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro type identityref > +--ro admin-status enumeration > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-state-ref > +--ro lower-layer-if* interface-state-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > > So these are the objects that would no longer be duplicated: > > - name > - type > > Neither one is supposed to have a different value in operational state > vs configuration. > > - enabled > - link-up-down-trap-enable > > These 2 could be different in operational state I suppose. > An RPC can provide the operational value without changing the YANG module > > rpc get-oper-value { > input { > leaf node { > type instance-identifier; > description "the config=true node to check"; > } > } > output { > anydata value { > description > "contains 1 child node matching the input 'node' parameter. > The value of the node is the current operational value." > } > } > } > > > > > /if:interfaces/if:interface[if:name='eth0']/enabled > > > > > > > false > > > > I don't need to change the YANG module at all to support operational > state. > > > Andy > > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm > not actually proposing immediately changing that model. I was > more thinking about IETF protocols that in the process of working > on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > 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 > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --------------0893CB482947FB27EFEAD959 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 20:32, Andy Bierman wrote:


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional module
> that follows some simplistic pattern.
> It may be simple, but I’m thinking that’s only because it’s not tricky  ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.  Operators might have to know about it to use it.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything.
> Don't you need separate description-stmts in every node for each
> datastore?  What does the value mean if pre-configured? configured?
> operational?  Will the auto-generated objects be exactly correct
> and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two nodes - one config and the other state - have the same name or even type (which is not always the case, as we know), their semantics is often different. An IP address in configuration means a manually configured address whereas in state it may come from any source. So writing sensible descriptions will become tricky.
I don't disagree that in some cases there is some nuanced differences between configured values and values that may be learned via other dynamic mechanisms.

The pragmatic point solution for these sorts of cases is to add an extra leaf to indicate the source of the value.  The existing ietf-ip YANG model already has a "source" leaf to indicate whether the address is static, dhcp, link-layer, random.  This type of adhoc mechanism will continue to work with a combined config/state data tree as well.

However, draft-ietf-netmod-revised-datastores also provides a generalized solution to this problem, via using origin metadata annotations (sections 5.2 and 8).  This allows the server to annotate whether a node in the operational state datastore has been populated via running configuration, or has been acquired via some other mechanism.

Yes, the descriptions may have to be written in a slightly different way, but I don't think that it is going to be too tricky to understand that was is in running represents the configuration given to the system, vs what is in the operational state datastore represents what configuration the device is actually running, along with all of the associated other operational state.

Rob



>
> Is is that realistic to force the config structure and operational structure
> to be the same? Seems it is quite common to monitor data structures
> with additional keys or different keys.  This is completely unsupported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.
>
> As an illustration, an RFC published combined ietf-interfaces model may look like this:
>


OK -- let me see if I understand the value of combining ietf-interfaces.


Here is the starting tree:


     +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-octets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects that would no longer be duplicated:

    - name
    - type

Neither one is supposed to have a different value in operational state vs configuration.

   - enabled
   - link-up-down-trap-enable

These 2 could be different in operational state I suppose.
An RPC can provide the operational value without changing the YANG module

    rpc get-oper-value {
      input {
         leaf node { 
            type instance-identifier; 
             description "the config=true node to check";
          }
      }
      output {
          anydata value {
             description 
               "contains 1 child node matching the input 'node' parameter.
                The value of the node is the current operational value."
          }
     }
   }


   <rpc>
      <get-oper-value>
          <node>/if:interfaces/if:interface[if:name='eth0']/enabled</node>
      </get-oper-value>
   </rpc>


   <rpc-reply>
       <value>
          <if:enabled>false</if:enabled>
        </value>
     </rpc-reply>

I don't need to change the YANG module at all to support operational state.


Andy

 
> module: ietf-interfaces-combined
>     +--rw interfaces
>        +--rw interface* [name]
>           +--rw name                        string
>           +--rw description?                string
>           +--rw type                        identityref
>           +--rw enabled?                    boolean
>           +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if*            interface-ref
>           +--ro lower-layer-if*             interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>     +--ro interfaces-state
>        +--ro interface* [name]
>           +--ro name                        string
>           +--ro description?                string
>           +--ro type                        identityref
>           +--ro enabled?                    boolean
>           +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if:if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if* if:interface-ref
>           +--ro lower-layer-if* if:interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> Servers that support operational-state would just implement ietf-interfaces-combined
>
> Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.
>
> Rob
>
>
> Exactly.  I agree that this is a real hack.  Implementations can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear.
>
>
>
>
>
>
> /martin
> _______________________________________________
> 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

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







--------------0893CB482947FB27EFEAD959-- From nobody Thu Jan 12 02:32:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC055129563; Thu, 12 Jan 2017 02:32:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zsRLfF2IeNAW; Thu, 12 Jan 2017 02:32:48 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA9A6129525; Thu, 12 Jan 2017 02:32:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30061; q=dns/txt; s=iport; t=1484217168; x=1485426768; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=hz/JZEQNnmXKrikZDcJ7plyarmG3Dsqi2HOZWpUiU4E=; b=Vkm5rkQeOFYQDcbeNQjdEJi9KMtMAhfQiNVkitudsN9DSXRJNx1IXLmC DIGziRKT1xkFcHP5BoWBpxYdi1Fuer3ENx28oyCkqpJKW0ZJ51iXJZw/w HQ92fPZUwcKwFXguPecbRdHzlnSlvnTuv1pEYCzhOdAiXb90glanAlksQ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BfAQBeWXdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgywPAQEBAQF+A4EKg1CKCHKRIZUogg0fAQqFLkoCgk4UAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQMBAQEhSwsFCwkCEgYgAwQDAgInHwMOBg0GAgEBFQKIXQgOk?= =?us-ascii?q?mCdToIlK4lmAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWGRYICgl+EMIMegl4Fjxy?= =?us-ascii?q?MDolwh2aKLYY4immHex84Nl8SCBUVOoN8bIFHPjWIZgEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="691276773" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 10:32:45 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0CAWilk028270; Thu, 12 Jan 2017 10:32:44 GMT To: Andy Bierman References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> From: Robert Wilton Message-ID: <5ff7521f-75f7-e59e-30da-9482c63dcc04@cisco.com> Date: Thu, 12 Jan 2017 10:32:44 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------9EBC1A57B6F066A5623D5C4B" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:32:52 -0000 This is a multi-part message in MIME format. --------------9EBC1A57B6F066A5623D5C4B Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 16:56, Andy Bierman wrote: > Hi, > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > wrote: > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > I think it is better to have a human decide what > is in the module > instead of relying on a pyang plugin to generate > some additional module > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because > it’s not tricky ;) > > > The client and server developers still need to know about this > auto-generated module > and implement it. Operators might have to know about it > to use it. > > My idea is not to auto generate models on the fly. > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > I am not convinced this "new format" has solved anything. > Don't you need separate description-stmts in every node for each > datastore? No, generally I don't this so. Assuming clients understand the general semantics and datastore architecture it should be fairly easy for them to understand the difference between the configured value and operational value. There might need to be some nuance as to how the description statements are written, but this still seems better than requiring two separate leaves for each property so that first one can have a description that says "this is the configured value" and the second says "this is the operational value". Anywhere where it is necessary to have manual duplication leads to mistakes and inconsistencies creeping in. > What does the value mean if pre-configured? configured? > operational? The datastore architecture defines the semantic meaning of what a node means in a particular datastore. This is true even today between startup, candidate, and running datastores. > Will the auto-generated objects be exactly correct > and never need any alterations or additional text? Yes, they will be exactly correct, and never need any alterations, since they have exactly the same semantic meaning as for the equivalent config true leaf in the operational state datastore. The auto-generation script could trivially append to each description statement for nodes in the generated model to indicate that it represents the operational value. > They still need to be used by developers and YANG tools. > > Is is that realistic to force the config structure and operational > structure > to be the same? Seems it is quite common to monitor data structures > with additional keys or different keys. This is completely unsupported > so separate /foo and /foo-state trees will still exist. It is not forcing the config and operational state structure to be the same, only that the operational state must extend from the config structure. These "monitor data structures" can continue to exist as config false structures just as they do today somewhere in the combined tree. They could even be put in top level foo-state objects if there was nowhere lower down the tree that is a better place for them, but I think that in the general case (for components that can be configured on or off, they can live under a single top level, config true, component container). Finally, if you allow the core structure of the config tree and state tree to deviate that it makes life much harder for management clients because they have to be hardcoded to know where the corresponding state lives for a particular set of configuration. > > IMO this combination of trees needs to be proven. > Take ietf-interfaces and show how much better it will work > if the /interfaces and /interfaces-state trees were combined. Yes, this might be a good idea. But doing this for the base IETF interface model on its own isn't really going to be informative. I think that a larger example is necessary to properly see the benefits. Rob > > > Andy > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > The aim here is that the single model being produced by IETF would > be usable both by new client/servers that support an operational > state datastore, and also by existing NETCONF client/servers that > don't implement an operational state datastore. > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > module: ietf-interfaces-combined > +--rw interfaces > +--rw interface* [name] > +--rw name string > +--rw description? string > +--rw type identityref > +--rw enabled? boolean > +--rw link-up-down-trap-enable? enumeration {if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-ref > +--ro lower-layer-if* interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > The extra generated model would look like this: > > module: ietf-interfaces-combined-state > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro description? string > +--ro type identityref > +--ro enabled? boolean > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 {if:if-mib}? > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* if:interface-ref > +--ro lower-layer-if* if:interface-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > Servers that support operational-state would just implement > ietf-interfaces-combined > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > Finally, I've illustrated this using ietf-interfaces, but I'm not > actually proposing immediately changing that model. I was more > thinking about IETF protocols that in the process of working on > their YANG models. > > Rob > > > Exactly. I agree that this is a real hack. Implementations > can use > whatever transformation tricks they want in order to comply with > different standards, but the standard modules should be very > clear. > > > > > > > > /martin > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > > > --------------9EBC1A57B6F066A5623D5C4B Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 16:56, Andy Bierman wrote:
Hi,


On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:


On 11/01/2017 09:22, Martin Bjorklund wrote:
Andy Bierman <andy@yumaworks.com> wrote:
On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:

I think it is better to have a human decide what is in the module
instead of relying on a pyang plugin to generate some additional module
that follows some simplistic pattern.
It may be simple, but I’m thinking that’s only because it’s not tricky  ;)


The client and server developers still need to know about this
auto-generated module
and implement it.  Operators might have to know about it to use it.
My idea is not to auto generate models on the fly.

My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.



I am not convinced this "new format" has solved anything.
Don't you need separate description-stmts in every node for each
datastore?
No, generally I don't this so.  Assuming clients understand the general semantics and datastore architecture it should be fairly easy for them to understand the difference between the configured value and operational value.

There might need to be some nuance as to how the description statements are written, but this still seems better than requiring two separate leaves for each property so that first one can have a description that says "this is the configured value" and the second says "this is the operational value".  Anywhere where it is necessary to have manual duplication leads to mistakes and inconsistencies creeping in.



  What does the value mean if pre-configured? configured?
operational?

The datastore architecture defines the semantic meaning of what a node means in a particular datastore.

This is true even today between startup, candidate, and running datastores.



  Will the auto-generated objects be exactly correct
and never need any alterations or additional text?

Yes, they will be exactly correct, and never need any alterations, since they have exactly the same semantic meaning as for the equivalent config true leaf in the operational state datastore.

The auto-generation script could trivially append to each description statement for nodes in the generated model to indicate that it represents the operational value.


They still need to be used by developers and YANG tools.

Is is that realistic to force the config structure and operational structure
to be the same? Seems it is quite common to monitor data structures
with additional keys or different keys.  This is completely unsupported
so separate /foo and /foo-state trees will still exist.

It is not forcing the config and operational state structure to be the same, only that the operational state must extend from the config structure.

These "monitor data structures" can continue to exist as config false structures just as they do today somewhere in the combined tree.  They could even be put in top level foo-state objects if there was nowhere lower down the tree that is a better place for them, but I think that in the general case (for components that can be configured on or off, they can live under a single top level, config true, component container).

Finally, if you allow the core structure of the config tree and state tree to deviate that it makes life much harder for management clients because they have to be hardcoded to know where the corresponding state lives for a particular set of configuration.


IMO this combination of trees needs to be proven.
Take ietf-interfaces and show how much better it will work
if the /interfaces and /interfaces-state trees were combined.

Yes, this might be a good idea.  But doing this for the base IETF interface model on its own isn't really going to be informative.  I think that a larger example is necessary to properly see the benefits.

Rob




Andy


The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.

The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.

I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.

As an illustration, an RFC published combined ietf-interfaces model may look like this:

module: ietf-interfaces-combined
    +--rw interfaces
       +--rw interface* [name]
          +--rw name                        string
          +--rw description?                string
          +--rw type                        identityref
          +--rw enabled?                    boolean
          +--rw link-up-down-trap-enable?   enumeration {if-mib}?
          +--ro oper-status                 enumeration
          +--ro last-change? yang:date-and-time
          +--ro if-index                    int32 {if-mib}?
          +--ro phys-address? yang:phys-address
          +--ro higher-layer-if*            interface-ref
          +--ro lower-layer-if*             interface-ref
          +--ro speed?                      yang:gauge64
          +--ro statistics
             +--ro discontinuity-time    yang:date-and-time
             +--ro in-octets?            yang:counter64
             +--ro in-unicast-pkts?      yang:counter64
             +--ro in-broadcast-pkts?    yang:counter64
             +--ro in-multicast-pkts?    yang:counter64
             +--ro in-discards?          yang:counter32
             +--ro in-errors?            yang:counter32
             +--ro in-unknown-protos?    yang:counter32
             +--ro out-octets?           yang:counter64
             +--ro out-unicast-pkts?     yang:counter64
             +--ro out-broadcast-pkts?   yang:counter64
             +--ro out-multicast-pkts?   yang:counter64
             +--ro out-discards?         yang:counter32
             +--ro out-errors?           yang:counter32

The extra generated model would look like this:

module: ietf-interfaces-combined-state
    +--ro interfaces-state
       +--ro interface* [name]
          +--ro name                        string
          +--ro description?                string
          +--ro type                        identityref
          +--ro enabled?                    boolean
          +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
          +--ro oper-status                 enumeration
          +--ro last-change? yang:date-and-time
          +--ro if-index                    int32 {if:if-mib}?
          +--ro phys-address? yang:phys-address
          +--ro higher-layer-if* if:interface-ref
          +--ro lower-layer-if* if:interface-ref
          +--ro speed?                      yang:gauge64
          +--ro statistics
             +--ro discontinuity-time    yang:date-and-time
             +--ro in-octets?            yang:counter64
             +--ro in-unicast-pkts?      yang:counter64
             +--ro in-broadcast-pkts?    yang:counter64
             +--ro in-multicast-pkts?    yang:counter64
             +--ro in-discards?          yang:counter32
             +--ro in-errors?            yang:counter32
             +--ro in-unknown-protos?    yang:counter32
             +--ro out-octets?           yang:counter64
             +--ro out-unicast-pkts?     yang:counter64
             +--ro out-broadcast-pkts?   yang:counter64
             +--ro out-multicast-pkts?   yang:counter64
             +--ro out-discards?         yang:counter32
             +--ro out-errors?           yang:counter32

Servers that support operational-state would just implement ietf-interfaces-combined

Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.

Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.

Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.

Rob


Exactly.  I agree that this is a real hack.  Implementations can use
whatever transformation tricks they want in order to comply with
different standards, but the standard modules should be very clear.






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



--------------9EBC1A57B6F066A5623D5C4B-- From nobody Thu Jan 12 02:45:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55DCD129545; Thu, 12 Jan 2017 02:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zk06TdairGSt; Thu, 12 Jan 2017 02:45:14 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D23129547; Thu, 12 Jan 2017 02:45:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35534; q=dns/txt; s=iport; t=1484217914; x=1485427514; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=xhcdxDShO7rBabBfrWjubn5Jlw1Ltv2/lrO119pevSc=; b=gmPg1/Hn/EjV6F39sojYnb161hQ4c3H5ON+AmhU8A3frBRxWO0njWt6y O+Um0C63lwfUzR9XmLYyAiQiut3TsHCeg3Ul97CIfgPgFA/kM6bN361tE nIJL0YJ+0Gnm27G7ONcaA5NBhkKSDXro9ct8/4SUTf+z/Qa4012PAmeU5 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0APAQCQXXdY/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgnJKAQEBAQF+A4EDg1CKCHKRIpUrggoDHwEKhS5KAoJNFAECAQE?= =?us-ascii?q?BAQEBAWMohGkBAQEDAQEBGAlLCwULCQIYIAECBAMCAicfEQYBDAYCAQEXiF0ID?= =?us-ascii?q?pJXnU6CJSuJZwEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkWCAoJfhCIOgxyCXgW?= =?us-ascii?q?PHoYKhgSJcIdmii+GO4pph3sfOIEVEggVFTqDfGyBRz41himCPQEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,349,1477958400"; d="scan'208,217";a="648715477" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 10:45:09 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0CAj7T9018310; Thu, 12 Jan 2017 10:45:08 GMT To: Andy Bierman , Ladislav Lhotka References: <6425C57C-C3DF-4099-AE77-4521B58B8D69@juniper.net> <20170111.102209.310040071380723970.mbj@tail-f.com> <9d4c54bf-ac6f-0d64-0361-668f9a793cd1@cisco.com> <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> From: Robert Wilton Message-ID: <5c26b1eb-b811-00cb-e362-b2d8d02b6b5d@cisco.com> Date: Thu, 12 Jan 2017 10:45:07 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF2D67C373073DA840A083C2" Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 10:45:17 -0000 This is a multi-part message in MIME format. --------------BF2D67C373073DA840A083C2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 11/01/2017 20:32, Andy Bierman wrote: > > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka > wrote: > > > > On 11 Jan 2017, at 17:56, Andy Bierman > wrote: > > > > Hi, > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > wrote: > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > Andy Bierman > wrote: > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > wrote: > > > > I think it is better to have a human decide what is in the module > > instead of relying on a pyang plugin to generate some additional > module > > that follows some simplistic pattern. > > It may be simple, but I’m thinking that’s only because it’s not > tricky ;) > > > > > > The client and server developers still need to know about this > > auto-generated module > > and implement it. Operators might have to know about it to use it. > > My idea is not to auto generate models on the fly. > > > > My aim is to allow folks to start writing models in the desired > long term format (i.e. combined config and state tree) with the > model designer being able to assume the existence of the > operational state datastore. > > > > > > > > I am not convinced this "new format" has solved anything. > > Don't you need separate description-stmts in every node for each > > datastore? What does the value mean if pre-configured? configured? > > operational? Will the auto-generated objects be exactly correct > > and never need any alterations or additional text? > > They still need to be used by developers and YANG tools. > > Right, this is one problem of this "deduplication": even if two > nodes - one config and the other state - have the same name or > even type (which is not always the case, as we know), their > semantics is often different. An IP address in configuration means > a manually configured address whereas in state it may come from > any source. So writing sensible descriptions will become tricky. > > > > > Is is that realistic to force the config structure and > operational structure > > to be the same? Seems it is quite common to monitor data structures > > with additional keys or different keys. This is completely > unsupported > > so separate /foo and /foo-state trees will still exist. > > I agree. > > Lada > > > > > IMO this combination of trees needs to be proven. > > Take ietf-interfaces and show how much better it will work > > if the /interfaces and /interfaces-state trees were combined. > > > > > > Andy > > > > > > The tooling would be there to statically generate the extra > foo-state config false node modules for servers that don't support > the operational state datastore. This could be done once, and the > extra foo-state modules committed to the github YANG respository > in the same way that models are extracted from IETF RFCs today. > > > > The aim here is that the single model being produced by IETF > would be usable both by new client/servers that support an > operational state datastore, and also by existing NETCONF > client/servers that don't implement an operational state datastore. > > > > I'm not proposing that as a long term solution, but as a path to > make it easier for folk to migrate, and to not slow down the model > writing effort. Otherwise, it may be hard to get a protocol model > writer to design the YANG model in a way that is not fully usable > on any current devices. > > > > As an illustration, an RFC published combined ietf-interfaces > model may look like this: > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces. > > > Here is the starting tree: > > > +--rw interfaces > | +--rw interface* [name] > | +--rw name string > | +--rw description? string > | +--rw type identityref > | +--rw enabled? boolean > | +--rw link-up-down-trap-enable? enumeration > +--ro interfaces-state > +--ro interface* [name] > +--ro name string > +--ro type identityref > +--ro admin-status enumeration > +--ro oper-status enumeration > +--ro last-change? yang:date-and-time > +--ro if-index int32 > +--ro phys-address? yang:phys-address > +--ro higher-layer-if* interface-state-ref > +--ro lower-layer-if* interface-state-ref > +--ro speed? yang:gauge64 > +--ro statistics > +--ro discontinuity-time yang:date-and-time > +--ro in-octets? yang:counter64 > +--ro in-unicast-pkts? yang:counter64 > +--ro in-broadcast-pkts? yang:counter64 > +--ro in-multicast-pkts? yang:counter64 > +--ro in-discards? yang:counter32 > +--ro in-errors? yang:counter32 > +--ro in-unknown-protos? yang:counter32 > +--ro out-octets? yang:counter64 > +--ro out-unicast-pkts? yang:counter64 > +--ro out-broadcast-pkts? yang:counter64 > +--ro out-multicast-pkts? yang:counter64 > +--ro out-discards? yang:counter32 > +--ro out-errors? yang:counter32 > > > So these are the objects that would no longer be duplicated: > > - name > - type > > Neither one is supposed to have a different value in operational state > vs configuration. > > - enabled I (personally) would make the config "enabled" and the state "admin-status" leaf the same as well. But this example is really too simple on its own, a larger model needs to be considered to properly see the benefits. > - link-up-down-trap-enable > > These 2 could be different in operational state I suppose. > An RPC can provide the operational value without changing the YANG module > > rpc get-oper-value { > input { > leaf node { > type instance-identifier; > description "the config=true node to check"; > } > } > output { > anydata value { > description > "contains 1 child node matching the input 'node' parameter. > The value of the node is the current operational value." > } > } > } > > > > > /if:interfaces/if:interface[if:name='eth0']/enabled > > > > > > > false > > > > I don't need to change the YANG module at all to support operational > state. This solution would naively seem to be very limited. Rob > > > Andy > > > module: ietf-interfaces-combined > > +--rw interfaces > > +--rw interface* [name] > > +--rw name string > > +--rw description? string > > +--rw type identityref > > +--rw enabled? boolean > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-ref > > +--ro lower-layer-if* interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > The extra generated model would look like this: > > > > module: ietf-interfaces-combined-state > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro description? string > > +--ro type identityref > > +--ro enabled? boolean > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}? > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 {if:if-mib}? > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* if:interface-ref > > +--ro lower-layer-if* if:interface-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > Servers that support operational-state would just implement > ietf-interfaces-combined > > > > Servers that don't support operational-state could implement > ietf-interfaces-combined and ietf-interfaces-combined-state, > probably not implementing the duplicate config false leaves under > the interfaces config tree. Deviations could also be > auto-generated to remove the config false leaves from the config > tree so that they are only in the state tree. > > > > Of course, Clients may need to support both schemes depending on > what types of devices they are interacting with. > > > > Finally, I've illustrated this using ietf-interfaces, but I'm > not actually proposing immediately changing that model. I was > more thinking about IETF protocols that in the process of working > on their YANG models. > > > > Rob > > > > > > Exactly. I agree that this is a real hack. Implementations can use > > whatever transformation tricks they want in order to comply with > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > /martin > > _______________________________________________ > > 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 > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > --------------BF2D67C373073DA840A083C2 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 11/01/2017 20:32, Andy Bierman wrote:


On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:

> On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
>
> Hi,
>
>
> On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
>
> On 11/01/2017 09:22, Martin Bjorklund wrote:
> Andy Bierman <andy@yumaworks.com> wrote:
> On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net> wrote:
>
> I think it is better to have a human decide what is in the module
> instead of relying on a pyang plugin to generate some additional module
> that follows some simplistic pattern.
> It may be simple, but I’m thinking that’s only because it’s not tricky  ;)
>
>
> The client and server developers still need to know about this
> auto-generated module
> and implement it.  Operators might have to know about it to use it.
> My idea is not to auto generate models on the fly.
>
> My aim is to allow folks to start writing models in the desired long term format (i.e. combined config and state tree) with the model designer being able to assume the existence of the operational state datastore.
>
>
>
> I am not convinced this "new format" has solved anything.
> Don't you need separate description-stmts in every node for each
> datastore?  What does the value mean if pre-configured? configured?
> operational?  Will the auto-generated objects be exactly correct
> and never need any alterations or additional text?
> They still need to be used by developers and YANG tools.

Right, this is one problem of this "deduplication": even if two nodes - one config and the other state - have the same name or even type (which is not always the case, as we know), their semantics is often different. An IP address in configuration means a manually configured address whereas in state it may come from any source. So writing sensible descriptions will become tricky.

>
> Is is that realistic to force the config structure and operational structure
> to be the same? Seems it is quite common to monitor data structures
> with additional keys or different keys.  This is completely unsupported
> so separate /foo and /foo-state trees will still exist.

I agree.

Lada

>
> IMO this combination of trees needs to be proven.
> Take ietf-interfaces and show how much better it will work
> if the /interfaces and /interfaces-state trees were combined.
>
>
> Andy
>
>
> The tooling would be there to statically generate the extra foo-state config false node modules for servers that don't support the operational state datastore.  This could be done once, and the extra foo-state modules committed to the github YANG respository in the same way that models are extracted from IETF RFCs today.
>
> The aim here is that the single model being produced by IETF would be usable both by new client/servers that support an operational state datastore, and also by existing NETCONF client/servers that don't implement an operational state datastore.
>
> I'm not proposing that as a long term solution, but as a path to make it easier for folk to migrate, and to not slow down the model writing effort.  Otherwise, it may be hard to get a protocol model writer to design the YANG model in a way that is not fully usable on any current devices.
>
> As an illustration, an RFC published combined ietf-interfaces model may look like this:
>


OK -- let me see if I understand the value of combining ietf-interfaces.


Here is the starting tree:


     +--rw interfaces
      |  +--rw interface* [name]
      |     +--rw name                        string
      |     +--rw description?                string
      |     +--rw type                        identityref
      |     +--rw enabled?                    boolean
      |     +--rw link-up-down-trap-enable?   enumeration
      +--ro interfaces-state
         +--ro interface* [name]
            +--ro name               string
            +--ro type               identityref
            +--ro admin-status       enumeration
            +--ro oper-status        enumeration
            +--ro last-change?       yang:date-and-time
            +--ro if-index           int32
            +--ro phys-address?      yang:phys-address
            +--ro higher-layer-if*   interface-state-ref
            +--ro lower-layer-if*    interface-state-ref
            +--ro speed?             yang:gauge64
            +--ro statistics
               +--ro discontinuity-time    yang:date-and-time
               +--ro in-octets?            yang:counter64
               +--ro in-unicast-pkts?      yang:counter64
               +--ro in-broadcast-pkts?    yang:counter64
               +--ro in-multicast-pkts?    yang:counter64
               +--ro in-discards?          yang:counter32
               +--ro in-errors?            yang:counter32
               +--ro in-unknown-protos?    yang:counter32
               +--ro out-octets?           yang:counter64
               +--ro out-unicast-pkts?     yang:counter64
               +--ro out-broadcast-pkts?   yang:counter64
               +--ro out-multicast-pkts?   yang:counter64
               +--ro out-discards?         yang:counter32
               +--ro out-errors?           yang:counter32


So these are the objects that would no longer be duplicated:

    - name
    - type

Neither one is supposed to have a different value in operational state vs configuration.

   - enabled

I (personally) would make the config "enabled" and the state "admin-status" leaf the same as well.

But this example is really too simple on its own, a larger model needs to be considered to properly see the benefits.


   - link-up-down-trap-enable

These 2 could be different in operational state I suppose.
An RPC can provide the operational value without changing the YANG module

    rpc get-oper-value {
      input {
         leaf node { 
            type instance-identifier; 
             description "the config=true node to check";
          }
      }
      output {
          anydata value {
             description 
               "contains 1 child node matching the input 'node' parameter.
                The value of the node is the current operational value."
          }
     }
   }


   <rpc>
      <get-oper-value>
          <node>/if:interfaces/if:interface[if:name='eth0']/enabled</node>
      </get-oper-value>
   </rpc>


   <rpc-reply>
       <value>
          <if:enabled>false</if:enabled>
        </value>
     </rpc-reply>

I don't need to change the YANG module at all to support operational state.

This solution would naively seem to be very limited.

Rob




Andy

 
> module: ietf-interfaces-combined
>     +--rw interfaces
>        +--rw interface* [name]
>           +--rw name                        string
>           +--rw description?                string
>           +--rw type                        identityref
>           +--rw enabled?                    boolean
>           +--rw link-up-down-trap-enable?   enumeration {if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if*            interface-ref
>           +--ro lower-layer-if*             interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> The extra generated model would look like this:
>
> module: ietf-interfaces-combined-state
>     +--ro interfaces-state
>        +--ro interface* [name]
>           +--ro name                        string
>           +--ro description?                string
>           +--ro type                        identityref
>           +--ro enabled?                    boolean
>           +--ro link-up-down-trap-enable?   enumeration {if:if-mib}?
>           +--ro oper-status                 enumeration
>           +--ro last-change? yang:date-and-time
>           +--ro if-index                    int32 {if:if-mib}?
>           +--ro phys-address? yang:phys-address
>           +--ro higher-layer-if* if:interface-ref
>           +--ro lower-layer-if* if:interface-ref
>           +--ro speed?                      yang:gauge64
>           +--ro statistics
>              +--ro discontinuity-time    yang:date-and-time
>              +--ro in-octets?            yang:counter64
>              +--ro in-unicast-pkts?      yang:counter64
>              +--ro in-broadcast-pkts?    yang:counter64
>              +--ro in-multicast-pkts?    yang:counter64
>              +--ro in-discards?          yang:counter32
>              +--ro in-errors?            yang:counter32
>              +--ro in-unknown-protos?    yang:counter32
>              +--ro out-octets?           yang:counter64
>              +--ro out-unicast-pkts?     yang:counter64
>              +--ro out-broadcast-pkts?   yang:counter64
>              +--ro out-multicast-pkts?   yang:counter64
>              +--ro out-discards?         yang:counter32
>              +--ro out-errors?           yang:counter32
>
> Servers that support operational-state would just implement ietf-interfaces-combined
>
> Servers that don't support operational-state could implement ietf-interfaces-combined and ietf-interfaces-combined-state, probably not implementing the duplicate config false leaves under the interfaces config tree.  Deviations could also be auto-generated to remove the config false leaves from the config tree so that they are only in the state tree.
>
> Of course, Clients may need to support both schemes depending on what types of devices they are interacting with.
>
> Finally, I've illustrated this using ietf-interfaces, but I'm not actually proposing immediately changing that model.  I was more thinking about IETF protocols that in the process of working on their YANG models.
>
> Rob
>
>
> Exactly.  I agree that this is a real hack.  Implementations can use
> whatever transformation tricks they want in order to comply with
> different standards, but the standard modules should be very clear.
>
>
>
>
>
>
> /martin
> _______________________________________________
> 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

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







--------------BF2D67C373073DA840A083C2-- From nobody Thu Jan 12 04:47:45 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35522129615; Thu, 12 Jan 2017 04:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j0i2uHiB7_uK; Thu, 12 Jan 2017 04:47:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 95A981295EE; Thu, 12 Jan 2017 04:47:40 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 563F51AE01AA; Thu, 12 Jan 2017 13:47:38 +0100 (CET) Date: Thu, 12 Jan 2017 13:47:37 +0100 (CET) Message-Id: <20170112.134737.887226373918047146.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netmod@ietf.org, netconf@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:47:43 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIEphbiAx MSwgMjAxNyBhdCA5OjIxIEFNLCBMYWRpc2xhdiBMaG90a2EgPGxob3RrYUBuaWMuY3o+IHdyb3Rl Og0KPiANCj4gPg0KPiA+ID4gT24gMTEgSmFuIDIwMTcsIGF0IDE3OjU2LCBBbmR5IEJpZXJtYW4g PGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6DQo+ID4gPg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ ID4NCj4gPiA+IE9uIFdlZCwgSmFuIDExLCAyMDE3IGF0IDc6MTIgQU0sIFJvYmVydCBXaWx0b24g PHJ3aWx0b25AY2lzY28uY29tPg0KPiA+IHdyb3RlOg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBPbiAx MS8wMS8yMDE3IDA5OjIyLCBNYXJ0aW4gQmpvcmtsdW5kIHdyb3RlOg0KPiA+ID4gQW5keSBCaWVy bWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiA+ID4gT24gVHVlLCBKYW4gMTAsIDIw MTcgYXQgMToyMCBQTSwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+DQo+ID4gd3Jv dGU6DQo+ID4gPg0KPiA+ID4gSSB0aGluayBpdCBpcyBiZXR0ZXIgdG8gaGF2ZSBhIGh1bWFuIGRl Y2lkZSB3aGF0IGlzIGluIHRoZSBtb2R1bGUNCj4gPiA+IGluc3RlYWQgb2YgcmVseWluZyBvbiBh IHB5YW5nIHBsdWdpbiB0byBnZW5lcmF0ZSBzb21lIGFkZGl0aW9uYWwgbW9kdWxlDQo+ID4gPiB0 aGF0IGZvbGxvd3Mgc29tZSBzaW1wbGlzdGljIHBhdHRlcm4uDQo+ID4gPiBJdCBtYXkgYmUgc2lt cGxlLCBidXQgSeKAmW0gdGhpbmtpbmcgdGhhdOKAmXMgb25seSBiZWNhdXNlIGl04oCZcyBub3Qg dHJpY2t5DQo+ID4gOykNCj4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlIGNsaWVudCBhbmQgc2VydmVy IGRldmVsb3BlcnMgc3RpbGwgbmVlZCB0byBrbm93IGFib3V0IHRoaXMNCj4gPiA+IGF1dG8tZ2Vu ZXJhdGVkIG1vZHVsZQ0KPiA+ID4gYW5kIGltcGxlbWVudCBpdC4gIE9wZXJhdG9ycyBtaWdodCBo YXZlIHRvIGtub3cgYWJvdXQgaXQgdG8gdXNlIGl0Lg0KPiA+ID4gTXkgaWRlYSBpcyBub3QgdG8g YXV0byBnZW5lcmF0ZSBtb2RlbHMgb24gdGhlIGZseS4NCj4gPiA+DQo+ID4gPiBNeSBhaW0gaXMg dG8gYWxsb3cgZm9sa3MgdG8gc3RhcnQgd3JpdGluZyBtb2RlbHMgaW4gdGhlIGRlc2lyZWQgbG9u Zw0KPiA+IHRlcm0gZm9ybWF0IChpLmUuIGNvbWJpbmVkIGNvbmZpZyBhbmQgc3RhdGUgdHJlZSkg d2l0aCB0aGUgbW9kZWwgZGVzaWduZXINCj4gPiBiZWluZyBhYmxlIHRvIGFzc3VtZSB0aGUgZXhp c3RlbmNlIG9mIHRoZSBvcGVyYXRpb25hbCBzdGF0ZSBkYXRhc3RvcmUuDQo+ID4gPg0KPiA+ID4N Cj4gPiA+DQo+ID4gPiBJIGFtIG5vdCBjb252aW5jZWQgdGhpcyAibmV3IGZvcm1hdCIgaGFzIHNv bHZlZCBhbnl0aGluZy4NCj4gPiA+IERvbid0IHlvdSBuZWVkIHNlcGFyYXRlIGRlc2NyaXB0aW9u LXN0bXRzIGluIGV2ZXJ5IG5vZGUgZm9yIGVhY2gNCj4gPiA+IGRhdGFzdG9yZT8gIFdoYXQgZG9l cyB0aGUgdmFsdWUgbWVhbiBpZiBwcmUtY29uZmlndXJlZD8gY29uZmlndXJlZD8NCj4gPiA+IG9w ZXJhdGlvbmFsPyAgV2lsbCB0aGUgYXV0by1nZW5lcmF0ZWQgb2JqZWN0cyBiZSBleGFjdGx5IGNv cnJlY3QNCj4gPiA+IGFuZCBuZXZlciBuZWVkIGFueSBhbHRlcmF0aW9ucyBvciBhZGRpdGlvbmFs IHRleHQ/DQo+ID4gPiBUaGV5IHN0aWxsIG5lZWQgdG8gYmUgdXNlZCBieSBkZXZlbG9wZXJzIGFu ZCBZQU5HIHRvb2xzLg0KPiA+DQo+ID4gUmlnaHQsIHRoaXMgaXMgb25lIHByb2JsZW0gb2YgdGhp cyAiZGVkdXBsaWNhdGlvbiI6IGV2ZW4gaWYgdHdvIG5vZGVzIC0NCj4gPiBvbmUgY29uZmlnIGFu ZCB0aGUgb3RoZXIgc3RhdGUgLSBoYXZlIHRoZSBzYW1lIG5hbWUgb3IgZXZlbiB0eXBlICh3aGlj aCBpcw0KPiA+IG5vdCBhbHdheXMgdGhlIGNhc2UsIGFzIHdlIGtub3cpLCB0aGVpciBzZW1hbnRp Y3MgaXMgb2Z0ZW4gZGlmZmVyZW50LiBBbiBJUA0KPiA+IGFkZHJlc3MgaW4gY29uZmlndXJhdGlv biBtZWFucyBhIG1hbnVhbGx5IGNvbmZpZ3VyZWQgYWRkcmVzcyB3aGVyZWFzIGluDQo+ID4gc3Rh dGUgaXQgbWF5IGNvbWUgZnJvbSBhbnkgc291cmNlLiBTbyB3cml0aW5nIHNlbnNpYmxlIGRlc2Ny aXB0aW9ucyB3aWxsDQo+ID4gYmVjb21lIHRyaWNreS4NCj4gPg0KPiA+ID4NCj4gPiA+IElzIGlz IHRoYXQgcmVhbGlzdGljIHRvIGZvcmNlIHRoZSBjb25maWcgc3RydWN0dXJlIGFuZCBvcGVyYXRp b25hbA0KPiA+IHN0cnVjdHVyZQ0KPiA+ID4gdG8gYmUgdGhlIHNhbWU/IFNlZW1zIGl0IGlzIHF1 aXRlIGNvbW1vbiB0byBtb25pdG9yIGRhdGEgc3RydWN0dXJlcw0KPiA+ID4gd2l0aCBhZGRpdGlv bmFsIGtleXMgb3IgZGlmZmVyZW50IGtleXMuICBUaGlzIGlzIGNvbXBsZXRlbHkgdW5zdXBwb3J0 ZWQNCj4gPiA+IHNvIHNlcGFyYXRlIC9mb28gYW5kIC9mb28tc3RhdGUgdHJlZXMgd2lsbCBzdGls bCBleGlzdC4NCj4gPg0KPiA+IEkgYWdyZWUuDQo+ID4NCj4gPiBMYWRhDQo+ID4NCj4gPiA+DQo+ ID4gPiBJTU8gdGhpcyBjb21iaW5hdGlvbiBvZiB0cmVlcyBuZWVkcyB0byBiZSBwcm92ZW4uDQo+ ID4gPiBUYWtlIGlldGYtaW50ZXJmYWNlcyBhbmQgc2hvdyBob3cgbXVjaCBiZXR0ZXIgaXQgd2ls bCB3b3JrDQo+ID4gPiBpZiB0aGUgL2ludGVyZmFjZXMgYW5kIC9pbnRlcmZhY2VzLXN0YXRlIHRy ZWVzIHdlcmUgY29tYmluZWQuDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEFuZHkNCj4gPiA+DQo+ID4g Pg0KPiA+ID4gVGhlIHRvb2xpbmcgd291bGQgYmUgdGhlcmUgdG8gc3RhdGljYWxseSBnZW5lcmF0 ZSB0aGUgZXh0cmEgZm9vLXN0YXRlDQo+ID4gY29uZmlnIGZhbHNlIG5vZGUgbW9kdWxlcyBmb3Ig c2VydmVycyB0aGF0IGRvbid0IHN1cHBvcnQgdGhlIG9wZXJhdGlvbmFsDQo+ID4gc3RhdGUgZGF0 YXN0b3JlLiAgVGhpcyBjb3VsZCBiZSBkb25lIG9uY2UsIGFuZCB0aGUgZXh0cmEgZm9vLXN0YXRl IG1vZHVsZXMNCj4gPiBjb21taXR0ZWQgdG8gdGhlIGdpdGh1YiBZQU5HIHJlc3Bvc2l0b3J5IGlu IHRoZSBzYW1lIHdheSB0aGF0IG1vZGVscyBhcmUNCj4gPiBleHRyYWN0ZWQgZnJvbSBJRVRGIFJG Q3MgdG9kYXkuDQo+ID4gPg0KPiA+ID4gVGhlIGFpbSBoZXJlIGlzIHRoYXQgdGhlIHNpbmdsZSBt b2RlbCBiZWluZyBwcm9kdWNlZCBieSBJRVRGIHdvdWxkIGJlDQo+ID4gdXNhYmxlIGJvdGggYnkg bmV3IGNsaWVudC9zZXJ2ZXJzIHRoYXQgc3VwcG9ydCBhbiBvcGVyYXRpb25hbCBzdGF0ZQ0KPiA+ IGRhdGFzdG9yZSwgYW5kIGFsc28gYnkgZXhpc3RpbmcgTkVUQ09ORiBjbGllbnQvc2VydmVycyB0 aGF0IGRvbid0IGltcGxlbWVudA0KPiA+IGFuIG9wZXJhdGlvbmFsIHN0YXRlIGRhdGFzdG9yZS4N Cj4gPiA+DQo+ID4gPiBJJ20gbm90IHByb3Bvc2luZyB0aGF0IGFzIGEgbG9uZyB0ZXJtIHNvbHV0 aW9uLCBidXQgYXMgYSBwYXRoIHRvIG1ha2UgaXQNCj4gPiBlYXNpZXIgZm9yIGZvbGsgdG8gbWln cmF0ZSwgYW5kIHRvIG5vdCBzbG93IGRvd24gdGhlIG1vZGVsIHdyaXRpbmcgZWZmb3J0Lg0KPiA+ IE90aGVyd2lzZSwgaXQgbWF5IGJlIGhhcmQgdG8gZ2V0IGEgcHJvdG9jb2wgbW9kZWwgd3JpdGVy IHRvIGRlc2lnbiB0aGUgWUFORw0KPiA+IG1vZGVsIGluIGEgd2F5IHRoYXQgaXMgbm90IGZ1bGx5 IHVzYWJsZSBvbiBhbnkgY3VycmVudCBkZXZpY2VzLg0KPiA+ID4NCj4gPiA+IEFzIGFuIGlsbHVz dHJhdGlvbiwgYW4gUkZDIHB1Ymxpc2hlZCBjb21iaW5lZCBpZXRmLWludGVyZmFjZXMgbW9kZWwg bWF5DQo+ID4gbG9vayBsaWtlIHRoaXM6DQo+ID4gPg0KPiA+DQo+IA0KPiANCj4gT0sgLS0gbGV0 IG1lIHNlZSBpZiBJIHVuZGVyc3RhbmQgdGhlIHZhbHVlIG9mIGNvbWJpbmluZyBpZXRmLWludGVy ZmFjZXMuDQo+IA0KPiANCj4gSGVyZSBpcyB0aGUgc3RhcnRpbmcgdHJlZToNCj4gDQo+IA0KPiAg ICAgICstLXJ3IGludGVyZmFjZXMNCj4gICAgICAgfCAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0N Cj4gICAgICAgfCAgICAgKy0tcncgbmFtZSAgICAgICAgICAgICAgICAgICAgICAgIHN0cmluZw0K PiAgICAgICB8ICAgICArLS1ydyBkZXNjcmlwdGlvbj8gICAgICAgICAgICAgICAgc3RyaW5nDQo+ ICAgICAgIHwgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGl0eXJl Zg0KPiAgICAgICB8ICAgICArLS1ydyBlbmFibGVkPyAgICAgICAgICAgICAgICAgICAgYm9vbGVh bg0KPiAgICAgICB8ICAgICArLS1ydyBsaW5rLXVwLWRvd24tdHJhcC1lbmFibGU/ICAgZW51bWVy YXRpb24NCj4gICAgICAgKy0tcm8gaW50ZXJmYWNlcy1zdGF0ZQ0KPiAgICAgICAgICArLS1ybyBp bnRlcmZhY2UqIFtuYW1lXQ0KPiAgICAgICAgICAgICArLS1ybyBuYW1lICAgICAgICAgICAgICAg c3RyaW5nDQo+ICAgICAgICAgICAgICstLXJvIHR5cGUgICAgICAgICAgICAgICBpZGVudGl0eXJl Zg0KPiAgICAgICAgICAgICArLS1ybyBhZG1pbi1zdGF0dXMgICAgICAgZW51bWVyYXRpb24NCj4g ICAgICAgICAgICAgKy0tcm8gb3Blci1zdGF0dXMgICAgICAgIGVudW1lcmF0aW9uDQo+ICAgICAg ICAgICAgICstLXJvIGxhc3QtY2hhbmdlPyAgICAgICB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gICAg ICAgICAgICAgKy0tcm8gaWYtaW5kZXggICAgICAgICAgIGludDMyDQo+ICAgICAgICAgICAgICst LXJvIHBoeXMtYWRkcmVzcz8gICAgICB5YW5nOnBoeXMtYWRkcmVzcw0KPiAgICAgICAgICAgICAr LS1ybyBoaWdoZXItbGF5ZXItaWYqICAgaW50ZXJmYWNlLXN0YXRlLXJlZg0KPiAgICAgICAgICAg ICArLS1ybyBsb3dlci1sYXllci1pZiogICAgaW50ZXJmYWNlLXN0YXRlLXJlZg0KPiAgICAgICAg ICAgICArLS1ybyBzcGVlZD8gICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQo+ICAgICAgICAgICAg ICstLXJvIHN0YXRpc3RpY3MNCj4gICAgICAgICAgICAgICAgKy0tcm8gZGlzY29udGludWl0eS10 aW1lICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0KPiAgICAgICAgICAgICAgICArLS1ybyBpbi1vY3Rl dHM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICAgICAgICAgKy0tcm8gaW4t dW5pY2FzdC1wa3RzPyAgICAgIHlhbmc6Y291bnRlcjY0DQo+ICAgICAgICAgICAgICAgICstLXJv IGluLWJyb2FkY2FzdC1wa3RzPyAgICB5YW5nOmNvdW50ZXI2NA0KPiAgICAgICAgICAgICAgICAr LS1ybyBpbi1tdWx0aWNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQNCj4gICAgICAgICAgICAg ICAgKy0tcm8gaW4tZGlzY2FyZHM/ICAgICAgICAgIHlhbmc6Y291bnRlcjMyDQo+ICAgICAgICAg ICAgICAgICstLXJvIGluLWVycm9ycz8gICAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiAgICAg ICAgICAgICAgICArLS1ybyBpbi11bmtub3duLXByb3Rvcz8gICAgeWFuZzpjb3VudGVyMzINCj4g DQo+ICAgICAgICAgICAgICAgICstLXJvIG91dC1vY3RldHM/ICAgICAgICAgICB5YW5nOmNvdW50 ZXI2NA0KPiAgICAgICAgICAgICAgICArLS1ybyBvdXQtdW5pY2FzdC1wa3RzPyAgICAgeWFuZzpj b3VudGVyNjQNCj4gICAgICAgICAgICAgICAgKy0tcm8gb3V0LWJyb2FkY2FzdC1wa3RzPyAgIHlh bmc6Y291bnRlcjY0DQo+ICAgICAgICAgICAgICAgICstLXJvIG91dC1tdWx0aWNhc3QtcGt0cz8g ICB5YW5nOmNvdW50ZXI2NA0KPiAgICAgICAgICAgICAgICArLS1ybyBvdXQtZGlzY2FyZHM/ICAg ICAgICAgeWFuZzpjb3VudGVyMzINCj4gICAgICAgICAgICAgICAgKy0tcm8gb3V0LWVycm9ycz8g ICAgICAgICAgIHlhbmc6Y291bnRlcjMyDQo+IA0KPiANCj4gDQo+IFNvIHRoZXNlIGFyZSB0aGUg b2JqZWN0cyB0aGF0IHdvdWxkIG5vIGxvbmdlciBiZSBkdXBsaWNhdGVkOg0KPiANCj4gICAgIC0g bmFtZQ0KPiAgICAgLSB0eXBlDQo+IA0KPiBOZWl0aGVyIG9uZSBpcyBzdXBwb3NlZCB0byBoYXZl IGEgZGlmZmVyZW50IHZhbHVlIGluIG9wZXJhdGlvbmFsIHN0YXRlIHZzDQo+IGNvbmZpZ3VyYXRp b24uDQo+IA0KPiAgICAtIGVuYWJsZWQNCj4gICAgLSBsaW5rLXVwLWRvd24tdHJhcC1lbmFibGUN Cj4gDQo+IFRoZXNlIDIgY291bGQgYmUgZGlmZmVyZW50IGluIG9wZXJhdGlvbmFsIHN0YXRlIEkg c3VwcG9zZS4NCj4gQW4gUlBDIGNhbiBwcm92aWRlIHRoZSBvcGVyYXRpb25hbCB2YWx1ZSB3aXRo b3V0IGNoYW5naW5nIHRoZSBZQU5HIG1vZHVsZQ0KPiANCj4gICAgIHJwYyBnZXQtb3Blci12YWx1 ZSB7DQo+ICAgICAgIGlucHV0IHsNCj4gICAgICAgICAgbGVhZiBub2RlIHsNCj4gICAgICAgICAg ICAgdHlwZSBpbnN0YW5jZS1pZGVudGlmaWVyOw0KPiAgICAgICAgICAgICAgZGVzY3JpcHRpb24g InRoZSBjb25maWc9dHJ1ZSBub2RlIHRvIGNoZWNrIjsNCj4gICAgICAgICAgIH0NCj4gICAgICAg fQ0KPiAgICAgICBvdXRwdXQgew0KPiAgICAgICAgICAgYW55ZGF0YSB2YWx1ZSB7DQo+ICAgICAg ICAgICAgICBkZXNjcmlwdGlvbg0KPiAgICAgICAgICAgICAgICAiY29udGFpbnMgMSBjaGlsZCBu b2RlIG1hdGNoaW5nIHRoZSBpbnB1dCAnbm9kZScgcGFyYW1ldGVyLg0KPiAgICAgICAgICAgICAg ICAgVGhlIHZhbHVlIG9mIHRoZSBub2RlIGlzIHRoZSBjdXJyZW50IG9wZXJhdGlvbmFsIHZhbHVl LiINCj4gICAgICAgICAgIH0NCj4gICAgICB9DQo+ICAgIH0NCg0KVGhpcyBpcyBlc3NlbnRpYWxs eSB3aGF0IHdlIHByb3Bvc2UsIGV4Y2VwdCB0aGF0IHdlIGhhdmUgZ2VuZXJhbGl6ZWQNCml0IHNv IHRoYXQgbW9yZSB0aGFuIG9uZSB2YWx1ZSBjYW4gYmUgcmV0cmVpdmVkOiA8Z2V0LXN0YXRlPiBv cg0KPGdldC1kYXRhPiB3aGljaCB0YWtlcyBhIGZpbHRlciBqdXN0IGxpa2UgPGdldD4uDQoNCg0K PiAgICA8cnBjPg0KPiAgICAgICA8Z2V0LW9wZXItdmFsdWU+DQo+ICAgICAgICAgICA8bm9kZT4v aWY6aW50ZXJmYWNlcy9pZjppbnRlcmZhY2VbaWY6bmFtZT0nZXRoMCddL2VuYWJsZWQ8L25vZGU+ DQo+ICAgICAgIDwvZ2V0LW9wZXItdmFsdWU+DQo+ICAgIDwvcnBjPg0KPiANCj4gDQo+ICAgIDxy cGMtcmVwbHk+DQo+ICAgICAgICA8dmFsdWU+DQo+ICAgICAgICAgICA8aWY6ZW5hYmxlZD5mYWxz ZTwvaWY6ZW5hYmxlZD4NCj4gICAgICAgICA8L3ZhbHVlPg0KPiAgICAgIDwvcnBjLXJlcGx5Pg0K PiANCj4gSSBkb24ndCBuZWVkIHRvIGNoYW5nZSB0aGUgWUFORyBtb2R1bGUgYXQgYWxsIHRvIHN1 cHBvcnQgb3BlcmF0aW9uYWwgc3RhdGUuDQoNCkNvcnJlY3QuICBPbGQgbW9kdWxlcyB3aWxsIGNv bnRpbnVlIHRvIHdvcmsuICBDbGllbnRzIHRoYXQgPGdldC1zdGF0ZT4NCmJvdGggL2ludGVyZmFj ZXMgYW5kIC9pbnRlcmZhY2VzLXN0YXRlIHdpbGwgcmVjZWl2ZSBzb21lIGR1cGxpY2F0ZQ0KZGF0 YS4NCg0KSG93ZXZlciwgdGhlIG5ldyBtb2RlbCBhbGxvd3MgZm9yIGNvbWJpbmVkIHRyZWVzIHRv IGJlIGRlZmluZWQuDQoNCg0KL21hcnRpbg0KDQo+IA0KPiANCj4gQW5keQ0KPiANCj4gDQo+IA0K PiA+ID4gbW9kdWxlOiBpZXRmLWludGVyZmFjZXMtY29tYmluZWQNCj4gPiA+ICAgICArLS1ydyBp bnRlcmZhY2VzDQo+ID4gPiAgICAgICAgKy0tcncgaW50ZXJmYWNlKiBbbmFtZV0NCj4gPiA+ICAg ICAgICAgICArLS1ydyBuYW1lICAgICAgICAgICAgICAgICAgICAgICAgc3RyaW5nDQo+ID4gPiAg ICAgICAgICAgKy0tcncgZGVzY3JpcHRpb24/ICAgICAgICAgICAgICAgIHN0cmluZw0KPiA+ID4g ICAgICAgICAgICstLXJ3IHR5cGUgICAgICAgICAgICAgICAgICAgICAgICBpZGVudGl0eXJlZg0K PiA+ID4gICAgICAgICAgICstLXJ3IGVuYWJsZWQ/ICAgICAgICAgICAgICAgICAgICBib29sZWFu DQo+ID4gPiAgICAgICAgICAgKy0tcncgbGluay11cC1kb3duLXRyYXAtZW5hYmxlPyAgIGVudW1l cmF0aW9uIHtpZi1taWJ9Pw0KPiA+ID4gICAgICAgICAgICstLXJvIG9wZXItc3RhdHVzICAgICAg ICAgICAgICAgICBlbnVtZXJhdGlvbg0KPiA+ID4gICAgICAgICAgICstLXJvIGxhc3QtY2hhbmdl PyB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gPiA+ICAgICAgICAgICArLS1ybyBpZi1pbmRleCAgICAg ICAgICAgICAgICAgICAgaW50MzIge2lmLW1pYn0/DQo+ID4gPiAgICAgICAgICAgKy0tcm8gcGh5 cy1hZGRyZXNzPyB5YW5nOnBoeXMtYWRkcmVzcw0KPiA+ID4gICAgICAgICAgICstLXJvIGhpZ2hl ci1sYXllci1pZiogICAgICAgICAgICBpbnRlcmZhY2UtcmVmDQo+ID4gPiAgICAgICAgICAgKy0t cm8gbG93ZXItbGF5ZXItaWYqICAgICAgICAgICAgIGludGVyZmFjZS1yZWYNCj4gPiA+ICAgICAg ICAgICArLS1ybyBzcGVlZD8gICAgICAgICAgICAgICAgICAgICAgeWFuZzpnYXVnZTY0DQo+ID4g PiAgICAgICAgICAgKy0tcm8gc3RhdGlzdGljcw0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGRp c2NvbnRpbnVpdHktdGltZSAgICB5YW5nOmRhdGUtYW5kLXRpbWUNCj4gPiA+ICAgICAgICAgICAg ICArLS1ybyBpbi1vY3RldHM/ICAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAg ICAgICAgICArLS1ybyBpbi11bmljYXN0LXBrdHM/ICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ ICAgICAgICAgICAgICArLS1ybyBpbi1icm9hZGNhc3QtcGt0cz8gICAgeWFuZzpjb3VudGVyNjQN Cj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1tdWx0aWNhc3QtcGt0cz8gICAgeWFuZzpjb3Vu dGVyNjQNCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1kaXNjYXJkcz8gICAgICAgICAgeWFu Zzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi1lcnJvcnM/ICAgICAgICAg ICAgeWFuZzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBpbi11bmtub3duLXBy b3Rvcz8gICAgeWFuZzpjb3VudGVyMzINCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBvdXQtb2N0 ZXRzPyAgICAgICAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAgICAgICArLS1ybyBv dXQtdW5pY2FzdC1wa3RzPyAgICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAgICAgICAr LS1ybyBvdXQtYnJvYWRjYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAgICAgICAg ICAgICArLS1ybyBvdXQtbXVsdGljYXN0LXBrdHM/ICAgeWFuZzpjb3VudGVyNjQNCj4gPiA+ICAg ICAgICAgICAgICArLS1ybyBvdXQtZGlzY2FyZHM/ICAgICAgICAgeWFuZzpjb3VudGVyMzINCj4g PiA+ICAgICAgICAgICAgICArLS1ybyBvdXQtZXJyb3JzPyAgICAgICAgICAgeWFuZzpjb3VudGVy MzINCj4gPiA+DQo+ID4gPiBUaGUgZXh0cmEgZ2VuZXJhdGVkIG1vZGVsIHdvdWxkIGxvb2sgbGlr ZSB0aGlzOg0KPiA+ID4NCj4gPiA+IG1vZHVsZTogaWV0Zi1pbnRlcmZhY2VzLWNvbWJpbmVkLXN0 YXRlDQo+ID4gPiAgICAgKy0tcm8gaW50ZXJmYWNlcy1zdGF0ZQ0KPiA+ID4gICAgICAgICstLXJv IGludGVyZmFjZSogW25hbWVdDQo+ID4gPiAgICAgICAgICAgKy0tcm8gbmFtZSAgICAgICAgICAg ICAgICAgICAgICAgIHN0cmluZw0KPiA+ID4gICAgICAgICAgICstLXJvIGRlc2NyaXB0aW9uPyAg ICAgICAgICAgICAgICBzdHJpbmcNCj4gPiA+ICAgICAgICAgICArLS1ybyB0eXBlICAgICAgICAg ICAgICAgICAgICAgICAgaWRlbnRpdHlyZWYNCj4gPiA+ICAgICAgICAgICArLS1ybyBlbmFibGVk PyAgICAgICAgICAgICAgICAgICAgYm9vbGVhbg0KPiA+ID4gICAgICAgICAgICstLXJvIGxpbmst dXAtZG93bi10cmFwLWVuYWJsZT8gICBlbnVtZXJhdGlvbiB7aWY6aWYtbWlifT8NCj4gPiA+ICAg ICAgICAgICArLS1ybyBvcGVyLXN0YXR1cyAgICAgICAgICAgICAgICAgZW51bWVyYXRpb24NCj4g PiA+ICAgICAgICAgICArLS1ybyBsYXN0LWNoYW5nZT8geWFuZzpkYXRlLWFuZC10aW1lDQo+ID4g PiAgICAgICAgICAgKy0tcm8gaWYtaW5kZXggICAgICAgICAgICAgICAgICAgIGludDMyIHtpZjpp Zi1taWJ9Pw0KPiA+ID4gICAgICAgICAgICstLXJvIHBoeXMtYWRkcmVzcz8geWFuZzpwaHlzLWFk ZHJlc3MNCj4gPiA+ICAgICAgICAgICArLS1ybyBoaWdoZXItbGF5ZXItaWYqIGlmOmludGVyZmFj ZS1yZWYNCj4gPiA+ICAgICAgICAgICArLS1ybyBsb3dlci1sYXllci1pZiogaWY6aW50ZXJmYWNl LXJlZg0KPiA+ID4gICAgICAgICAgICstLXJvIHNwZWVkPyAgICAgICAgICAgICAgICAgICAgICB5 YW5nOmdhdWdlNjQNCj4gPiA+ICAgICAgICAgICArLS1ybyBzdGF0aXN0aWNzDQo+ID4gPiAgICAg ICAgICAgICAgKy0tcm8gZGlzY29udGludWl0eS10aW1lICAgIHlhbmc6ZGF0ZS1hbmQtdGltZQ0K PiA+ID4gICAgICAgICAgICAgICstLXJvIGluLW9jdGV0cz8gICAgICAgICAgICB5YW5nOmNvdW50 ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLXVuaWNhc3QtcGt0cz8gICAgICB5YW5n OmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLWJyb2FkY2FzdC1wa3RzPyAg ICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLW11bHRpY2FzdC1w a3RzPyAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGluLWRpc2Nh cmRzPyAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICstLXJvIGlu LWVycm9ycz8gICAgICAgICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICst LXJvIGluLXVua25vd24tcHJvdG9zPyAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAg ICAgICstLXJvIG91dC1vY3RldHM/ICAgICAgICAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ID4gICAg ICAgICAgICAgICstLXJvIG91dC11bmljYXN0LXBrdHM/ICAgICB5YW5nOmNvdW50ZXI2NA0KPiA+ ID4gICAgICAgICAgICAgICstLXJvIG91dC1icm9hZGNhc3QtcGt0cz8gICB5YW5nOmNvdW50ZXI2 NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1tdWx0aWNhc3QtcGt0cz8gICB5YW5nOmNv dW50ZXI2NA0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1kaXNjYXJkcz8gICAgICAgICB5 YW5nOmNvdW50ZXIzMg0KPiA+ID4gICAgICAgICAgICAgICstLXJvIG91dC1lcnJvcnM/ICAgICAg ICAgICB5YW5nOmNvdW50ZXIzMg0KPiA+ID4NCj4gPiA+IFNlcnZlcnMgdGhhdCBzdXBwb3J0IG9w ZXJhdGlvbmFsLXN0YXRlIHdvdWxkIGp1c3QgaW1wbGVtZW50DQo+ID4gaWV0Zi1pbnRlcmZhY2Vz LWNvbWJpbmVkDQo+ID4gPg0KPiA+ID4gU2VydmVycyB0aGF0IGRvbid0IHN1cHBvcnQgb3BlcmF0 aW9uYWwtc3RhdGUgY291bGQgaW1wbGVtZW50DQo+ID4gaWV0Zi1pbnRlcmZhY2VzLWNvbWJpbmVk IGFuZCBpZXRmLWludGVyZmFjZXMtY29tYmluZWQtc3RhdGUsIHByb2JhYmx5IG5vdA0KPiA+IGlt cGxlbWVudGluZyB0aGUgZHVwbGljYXRlIGNvbmZpZyBmYWxzZSBsZWF2ZXMgdW5kZXIgdGhlIGlu dGVyZmFjZXMgY29uZmlnDQo+ID4gdHJlZS4gIERldmlhdGlvbnMgY291bGQgYWxzbyBiZSBhdXRv LWdlbmVyYXRlZCB0byByZW1vdmUgdGhlIGNvbmZpZyBmYWxzZQ0KPiA+IGxlYXZlcyBmcm9tIHRo ZSBjb25maWcgdHJlZSBzbyB0aGF0IHRoZXkgYXJlIG9ubHkgaW4gdGhlIHN0YXRlIHRyZWUuDQo+ ID4gPg0KPiA+ID4gT2YgY291cnNlLCBDbGllbnRzIG1heSBuZWVkIHRvIHN1cHBvcnQgYm90aCBz Y2hlbWVzIGRlcGVuZGluZyBvbiB3aGF0DQo+ID4gdHlwZXMgb2YgZGV2aWNlcyB0aGV5IGFyZSBp bnRlcmFjdGluZyB3aXRoLg0KPiA+ID4NCj4gPiA+IEZpbmFsbHksIEkndmUgaWxsdXN0cmF0ZWQg dGhpcyB1c2luZyBpZXRmLWludGVyZmFjZXMsIGJ1dCBJJ20gbm90DQo+ID4gYWN0dWFsbHkgcHJv cG9zaW5nIGltbWVkaWF0ZWx5IGNoYW5naW5nIHRoYXQgbW9kZWwuICBJIHdhcyBtb3JlIHRoaW5r aW5nDQo+ID4gYWJvdXQgSUVURiBwcm90b2NvbHMgdGhhdCBpbiB0aGUgcHJvY2VzcyBvZiB3b3Jr aW5nIG9uIHRoZWlyIFlBTkcgbW9kZWxzLg0KPiA+ID4NCj4gPiA+IFJvYg0KPiA+ID4NCj4gPiA+ DQo+ID4gPiBFeGFjdGx5LiAgSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYSByZWFsIGhhY2suICBJbXBs ZW1lbnRhdGlvbnMgY2FuIHVzZQ0KPiA+ID4gd2hhdGV2ZXIgdHJhbnNmb3JtYXRpb24gdHJpY2tz IHRoZXkgd2FudCBpbiBvcmRlciB0byBjb21wbHkgd2l0aA0KPiA+ID4gZGlmZmVyZW50IHN0YW5k YXJkcywgYnV0IHRoZSBzdGFuZGFyZCBtb2R1bGVzIHNob3VsZCBiZSB2ZXJ5IGNsZWFyLg0KPiA+ ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gL21hcnRpbg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPiA+DQo+ID4gPg0KPiA+ ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+ IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPiA+IG5ldG1vZEBpZXRmLm9yZw0KPiA+ID4gaHR0cHM6 Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4gPg0KPiA+IC0tDQo+ID4g TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPiA+IFBHUCBLZXkgSUQ6IDB4QjhGOTJCMDhB OUY3NkM2Nw0KPiA+DQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4gPg0K From nobody Thu Jan 12 04:53:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 180F312961A for ; Thu, 12 Jan 2017 04:53:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Cehoy-bnQcgU for ; Thu, 12 Jan 2017 04:53:22 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D4770129619 for ; Thu, 12 Jan 2017 04:53:21 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 07CFC1AE044E; Thu, 12 Jan 2017 13:53:20 +0100 (CET) Date: Thu, 12 Jan 2017 13:53:20 +0100 (CET) Message-Id: <20170112.135320.1844651205821472591.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:53:23 -0000 Andy Bierman wrote: > Hi, > > I would like some text in RFC 7950 to be reinterpreted. The text implies > each > notification message can only describe 1 instance of 1 event type. > > RFC 7950, sec 7.16.2 > > The innermost container or list contains an XML > element that carries the name of the defined notification. > > > > There are 3 corner-cases that should be considered in order > to minimize network overhead for notifications in 5277bis. > Replicating the node/key hierarchy could be expensive > and events occurring at the same time could be correlated. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ So how common is this? Is it worth the additional complexity to support this case? How many events would have to be generated at the same time for this "optimization" be worth it? /martin > Duplicating the notification messages is inefficient, > but processing multiple events per message makes > filtering and parsing more complicated. > > I am curious if the WG thinks notification overhead is a concern and > if it needs to be addressed somehow in 5277bis. > > > 1) multiple non-sibling events in same subtree > > > > > > > * * > > * 42* > > * * > > > > eth0 > > * * > > * auto* > > * * > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > eth0 > > * * > > * auto* > > * * > > * * > > * admin* > > * * > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > * * > > * 42* > > * * > > > > > > > > eth0 > > * * > > * auto* > > * * > > > > > > > > > > > Andy From nobody Thu Jan 12 04:59:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9ED12961C for ; Thu, 12 Jan 2017 04:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 U0aob__cX7rf for ; Thu, 12 Jan 2017 04:59:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5A9741295E1 for ; Thu, 12 Jan 2017 04:59:49 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C0C71AE01AA; Thu, 12 Jan 2017 13:59:48 +0100 (CET) Date: Thu, 12 Jan 2017 13:59:47 +0100 (CET) Message-Id: <20170112.135947.218954166063566738.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <39b938d3504f4599bf4e92a48b685a0a@XCH-RTP-013.cisco.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 12:59:51 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBGcmksIEphbiA2 LCAyMDE3IGF0IDk6MjggQU0sIEVyaWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+IHdy b3RlOg0KPiANCj4gPiA+IEZyb206IEFuZHkgQmllcm1hbiwgSmFudWFyeSA1LCAyMDE3IDk6NDMg UE0NCj4gPiA+DQo+ID4gPiBPbiBUaHUsIEphbiA1LCAyMDE3IGF0IDU6MTYgUE0sIEVyaWMgVm9p dCAoZXZvaXQpIDxtYWlsdG86DQo+ID4gZXZvaXRAY2lzY28uY29tPg0KPiA+ID4gd3JvdGU6DQo+ ID4gPiBIaSBBbmR5LA0KPiA+ID4NCj4gPiA+IOKAnFRoZSBpbm5lcm1vc3QgY29udGFpbmVyIG9y IGxpc3TigJ0gdGV4dCBpcyBzaW1pbGFyIHRvIHRoYXQgZm9yIGFjdGlvbnMgaW4NCj4gPiBzZWN0 aW9uDQo+ID4gPiA3LjE1LjIuICAgUGVyaGFwcyB0aGUgbWVudGFsIG1vZGVsIG9mIG9uZSB0YXJn ZXQgZm9yIGFuIGFjdGlvbiB3YXMNCj4gPiByZXBsaWNhdGVkPw0KPiA+ID4NCj4gPiA+IEkgaGFk IG5vdCBjb25zaWRlcmVkIHRoYXQgWUFORyAxLjHigJlzIGRlZmluaXRpb24gbWlnaHQgZm9yY2Ug dGhlIGJyZWFrdXANCj4gPiBvZiBhDQo+ID4gPiB2ZXJib3NlIHNvZnR3YXJlIGNvbXBvbmVudCBn ZW5lcmF0ZWQgbm90aWZpY2F0aW9uIGludG8gbXVsdGlwbGUgcHVzaGVkDQo+ID4gPiBub3RpZmlj YXRpb24gbWVzc2FnZXMuICBMb29raW5nIGF0IHRoZSB0aHJlZSBjYXNlcyBiZWxvdywgSSBkb27i gJl0IHRoaW5rDQo+ID4gdGhhdA0KPiA+ID4gYXJiaXRyYXJ5IGNob2ljZXMgbWFkZSBpbiBZQU5H IG1vZGVsIHN0cnVjdHVyZSBzaG91bGQgaW1wYWN0IHdoYXQgY291bGQNCj4gPiBvcg0KPiA+ID4g Y291bGRu4oCZdCBiZSBpbiBlbmNvZGVkIHdpdGhpbiBhbnkgc2luZ2xlIG5vdGlmaWNhdGlvbi4g IFNvIG15IHByZWZlcmVuY2UNCj4gPiB3b3VsZA0KPiA+ID4gYmUgdGhhdCBhbGwgdGhyZWUgdmFy aWFudHMgYmVsb3cgc2hvdWxkIHN1cHBvcnRhYmxlIGlmIHRoYXQgaXMgaG93IHRoZQ0KPiA+IHN5 c3RlbQ0KPiA+ID4gcGFzc2VkIHRoZW0gdG8gYmUgZW5jb2RlZCBhcyBwYXJ0IG9mIGFuIGV2ZW50 Lg0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gSSB0aGluayB0aGUgV0cgZGlkIG5vdCBjb25z aWRlciB0aGVzZSBkZXRhaWxzIGFuZCBhc3N1bWVkIHRoZXkgd2VyZSB0aGUNCj4gPiBzYW1lDQo+ ID4gPiBhcyBmb3IgYWN0aW9uLg0KPiA+ID4NCj4gPiA+IFRoaXMgd291bGQgYmUgYSBNQVkgZm9y IHRoZSBzZXJ2ZXIgYW5kIGEgTVVTVCBmb3IgdGhlIGNsaWVudCwgc28gaXQgaXMNCj4gPiBub3QN Cj4gPiA+IGFuIGVhc3kgZGVjaXNpb24uDQo+ID4gPg0KPiA+ID4gQSBjb3VwbGUgdXNlLWNhc2Vz IEkgaGF2ZSBpbiBtaW5kOg0KPiA+ID4NCj4gPiA+ICAgMSkgZXZlbnQgYnJva2VyDQo+ID4gPiAg ICAgICBzdWJzY3JpYmVyIGlzIHJlYWxseSBhIGJyb2tlciB0aGF0IG1heSBiZSBwcmUtcHJvY2Vz c2luZyBsb3RzIG9mDQo+ID4gPiAgICAgICBzdWJzY3JpcHRpb25zIG9yIGV2ZW50IHR5cGVzIHdp dGhpbiAxIHN1YnNjcmlwdGlvbg0KPiA+ID4NCj4gPiA+ICAgIDIpIGRpZ2VzdCAodGltZS1iYXNl ZCBwdXNoKQ0KPiA+ID4gICAgICBTdWJzY3JpYmVyIHdhbnRzIGFuIHVwZGF0ZSBldmVyeSA1IHNl Y29uZHMgd2l0aCBhbGwgdGhlIFlBTkcgMS4xDQo+ID4gZXZlbnRzDQo+ID4gPiAgICAgZm9yIHRo ZSBwcmV2aW91cyA1IHNlY29uZHMNCj4gPg0KPiA+IFRoZXNlIGFyZSBib3RoIHJlYXNvbmFibGUg YXMgY29udHJvbGxlcnMgYXJlIHJlcXVpcmluZyBzY2FsYWJsZSBtZXRob2RzIG9mDQo+ID4gc3lu Y2hpbmcgb24gZGV2aWNlIHN0YXR1cy4NCj4gPg0KPiA+ID4gV2hhdCBpZiB0aGUgcmVpbnRlcnBy ZXRhdGlvbiB3ZXJlIGFzIHNpbXBsZSBhcyDigJxBbiBpbm5lcm1vc3TigJ0gb3Ig4oCcVGhlDQo+ ID4gZmlyc3QNCj4gPiA+IGlubmVybW9zdOKAnT8NCj4gPiA+DQo+ID4gPiBUaGlzIGNvdmVycyBj YXNlIDIuIChDaGFuZ2UgIlRoZSIgdG8gIkFuIikuDQo+ID4gPiBUaGUgY2xpZW50IHdvdWxkIG5l ZWQgdG8gY2hlY2sgZm9yIFlBTkcgMS4xIG5vdGlmaWNhdGlvbnMgaW4gdGhlDQo+ID4gPiBzYW1l IHdheSBpdCBjaGVja3MgY2hpbGQgbm9kZXMgYWxyZWFkeS4NCj4gPg0KPiA+ICJBbnkgaW5uZXJt b3N0Ii4uLj8gICBBbmQgeWVzLCB0aGlzIGlzIGEgbW9yZSBzaWduaWZpY2FudCBjaGFuZ2Ugb24g dGhlDQo+ID4gY2xpZW50LiAgQmV5b25kIHRoaXMsIGZvciB1c2UgY2FzZXMgKDEpICYgKDIpLCBp ZiB5b3UgZG9uJ3Qgd2FudCB0bw0KPiA+IHN1bW1hcml6ZSB0aGUgZXZlbnRUaW1lLCB0aGUgdGlt ZSBzaG91bGQgYmUgcGxhY2VkIHdpdGggZWFjaCBpbm5lcm1vc3QNCj4gPiBldmVudC4gIEkgYW0g bm90IHN1Z2dlc3Rpbmcgd2UgZG8gdGhpcywgYnV0IGxpa2UgQW5keSBJIHdhbnQgdG8gZmlndXJl IG91dA0KPiA+IHdoYXQgdGhlIFdHIG1pZ2h0IGJlIHdpbGxpbmcgdG8gY29uc2lkZXIgaW4gc2Nv cGUuDQo+ID4NCj4gPg0KPiANCj4gVGhlcmUgd2FzIGFjdHVhbGx5IGEgbG90IG9mIGRpc2N1c3Np b24gYWJvdXQgImV2ZW50VGltZSIgaW4gdGhlIE5FVENPTkYgV0cNCj4gd2hlbiBSRkMgNTI3NyB3 YXMgZG9uZS4NCj4gTG90cyBvZiBkaXNhZ3JlZW1lbnQgb24gd2hhdCBpdCBtZWFucy4gIFRoZSBS RkMgb2ZmZXJzIGxpdHRsZSBndWlkYW5jZSBvcg0KPiBoaW50IG9mIHRoZSBkaXNjdXNzaW9uOg0K PiANCj4gDQo+ICAgICBldmVudFRpbWU6DQo+ICAgICAgICBUaGUgdGltZSB0aGUgZXZlbnQgd2Fz IGdlbmVyYXRlZCBieSB0aGUgZXZlbnQgc291cmNlLg0KPiANCj4gSXQgbWF5IHRha2UgdGhlIHNl cnZlciBzb21lIHRpbWUgdG8gZGV0ZWN0IHRoZSBldmVudCBhZnRlciBpdCBvY2N1cnMuDQo+IEl0 IG1heSB0YWtlIHNvbWUgdGltZSB0byBzYXZlIHRoZSBldmVudCBmb3IgcmVwbGF5IGFuZCB0cmFu c21pc3Npb24uDQo+IFdoaWNoIG9mIHRoZXNlIDMgZGlmZmVyZW50IHRpbWVzIGlzIGl0PyAoT3V0 IG9mIHNjb3BlIEkgdGhpbmspDQo+IA0KPiBBZGRpbmcgbW9yZSB0aW1lc3RhbXBzIGlzIGFuIGlu dGVyZXN0aW5nIGlkZWEuDQo+IA0KPiBCdXQgSSB0aGluayBzb21ldGhpbmcgbGlrZSB0aGlzIGNv dWxkIGJlIGRvbmUgd2l0aG91dCBhIGNsaWVudCBNVVNULg0KPiBUaGUgY2xpZW50IE1BWSByZXF1 ZXN0ICdidWxrLWVuY29kaW5nJyBhbmQgaWYgdGhlIHNlcnZlciBzdXBwb3J0cyBpdCwNCj4gYSBt b3JlIG9wdGltaXplZCBzdHJ1Y3R1cmUgd291bGQgYmUgc2VudCBpbnN0ZWFkIG9mIHRoZSBub3Jt YWwgbWVzc2FnZS4NCg0KSSBwcmVmZXIgdGhpcyBhcHByb2FjaCwgcmF0aGVyIHRoYW4gdGhlIGV4 YW1wbGUgaW4gdGhlIG9yaWdpbmFsDQplbWFpbC4gIElmIHRoZSBidWxrLWVuY29kZWQgbm90aWZp Y2F0aW9ucyBhcmUgZW5jb2RlZCBpbnRvIGEgbm9ybWFsDQpub3RpZmljYXRpb24sIHdlIGRvbid0 IGhhdmUgdG8gY2hhbmdlIGFueXRoaW5nOg0KDQogIDxub3RpZmljYXRpb24NCiAgICAgIHhtbG5z PSJ1cm46aWV0ZjpwYXJhbXM6eG1sOm5zOm5ldGNvbmY6bm90aWZpY2F0aW9uOjEuMCI+DQogICAg PGV2ZW50VGltZT4yMDE3LTAxLTA4VDAwOjAxOjAwWjwvZXZlbnRUaW1lPg0KICAgIDxidWxrLW5v dGlmaWNhdGlvbnMgeG1sbnM9Ii4uLiI+DQogICAgICA8bm90aWZpY2F0aW9uDQogICAgICAgICAg eG1sbnM9InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIj4N CiAgICAgICAgPGV2ZW50VGltZT4yMDE3LTAxLTA4VDAwOjAwOjAwWjwvZXZlbnRUaW1lPg0KICAg ICAgICA8bGluay11cCAuLi4vPg0KICAgICAgPC9ub3RpZmljYXRpb24+DQoNCiAgICAgIDxub3Rp ZmljYXRpb24NCiAgICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25m Om5vdGlmaWNhdGlvbjoxLjAiPg0KICAgICAgICA8ZXZlbnRUaW1lPjIwMTctMDEtMDhUMDA6MDA6 MDFaPC9ldmVudFRpbWU+DQogICAgICAgIDxsaW5rLWRvd24gLi4uLz4NCiAgICAgIDwvbm90aWZp Y2F0aW9uPg0KICAgICAgLi4uDQogICA8L25vdGlmaWNhdGlvbj4NCiAgICAgIA0KDQoNCi9tYXJ0 aW4NCg0KDQo+IFRoZSByZWNlaXZlciBNQVkgZXh0cmFjdCBpbmRpdmlkdWFsIG1lc3NhZ2VzIGZy b20gdGhlIGJ1bGsgZm9ybWF0IChtYXliZQ0KPiBiaW5hcnkpDQo+IGludG8gb3RoZXIgZm9ybWF0 cyAobGlrZSBYTUwgb3IgSlNPTikuDQo+IA0KPiBJIGFtIHRyeWluZyB0byBwbGFuIGFoZWFkIGZv ciB3aGVuIFlBTkcgUHVzaCB0dXJucyBvdXQgdG8gYmUgYSBzbG93IG5ldHdvcmsNCj4gaG9nIDot KQ0KPiANCj4gDQo+IEVyaWMNCj4gPg0KPiA+DQo+ICBBbmR5DQo+IA0KPiA+IEVyaWMNCj4gPiA+ DQo+ID4gPg0KPiA+ID4gQW5keQ0KPiA+ID4NCj4gPiA+IEZyb206IE5ldGNvbmYgW21haWx0bzpt YWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgQW5keQ0KPiA+ID4g Qmllcm1hbg0KPiA+ID4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgNSwgMjAxNyA1OjI1IFBNDQo+ ID4gPiBUbzogTmV0Y29uZiA8bWFpbHRvOm5ldGNvbmZAaWV0Zi5vcmc+DQo+ID4gPiBTdWJqZWN0 OiBbTmV0Y29uZl0gbmVzdGVkIG5vdGlmaWNhdGlvbnMNCj4gPiA+DQo+ID4gPiBIaSwNCj4gPiA+ DQo+ID4gPiBJIHdvdWxkIGxpa2Ugc29tZSB0ZXh0IGluIFJGQyA3OTUwIHRvIGJlIHJlaW50ZXJw cmV0ZWQuIFRoZSB0ZXh0IGltcGxpZXMNCj4gPiBlYWNoDQo+ID4gPiBub3RpZmljYXRpb24gbWVz c2FnZSBjYW4gb25seSBkZXNjcmliZSAxIGluc3RhbmNlIG9mIDEgZXZlbnQgdHlwZS4NCj4gPiA+ DQo+ID4gPiBSRkMgNzk1MCwgc2VjIDcuMTYuMg0KPiA+ID4NCj4gPiA+ICAgIFRoZSBpbm5lcm1v c3QgY29udGFpbmVyIG9yIGxpc3QgY29udGFpbnMgYW4gWE1MDQo+ID4gPiAgICBlbGVtZW50IHRo YXQgY2FycmllcyB0aGUgbmFtZSBvZiB0aGUgZGVmaW5lZCBub3RpZmljYXRpb24uDQo+ID4gPg0K PiA+ID4NCj4gPiA+IFRoZXJlIGFyZSAzIGNvcm5lci1jYXNlcyB0aGF0IHNob3VsZCBiZSBjb25z aWRlcmVkIGluIG9yZGVyDQo+ID4gPiB0byBtaW5pbWl6ZSBuZXR3b3JrIG92ZXJoZWFkIGZvciBu b3RpZmljYXRpb25zIGluIDUyNzdiaXMuDQo+ID4gPiBSZXBsaWNhdGluZyB0aGUgbm9kZS9rZXkg aGllcmFyY2h5IGNvdWxkIGJlIGV4cGVuc2l2ZQ0KPiA+ID4gYW5kIGV2ZW50cyBvY2N1cnJpbmcg YXQgdGhlIHNhbWUgdGltZSBjb3VsZCBiZSBjb3JyZWxhdGVkLg0KPiA+ID4NCj4gPiA+IER1cGxp Y2F0aW5nIHRoZSBub3RpZmljYXRpb24gbWVzc2FnZXMgaXMgaW5lZmZpY2llbnQsDQo+ID4gPiBi dXQgcHJvY2Vzc2luZyBtdWx0aXBsZSBldmVudHMgcGVyIG1lc3NhZ2UgbWFrZXMNCj4gPiA+IGZp bHRlcmluZyBhbmQgcGFyc2luZyBtb3JlIGNvbXBsaWNhdGVkLg0KPiA+ID4NCj4gPiA+IEkgYW0g Y3VyaW91cyBpZiB0aGUgV0cgdGhpbmtzIG5vdGlmaWNhdGlvbiBvdmVyaGVhZCBpcyBhIGNvbmNl cm4gYW5kDQo+ID4gPiBpZiBpdCBuZWVkcyB0byBiZSBhZGRyZXNzZWQgc29tZWhvdyBpbiA1Mjc3 YmlzLg0KPiA+ID4NCj4gPiA+DQo+ID4gPiAxKSBtdWx0aXBsZSBub24tc2libGluZyBldmVudHMg aW4gc2FtZSBzdWJ0cmVlDQo+ID4gPg0KPiA+ID4gICA8bm90aWZpY2F0aW9uPg0KPiA+ID4gICAg IDxpbnRlcmZhY2VzPg0KPiA+ID4gICAgICAgPG15LXRvcC1ldmVudD4NCj4gPiA+ICAgICAgICAg PG15LWRhdGE+NDI8L215LWRhdGE+DQo+ID4gPiAgICAgICA8L215LXRvcC1ldmVudD4NCj4gPiA+ ICAgICAgIDxpbnRlcmZhY2U+DQo+ID4gPiAgICAgICAgIDxuYW1lPmV0aDA8L25hbWU+DQo+ID4g PiAgICAgICAgIDxteS1pbnRlcmZhY2UtZXZlbnQ+DQo+ID4gPiAgICAgICAgICAgICAgIDxpZi1k YXRhPmF1dG88L2lmLWRhdGE+DQo+ID4gPiAgICAgICAgIDwvbXktaW50ZXJmYWNlLWV2ZW50Pg0K PiA+ID4gICAgICAgPC9pbnRlcmZhY2U+DQo+ID4gPiAgICAgPC9pbnRlcmZhY2VzPg0KPiA+ID4g ICA8L25vdGlmaWNhdGlvbj4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gMikgbXVsdGlwbGUgc2libGlu ZyBldmVudHMgaW4gdGhlIHNhbWUgc3VidHJlZQ0KPiA+ID4NCj4gPiA+ICAgPG5vdGlmaWNhdGlv bj4NCj4gPiA+ICAgICA8aW50ZXJmYWNlcz4NCj4gPiA+ICAgICAgIDxpbnRlcmZhY2U+DQo+ID4g PiAgICAgICAgIDxuYW1lPmV0aDA8L25hbWU+DQo+ID4gPiAgICAgICAgIDxteS1pbnRlcmZhY2Ut ZXZlbnQ+DQo+ID4gPiAgICAgICAgICAgICAgIDxpZi1kYXRhPmF1dG88L2lmLWRhdGE+DQo+ID4g PiAgICAgICAgIDwvbXktaW50ZXJmYWNlLWV2ZW50Pg0KPiA+ID4gICAgICAgICA8aW50ZXJmYWNl LWVuYWJsZWQ+DQo+ID4gPiAgICAgICAgICAgIDxieS11c2VyPmFkbWluPC9ieS11c2VyPg0KPiA+ ID4gICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KPiA+ID4gICAgICAgPC9pbnRlcmZhY2U+ DQo+ID4gPiAgICAgPC9pbnRlcmZhY2VzPg0KPiA+ID4gICA8L25vdGlmaWNhdGlvbj4NCj4gPiA+ DQo+ID4gPg0KPiA+ID4gMykgbXVsdGlwbGUgbm9uLXNpYmxpbmcgZXZlbnRzIGluIGRpZmZlcmVu dCBzdWJ0cmVlcw0KPiA+ID4NCj4gPiA+ICAgPG5vdGlmaWNhdGlvbj4NCj4gPiA+ICAgICA8c3lz dGVtPg0KPiA+ID4gICAgICAgPG15LXN5c3RlbS1ldmVudD4NCj4gPiA+ICAgICAgICAgICAgIDxt eS1kYXRhPjQyPC9teS1kYXRhPg0KPiA+ID4gICAgICAgPC9teS1zeXN0ZW0tZXZlbnQ+DQo+ID4g PiAgICAgPC9zeXN0ZW0+DQo+ID4gPiAgICAgPGludGVyZmFjZXM+DQo+ID4gPiAgICAgICA8aW50 ZXJmYWNlPg0KPiA+ID4gICAgICAgICA8bmFtZT5ldGgwPC9uYW1lPg0KPiA+ID4gICAgICAgICA8 bXktaW50ZXJmYWNlLWV2ZW50Pg0KPiA+ID4gICAgICAgICAgICAgICA8aWYtZGF0YT5hdXRvPC9p Zi1kYXRhPg0KPiA+ID4gICAgICAgICA8L215LWludGVyZmFjZS1ldmVudD4NCj4gPiA+ICAgICAg IDwvaW50ZXJmYWNlPg0KPiA+ID4gICAgIDwvaW50ZXJmYWNlcz4NCj4gPiA+ICAgPC9ub3RpZmlj YXRpb24+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPiBBbmR5DQo+ID4gPg0KPiA+ID4NCj4g Pg0KPiA+DQo= From nobody Thu Jan 12 09:20:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D946F1293EC for ; Thu, 12 Jan 2017 09:19:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mbkgqIJq4fEU for ; Thu, 12 Jan 2017 09:19:56 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 00D5E1294BD for ; Thu, 12 Jan 2017 09:19:55 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id u25so27461849qki.2 for ; Thu, 12 Jan 2017 09:19:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9X6ExlFTK9by5VCRAK8tDvKc9+wppnYra3WaKlBbxSE=; b=GGQXHHnTQruxbZIAsxFbVaOT5bMC9fe5ZNtqNIF0dgK9F7jhitZNC+2f0tehIfCoQ1 u70M/VVI5Ri+WoFOyjFvl8GwzFuxwPLG+iNfdaf7XynhxQCQJrjNu242elJvy+II7j5U d1OM295+cte+l4WJQ0wEXzpnbxqBgO7vOstRQsJHFkteV/uZmIW1aXYCUArp1m0xZuJJ q7gkvCzYelo59kJ0KZ1MoKVjzv3/vtPjCDGMN11YWqhU/QUGSji8qFjKYIRY8ZWU/Jvz tqoA5s65xD4w1hid7zh6Gt7oh6oWO1tlILD3M491sCQN/77TNUgrt0UT520e04Mx0F/J 7YfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9X6ExlFTK9by5VCRAK8tDvKc9+wppnYra3WaKlBbxSE=; b=N5o8owxLK7frT71W2uRrpBXvklXUKAwxZtRPkfuhL0IhBuAYAr3/fx04tTgM3q3Xr/ sThqB77VH25YfdTe1a7JPnik1Cw8vFf/tB9Zo1immgfv1SioUwZnUNL4bgsslc+j5uIK VTfEoSFdGkAuFb31l/r3TOxK1mHuv5tLlddar4Fu8WGC0rqAwZOIbFiFNWCarF5hsTNj 4rEZ8J18IriFGna5K5wzc9I2WO98jYa6/Ypt9w8AgcYEPdxgxL4cNqnRq2CF1WyPgaGQ u0u2fNiANk+LOgoVdR5sL3Dy+0pnK1Ig093sDeFlHlW9XXaJfcqcZDe8zL9dxHkpX1LT gL4g== X-Gm-Message-State: AIkVDXJ3PggquNteMTChAcckeKRdPJ5OfnnWIuc1+S4MGCOuZizxtXNL9jp++1iiJe6yY8ygrike1PlWWM6mWw== X-Received: by 10.55.22.97 with SMTP id g94mr13869401qkh.287.1484241595041; Thu, 12 Jan 2017 09:19:55 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:19:54 -0800 (PST) In-Reply-To: <20170112.134737.887226373918047146.mbj@tail-f.com> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 09:19:54 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a114967ea08bd820545e8ed9e Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:20:00 -0000 --001a114967ea08bd820545e8ed9e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 4:47 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka wrote: > > > > > > > > > On 11 Jan 2017, at 17:56, Andy Bierman wrote: > > > > > > > > Hi, > > > > > > > > > > > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton > > > wrote: > > > > > > > > > > > > On 11/01/2017 09:22, Martin Bjorklund wrote: > > > > Andy Bierman wrote: > > > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen > > > wrote: > > > > > > > > I think it is better to have a human decide what is in the module > > > > instead of relying on a pyang plugin to generate some additional > module > > > > that follows some simplistic pattern. > > > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s only beca= use it=E2=80=99s not > tricky > > > ;) > > > > > > > > > > > > The client and server developers still need to know about this > > > > auto-generated module > > > > and implement it. Operators might have to know about it to use it. > > > > My idea is not to auto generate models on the fly. > > > > > > > > My aim is to allow folks to start writing models in the desired lon= g > > > term format (i.e. combined config and state tree) with the model > designer > > > being able to assume the existence of the operational state datastore= . > > > > > > > > > > > > > > > > I am not convinced this "new format" has solved anything. > > > > Don't you need separate description-stmts in every node for each > > > > datastore? What does the value mean if pre-configured? configured? > > > > operational? Will the auto-generated objects be exactly correct > > > > and never need any alterations or additional text? > > > > They still need to be used by developers and YANG tools. > > > > > > Right, this is one problem of this "deduplication": even if two nodes= - > > > one config and the other state - have the same name or even type > (which is > > > not always the case, as we know), their semantics is often different. > An IP > > > address in configuration means a manually configured address whereas = in > > > state it may come from any source. So writing sensible descriptions > will > > > become tricky. > > > > > > > > > > > Is is that realistic to force the config structure and operational > > > structure > > > > to be the same? Seems it is quite common to monitor data structures > > > > with additional keys or different keys. This is completely > unsupported > > > > so separate /foo and /foo-state trees will still exist. > > > > > > I agree. > > > > > > Lada > > > > > > > > > > > IMO this combination of trees needs to be proven. > > > > Take ietf-interfaces and show how much better it will work > > > > if the /interfaces and /interfaces-state trees were combined. > > > > > > > > > > > > Andy > > > > > > > > > > > > The tooling would be there to statically generate the extra foo-sta= te > > > config false node modules for servers that don't support the > operational > > > state datastore. This could be done once, and the extra foo-state > modules > > > committed to the github YANG respository in the same way that models > are > > > extracted from IETF RFCs today. > > > > > > > > The aim here is that the single model being produced by IETF would = be > > > usable both by new client/servers that support an operational state > > > datastore, and also by existing NETCONF client/servers that don't > implement > > > an operational state datastore. > > > > > > > > I'm not proposing that as a long term solution, but as a path to > make it > > > easier for folk to migrate, and to not slow down the model writing > effort. > > > Otherwise, it may be hard to get a protocol model writer to design th= e > YANG > > > model in a way that is not fully usable on any current devices. > > > > > > > > As an illustration, an RFC published combined ietf-interfaces model > may > > > look like this: > > > > > > > > > > > > > OK -- let me see if I understand the value of combining ietf-interfaces= . > > > > > > Here is the starting tree: > > > > > > +--rw interfaces > > | +--rw interface* [name] > > | +--rw name string > > | +--rw description? string > > | +--rw type identityref > > | +--rw enabled? boolean > > | +--rw link-up-down-trap-enable? enumeration > > +--ro interfaces-state > > +--ro interface* [name] > > +--ro name string > > +--ro type identityref > > +--ro admin-status enumeration > > +--ro oper-status enumeration > > +--ro last-change? yang:date-and-time > > +--ro if-index int32 > > +--ro phys-address? yang:phys-address > > +--ro higher-layer-if* interface-state-ref > > +--ro lower-layer-if* interface-state-ref > > +--ro speed? yang:gauge64 > > +--ro statistics > > +--ro discontinuity-time yang:date-and-time > > +--ro in-octets? yang:counter64 > > +--ro in-unicast-pkts? yang:counter64 > > +--ro in-broadcast-pkts? yang:counter64 > > +--ro in-multicast-pkts? yang:counter64 > > +--ro in-discards? yang:counter32 > > +--ro in-errors? yang:counter32 > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > +--ro out-unicast-pkts? yang:counter64 > > +--ro out-broadcast-pkts? yang:counter64 > > +--ro out-multicast-pkts? yang:counter64 > > +--ro out-discards? yang:counter32 > > +--ro out-errors? yang:counter32 > > > > > > > > So these are the objects that would no longer be duplicated: > > > > - name > > - type > > > > Neither one is supposed to have a different value in operational state = vs > > configuration. > > > > - enabled > > - link-up-down-trap-enable > > > > These 2 could be different in operational state I suppose. > > An RPC can provide the operational value without changing the YANG modu= le > > > > rpc get-oper-value { > > input { > > leaf node { > > type instance-identifier; > > description "the config=3Dtrue node to check"; > > } > > } > > output { > > anydata value { > > description > > "contains 1 child node matching the input 'node' > parameter. > > The value of the node is the current operational value.= " > > } > > } > > } > > This is essentially what we propose, except that we have generalized > it so that more than one value can be retreived: or > which takes a filter just like . > > OK How do I retrieve the same subtree from multiple contexts at once so I can reduce time-skew caused by retrieving config-tree then oper-tree? > > > > > > > /if:interfaces/if:interface[if:name=3D'eth0']/ > enabled > > > > > > > > > > > > > > false > > > > > > > > I don't need to change the YANG module at all to support operational > state. > > Correct. Old modules will continue to work. Clients that > both /interfaces and /interfaces-state will receive some duplicate > data. > > However, the new model allows for combined trees to be defined. > > Here are the things that do not work anymore if a designer uses the new tree approach: YANG statements: - It is not possible to define these statements so they are different for config and oper - must - when - unique - key - min-elements - max-elements - leafref (path) - if-feature - deviation - type (or any sub-statements of type-stmt) - status - description - reference YANG allows must-when to reference state data nodes in every XPath context except 1: - state data - RPC input - RPC output - action input - action output - notification payload Seems like you are removing a lot of YANG functionality in order to make the problem-space fit your solution-space. > > /martin > > > > > > > Andy > > > Andy > > > > > > > > module: ietf-interfaces-combined > > > > +--rw interfaces > > > > +--rw interface* [name] > > > > +--rw name string > > > > +--rw description? string > > > > +--rw type identityref > > > > +--rw enabled? boolean > > > > +--rw link-up-down-trap-enable? enumeration {if-mib}? > > > > +--ro oper-status enumeration > > > > +--ro last-change? yang:date-and-time > > > > +--ro if-index int32 {if-mib}? > > > > +--ro phys-address? yang:phys-address > > > > +--ro higher-layer-if* interface-ref > > > > +--ro lower-layer-if* interface-ref > > > > +--ro speed? yang:gauge64 > > > > +--ro statistics > > > > +--ro discontinuity-time yang:date-and-time > > > > +--ro in-octets? yang:counter64 > > > > +--ro in-unicast-pkts? yang:counter64 > > > > +--ro in-broadcast-pkts? yang:counter64 > > > > +--ro in-multicast-pkts? yang:counter64 > > > > +--ro in-discards? yang:counter32 > > > > +--ro in-errors? yang:counter32 > > > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > > > +--ro out-unicast-pkts? yang:counter64 > > > > +--ro out-broadcast-pkts? yang:counter64 > > > > +--ro out-multicast-pkts? yang:counter64 > > > > +--ro out-discards? yang:counter32 > > > > +--ro out-errors? yang:counter32 > > > > > > > > The extra generated model would look like this: > > > > > > > > module: ietf-interfaces-combined-state > > > > +--ro interfaces-state > > > > +--ro interface* [name] > > > > +--ro name string > > > > +--ro description? string > > > > +--ro type identityref > > > > +--ro enabled? boolean > > > > +--ro link-up-down-trap-enable? enumeration {if:if-mib}= ? > > > > +--ro oper-status enumeration > > > > +--ro last-change? yang:date-and-time > > > > +--ro if-index int32 {if:if-mib}? > > > > +--ro phys-address? yang:phys-address > > > > +--ro higher-layer-if* if:interface-ref > > > > +--ro lower-layer-if* if:interface-ref > > > > +--ro speed? yang:gauge64 > > > > +--ro statistics > > > > +--ro discontinuity-time yang:date-and-time > > > > +--ro in-octets? yang:counter64 > > > > +--ro in-unicast-pkts? yang:counter64 > > > > +--ro in-broadcast-pkts? yang:counter64 > > > > +--ro in-multicast-pkts? yang:counter64 > > > > +--ro in-discards? yang:counter32 > > > > +--ro in-errors? yang:counter32 > > > > +--ro in-unknown-protos? yang:counter32 > > > > +--ro out-octets? yang:counter64 > > > > +--ro out-unicast-pkts? yang:counter64 > > > > +--ro out-broadcast-pkts? yang:counter64 > > > > +--ro out-multicast-pkts? yang:counter64 > > > > +--ro out-discards? yang:counter32 > > > > +--ro out-errors? yang:counter32 > > > > > > > > Servers that support operational-state would just implement > > > ietf-interfaces-combined > > > > > > > > Servers that don't support operational-state could implement > > > ietf-interfaces-combined and ietf-interfaces-combined-state, probably > not > > > implementing the duplicate config false leaves under the interfaces > config > > > tree. Deviations could also be auto-generated to remove the config > false > > > leaves from the config tree so that they are only in the state tree. > > > > > > > > Of course, Clients may need to support both schemes depending on wh= at > > > types of devices they are interacting with. > > > > > > > > Finally, I've illustrated this using ietf-interfaces, but I'm not > > > actually proposing immediately changing that model. I was more > thinking > > > about IETF protocols that in the process of working on their YANG > models. > > > > > > > > Rob > > > > > > > > > > > > Exactly. I agree that this is a real hack. Implementations can us= e > > > > whatever transformation tricks they want in order to comply with > > > > different standards, but the standard modules should be very clear. > > > > > > > > > > > > > > > > > > > > > > > > > > > > /martin > > > > _______________________________________________ > > > > 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 > > > > > > -- > > > Ladislav Lhotka, CZ.NIC Labs > > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > > > > > > > > > > > > > > > > --001a114967ea08bd820545e8ed9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 4:47 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Jan 11, 2017 at 9:21 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> >
> > > On 11 Jan 2017, at 17:56, Andy Bierman <andy@yumaworks.com> wrote:
> > >
> > > Hi,
> > >
> > >
> > > On Wed, Jan 11, 2017 at 7:12 AM, Robert Wilton <rwilton@cisco.com>
> > wrote:
> > >
> > >
> > > On 11/01/2017 09:22, Martin Bjorklund wrote:
> > > Andy Bierman <andy@= yumaworks.com> wrote:
> > > On Tue, Jan 10, 2017 at 1:20 PM, Kent Watsen <kwatsen@juniper.net>
> > wrote:
> > >
> > > I think it is better to have a human decide what is in the m= odule
> > > instead of relying on a pyang plugin to generate some additi= onal module
> > > that follows some simplistic pattern.
> > > It may be simple, but I=E2=80=99m thinking that=E2=80=99s on= ly because it=E2=80=99s not tricky
> > ;)
> > >
> > >
> > > The client and server developers still need to know about th= is
> > > auto-generated module
> > > and implement it.=C2=A0 Operators might have to know about i= t to use it.
> > > My idea is not to auto generate models on the fly.
> > >
> > > My aim is to allow folks to start writing models in the desi= red long
> > term format (i.e. combined config and state tree) with the model = designer
> > being able to assume the existence of the operational state datas= tore.
> > >
> > >
> > >
> > > I am not convinced this "new format" has solved an= ything.
> > > Don't you need separate description-stmts in every node = for each
> > > datastore?=C2=A0 What does the value mean if pre-configured?= configured?
> > > operational?=C2=A0 Will the auto-generated objects be exactl= y correct
> > > and never need any alterations or additional text?
> > > They still need to be used by developers and YANG tools.
> >
> > Right, this is one problem of this "deduplication": eve= n if two nodes -
> > one config and the other state - have the same name or even type = (which is
> > not always the case, as we know), their semantics is often differ= ent. An IP
> > address in configuration means a manually configured address wher= eas in
> > state it may come from any source. So writing sensible descriptio= ns will
> > become tricky.
> >
> > >
> > > Is is that realistic to force the config structure and opera= tional
> > structure
> > > to be the same? Seems it is quite common to monitor data str= uctures
> > > with additional keys or different keys.=C2=A0 This is comple= tely unsupported
> > > so separate /foo and /foo-state trees will still exist.
> >
> > I agree.
> >
> > Lada
> >
> > >
> > > IMO this combination of trees needs to be proven.
> > > Take ietf-interfaces and show how much better it will work > > > if the /interfaces and /interfaces-state trees were combined= .
> > >
> > >
> > > Andy
> > >
> > >
> > > The tooling would be there to statically generate the extra = foo-state
> > config false node modules for servers that don't support the = operational
> > state datastore.=C2=A0 This could be done once, and the extra foo= -state modules
> > committed to the github YANG respository in the same way that mod= els are
> > extracted from IETF RFCs today.
> > >
> > > The aim here is that the single model being produced by IETF= would be
> > usable both by new client/servers that support an operational sta= te
> > datastore, and also by existing NETCONF client/servers that don&#= 39;t implement
> > an operational state datastore.
> > >
> > > I'm not proposing that as a long term solution, but as a= path to make it
> > easier for folk to migrate, and to not slow down the model writin= g effort.
> > Otherwise, it may be hard to get a protocol model writer to desig= n the YANG
> > model in a way that is not fully usable on any current devices. > > >
> > > As an illustration, an RFC published combined ietf-interface= s model may
> > look like this:
> > >
> >
>
>
> OK -- let me see if I understand the value of combining ietf-interface= s.
>
>
> Here is the starting tree:
>
>
>=C2=A0 =C2=A0 =C2=A0 +--rw interfaces
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 +--rw interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 stri= ng
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw description?=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 iden= tityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
>=C2=A0 =C2=A0 =C2=A0 =C2=A0|=C2=A0 =C2=A0 =C2=A0+--rw link-up-down-trap= -enable?=C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0string
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identityref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro admin-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2=A0= =C2=A0 =C2=A0 =C2=A0 enumeration
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change?=C2= =A0 =C2=A0 =C2=A0 =C2=A0yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0int32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address?=C2= =A0 =C2=A0 =C2=A0 yang:phys-address
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-if*= =C2=A0 =C2=A0interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if*= =C2=A0 =C2=A0 interface-state-ref
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:gauge64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discontin= uity-time=C2=A0 =C2=A0 yang:date-and-time
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-octets= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unicas= t-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-broadc= ast-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-multic= ast-pkts?=C2=A0 =C2=A0 yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-discar= ds?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-errors= ?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unknow= n-protos?=C2=A0 =C2=A0 yang:counter32
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-octet= s?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-unica= st-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-broad= cast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-multi= cast-pkts?=C2=A0 =C2=A0yang:counter64
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-disca= rds?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-error= s?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
>
>
>
> So these are the objects that would no longer be duplicated:
>
>=C2=A0 =C2=A0 =C2=A0- name
>=C2=A0 =C2=A0 =C2=A0- type
>
> Neither one is supposed to have a different value in operational state= vs
> configuration.
>
>=C2=A0 =C2=A0 - enabled
>=C2=A0 =C2=A0 - link-up-down-trap-enable
>
> These 2 could be different in operational state I suppose.
> An RPC can provide the operational value without changing the YANG mod= ule
>
>=C2=A0 =C2=A0 =C2=A0rpc get-oper-value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0input {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 leaf node {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0type instance-identifie= r;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "the = config=3Dtrue node to check";
>=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=A0output {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0anydata value {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 "contains = 1 child node matching the input 'node' parameter.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The value= of the node is the current operational value."
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>=C2=A0 =C2=A0 =C2=A0 }
>=C2=A0 =C2=A0 }

This is essentially what we propose, except that we have generalized
it so that more than one value can be retreived: <get-state> or
<get-data> which takes a filter just like <get>.


OK

How do I r= etrieve the same subtree from multiple contexts at once
so I can = reduce time-skew caused by retrieving config-tree then oper-tree?
=C2=A0

>=C2=A0 =C2=A0 <rpc>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<get-oper-value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<node>/if:interfaces/if:= interface[if:name=3D'eth0']/enabled</node>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</get-oper-value>
>=C2=A0 =C2=A0 </rpc>
>
>
>=C2=A0 =C2=A0 <rpc-reply>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 <value>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<if:enabled>false</if= :enabled>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</value>
>=C2=A0 =C2=A0 =C2=A0 </rpc-reply>
>
> I don't need to change the YANG module at all to support operation= al state.

Correct.=C2=A0 Old modules will continue to work.=C2=A0 Clients that <ge= t-state>
both /interfaces and /interfaces-state will receive some duplicate
data.

However, the new model allows for combined trees to be defined.



Here are the things tha= t do not work anymore if a designer uses the new tree approach:
<= br>

YANG statements:
=C2=A0 =C2=A0- It i= s not possible to define these statements so they are different for config = and oper
=C2=A0 =C2=A0 =C2=A0 - must
=C2=A0 =C2=A0 =C2= =A0 - when
=C2=A0 =C2=A0 =C2=A0 - unique
=C2=A0 =C2=A0 = =C2=A0 - key
=C2=A0 =C2=A0 =C2=A0 - min-elements
=C2=A0= =C2=A0 =C2=A0 - max-elements
=C2=A0 =C2=A0 =C2=A0 - leafref (pat= h)
=C2=A0 =C2=A0 =C2=A0 - if-feature
=C2=A0 =C2=A0 =C2= =A0 - deviation
=C2=A0 =C2=A0 =C2=A0 - type (or any sub-statement= s of type-stmt)
=C2=A0 =C2=A0 =C2=A0 - status
=C2=A0 = =C2=A0 =C2=A0 - description
=C2=A0 =C2=A0 =C2=A0 - reference

YANG allows must-when to reference state data nodes in= every XPath context except 1:
=C2=A0 =C2=A0- state data
=C2=A0 =C2=A0- RPC input
=C2=A0 =C2=A0- RPC output
= =C2=A0 =C2=A0- action input
=C2=A0 =C2=A0- action output
=C2=A0 =C2=A0- notification payload

Seems like y= ou are removing a lot of YANG functionality in order to make the problem-sp= ace
fit your solution-space.

=C2=A0

/martin

>
>
> Andy
>


Andy
=C2= =A0
>
>
> > > module: ietf-interfaces-combined
> > >=C2=A0 =C2=A0 =C2=A0+--rw interfaces
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--rw interface* [name]
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= tring
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw description?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw type=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= dentityref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw enabled?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--rw link-up-down-t= rap-enable?=C2=A0 =C2=A0enumeration {if-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? y= ang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if-m= ib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? = yang:phys-address
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-i= f*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if= *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:= gauge64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discon= tinuity-time=C2=A0 =C2=A0 yang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-oct= ets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-uni= cast-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-bro= adcast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-mul= ticast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-dis= cards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-err= ors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unk= nown-protos?=C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-oc= tets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-un= icast-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-br= oadcast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-mu= lticast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-di= scards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-er= rors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >
> > > The extra generated model would look like this:
> > >
> > > module: ietf-interfaces-combined-state
> > >=C2=A0 =C2=A0 =C2=A0+--ro interfaces-state
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro interface* [name]
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro name=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 s= tring
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro description?= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 string
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro type=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 i= dentityref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro enabled?=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 boolean
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro link-up-down-t= rap-enable?=C2=A0 =C2=A0enumeration {if:if-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro oper-status=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0enumeration
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro last-change? y= ang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro if-index=C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 int32 {if:i= f-mib}?
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro phys-address? = yang:phys-address
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro higher-layer-i= f* if:interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro lower-layer-if= * if:interface-ref
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro speed?=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:= gauge64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+--ro statistics
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro discon= tinuity-time=C2=A0 =C2=A0 yang:date-and-time
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-oct= ets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-uni= cast-pkts?=C2=A0 =C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-bro= adcast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-mul= ticast-pkts?=C2=A0 =C2=A0 yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-dis= cards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-err= ors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro in-unk= nown-protos?=C2=A0 =C2=A0 yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-oc= tets?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-un= icast-pkts?=C2=A0 =C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-br= oadcast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-mu= lticast-pkts?=C2=A0 =C2=A0yang:counter64
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-di= scards?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 +--ro out-er= rors?=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0yang:counter32
> > >
> > > Servers that support operational-state would just implement<= br> > > ietf-interfaces-combined
> > >
> > > Servers that don't support operational-state could imple= ment
> > ietf-interfaces-combined and ietf-interfaces-combined-state,= probably not
> > implementing the duplicate config false leaves under the interfac= es config
> > tree.=C2=A0 Deviations could also be auto-generated to remove the= config false
> > leaves from the config tree so that they are only in the state tr= ee.
> > >
> > > Of course, Clients may need to support both schemes dependin= g on what
> > types of devices they are interacting with.
> > >
> > > Finally, I've illustrated this using ietf-interfaces, bu= t I'm not
> > actually proposing immediately changing that model.=C2=A0 I was m= ore thinking
> > about IETF protocols that in the process of working on their YANG= models.
> > >
> > > Rob
> > >
> > >
> > > Exactly.=C2=A0 I agree that this is a real hack.=C2=A0 Imple= mentations can use
> > > whatever transformation tricks they want in order to comply = with
> > > different standards, but the standard modules should be very= clear.
> > >
> > >
> > >
> > >
> > >
> > >
> > > /martin
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/netmod
> > >
> > >
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinf= o/netmod
> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> >
> >
> >
> >
> >
> >

--001a114967ea08bd820545e8ed9e-- From nobody Thu Jan 12 09:25:28 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 313251294CF for ; Thu, 12 Jan 2017 09:25:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5WY0Ke8_Pnfq for ; Thu, 12 Jan 2017 09:25:25 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01DD9128BA2 for ; Thu, 12 Jan 2017 09:25:25 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v23so24493884qtb.0 for ; Thu, 12 Jan 2017 09:25:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M2SdgFNTATfwkxscH3LmQ7oh0IK/utmGC5GiaSEfUxw=; b=CJ76mv3khdKC5sxUKtWVvFiToWjPMA2pBWP8Bfv98ih4dJ/wSsoF4yh4zpLgmcZ3Z3 iaaT8R7Nyd7z1SnNDDeLYnSKLpusXMeklxLUADwAN365yb8ErE5URoECKnuHQL5EALh4 6W99FYTwW1r3iHqjkph3xYYBsd5Msj1EsOvSFMHF4dK67DOxoBn1Gtl2zbQoDePAWRVy dZ11S8HaRfjv9bZ9vE/I9lFvID1xcDBRJ1pPd1xJTrOUnJVzRNpxnpD16Nb446myreI+ EgudtRpR9+bnjSaDxuoptMlCZEtcCi3/jm41/7SY22oMs9ns4lu++Q9pfd9Vf2vVktTa QA+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M2SdgFNTATfwkxscH3LmQ7oh0IK/utmGC5GiaSEfUxw=; b=GQoyn1yVmF+HQ0ASv8j27zXsxlgtKMYEu8a3PGlIKDVVIkZoI3R1u7tORDLX5vKOBY kMV8I20QQMD8jf0Rfv6wEbAjqatRffzks83MdDph/mwnh23ztwS5B4m025EkhFYJfDoZ br3JUGgNzqxOgHjEW6Psqqlcz3aRFkrDVoD9kdrV5XiXpVtZSKfxH2f+7FoJktWMdh76 JK4pmuSqaqHICriAZyNFch8fT0TEw9CeERs7unqUzUuq3MlbP8+sisPSGidZwtUGudEc dWORH8Y4iHK9rcx47DuE5RJbW5YzzGRAUa9HdS2hcP0g5hQA4mN2ULuKShcbOJDGWxwY XK6g== X-Gm-Message-State: AIkVDXKfRqmoaYjL3jlNDCqt3ZNST6MU2Aiz6PHKAvGsNc10XxNSDwaW3aKp6M34sCmy+lUL9FUiesZeMP9Jvw== X-Received: by 10.200.48.235 with SMTP id w40mr13397296qta.72.1484241924107; Thu, 12 Jan 2017 09:25:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:25:23 -0800 (PST) In-Reply-To: <20170112.135320.1844651205821472591.mbj@tail-f.com> References: <20170112.135320.1844651205821472591.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 09:25:23 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a11404a48a5c3e90545e90039 Archived-At: Cc: Netconf Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:25:27 -0000 --001a11404a48a5c3e90545e90039 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 4:53 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > Hi, > > > > I would like some text in RFC 7950 to be reinterpreted. The text implies > > each > > notification message can only describe 1 instance of 1 event type. > > > > RFC 7950, sec 7.16.2 > > > > The innermost container or list contains an XML > > element that carries the name of the defined notification. > > > > > > > > There are 3 corner-cases that should be considered in order > > to minimize network overhead for notifications in 5277bis. > > Replicating the node/key hierarchy could be expensive > > and events occurring at the same time could be correlated. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > > So how common is this? Is it worth the additional complexity to > support this case? How many events would have to be generated at the > same time for this "optimization" be worth it? > > Depends on the meaning of "same time". If I am implementing a client-configured digest service, and the client only wants to receive notifications every 1 - 5 seconds instead of ASAP. I can build up a tree of YANG 1.1 notifications and send it off in N seconds, then start a new tree. I agree it is very implementation dependent whether or not the originator of the event will combine that event with others. (Most likely not). > > /martin > > Andy > > > Duplicating the notification messages is inefficient, > > but processing multiple events per message makes > > filtering and parsing more complicated. > > > > I am curious if the WG thinks notification overhead is a concern and > > if it needs to be addressed somehow in 5277bis. > > > > > > 1) multiple non-sibling events in same subtree > > > > > > > > > > > > > > * * > > > > * 42* > > > > * * > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > > > > > > > > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > > > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > * * > > > > * admin* > > > > * * > > > > > > > > > > > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > > > > > > > > * * > > > > * 42* > > > > * * > > > > > > > > > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > > > > > > > > > > > > > > > > > > > Andy > --001a11404a48a5c3e90545e90039 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 4:53 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> Hi,
>
> I would like some text in RFC 7950 to be reinterpreted. The text impli= es
> each
> notification message can only describe 1 instance of 1 event type.
>
> RFC 7950, sec 7.16.2
>
>=C2=A0 =C2=A0 The innermost container or list contains an XML
>=C2=A0 =C2=A0 element that carries the name of the defined notification= .
>
>
>
> There are 3 corner-cases that should be considered in order
> to minimize network overhead for notifications in 5277bis.
> Replicating the node/key hierarchy could be expensive
> and events occurring at the same time could be correlated.
=C2=A0 =C2=A0 =C2=A0 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^= ^^^^^

So how common is this?=C2=A0 Is it worth the additional complexity to
support this case?=C2=A0 How many events would have to be generated at the<= br> same time for this "optimization" be worth it?


Depends on the meaning of "same t= ime".
If I am implementing a client-configured digest servic= e, and the client only
wants to receive notifications every 1 - 5= seconds instead of ASAP.
I can build up a tree of YANG 1.1 notif= ications and send it off in N seconds,
then start a new tree.

I agree it is very implementation dependent whether o= r not the originator of the event
will combine that event with ot= hers. (Most likely not).

=C2=A0

/martin


Andy
=C2=A0

> Duplicating the notification messages is inefficient,
> but processing multiple events per message makes
> filtering and parsing more complicated.
>
> I am curious if the WG thinks notification overhead is a concern and > if it needs to be addressed somehow in 5277bis.
>
>
> 1) multiple non-sibling events in same subtree
>
>
>=C2=A0 =C2=A0<notification>
>
>=C2=A0 =C2=A0 =C2=A0<interfaces>
>
>=C2=A0 =C2=A0 =C2=A0*=C2=A0 <my-top-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 <my-data>42</my-data>*
>
> *=C2=A0 =C2=A0 =C2=A0 </my-top-event>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
>
>=C2=A0 =C2=A0 =C2=A0*=C2=A0 =C2=A0 <my-interface-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <if-data>auto&= lt;/if-data>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 </my-interface-event>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
>
>=C2=A0 =C2=A0 =C2=A0</interfaces>
>
>=C2=A0 =C2=A0</notification>
>
>
>
> 2) multiple sibling events in the same subtree
>
>
>=C2=A0 =C2=A0<notification>
>
>=C2=A0 =C2=A0 =C2=A0<interfaces>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
>
>=C2=A0 =C2=A0 =C2=A0 *=C2=A0 =C2=A0<my-interface-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <if-data>auto&= lt;/if-data>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 </my-interface-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 <interface-enabled>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<by-user>admin</by-= user>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 </interface-enabled>=C2=A0 *
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
>
>=C2=A0 =C2=A0 =C2=A0</interfaces>
>
>=C2=A0 =C2=A0</notification>
>
>
>
> 3) multiple non-sibling events in different subtrees
>
>
>=C2=A0 =C2=A0<notification>
>
>=C2=A0 =C2=A0 =C2=A0<system>
>
>=C2=A0 =C2=A0 *=C2=A0 =C2=A0<my-system-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <my-data>42</my-da= ta>*
>
> *=C2=A0 =C2=A0 =C2=A0 </my-system-event>*
>
>=C2=A0 =C2=A0 =C2=A0</system>
>
>=C2=A0 =C2=A0 =C2=A0<interfaces>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 * <my-interface-event>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <if-data>auto&= lt;/if-data>*
>
> *=C2=A0 =C2=A0 =C2=A0 =C2=A0 </my-interface-event>*
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
>
>=C2=A0 =C2=A0 =C2=A0</interfaces>
>
>=C2=A0 =C2=A0</notification>
>
>
>
>
> Andy

--001a11404a48a5c3e90545e90039-- From nobody Thu Jan 12 09:34:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 061E312959B; Thu, 12 Jan 2017 09:34:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 U-diHiLb_sOZ; Thu, 12 Jan 2017 09:34:04 -0800 (PST) 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 8180412956C; Thu, 12 Jan 2017 09:34:04 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id D6EA06D5; Thu, 12 Jan 2017 18:34:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ggU5cZL2ve18; Thu, 12 Jan 2017 18:33:59 +0100 (CET) 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, 12 Jan 2017 18:34:02 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 95AD720091; Thu, 12 Jan 2017 18:34:02 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id sQx4bIXLdDm5; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2AE462008D; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 0258E3E0B377; Thu, 12 Jan 2017 18:34:02 +0100 (CET) Date: Thu, 12 Jan 2017 18:34:02 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170112173402.GB21677@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.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.6.0 (2016-04-01) Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:34:11 -0000 On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > YANG statements: > - It is not possible to define these statements so they are different > for config and oper > - must > - when > - unique > - key > - min-elements > - max-elements > - leafref (path) > - if-feature > - deviation > - type (or any sub-statements of type-stmt) > - status > - description > - reference Considering statements that constraint 'values', it is not entirely clear to me what they mean for state nodes. If a server has operational state that violates a must or range or ... constraint in the YANG model, what is the server expected to do? /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 Jan 12 09:37:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A7D07129521 for ; Thu, 12 Jan 2017 09:37:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ecrNAkLctBLF for ; Thu, 12 Jan 2017 09:37:03 -0800 (PST) Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 952001294BD for ; Thu, 12 Jan 2017 09:37:03 -0800 (PST) Received: by mail-qt0-x229.google.com with SMTP id l7so24808669qtd.1 for ; Thu, 12 Jan 2017 09:37:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jloYKq0m8VCqP5CM312ECRs3bElY0t3Chagc0BULzik=; b=xBbsv10zfekzxyckHiADr6qU8y1Hdgnjol0F1WKNXyd6hy/qcpZ8UyDTM4OXUGYXfj 6uxyxNrvi2Z6k5r2jLg4TgTygBikKr8Mi5Jgu7aZDPi2SCzmi3eG3FplzRVR13hqGVyx hpr9XkpQ9eyMCVesWkO0dszoKE8wBXdniHh4TBahez6mbKuBhfZKj+AL4ls0tL07wikK N+wPUY0nKrDDz62OPFc9Un5DVSM3vbLViZE6RwiLGlFxXg/5tlWxuhCN77F9/qHh4Eyl dT5To2XsI4gIzn0TVJKJrEzpaqSwzb0iPv4ZqbLdNtFLEZcSa7rt2IM1viZRl1eHcNi0 PCXA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jloYKq0m8VCqP5CM312ECRs3bElY0t3Chagc0BULzik=; b=Z+e7O/QfAj37HOr3vN6xHd9B0bgUpx5Sts5Ez8Zcm/IQFLJt+Sd5P6thJRB8wwHL4Z 3fpo/hn4y6je3Xz/IfMmXgLiYcmBWQgJisnH1cCxn3+xeOQZuSLgE8hUhGZjz1jRd4gG vWsRG7NQTVniflmfyfZM7Ua2Ism7ZN3IwISdw9Ink7wy5FGwP8AJkno3ZLpLX5X3bJ6U jvIc/OQAXq8mVZxdXsPX3eU6AEQHPba3xD1a7vFP/Q30kkSYaISC6G6hBE4LyJ7xmPf3 mjaKs6y4ucZLXgTAzGqzoamAA1Ra2w78SsYlSYKGH5RcLjHVvIbz5gow4fFAe2uWC61I lqMA== X-Gm-Message-State: AIkVDXJCI0qc31sNPYL3eZI499E01nC8lFGx9lGGadswblAZw/M3cMhV5Ure5d0Q+ZpOl4Us8lG0uSLex31z7w== X-Received: by 10.237.34.239 with SMTP id q44mr13302661qtc.18.1484242622650; Thu, 12 Jan 2017 09:37:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:37:01 -0800 (PST) In-Reply-To: <20170112.135947.218954166063566738.mbj@tail-f.com> References: <39b938d3504f4599bf4e92a48b685a0a@XCH-RTP-013.cisco.com> <20170112.135947.218954166063566738.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 09:37:01 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113e7aee48db360545e92aa2 Archived-At: Cc: Netconf Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:37:06 -0000 --001a113e7aee48db360545e92aa2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) > wrote: > > > > > > From: Andy Bierman, January 5, 2017 9:43 PM > > > > > > > > On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) > > evoit@cisco.com> > > > > wrote: > > > > Hi Andy, > > > > > > > > =E2=80=9CThe innermost container or list=E2=80=9D text is similar t= o that for > actions in > > > section > > > > 7.15.2. Perhaps the mental model of one target for an action was > > > replicated? > > > > > > > > I had not considered that YANG 1.1=E2=80=99s definition might force= the > breakup > > > of a > > > > verbose software component generated notification into multiple > pushed > > > > notification messages. Looking at the three cases below, I don=E2= =80=99t > think > > > that > > > > arbitrary choices made in YANG model structure should impact what > could > > > or > > > > couldn=E2=80=99t be in encoded within any single notification. So = my > preference > > > would > > > > be that all three variants below should supportable if that is how > the > > > system > > > > passed them to be encoded as part of an event. > > > > > > > > > > > > > > > > I think the WG did not consider these details and assumed they were > the > > > same > > > > as for action. > > > > > > > > This would be a MAY for the server and a MUST for the client, so it > is > > > not > > > > an easy decision. > > > > > > > > A couple use-cases I have in mind: > > > > > > > > 1) event broker > > > > subscriber is really a broker that may be pre-processing lots > of > > > > subscriptions or event types within 1 subscription > > > > > > > > 2) digest (time-based push) > > > > Subscriber wants an update every 5 seconds with all the YANG 1= .1 > > > events > > > > for the previous 5 seconds > > > > > > These are both reasonable as controllers are requiring scalable > methods of > > > synching on device status. > > > > > > > What if the reinterpretation were as simple as =E2=80=9CAn innermos= t=E2=80=9D or =E2=80=9CThe > > > first > > > > innermost=E2=80=9D? > > > > > > > > This covers case 2. (Change "The" to "An"). > > > > The client would need to check for YANG 1.1 notifications in the > > > > same way it checks child nodes already. > > > > > > "Any innermost"...? And yes, this is a more significant change on t= he > > > client. Beyond this, for use cases (1) & (2), if you don't want to > > > summarize the eventTime, the time should be placed with each innermos= t > > > event. I am not suggesting we do this, but like Andy I want to figur= e > out > > > what the WG might be willing to consider in scope. > > > > > > > > > > There was actually a lot of discussion about "eventTime" in the NETCONF > WG > > when RFC 5277 was done. > > Lots of disagreement on what it means. The RFC offers little guidance = or > > hint of the discussion: > > > > > > eventTime: > > The time the event was generated by the event source. > > > > It may take the server some time to detect the event after it occurs. > > It may take some time to save the event for replay and transmission. > > Which of these 3 different times is it? (Out of scope I think) > > > > Adding more timestamps is an interesting idea. > > > > But I think something like this could be done without a client MUST. > > The client MAY request 'bulk-encoding' and if the server supports it, > > a more optimized structure would be sent instead of the normal message. > > I prefer this approach, rather than the example in the original > email. If the bulk-encoded notifications are encoded into a normal > notification, we don't have to change anything: > > xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2017-01-08T00:01:00Z > > xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2017-01-08T00:00:00Z > > > > xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > 2017-01-08T00:00:01Z > > > ... > > > > I was hoping for a bulk format that reduced the payload. Your example actually increases the payload size. I think the subscription needs some sort of encoding negotiation like the Accept header in HTTP. People will eventually think of lots of optimizations that we never imagined. The protocol should be robust enough to allow this to happen. e.g., send multiple subscription-id values in 1 notification instead of duplicating that notification to the receiver N times. Another obvious optimization is the ability to group similar events into a range like link-up for a port-range, representing the entire line card that was just plugged in. ....no restrictions on what is in the header ... ... // limit to 1 element for payload? A simple notification is the canonical form. A notification subscriber acting as a broker will need to convert the bulk form into 1 or more notifications in canonical format. > > /martin > Andy > > > > The receiver MAY extract individual messages from the bulk format (mayb= e > > binary) > > into other formats (like XML or JSON). > > > > I am trying to plan ahead for when YANG Push turns out to be a slow > network > > hog :-) > > > > > > Eric > > > > > > > > Andy > > > > > Eric > > > > > > > > > > > > Andy > > > > > > > > From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On Behalf Of > Andy > > > > Bierman > > > > Sent: Thursday, January 5, 2017 5:25 PM > > > > To: Netconf > > > > Subject: [Netconf] nested notifications > > > > > > > > Hi, > > > > > > > > I would like some text in RFC 7950 to be reinterpreted. The text > implies > > > each > > > > notification message can only describe 1 instance of 1 event type. > > > > > > > > RFC 7950, sec 7.16.2 > > > > > > > > The innermost container or list contains an XML > > > > element that carries the name of the defined notification. > > > > > > > > > > > > There are 3 corner-cases that should be considered in order > > > > to minimize network overhead for notifications in 5277bis. > > > > Replicating the node/key hierarchy could be expensive > > > > and events occurring at the same time could be correlated. > > > > > > > > Duplicating the notification messages is inefficient, > > > > but processing multiple events per message makes > > > > filtering and parsing more complicated. > > > > > > > > I am curious if the WG thinks notification overhead is a concern an= d > > > > if it needs to be addressed somehow in 5277bis. > > > > > > > > > > > > 1) multiple non-sibling events in same subtree > > > > > > > > > > > > > > > > > > > > 42 > > > > > > > > > > > > eth0 > > > > > > > > auto > > > > > > > > > > > > > > > > > > > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > > > > > > > > > > > > eth0 > > > > > > > > auto > > > > > > > > > > > > admin > > > > > > > > > > > > > > > > > > > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > > > > > > > > > > > > > > 42 > > > > > > > > > > > > > > > > > > > > eth0 > > > > > > > > auto > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Andy > > > > > > > > > > > > > > > --001a113e7aee48db360545e92aa2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) <evoit@cisco.com> wrote:
>
> > > From: Andy Bierman, January 5, 2017 9:43 PM
> > >
> > > On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) <mailto= :
> > evoit@cisco.com>
> > > wrote:
> > > Hi Andy,
> > >
> > > =E2=80=9CThe innermost container or list=E2=80=9D text is si= milar to that for actions in
> > section
> > > 7.15.2.=C2=A0 =C2=A0Perhaps the mental model of one target f= or an action was
> > replicated?
> > >
> > > I had not considered that YANG 1.1=E2=80=99s definition migh= t force the breakup
> > of a
> > > verbose software component generated notification into multi= ple pushed
> > > notification messages.=C2=A0 Looking at the three cases belo= w, I don=E2=80=99t think
> > that
> > > arbitrary choices made in YANG model structure should impact= what could
> > or
> > > couldn=E2=80=99t be in encoded within any single notificatio= n.=C2=A0 So my preference
> > would
> > > be that all three variants below should supportable if that = is how the
> > system
> > > passed them to be encoded as part of an event.
> > >
> > >
> > >
> > > I think the WG did not consider these details and assumed th= ey were the
> > same
> > > as for action.
> > >
> > > This would be a MAY for the server and a MUST for the client= , so it is
> > not
> > > an easy decision.
> > >
> > > A couple use-cases I have in mind:
> > >
> > >=C2=A0 =C2=A01) event broker
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0subscriber is really a broker that= may be pre-processing lots of
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0subscriptions or event types withi= n 1 subscription
> > >
> > >=C2=A0 =C2=A0 2) digest (time-based push)
> > >=C2=A0 =C2=A0 =C2=A0 Subscriber wants an update every 5 secon= ds with all the YANG 1.1
> > events
> > >=C2=A0 =C2=A0 =C2=A0for the previous 5 seconds
> >
> > These are both reasonable as controllers are requiring scalable m= ethods of
> > synching on device status.
> >
> > > What if the reinterpretation were as simple as =E2=80=9CAn i= nnermost=E2=80=9D or =E2=80=9CThe
> > first
> > > innermost=E2=80=9D?
> > >
> > > This covers case 2. (Change "The" to "An"= ;).
> > > The client would need to check for YANG 1.1 notifications in= the
> > > same way it checks child nodes already.
> >
> > "Any innermost"...?=C2=A0 =C2=A0And yes, this is a more= significant change on the
> > client.=C2=A0 Beyond this, for use cases (1) & (2), if you do= n't want to
> > summarize the eventTime, the time should be placed with each inne= rmost
> > event.=C2=A0 I am not suggesting we do this, but like Andy I want= to figure out
> > what the WG might be willing to consider in scope.
> >
> >
>
> There was actually a lot of discussion about "eventTime" in = the NETCONF WG
> when RFC 5277 was done.
> Lots of disagreement on what it means.=C2=A0 The RFC offers little gui= dance or
> hint of the discussion:
>
>
>=C2=A0 =C2=A0 =C2=A0eventTime:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 The time the event was generated by the eve= nt source.
>
> It may take the server some time to detect the event after it occurs.<= br> > It may take some time to save the event for replay and transmission. > Which of these 3 different times is it? (Out of scope I think)
>
> Adding more timestamps is an interesting idea.
>
> But I think something like this could be done without a client MUST. > The client MAY request 'bulk-encoding' and if the server suppo= rts it,
> a more optimized structure would be sent instead of the normal message= .

I prefer this approach, rather than the example in the original
email.=C2=A0 If the bulk-encoded notifications are encoded into a normal notification, we don't have to change anything:

=C2=A0 <notification
=C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:noti= fication:1.0">
=C2=A0 =C2=A0 <eventTime>2017-01-08T00:01:00Z</eventTime><= br> =C2=A0 =C2=A0 <bulk-notifications xmlns=3D"...">
=C2=A0 =C2=A0 =C2=A0 <notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <eventTime>2017-01-08T00:00:00Z</= eventTime>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <link-up .../>
=C2=A0 =C2=A0 =C2=A0 </notification>

=C2=A0 =C2=A0 =C2=A0 <notification
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0">
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <eventTime>2017-01-08T00:00:01Z</= eventTime>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 <link-down .../>
=C2=A0 =C2=A0 =C2=A0 </notification>
=C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0</notification>



I was hoping for a bulk format that re= duced the payload.
Your example actually increases the payload si= ze.

I think the subscription needs some sort of en= coding negotiation like the Accept header in HTTP.
People will ev= entually think of lots of optimizations that we never imagined.=C2=A0 The p= rotocol should
be robust enough to allow this to happen. =C2=A0e.= g., send multiple subscription-id values in
1 notification instea= d of duplicating that notification to the receiver N times.
Anoth= er obvious optimization is the ability to group similar events into a range=
like link-up for a port-range, representing the entire line card= that was just plugged in.

=C2=A0 <notification= >
=C2=A0 =C2=A0 =C2=A0<hdr>....no restrictions on what i= s in the header ... </hdr>
=C2=A0 =C2=A0 =C2=A0<link-dow= n> ... </link-down> =C2=A0 // limit to 1 element for payload?
=C2=A0 </notification>

A simple notifi= cation is the canonical form.
A notification subscriber acting as= a broker will need to convert the bulk form
into 1 or more notif= ications in canonical format.

=C2=A0

/martin

Andy
=C2=A0


> The receiver MAY extract individual messages from the bulk format (may= be
> binary)
> into other formats (like XML or JSON).
>
> I am trying to plan ahead for when YANG Push turns out to be a slow ne= twork
> hog :-)
>
>
> Eric
> >
> >
>=C2=A0 Andy
>
> > Eric
> > >
> > >
> > > Andy
> > >
> > > From: Netconf [mailto:mailto:<= a href=3D"mailto:netconf-bounces@ietf.org">netconf-bounces@ietf.org] On Behalf Of Andy
> > > Bierman
> > > Sent: Thursday, January 5, 2017 5:25 PM
> > > To: Netconf <mailto:n= etconf@ietf.org>
> > > Subject: [Netconf] nested notifications
> > >
> > > Hi,
> > >
> > > I would like some text in RFC 7950 to be reinterpreted. The = text implies
> > each
> > > notification message can only describe 1 instance of 1 event= type.
> > >
> > > RFC 7950, sec 7.16.2
> > >
> > >=C2=A0 =C2=A0 The innermost container or list contains an XML=
> > >=C2=A0 =C2=A0 element that carries the name of the defined no= tification.
> > >
> > >
> > > There are 3 corner-cases that should be considered in order<= br> > > > to minimize network overhead for notifications in 5277bis. > > > Replicating the node/key hierarchy could be expensive
> > > and events occurring at the same time could be correlated. > > >
> > > Duplicating the notification messages is inefficient,
> > > but processing multiple events per message makes
> > > filtering and parsing more complicated.
> > >
> > > I am curious if the WG thinks notification overhead is a con= cern and
> > > if it needs to be addressed somehow in 5277bis.
> > >
> > >
> > > 1) multiple non-sibling events in same subtree
> > >
> > >=C2=A0 =C2=A0<notification>
> > >=C2=A0 =C2=A0 =C2=A0<interfaces>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<my-top-event>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<my-data>42</my-da= ta>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</my-top-event>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name&g= t;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<my-interface-event><= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<if= -data>auto</if-data>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</my-interface-event>=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
> > >=C2=A0 =C2=A0 =C2=A0</interfaces>
> > >=C2=A0 =C2=A0</notification>
> > >
> > >
> > > 2) multiple sibling events in the same subtree
> > >
> > >=C2=A0 =C2=A0<notification>
> > >=C2=A0 =C2=A0 =C2=A0<interfaces>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name&g= t;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<my-interface-event><= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<if= -data>auto</if-data>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</my-interface-event>=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<interface-enabled> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 <by-user>admi= n</by-user>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</interface-enabled><= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
> > >=C2=A0 =C2=A0 =C2=A0</interfaces>
> > >=C2=A0 =C2=A0</notification>
> > >
> > >
> > > 3) multiple non-sibling events in different subtrees
> > >
> > >=C2=A0 =C2=A0<notification>
> > >=C2=A0 =C2=A0 =C2=A0<system>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<my-system-event>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<my-data&g= t;42</my-data>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</my-system-event>
> > >=C2=A0 =C2=A0 =C2=A0</system>
> > >=C2=A0 =C2=A0 =C2=A0<interfaces>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0<interface>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<name>eth0</name&g= t;
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<my-interface-event><= br> > > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<if= -data>auto</if-data>
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0</my-interface-event>=
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0</interface>
> > >=C2=A0 =C2=A0 =C2=A0</interfaces>
> > >=C2=A0 =C2=A0</notification>
> > >
> > >
> > >
> > > Andy
> > >
> > >
> >
> >

--001a113e7aee48db360545e92aa2-- From nobody Thu Jan 12 09:38:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 64A7D129503 for ; Thu, 12 Jan 2017 09:38:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1oMqGmU9gVf for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 53383129408 for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) Received: by mail-qt0-x22d.google.com with SMTP id l7so24858098qtd.1 for ; Thu, 12 Jan 2017 09:38:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=+pGt2j1lufCBXwYKSCaUTSSdWKjAkv8ggAIZd+jr1UQ=; b=GsZx+Jk07ZtGK4ejOpdox6T6afP6zTGZSkIjh3JCyU4/YNxyf09ZWI7COCh5S73S57 dylyr+nliFTXVgKZwwClyWPeuYu1GoYSlpkWMyyeiiRiY6WyT4+nvZ07Nkg5n6pP7B+W 7JZO0q2VBtQNUCdqsHqiDppsYTcroySzuhb7/8Sh3TAo7/8CEbvQy2aYBYlxNwuaotnB ZL4IeFDt80jyi0Z4ku+YxfNQ1OEeKL0kuOfuoxJv/ZGEKqJw8NzOslrZ0RKQTNZ3jSgy /erDXmU8PVLzXeSOkmGjP5gnq958iFBq60WFJByQ9yK5imLLTXZx1J+Eux34RO2Grzkz Ge6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=+pGt2j1lufCBXwYKSCaUTSSdWKjAkv8ggAIZd+jr1UQ=; b=P7BdK1PhQ6+Je5N3ypYp43ZoVzUjocNnBSGDF3dcaiAjRNWb7p6UdixLSoENdb4Awa KWx/Ka+QLScvcb9xrKbv8AU3DiAK3TMRF9xAIhh7ynqLA591hXRxD/jD/vYjNiAqpzFy AtTICZOPAyf9Pfw2t6vV3OsFlgt8JRpnsoLmBFBwchE1CotW9NI6yr9higcImIQJMYTu ZLDkaajNv+jTBGZiSdfVYn5nu7NBcNmHHcmnqmHzCdgS9Znp5U+mu32OF7vurCKsxJAt AxsEWheJBOSAMFlifQT/MO4Ueogu5oJ8tSnwg/JpVDpaXzg7B47U9JYkB9de2EFbCvJn sDgw== X-Gm-Message-State: AIkVDXKCmJ3oR27/c7DQdlDyAhjghDb0bqZhEm+KBiDaZxN6DTzQYXGx5lf991EN97KgG83DFxjXB7wK3QezGw== X-Received: by 10.200.1.2 with SMTP id e2mr2161449qtg.142.1484242728342; Thu, 12 Jan 2017 09:38:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 09:38:46 -0800 (PST) In-Reply-To: <20170112173402.GB21677@elstar.local> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> From: Andy Bierman Date: Thu, 12 Jan 2017 09:38:46 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf Content-Type: multipart/alternative; boundary=f403045f39e4956b0b0545e930c5 Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:38:51 -0000 --f403045f39e4956b0b0545e930c5 Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > > > YANG statements: > > - It is not possible to define these statements so they are different > > for config and oper > > - must > > - when > > - unique > > - key > > - min-elements > > - max-elements > > - leafref (path) > > - if-feature > > - deviation > > - type (or any sub-statements of type-stmt) > > - status > > - description > > - reference > > Considering statements that constraint 'values', it is not entirely > clear to me what they mean for state nodes. If a server has > operational state that violates a must or range or ... constraint in > the YANG model, what is the server expected to do? > The client uses the YANG validation to check on what the server is sending. The server is buggy if it is sending data that violates YANG constraints. If any of these statements need to be different for config and oper then the old style YANG has to be used instead. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --f403045f39e4956b0b0545e930c5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierm= an wrote:
>
> YANG statements:
>=C2=A0 =C2=A0 - It is not possible to define these statements so they a= re different
> for config and oper
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- must
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- when
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- unique
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- key
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- min-elements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- max-elements
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- leafref (path)
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- if-feature
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- deviation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- type (or any sub-statements of type-stmt)<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0- status
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- description
>=C2=A0 =C2=A0 =C2=A0 =C2=A0- reference

Considering statements that constraint 'values', it is not entirely=
clear to me what they mean for state nodes. If a server has
operational state that violates a must or range or ... constraint in
the YANG model, what is the server expected to do?
The client uses the YANG validation to check on what the server= is sending.
The server is buggy if it is sending data that viola= tes YANG constraints.
If any of these statements need to be diffe= rent for config and oper
then the old style YANG has to be used i= nstead.

=C2=A0

/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--f403045f39e4956b0b0545e930c5-- From nobody Thu Jan 12 09:54:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 829901294D2; Thu, 12 Jan 2017 09:54:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bj6I-OIz8sLr; Thu, 12 Jan 2017 09:54:07 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3ABC129447; Thu, 12 Jan 2017 09:54:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7746; q=dns/txt; s=iport; t=1484243647; x=1485453247; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=xUHvkiVGbAu/2DABkKo3bWpHsr0TJyne4nB/KvLiotA=; b=A6Pv/PQwc5fssFcLECBG0t5+lpkc5Xqen8tpMWxQVMSfeCY4NwS11rkE QZfc3Xi2cySK7ahVlxOF6tzQlEtEm7qLSwyRySq7fx0c4jPI5B88UxZag iH6fNmhZDIOk2djjyFZJnEspwWNQWV2rCaNUusZvWCN/rmK3d9RunBFdp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AcAQBQwndY/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM8AQEBAQF+A4EGjVhykSKPf4Urgg0fAQqEHoEQSgKCRBQBAgE?= =?us-ascii?q?BAQEBAQFjKIRpAQEBBAEBbBkCCxAIIwQHGwwfEQYBDAYCAQGIfA6zByuJbQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAR0FhkCCAgiCV4QwNyaCBYMYBZsskVaKL4Y7imm?= =?us-ascii?q?Hex84gRUSCBUVOoN8bIFHPjWGKyuCEAEBAQ?= X-IronPort-AV: E=Sophos;i="5.33,219,1477958400"; d="scan'208,217";a="649749111" 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/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Jan 2017 17:54:02 +0000 Received: from [10.63.23.107] (dhcp-ensft1-uk-vla370-10-63-23-107.cisco.com [10.63.23.107]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id v0CHs2gh025452; Thu, 12 Jan 2017 17:54:02 GMT To: Andy Bierman , Juergen Schoenwaelder , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> From: Robert Wilton Message-ID: <67fae2eb-faa2-7bc3-4763-51a38296233b@cisco.com> Date: Thu, 12 Jan 2017 17:54:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------EA9C078E1E67848E7E4646EA" Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 17:54:09 -0000 This is a multi-part message in MIME format. --------------EA9C078E1E67848E7E4646EA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit On 12/01/2017 17:38, Andy Bierman wrote: > > > On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder > > wrote: > > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > > > YANG statements: > > - It is not possible to define these statements so they are > different > > for config and oper > > - must > > - when > > - unique > > - key > > - min-elements > > - max-elements > > - leafref (path) > > - if-feature > > - deviation > > - type (or any sub-statements of type-stmt) > > - status > > - description > > - reference > > Considering statements that constraint 'values', it is not entirely > clear to me what they mean for state nodes. If a server has > operational state that violates a must or range or ... constraint in > the YANG model, what is the server expected to do? > > > The client uses the YANG validation to check on what the server is > sending. > The server is buggy if it is sending data that violates YANG constraints. > If any of these statements need to be different for config and oper > then the old style YANG has to be used instead. You just have a separate state leaf. These are still allowed in a combined tree. The config true leaf in the operational state datastore represents the applied configuration. The additional state leaf represents some more complex state derived from the applied configuration, just like the rest of the config false leaves. Rob > > > /js > > > Andy > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------EA9C078E1E67848E7E4646EA Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit



On 12/01/2017 17:38, Andy Bierman wrote:


On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote:
>
> YANG statements:
>    - It is not possible to define these statements so they are different
> for config and oper
>       - must
>       - when
>       - unique
>       - key
>       - min-elements
>       - max-elements
>       - leafref (path)
>       - if-feature
>       - deviation
>       - type (or any sub-statements of type-stmt)
>       - status
>       - description
>       - reference

Considering statements that constraint 'values', it is not entirely
clear to me what they mean for state nodes. If a server has
operational state that violates a must or range or ... constraint in
the YANG model, what is the server expected to do?

The client uses the YANG validation to check on what the server is sending.
The server is buggy if it is sending data that violates YANG constraints.
If any of these statements need to be different for config and oper
then the old style YANG has to be used instead.
You just have a separate state leaf.  These are still allowed in a combined tree.

The config true leaf in the operational state datastore represents the applied configuration.
The additional state leaf represents some more complex state derived from the applied configuration, just like the rest of the config false leaves.

Rob



 

/js

Andy
 

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



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

--------------EA9C078E1E67848E7E4646EA-- From nobody Thu Jan 12 10:30:38 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 396A51294E1 for ; Thu, 12 Jan 2017 10:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 0qDFFma5P-eC for ; Thu, 12 Jan 2017 10:30:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 19847129483 for ; Thu, 12 Jan 2017 10:30:32 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 66AF11AE01AA; Thu, 12 Jan 2017 19:30:29 +0100 (CET) Date: Thu, 12 Jan 2017 19:30:29 +0100 (CET) Message-Id: <20170112.193029.9249587815129986.mbj@tail-f.com> To: andy@yumaworks.com From: Martin Bjorklund In-Reply-To: References: <20170112.135947.218954166063566738.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:30:35 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBUaHUsIEphbiAx MiwgMjAxNyBhdCA0OjU5IEFNLCBNYXJ0aW4gQmpvcmtsdW5kIDxtYmpAdGFpbC1mLmNvbT4gd3Jv dGU6DQo+IA0KPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5dW1hd29ya3MuY29tPiB3cm90ZToNCj4g PiA+IE9uIEZyaSwgSmFuIDYsIDIwMTcgYXQgOToyOCBBTSwgRXJpYyBWb2l0IChldm9pdCkgPGV2 b2l0QGNpc2NvLmNvbT4NCj4gPiB3cm90ZToNCj4gPiA+DQo+ID4gPiA+ID4gRnJvbTogQW5keSBC aWVybWFuLCBKYW51YXJ5IDUsIDIwMTcgOTo0MyBQTQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gT24g VGh1LCBKYW4gNSwgMjAxNyBhdCA1OjE2IFBNLCBFcmljIFZvaXQgKGV2b2l0KSA8bWFpbHRvOg0K PiA+ID4gPiBldm9pdEBjaXNjby5jb20+DQo+ID4gPiA+ID4gd3JvdGU6DQo+ID4gPiA+ID4gSGkg QW5keSwNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IOKAnFRoZSBpbm5lcm1vc3QgY29udGFpbmVyIG9y IGxpc3TigJ0gdGV4dCBpcyBzaW1pbGFyIHRvIHRoYXQgZm9yDQo+ID4gYWN0aW9ucyBpbg0KPiA+ ID4gPiBzZWN0aW9uDQo+ID4gPiA+ID4gNy4xNS4yLiAgIFBlcmhhcHMgdGhlIG1lbnRhbCBtb2Rl bCBvZiBvbmUgdGFyZ2V0IGZvciBhbiBhY3Rpb24gd2FzDQo+ID4gPiA+IHJlcGxpY2F0ZWQ/DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGhhZCBub3QgY29uc2lkZXJlZCB0aGF0IFlBTkcgMS4x4oCZ cyBkZWZpbml0aW9uIG1pZ2h0IGZvcmNlIHRoZQ0KPiA+IGJyZWFrdXANCj4gPiA+ID4gb2YgYQ0K PiA+ID4gPiA+IHZlcmJvc2Ugc29mdHdhcmUgY29tcG9uZW50IGdlbmVyYXRlZCBub3RpZmljYXRp b24gaW50byBtdWx0aXBsZQ0KPiA+IHB1c2hlZA0KPiA+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNz YWdlcy4gIExvb2tpbmcgYXQgdGhlIHRocmVlIGNhc2VzIGJlbG93LCBJIGRvbuKAmXQNCj4gPiB0 aGluaw0KPiA+ID4gPiB0aGF0DQo+ID4gPiA+ID4gYXJiaXRyYXJ5IGNob2ljZXMgbWFkZSBpbiBZ QU5HIG1vZGVsIHN0cnVjdHVyZSBzaG91bGQgaW1wYWN0IHdoYXQNCj4gPiBjb3VsZA0KPiA+ID4g PiBvcg0KPiA+ID4gPiA+IGNvdWxkbuKAmXQgYmUgaW4gZW5jb2RlZCB3aXRoaW4gYW55IHNpbmds ZSBub3RpZmljYXRpb24uICBTbyBteQ0KPiA+IHByZWZlcmVuY2UNCj4gPiA+ID4gd291bGQNCj4g PiA+ID4gPiBiZSB0aGF0IGFsbCB0aHJlZSB2YXJpYW50cyBiZWxvdyBzaG91bGQgc3VwcG9ydGFi bGUgaWYgdGhhdCBpcyBob3cNCj4gPiB0aGUNCj4gPiA+ID4gc3lzdGVtDQo+ID4gPiA+ID4gcGFz c2VkIHRoZW0gdG8gYmUgZW5jb2RlZCBhcyBwYXJ0IG9mIGFuIGV2ZW50Lg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgdGhpbmsgdGhlIFdHIGRpZCBub3QgY29u c2lkZXIgdGhlc2UgZGV0YWlscyBhbmQgYXNzdW1lZCB0aGV5IHdlcmUNCj4gPiB0aGUNCj4gPiA+ ID4gc2FtZQ0KPiA+ID4gPiA+IGFzIGZvciBhY3Rpb24uDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBU aGlzIHdvdWxkIGJlIGEgTUFZIGZvciB0aGUgc2VydmVyIGFuZCBhIE1VU1QgZm9yIHRoZSBjbGll bnQsIHNvIGl0DQo+ID4gaXMNCj4gPiA+ID4gbm90DQo+ID4gPiA+ID4gYW4gZWFzeSBkZWNpc2lv bi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEEgY291cGxlIHVzZS1jYXNlcyBJIGhhdmUgaW4gbWlu ZDoNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgMSkgZXZlbnQgYnJva2VyDQo+ID4gPiA+ID4gICAg ICAgc3Vic2NyaWJlciBpcyByZWFsbHkgYSBicm9rZXIgdGhhdCBtYXkgYmUgcHJlLXByb2Nlc3Np bmcgbG90cw0KPiA+IG9mDQo+ID4gPiA+ID4gICAgICAgc3Vic2NyaXB0aW9ucyBvciBldmVudCB0 eXBlcyB3aXRoaW4gMSBzdWJzY3JpcHRpb24NCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIDIpIGRp Z2VzdCAodGltZS1iYXNlZCBwdXNoKQ0KPiA+ID4gPiA+ICAgICAgU3Vic2NyaWJlciB3YW50cyBh biB1cGRhdGUgZXZlcnkgNSBzZWNvbmRzIHdpdGggYWxsIHRoZSBZQU5HIDEuMQ0KPiA+ID4gPiBl dmVudHMNCj4gPiA+ID4gPiAgICAgZm9yIHRoZSBwcmV2aW91cyA1IHNlY29uZHMNCj4gPiA+ID4N Cj4gPiA+ID4gVGhlc2UgYXJlIGJvdGggcmVhc29uYWJsZSBhcyBjb250cm9sbGVycyBhcmUgcmVx dWlyaW5nIHNjYWxhYmxlDQo+ID4gbWV0aG9kcyBvZg0KPiA+ID4gPiBzeW5jaGluZyBvbiBkZXZp Y2Ugc3RhdHVzLg0KPiA+ID4gPg0KPiA+ID4gPiA+IFdoYXQgaWYgdGhlIHJlaW50ZXJwcmV0YXRp b24gd2VyZSBhcyBzaW1wbGUgYXMg4oCcQW4gaW5uZXJtb3N04oCdIG9yIOKAnFRoZQ0KPiA+ID4g PiBmaXJzdA0KPiA+ID4gPiA+IGlubmVybW9zdOKAnT8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRo aXMgY292ZXJzIGNhc2UgMi4gKENoYW5nZSAiVGhlIiB0byAiQW4iKS4NCj4gPiA+ID4gPiBUaGUg Y2xpZW50IHdvdWxkIG5lZWQgdG8gY2hlY2sgZm9yIFlBTkcgMS4xIG5vdGlmaWNhdGlvbnMgaW4g dGhlDQo+ID4gPiA+ID4gc2FtZSB3YXkgaXQgY2hlY2tzIGNoaWxkIG5vZGVzIGFscmVhZHkuDQo+ ID4gPiA+DQo+ID4gPiA+ICJBbnkgaW5uZXJtb3N0Ii4uLj8gICBBbmQgeWVzLCB0aGlzIGlzIGEg bW9yZSBzaWduaWZpY2FudCBjaGFuZ2Ugb24gdGhlDQo+ID4gPiA+IGNsaWVudC4gIEJleW9uZCB0 aGlzLCBmb3IgdXNlIGNhc2VzICgxKSAmICgyKSwgaWYgeW91IGRvbid0IHdhbnQgdG8NCj4gPiA+ ID4gc3VtbWFyaXplIHRoZSBldmVudFRpbWUsIHRoZSB0aW1lIHNob3VsZCBiZSBwbGFjZWQgd2l0 aCBlYWNoIGlubmVybW9zdA0KPiA+ID4gPiBldmVudC4gIEkgYW0gbm90IHN1Z2dlc3Rpbmcgd2Ug ZG8gdGhpcywgYnV0IGxpa2UgQW5keSBJIHdhbnQgdG8gZmlndXJlDQo+ID4gb3V0DQo+ID4gPiA+ IHdoYXQgdGhlIFdHIG1pZ2h0IGJlIHdpbGxpbmcgdG8gY29uc2lkZXIgaW4gc2NvcGUuDQo+ID4g PiA+DQo+ID4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlcmUgd2FzIGFjdHVhbGx5IGEgbG90IG9mIGRp c2N1c3Npb24gYWJvdXQgImV2ZW50VGltZSIgaW4gdGhlIE5FVENPTkYNCj4gPiBXRw0KPiA+ID4g d2hlbiBSRkMgNTI3NyB3YXMgZG9uZS4NCj4gPiA+IExvdHMgb2YgZGlzYWdyZWVtZW50IG9uIHdo YXQgaXQgbWVhbnMuICBUaGUgUkZDIG9mZmVycyBsaXR0bGUgZ3VpZGFuY2Ugb3INCj4gPiA+IGhp bnQgb2YgdGhlIGRpc2N1c3Npb246DQo+ID4gPg0KPiA+ID4NCj4gPiA+ICAgICBldmVudFRpbWU6 DQo+ID4gPiAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50IHdhcyBnZW5lcmF0ZWQgYnkgdGhlIGV2 ZW50IHNvdXJjZS4NCj4gPiA+DQo+ID4gPiBJdCBtYXkgdGFrZSB0aGUgc2VydmVyIHNvbWUgdGlt ZSB0byBkZXRlY3QgdGhlIGV2ZW50IGFmdGVyIGl0IG9jY3Vycy4NCj4gPiA+IEl0IG1heSB0YWtl IHNvbWUgdGltZSB0byBzYXZlIHRoZSBldmVudCBmb3IgcmVwbGF5IGFuZCB0cmFuc21pc3Npb24u DQo+ID4gPiBXaGljaCBvZiB0aGVzZSAzIGRpZmZlcmVudCB0aW1lcyBpcyBpdD8gKE91dCBvZiBz Y29wZSBJIHRoaW5rKQ0KPiA+ID4NCj4gPiA+IEFkZGluZyBtb3JlIHRpbWVzdGFtcHMgaXMgYW4g aW50ZXJlc3RpbmcgaWRlYS4NCj4gPiA+DQo+ID4gPiBCdXQgSSB0aGluayBzb21ldGhpbmcgbGlr ZSB0aGlzIGNvdWxkIGJlIGRvbmUgd2l0aG91dCBhIGNsaWVudCBNVVNULg0KPiA+ID4gVGhlIGNs aWVudCBNQVkgcmVxdWVzdCAnYnVsay1lbmNvZGluZycgYW5kIGlmIHRoZSBzZXJ2ZXIgc3VwcG9y dHMgaXQsDQo+ID4gPiBhIG1vcmUgb3B0aW1pemVkIHN0cnVjdHVyZSB3b3VsZCBiZSBzZW50IGlu c3RlYWQgb2YgdGhlIG5vcm1hbCBtZXNzYWdlLg0KPiA+DQo+ID4gSSBwcmVmZXIgdGhpcyBhcHBy b2FjaCwgcmF0aGVyIHRoYW4gdGhlIGV4YW1wbGUgaW4gdGhlIG9yaWdpbmFsDQo+ID4gZW1haWwu ICBJZiB0aGUgYnVsay1lbmNvZGVkIG5vdGlmaWNhdGlvbnMgYXJlIGVuY29kZWQgaW50byBhIG5v cm1hbA0KPiA+IG5vdGlmaWNhdGlvbiwgd2UgZG9uJ3QgaGF2ZSB0byBjaGFuZ2UgYW55dGhpbmc6 DQo+ID4NCj4gPiAgIDxub3RpZmljYXRpb24NCj4gPiAgICAgICB4bWxucz0idXJuOmlldGY6cGFy YW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiPg0KPiA+ICAgICA8ZXZlbnRUaW1l PjIwMTctMDEtMDhUMDA6MDE6MDBaPC9ldmVudFRpbWU+DQo+ID4gICAgIDxidWxrLW5vdGlmaWNh dGlvbnMgeG1sbnM9Ii4uLiI+DQo+ID4gICAgICAgPG5vdGlmaWNhdGlvbg0KPiA+ICAgICAgICAg ICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAi Pg0KPiA+ICAgICAgICAgPGV2ZW50VGltZT4yMDE3LTAxLTA4VDAwOjAwOjAwWjwvZXZlbnRUaW1l Pg0KPiA+ICAgICAgICAgPGxpbmstdXAgLi4uLz4NCj4gPiAgICAgICA8L25vdGlmaWNhdGlvbj4N Cj4gPg0KPiA+ICAgICAgIDxub3RpZmljYXRpb24NCj4gPiAgICAgICAgICAgeG1sbnM9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIj4NCj4gPiAgICAgICAg IDxldmVudFRpbWU+MjAxNy0wMS0wOFQwMDowMDowMVo8L2V2ZW50VGltZT4NCj4gPiAgICAgICAg IDxsaW5rLWRvd24gLi4uLz4NCj4gPiAgICAgICA8L25vdGlmaWNhdGlvbj4NCj4gPiAgICAgICAu Li4NCj4gPiAgICA8L25vdGlmaWNhdGlvbj4NCj4gPg0KPiA+DQo+ID4NCj4gSSB3YXMgaG9waW5n IGZvciBhIGJ1bGsgZm9ybWF0IHRoYXQgcmVkdWNlZCB0aGUgcGF5bG9hZC4NCj4gWW91ciBleGFt cGxlIGFjdHVhbGx5IGluY3JlYXNlcyB0aGUgcGF5bG9hZCBzaXplLg0KDQpGb3IgaWxsdXN0cmF0 aW9uIHB1cnBvc2Ugb25seSA7LSkNCg0KSXQncyBwZXJmZWN0bHkgZmluZSB3LyBtZSBpZiB0aGUg Y29udGVudHMgb2YgdGhpcyAiYnVsay1ub3RpZmljYXRpb24iDQpub3RpZiBjb250YWlucyBhIGNv bXByZXNzZWQgb3IgY2xldmVybHkgZW5jb2RlZCBsaXN0IG9mDQpub3RpZmljYXRpb25zLg0KDQpU aGUgbmljZSB0aGluZyB3aXRoIHlvdXIgaWRlYSBpcyB0aGF0IGl0IGRvZXNuJ3QgY2hhbmdlIHRo ZSBjb3JlDQpwcm90b2NvbC4NCg0KDQoNCi9tYXJ0aW4NCg0KDQo+IEkgdGhpbmsgdGhlIHN1YnNj cmlwdGlvbiBuZWVkcyBzb21lIHNvcnQgb2YgZW5jb2RpbmcgbmVnb3RpYXRpb24gbGlrZSB0aGUN Cj4gQWNjZXB0IGhlYWRlciBpbiBIVFRQLg0KPiBQZW9wbGUgd2lsbCBldmVudHVhbGx5IHRoaW5r IG9mIGxvdHMgb2Ygb3B0aW1pemF0aW9ucyB0aGF0IHdlIG5ldmVyDQo+IGltYWdpbmVkLiAgVGhl IHByb3RvY29sIHNob3VsZA0KPiBiZSByb2J1c3QgZW5vdWdoIHRvIGFsbG93IHRoaXMgdG8gaGFw cGVuLiAgZS5nLiwgc2VuZCBtdWx0aXBsZQ0KPiBzdWJzY3JpcHRpb24taWQgdmFsdWVzIGluDQo+ IDEgbm90aWZpY2F0aW9uIGluc3RlYWQgb2YgZHVwbGljYXRpbmcgdGhhdCBub3RpZmljYXRpb24g dG8gdGhlIHJlY2VpdmVyIE4NCj4gdGltZXMuDQo+IEFub3RoZXIgb2J2aW91cyBvcHRpbWl6YXRp b24gaXMgdGhlIGFiaWxpdHkgdG8gZ3JvdXAgc2ltaWxhciBldmVudHMgaW50byBhDQo+IHJhbmdl DQo+IGxpa2UgbGluay11cCBmb3IgYSBwb3J0LXJhbmdlLCByZXByZXNlbnRpbmcgdGhlIGVudGly ZSBsaW5lIGNhcmQgdGhhdCB3YXMNCj4ganVzdCBwbHVnZ2VkIGluLg0KPiANCj4gICA8bm90aWZp Y2F0aW9uPg0KPiAgICAgIDxoZHI+Li4uLm5vIHJlc3RyaWN0aW9ucyBvbiB3aGF0IGlzIGluIHRo ZSBoZWFkZXIgLi4uIDwvaGRyPg0KPiAgICAgIDxsaW5rLWRvd24+IC4uLiA8L2xpbmstZG93bj4g ICAvLyBsaW1pdCB0byAxIGVsZW1lbnQgZm9yIHBheWxvYWQ/DQo+ICAgPC9ub3RpZmljYXRpb24+ DQo+IA0KPiBBIHNpbXBsZSBub3RpZmljYXRpb24gaXMgdGhlIGNhbm9uaWNhbCBmb3JtLg0KPiBB IG5vdGlmaWNhdGlvbiBzdWJzY3JpYmVyIGFjdGluZyBhcyBhIGJyb2tlciB3aWxsIG5lZWQgdG8g Y29udmVydCB0aGUgYnVsaw0KPiBmb3JtDQo+IGludG8gMSBvciBtb3JlIG5vdGlmaWNhdGlvbnMg aW4gY2Fub25pY2FsIGZvcm1hdC4NCj4gDQo+IA0KPiANCj4gPg0KPiA+IC9tYXJ0aW4NCj4gPg0K PiANCj4gQW5keQ0KPiANCj4gDQo+ID4NCj4gPg0KPiA+ID4gVGhlIHJlY2VpdmVyIE1BWSBleHRy YWN0IGluZGl2aWR1YWwgbWVzc2FnZXMgZnJvbSB0aGUgYnVsayBmb3JtYXQgKG1heWJlDQo+ID4g PiBiaW5hcnkpDQo+ID4gPiBpbnRvIG90aGVyIGZvcm1hdHMgKGxpa2UgWE1MIG9yIEpTT04pLg0K PiA+ID4NCj4gPiA+IEkgYW0gdHJ5aW5nIHRvIHBsYW4gYWhlYWQgZm9yIHdoZW4gWUFORyBQdXNo IHR1cm5zIG91dCB0byBiZSBhIHNsb3cNCj4gPiBuZXR3b3JrDQo+ID4gPiBob2cgOi0pDQo+ID4g Pg0KPiA+ID4NCj4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4NCj4gPiA+ICBBbmR5DQo+ID4g Pg0KPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFuZHkNCj4g PiA+ID4gPg0KPiA+ID4gPiA+IEZyb206IE5ldGNvbmYgW21haWx0bzptYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YNCj4gPiBBbmR5DQo+ID4gPiA+ID4gQmllcm1h bg0KPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDUsIDIwMTcgNToyNSBQTQ0KPiA+ ID4gPiA+IFRvOiBOZXRjb25mIDxtYWlsdG86bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiA+ID4gPiBT dWJqZWN0OiBbTmV0Y29uZl0gbmVzdGVkIG5vdGlmaWNhdGlvbnMNCj4gPiA+ID4gPg0KPiA+ID4g PiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSB3b3VsZCBsaWtlIHNvbWUgdGV4dCBpbiBS RkMgNzk1MCB0byBiZSByZWludGVycHJldGVkLiBUaGUgdGV4dA0KPiA+IGltcGxpZXMNCj4gPiA+ ID4gZWFjaA0KPiA+ID4gPiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGNhbiBvbmx5IGRlc2NyaWJl IDEgaW5zdGFuY2Ugb2YgMSBldmVudCB0eXBlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUkZDIDc5 NTAsIHNlYyA3LjE2LjINCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIFRoZSBpbm5lcm1vc3QgY29u dGFpbmVyIG9yIGxpc3QgY29udGFpbnMgYW4gWE1MDQo+ID4gPiA+ID4gICAgZWxlbWVudCB0aGF0 IGNhcnJpZXMgdGhlIG5hbWUgb2YgdGhlIGRlZmluZWQgbm90aWZpY2F0aW9uLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBUaGVyZSBhcmUgMyBjb3JuZXItY2FzZXMgdGhhdCBzaG91 bGQgYmUgY29uc2lkZXJlZCBpbiBvcmRlcg0KPiA+ID4gPiA+IHRvIG1pbmltaXplIG5ldHdvcmsg b3ZlcmhlYWQgZm9yIG5vdGlmaWNhdGlvbnMgaW4gNTI3N2Jpcy4NCj4gPiA+ID4gPiBSZXBsaWNh dGluZyB0aGUgbm9kZS9rZXkgaGllcmFyY2h5IGNvdWxkIGJlIGV4cGVuc2l2ZQ0KPiA+ID4gPiA+ IGFuZCBldmVudHMgb2NjdXJyaW5nIGF0IHRoZSBzYW1lIHRpbWUgY291bGQgYmUgY29ycmVsYXRl ZC4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IER1cGxpY2F0aW5nIHRoZSBub3RpZmljYXRpb24gbWVz c2FnZXMgaXMgaW5lZmZpY2llbnQsDQo+ID4gPiA+ID4gYnV0IHByb2Nlc3NpbmcgbXVsdGlwbGUg ZXZlbnRzIHBlciBtZXNzYWdlIG1ha2VzDQo+ID4gPiA+ID4gZmlsdGVyaW5nIGFuZCBwYXJzaW5n IG1vcmUgY29tcGxpY2F0ZWQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBJIGFtIGN1cmlvdXMgaWYg dGhlIFdHIHRoaW5rcyBub3RpZmljYXRpb24gb3ZlcmhlYWQgaXMgYSBjb25jZXJuIGFuZA0KPiA+ ID4gPiA+IGlmIGl0IG5lZWRzIHRvIGJlIGFkZHJlc3NlZCBzb21laG93IGluIDUyNzdiaXMuDQo+ ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDEpIG11bHRpcGxlIG5vbi1zaWJsaW5nIGV2 ZW50cyBpbiBzYW1lIHN1YnRyZWUNCj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgPG5vdGlmaWNhdGlv bj4NCj4gPiA+ID4gPiAgICAgPGludGVyZmFjZXM+DQo+ID4gPiA+ID4gICAgICAgPG15LXRvcC1l dmVudD4NCj4gPiA+ID4gPiAgICAgICAgIDxteS1kYXRhPjQyPC9teS1kYXRhPg0KPiA+ID4gPiA+ ICAgICAgIDwvbXktdG9wLWV2ZW50Pg0KPiA+ID4gPiA+ICAgICAgIDxpbnRlcmZhY2U+DQo+ID4g PiA+ID4gICAgICAgICA8bmFtZT5ldGgwPC9uYW1lPg0KPiA+ID4gPiA+ICAgICAgICAgPG15LWlu dGVyZmFjZS1ldmVudD4NCj4gPiA+ID4gPiAgICAgICAgICAgICAgIDxpZi1kYXRhPmF1dG88L2lm LWRhdGE+DQo+ID4gPiA+ID4gICAgICAgICA8L215LWludGVyZmFjZS1ldmVudD4NCj4gPiA+ID4g PiAgICAgICA8L2ludGVyZmFjZT4NCj4gPiA+ID4gPiAgICAgPC9pbnRlcmZhY2VzPg0KPiA+ID4g PiA+ICAgPC9ub3RpZmljYXRpb24+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IDIp IG11bHRpcGxlIHNpYmxpbmcgZXZlbnRzIGluIHRoZSBzYW1lIHN1YnRyZWUNCj4gPiA+ID4gPg0K PiA+ID4gPiA+ICAgPG5vdGlmaWNhdGlvbj4NCj4gPiA+ID4gPiAgICAgPGludGVyZmFjZXM+DQo+ ID4gPiA+ID4gICAgICAgPGludGVyZmFjZT4NCj4gPiA+ID4gPiAgICAgICAgIDxuYW1lPmV0aDA8 L25hbWU+DQo+ID4gPiA+ID4gICAgICAgICA8bXktaW50ZXJmYWNlLWV2ZW50Pg0KPiA+ID4gPiA+ ICAgICAgICAgICAgICAgPGlmLWRhdGE+YXV0bzwvaWYtZGF0YT4NCj4gPiA+ID4gPiAgICAgICAg IDwvbXktaW50ZXJmYWNlLWV2ZW50Pg0KPiA+ID4gPiA+ICAgICAgICAgPGludGVyZmFjZS1lbmFi bGVkPg0KPiA+ID4gPiA+ICAgICAgICAgICAgPGJ5LXVzZXI+YWRtaW48L2J5LXVzZXI+DQo+ID4g PiA+ID4gICAgICAgICA8L2ludGVyZmFjZS1lbmFibGVkPg0KPiA+ID4gPiA+ICAgICAgIDwvaW50 ZXJmYWNlPg0KPiA+ID4gPiA+ICAgICA8L2ludGVyZmFjZXM+DQo+ID4gPiA+ID4gICA8L25vdGlm aWNhdGlvbj4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gMykgbXVsdGlwbGUgbm9u LXNpYmxpbmcgZXZlbnRzIGluIGRpZmZlcmVudCBzdWJ0cmVlcw0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gICA8bm90aWZpY2F0aW9uPg0KPiA+ID4gPiA+ICAgICA8c3lzdGVtPg0KPiA+ID4gPiA+ICAg ICAgIDxteS1zeXN0ZW0tZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgICAgICAgPG15LWRhdGE+NDI8 L215LWRhdGE+DQo+ID4gPiA+ID4gICAgICAgPC9teS1zeXN0ZW0tZXZlbnQ+DQo+ID4gPiA+ID4g ICAgIDwvc3lzdGVtPg0KPiA+ID4gPiA+ICAgICA8aW50ZXJmYWNlcz4NCj4gPiA+ID4gPiAgICAg ICA8aW50ZXJmYWNlPg0KPiA+ID4gPiA+ICAgICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4NCj4gPiA+ ID4gPiAgICAgICAgIDxteS1pbnRlcmZhY2UtZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgICAgICAg ICA8aWYtZGF0YT5hdXRvPC9pZi1kYXRhPg0KPiA+ID4gPiA+ICAgICAgICAgPC9teS1pbnRlcmZh Y2UtZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgPC9pbnRlcmZhY2U+DQo+ID4gPiA+ID4gICAgIDwv aW50ZXJmYWNlcz4NCj4gPiA+ID4gPiAgIDwvbm90aWZpY2F0aW9uPg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEFuZHkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPiA+DQo+ID4NCg== From nobody Thu Jan 12 10:45:01 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36EEE129435; Thu, 12 Jan 2017 10:44:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 heN2KVIOWi2Q; Thu, 12 Jan 2017 10:44:53 -0800 (PST) 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 40AC41293F3; Thu, 12 Jan 2017 10:44:53 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 184CC7C2; Thu, 12 Jan 2017 19:44:52 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id T-yJd-aitBPt; Thu, 12 Jan 2017 19:44:48 +0100 (CET) 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, 12 Jan 2017 19:44:51 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B21DB2008E; Thu, 12 Jan 2017 19:44:51 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id FbGHND9kSYxT; Thu, 12 Jan 2017 19:44:50 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 928E22008C; Thu, 12 Jan 2017 19:44:50 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F01FE3E0B4E8; Thu, 12 Jan 2017 19:44:52 +0100 (CET) Date: Thu, 12 Jan 2017 19:44:52 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170112184452.GC21677@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:44:56 -0000 On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > > > > > YANG statements: > > > - It is not possible to define these statements so they are different > > > for config and oper > > > - must > > > - when > > > - unique > > > - key > > > - min-elements > > > - max-elements > > > - leafref (path) > > > - if-feature > > > - deviation > > > - type (or any sub-statements of type-stmt) > > > - status > > > - description > > > - reference > > > > Considering statements that constraint 'values', it is not entirely > > clear to me what they mean for state nodes. If a server has > > operational state that violates a must or range or ... constraint in > > the YANG model, what is the server expected to do? > > > > The client uses the YANG validation to check on what the server is sending. > The server is buggy if it is sending data that violates YANG constraints. > If any of these statements need to be different for config and oper > then the old style YANG has to be used instead. > OK. So the client does the validation. What does the client do if the operational state it got is not valid according to the YANG constraints? /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 Jan 12 10:57:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 523D1129484 for ; Thu, 12 Jan 2017 10:57:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ucQoZoa_CqYs for ; Thu, 12 Jan 2017 10:57:19 -0800 (PST) Received: from mail-pf0-x230.google.com (mail-pf0-x230.google.com [IPv6:2607:f8b0:400e:c00::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0FA8112947F for ; Thu, 12 Jan 2017 10:57:19 -0800 (PST) Received: by mail-pf0-x230.google.com with SMTP id y143so17336531pfb.0 for ; Thu, 12 Jan 2017 10:57:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=D2kC2pAjNuRKlhHxKO+e5oanfz0y8tpJGAKwKcmjleY=; b=g0E8MIcY+5yI3OW+KMYVFpqyo6hv34Njtv3ibdw6fHF1SY5Hu6EU94IabwhPhN9UhZ Kgv4o18FFEqZLStr9BqKVCq+b6fnZvHpXIxjIRIa2+OYp5DArAsv6sGcIejYsg3gnapV SAUfv0sQSyVVlk6fKdQCnWEYC/I7JV5k9JbHuWfpqddFgka4hKAlskJSBobC2DPa6ykV EFzWHbOcGD0KOKmWOQ/84Y7IRxAAKfGypfEMNLE3GalLWmPB2INaH8etLiez4LlFPkmz xHQTE4Wfc9LpJUx48G7vbi7w6ElXA+OB/yKFl4fEtT4pIqT2r+JNPuadfFujshPAD9kG F1Dw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=D2kC2pAjNuRKlhHxKO+e5oanfz0y8tpJGAKwKcmjleY=; b=ub+qysRp6/YYUUd05STY2+qZo7WRIGCnz1YWxk3BFVWyedug0vqWMlqAf94blxNcJf u5txv7+qjc1IKGn3pjQRI7qEangUPMubwLSoArBYnOslGVmh285pJ7zHfSROmAOSCE+O HePuhAiAhomXQKlCKa7oPrsRTq4n4VTDiwPnCRSqLp9860noN5msGgeyNBXsf55XZOgM J/sEAjswPgvntGhqEznGiqosmBvvov9BTSCcUipioerFhXAgVUpfpl4griNWExJnnrG8 eHiNVaeHw0Y2voUwCL2m6FOd5gP7uaHQ4A5JExAYYMQbU0HlJIwZwL8r51o7WyvtxoYM wU8Q== X-Gm-Message-State: AIkVDXIcZXcRkC/udqa7vgAMorASxeXre9Kdt4r8rHe1SHher8qWX3cUUX31BSKw9IeBMQ== X-Received: by 10.99.127.16 with SMTP id a16mr19230131pgd.60.1484247438429; Thu, 12 Jan 2017 10:57:18 -0800 (PST) Received: from sjc-mahesh-nitro5.cisco.com ([128.107.241.191]) by smtp.gmail.com with ESMTPSA id w11sm23423179pfk.75.2017.01.12.10.57.16 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 12 Jan 2017 10:57:17 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_10313B64-2ED7-43EE-AEB7-3AFE86B65C57" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Mahesh Jethanandani In-Reply-To: Date: Thu, 12 Jan 2017 10:57:15 -0800 Message-Id: <39375138-A4A9-4F97-8475-6D2BD7D2B8B1@gmail.com> References: <20170112.135320.1844651205821472591.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.3124) Archived-At: Cc: Netconf Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 18:57:21 -0000 --Apple-Mail=_10313B64-2ED7-43EE-AEB7-3AFE86B65C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jan 12, 2017, at 9:25 AM, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Jan 12, 2017 at 4:53 AM, Martin Bjorklund > wrote: > Andy Bierman > wrote: > > Hi, > > > > I would like some text in RFC 7950 to be reinterpreted. The text = implies > > each > > notification message can only describe 1 instance of 1 event type. > > > > RFC 7950, sec 7.16.2 > > > > The innermost container or list contains an XML > > element that carries the name of the defined notification. > > > > > > > > There are 3 corner-cases that should be considered in order > > to minimize network overhead for notifications in 5277bis. > > Replicating the node/key hierarchy could be expensive > > and events occurring at the same time could be correlated. > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >=20 > So how common is this? Is it worth the additional complexity to > support this case? How many events would have to be generated at the > same time for this "optimization" be worth it? >=20 >=20 > Depends on the meaning of "same time". > If I am implementing a client-configured digest service, and the = client only > wants to receive notifications every 1 - 5 seconds instead of ASAP. > I can build up a tree of YANG 1.1 notifications and send it off in N = seconds, > then start a new tree. >=20 > I agree it is very implementation dependent whether or not the = originator of the event > will combine that event with others. (Most likely not). The ability to correlate events is important.=20 Take the example of OAM running at different layers in the network. A = failure at the physical layer will result in multiple events being = generated at the higher layers. The ability to correlate events allows = the suppression of events/alarms in the layer directly above the level = where the fault/event was first detected. And if I can do that for one = extra event, I have optimized. >=20 > =20 >=20 > /martin >=20 >=20 > Andy > =20 >=20 > > Duplicating the notification messages is inefficient, > > but processing multiple events per message makes > > filtering and parsing more complicated. > > > > I am curious if the WG thinks notification overhead is a concern and > > if it needs to be addressed somehow in 5277bis. > > > > > > 1) multiple non-sibling events in same subtree > > > > > > > > > > > > > > * * > > > > * 42* > > > > * * > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > > > > > > > > > > > > > > > > > 2) multiple sibling events in the same subtree > > > > > > > > > > > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > * * > > > > * admin* > > > > * * > > > > > > > > > > > > > > > > > > > > 3) multiple non-sibling events in different subtrees > > > > > > > > > > > > > > * * > > > > * 42* > > > > * * > > > > > > > > > > > > > > > > eth0 > > > > * * > > > > * auto* > > > > * * > > > > > > > > > > > > > > > > > > > > > > Andy >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_10313B64-2ED7-43EE-AEB7-3AFE86B65C57 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jan 12, 2017, at 9:25 AM, Andy Bierman <andy@yumaworks.com> = wrote:



On Thu, Jan 12, 2017 at 4:53 AM, = Martin Bjorklund <mbj@tail-f.com> wrote:
Andy Bierman <andy@yumaworks.com> = wrote:
> Hi,
>
> I would like some text in RFC 7950 to be reinterpreted. The text = implies
> each
> notification message can only describe 1 instance of 1 event = type.
>
> RFC 7950, sec 7.16.2
>
>    The innermost container or list contains an XML
>    element that carries the name of the defined = notification.
>
>
>
> There are 3 corner-cases that should be considered in order
> to minimize network overhead for notifications in 5277bis.
> Replicating the node/key hierarchy could be expensive
> and events occurring at the same time could be correlated.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So how common is this?  Is it worth the additional complexity to
support this case?  How many events would have to be generated at = the
same time for this "optimization" be worth it?


Depends on the meaning of "same time".
If = I am implementing a client-configured digest service, and the client = only
wants to receive notifications every 1 - 5 = seconds instead of ASAP.
I can build up a tree of = YANG 1.1 notifications and send it off in N seconds,
then start a new tree.

I agree it is very implementation = dependent whether or not the originator of the event
will combine that event with others. (Most likely = not).

The ability to correlate events is = important. 

Take the example of = OAM running at different layers in the network. A failure at the = physical layer will result in multiple events being generated at the = higher layers. The ability to correlate events allows the suppression of = events/alarms in the layer directly above the level where the = fault/event was first detected. And if I can do that for one extra = event, I have optimized.


 

/martin


Andy
 

> Duplicating the notification messages is inefficient,
> but processing multiple events per message makes
> filtering and parsing more complicated.
>
> I am curious if the WG thinks notification overhead is a concern = and
> if it needs to be addressed somehow in 5277bis.
>
>
> 1) multiple non-sibling events in same subtree
>
>
>   <notification>
>
>     <interfaces>
>
>     *  <my-top-event>*
>
> *        <my-data>42</my-data>*
>
> *      </my-top-event>*
>
>       <interface>
>
>         <name>eth0</name>
>
>     *    <my-interface-event>*
>
> *              = <if-data>auto</if-data>*
>
> *        </my-interface-event>*
>
>       </interface>
>
>     </interfaces>
>
>   </notification>
>
>
>
> 2) multiple sibling events in the same subtree
>
>
>   <notification>
>
>     <interfaces>
>
>       <interface>
>
>         <name>eth0</name>
>
>      *   <my-interface-event>*
>
> *              = <if-data>auto</if-data>*
>
> *        </my-interface-event>*
>
> *        <interface-enabled>*
>
> *          =  <by-user>admin</by-user>*
>
> *        </interface-enabled>  *
>
>       </interface>
>
>     </interfaces>
>
>   </notification>
>
>
>
> 3) multiple non-sibling events in different subtrees
>
>
>   <notification>
>
>     <system>
>
>    *   <my-system-event>*
>
> *            = <my-data>42</my-data>*
>
> *      </my-system-event>*
>
>     </system>
>
>     <interfaces>
>
>       <interface>
>
>         <name>eth0</name>
>
>        * <my-interface-event>*
>
> *              = <if-data>auto</if-data>*
>
> *        </my-interface-event>*
>
>       </interface>
>
>     </interfaces>
>
>   </notification>
>
>
>
>
> Andy

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

Mahesh Jethanandani
mjethanandani@gmail.com



= --Apple-Mail=_10313B64-2ED7-43EE-AEB7-3AFE86B65C57-- From nobody Thu Jan 12 12:54:45 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E4AD129483; Thu, 12 Jan 2017 12:54:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 78kEG4HcFJLI; Thu, 12 Jan 2017 12:54:41 -0800 (PST) Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E116D129481; Thu, 12 Jan 2017 12:54:41 -0800 (PST) From: Alex Campbell To: Andy Bierman , Juergen Schoenwaelder Thread-Topic: [netmod] [Netconf] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits Thread-Index: AQHSaE0J1+3vtKka+km/wzqqYB4OMqEsVSSAgAAOqACABDhbgIAAA9SAgAADg4CAAGDRAIAAHFwAgAAJDoCAAAdCgIAAhzOAgACqYICAAAzRgIAADk0AgAAE0ACAAA7XgIAAA8uAgAAKVICAAA5/AIAAFi8AgAARsYCAALgOgIAAYfIAgAAc7QCAAAcCgIAANWWAgAEQd4CAAEwUAIAAA/MAgAABUgCAABJ4AP//nGXE Date: Thu, 12 Jan 2017 20:54:38 +0000 Message-ID: <1484254478595.50623@Aviatnet.com> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> , <20170112184452.GC21677@elstar.local> In-Reply-To: <20170112184452.GC21677@elstar.local> Accept-Language: en-NZ, en-US Content-Language: en-NZ X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.15.6.10] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 20:54:44 -0000 IMO it should be treated like any other protocol error.=0A= Which means that an ideal client will report an error - but in practice the= y'll end up ignoring the constraint violation because it's easier to not do= validation.=0A= =0A= This problem isn't specific to YANG - what happens if I make a request to a= n HTTP server ("GET / HTTP/1.1") and the server sends back nonsense ("FOOBA= R/-1.3i xyz Didn't feel like it")?=0A= A good client will report that there was an error parsing the response; a b= ad client might call atoi on the second field (recording the status code as= 0) and ignore the other fields.=0A= Is there anything we can do about that? I don't think there is.=0A= =0A= Alex=0A= =0A= ________________________________________=0A= From: netmod on behalf of Juergen Schoenwaelder <= j.schoenwaelder@jacobs-university.de>=0A= Sent: Friday, 13 January 2017 7:44 a.m.=0A= To: Andy Bierman=0A= Cc: Netconf; netmod@ietf.org=0A= Subject: Re: [netmod] [Netconf] Decision on the Intended Status of the Revi= sed DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits=0A= =0A= On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:=0A= > On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder <=0A= > j.schoenwaelder@jacobs-university.de> wrote:=0A= >=0A= > > On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote:=0A= > > >=0A= > > > YANG statements:=0A= > > > - It is not possible to define these statements so they are differ= ent=0A= > > > for config and oper=0A= > > > - must=0A= > > > - when=0A= > > > - unique=0A= > > > - key=0A= > > > - min-elements=0A= > > > - max-elements=0A= > > > - leafref (path)=0A= > > > - if-feature=0A= > > > - deviation=0A= > > > - type (or any sub-statements of type-stmt)=0A= > > > - status=0A= > > > - description=0A= > > > - reference=0A= > >=0A= > > Considering statements that constraint 'values', it is not entirely=0A= > > clear to me what they mean for state nodes. If a server has=0A= > > operational state that violates a must or range or ... constraint in=0A= > > the YANG model, what is the server expected to do?=0A= > >=0A= >=0A= > The client uses the YANG validation to check on what the server is sendin= g.=0A= > The server is buggy if it is sending data that violates YANG constraints.= =0A= > If any of these statements need to be different for config and oper=0A= > then the old style YANG has to be used instead.=0A= >=0A= =0A= OK. So the client does the validation. What does the client do if the=0A= operational state it got is not valid according to the YANG constraints?=0A= =0A= /js=0A= =0A= --=0A= Juergen Schoenwaelder Jacobs University Bremen gGmbH=0A= Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany=0A= Fax: +49 421 200 3103 =0A= =0A= _______________________________________________=0A= netmod mailing list=0A= netmod@ietf.org=0A= https://www.ietf.org/mailman/listinfo/netmod=0A= From nobody Thu Jan 12 13:20:57 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4F0F129508; Thu, 12 Jan 2017 13:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bj1MNpjqOIgE; Thu, 12 Jan 2017 13:20:47 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E0E81294F9; Thu, 12 Jan 2017 13:20:47 -0800 (PST) Received: from [172.29.2.202] (nat-14.bravonet.cz [77.48.225.14]) by mail.nic.cz (Postfix) with ESMTPSA id 9B6FE6098C; Thu, 12 Jan 2017 22:20:45 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484256045; bh=wXdmhO5M/zcD8LIIZyxHWyQmTat7IuyO6TeT8oWrijM=; h=From:Date:To; b=A81xucwZ1FW/9KPv4/JeNbmrUF00lX60T9RfIfWMsJ1N1f603kWs0QTFKqhDWhfzp rM8vUvxMZsfe8Ho4Gr1JkaRI3n3zCrrsh5SKNLhE/7EWu2woe3tCC+NbKEt0XCLBv3 0d4u5nFDQRZFEYfrdiwvmJ3Rc8NtLJSxN/NksTPQ= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112184452.GC21677@elstar.local> Date: Thu, 12 Jan 2017 22:20:44 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:20:53 -0000 > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >>=20 >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>=20 >>>> YANG statements: >>>> - It is not possible to define these statements so they are = different >>>> for config and oper >>>> - must >>>> - when >>>> - unique >>>> - key >>>> - min-elements >>>> - max-elements >>>> - leafref (path) >>>> - if-feature >>>> - deviation >>>> - type (or any sub-statements of type-stmt) >>>> - status >>>> - description >>>> - reference >>>=20 >>> Considering statements that constraint 'values', it is not entirely >>> clear to me what they mean for state nodes. If a server has >>> operational state that violates a must or range or ... constraint in >>> the YANG model, what is the server expected to do? >>>=20 >>=20 >> The client uses the YANG validation to check on what the server is = sending. >> The server is buggy if it is sending data that violates YANG = constraints. >> If any of these statements need to be different for config and oper >> then the old style YANG has to be used instead. >>=20 >=20 > OK. So the client does the validation. What does the client do if the > operational state it got is not valid according to the YANG = constraints? Don't forget that data models also provide guidelines to server = implementors. It is not without reason to write a test suite that = validates server responses, including state data. 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 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Thu Jan 12 13:28:05 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB4A41294F9; Thu, 12 Jan 2017 13:27:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 ZzrFUnHbE1WH; Thu, 12 Jan 2017 13:27:57 -0800 (PST) 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 E1299129499; Thu, 12 Jan 2017 13:27:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8B8680E; Thu, 12 Jan 2017 22:27:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yefyiHB053io; Thu, 12 Jan 2017 22:27:52 +0100 (CET) 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, 12 Jan 2017 22:27:55 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C53320091; Thu, 12 Jan 2017 22:27:55 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id mpiohPqj-q3d; Thu, 12 Jan 2017 22:27:54 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C8C5120090; Thu, 12 Jan 2017 22:27:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 5D4153E0B77C; Thu, 12 Jan 2017 22:27:56 +0100 (CET) Date: Thu, 12 Jan 2017 22:27:55 +0100 From: Juergen Schoenwaelder To: Ladislav Lhotka Message-ID: <20170112212755.GA22142@elstar.local> Mail-Followup-To: Ladislav Lhotka , Andy Bierman , Netconf , "netmod@ietf.org" References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:28:00 -0000 On Thu, Jan 12, 2017 at 10:20:44PM +0100, Ladislav Lhotka wrote: > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder wrote: > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > >>>> > >>>> YANG statements: > >>>> - It is not possible to define these statements so they are different > >>>> for config and oper > >>>> - must > >>>> - when > >>>> - unique > >>>> - key > >>>> - min-elements > >>>> - max-elements > >>>> - leafref (path) > >>>> - if-feature > >>>> - deviation > >>>> - type (or any sub-statements of type-stmt) > >>>> - status > >>>> - description > >>>> - reference > >>> > >>> Considering statements that constraint 'values', it is not entirely > >>> clear to me what they mean for state nodes. If a server has > >>> operational state that violates a must or range or ... constraint in > >>> the YANG model, what is the server expected to do? > >>> > >> > >> The client uses the YANG validation to check on what the server is sending. > >> The server is buggy if it is sending data that violates YANG constraints. > >> If any of these statements need to be different for config and oper > >> then the old style YANG has to be used instead. > >> > > > > OK. So the client does the validation. What does the client do if the > > operational state it got is not valid according to the YANG constraints? > > Don't forget that data models also provide guidelines to server implementors. It is not without reason to write a test suite that validates server responses, including state data. > OK. But what do you expect a regular client to do? /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 Jan 12 13:34:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6DCA6129443 for ; Thu, 12 Jan 2017 13:34:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 27W8I6SN-wUk for ; Thu, 12 Jan 2017 13:34:52 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A650F1289C4 for ; Thu, 12 Jan 2017 13:34:51 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml705-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYR80373; Thu, 12 Jan 2017 21:34:49 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml705-cah.china.huawei.com (10.201.5.168) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 21:34:48 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Thu, 12 Jan 2017 13:34:43 -0800 From: Alexander Clemm To: Martin Bjorklund , "andy@yumaworks.com" Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KSFQsAF1aiAU+PjrHFwgk9UKEqeKNAgACZJoCAAIaW4IAAADDwgAFZcoCACGxXgIAATXWAgAAO8ID//5YBgA== Date: Thu, 12 Jan 2017 21:34:42 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> References: <20170112.135947.218954166063566738.mbj@tail-f.com> <20170112.193029.9249587815129986.mbj@tail-f.com> In-Reply-To: <20170112.193029.9249587815129986.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.47] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020204.5877F679.02F2, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 251aff3eb5f78038998fdfc04b3e53b5 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:34:54 -0000 SSBhZ3JlZSB0aGF0IGl0IG1ha2VzIHNlbnNlIHRvIGFsbG93IG11bHRpcGxlIG5vdGlmaWNhdGlv bnMgdG8gYmUgc2VudCBpbiBvbmUgbWVzc2FnZS4gIA0KDQpXZSBuZWVkIHRvIGFsbG93IGZvciBk aWZmZXJlbnQgdGltZSBzdGFtcHMsIGFsbG93aW5nIHRvIHN0YW1wIGluZGl2aWR1YWwgbm90aWZp Y2F0aW9ucyBzZXBhcmF0ZWx5LiAgQ2xlYXJseSwgY29tcHJlc3Npb24gc2NoZW1lcyBjYW4gYmUg ZGV2aXNlZCwgaW5jbHVkaW5nIGEgdHJpdmlhbCBjb21wcmVzc2lvbiBzY2hlbWUgdG8gYXBwbHkg b25lICJidWxrIiB0aW1lc3RhbXAgZm9yIGV2ZXJ5IG5vdGlmaWNhdGlvbiBpbiB0aGUgbWVzc2Fn ZS4gIA0KDQpMb29raW5nIGF0IFJGQyA3OTUwIFNlY3Rpb24gNy4xNi4yLCBJIGFtIG5vdCBzdXJl IGhvdyB0byBwYXJzZSBpdCwgc3BlY2lmaWNhbGx5IGl0IGlzIG5vdCBjbGVhciB3aGF0IGlzIHJl YWxseSBtYW5kYXRlZCBhcyBwYXJ0IG9mIHRoZSBlbmNvZGluZy4gIFRoZSBSRkMgc3RhdGVzIG1l cmVseSB0aGF0IHRoZSBub3RpZmljYXRpb24gaXMgZW5jb2RlZCBhcyBfYV8gY2hpbGQgWE1MIGVs ZW1lbnQgdG8gdGhlIDxub3RpZmljYXRpb24+IGVsZW1lbnQuICBUaGUgc3BlY2lmaWNhdGlvbi9k ZWZpbml0aW9uIG9mIHRoZSA8bm90aWZpY2F0aW9uPiBlbGVtZW50IGl0c2VsZiBpcyBob3dldmVy IG5vdCBwYXJ0IG9mIFJGQyA3OTUwLCBuZWl0aGVyIGlzIHRoZSBkZWZpbml0aW9uIG9mIHRoZSB0 aW1lIHN0YW1wIChldmVudC10aW1lKS4gIEl0IHNlZW1zIHRoYXQgYWxsIHRoYXQgaXMgc3BlY2lm aWVkIGlzIHRoZSBlbmNvZGluZyBvZiB0aGUgZXZlbnQgaXRzZWxmLCBpLmUuIHRoZSByZXByZXNl bnRhdGlvbiBvZiB0aGUgbm90aWZpY2F0aW9uIGlkZW50aWZpZXIgYW5kIHRoZW4gdGhlIHBhcmFt ZXRlcnMgY29udGFpbmVkIHdpdGhpbiBpdC4gDQoNCkRvZXMgUkZDIDc5NTAgaW1wbHkgdGhhdCBu b3RpZmljYXRpb24gbm9kZXMgY2FuIG9ubHkgYmUgZW5jb2RlZCBhcyBjb250YWluZWQgaW4gYSA8 bm90aWZpY2F0aW9uPiBlbGVtZW50IGFzIGRlZmluZWQgaW4gUkZDIDUyNzc/ICBUaGF0IHdvdWxk IGJlIGEgY29uc2lkZXJhYmxlIGxpbWl0YXRpb24gYW5kIGlzc3VlIGF0IGxlYXN0IGluIHRoZSBj b250ZXh0IG9mIE5ldGNvbmYuICBJIGd1ZXNzIG9uZSBjb3VsZCBhbHdheXMgZGVmaW5lIG90aGVy IGVuY29kaW5nIHJ1bGVzIG91dHNpZGUgb2YgTmV0Y29uZi4gIEkgZG9uJ3QgdGhpbmsgZGVmaW5p bmcgYSBidWxrIG5vdGlmaWNhdGlvbiBhcyBhIHNwZWNpYWwgbm90aWZpY2F0aW9uLCB0aGF0IGl0 c2VsZiBuZWVkcyB0byBiZSBjYXJyaWVkIGluIGEgcmVndWxhciBub3RpZmljYXRpb24sIGlzIGEg Z29vZCBzb2x1dGlvbi4gIFRoZSBub3RpZmljYXRpb24gZWxlbWVudCBpcyBwdXJlIG92ZXJoZWFk IGF0IHRoaXMgcG9pbnQuICBBbGxvd2luZyB0aGUgZGVmaW5pdGlvbiBvZiBhIG5ldyBidWxrIG5v dGlmaWNhdGlvbiBlbGVtZW50LCB3aGljaCBjYW4gYmUgdXNlZCBpbiBsaWV1IG9mIGEgbm90aWZp Y2F0aW9uIGVsZW1lbnQsIHdvdWxkIHNlZW0gYSBsb3QgbW9yZSBkZXNpcmFibGUuICANCg0KLS0t IEFsZXgNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE5ldGNvbmYgW21haWx0 bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYXJ0aW4gQmpvcmtsdW5k DQpTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxMiwgMjAxNyAxMDozMCBBTQ0KVG86IGFuZHlAeXVt YXdvcmtzLmNvbQ0KQ2M6IG5ldGNvbmZAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbTmV0Y29uZl0g bmVzdGVkIG5vdGlmaWNhdGlvbnMNCg0KQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+ IHdyb3RlOg0KPiBPbiBUaHUsIEphbiAxMiwgMjAxNyBhdCA0OjU5IEFNLCBNYXJ0aW4gQmpvcmts dW5kIDxtYmpAdGFpbC1mLmNvbT4gd3JvdGU6DQo+IA0KPiA+IEFuZHkgQmllcm1hbiA8YW5keUB5 dW1hd29ya3MuY29tPiB3cm90ZToNCj4gPiA+IE9uIEZyaSwgSmFuIDYsIDIwMTcgYXQgOToyOCBB TSwgRXJpYyBWb2l0IChldm9pdCkgDQo+ID4gPiA8ZXZvaXRAY2lzY28uY29tPg0KPiA+IHdyb3Rl Og0KPiA+ID4NCj4gPiA+ID4gPiBGcm9tOiBBbmR5IEJpZXJtYW4sIEphbnVhcnkgNSwgMjAxNyA5 OjQzIFBNDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiBPbiBUaHUsIEphbiA1LCAyMDE3IGF0IDU6MTYg UE0sIEVyaWMgVm9pdCAoZXZvaXQpIDxtYWlsdG86DQo+ID4gPiA+IGV2b2l0QGNpc2NvLmNvbT4N Cj4gPiA+ID4gPiB3cm90ZToNCj4gPiA+ID4gPiBIaSBBbmR5LA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4g4oCcVGhlIGlubmVybW9zdCBjb250YWluZXIgb3IgbGlzdOKAnSB0ZXh0IGlzIHNpbWlsYXIg dG8gdGhhdCBmb3INCj4gPiBhY3Rpb25zIGluDQo+ID4gPiA+IHNlY3Rpb24NCj4gPiA+ID4gPiA3 LjE1LjIuICAgUGVyaGFwcyB0aGUgbWVudGFsIG1vZGVsIG9mIG9uZSB0YXJnZXQgZm9yIGFuIGFj dGlvbiB3YXMNCj4gPiA+ID4gcmVwbGljYXRlZD8NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEkgaGFk IG5vdCBjb25zaWRlcmVkIHRoYXQgWUFORyAxLjHigJlzIGRlZmluaXRpb24gbWlnaHQgZm9yY2Ug DQo+ID4gPiA+ID4gdGhlDQo+ID4gYnJlYWt1cA0KPiA+ID4gPiBvZiBhDQo+ID4gPiA+ID4gdmVy Ym9zZSBzb2Z0d2FyZSBjb21wb25lbnQgZ2VuZXJhdGVkIG5vdGlmaWNhdGlvbiBpbnRvIA0KPiA+ ID4gPiA+IG11bHRpcGxlDQo+ID4gcHVzaGVkDQo+ID4gPiA+ID4gbm90aWZpY2F0aW9uIG1lc3Nh Z2VzLiAgTG9va2luZyBhdCB0aGUgdGhyZWUgY2FzZXMgYmVsb3csIEkgDQo+ID4gPiA+ID4gZG9u 4oCZdA0KPiA+IHRoaW5rDQo+ID4gPiA+IHRoYXQNCj4gPiA+ID4gPiBhcmJpdHJhcnkgY2hvaWNl cyBtYWRlIGluIFlBTkcgbW9kZWwgc3RydWN0dXJlIHNob3VsZCBpbXBhY3QgDQo+ID4gPiA+ID4g d2hhdA0KPiA+IGNvdWxkDQo+ID4gPiA+IG9yDQo+ID4gPiA+ID4gY291bGRu4oCZdCBiZSBpbiBl bmNvZGVkIHdpdGhpbiBhbnkgc2luZ2xlIG5vdGlmaWNhdGlvbi4gIFNvIG15DQo+ID4gcHJlZmVy ZW5jZQ0KPiA+ID4gPiB3b3VsZA0KPiA+ID4gPiA+IGJlIHRoYXQgYWxsIHRocmVlIHZhcmlhbnRz IGJlbG93IHNob3VsZCBzdXBwb3J0YWJsZSBpZiB0aGF0IGlzIA0KPiA+ID4gPiA+IGhvdw0KPiA+ IHRoZQ0KPiA+ID4gPiBzeXN0ZW0NCj4gPiA+ID4gPiBwYXNzZWQgdGhlbSB0byBiZSBlbmNvZGVk IGFzIHBhcnQgb2YgYW4gZXZlbnQuDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ ID4gPiA+ID4gSSB0aGluayB0aGUgV0cgZGlkIG5vdCBjb25zaWRlciB0aGVzZSBkZXRhaWxzIGFu ZCBhc3N1bWVkIHRoZXkgDQo+ID4gPiA+ID4gd2VyZQ0KPiA+IHRoZQ0KPiA+ID4gPiBzYW1lDQo+ ID4gPiA+ID4gYXMgZm9yIGFjdGlvbi4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+IFRoaXMgd291bGQg YmUgYSBNQVkgZm9yIHRoZSBzZXJ2ZXIgYW5kIGEgTVVTVCBmb3IgdGhlIGNsaWVudCwgDQo+ID4g PiA+ID4gc28gaXQNCj4gPiBpcw0KPiA+ID4gPiBub3QNCj4gPiA+ID4gPiBhbiBlYXN5IGRlY2lz aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gQSBjb3VwbGUgdXNlLWNhc2VzIEkgaGF2ZSBpbiBt aW5kOg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICAxKSBldmVudCBicm9rZXINCj4gPiA+ID4gPiAg ICAgICBzdWJzY3JpYmVyIGlzIHJlYWxseSBhIGJyb2tlciB0aGF0IG1heSBiZSBwcmUtcHJvY2Vz c2luZyANCj4gPiA+ID4gPiBsb3RzDQo+ID4gb2YNCj4gPiA+ID4gPiAgICAgICBzdWJzY3JpcHRp b25zIG9yIGV2ZW50IHR5cGVzIHdpdGhpbiAxIHN1YnNjcmlwdGlvbg0KPiA+ID4gPiA+DQo+ID4g PiA+ID4gICAgMikgZGlnZXN0ICh0aW1lLWJhc2VkIHB1c2gpDQo+ID4gPiA+ID4gICAgICBTdWJz Y3JpYmVyIHdhbnRzIGFuIHVwZGF0ZSBldmVyeSA1IHNlY29uZHMgd2l0aCBhbGwgdGhlIA0KPiA+ ID4gPiA+IFlBTkcgMS4xDQo+ID4gPiA+IGV2ZW50cw0KPiA+ID4gPiA+ICAgICBmb3IgdGhlIHBy ZXZpb3VzIDUgc2Vjb25kcw0KPiA+ID4gPg0KPiA+ID4gPiBUaGVzZSBhcmUgYm90aCByZWFzb25h YmxlIGFzIGNvbnRyb2xsZXJzIGFyZSByZXF1aXJpbmcgc2NhbGFibGUNCj4gPiBtZXRob2RzIG9m DQo+ID4gPiA+IHN5bmNoaW5nIG9uIGRldmljZSBzdGF0dXMuDQo+ID4gPiA+DQo+ID4gPiA+ID4g V2hhdCBpZiB0aGUgcmVpbnRlcnByZXRhdGlvbiB3ZXJlIGFzIHNpbXBsZSBhcyDigJxBbiBpbm5l cm1vc3TigJ0gDQo+ID4gPiA+ID4gb3Ig4oCcVGhlDQo+ID4gPiA+IGZpcnN0DQo+ID4gPiA+ID4g aW5uZXJtb3N04oCdPw0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gVGhpcyBjb3ZlcnMgY2FzZSAyLiAo Q2hhbmdlICJUaGUiIHRvICJBbiIpLg0KPiA+ID4gPiA+IFRoZSBjbGllbnQgd291bGQgbmVlZCB0 byBjaGVjayBmb3IgWUFORyAxLjEgbm90aWZpY2F0aW9ucyBpbiANCj4gPiA+ID4gPiB0aGUgc2Ft ZSB3YXkgaXQgY2hlY2tzIGNoaWxkIG5vZGVzIGFscmVhZHkuDQo+ID4gPiA+DQo+ID4gPiA+ICJB bnkgaW5uZXJtb3N0Ii4uLj8gICBBbmQgeWVzLCB0aGlzIGlzIGEgbW9yZSBzaWduaWZpY2FudCBj aGFuZ2Ugb24gdGhlDQo+ID4gPiA+IGNsaWVudC4gIEJleW9uZCB0aGlzLCBmb3IgdXNlIGNhc2Vz ICgxKSAmICgyKSwgaWYgeW91IGRvbid0IHdhbnQgDQo+ID4gPiA+IHRvIHN1bW1hcml6ZSB0aGUg ZXZlbnRUaW1lLCB0aGUgdGltZSBzaG91bGQgYmUgcGxhY2VkIHdpdGggZWFjaCANCj4gPiA+ID4g aW5uZXJtb3N0IGV2ZW50LiAgSSBhbSBub3Qgc3VnZ2VzdGluZyB3ZSBkbyB0aGlzLCBidXQgbGlr ZSBBbmR5IA0KPiA+ID4gPiBJIHdhbnQgdG8gZmlndXJlDQo+ID4gb3V0DQo+ID4gPiA+IHdoYXQg dGhlIFdHIG1pZ2h0IGJlIHdpbGxpbmcgdG8gY29uc2lkZXIgaW4gc2NvcGUuDQo+ID4gPiA+DQo+ ID4gPiA+DQo+ID4gPg0KPiA+ID4gVGhlcmUgd2FzIGFjdHVhbGx5IGEgbG90IG9mIGRpc2N1c3Np b24gYWJvdXQgImV2ZW50VGltZSIgaW4gdGhlIA0KPiA+ID4gTkVUQ09ORg0KPiA+IFdHDQo+ID4g PiB3aGVuIFJGQyA1Mjc3IHdhcyBkb25lLg0KPiA+ID4gTG90cyBvZiBkaXNhZ3JlZW1lbnQgb24g d2hhdCBpdCBtZWFucy4gIFRoZSBSRkMgb2ZmZXJzIGxpdHRsZSANCj4gPiA+IGd1aWRhbmNlIG9y IGhpbnQgb2YgdGhlIGRpc2N1c3Npb246DQo+ID4gPg0KPiA+ID4NCj4gPiA+ICAgICBldmVudFRp bWU6DQo+ID4gPiAgICAgICAgVGhlIHRpbWUgdGhlIGV2ZW50IHdhcyBnZW5lcmF0ZWQgYnkgdGhl IGV2ZW50IHNvdXJjZS4NCj4gPiA+DQo+ID4gPiBJdCBtYXkgdGFrZSB0aGUgc2VydmVyIHNvbWUg dGltZSB0byBkZXRlY3QgdGhlIGV2ZW50IGFmdGVyIGl0IG9jY3Vycy4NCj4gPiA+IEl0IG1heSB0 YWtlIHNvbWUgdGltZSB0byBzYXZlIHRoZSBldmVudCBmb3IgcmVwbGF5IGFuZCB0cmFuc21pc3Np b24uDQo+ID4gPiBXaGljaCBvZiB0aGVzZSAzIGRpZmZlcmVudCB0aW1lcyBpcyBpdD8gKE91dCBv ZiBzY29wZSBJIHRoaW5rKQ0KPiA+ID4NCj4gPiA+IEFkZGluZyBtb3JlIHRpbWVzdGFtcHMgaXMg YW4gaW50ZXJlc3RpbmcgaWRlYS4NCj4gPiA+DQo+ID4gPiBCdXQgSSB0aGluayBzb21ldGhpbmcg bGlrZSB0aGlzIGNvdWxkIGJlIGRvbmUgd2l0aG91dCBhIGNsaWVudCBNVVNULg0KPiA+ID4gVGhl IGNsaWVudCBNQVkgcmVxdWVzdCAnYnVsay1lbmNvZGluZycgYW5kIGlmIHRoZSBzZXJ2ZXIgc3Vw cG9ydHMgDQo+ID4gPiBpdCwgYSBtb3JlIG9wdGltaXplZCBzdHJ1Y3R1cmUgd291bGQgYmUgc2Vu dCBpbnN0ZWFkIG9mIHRoZSBub3JtYWwgbWVzc2FnZS4NCj4gPg0KPiA+IEkgcHJlZmVyIHRoaXMg YXBwcm9hY2gsIHJhdGhlciB0aGFuIHRoZSBleGFtcGxlIGluIHRoZSBvcmlnaW5hbCANCj4gPiBl bWFpbC4gIElmIHRoZSBidWxrLWVuY29kZWQgbm90aWZpY2F0aW9ucyBhcmUgZW5jb2RlZCBpbnRv IGEgbm9ybWFsIA0KPiA+IG5vdGlmaWNhdGlvbiwgd2UgZG9uJ3QgaGF2ZSB0byBjaGFuZ2UgYW55 dGhpbmc6DQo+ID4NCj4gPiAgIDxub3RpZmljYXRpb24NCj4gPiAgICAgICB4bWxucz0idXJuOmll dGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlvbjoxLjAiPg0KPiA+ICAgICA8ZXZl bnRUaW1lPjIwMTctMDEtMDhUMDA6MDE6MDBaPC9ldmVudFRpbWU+DQo+ID4gICAgIDxidWxrLW5v dGlmaWNhdGlvbnMgeG1sbnM9Ii4uLiI+DQo+ID4gICAgICAgPG5vdGlmaWNhdGlvbg0KPiA+ICAg ICAgICAgICB4bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpuZXRjb25mOm5vdGlmaWNhdGlv bjoxLjAiPg0KPiA+ICAgICAgICAgPGV2ZW50VGltZT4yMDE3LTAxLTA4VDAwOjAwOjAwWjwvZXZl bnRUaW1lPg0KPiA+ICAgICAgICAgPGxpbmstdXAgLi4uLz4NCj4gPiAgICAgICA8L25vdGlmaWNh dGlvbj4NCj4gPg0KPiA+ICAgICAgIDxub3RpZmljYXRpb24NCj4gPiAgICAgICAgICAgeG1sbnM9 InVybjppZXRmOnBhcmFtczp4bWw6bnM6bmV0Y29uZjpub3RpZmljYXRpb246MS4wIj4NCj4gPiAg ICAgICAgIDxldmVudFRpbWU+MjAxNy0wMS0wOFQwMDowMDowMVo8L2V2ZW50VGltZT4NCj4gPiAg ICAgICAgIDxsaW5rLWRvd24gLi4uLz4NCj4gPiAgICAgICA8L25vdGlmaWNhdGlvbj4NCj4gPiAg ICAgICAuLi4NCj4gPiAgICA8L25vdGlmaWNhdGlvbj4NCj4gPg0KPiA+DQo+ID4NCj4gSSB3YXMg aG9waW5nIGZvciBhIGJ1bGsgZm9ybWF0IHRoYXQgcmVkdWNlZCB0aGUgcGF5bG9hZC4NCj4gWW91 ciBleGFtcGxlIGFjdHVhbGx5IGluY3JlYXNlcyB0aGUgcGF5bG9hZCBzaXplLg0KDQpGb3IgaWxs dXN0cmF0aW9uIHB1cnBvc2Ugb25seSA7LSkNCg0KSXQncyBwZXJmZWN0bHkgZmluZSB3LyBtZSBp ZiB0aGUgY29udGVudHMgb2YgdGhpcyAiYnVsay1ub3RpZmljYXRpb24iDQpub3RpZiBjb250YWlu cyBhIGNvbXByZXNzZWQgb3IgY2xldmVybHkgZW5jb2RlZCBsaXN0IG9mIG5vdGlmaWNhdGlvbnMu DQoNClRoZSBuaWNlIHRoaW5nIHdpdGggeW91ciBpZGVhIGlzIHRoYXQgaXQgZG9lc24ndCBjaGFu Z2UgdGhlIGNvcmUgcHJvdG9jb2wuDQoNCg0KDQovbWFydGluDQoNCg0KPiBJIHRoaW5rIHRoZSBz dWJzY3JpcHRpb24gbmVlZHMgc29tZSBzb3J0IG9mIGVuY29kaW5nIG5lZ290aWF0aW9uIGxpa2Ug DQo+IHRoZSBBY2NlcHQgaGVhZGVyIGluIEhUVFAuDQo+IFBlb3BsZSB3aWxsIGV2ZW50dWFsbHkg dGhpbmsgb2YgbG90cyBvZiBvcHRpbWl6YXRpb25zIHRoYXQgd2UgbmV2ZXIgDQo+IGltYWdpbmVk LiAgVGhlIHByb3RvY29sIHNob3VsZCBiZSByb2J1c3QgZW5vdWdoIHRvIGFsbG93IHRoaXMgdG8g DQo+IGhhcHBlbi4gIGUuZy4sIHNlbmQgbXVsdGlwbGUgc3Vic2NyaXB0aW9uLWlkIHZhbHVlcyBp bg0KPiAxIG5vdGlmaWNhdGlvbiBpbnN0ZWFkIG9mIGR1cGxpY2F0aW5nIHRoYXQgbm90aWZpY2F0 aW9uIHRvIHRoZSANCj4gcmVjZWl2ZXIgTiB0aW1lcy4NCj4gQW5vdGhlciBvYnZpb3VzIG9wdGlt aXphdGlvbiBpcyB0aGUgYWJpbGl0eSB0byBncm91cCBzaW1pbGFyIGV2ZW50cyANCj4gaW50byBh IHJhbmdlIGxpa2UgbGluay11cCBmb3IgYSBwb3J0LXJhbmdlLCByZXByZXNlbnRpbmcgdGhlIGVu dGlyZSANCj4gbGluZSBjYXJkIHRoYXQgd2FzIGp1c3QgcGx1Z2dlZCBpbi4NCj4gDQo+ICAgPG5v dGlmaWNhdGlvbj4NCj4gICAgICA8aGRyPi4uLi5ubyByZXN0cmljdGlvbnMgb24gd2hhdCBpcyBp biB0aGUgaGVhZGVyIC4uLiA8L2hkcj4NCj4gICAgICA8bGluay1kb3duPiAuLi4gPC9saW5rLWRv d24+ICAgLy8gbGltaXQgdG8gMSBlbGVtZW50IGZvciBwYXlsb2FkPw0KPiAgIDwvbm90aWZpY2F0 aW9uPg0KPiANCj4gQSBzaW1wbGUgbm90aWZpY2F0aW9uIGlzIHRoZSBjYW5vbmljYWwgZm9ybS4N Cj4gQSBub3RpZmljYXRpb24gc3Vic2NyaWJlciBhY3RpbmcgYXMgYSBicm9rZXIgd2lsbCBuZWVk IHRvIGNvbnZlcnQgdGhlIA0KPiBidWxrIGZvcm0gaW50byAxIG9yIG1vcmUgbm90aWZpY2F0aW9u cyBpbiBjYW5vbmljYWwgZm9ybWF0Lg0KPiANCj4gDQo+IA0KPiA+DQo+ID4gL21hcnRpbg0KPiA+ DQo+IA0KPiBBbmR5DQo+IA0KPiANCj4gPg0KPiA+DQo+ID4gPiBUaGUgcmVjZWl2ZXIgTUFZIGV4 dHJhY3QgaW5kaXZpZHVhbCBtZXNzYWdlcyBmcm9tIHRoZSBidWxrIGZvcm1hdCANCj4gPiA+ICht YXliZQ0KPiA+ID4gYmluYXJ5KQ0KPiA+ID4gaW50byBvdGhlciBmb3JtYXRzIChsaWtlIFhNTCBv ciBKU09OKS4NCj4gPiA+DQo+ID4gPiBJIGFtIHRyeWluZyB0byBwbGFuIGFoZWFkIGZvciB3aGVu IFlBTkcgUHVzaCB0dXJucyBvdXQgdG8gYmUgYSANCj4gPiA+IHNsb3cNCj4gPiBuZXR3b3JrDQo+ ID4gPiBob2cgOi0pDQo+ID4gPg0KPiA+ID4NCj4gPiA+IEVyaWMNCj4gPiA+ID4NCj4gPiA+ID4N Cj4gPiA+ICBBbmR5DQo+ID4gPg0KPiA+ID4gPiBFcmljDQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+IEFuZHkNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEZyb206IE5ldGNvbmYgW21haWx0 bzptYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiANCj4gPiA+ID4gPiBCZWhhbGYg T2YNCj4gPiBBbmR5DQo+ID4gPiA+ID4gQmllcm1hbg0KPiA+ID4gPiA+IFNlbnQ6IFRodXJzZGF5 LCBKYW51YXJ5IDUsIDIwMTcgNToyNSBQTQ0KPiA+ID4gPiA+IFRvOiBOZXRjb25mIDxtYWlsdG86 bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiA+ID4gPiBTdWJqZWN0OiBbTmV0Y29uZl0gbmVzdGVkIG5v dGlmaWNhdGlvbnMNCj4gPiA+ID4gPg0KPiA+ID4gPiA+IEhpLA0KPiA+ID4gPiA+DQo+ID4gPiA+ ID4gSSB3b3VsZCBsaWtlIHNvbWUgdGV4dCBpbiBSRkMgNzk1MCB0byBiZSByZWludGVycHJldGVk LiBUaGUgDQo+ID4gPiA+ID4gdGV4dA0KPiA+IGltcGxpZXMNCj4gPiA+ID4gZWFjaA0KPiA+ID4g PiA+IG5vdGlmaWNhdGlvbiBtZXNzYWdlIGNhbiBvbmx5IGRlc2NyaWJlIDEgaW5zdGFuY2Ugb2Yg MSBldmVudCB0eXBlLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gUkZDIDc5NTAsIHNlYyA3LjE2LjIN Cj4gPiA+ID4gPg0KPiA+ID4gPiA+ICAgIFRoZSBpbm5lcm1vc3QgY29udGFpbmVyIG9yIGxpc3Qg Y29udGFpbnMgYW4gWE1MDQo+ID4gPiA+ID4gICAgZWxlbWVudCB0aGF0IGNhcnJpZXMgdGhlIG5h bWUgb2YgdGhlIGRlZmluZWQgbm90aWZpY2F0aW9uLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4g PiA+ID4gPiBUaGVyZSBhcmUgMyBjb3JuZXItY2FzZXMgdGhhdCBzaG91bGQgYmUgY29uc2lkZXJl ZCBpbiBvcmRlciB0byANCj4gPiA+ID4gPiBtaW5pbWl6ZSBuZXR3b3JrIG92ZXJoZWFkIGZvciBu b3RpZmljYXRpb25zIGluIDUyNzdiaXMuDQo+ID4gPiA+ID4gUmVwbGljYXRpbmcgdGhlIG5vZGUv a2V5IGhpZXJhcmNoeSBjb3VsZCBiZSBleHBlbnNpdmUgYW5kIA0KPiA+ID4gPiA+IGV2ZW50cyBv Y2N1cnJpbmcgYXQgdGhlIHNhbWUgdGltZSBjb3VsZCBiZSBjb3JyZWxhdGVkLg0KPiA+ID4gPiA+ DQo+ID4gPiA+ID4gRHVwbGljYXRpbmcgdGhlIG5vdGlmaWNhdGlvbiBtZXNzYWdlcyBpcyBpbmVm ZmljaWVudCwgYnV0IA0KPiA+ID4gPiA+IHByb2Nlc3NpbmcgbXVsdGlwbGUgZXZlbnRzIHBlciBt ZXNzYWdlIG1ha2VzIGZpbHRlcmluZyBhbmQgDQo+ID4gPiA+ID4gcGFyc2luZyBtb3JlIGNvbXBs aWNhdGVkLg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gSSBhbSBjdXJpb3VzIGlmIHRoZSBXRyB0aGlu a3Mgbm90aWZpY2F0aW9uIG92ZXJoZWFkIGlzIGEgDQo+ID4gPiA+ID4gY29uY2VybiBhbmQgaWYg aXQgbmVlZHMgdG8gYmUgYWRkcmVzc2VkIHNvbWVob3cgaW4gNTI3N2Jpcy4NCj4gPiA+ID4gPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4gMSkgbXVsdGlwbGUgbm9uLXNpYmxpbmcgZXZlbnRzIGluIHNh bWUgc3VidHJlZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gICA8bm90aWZpY2F0aW9uPg0KPiA+ID4g PiA+ICAgICA8aW50ZXJmYWNlcz4NCj4gPiA+ID4gPiAgICAgICA8bXktdG9wLWV2ZW50Pg0KPiA+ ID4gPiA+ICAgICAgICAgPG15LWRhdGE+NDI8L215LWRhdGE+DQo+ID4gPiA+ID4gICAgICAgPC9t eS10b3AtZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgPGludGVyZmFjZT4NCj4gPiA+ID4gPiAgICAg ICAgIDxuYW1lPmV0aDA8L25hbWU+DQo+ID4gPiA+ID4gICAgICAgICA8bXktaW50ZXJmYWNlLWV2 ZW50Pg0KPiA+ID4gPiA+ICAgICAgICAgICAgICAgPGlmLWRhdGE+YXV0bzwvaWYtZGF0YT4NCj4g PiA+ID4gPiAgICAgICAgIDwvbXktaW50ZXJmYWNlLWV2ZW50Pg0KPiA+ID4gPiA+ICAgICAgIDwv aW50ZXJmYWNlPg0KPiA+ID4gPiA+ICAgICA8L2ludGVyZmFjZXM+DQo+ID4gPiA+ID4gICA8L25v dGlmaWNhdGlvbj4NCj4gPiA+ID4gPg0KPiA+ID4gPiA+DQo+ID4gPiA+ID4gMikgbXVsdGlwbGUg c2libGluZyBldmVudHMgaW4gdGhlIHNhbWUgc3VidHJlZQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4g ICA8bm90aWZpY2F0aW9uPg0KPiA+ID4gPiA+ICAgICA8aW50ZXJmYWNlcz4NCj4gPiA+ID4gPiAg ICAgICA8aW50ZXJmYWNlPg0KPiA+ID4gPiA+ICAgICAgICAgPG5hbWU+ZXRoMDwvbmFtZT4NCj4g PiA+ID4gPiAgICAgICAgIDxteS1pbnRlcmZhY2UtZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgICAg ICAgICA8aWYtZGF0YT5hdXRvPC9pZi1kYXRhPg0KPiA+ID4gPiA+ICAgICAgICAgPC9teS1pbnRl cmZhY2UtZXZlbnQ+DQo+ID4gPiA+ID4gICAgICAgICA8aW50ZXJmYWNlLWVuYWJsZWQ+DQo+ID4g PiA+ID4gICAgICAgICAgICA8YnktdXNlcj5hZG1pbjwvYnktdXNlcj4NCj4gPiA+ID4gPiAgICAg ICAgIDwvaW50ZXJmYWNlLWVuYWJsZWQ+DQo+ID4gPiA+ID4gICAgICAgPC9pbnRlcmZhY2U+DQo+ ID4gPiA+ID4gICAgIDwvaW50ZXJmYWNlcz4NCj4gPiA+ID4gPiAgIDwvbm90aWZpY2F0aW9uPg0K PiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAzKSBtdWx0aXBsZSBub24tc2libGluZyBl dmVudHMgaW4gZGlmZmVyZW50IHN1YnRyZWVzDQo+ID4gPiA+ID4NCj4gPiA+ID4gPiAgIDxub3Rp ZmljYXRpb24+DQo+ID4gPiA+ID4gICAgIDxzeXN0ZW0+DQo+ID4gPiA+ID4gICAgICAgPG15LXN5 c3RlbS1ldmVudD4NCj4gPiA+ID4gPiAgICAgICAgICAgICA8bXktZGF0YT40MjwvbXktZGF0YT4N Cj4gPiA+ID4gPiAgICAgICA8L215LXN5c3RlbS1ldmVudD4NCj4gPiA+ID4gPiAgICAgPC9zeXN0 ZW0+DQo+ID4gPiA+ID4gICAgIDxpbnRlcmZhY2VzPg0KPiA+ID4gPiA+ICAgICAgIDxpbnRlcmZh Y2U+DQo+ID4gPiA+ID4gICAgICAgICA8bmFtZT5ldGgwPC9uYW1lPg0KPiA+ID4gPiA+ICAgICAg ICAgPG15LWludGVyZmFjZS1ldmVudD4NCj4gPiA+ID4gPiAgICAgICAgICAgICAgIDxpZi1kYXRh PmF1dG88L2lmLWRhdGE+DQo+ID4gPiA+ID4gICAgICAgICA8L215LWludGVyZmFjZS1ldmVudD4N Cj4gPiA+ID4gPiAgICAgICA8L2ludGVyZmFjZT4NCj4gPiA+ID4gPiAgICAgPC9pbnRlcmZhY2Vz Pg0KPiA+ID4gPiA+ICAgPC9ub3RpZmljYXRpb24+DQo+ID4gPiA+ID4NCj4gPiA+ID4gPg0KPiA+ ID4gPiA+DQo+ID4gPiA+ID4gQW5keQ0KPiA+ID4gPiA+DQo+ID4gPiA+ID4NCj4gPiA+ID4NCj4g PiA+ID4NCj4gPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg== From nobody Thu Jan 12 13:45:49 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A933812944B for ; Thu, 12 Jan 2017 13:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 j9tVWypUEbjA for ; Thu, 12 Jan 2017 13:45:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 72B241289C4 for ; Thu, 12 Jan 2017 13:45:45 -0800 (PST) Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 6E80C1AE01AA; Thu, 12 Jan 2017 22:45:44 +0100 (CET) To: Alexander Clemm References: <20170112.135947.218954166063566738.mbj@tail-f.com> <20170112.193029.9249587815129986.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> From: Per Hedeland Message-ID: <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> Date: Thu, 12 Jan 2017 22:45:43 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:45:47 -0000 On 2017-01-12 22:34, Alexander Clemm wrote: > I agree that it makes sense to allow multiple notifications to be sent in one message. > > We need to allow for different time stamps, allowing to stamp individual notifications separately. Clearly, compression schemes can be devised, including a trivial compression scheme to apply one "bulk" timestamp for every notification in the message. > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, specifically it is not clear what is really mandated as part of the encoding. The RFC states merely that the notification is encoded as _a_ child XML element to the element. The specification/definition of the element itself is however not part of RFC 7950, neither is the definition of the time stamp (event-time). It seems that all that is specified is the encoding of the event itself, i.e. the representation of the notification identifier and then the parameters contained within it. It seems that you are reading only the first paragraph of 7.16.2, the one that starts with "A notification node that is defined on the top level of a module...". Try the second one.:-) --Per > Does RFC 7950 imply that notification nodes can only be encoded as contained in a element as defined in RFC 5277? That would be a considerable limitation and issue at least in the context of Netconf. I guess one could always define other encoding rules outside of Netconf. I don't think defining a bulk notification as a special notification, that itself needs to be carried in a regular notification, is a good solution. The notification element is pure overhead at this point. Allowing the definition of a new bulk notification element, which can be used in lieu of a notification element, would seem a lot more desirable. > > --- Alex > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund > Sent: Thursday, January 12, 2017 10:30 AM > To: andy@yumaworks.com > Cc: netconf@ietf.org > Subject: Re: [Netconf] nested notifications > > Andy Bierman wrote: >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund wrote: >> >>> Andy Bierman wrote: >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) >>>> >>> wrote: >>>> >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM >>>>>> >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) >>>> evoit@cisco.com> >>>>>> wrote: >>>>>> Hi Andy, >>>>>> >>>>>> The innermost container or list text is similar to that for >>> actions in >>>>> section >>>>>> 7.15.2. Perhaps the mental model of one target for an action was >>>>> replicated? >>>>>> >>>>>> I had not considered that YANG 1.1s definition might force >>>>>> the >>> breakup >>>>> of a >>>>>> verbose software component generated notification into >>>>>> multiple >>> pushed >>>>>> notification messages. Looking at the three cases below, I >>>>>> dont >>> think >>>>> that >>>>>> arbitrary choices made in YANG model structure should impact >>>>>> what >>> could >>>>> or >>>>>> couldnt be in encoded within any single notification. So my >>> preference >>>>> would >>>>>> be that all three variants below should supportable if that is >>>>>> how >>> the >>>>> system >>>>>> passed them to be encoded as part of an event. >>>>>> >>>>>> >>>>>> >>>>>> I think the WG did not consider these details and assumed they >>>>>> were >>> the >>>>> same >>>>>> as for action. >>>>>> >>>>>> This would be a MAY for the server and a MUST for the client, >>>>>> so it >>> is >>>>> not >>>>>> an easy decision. >>>>>> >>>>>> A couple use-cases I have in mind: >>>>>> >>>>>> 1) event broker >>>>>> subscriber is really a broker that may be pre-processing >>>>>> lots >>> of >>>>>> subscriptions or event types within 1 subscription >>>>>> >>>>>> 2) digest (time-based push) >>>>>> Subscriber wants an update every 5 seconds with all the >>>>>> YANG 1.1 >>>>> events >>>>>> for the previous 5 seconds >>>>> >>>>> These are both reasonable as controllers are requiring scalable >>> methods of >>>>> synching on device status. >>>>> >>>>>> What if the reinterpretation were as simple as An innermost >>>>>> or The >>>>> first >>>>>> innermost? >>>>>> >>>>>> This covers case 2. (Change "The" to "An"). >>>>>> The client would need to check for YANG 1.1 notifications in >>>>>> the same way it checks child nodes already. >>>>> >>>>> "Any innermost"...? And yes, this is a more significant change on the >>>>> client. Beyond this, for use cases (1) & (2), if you don't want >>>>> to summarize the eventTime, the time should be placed with each >>>>> innermost event. I am not suggesting we do this, but like Andy >>>>> I want to figure >>> out >>>>> what the WG might be willing to consider in scope. >>>>> >>>>> >>>> >>>> There was actually a lot of discussion about "eventTime" in the >>>> NETCONF >>> WG >>>> when RFC 5277 was done. >>>> Lots of disagreement on what it means. The RFC offers little >>>> guidance or hint of the discussion: >>>> >>>> >>>> eventTime: >>>> The time the event was generated by the event source. >>>> >>>> It may take the server some time to detect the event after it occurs. >>>> It may take some time to save the event for replay and transmission. >>>> Which of these 3 different times is it? (Out of scope I think) >>>> >>>> Adding more timestamps is an interesting idea. >>>> >>>> But I think something like this could be done without a client MUST. >>>> The client MAY request 'bulk-encoding' and if the server supports >>>> it, a more optimized structure would be sent instead of the normal message. >>> >>> I prefer this approach, rather than the example in the original >>> email. If the bulk-encoded notifications are encoded into a normal >>> notification, we don't have to change anything: >>> >>> >> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> >>> 2017-01-08T00:01:00Z >>> >>> >> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> >>> 2017-01-08T00:00:00Z >>> >>> >>> >>> >> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> >>> 2017-01-08T00:00:01Z >>> >>> >>> ... >>> >>> >>> >>> >> I was hoping for a bulk format that reduced the payload. >> Your example actually increases the payload size. > > For illustration purpose only ;-) > > It's perfectly fine w/ me if the contents of this "bulk-notification" > notif contains a compressed or cleverly encoded list of notifications. > > The nice thing with your idea is that it doesn't change the core protocol. > > > > /martin > > >> I think the subscription needs some sort of encoding negotiation like >> the Accept header in HTTP. >> People will eventually think of lots of optimizations that we never >> imagined. The protocol should be robust enough to allow this to >> happen. e.g., send multiple subscription-id values in >> 1 notification instead of duplicating that notification to the >> receiver N times. >> Another obvious optimization is the ability to group similar events >> into a range like link-up for a port-range, representing the entire >> line card that was just plugged in. >> >> >> ....no restrictions on what is in the header ... >> ... // limit to 1 element for payload? >> >> >> A simple notification is the canonical form. >> A notification subscriber acting as a broker will need to convert the >> bulk form into 1 or more notifications in canonical format. >> >> >> >>> >>> /martin >>> >> >> Andy >> >> >>> >>> >>>> The receiver MAY extract individual messages from the bulk format >>>> (maybe >>>> binary) >>>> into other formats (like XML or JSON). >>>> >>>> I am trying to plan ahead for when YANG Push turns out to be a >>>> slow >>> network >>>> hog :-) >>>> >>>> >>>> Eric >>>>> >>>>> >>>> Andy >>>> >>>>> Eric >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On >>>>>> Behalf Of >>> Andy >>>>>> Bierman >>>>>> Sent: Thursday, January 5, 2017 5:25 PM >>>>>> To: Netconf >>>>>> Subject: [Netconf] nested notifications >>>>>> >>>>>> Hi, >>>>>> >>>>>> I would like some text in RFC 7950 to be reinterpreted. The >>>>>> text >>> implies >>>>> each >>>>>> notification message can only describe 1 instance of 1 event type. >>>>>> >>>>>> RFC 7950, sec 7.16.2 >>>>>> >>>>>> The innermost container or list contains an XML >>>>>> element that carries the name of the defined notification. >>>>>> >>>>>> >>>>>> There are 3 corner-cases that should be considered in order to >>>>>> minimize network overhead for notifications in 5277bis. >>>>>> Replicating the node/key hierarchy could be expensive and >>>>>> events occurring at the same time could be correlated. >>>>>> >>>>>> Duplicating the notification messages is inefficient, but >>>>>> processing multiple events per message makes filtering and >>>>>> parsing more complicated. >>>>>> >>>>>> I am curious if the WG thinks notification overhead is a >>>>>> concern and if it needs to be addressed somehow in 5277bis. >>>>>> >>>>>> >>>>>> 1) multiple non-sibling events in same subtree >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 42 >>>>>> >>>>>> >>>>>> eth0 >>>>>> >>>>>> auto >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 2) multiple sibling events in the same subtree >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> eth0 >>>>>> >>>>>> auto >>>>>> >>>>>> >>>>>> admin >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 3) multiple non-sibling events in different subtrees >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> 42 >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> eth0 >>>>>> >>>>>> auto >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> Andy >>>>>> >>>>>> >>>>> >>>>> >>> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > From nobody Thu Jan 12 13:55:40 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 04CEF124281 for ; Thu, 12 Jan 2017 13:55:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 Yx-nccV4dEjj for ; Thu, 12 Jan 2017 13:55:37 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D32B3129443 for ; Thu, 12 Jan 2017 13:55:36 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 1A74B1AE01AA; Thu, 12 Jan 2017 22:55:36 +0100 (CET) Date: Thu, 12 Jan 2017 22:55:35 +0100 (CET) Message-Id: <20170112.225535.699844646707934283.mbj@tail-f.com> To: per@tail-f.com From: Martin Bjorklund In-Reply-To: <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> References: <20170112.193029.9249587815129986.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:55:39 -0000 Per Hedeland wrote: > On 2017-01-12 22:34, Alexander Clemm wrote: > > I agree that it makes sense to allow multiple notifications to be sent in one message. > > > > We need to allow for different time stamps, allowing to stamp individual notifications separately. Clearly, compression schemes can be devised, including a trivial compression scheme to apply one "bulk" timestamp for every notification in the message. > > > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, specifically it is not clear what is really mandated as part of the encoding. The RFC states merely that the notification is encoded as _a_ child XML element to the element. The specification/definition of the element itself is however not part of RFC 7950, neither is the definition of the time stamp (event-time). It seems that all that is specified is the encoding of the event itself, i.e. the representation of the notification identifier and then the parameters contained within it. > > It seems that you are reading only the first paragraph of 7.16.2, the > one that starts with "A notification node that is defined on the top > level of a module...". Try the second one.:-) And also check the XSD in RFC 5277; it allows exactly one child element for the notification content. > > Does RFC 7950 imply that notification nodes can only be encoded as contained in a element as defined in RFC 5277? That would be a considerable limitation and issue at least in the context of Netconf. I guess one could always define other encoding rules outside of Netconf. I don't think defining a bulk notification as a special notification, that itself needs to be carried in a regular notification, is a good solution. The notification element is pure overhead at this point. Allowing the definition of a new bulk notification element, which can be used in lieu of a notification element, would seem a lot more desirable. Even in the bulk case you probably want the eventTime for each individual notification, and if we add more header fields some might be notification specific. The overhead of the top-level element 'notification' is minimal in this case. And for the header fields that apply to all notifications within the bulk, they can nicely be handled if the bulk thingie is a notification. /martin > > > > --- Alex > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund > > Sent: Thursday, January 12, 2017 10:30 AM > > To: andy@yumaworks.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] nested notifications > > > > Andy Bierman wrote: > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund wrote: > >> > >>> Andy Bierman wrote: > >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) > >>>> > >>> wrote: > >>>> > >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM > >>>>>> > >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) >>>>> evoit@cisco.com> > >>>>>> wrote: > >>>>>> Hi Andy, > >>>>>> > >>>>>> The innermost container or list text is similar to that for > >>> actions in > >>>>> section > >>>>>> 7.15.2. Perhaps the mental model of one target for an action was > >>>>> replicated? > >>>>>> > >>>>>> I had not considered that YANG 1.1s definition might force > >>>>>> the > >>> breakup > >>>>> of a > >>>>>> verbose software component generated notification into > >>>>>> multiple > >>> pushed > >>>>>> notification messages. Looking at the three cases below, I > >>>>>> dont > >>> think > >>>>> that > >>>>>> arbitrary choices made in YANG model structure should impact > >>>>>> what > >>> could > >>>>> or > >>>>>> couldnt be in encoded within any single notification. So my > >>> preference > >>>>> would > >>>>>> be that all three variants below should supportable if that is > >>>>>> how > >>> the > >>>>> system > >>>>>> passed them to be encoded as part of an event. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think the WG did not consider these details and assumed they > >>>>>> were > >>> the > >>>>> same > >>>>>> as for action. > >>>>>> > >>>>>> This would be a MAY for the server and a MUST for the client, > >>>>>> so it > >>> is > >>>>> not > >>>>>> an easy decision. > >>>>>> > >>>>>> A couple use-cases I have in mind: > >>>>>> > >>>>>> 1) event broker > >>>>>> subscriber is really a broker that may be pre-processing > >>>>>> lots > >>> of > >>>>>> subscriptions or event types within 1 subscription > >>>>>> > >>>>>> 2) digest (time-based push) > >>>>>> Subscriber wants an update every 5 seconds with all the > >>>>>> YANG 1.1 > >>>>> events > >>>>>> for the previous 5 seconds > >>>>> > >>>>> These are both reasonable as controllers are requiring scalable > >>> methods of > >>>>> synching on device status. > >>>>> > >>>>>> What if the reinterpretation were as simple as An innermost > >>>>>> or The > >>>>> first > >>>>>> innermost? > >>>>>> > >>>>>> This covers case 2. (Change "The" to "An"). > >>>>>> The client would need to check for YANG 1.1 notifications in > >>>>>> the same way it checks child nodes already. > >>>>> > >>>>> "Any innermost"...? And yes, this is a more significant change on the > >>>>> client. Beyond this, for use cases (1) & (2), if you don't want > >>>>> to summarize the eventTime, the time should be placed with each > >>>>> innermost event. I am not suggesting we do this, but like Andy > >>>>> I want to figure > >>> out > >>>>> what the WG might be willing to consider in scope. > >>>>> > >>>>> > >>>> > >>>> There was actually a lot of discussion about "eventTime" in the > >>>> NETCONF > >>> WG > >>>> when RFC 5277 was done. > >>>> Lots of disagreement on what it means. The RFC offers little > >>>> guidance or hint of the discussion: > >>>> > >>>> > >>>> eventTime: > >>>> The time the event was generated by the event source. > >>>> > >>>> It may take the server some time to detect the event after it occurs. > >>>> It may take some time to save the event for replay and transmission. > >>>> Which of these 3 different times is it? (Out of scope I think) > >>>> > >>>> Adding more timestamps is an interesting idea. > >>>> > >>>> But I think something like this could be done without a client MUST. > >>>> The client MAY request 'bulk-encoding' and if the server supports > >>>> it, a more optimized structure would be sent instead of the normal message. > >>> > >>> I prefer this approach, rather than the example in the original > >>> email. If the bulk-encoded notifications are encoded into a normal > >>> notification, we don't have to change anything: > >>> > >>> >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:01:00Z > >>> > >>> >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:00:00Z > >>> > >>> > >>> > >>> >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:00:01Z > >>> > >>> > >>> ... > >>> > >>> > >>> > >>> > >> I was hoping for a bulk format that reduced the payload. > >> Your example actually increases the payload size. > > > > For illustration purpose only ;-) > > > > It's perfectly fine w/ me if the contents of this "bulk-notification" > > notif contains a compressed or cleverly encoded list of notifications. > > > > The nice thing with your idea is that it doesn't change the core protocol. > > > > > > > > /martin > > > > > >> I think the subscription needs some sort of encoding negotiation like > >> the Accept header in HTTP. > >> People will eventually think of lots of optimizations that we never > >> imagined. The protocol should be robust enough to allow this to > >> happen. e.g., send multiple subscription-id values in > >> 1 notification instead of duplicating that notification to the > >> receiver N times. > >> Another obvious optimization is the ability to group similar events > >> into a range like link-up for a port-range, representing the entire > >> line card that was just plugged in. > >> > >> > >> ....no restrictions on what is in the header ... > >> ... // limit to 1 element for payload? > >> > >> > >> A simple notification is the canonical form. > >> A notification subscriber acting as a broker will need to convert the > >> bulk form into 1 or more notifications in canonical format. > >> > >> > >> > >>> > >>> /martin > >>> > >> > >> Andy > >> > >> > >>> > >>> > >>>> The receiver MAY extract individual messages from the bulk format > >>>> (maybe > >>>> binary) > >>>> into other formats (like XML or JSON). > >>>> > >>>> I am trying to plan ahead for when YANG Push turns out to be a > >>>> slow > >>> network > >>>> hog :-) > >>>> > >>>> > >>>> Eric > >>>>> > >>>>> > >>>> Andy > >>>> > >>>>> Eric > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On > >>>>>> Behalf Of > >>> Andy > >>>>>> Bierman > >>>>>> Sent: Thursday, January 5, 2017 5:25 PM > >>>>>> To: Netconf > >>>>>> Subject: [Netconf] nested notifications > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I would like some text in RFC 7950 to be reinterpreted. The > >>>>>> text > >>> implies > >>>>> each > >>>>>> notification message can only describe 1 instance of 1 event type. > >>>>>> > >>>>>> RFC 7950, sec 7.16.2 > >>>>>> > >>>>>> The innermost container or list contains an XML > >>>>>> element that carries the name of the defined notification. > >>>>>> > >>>>>> > >>>>>> There are 3 corner-cases that should be considered in order to > >>>>>> minimize network overhead for notifications in 5277bis. > >>>>>> Replicating the node/key hierarchy could be expensive and > >>>>>> events occurring at the same time could be correlated. > >>>>>> > >>>>>> Duplicating the notification messages is inefficient, but > >>>>>> processing multiple events per message makes filtering and > >>>>>> parsing more complicated. > >>>>>> > >>>>>> I am curious if the WG thinks notification overhead is a > >>>>>> concern and if it needs to be addressed somehow in 5277bis. > >>>>>> > >>>>>> > >>>>>> 1) multiple non-sibling events in same subtree > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 42 > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2) multiple sibling events in the same subtree > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> admin > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 3) multiple non-sibling events in different subtrees > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 42 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>> > >>>>> > >>> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > > From nobody Thu Jan 12 13:59:44 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79B9E129459; Thu, 12 Jan 2017 13:59:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 zivpO4lEUrq3; Thu, 12 Jan 2017 13:59:38 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6A1124281; Thu, 12 Jan 2017 13:59:38 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 465CD1AE01AA; Thu, 12 Jan 2017 22:59:37 +0100 (CET) Date: Thu, 12 Jan 2017 22:59:37 +0100 (CET) Message-Id: <20170112.225937.1113385078732083121.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org, netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 21:59:39 -0000 Ladislav Lhotka wrote: > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > wrote: > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > >> j.schoenwaelder@jacobs-university.de> wrote: > >> > >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > >>>> > >>>> YANG statements: > >>>> - It is not possible to define these statements so they are different > >>>> for config and oper > >>>> - must > >>>> - when > >>>> - unique > >>>> - key > >>>> - min-elements > >>>> - max-elements > >>>> - leafref (path) > >>>> - if-feature > >>>> - deviation > >>>> - type (or any sub-statements of type-stmt) > >>>> - status > >>>> - description > >>>> - reference > >>> > >>> Considering statements that constraint 'values', it is not entirely > >>> clear to me what they mean for state nodes. If a server has > >>> operational state that violates a must or range or ... constraint in > >>> the YANG model, what is the server expected to do? > >>> > >> > >> The client uses the YANG validation to check on what the server is > >> sending. > >> The server is buggy if it is sending data that violates YANG > >> constraints. > >> If any of these statements need to be different for config and oper > >> then the old style YANG has to be used instead. > >> > > > > OK. So the client does the validation. What does the client do if the > > operational state it got is not valid according to the YANG > > constraints? > > Don't forget that data models also provide guidelines to server > implementors. Yes, and that it is all that can be done currently. I don't think any implemention that receives a request today freezes the system in order to get a guaranteed consistent snapshot. Instead, the different subsystems will be queried, sequentially or in parallell, and the end result is shipped to the client. The result may or may not be consistent. /martin From nobody Thu Jan 12 14:05:13 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C6121294F6 for ; Thu, 12 Jan 2017 14:05:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2-QiTZOwm4lB for ; Thu, 12 Jan 2017 14:05:10 -0800 (PST) Received: from mail-qt0-x233.google.com (mail-qt0-x233.google.com [IPv6:2607:f8b0:400d:c0d::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29744129459 for ; Thu, 12 Jan 2017 14:05:10 -0800 (PST) Received: by mail-qt0-x233.google.com with SMTP id l7so31681937qtd.1 for ; Thu, 12 Jan 2017 14:05:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GQt0Br9O5s2Hgpsy6ejma+NURrF292MKAMA0GqgCcvU=; b=J5eRustOnKjAzKmw5BK31jFJRKrMPQXjtLCXI+rny24aL7/xsTOKKT9zk8bSz4uHrJ ACB/YdtRkiAtvNJRJr+K9k2nL1KpLBMhc3BYAKhOl5fE8nMersOAu5GfMER6NDq9DsHW VuzarEZkjXUodhRjy8IAVN1phfnmKGWnW5MS51r0dUgd4TbXy9s7pYRyrN8ntX0dwbnw W54qfbF/lzLgaGbfVVJ/8UB/HBWKF1wbEeRBvRu1Qi/LjNmXUSJgCjrfaLwEuSY00beu 6kR9lK2Thvv57+uKWFsOt+S9V37uFc6U2ze/rjOJT6qpQgi1ujRcK/VhYHQSF7UiMLLe Qvgg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=GQt0Br9O5s2Hgpsy6ejma+NURrF292MKAMA0GqgCcvU=; b=WJN7pgUNUQv5em6KbYcmrjehUC8zabvZSfpfjRcyagcwxXkqEBZBquAdZafSwGw1s7 38HBJNzkalo426FqUvav/8NxueYMhiZuPYHEES1KruPtmtUTJ4IsqsKG9R0a5BOJbNL3 XnAnsYJ0hxhlOi2xmlDFjKTnAxsPCkZOWqWNlhf51LfHGcBG0qRWD4SO+QAXnKyTTVDp yYseB6Hq1lbcjSCKLK2hXpumGnr9Ej4Y18/7+OTaUOqWSyYuSVtTNnz4AUGxMdCedFmx 8PunPv9WiBpvCFNwI+jIOzb7IgjMTVWNglEpuRoSn0LosFxcmtQcF6Yd0gABHXwKBW6e yvGg== X-Gm-Message-State: AIkVDXKWjMOhTpy4NTjccQZNfydYUSrRd8/Ctg8c8glComhj2AfiR6/7AoilNgsWAvRiOOD5CTxrAQMlsr+kJQ== X-Received: by 10.200.57.75 with SMTP id t11mr15774796qtb.274.1484258709155; Thu, 12 Jan 2017 14:05:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 12 Jan 2017 14:05:07 -0800 (PST) In-Reply-To: <20170112.225937.1113385078732083121.mbj@tail-f.com> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> From: Andy Bierman Date: Thu, 12 Jan 2017 14:05:07 -0800 Message-ID: To: Martin Bjorklund Content-Type: multipart/alternative; boundary=001a113ef3581d63a90545ece92d Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:05:12 -0000 --001a113ef3581d63a90545ece92d Content-Type: text/plain; charset=UTF-8 On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund wrote: > Ladislav Lhotka wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > >>>> > > >>>> YANG statements: > > >>>> - It is not possible to define these statements so they are > different > > >>>> for config and oper > > >>>> - must > > >>>> - when > > >>>> - unique > > >>>> - key > > >>>> - min-elements > > >>>> - max-elements > > >>>> - leafref (path) > > >>>> - if-feature > > >>>> - deviation > > >>>> - type (or any sub-statements of type-stmt) > > >>>> - status > > >>>> - description > > >>>> - reference > > >>> > > >>> Considering statements that constraint 'values', it is not entirely > > >>> clear to me what they mean for state nodes. If a server has > > >>> operational state that violates a must or range or ... constraint in > > >>> the YANG model, what is the server expected to do? > > >>> > > >> > > >> The client uses the YANG validation to check on what the server is > > >> sending. > > >> The server is buggy if it is sending data that violates YANG > > >> constraints. > > >> If any of these statements need to be different for config and oper > > >> then the old style YANG has to be used instead. > > >> > > > > > > OK. So the client does the validation. What does the client do if the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. > > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. > > > So this thread is questioning why YANG allows constraints on config=false data nodes. >From the generic toolbuilder POV, it allows the YANG engine to report issues to the operator without custom programming for each little issue. Who knows why the foo-table requires 3 entries to be valid min-elements 3). The tool can report to the operator "foo-table does not have enough entries" and let the operator decide what to do about it. /martin > > Andy > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --001a113ef3581d63a90545ece92d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:
>
> > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder
> > <j.sch= oenwaelder@jacobs-university.de> wrote:
> >
> > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote:
> >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > >> j.sch= oenwaelder@jacobs-university.de> wrote:
> >>
> >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wr= ote:
> >>>>
> >>>> YANG statements:
> >>>>=C2=A0 =C2=A0- It is not possible to define these stat= ements so they are different
> >>>> for config and oper
> >>>>=C2=A0 =C2=A0 =C2=A0 - must
> >>>>=C2=A0 =C2=A0 =C2=A0 - when
> >>>>=C2=A0 =C2=A0 =C2=A0 - unique
> >>>>=C2=A0 =C2=A0 =C2=A0 - key
> >>>>=C2=A0 =C2=A0 =C2=A0 - min-elements
> >>>>=C2=A0 =C2=A0 =C2=A0 - max-elements
> >>>>=C2=A0 =C2=A0 =C2=A0 - leafref (path)
> >>>>=C2=A0 =C2=A0 =C2=A0 - if-feature
> >>>>=C2=A0 =C2=A0 =C2=A0 - deviation
> >>>>=C2=A0 =C2=A0 =C2=A0 - type (or any sub-statements of = type-stmt)
> >>>>=C2=A0 =C2=A0 =C2=A0 - status
> >>>>=C2=A0 =C2=A0 =C2=A0 - description
> >>>>=C2=A0 =C2=A0 =C2=A0 - reference
> >>>
> >>> Considering statements that constraint 'values', = it is not entirely
> >>> clear to me what they mean for state nodes. If a server h= as
> >>> operational state that violates a must or range or ... co= nstraint in
> >>> the YANG model, what is the server expected to do?
> >>>
> >>
> >> The client uses the YANG validation to check on what the serv= er is
> >> sending.
> >> The server is buggy if it is sending data that violates YANG<= br> > >> constraints.
> >> If any of these statements need to be different for config an= d oper
> >> then the old style YANG has to be used instead.
> >>
> >
> > OK. So the client does the validation. What does the client do if= the
> > operational state it got is not valid according to the YANG
> > constraints?
>
> Don't forget that data models also provide guidelines to server > implementors.

Yes, and that it is all that can be done currently.=C2=A0 I don't think= any
implemention that receives a <get> request today freezes the system i= n
order to get a guaranteed consistent snapshot.=C2=A0 Instead, the different=
subsystems will be queried, sequentially or in parallell, and the end
result is shipped to the client.=C2=A0 The result may or may not be
consistent.



So this thread is questioning why YANG= allows constraints on config=3Dfalse data nodes.
From the generi= c toolbuilder POV, it allows the YANG engine to report issues to
= the operator without custom programming for each little issue.=C2=A0 Who kn= ows why the
foo-table requires 3 entries to be valid min-elements= 3).
The tool can report to the operator "foo-table does not= have enough entries"
and let the operator decide what to do= about it.


=C2=A0
/martin


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

--001a113ef3581d63a90545ece92d-- From nobody Thu Jan 12 14:32:02 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3CDB129546 for ; Thu, 12 Jan 2017 14:32:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 nKNPEVuggBeN for ; Thu, 12 Jan 2017 14:31:58 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 057AC129536 for ; Thu, 12 Jan 2017 14:31:56 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml701-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DEI22395; Thu, 12 Jan 2017 22:31:54 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml701-cah.china.huawei.com (10.201.5.93) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 12 Jan 2017 22:31:53 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Thu, 12 Jan 2017 14:31:51 -0800 From: Alexander Clemm To: Martin Bjorklund , "per@tail-f.com" Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KSFQsAF1aiAU+PjrHFwgk9UKEqeKNAgACZJoCAAIaW4IAAADDwgAFZcoCACGxXgIAATXWAgAAO8ID//5YBgIAAoIuAgAACwoD//3rocA== Date: Thu, 12 Jan 2017 22:31:50 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> References: <20170112.193029.9249587815129986.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> <20170112.225535.699844646707934283.mbj@tail-f.com> In-Reply-To: <20170112.225535.699844646707934283.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.47] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090205.587803DA.012A, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 79ee8a344065a33670fc5b50d59c19e7 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:32:01 -0000 Understood, 5277 allows exactly one child element for the notification elem= ent. =20 My question is about 7950. Does 7950 mandate that notification nodes MUST = be used/encoded per 5277 - does 5277 by extension become part of 7950? Or = does it merely specify what goes below (the notification element element in= the case of 5277, and perhaps a bulk element or something else in case a 5= 277 alternative becomes available? I guess from your responses it's the fo= rmer (which I find somewhat limiting - but I guess we are free to define ot= her encodings for other contexts beyond Netconf XML...). =20 --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, January 12, 2017 1:56 PM To: per@tail-f.com Cc: Alexander Clemm ; netconf@ietf.org Subject: Re: [Netconf] nested notifications Per Hedeland wrote: > On 2017-01-12 22:34, Alexander Clemm wrote: > > I agree that it makes sense to allow multiple notifications to be sent = in one message. =20 > >=20 > > We need to allow for different time stamps, allowing to stamp individua= l notifications separately. Clearly, compression schemes can be devised, i= ncluding a trivial compression scheme to apply one "bulk" timestamp for eve= ry notification in the message. =20 > >=20 > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, spec= ifically it is not clear what is really mandated as part of the encoding. = The RFC states merely that the notification is encoded as _a_ child XML ele= ment to the element. The specification/definition of the element itself is however not part of RFC 7950, neither is the= definition of the time stamp (event-time). It seems that all that is spec= ified is the encoding of the event itself, i.e. the representation of the n= otification identifier and then the parameters contained within it.=20 >=20 > It seems that you are reading only the first paragraph of 7.16.2, the=20 > one that starts with "A notification node that is defined on the top=20 > level of a module...". Try the second one.:-) And also check the XSD in RFC 5277; it allows exactly one child element for= the notification content. > > Does RFC 7950 imply that notification nodes can only be encoded as cont= ained in a element as defined in RFC 5277? That would be a = considerable limitation and issue at least in the context of Netconf. I gu= ess one could always define other encoding rules outside of Netconf. I don= 't think defining a bulk notification as a special notification, that itsel= f needs to be carried in a regular notification, is a good solution. The n= otification element is pure overhead at this point. Allowing the definitio= n of a new bulk notification element, which can be used in lieu of a notifi= cation element, would seem a lot more desirable. =20 Even in the bulk case you probably want the eventTime for each individual n= otification, and if we add more header fields some might be notification sp= ecific. The overhead of the top-level element 'notification' is minimal in= this case. And for the header fields that apply to all notifications with= in the bulk, they can nicely be handled if the bulk thingie is a notificati= on. /martin > >=20 > > --- Alex > >=20 > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin=20 > > Bjorklund > > Sent: Thursday, January 12, 2017 10:30 AM > > To: andy@yumaworks.com > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] nested notifications > >=20 > > Andy Bierman wrote: > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund wro= te: > >> > >>> Andy Bierman wrote: > >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit)=20 > >>>> > >>> wrote: > >>>> > >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM > >>>>>> > >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) >>>>> evoit@cisco.com> > >>>>>> wrote: > >>>>>> Hi Andy, > >>>>>> > >>>>>> =1CThe innermost container or list=1D text is similar to that for > >>> actions in > >>>>> section > >>>>>> 7.15.2. Perhaps the mental model of one target for an action was > >>>>> replicated? > >>>>>> > >>>>>> I had not considered that YANG 1.1=19s definition might force the > >>> breakup > >>>>> of a > >>>>>> verbose software component generated notification into multiple > >>> pushed > >>>>>> notification messages. Looking at the three cases below, I=20 > >>>>>> don=19t > >>> think > >>>>> that > >>>>>> arbitrary choices made in YANG model structure should impact=20 > >>>>>> what > >>> could > >>>>> or > >>>>>> couldn=19t be in encoded within any single notification. So my > >>> preference > >>>>> would > >>>>>> be that all three variants below should supportable if that is=20 > >>>>>> how > >>> the > >>>>> system > >>>>>> passed them to be encoded as part of an event. > >>>>>> > >>>>>> > >>>>>> > >>>>>> I think the WG did not consider these details and assumed they=20 > >>>>>> were > >>> the > >>>>> same > >>>>>> as for action. > >>>>>> > >>>>>> This would be a MAY for the server and a MUST for the client,=20 > >>>>>> so it > >>> is > >>>>> not > >>>>>> an easy decision. > >>>>>> > >>>>>> A couple use-cases I have in mind: > >>>>>> > >>>>>> 1) event broker > >>>>>> subscriber is really a broker that may be pre-processing=20 > >>>>>> lots > >>> of > >>>>>> subscriptions or event types within 1 subscription > >>>>>> > >>>>>> 2) digest (time-based push) > >>>>>> Subscriber wants an update every 5 seconds with all the=20 > >>>>>> YANG 1.1 > >>>>> events > >>>>>> for the previous 5 seconds > >>>>> > >>>>> These are both reasonable as controllers are requiring scalable > >>> methods of > >>>>> synching on device status. > >>>>> > >>>>>> What if the reinterpretation were as simple as =1CAn innermost=1D= =20 > >>>>>> or =1CThe > >>>>> first > >>>>>> innermost=1D? > >>>>>> > >>>>>> This covers case 2. (Change "The" to "An"). > >>>>>> The client would need to check for YANG 1.1 notifications in=20 > >>>>>> the same way it checks child nodes already. > >>>>> > >>>>> "Any innermost"...? And yes, this is a more significant change on= the > >>>>> client. Beyond this, for use cases (1) & (2), if you don't want=20 > >>>>> to summarize the eventTime, the time should be placed with each=20 > >>>>> innermost event. I am not suggesting we do this, but like Andy=20 > >>>>> I want to figure > >>> out > >>>>> what the WG might be willing to consider in scope. > >>>>> > >>>>> > >>>> > >>>> There was actually a lot of discussion about "eventTime" in the=20 > >>>> NETCONF > >>> WG > >>>> when RFC 5277 was done. > >>>> Lots of disagreement on what it means. The RFC offers little=20 > >>>> guidance or hint of the discussion: > >>>> > >>>> > >>>> eventTime: > >>>> The time the event was generated by the event source. > >>>> > >>>> It may take the server some time to detect the event after it occurs= . > >>>> It may take some time to save the event for replay and transmission. > >>>> Which of these 3 different times is it? (Out of scope I think) > >>>> > >>>> Adding more timestamps is an interesting idea. > >>>> > >>>> But I think something like this could be done without a client MUST. > >>>> The client MAY request 'bulk-encoding' and if the server supports=20 > >>>> it, a more optimized structure would be sent instead of the normal m= essage. > >>> > >>> I prefer this approach, rather than the example in the original=20 > >>> email. If the bulk-encoded notifications are encoded into a=20 > >>> normal notification, we don't have to change anything: > >>> > >>> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:01:00Z > >>> > >>> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:00:00Z > >>> > >>> > >>> > >>> >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > >>> 2017-01-08T00:00:01Z > >>> > >>> > >>> ... > >>> > >>> > >>> > >>> > >> I was hoping for a bulk format that reduced the payload. > >> Your example actually increases the payload size. > >=20 > > For illustration purpose only ;-) > >=20 > > It's perfectly fine w/ me if the contents of this "bulk-notification" > > notif contains a compressed or cleverly encoded list of notifications. > >=20 > > The nice thing with your idea is that it doesn't change the core protoc= ol. > >=20 > >=20 > >=20 > > /martin > >=20 > >=20 > >> I think the subscription needs some sort of encoding negotiation=20 > >> like the Accept header in HTTP. > >> People will eventually think of lots of optimizations that we never=20 > >> imagined. The protocol should be robust enough to allow this to=20 > >> happen. e.g., send multiple subscription-id values in > >> 1 notification instead of duplicating that notification to the=20 > >> receiver N times. > >> Another obvious optimization is the ability to group similar events=20 > >> into a range like link-up for a port-range, representing the entire=20 > >> line card that was just plugged in. > >> > >> > >> ....no restrictions on what is in the header ... > >> ... // limit to 1 element for payload? > >> > >> > >> A simple notification is the canonical form. > >> A notification subscriber acting as a broker will need to convert=20 > >> the bulk form into 1 or more notifications in canonical format. > >> > >> > >> > >>> > >>> /martin > >>> > >> > >> Andy > >> > >> > >>> > >>> > >>>> The receiver MAY extract individual messages from the bulk format=20 > >>>> (maybe > >>>> binary) > >>>> into other formats (like XML or JSON). > >>>> > >>>> I am trying to plan ahead for when YANG Push turns out to be a=20 > >>>> slow > >>> network > >>>> hog :-) > >>>> > >>>> > >>>> Eric > >>>>> > >>>>> > >>>> Andy > >>>> > >>>>> Eric > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On=20 > >>>>>> Behalf Of > >>> Andy > >>>>>> Bierman > >>>>>> Sent: Thursday, January 5, 2017 5:25 PM > >>>>>> To: Netconf > >>>>>> Subject: [Netconf] nested notifications > >>>>>> > >>>>>> Hi, > >>>>>> > >>>>>> I would like some text in RFC 7950 to be reinterpreted. The=20 > >>>>>> text > >>> implies > >>>>> each > >>>>>> notification message can only describe 1 instance of 1 event type. > >>>>>> > >>>>>> RFC 7950, sec 7.16.2 > >>>>>> > >>>>>> The innermost container or list contains an XML > >>>>>> element that carries the name of the defined notification. > >>>>>> > >>>>>> > >>>>>> There are 3 corner-cases that should be considered in order to=20 > >>>>>> minimize network overhead for notifications in 5277bis. > >>>>>> Replicating the node/key hierarchy could be expensive and=20 > >>>>>> events occurring at the same time could be correlated. > >>>>>> > >>>>>> Duplicating the notification messages is inefficient, but=20 > >>>>>> processing multiple events per message makes filtering and=20 > >>>>>> parsing more complicated. > >>>>>> > >>>>>> I am curious if the WG thinks notification overhead is a=20 > >>>>>> concern and if it needs to be addressed somehow in 5277bis. > >>>>>> > >>>>>> > >>>>>> 1) multiple non-sibling events in same subtree > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 42 > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 2) multiple sibling events in the same subtree > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> admin > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 3) multiple non-sibling events in different subtrees > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> 42 > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> eth0 > >>>>>> > >>>>>> auto > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> Andy > >>>>>> > >>>>>> > >>>>> > >>>>> > >>> > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > >=20 >=20 From nobody Thu Jan 12 14:58:59 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 446BD127071 for ; Thu, 12 Jan 2017 14:58:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3pDnpTkZlSR2 for ; Thu, 12 Jan 2017 14:58:56 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E47F128824 for ; Thu, 12 Jan 2017 14:58:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16120; q=dns/txt; s=iport; t=1484261936; x=1485471536; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=RNl/ffVX6xYuOJOP5zrByKH5dgr8RzTIoQispxI2KWc=; b=Ga6lhicOGoFx+l3Oby8ZHfjTIiqGzIVRIjvR/OFxS/hOjsfsly0J44uI 9qH4/GWN9gJuFe9lOwMHV4uIx3YEXfmV0CtBzaKNRDkVtg4SbN+wq81Zr aq0IKKB4XAD8PGn9bbw7NDRdEinkl3tnCF8yS0LLDdH/f19Chv0QuidaZ k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DfAgAXCXhY/4YNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgzwBAQEBAR9fgQkHn2SXNx8LgkKCbEoCgghDEAECAQEBAQEBAWM?= =?us-ascii?q?ohGkBAQEDAQEBOC0HCQIFBwQCAQgRBAEBAQ0RCQcnCxQJCAIEAQ0FCBOIXQgOs?= =?us-ascii?q?wOKDAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFhkWEYYQYCwYBBoV6BY8ejA4BiW+?= =?us-ascii?q?HXYIAjnOIE4pQATYhcVMVOoQ0HIFfc4YqDheBCoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,220,1477958400"; d="scan'208";a="197171237" Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Jan 2017 22:58:54 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id v0CMwsQ0000413 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 12 Jan 2017 22:58:54 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 12 Jan 2017 17:58:53 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 12 Jan 2017 17:58:53 -0500 From: "Eric Voit (evoit)" To: Alexander Clemm , Martin Bjorklund , "per@tail-f.com" , "Andy Bierman (andy@yumaworks.com)" Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KI87NiViNDDkG9WNSE0h61kKEqeKNAgACZJoCAAIaW4IAAADDwgAFZcoCACGxXgIAATXWAgAAO8ID//5YBgIAAoIuAgAACwoD//3rocIAADjcg Date: Thu, 12 Jan 2017 22:58:53 +0000 Message-ID: <0375f3d561e049afac919421e6481b44@XCH-RTP-013.cisco.com> References: <20170112.193029.9249587815129986.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4DEC@dfweml501-mbb> <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> <20170112.225535.699844646707934283.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> 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: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Jan 2017 22:58:58 -0000 We should split the need for nesting, which is a function of encoding effic= iency from the need for bundling, which might be done to limit the number o= f messages sent. If encoding efficiency isn't really an issue, we can just concatenate event= s into a single event notification bundle. And then push the bundle. Such= a thing would impact the headers of course, and we might want different he= aders for each notification as well as the overall bundle. Something like: 2017-01-12T12:00:05Z 349873 094882 2017-01-12T12:00:00Z 22 ... ... As each event above is discrete, we should be able to multiplex general not= ifications, subscribed notifications, and yang-push updates. Eric > From: Netconf, January 12, 2017 5:32 PM >=20 > Understood, 5277 allows exactly one child element for the notification > element. >=20 > My question is about 7950. Does 7950 mandate that notification nodes MUS= T > be used/encoded per 5277 - does 5277 by extension become part of 7950? O= r > does it merely specify what goes below (the notification element element = in > the case of 5277, and perhaps a bulk element or something else in case a = 5277 > alternative becomes available? I guess from your responses it's the form= er > (which I find somewhat limiting - but I guess we are free to define other > encodings for other contexts beyond Netconf XML...). >=20 > --- Alex >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, January 12, 2017 1:56 PM > To: per@tail-f.com > Cc: Alexander Clemm ; netconf@ietf.org > Subject: Re: [Netconf] nested notifications >=20 > Per Hedeland wrote: > > On 2017-01-12 22:34, Alexander Clemm wrote: > > > I agree that it makes sense to allow multiple notifications to be sen= t in one > message. > > > > > > We need to allow for different time stamps, allowing to stamp individ= ual > notifications separately. Clearly, compression schemes can be devised, > including a trivial compression scheme to apply one "bulk" timestamp for = every > notification in the message. > > > > > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, > specifically it is not clear what is really mandated as part of the encod= ing. The > RFC states merely that the notification is encoded as _a_ child XML eleme= nt to > the element. The specification/definition of the > element itself is however not part of RFC 7950, neither is the definition= of the > time stamp (event-time). It seems that all that is specified is the enco= ding of > the event itself, i.e. the representation of the notification identifier = and then > the parameters contained within it. > > > > It seems that you are reading only the first paragraph of 7.16.2, the > > one that starts with "A notification node that is defined on the top > > level of a module...". Try the second one.:-) >=20 > And also check the XSD in RFC 5277; it allows exactly one child element f= or the > notification content. >=20 > > > Does RFC 7950 imply that notification nodes can only be encoded as > contained in a element as defined in RFC 5277? That would= be a > considerable limitation and issue at least in the context of Netconf. I = guess one > could always define other encoding rules outside of Netconf. I don't thi= nk > defining a bulk notification as a special notification, that itself needs= to be > carried in a regular notification, is a good solution. The notification = element is > pure overhead at this point. Allowing the definition of a new bulk notif= ication > element, which can be used in lieu of a notification element, would seem = a lot > more desirable. >=20 > Even in the bulk case you probably want the eventTime for each individual > notification, and if we add more header fields some might be notification > specific. The overhead of the top-level element 'notification' is minima= l in this > case. And for the header fields that apply to all notifications within t= he bulk, > they can nicely be handled if the bulk thingie is a notification. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > > > > > > --- Alex > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Thursday, January 12, 2017 10:30 AM > > > To: andy@yumaworks.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] nested notifications > > > > > > Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund > wrote: > > >> > > >>> Andy Bierman wrote: > > >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) > > >>>> > > >>> wrote: > > >>>> > > >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM > > >>>>>> > > >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) > >>>>> evoit@cisco.com> > > >>>>>> wrote: > > >>>>>> Hi Andy, > > >>>>>> > > >>>>>> =1CThe innermost container or list=1D text is similar to that fo= r > > >>> actions in > > >>>>> section > > >>>>>> 7.15.2. Perhaps the mental model of one target for an action w= as > > >>>>> replicated? > > >>>>>> > > >>>>>> I had not considered that YANG 1.1=19s definition might force th= e > > >>> breakup > > >>>>> of a > > >>>>>> verbose software component generated notification into multiple > > >>> pushed > > >>>>>> notification messages. Looking at the three cases below, I > > >>>>>> don=19t > > >>> think > > >>>>> that > > >>>>>> arbitrary choices made in YANG model structure should impact > > >>>>>> what > > >>> could > > >>>>> or > > >>>>>> couldn=19t be in encoded within any single notification. So my > > >>> preference > > >>>>> would > > >>>>>> be that all three variants below should supportable if that is > > >>>>>> how > > >>> the > > >>>>> system > > >>>>>> passed them to be encoded as part of an event. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I think the WG did not consider these details and assumed they > > >>>>>> were > > >>> the > > >>>>> same > > >>>>>> as for action. > > >>>>>> > > >>>>>> This would be a MAY for the server and a MUST for the client, > > >>>>>> so it > > >>> is > > >>>>> not > > >>>>>> an easy decision. > > >>>>>> > > >>>>>> A couple use-cases I have in mind: > > >>>>>> > > >>>>>> 1) event broker > > >>>>>> subscriber is really a broker that may be pre-processing > > >>>>>> lots > > >>> of > > >>>>>> subscriptions or event types within 1 subscription > > >>>>>> > > >>>>>> 2) digest (time-based push) > > >>>>>> Subscriber wants an update every 5 seconds with all the > > >>>>>> YANG 1.1 > > >>>>> events > > >>>>>> for the previous 5 seconds > > >>>>> > > >>>>> These are both reasonable as controllers are requiring scalable > > >>> methods of > > >>>>> synching on device status. > > >>>>> > > >>>>>> What if the reinterpretation were as simple as =1CAn innermost= =1D > > >>>>>> or =1CThe > > >>>>> first > > >>>>>> innermost=1D? > > >>>>>> > > >>>>>> This covers case 2. (Change "The" to "An"). > > >>>>>> The client would need to check for YANG 1.1 notifications in > > >>>>>> the same way it checks child nodes already. > > >>>>> > > >>>>> "Any innermost"...? And yes, this is a more significant change = on the > > >>>>> client. Beyond this, for use cases (1) & (2), if you don't want > > >>>>> to summarize the eventTime, the time should be placed with each > > >>>>> innermost event. I am not suggesting we do this, but like Andy > > >>>>> I want to figure > > >>> out > > >>>>> what the WG might be willing to consider in scope. > > >>>>> > > >>>>> > > >>>> > > >>>> There was actually a lot of discussion about "eventTime" in the > > >>>> NETCONF > > >>> WG > > >>>> when RFC 5277 was done. > > >>>> Lots of disagreement on what it means. The RFC offers little > > >>>> guidance or hint of the discussion: > > >>>> > > >>>> > > >>>> eventTime: > > >>>> The time the event was generated by the event source. > > >>>> > > >>>> It may take the server some time to detect the event after it occu= rs. > > >>>> It may take some time to save the event for replay and transmissio= n. > > >>>> Which of these 3 different times is it? (Out of scope I think) > > >>>> > > >>>> Adding more timestamps is an interesting idea. > > >>>> > > >>>> But I think something like this could be done without a client MUS= T. > > >>>> The client MAY request 'bulk-encoding' and if the server supports > > >>>> it, a more optimized structure would be sent instead of the normal > message. > > >>> > > >>> I prefer this approach, rather than the example in the original > > >>> email. If the bulk-encoded notifications are encoded into a > > >>> normal notification, we don't have to change anything: > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > > >>> 2017-01-08T00:01:00Z > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"= > > > >>> 2017-01-08T00:00:00Z > > >>> > > >>> > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"= > > > >>> 2017-01-08T00:00:01Z > > >>> > > >>> > > >>> ... > > >>> > > >>> > > >>> > > >>> > > >> I was hoping for a bulk format that reduced the payload. > > >> Your example actually increases the payload size. > > > > > > For illustration purpose only ;-) > > > > > > It's perfectly fine w/ me if the contents of this "bulk-notification" > > > notif contains a compressed or cleverly encoded list of notifications= . > > > > > > The nice thing with your idea is that it doesn't change the core prot= ocol. > > > > > > > > > > > > /martin > > > > > > > > >> I think the subscription needs some sort of encoding negotiation > > >> like the Accept header in HTTP. > > >> People will eventually think of lots of optimizations that we never > > >> imagined. The protocol should be robust enough to allow this to > > >> happen. e.g., send multiple subscription-id values in > > >> 1 notification instead of duplicating that notification to the > > >> receiver N times. > > >> Another obvious optimization is the ability to group similar events > > >> into a range like link-up for a port-range, representing the entire > > >> line card that was just plugged in. > > >> > > >> > > >> ....no restrictions on what is in the header ... > > >> ... // limit to 1 element for payloa= d? > > >> > > >> > > >> A simple notification is the canonical form. > > >> A notification subscriber acting as a broker will need to convert > > >> the bulk form into 1 or more notifications in canonical format. > > >> > > >> > > >> > > >>> > > >>> /martin > > >>> > > >> > > >> Andy > > >> > > >> > > >>> > > >>> > > >>>> The receiver MAY extract individual messages from the bulk format > > >>>> (maybe > > >>>> binary) > > >>>> into other formats (like XML or JSON). > > >>>> > > >>>> I am trying to plan ahead for when YANG Push turns out to be a > > >>>> slow > > >>> network > > >>>> hog :-) > > >>>> > > >>>> > > >>>> Eric > > >>>>> > > >>>>> > > >>>> Andy > > >>>> > > >>>>> Eric > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On > > >>>>>> Behalf Of > > >>> Andy > > >>>>>> Bierman > > >>>>>> Sent: Thursday, January 5, 2017 5:25 PM > > >>>>>> To: Netconf > > >>>>>> Subject: [Netconf] nested notifications > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I would like some text in RFC 7950 to be reinterpreted. The > > >>>>>> text > > >>> implies > > >>>>> each > > >>>>>> notification message can only describe 1 instance of 1 event typ= e. > > >>>>>> > > >>>>>> RFC 7950, sec 7.16.2 > > >>>>>> > > >>>>>> The innermost container or list contains an XML > > >>>>>> element that carries the name of the defined notification. > > >>>>>> > > >>>>>> > > >>>>>> There are 3 corner-cases that should be considered in order to > > >>>>>> minimize network overhead for notifications in 5277bis. > > >>>>>> Replicating the node/key hierarchy could be expensive and > > >>>>>> events occurring at the same time could be correlated. > > >>>>>> > > >>>>>> Duplicating the notification messages is inefficient, but > > >>>>>> processing multiple events per message makes filtering and > > >>>>>> parsing more complicated. > > >>>>>> > > >>>>>> I am curious if the WG thinks notification overhead is a > > >>>>>> concern and if it needs to be addressed somehow in 5277bis. > > >>>>>> > > >>>>>> > > >>>>>> 1) multiple non-sibling events in same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2) multiple sibling events in the same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> admin > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 3) multiple non-sibling events in different subtrees > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Fri Jan 13 00:09:24 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCEE1129B0E; Fri, 13 Jan 2017 00:09:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHeqx_MnMjnK; Fri, 13 Jan 2017 00:09:20 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A10C8129B0D; Fri, 13 Jan 2017 00:09:20 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 41A0961153; Fri, 13 Jan 2017 09:09:18 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484294958; bh=mtomv78Lf6a7KQgSSz7sOCTJrhWmornty7FDmLNi6CE=; h=From:Date:To; b=yTT7iR7BPLXx+cSfMSPTbIOjDoHXAK6K3qs+8P8+G6+5hM0OXCBojlR5SMSqsdbFB 4qLmHgx+OF4u1xH83wGgOjzH8Q2SXDsqsz3hm64vv7bPfwc+bI/9gyL+HPACdevulX 35TyE3iP2EQY5uWiJj0520cRg8IVfiSBinfBUI1Y= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112212755.GA22142@elstar.local> Date: Fri, 13 Jan 2017 09:09:17 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9B70D0DB-AAAC-4C3A-A734-C7EBA7D12830@nic.cz> References: <2E0A23BE-1A1B-4817-98BE-DE1E79199868@nic.cz> <20170112.134737.887226373918047146.mbj@tail-f.com> <20170112173402.GB21677@elstar.local> <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112212755.GA22142@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:09:23 -0000 > On 12 Jan 2017, at 22:27, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 10:20:44PM +0100, Ladislav Lhotka wrote: >>=20 >>> On 12 Jan 2017, at 19:44, Juergen Schoenwaelder = wrote: >>>=20 >>> On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >>>> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>>>=20 >>>>>> YANG statements: >>>>>> - It is not possible to define these statements so they are = different >>>>>> for config and oper >>>>>> - must >>>>>> - when >>>>>> - unique >>>>>> - key >>>>>> - min-elements >>>>>> - max-elements >>>>>> - leafref (path) >>>>>> - if-feature >>>>>> - deviation >>>>>> - type (or any sub-statements of type-stmt) >>>>>> - status >>>>>> - description >>>>>> - reference >>>>>=20 >>>>> Considering statements that constraint 'values', it is not = entirely >>>>> clear to me what they mean for state nodes. If a server has >>>>> operational state that violates a must or range or ... constraint = in >>>>> the YANG model, what is the server expected to do? >>>>>=20 >>>>=20 >>>> The client uses the YANG validation to check on what the server is = sending. >>>> The server is buggy if it is sending data that violates YANG = constraints. >>>> If any of these statements need to be different for config and oper >>>> then the old style YANG has to be used instead. >>>>=20 >>>=20 >>> OK. So the client does the validation. What does the client do if = the >>> operational state it got is not valid according to the YANG = constraints? >>=20 >> Don't forget that data models also provide guidelines to server = implementors. It is not without reason to write a test suite that = validates server responses, including state data. >>=20 >=20 > OK. But what do you expect a regular client to do? >=20 Complain to the vendor that their server is broken. Lada > /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: 0xB8F92B08A9F76C67 From nobody Fri Jan 13 00:22:18 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F9ED129B1E; Fri, 13 Jan 2017 00:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n0Ae7e6Et0Kt; Fri, 13 Jan 2017 00:22:14 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86C67129B08; Fri, 13 Jan 2017 00:22:14 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 3809C6137F; Fri, 13 Jan 2017 09:22:13 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484295733; bh=QQxWAGeD9lE1E+sqAEf13B/Lm7zVuc7MKZdASKlGg8Q=; h=From:Date:To; b=vZKOCOzGGSSMFAX71sRjieD6UtczKswIfZRKZXVpB475fKwDykYLk+1DmI7WNCiH1 rhfHl0VB3hhIxoF5OV2h4c5UelpxJWXeEs/VKibFTP85dq0yoDLx6I6Ca4ncH2Y5t6 hZ4GmbPeyqVBVcTzuJkXeSWXZs4AHVEhxZyyUl3s= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170112.225937.1113385078732083121.mbj@tail-f.com> Date: Fri, 13 Jan 2017 09:22:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <9A8B650F-E224-42FC-8987-FBF15CA4D614@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:22:16 -0000 > On 12 Jan 2017, at 22:59, Martin Bjorklund wrote: >=20 > Ladislav Lhotka wrote: >>=20 >>> On 12 Jan 2017, at 19:44, Juergen Schoenwaelder >>> wrote: >>>=20 >>> On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: >>>> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < >>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>=20 >>>>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: >>>>>>=20 >>>>>> YANG statements: >>>>>> - It is not possible to define these statements so they are = different >>>>>> for config and oper >>>>>> - must >>>>>> - when >>>>>> - unique >>>>>> - key >>>>>> - min-elements >>>>>> - max-elements >>>>>> - leafref (path) >>>>>> - if-feature >>>>>> - deviation >>>>>> - type (or any sub-statements of type-stmt) >>>>>> - status >>>>>> - description >>>>>> - reference >>>>>=20 >>>>> Considering statements that constraint 'values', it is not = entirely >>>>> clear to me what they mean for state nodes. If a server has >>>>> operational state that violates a must or range or ... constraint = in >>>>> the YANG model, what is the server expected to do? >>>>>=20 >>>>=20 >>>> The client uses the YANG validation to check on what the server is >>>> sending. >>>> The server is buggy if it is sending data that violates YANG >>>> constraints. >>>> If any of these statements need to be different for config and oper >>>> then the old style YANG has to be used instead. >>>>=20 >>>=20 >>> OK. So the client does the validation. What does the client do if = the >>> operational state it got is not valid according to the YANG >>> constraints? >>=20 >> Don't forget that data models also provide guidelines to server >> implementors. >=20 > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different Which doesn't mean that inconsistent (format of) state data is = acceptable. My colleague develops a BGP looking glass, and it is really = a terrible work because he has to do a lot of screen-scraping. Each time = a vendor changes the data format, he has to update his software. I keep = telling him that our nice protocols would save him from this drudgery. Lada > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. >=20 >=20 > /martin -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Jan 13 00:42:49 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E725129B3E; Fri, 13 Jan 2017 00:42:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqOsw47QHYmr; Fri, 13 Jan 2017 00:42:44 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB0D129B36; Fri, 13 Jan 2017 00:42:43 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id A5372611C7; Fri, 13 Jan 2017 09:42:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484296961; bh=kxEC4UbwM+FpA/QBjX37cLj6kXP1vVaRUlbk6KvObdI=; h=From:Date:To; b=hT9cIyO3qNSAmAVYy4vVkaKYxhI7NF+BxMugd6CSVRSDpCV/5WLmqrzsu90bwq9NZ e7jIP5NgOO/fonYbURB7o0HmZJxuiXqdG40a77VHrrvQ49Z6ouPScecZNpWg0WtJgy qPAXcbUnCH3L3a9o2cOFAdhOp4H58AF5+nJ+vGW0= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Fri, 13 Jan 2017 09:42:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <971145C2-ACDC-4BB0-B041-0BE31173C1A4@nic.cz> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:42:47 -0000 > On 12 Jan 2017, at 23:05, Andy Bierman wrote: >=20 >=20 >=20 > On Thu, Jan 12, 2017 at 1:59 PM, Martin Bjorklund = wrote: > Ladislav Lhotka wrote: > > > > > On 12 Jan 2017, at 19:44, Juergen Schoenwaelder > > > wrote: > > > > > > On Thu, Jan 12, 2017 at 09:38:46AM -0800, Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 9:34 AM, Juergen Schoenwaelder < > > >> j.schoenwaelder@jacobs-university.de> wrote: > > >> > > >>> On Thu, Jan 12, 2017 at 09:19:54AM -0800, Andy Bierman wrote: > > >>>> > > >>>> YANG statements: > > >>>> - It is not possible to define these statements so they are = different > > >>>> for config and oper > > >>>> - must > > >>>> - when > > >>>> - unique > > >>>> - key > > >>>> - min-elements > > >>>> - max-elements > > >>>> - leafref (path) > > >>>> - if-feature > > >>>> - deviation > > >>>> - type (or any sub-statements of type-stmt) > > >>>> - status > > >>>> - description > > >>>> - reference > > >>> > > >>> Considering statements that constraint 'values', it is not = entirely > > >>> clear to me what they mean for state nodes. If a server has > > >>> operational state that violates a must or range or ... = constraint in > > >>> the YANG model, what is the server expected to do? > > >>> > > >> > > >> The client uses the YANG validation to check on what the server = is > > >> sending. > > >> The server is buggy if it is sending data that violates YANG > > >> constraints. > > >> If any of these statements need to be different for config and = oper > > >> then the old style YANG has to be used instead. > > >> > > > > > > OK. So the client does the validation. What does the client do if = the > > > operational state it got is not valid according to the YANG > > > constraints? > > > > Don't forget that data models also provide guidelines to server > > implementors. >=20 > Yes, and that it is all that can be done currently. I don't think any > implemention that receives a request today freezes the system in > order to get a guaranteed consistent snapshot. Instead, the different > subsystems will be queried, sequentially or in parallell, and the end > result is shipped to the client. The result may or may not be > consistent. >=20 >=20 >=20 > So this thread is questioning why YANG allows constraints on = config=3Dfalse data nodes. Partly it is a fault of YANG spec because RFC 7950 only says in sec. 8.1 = that The running configuration datastore MUST always be valid. This is exactly what I would like to remove. *Any* data tree for which = we have a corresponding YANG data model can be validated, and it is IMO = up to a particular management application (with a certain datastore = model) to decide what needs to be validated and what not. A particular workflow, datastore model and validation procedure can also = be standardized, but it should be done outside the YANG spec. Lada > =46rom the generic toolbuilder POV, it allows the YANG engine to = report issues to > the operator without custom programming for each little issue. Who = knows why the > foo-table requires 3 entries to be valid min-elements 3). > The tool can report to the operator "foo-table does not have enough = entries" > and let the operator decide what to do about it. >=20 >=20 > =20 > /martin >=20 >=20 > Andy > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Jan 13 00:51:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 264C41294A0; Fri, 13 Jan 2017 00:51:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 AYE-eLZVhFb5; Fri, 13 Jan 2017 00:51:40 -0800 (PST) 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 ACB3E129489; Fri, 13 Jan 2017 00:51:39 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 17C1C8D0; Fri, 13 Jan 2017 09:51:38 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id vZdhe2XMQRl9; Fri, 13 Jan 2017 09:51:34 +0100 (CET) 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, 13 Jan 2017 09:51:37 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id AABAB20091; Fri, 13 Jan 2017 09:51:37 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id q2DNpTtc1SlY; Fri, 13 Jan 2017 09:51:37 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2178A20090; Fri, 13 Jan 2017 09:51:37 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B17EE3E0C040; Fri, 13 Jan 2017 09:51:38 +0100 (CET) Date: Fri, 13 Jan 2017 09:51:38 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170113085137.GA23063@elstar.local> Mail-Followup-To: Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.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.6.0 (2016-04-01) Archived-At: Cc: Netconf , "netmod@ietf.org" Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 08:51:45 -0000 On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: > > So this thread is questioning why YANG allows constraints on config=false > data nodes. > The point I am trying to make is that for configuration data, we have a clear model what validation means and when it is applied. The basic idea is that the running configuration of a system is always valid and configuration changes will never leave the running configuration in an invalid state, i.e., configuration change requests are rejected if they would leave to invalid configuration state. For operational state data, it is not entirely clear where and when validation will occur or if it will occur at all. In fact, if a system is in a weird state, it might actually be useful for certain purposes to expose the weird state. And, as Martin pointed out, inconsistencies may also result from the technical difficulties to take a consistent snapshort of a system with several concurrent subsystems. For these reasons, the assumption that a server always returns valid operational state data is likely not true. > From the generic toolbuilder POV, it allows the YANG engine to > report issues to the operator without custom programming for each > little issue. Who knows why the foo-table requires 3 entries to be > valid min-elements 3). The tool can report to the operator > "foo-table does not have enough entries" and let the operator decide > what to do about it. Yes, it will be up to the client's functionality and its implemention specifics to deal with the question whether it is useful to validate operational state data or what to do if the received operational state data is invalid. While servers are expected to be strict about the validity of configuration data, I think clients need to be lenient about the validity of operational state data. /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 Jan 13 01:26:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C5A0129AB1; Fri, 13 Jan 2017 01:26:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q2vw04hLJQ50; Fri, 13 Jan 2017 01:26:06 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B9D4C12944F; Fri, 13 Jan 2017 01:26:05 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:4569:b014:942e:3753] (unknown [IPv6:2001:718:1a02:1:4569:b014:942e:3753]) by mail.nic.cz (Postfix) with ESMTPSA id 355CF60FE4; Fri, 13 Jan 2017 10:26:03 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484299563; bh=QVqgqN9w+B1xUKiok5v8I2jrw9Oun6N4aPnwFc+RdrE=; h=From:Date:To; b=Ujob1znQIFJXWs8fXRxIsZiMOAtLPAMvKp4vb7G7zS2cufb7aXV2b8aXB00uMM9D6 2u99QlhwSthKuCQEfLTf0UhNe/7tBDI9Cq9OOULQb2nMmNY/QDiQBFYHzw1cbNA0ar PgIadc23GQ5NcWbELBoydTYewR25jhzhIFoYd0vw= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: <20170113085137.GA23063@elstar.local> Date: Fri, 13 Jan 2017 10:26:02 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <20170113085137.GA23063@elstar.local> To: =?utf-8?B?SsO8cmdlbiBTY2jDtm53w6RsZGVy?= X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:26:08 -0000 > On 13 Jan 2017, at 09:51, Juergen Schoenwaelder = wrote: >=20 > On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: >>=20 >> So this thread is questioning why YANG allows constraints on = config=3Dfalse >> data nodes. >>=20 >=20 > The point I am trying to make is that for configuration data, we have > a clear model what validation means and when it is applied. The basic > idea is that the running configuration of a system is always valid and > configuration changes will never leave the running configuration in an > invalid state, i.e., configuration change requests are rejected if > they would leave to invalid configuration state. >=20 > For operational state data, it is not entirely clear where and when > validation will occur or if it will occur at all. In fact, if a system > is in a weird state, it might actually be useful for certain purposes > to expose the weird state. And, as Martin pointed out, inconsistencies > may also result from the technical difficulties to take a consistent > snapshort of a system with several concurrent subsystems. For these These are valid reasons and could IMO be lived with, but I think we have = to require "best effort" from the server. If we drop validity of state = data altogether, their invalidity will be commonplace, and (I suspect) = caused mainly by laziness of server implementors. That said, I would be in favour of decoupling data models of = configuration and state data. If a device produces native state data in = a format that's difficult to translate to a standard form, vendors could = be allowed to use a proprietary model for state data. It is IMO still = far better than declaring compliance to RFC XXXX on paper and then = sending something else. > reasons, the assumption that a server always returns valid operational > state data is likely not true. >=20 >> =46rom the generic toolbuilder POV, it allows the YANG engine to >> report issues to the operator without custom programming for each >> little issue. Who knows why the foo-table requires 3 entries to be >> valid min-elements 3). The tool can report to the operator >> "foo-table does not have enough entries" and let the operator decide >> what to do about it. >=20 > Yes, it will be up to the client's functionality and its implemention > specifics to deal with the question whether it is useful to validate > operational state data or what to do if the received operational state > data is invalid. >=20 > While servers are expected to be strict about the validity of > configuration data, I think clients need to be lenient about the > validity of operational state data. It is all about the Postel Principle: the server should be strict, and = the client may be lenient. It also depends on the character of the state = data and specific aspect of validity (broken leafref is not the same as = missing mandatory leaf). 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 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Jan 13 01:26:36 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE970129B36 for ; Fri, 13 Jan 2017 01:26:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 RQ82e_rx3IBU for ; Fri, 13 Jan 2017 01:26:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8DFCE129B3B for ; Fri, 13 Jan 2017 01:26:28 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 4C56B1AE018A; Fri, 13 Jan 2017 10:26:27 +0100 (CET) Date: Fri, 13 Jan 2017 10:26:27 +0100 (CET) Message-Id: <20170113.102627.1957757287998651335.mbj@tail-f.com> To: alexander.clemm@huawei.com From: Martin Bjorklund In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> References: <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> <20170112.225535.699844646707934283.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 09:26:35 -0000 Alexander Clemm wrote: > Understood, 5277 allows exactly one child element for the notification > element. > > My question is about 7950. Does 7950 mandate that notification nodes > MUST be used/encoded per 5277 - does 5277 by extension become part of > 7950? Or does it merely specify what goes below (the notification > element element in the case of 5277, and perhaps a bulk element or > something else in case a 5277 alternative becomes available? I guess > from your responses it's the former (which I find somewhat limiting - > but I guess we are free to define other encodings for other contexts > beyond Netconf XML...). Maybe a little of both... The section is called "NETCONF XML Encoding Rules". So clearly other contexts can have other rules. But when it is time to send a notification over NETCONF, clients know how the notification will be encoded. Now, suppose we obsolete 5277 and define a new element. In this case we should probably define a paragraph in the new RFC which "Updates: RFC 7950", with text that exaplains how YANG-defined notifications are encoded. /martin > --- Alex > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, January 12, 2017 1:56 PM > To: per@tail-f.com > Cc: Alexander Clemm ; netconf@ietf.org > Subject: Re: [Netconf] nested notifications > > Per Hedeland wrote: > > On 2017-01-12 22:34, Alexander Clemm wrote: > > > I agree that it makes sense to allow multiple notifications to be sent > > > in one message. > > > > > > We need to allow for different time stamps, allowing to stamp > > > individual notifications separately. Clearly, compression schemes can > > > be devised, including a trivial compression scheme to apply one "bulk" > > > timestamp for every notification in the message. > > > > > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, > > > specifically it is not clear what is really mandated as part of the > > > encoding. The RFC states merely that the notification is encoded as > > > _a_ child XML element to the element. The > > > specification/definition of the element itself is > > > however not part of RFC 7950, neither is the definition of the time > > > stamp (event-time). It seems that all that is specified is the > > > encoding of the event itself, i.e. the representation of the > > > notification identifier and then the parameters contained within it. > > > > It seems that you are reading only the first paragraph of 7.16.2, the > > one that starts with "A notification node that is defined on the top > > level of a module...". Try the second one.:-) > > And also check the XSD in RFC 5277; it allows exactly one child > element for the notification content. > > > > Does RFC 7950 imply that notification nodes can only be encoded as > > > contained in a element as defined in RFC 5277? That > > > would be a considerable limitation and issue at least in the context > > > of Netconf. I guess one could always define other encoding rules > > > outside of Netconf. I don't think defining a bulk notification as a > > > special notification, that itself needs to be carried in a regular > > > notification, is a good solution. The notification element is pure > > > overhead at this point. Allowing the definition of a new bulk > > > notification element, which can be used in lieu of a notification > > > element, would seem a lot more desirable. > > Even in the bulk case you probably want the eventTime for each > individual notification, and if we add more header fields some might > be notification specific. The overhead of the top-level element > 'notification' is minimal in this case. And for the header fields > that apply to all notifications within the bulk, they can nicely be > handled if the bulk thingie is a notification. > > > > /martin > > > > > > > > > --- Alex > > > > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin > > > Bjorklund > > > Sent: Thursday, January 12, 2017 10:30 AM > > > To: andy@yumaworks.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] nested notifications > > > > > > Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund > > >> wrote: > > >> > > >>> Andy Bierman wrote: > > >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) > > >>>> > > >>> wrote: > > >>>> > > >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM > > >>>>>> > > >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) > >>>>> evoit@cisco.com> > > >>>>>> wrote: > > >>>>>> Hi Andy, > > >>>>>> > > >>>>>> The innermost container or list text is similar to that for > > >>> actions in > > >>>>> section > > >>>>>> 7.15.2. Perhaps the mental model of one target for an action was > > >>>>> replicated? > > >>>>>> > > >>>>>> I had not considered that YANG 1.1s definition might force the > > >>> breakup > > >>>>> of a > > >>>>>> verbose software component generated notification into multiple > > >>> pushed > > >>>>>> notification messages. Looking at the three cases below, I > > >>>>>> dont > > >>> think > > >>>>> that > > >>>>>> arbitrary choices made in YANG model structure should impact > > >>>>>> what > > >>> could > > >>>>> or > > >>>>>> couldnt be in encoded within any single notification. So my > > >>> preference > > >>>>> would > > >>>>>> be that all three variants below should supportable if that is > > >>>>>> how > > >>> the > > >>>>> system > > >>>>>> passed them to be encoded as part of an event. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I think the WG did not consider these details and assumed they > > >>>>>> were > > >>> the > > >>>>> same > > >>>>>> as for action. > > >>>>>> > > >>>>>> This would be a MAY for the server and a MUST for the client, > > >>>>>> so it > > >>> is > > >>>>> not > > >>>>>> an easy decision. > > >>>>>> > > >>>>>> A couple use-cases I have in mind: > > >>>>>> > > >>>>>> 1) event broker > > >>>>>> subscriber is really a broker that may be pre-processing > > >>>>>> lots > > >>> of > > >>>>>> subscriptions or event types within 1 subscription > > >>>>>> > > >>>>>> 2) digest (time-based push) > > >>>>>> Subscriber wants an update every 5 seconds with all the > > >>>>>> YANG 1.1 > > >>>>> events > > >>>>>> for the previous 5 seconds > > >>>>> > > >>>>> These are both reasonable as controllers are requiring scalable > > >>> methods of > > >>>>> synching on device status. > > >>>>> > > >>>>>> What if the reinterpretation were as simple as An innermost > > >>>>>> or The > > >>>>> first > > >>>>>> innermost? > > >>>>>> > > >>>>>> This covers case 2. (Change "The" to "An"). > > >>>>>> The client would need to check for YANG 1.1 notifications in > > >>>>>> the same way it checks child nodes already. > > >>>>> > > >>>>> "Any innermost"...? And yes, this is a more significant change on the > > >>>>> client. Beyond this, for use cases (1) & (2), if you don't want > > >>>>> to summarize the eventTime, the time should be placed with each > > >>>>> innermost event. I am not suggesting we do this, but like Andy > > >>>>> I want to figure > > >>> out > > >>>>> what the WG might be willing to consider in scope. > > >>>>> > > >>>>> > > >>>> > > >>>> There was actually a lot of discussion about "eventTime" in the > > >>>> NETCONF > > >>> WG > > >>>> when RFC 5277 was done. > > >>>> Lots of disagreement on what it means. The RFC offers little > > >>>> guidance or hint of the discussion: > > >>>> > > >>>> > > >>>> eventTime: > > >>>> The time the event was generated by the event source. > > >>>> > > >>>> It may take the server some time to detect the event after it occurs. > > >>>> It may take some time to save the event for replay and transmission. > > >>>> Which of these 3 different times is it? (Out of scope I think) > > >>>> > > >>>> Adding more timestamps is an interesting idea. > > >>>> > > >>>> But I think something like this could be done without a client MUST. > > >>>> The client MAY request 'bulk-encoding' and if the server supports > > >>>> it, a more optimized structure would be sent instead of the normal > > >>>> message. > > >>> > > >>> I prefer this approach, rather than the example in the original > > >>> email. If the bulk-encoded notifications are encoded into a > > >>> normal notification, we don't have to change anything: > > >>> > > >>> > >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > >>> 2017-01-08T00:01:00Z > > >>> > > >>> > >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > >>> 2017-01-08T00:00:00Z > > >>> > > >>> > > >>> > > >>> > >>> xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0"> > > >>> 2017-01-08T00:00:01Z > > >>> > > >>> > > >>> ... > > >>> > > >>> > > >>> > > >>> > > >> I was hoping for a bulk format that reduced the payload. > > >> Your example actually increases the payload size. > > > > > > For illustration purpose only ;-) > > > > > > It's perfectly fine w/ me if the contents of this "bulk-notification" > > > notif contains a compressed or cleverly encoded list of notifications. > > > > > > The nice thing with your idea is that it doesn't change the core > > > protocol. > > > > > > > > > > > > /martin > > > > > > > > >> I think the subscription needs some sort of encoding negotiation > > >> like the Accept header in HTTP. > > >> People will eventually think of lots of optimizations that we never > > >> imagined. The protocol should be robust enough to allow this to > > >> happen. e.g., send multiple subscription-id values in > > >> 1 notification instead of duplicating that notification to the > > >> receiver N times. > > >> Another obvious optimization is the ability to group similar events > > >> into a range like link-up for a port-range, representing the entire > > >> line card that was just plugged in. > > >> > > >> > > >> ....no restrictions on what is in the header ... > > >> ... // limit to 1 element for payload? > > >> > > >> > > >> A simple notification is the canonical form. > > >> A notification subscriber acting as a broker will need to convert > > >> the bulk form into 1 or more notifications in canonical format. > > >> > > >> > > >> > > >>> > > >>> /martin > > >>> > > >> > > >> Andy > > >> > > >> > > >>> > > >>> > > >>>> The receiver MAY extract individual messages from the bulk format > > >>>> (maybe > > >>>> binary) > > >>>> into other formats (like XML or JSON). > > >>>> > > >>>> I am trying to plan ahead for when YANG Push turns out to be a > > >>>> slow > > >>> network > > >>>> hog :-) > > >>>> > > >>>> > > >>>> Eric > > >>>>> > > >>>>> > > >>>> Andy > > >>>> > > >>>>> Eric > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On > > >>>>>> Behalf Of > > >>> Andy > > >>>>>> Bierman > > >>>>>> Sent: Thursday, January 5, 2017 5:25 PM > > >>>>>> To: Netconf > > >>>>>> Subject: [Netconf] nested notifications > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I would like some text in RFC 7950 to be reinterpreted. The > > >>>>>> text > > >>> implies > > >>>>> each > > >>>>>> notification message can only describe 1 instance of 1 event type. > > >>>>>> > > >>>>>> RFC 7950, sec 7.16.2 > > >>>>>> > > >>>>>> The innermost container or list contains an XML > > >>>>>> element that carries the name of the defined notification. > > >>>>>> > > >>>>>> > > >>>>>> There are 3 corner-cases that should be considered in order to > > >>>>>> minimize network overhead for notifications in 5277bis. > > >>>>>> Replicating the node/key hierarchy could be expensive and > > >>>>>> events occurring at the same time could be correlated. > > >>>>>> > > >>>>>> Duplicating the notification messages is inefficient, but > > >>>>>> processing multiple events per message makes filtering and > > >>>>>> parsing more complicated. > > >>>>>> > > >>>>>> I am curious if the WG thinks notification overhead is a > > >>>>>> concern and if it needs to be addressed somehow in 5277bis. > > >>>>>> > > >>>>>> > > >>>>>> 1) multiple non-sibling events in same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2) multiple sibling events in the same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> admin > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 3) multiple non-sibling events in different subtrees > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > From nobody Fri Jan 13 08:50:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B1A6129C76 for ; Fri, 13 Jan 2017 08:50:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7RDCgsvVbvw for ; Fri, 13 Jan 2017 08:50:19 -0800 (PST) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEBBF129C75 for ; Fri, 13 Jan 2017 08:50:19 -0800 (PST) Received: by mail-qt0-x22c.google.com with SMTP id l7so52703533qtd.1 for ; Fri, 13 Jan 2017 08:50:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=x9dOn4ZvYE/hKe+I57+XWMKEhPveTjb5AQvccmZBvXo=; b=VSjdgIr8bF3hQD6vI1f0L3XbazgyNJlM51hKf3hg1VWJHcbegHD3s7zc2dbP+Z5xb8 gVKg8/65ciW9LgWzGdUvMfnmYyCZ52eCTgcN405GFaFvbPCFLzjPGkDXl4a8xmdJAljs +olu+MLevgklA5eIFPvlKTKf4Y4wYhSLEeqgDrrh0gmRG3EQQXtvD/yOhzgEmbtYYg90 oMF2yo4ZU7c3PMRVHSK+o+JCQKknj9Tg+uMCONsin75gCTxpaUfbkLc7Z8SxcYCdv8Cp Gbz253U4s629JHHff0/F1iRKDlabCWppYW1affYSl8oVjQcUyHXBbQHtw6KBAEbsVViD yJ4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=x9dOn4ZvYE/hKe+I57+XWMKEhPveTjb5AQvccmZBvXo=; b=h3+gBT8WlQwVnXgJUwOfZBS7wXUQjD6cuY9LYCJUPQeTOTvpGi5UBYCppNuelofnEV 4OIgoYK0Lauj14CbctORCrsK5imSNsQyoJyu9Bu4oAxqVfDz9D2wTpnyRvo/acPn2Aqz wUWq+MIAG1hypbw8OrwW2gfTNYSzgzbNllZJcGdOzT8PZYH+xLXSMv48+XNQXw4d+NnY hCxUEL8c1pvPnkzcnsSE18Mbib+fFTCzKWkyDbvEnRsbOsJAtZSbWaaJgBDFEWPV/wur ya1GuN1xz5h8HWNyYLIj6uVUcM9W0G/98T/tf4ho4bt9iVRaOdM8/t3SS6PDVYTyyC0y LD3Q== X-Gm-Message-State: AIkVDXIVcNeWlaJxh4El2U/iS4fPoqrhUmwaWZb4VnNWmArXUX5QMSSpRfwGzopKHkq0SJp5qZkbZSvG365uXg== X-Received: by 10.237.59.203 with SMTP id s11mr19666692qte.46.1484326218952; Fri, 13 Jan 2017 08:50:18 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Fri, 13 Jan 2017 08:50:17 -0800 (PST) In-Reply-To: <20170113085137.GA23063@elstar.local> References: <20170112184452.GC21677@elstar.local> <47641B5E-A338-4D88-ADC3-977072F558F3@nic.cz> <20170112.225937.1113385078732083121.mbj@tail-f.com> <20170113085137.GA23063@elstar.local> From: Andy Bierman Date: Fri, 13 Jan 2017 08:50:17 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , "netmod@ietf.org" , Netconf Content-Type: multipart/alternative; boundary=94eb2c1907ac03145b0545fca1e2 Archived-At: Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 16:50:22 -0000 --94eb2c1907ac03145b0545fca1e2 Content-Type: text/plain; charset=UTF-8 On Fri, Jan 13, 2017 at 12:51 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bierman wrote: > > > > So this thread is questioning why YANG allows constraints on config=false > > data nodes. > > > > The point I am trying to make is that for configuration data, we have > a clear model what validation means and when it is applied. The basic > idea is that the running configuration of a system is always valid and > configuration changes will never leave the running configuration in an > invalid state, i.e., configuration change requests are rejected if > they would leave to invalid configuration state. > > For operational state data, it is not entirely clear where and when > validation will occur or if it will occur at all. In fact, if a system > is in a weird state, it might actually be useful for certain purposes > to expose the weird state. And, as Martin pointed out, inconsistencies > may also result from the technical difficulties to take a consistent > snapshort of a system with several concurrent subsystems. For these > reasons, the assumption that a server always returns valid operational > state data is likely not true. > > > From the generic toolbuilder POV, it allows the YANG engine to > > report issues to the operator without custom programming for each > > little issue. Who knows why the foo-table requires 3 entries to be > > valid min-elements 3). The tool can report to the operator > > "foo-table does not have enough entries" and let the operator decide > > what to do about it. > > Yes, it will be up to the client's functionality and its implemention > specifics to deal with the question whether it is useful to validate > operational state data or what to do if the received operational state > data is invalid. > > While servers are expected to be strict about the validity of > configuration data, I think clients need to be lenient about the > validity of operational state data. > > Actually, a client that is not restricted by NACM can use the YANG validation just fine. There are opstate tables that churn but that is the exception. Also note that the rpc/input and action/input constraints are validated by the server, and MUST be implemented. The XPath in these contexts are allowed to reference state data (starting in YANG 1.1) > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1907ac03145b0545fca1e2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 12:51 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Jan 12, 2017 at 02:05:07PM -0800, Andy Bier= man wrote:
>
> So this thread is questioning why YANG allows constraints on config=3D= false
> data nodes.
>

The point I am trying to make is that for configuration data, we have
a clear model what validation means and when it is applied. The basic
idea is that the running configuration of a system is always valid and
configuration changes will never leave the running configuration in an
invalid state, i.e., configuration change requests are rejected if
they would leave to invalid configuration state.

For operational state data, it is not entirely clear where and when
validation will occur or if it will occur at all. In fact, if a system
is in a weird state, it might actually be useful for certain purposes
to expose the weird state. And, as Martin pointed out, inconsistencies
may also result from the technical difficulties to take a consistent
snapshort of a system with several concurrent subsystems. For these
reasons, the assumption that a server always returns valid operational
state data is likely not true.

> From the generic toolbuilder POV, it allows the YANG engine to
> report issues to the operator without custom programming for each
> little issue. Who knows why the foo-table requires 3 entries to be
> valid min-elements 3). The tool can report to the operator
> "foo-table does not have enough entries" and let the operato= r decide
> what to do about it.

Yes, it will be up to the client's functionality and its implemention specifics to deal with the question whether it is useful to validate
operational state data or what to do if the received operational state
data is invalid.

While servers are expected to be strict about the validity of
configuration data, I think clients need to be lenient about the
validity of operational state data.



Actually, a client that is not restri= cted by NACM can use the YANG validation just fine.
There are ops= tate tables that churn but that is the exception.

= Also note that the rpc/input and action/input constraints are validated
by the server, and MUST be implemented.=C2=A0 The XPath in these con= texts
are allowed to reference state data (starting in YANG 1.1)<= /div>


=C2=A0
/js

Andy
=C2=A0=

--
Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer= sity Bremen gGmbH
Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring 1 | 28= 759 Bremen | Germany
Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<http://www.jacobs-university.de/>

--94eb2c1907ac03145b0545fca1e2-- From nobody Fri Jan 13 10:00:35 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1DC0129CFC for ; Fri, 13 Jan 2017 10:00:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2jdI0wYY6RgP for ; Fri, 13 Jan 2017 10:00:31 -0800 (PST) Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0111.outbound.protection.outlook.com [104.47.36.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A6844126BF6 for ; Fri, 13 Jan 2017 10:00:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=SPjnzkLRx52PltlPfVYQyWuUjIwvtiCxiUN9qnM549E=; b=iYSjI7+kQgcaBLq77Jf8GIT5RjfEw6udX87N9zCUPYqZrpeb+AoVLd2qawItAQDi4xWf0r1MmgSraVo+XJFmwmO0MprVA1Pb/M54yi8YWklA8TK+Lb1tpEUZ5nCRuSHJ1rdkr66qELYzUXTT+yeG4zYIYODSCz8IR0fmkWCGXfY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Fri, 13 Jan 2017 18:00:29 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.008; Fri, 13 Jan 2017 18:00:29 +0000 From: Kent Watsen To: "netconf@ietf.org" Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeg== Date: Fri, 13 Jan 2017 18:00:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.10] x-ms-office365-filtering-correlation-id: 106becb9-cb0d-4899-a635-08d43bde0f7b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:yj0xi3unxCkw9XSKe9Q/D/s6DlhQlcSnx02VW1feThkO5NpKmVBMZJ8GNVmHU8KJOCtYQS1v2lZyotkKHi5kK0Od/sZmbeF+15ut5ZHyrVU1atg6vBaR9wKp+SQmNDH5SeogamCBgLbUzKP1KSOqEPHEIE9GtLNVT9pvTLOFeHRsErt7vlN6CQL30a3uNckiCmvaXfqgL4tyOBx+S+hWaZ3WVk4gt2k/Ycg8IVvzxvwWH/UKHTG8GLT89/KSZxy641NUzz8ALcXFFBMfSYipGloGH9JRIr3F1s9PNiaqfxuvUKe6QRPzKE1sEd3179isB/RHvtrNVNBqBZjt2dz2hzpzkSOMfsHgu9jxsojG6B4fbMsMCfDtzlfpXX8zpkAfejBQDTvqECU2TCvT2oyqGI4AXJ651T5D8wdXD+r9W2h/ZWjEgF7Au0QgLU//6TOkiClCK4paKXEQFRFQYKkPBw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 018632C080 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39860400002)(39840400002)(39410400002)(39850400002)(189002)(199003)(102836003)(4001350100001)(6116002)(50986999)(110136003)(3846002)(31430400001)(2501003)(54356999)(33656002)(66066001)(97736004)(6916009)(189998001)(36756003)(92566002)(8936002)(2900100001)(101416001)(229853002)(5660300001)(99286003)(6512007)(83716003)(3280700002)(3660700001)(305945005)(6486002)(77096006)(86362001)(8676002)(2906002)(25786008)(6436002)(1730700003)(6506006)(82746002)(7736002)(5640700003)(38730400001)(68736007)(83506001)(81166006)(106356001)(106116001)(2351001)(122556002)(81156014)(107886002)(105586002)(450100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <4ACEF9043D596F459605B8E8818B5CE2@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Jan 2017 18:00:29.3261 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:00:34 -0000 DQpTb21ld2hhdCBhbnN3ZXJpbmcgbXkgb3duIHF1ZXN0aW9uLCBidXQgYnkgbm8gbWVhbnMgY29t aW5nIHRvIGEgY29tcGxldGUgc29sdXRpb24sIEkgcmVhbGl6ZWQgdGhhdCBSRVNUQ09ORiBkb2Vz IHNvbWV0aGluZyBzaW1pbGFyIHdpdGggaXRzIHlhbmctZGF0YSBleHRlbnNpb24gYW5kIFlBTkcg ZGF0YSB0ZW1wbGF0ZToNCg0KICAgbyAgeWFuZy1kYXRhIGV4dGVuc2lvbjogQSBZQU5HIGV4dGVy bmFsIHN0YXRlbWVudCB0aGF0IGNvbmZvcm1zIHRvDQogICAgICB0aGUgInlhbmctZGF0YSIgZXh0 ZW5zaW9uIHN0YXRlbWVudCBmb3VuZCBpbiBTZWN0aW9uIDguICBUaGUgeWFuZy0NCiAgICAgIGRh dGEgZXh0ZW5zaW9uIGlzIHVzZWQgdG8gZGVmaW5lIFlBTkcgZGF0YSBzdHJ1Y3R1cmVzIHRoYXQg YXJlDQogICAgICBtZWFudCB0byBiZSB1c2VkIGFzIFlBTkcgZGF0YSB0ZW1wbGF0ZXMuICBUaGVz ZSBkYXRhIHN0cnVjdHVyZXMNCiAgICAgIGFyZSBub3QgaW50ZW5kZWQgdG8gYmUgaW1wbGVtZW50 ZWQgYXMgcGFydCBvZiBhIGNvbmZpZ3VyYXRpb24NCiAgICAgIGRhdGFzdG9yZSBvciBhcyBvcGVy YXRpb25hbCBzdGF0ZSB3aXRoaW4gdGhlIHNlcnZlciwgc28gbm9ybWFsDQogICAgICBZQU5HIGRh dGEgZGVmaW5pdGlvbiBzdGF0ZW1lbnRzIGNhbm5vdCBiZSB1c2VkLg0KDQogICBvICBZQU5HIGRh dGEgdGVtcGxhdGU6IGEgc2NoZW1hIGZvciBtb2RlbGluZyBwcm90b2NvbCBtZXNzYWdlDQogICAg ICBjb21wb25lbnRzIGFzIGNvbmNlcHR1YWwgZGF0YSBzdHJ1Y3R1cmUgdXNpbmcgWUFORy4gIFRo aXMgYWxsb3dzDQogICAgICB0aGUgbWVzc2FnZXMgdG8gYmUgZGVmaW5lZCBpbiBhbiBlbmNvZGlu Zy1pbmRlcGVuZGVudCBtYW5uZXIuDQogICAgICBFYWNoIFlBTkcgZGF0YSB0ZW1wbGF0ZSBpcyBk ZWZpbmVkIHdpdGggdGhlICJ5YW5nLWRhdGEiIGV4dGVuc2lvbiwNCiAgICAgIGZvdW5kIGluIFNl Y3Rpb24gOC4gIFJlcHJlc2VudGF0aW9ucyBvZiBpbnN0YW5jZXMgY29uZm9ybWluZyB0byBhDQog ICAgICBwYXJ0aWN1bGFyIFlBTkcgZGF0YSB0ZW1wbGF0ZSBjYW4gYmUgZGVmaW5lZCBmb3IgWUFO Ry4gIFRoZSBYTUwNCiAgICAgIHJlcHJlc2VudGF0aW9uIGlzIGRlZmluZWQgaW4gWUFORyB2ZXJz aW9uIDEuMSBbUkZDNzk1MF0sIGFuZA0KICAgICAgc3VwcG9ydGVkIHdpdGggdGhlICJhcHBsaWNh dGlvbi95YW5nLWRhdGEreG1sIiBtZWRpYSB0eXBlLiAgVGhlDQogICAgICBKU09OIHJlcHJlc2Vu dGF0aW9uIGlzIGRlZmluZWQgaW4gSlNPTiBFbmNvZGluZyBvZiBEYXRhIE1vZGVsZWQNCiAgICAg IHdpdGggWUFORyBbUkZDNzk1MV0sIGFuZCBzdXBwb3J0ZWQgd2l0aCB0aGUgImFwcGxpY2F0aW9u Lw0KICAgICAgeWFuZy1kYXRhK2pzb24iIG1lZGlhIHR5cGUuDQoNCg0KVGhpcyBsb29rcyBnb29k IG9uIHRoZSBzdXJmYWNlLCBidXQ6DQoNCiAgMSkgdGhlcmUgc2hvdWxkbuKAmXQgYmUgYSBuZWVk IHRvIHJlZmVyZW5jZSB0aGUgUkVTVENPTkYgUkZDDQoNCiAgMikgc3VjaCBkZWZpbml0aW9ucyBz aG91bGQgYmUgYXZhaWxhYmxlIG91dHNpZGUgUkVTVENPTkYgcHJvdG9jb2wNCiAgICAgb3BlcmF0 aW9ucyAoY3VycmVudGx5IHRoZXkgc2VlbSBib3VuZCB0byB3aGVuIHVzaW5nIHRoZSANCiAgICAg ImFwcGxpY2F0aW9uL3lhbmctZGF0YSt4bWwiIG1lZGlhIHR5cGUpDQoNCiAgMykgSSBkaWRu4oCZ dCBrbm93IHRoYXQgZXh0ZW5zaW9ucyBjYW4gYmUgdXNlZCB0byBkZWZpbmUgaW5zdGFuY2UNCiAg ICAgZGF0YSwgYXMgSeKAmXZlIGFsd2F5cyBvbmx5IHNlZW4gdGhlbSB0byBkZWZpbmUgWUFORyBz dGF0ZW1lbnRzLA0KICAgICB3aXRoIG5vIGluc3RhbmNlIGVuY29kaW5nLiAgSXMgdGhlIOKAnHlh bmctZGF0YSBleHRlbnNpb27igJ0gdGVybQ0KICAgICBhYm92ZSBkZWZpbmluZyB0aGlzIGJlaGF2 aW9yLCBhYm92ZSBhbmQgYmV5b25kIHdoYXTigJlzIHByb3ZpZGVkDQogICAgIGJ5IFJGQyA3OTUw Pw0KDQogIDQpIHRoaXMgc2VlbXMgbGlrZSBhbiBvdmVybHkgY29tcGxpY2F0ZWQgd2F5IHRvIGFj aGlldmUgd2hhdCBJDQogICAgIGJlbGlldmUgc2hvdWxkIGJlIHNpbXBsZSB0aGluZy4NCg0KDQpU aG91Z2h0cz8NCg0KS2VudA0KDQoNCg0K From nobody Fri Jan 13 10:34:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E993C129D44 for ; Fri, 13 Jan 2017 10:34:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VKRn9Ls1UkBq for ; Fri, 13 Jan 2017 10:34:06 -0800 (PST) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5865A129D41 for ; Fri, 13 Jan 2017 10:34:03 -0800 (PST) Received: by mail-qk0-x22f.google.com with SMTP id u25so62821117qki.2 for ; Fri, 13 Jan 2017 10:34:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=KLp6D7KA8oACGwW+QQ4N94+OltnT7vVRXJIBqdZUfgY=; b=EeqlVtQx8d/5IJsGvrZ376gHUWCfi9C/XQ62BQL/jBhkf229pXahdAB0i3Cpu4WQ6c Eh/RgUkWi7iI0VIhAEL5jnY80qA4kQUwikYVzCyf9knrUP9n9n4y/YaQVe7XfRLI0M3u mW4VIOb1MdNbG25DQvWnIL4ELKlyd/Sb7qwdqEJCx7NdFlK3VhUu7t3fe7q3PeU4QUsr +HAW2nkbuwT7araVoN2PHfBxnM2HoHWByoT+Gaxp9I0Sfq1+nWWjHhvSDK8XKXXoNdgh EpplrN0VtYO+64+R8lacA/LjqmFZnjxdMEI0dJJBHrPlB+aiknWF5CilLlxuqY3hCis+ EklA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=KLp6D7KA8oACGwW+QQ4N94+OltnT7vVRXJIBqdZUfgY=; b=XPzh+OAsZnsofe/NKlcdQywlhDTGBmnbjM4QAmmWg1PY3cJWZE10LCgDckJ/+AUjMV vMJ+m41LFyIROpx//huwGrRMekfkAfCpfEqdmQ4m8td9nm9broFbNOJ34Px00uqrhSMs GzHkfp0OWa9k9qXuGfeDqrb2P7vY8Rc8YPJclBG1WO484KzHUVr/sOcJkQNsZjD09xHO /njuf2BKz6KumlYZ3AvZt/DxgOgRPeSg0+qN01JgIf9aBMtvC3NNK/43BCUhyRHq9FVQ n6vRT7SUe8xhQPDE2ZNlfioCEfeqZp3CzLzqXB9lcJIc/ffS58kpRBNpPxK4HE0bI7ul zxjA== X-Gm-Message-State: AIkVDXJEu4o5bgGiYB/EDDYGn6eq33ianfX46hkUSeCFBNH2oEVVyY8HTUpxEpir+hoTtMGObzffZ0O3uJ6TZA== X-Received: by 10.55.7.2 with SMTP id 2mr22519195qkh.228.1484332442419; Fri, 13 Jan 2017 10:34:02 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Fri, 13 Jan 2017 10:34:01 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Fri, 13 Jan 2017 10:34:01 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a114c877cf59aa70545fe1350 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:34:09 -0000 --001a114c877cf59aa70545fe1350 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Jan 13, 2017 at 10:00 AM, Kent Watsen wrote: > > Somewhat answering my own question, but by no means coming to a complete > solution, I realized that RESTCONF does something similar with its > yang-data extension and YANG data template: > > o yang-data extension: A YANG external statement that conforms to > the "yang-data" extension statement found in Section 8. The yang- > data extension is used to define YANG data structures that are > meant to be used as YANG data templates. These data structures > are not intended to be implemented as part of a configuration > datastore or as operational state within the server, so normal > YANG data definition statements cannot be used. > > o YANG data template: a schema for modeling protocol message > components as conceptual data structure using YANG. This allows > the messages to be defined in an encoding-independent manner. > Each YANG data template is defined with the "yang-data" extension, > found in Section 8. Representations of instances conforming to a > particular YANG data template can be defined for YANG. The XML > representation is defined in YANG version 1.1 [RFC7950], and > supported with the "application/yang-data+xml" media type. The > JSON representation is defined in JSON Encoding of Data Modeled > with YANG [RFC7951], and supported with the "application/ > yang-data+json" media type. > > > This looks good on the surface, but: > > 1) there shouldn=E2=80=99t be a need to reference the RESTCONF RFC > > 2) such definitions should be available outside RESTCONF protocol > operations (currently they seem bound to when using the > "application/yang-data+xml" media type) > > 3) I didn=E2=80=99t know that extensions can be used to define instance > data, as I=E2=80=99ve always only seen them to define YANG statement= s, > with no instance encoding. Is the =E2=80=9Cyang-data extension=E2= =80=9D term > above defining this behavior, above and beyond what=E2=80=99s provid= ed > by RFC 7950? > > 4) this seems like an overly complicated way to achieve what I > believe should be simple thing. > > > Thoughts? > > We had a RESTCONF issue on a similar topic https://github.com/netconf-wg/restconf/issues/68 I raised the issue; nobody cared; we didn't change anything; Just reference RESTCONF was the WG consensus. > Kent > Andy > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a114c877cf59aa70545fe1350 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Jan 13, 2017 at 10:00 AM, Kent Watsen <kwatsen@juniper.net> wrote:

Somewhat answering my own question, but by no means coming to a complete so= lution, I realized that RESTCONF does something similar with its yang-data = extension and YANG data template:

=C2=A0 =C2=A0o=C2=A0 yang-data extension: A YANG external statement that co= nforms to
=C2=A0 =C2=A0 =C2=A0 the "yang-data" extension statement found in= Section 8.=C2=A0 The yang-
=C2=A0 =C2=A0 =C2=A0 data extension is used to define YANG data structures = that are
=C2=A0 =C2=A0 =C2=A0 meant to be used as YANG data templates.=C2=A0 These d= ata structures
=C2=A0 =C2=A0 =C2=A0 are not intended to be implemented as part of a config= uration
=C2=A0 =C2=A0 =C2=A0 datastore or as operational state within the server, s= o normal
=C2=A0 =C2=A0 =C2=A0 YANG data definition statements cannot be used.

=C2=A0 =C2=A0o=C2=A0 YANG data template: a schema for modeling protocol mes= sage
=C2=A0 =C2=A0 =C2=A0 components as conceptual data structure using YANG.=C2= =A0 This allows
=C2=A0 =C2=A0 =C2=A0 the messages to be defined in an encoding-independent = manner.
=C2=A0 =C2=A0 =C2=A0 Each YANG data template is defined with the "yang= -data" extension,
=C2=A0 =C2=A0 =C2=A0 found in Section 8.=C2=A0 Representations of instances= conforming to a
=C2=A0 =C2=A0 =C2=A0 particular YANG data template can be defined for YANG.= =C2=A0 The XML
=C2=A0 =C2=A0 =C2=A0 representation is defined in YANG version 1.1 [RFC7950= ], and
=C2=A0 =C2=A0 =C2=A0 supported with the "application/yang-data+xml&quo= t; media type.=C2=A0 The
=C2=A0 =C2=A0 =C2=A0 JSON representation is defined in JSON Encoding of Dat= a Modeled
=C2=A0 =C2=A0 =C2=A0 with YANG [RFC7951], and supported with the "appl= ication/
=C2=A0 =C2=A0 =C2=A0 yang-data+json" media type.


This looks good on the surface, but:

=C2=A0 1) there shouldn=E2=80=99t be a need to reference the RESTCONF RFC
=C2=A0 2) such definitions should be available outside RESTCONF protocol =C2=A0 =C2=A0 =C2=A0operations (currently they seem bound to when using the=
=C2=A0 =C2=A0 =C2=A0"application/yang-data+xml" media type)

=C2=A0 3) I didn=E2=80=99t know that extensions can be used to define insta= nce
=C2=A0 =C2=A0 =C2=A0data, as I=E2=80=99ve always only seen them to define Y= ANG statements,
=C2=A0 =C2=A0 =C2=A0with no instance encoding.=C2=A0 Is the =E2=80=9Cyang-d= ata extension=E2=80=9D term
=C2=A0 =C2=A0 =C2=A0above defining this behavior, above and beyond what=E2= =80=99s provided
=C2=A0 =C2=A0 =C2=A0by RFC 7950?

=C2=A0 4) this seems like an overly complicated way to achieve what I
=C2=A0 =C2=A0 =C2=A0believe should be simple thing.


Thoughts?



We had a RESTCONF issue= on a similar topic
<= div>
I raised the issue; nobody cared; we didn't change a= nything;
Just reference RESTCONF was the WG consensus.
=
=C2=A0
Kent


Andy
=C2= =A0



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

--001a114c877cf59aa70545fe1350-- From nobody Fri Jan 13 10:46:12 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1AD0129D54 for ; Fri, 13 Jan 2017 10:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 FCI-YlESt62g for ; Fri, 13 Jan 2017 10:46:08 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09EED129D53 for ; Fri, 13 Jan 2017 10:46:06 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml704-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CYT09309; Fri, 13 Jan 2017 18:46:04 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml704-cah.china.huawei.com (10.201.5.130) with Microsoft SMTP Server (TLS) id 14.3.301.0; Fri, 13 Jan 2017 18:46:02 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Fri, 13 Jan 2017 10:43:51 -0800 From: Alexander Clemm To: Martin Bjorklund Thread-Topic: [Netconf] nested notifications Thread-Index: AQHSZ6KSFQsAF1aiAU+PjrHFwgk9UKEqeKNAgACZJoCAAIaW4IAAADDwgAFZcoCACGxXgIAATXWAgAAO8ID//5YBgIAAoIuAgAACwoD//3rocIABRh+AgAAUmOA= Date: Fri, 13 Jan 2017 18:43:50 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E3C50FD@dfweml501-mbb> References: <7156728a-278f-4ff5-8289-f0d88e242318@tail-f.com> <20170112.225535.699844646707934283.mbj@tail-f.com> <644DA50AFA8C314EA9BDDAC83BD38A2E3C4E6C@dfweml501-mbb> <20170113.102627.1957757287998651335.mbj@tail-f.com> In-Reply-To: <20170113.102627.1957757287998651335.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.107] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.5879206D.0086, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 251aff3eb5f78038998fdfc04b3e53b5 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] nested notifications X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 18:46:12 -0000 If can have a clause that allows us to updates RFC 7950, clearly designates= as such, that will work. Thanks --- Alex -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Friday, January 13, 2017 1:26 AM To: Alexander Clemm Cc: per@tail-f.com; netconf@ietf.org Subject: Re: [Netconf] nested notifications Alexander Clemm wrote: > Understood, 5277 allows exactly one child element for the notification=20 > element. >=20 > My question is about 7950. Does 7950 mandate that notification nodes=20 > MUST be used/encoded per 5277 - does 5277 by extension become part of=20 > 7950? Or does it merely specify what goes below (the notification=20 > element element in the case of 5277, and perhaps a bulk element or=20 > something else in case a 5277 alternative becomes available? I guess=20 > from your responses it's the former (which I find somewhat limiting -=20 > but I guess we are free to define other encodings for other contexts=20 > beyond Netconf XML...). Maybe a little of both... The section is called "NETCONF XML Encoding Rule= s". So clearly other contexts can have other rules. But when it is time t= o send a notification over NETCONF, clients know how the notification will = be encoded. Now, suppose we obsolete 5277 and define a new = element. In this case we should probably define a paragraph in the new RFC= which "Updates: RFC 7950", with text that exaplains how YANG-defined notif= ications are encoded. /martin > --- Alex >=20 > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Thursday, January 12, 2017 1:56 PM > To: per@tail-f.com > Cc: Alexander Clemm ; netconf@ietf.org > Subject: Re: [Netconf] nested notifications >=20 > Per Hedeland wrote: > > On 2017-01-12 22:34, Alexander Clemm wrote: > > > I agree that it makes sense to allow multiple notifications to be=20 > > > sent in one message. > > >=20 > > > We need to allow for different time stamps, allowing to stamp=20 > > > individual notifications separately. Clearly, compression schemes=20 > > > can be devised, including a trivial compression scheme to apply one "= bulk" > > > timestamp for every notification in the message. > > >=20 > > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it,=20 > > > specifically it is not clear what is really mandated as part of=20 > > > the encoding. The RFC states merely that the notification is=20 > > > encoded as _a_ child XML element to the element. =20 > > > The specification/definition of the element itself=20 > > > is however not part of RFC 7950, neither is the definition of the=20 > > > time stamp (event-time). It seems that all that is specified is=20 > > > the encoding of the event itself, i.e. the representation of the=20 > > > notification identifier and then the parameters contained within it. > >=20 > > It seems that you are reading only the first paragraph of 7.16.2,=20 > > the one that starts with "A notification node that is defined on the=20 > > top level of a module...". Try the second one.:-) >=20 > And also check the XSD in RFC 5277; it allows exactly one child=20 > element for the notification content. >=20 > > > Does RFC 7950 imply that notification nodes can only be encoded as=20 > > > contained in a element as defined in RFC 5277? =20 > > > That would be a considerable limitation and issue at least in the=20 > > > context of Netconf. I guess one could always define other=20 > > > encoding rules outside of Netconf. I don't think defining a bulk=20 > > > notification as a special notification, that itself needs to be=20 > > > carried in a regular notification, is a good solution. The=20 > > > notification element is pure overhead at this point. Allowing the=20 > > > definition of a new bulk notification element, which can be used=20 > > > in lieu of a notification element, would seem a lot more desirable. >=20 > Even in the bulk case you probably want the eventTime for each=20 > individual notification, and if we add more header fields some might=20 > be notification specific. The overhead of the top-level element=20 > 'notification' is minimal in this case. And for the header fields=20 > that apply to all notifications within the bulk, they can nicely be=20 > handled if the bulk thingie is a notification. >=20 >=20 >=20 > /martin >=20 >=20 >=20 > > >=20 > > > --- Alex > > >=20 > > > -----Original Message----- > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of=20 > > > Martin Bjorklund > > > Sent: Thursday, January 12, 2017 10:30 AM > > > To: andy@yumaworks.com > > > Cc: netconf@ietf.org > > > Subject: Re: [Netconf] nested notifications > > >=20 > > > Andy Bierman wrote: > > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund=20 > > >> > > >> wrote: > > >> > > >>> Andy Bierman wrote: > > >>>> On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit)=20 > > >>>> > > >>> wrote: > > >>>> > > >>>>>> From: Andy Bierman, January 5, 2017 9:43 PM > > >>>>>> > > >>>>>> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) > >>>>> evoit@cisco.com> > > >>>>>> wrote: > > >>>>>> Hi Andy, > > >>>>>> > > >>>>>> =1CThe innermost container or list=1D text is similar to that fo= r > > >>> actions in > > >>>>> section > > >>>>>> 7.15.2. Perhaps the mental model of one target for an action w= as > > >>>>> replicated? > > >>>>>> > > >>>>>> I had not considered that YANG 1.1=19s definition might force=20 > > >>>>>> the > > >>> breakup > > >>>>> of a > > >>>>>> verbose software component generated notification into=20 > > >>>>>> multiple > > >>> pushed > > >>>>>> notification messages. Looking at the three cases below, I=20 > > >>>>>> don=19t > > >>> think > > >>>>> that > > >>>>>> arbitrary choices made in YANG model structure should impact=20 > > >>>>>> what > > >>> could > > >>>>> or > > >>>>>> couldn=19t be in encoded within any single notification. So my > > >>> preference > > >>>>> would > > >>>>>> be that all three variants below should supportable if that=20 > > >>>>>> is how > > >>> the > > >>>>> system > > >>>>>> passed them to be encoded as part of an event. > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> I think the WG did not consider these details and assumed=20 > > >>>>>> they were > > >>> the > > >>>>> same > > >>>>>> as for action. > > >>>>>> > > >>>>>> This would be a MAY for the server and a MUST for the client,=20 > > >>>>>> so it > > >>> is > > >>>>> not > > >>>>>> an easy decision. > > >>>>>> > > >>>>>> A couple use-cases I have in mind: > > >>>>>> > > >>>>>> 1) event broker > > >>>>>> subscriber is really a broker that may be=20 > > >>>>>> pre-processing lots > > >>> of > > >>>>>> subscriptions or event types within 1 subscription > > >>>>>> > > >>>>>> 2) digest (time-based push) > > >>>>>> Subscriber wants an update every 5 seconds with all the=20 > > >>>>>> YANG 1.1 > > >>>>> events > > >>>>>> for the previous 5 seconds > > >>>>> > > >>>>> These are both reasonable as controllers are requiring=20 > > >>>>> scalable > > >>> methods of > > >>>>> synching on device status. > > >>>>> > > >>>>>> What if the reinterpretation were as simple as =1CAn innermost= =1D=20 > > >>>>>> or =1CThe > > >>>>> first > > >>>>>> innermost=1D? > > >>>>>> > > >>>>>> This covers case 2. (Change "The" to "An"). > > >>>>>> The client would need to check for YANG 1.1 notifications in=20 > > >>>>>> the same way it checks child nodes already. > > >>>>> > > >>>>> "Any innermost"...? And yes, this is a more significant=20 > > >>>>> change on the client. Beyond this, for use cases (1) & (2),=20 > > >>>>> if you don't want to summarize the eventTime, the time should=20 > > >>>>> be placed with each innermost event. I am not suggesting we=20 > > >>>>> do this, but like Andy I want to figure > > >>> out > > >>>>> what the WG might be willing to consider in scope. > > >>>>> > > >>>>> > > >>>> > > >>>> There was actually a lot of discussion about "eventTime" in the=20 > > >>>> NETCONF > > >>> WG > > >>>> when RFC 5277 was done. > > >>>> Lots of disagreement on what it means. The RFC offers little=20 > > >>>> guidance or hint of the discussion: > > >>>> > > >>>> > > >>>> eventTime: > > >>>> The time the event was generated by the event source. > > >>>> > > >>>> It may take the server some time to detect the event after it occu= rs. > > >>>> It may take some time to save the event for replay and transmissio= n. > > >>>> Which of these 3 different times is it? (Out of scope I think) > > >>>> > > >>>> Adding more timestamps is an interesting idea. > > >>>> > > >>>> But I think something like this could be done without a client MUS= T. > > >>>> The client MAY request 'bulk-encoding' and if the server=20 > > >>>> supports it, a more optimized structure would be sent instead=20 > > >>>> of the normal message. > > >>> > > >>> I prefer this approach, rather than the example in the original=20 > > >>> email. If the bulk-encoded notifications are encoded into a=20 > > >>> normal notification, we don't have to change anything: > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"> > > >>> 2017-01-08T00:01:00Z > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"= > > > >>> 2017-01-08T00:00:00Z > > >>> > > >>> > > >>> > > >>> > >>> xmlns=3D"urn:ietf:params:xml:ns:netconf:notification:1.0"= > > > >>> 2017-01-08T00:00:01Z > > >>> > > >>> > > >>> ... > > >>> > > >>> > > >>> > > >>> > > >> I was hoping for a bulk format that reduced the payload. > > >> Your example actually increases the payload size. > > >=20 > > > For illustration purpose only ;-) > > >=20 > > > It's perfectly fine w/ me if the contents of this "bulk-notification" > > > notif contains a compressed or cleverly encoded list of notifications= . > > >=20 > > > The nice thing with your idea is that it doesn't change the core=20 > > > protocol. > > >=20 > > >=20 > > >=20 > > > /martin > > >=20 > > >=20 > > >> I think the subscription needs some sort of encoding negotiation=20 > > >> like the Accept header in HTTP. > > >> People will eventually think of lots of optimizations that we=20 > > >> never imagined. The protocol should be robust enough to allow=20 > > >> this to happen. e.g., send multiple subscription-id values in > > >> 1 notification instead of duplicating that notification to the=20 > > >> receiver N times. > > >> Another obvious optimization is the ability to group similar=20 > > >> events into a range like link-up for a port-range, representing=20 > > >> the entire line card that was just plugged in. > > >> > > >> > > >> ....no restrictions on what is in the header ... > > >> ... // limit to 1 element for payloa= d? > > >> > > >> > > >> A simple notification is the canonical form. > > >> A notification subscriber acting as a broker will need to convert=20 > > >> the bulk form into 1 or more notifications in canonical format. > > >> > > >> > > >> > > >>> > > >>> /martin > > >>> > > >> > > >> Andy > > >> > > >> > > >>> > > >>> > > >>>> The receiver MAY extract individual messages from the bulk=20 > > >>>> format (maybe > > >>>> binary) > > >>>> into other formats (like XML or JSON). > > >>>> > > >>>> I am trying to plan ahead for when YANG Push turns out to be a=20 > > >>>> slow > > >>> network > > >>>> hog :-) > > >>>> > > >>>> > > >>>> Eric > > >>>>> > > >>>>> > > >>>> Andy > > >>>> > > >>>>> Eric > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> From: Netconf [mailto:mailto:netconf-bounces@ietf.org] On=20 > > >>>>>> Behalf Of > > >>> Andy > > >>>>>> Bierman > > >>>>>> Sent: Thursday, January 5, 2017 5:25 PM > > >>>>>> To: Netconf > > >>>>>> Subject: [Netconf] nested notifications > > >>>>>> > > >>>>>> Hi, > > >>>>>> > > >>>>>> I would like some text in RFC 7950 to be reinterpreted. The=20 > > >>>>>> text > > >>> implies > > >>>>> each > > >>>>>> notification message can only describe 1 instance of 1 event typ= e. > > >>>>>> > > >>>>>> RFC 7950, sec 7.16.2 > > >>>>>> > > >>>>>> The innermost container or list contains an XML > > >>>>>> element that carries the name of the defined notification. > > >>>>>> > > >>>>>> > > >>>>>> There are 3 corner-cases that should be considered in order=20 > > >>>>>> to minimize network overhead for notifications in 5277bis. > > >>>>>> Replicating the node/key hierarchy could be expensive and=20 > > >>>>>> events occurring at the same time could be correlated. > > >>>>>> > > >>>>>> Duplicating the notification messages is inefficient, but=20 > > >>>>>> processing multiple events per message makes filtering and=20 > > >>>>>> parsing more complicated. > > >>>>>> > > >>>>>> I am curious if the WG thinks notification overhead is a=20 > > >>>>>> concern and if it needs to be addressed somehow in 5277bis. > > >>>>>> > > >>>>>> > > >>>>>> 1) multiple non-sibling events in same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 2) multiple sibling events in the same subtree > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> admin > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 3) multiple non-sibling events in different subtrees > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> 42 > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> eth0 > > >>>>>> > > >>>>>> auto > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> > > >>>>>> Andy > > >>>>>> > > >>>>>> > > >>>>> > > >>>>> > > >>> > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > >=20 > >=20 >=20 From nobody Fri Jan 13 11:41:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0D991129DA0 for ; Fri, 13 Jan 2017 11:41:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 eMDceUszBWis for ; Fri, 13 Jan 2017 11:41:48 -0800 (PST) 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 367AA129CE7 for ; Fri, 13 Jan 2017 11:41:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B56838F7; Fri, 13 Jan 2017 20:41:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id dEH5mFHd5aEH; Fri, 13 Jan 2017 20:41:42 +0100 (CET) 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, 13 Jan 2017 20:41:46 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3E8B92009D; Fri, 13 Jan 2017 20:41:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KT23s59RCLvA; Fri, 13 Jan 2017 20:41:45 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8EB020090; Fri, 13 Jan 2017 20:41:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 3A7F53E20CC8; Fri, 13 Jan 2017 20:41:48 +0100 (CET) Date: Fri, 13 Jan 2017 20:41:48 +0100 From: Juergen Schoenwaelder To: Andy Bierman Message-ID: <20170113194148.GB24768@elstar.local> Mail-Followup-To: Andy Bierman , Kent Watsen , "netconf@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jan 2017 19:41:51 -0000 On Fri, Jan 13, 2017 at 10:34:01AM -0800, Andy Bierman wrote: > On Fri, Jan 13, 2017 at 10:00 AM, Kent Watsen wrote: > > > > > Somewhat answering my own question, but by no means coming to a complete > > solution, I realized that RESTCONF does something similar with its > > yang-data extension and YANG data template: > > [...] > > > > This looks good on the surface, but: > > > > 1) there shouldn’t be a need to reference the RESTCONF RFC > > > > 2) such definitions should be available outside RESTCONF protocol > > operations (currently they seem bound to when using the > > "application/yang-data+xml" media type) > > > > 3) I didn’t know that extensions can be used to define instance > > data, as I’ve always only seen them to define YANG statements, > > with no instance encoding. Is the “yang-data extension†term > > above defining this behavior, above and beyond what’s provided > > by RFC 7950? > > > > 4) this seems like an overly complicated way to achieve what I > > believe should be simple thing. > > > > > > Thoughts? > > > > > > We had a RESTCONF issue on a similar topic > https://github.com/netconf-wg/restconf/issues/68 > > I raised the issue; nobody cared; we didn't change anything; > Just reference RESTCONF was the WG consensus. > And hopefully some future version of YANG provides proper support for this (and specifications that use the RESTCONF workaround can ideally eventually retire this dependency on RESTCONF in the future). /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 Jan 16 04:35:18 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3E44612943E for ; Mon, 16 Jan 2017 04:35:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=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 MtC8xLX-DMgm for ; Mon, 16 Jan 2017 04:35:15 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 3A331129406 for ; Mon, 16 Jan 2017 04:35:14 -0800 (PST) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id E8E6E1CC0282; Mon, 16 Jan 2017 13:35:13 +0100 (CET) From: Ladislav Lhotka To: Kent Watsen , "netconf\@ietf.org" In-Reply-To: References: Date: Mon, 16 Jan 2017 13:35:12 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 12:35:17 -0000 Kent Watsen writes: > Somewhat answering my own question, but by no means coming to a complete = solution, I realized that RESTCONF does something similar with its yang-dat= a extension and YANG data template: > > o yang-data extension: A YANG external statement that conforms to > the "yang-data" extension statement found in Section 8. The yang- > data extension is used to define YANG data structures that are > meant to be used as YANG data templates. These data structures > are not intended to be implemented as part of a configuration > datastore or as operational state within the server, so normal > YANG data definition statements cannot be used. > > o YANG data template: a schema for modeling protocol message > components as conceptual data structure using YANG. This allows > the messages to be defined in an encoding-independent manner. > Each YANG data template is defined with the "yang-data" extension, > found in Section 8. Representations of instances conforming to a > particular YANG data template can be defined for YANG. The XML > representation is defined in YANG version 1.1 [RFC7950], and > supported with the "application/yang-data+xml" media type. The > JSON representation is defined in JSON Encoding of Data Modeled > with YANG [RFC7951], and supported with the "application/ > yang-data+json" media type. > > > This looks good on the surface, but: > > 1) there shouldn=E2=80=99t be a need to reference the RESTCONF RFC > > 2) such definitions should be available outside RESTCONF protocol > operations (currently they seem bound to when using the=20 > "application/yang-data+xml" media type) > > 3) I didn=E2=80=99t know that extensions can be used to define instance > data, as I=E2=80=99ve always only seen them to define YANG statement= s, > with no instance encoding. Is the =E2=80=9Cyang-data extension=E2= =80=9D term > above defining this behavior, above and beyond what=E2=80=99s provid= ed > by RFC 7950? > > 4) this seems like an overly complicated way to achieve what I > believe should be simple thing. This would be another merit of my proposal to remove any dependencies on datastores and protocol(s) from YANG spec: it should only deal with deciding whether a given data tree is valid (perhaps for several levels of validity, e.g. grammar + datatypes, semantic rules, references). The notion of a (conceptual) data tree is already implicitly present in most of the 7950 text, and everything else can IMO be specified in other documents. If we don't do this, then I believe we will see YANG being "misused" again and again as in your examples. This just undermines the value of the YANG standard. Lada > > > Thoughts? > > Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=20 Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Mon Jan 16 05:14:11 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C54DC129476 for ; Mon, 16 Jan 2017 05:14:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 V-MnuhjfdILh for ; Mon, 16 Jan 2017 05:14:09 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 62C57129431 for ; Mon, 16 Jan 2017 05:14:09 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 345111AE018A; Mon, 16 Jan 2017 14:14:07 +0100 (CET) Date: Mon, 16 Jan 2017 14:14:05 +0100 (CET) Message-Id: <20170116.141405.521276088073036158.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Jan 2017 13:14:11 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiANCj4gU29tZXdoYXQg YW5zd2VyaW5nIG15IG93biBxdWVzdGlvbiwgYnV0IGJ5IG5vIG1lYW5zIGNvbWluZyB0byBhIGNv bXBsZXRlIHNvbHV0aW9uLCBJIHJlYWxpemVkIHRoYXQgUkVTVENPTkYgZG9lcyBzb21ldGhpbmcg c2ltaWxhciB3aXRoIGl0cyB5YW5nLWRhdGEgZXh0ZW5zaW9uIGFuZCBZQU5HIGRhdGEgdGVtcGxh dGU6DQo+IA0KPiAgICBvICB5YW5nLWRhdGEgZXh0ZW5zaW9uOiBBIFlBTkcgZXh0ZXJuYWwgc3Rh dGVtZW50IHRoYXQgY29uZm9ybXMgdG8NCj4gICAgICAgdGhlICJ5YW5nLWRhdGEiIGV4dGVuc2lv biBzdGF0ZW1lbnQgZm91bmQgaW4gU2VjdGlvbiA4LiAgVGhlIHlhbmctDQo+ICAgICAgIGRhdGEg ZXh0ZW5zaW9uIGlzIHVzZWQgdG8gZGVmaW5lIFlBTkcgZGF0YSBzdHJ1Y3R1cmVzIHRoYXQgYXJl DQo+ICAgICAgIG1lYW50IHRvIGJlIHVzZWQgYXMgWUFORyBkYXRhIHRlbXBsYXRlcy4gIFRoZXNl IGRhdGEgc3RydWN0dXJlcw0KPiAgICAgICBhcmUgbm90IGludGVuZGVkIHRvIGJlIGltcGxlbWVu dGVkIGFzIHBhcnQgb2YgYSBjb25maWd1cmF0aW9uDQo+ICAgICAgIGRhdGFzdG9yZSBvciBhcyBv cGVyYXRpb25hbCBzdGF0ZSB3aXRoaW4gdGhlIHNlcnZlciwgc28gbm9ybWFsDQo+ICAgICAgIFlB TkcgZGF0YSBkZWZpbml0aW9uIHN0YXRlbWVudHMgY2Fubm90IGJlIHVzZWQuDQo+IA0KPiAgICBv ICBZQU5HIGRhdGEgdGVtcGxhdGU6IGEgc2NoZW1hIGZvciBtb2RlbGluZyBwcm90b2NvbCBtZXNz YWdlDQo+ICAgICAgIGNvbXBvbmVudHMgYXMgY29uY2VwdHVhbCBkYXRhIHN0cnVjdHVyZSB1c2lu ZyBZQU5HLiAgVGhpcyBhbGxvd3MNCj4gICAgICAgdGhlIG1lc3NhZ2VzIHRvIGJlIGRlZmluZWQg aW4gYW4gZW5jb2RpbmctaW5kZXBlbmRlbnQgbWFubmVyLg0KPiAgICAgICBFYWNoIFlBTkcgZGF0 YSB0ZW1wbGF0ZSBpcyBkZWZpbmVkIHdpdGggdGhlICJ5YW5nLWRhdGEiIGV4dGVuc2lvbiwNCj4g ICAgICAgZm91bmQgaW4gU2VjdGlvbiA4LiAgUmVwcmVzZW50YXRpb25zIG9mIGluc3RhbmNlcyBj b25mb3JtaW5nIHRvIGENCj4gICAgICAgcGFydGljdWxhciBZQU5HIGRhdGEgdGVtcGxhdGUgY2Fu IGJlIGRlZmluZWQgZm9yIFlBTkcuICBUaGUgWE1MDQo+ICAgICAgIHJlcHJlc2VudGF0aW9uIGlz IGRlZmluZWQgaW4gWUFORyB2ZXJzaW9uIDEuMSBbUkZDNzk1MF0sIGFuZA0KPiAgICAgICBzdXBw b3J0ZWQgd2l0aCB0aGUgImFwcGxpY2F0aW9uL3lhbmctZGF0YSt4bWwiIG1lZGlhIHR5cGUuICBU aGUNCj4gICAgICAgSlNPTiByZXByZXNlbnRhdGlvbiBpcyBkZWZpbmVkIGluIEpTT04gRW5jb2Rp bmcgb2YgRGF0YSBNb2RlbGVkDQo+ICAgICAgIHdpdGggWUFORyBbUkZDNzk1MV0sIGFuZCBzdXBw b3J0ZWQgd2l0aCB0aGUgImFwcGxpY2F0aW9uLw0KPiAgICAgICB5YW5nLWRhdGEranNvbiIgbWVk aWEgdHlwZS4NCj4gDQo+IA0KPiBUaGlzIGxvb2tzIGdvb2Qgb24gdGhlIHN1cmZhY2UsIGJ1dDoN Cj4gDQo+ICAgMSkgdGhlcmUgc2hvdWxkbuKAmXQgYmUgYSBuZWVkIHRvIHJlZmVyZW5jZSB0aGUg UkVTVENPTkYgUkZDDQo+IA0KPiAgIDIpIHN1Y2ggZGVmaW5pdGlvbnMgc2hvdWxkIGJlIGF2YWls YWJsZSBvdXRzaWRlIFJFU1RDT05GIHByb3RvY29sDQo+ICAgICAgb3BlcmF0aW9ucyAoY3VycmVu dGx5IHRoZXkgc2VlbSBib3VuZCB0byB3aGVuIHVzaW5nIHRoZSANCj4gICAgICAiYXBwbGljYXRp b24veWFuZy1kYXRhK3htbCIgbWVkaWEgdHlwZSkNCj4gDQo+ICAgMykgSSBkaWRu4oCZdCBrbm93 IHRoYXQgZXh0ZW5zaW9ucyBjYW4gYmUgdXNlZCB0byBkZWZpbmUgaW5zdGFuY2UNCj4gICAgICBk YXRhDQoNCkknbSBub3Qgc3VyZSBJIHVuZGVyc3RhbmQgd2hhdCB5b3UgbWVhbi4gIFRoZSAieWFu Zy1kYXRhIiBleHRlbnNpb24NCmRvZXNuJ3QgZGVmaW5lIGluc3RhbmNlIGRhdGEuICBJdCBkZWZp bmVzIHRoZSAqc2NoZW1hKiBmb3IgaW5zdGFuY2UNCmRhdGEuDQoNCg0KPiAsIGFzIEnigJl2ZSBh bHdheXMgb25seSBzZWVuIHRoZW0gdG8gZGVmaW5lIFlBTkcgc3RhdGVtZW50cywNCj4gICAgICB3 aXRoIG5vIGluc3RhbmNlIGVuY29kaW5nLg0KDQpUaGVyZSBpcyBub3RoaW5nIGluIFJGQyA3OTUw IHRoYXQgd291bGQgbWFrZSB0aGlzIGlsbGVnYWwuDQoNCj4gSXMgdGhlIOKAnHlhbmctZGF0YSBl eHRlbnNpb27igJ0gdGVybQ0KPiAgICAgIGFib3ZlIGRlZmluaW5nIHRoaXMgYmVoYXZpb3IsIGFi b3ZlIGFuZCBiZXlvbmQgd2hhdOKAmXMgcHJvdmlkZWQNCj4gICAgICBieSBSRkMgNzk1MD8NCj4g DQo+ICAgNCkgdGhpcyBzZWVtcyBsaWtlIGFuIG92ZXJseSBjb21wbGljYXRlZCB3YXkgdG8gYWNo aWV2ZSB3aGF0IEkNCj4gICAgICBiZWxpZXZlIHNob3VsZCBiZSBzaW1wbGUgdGhpbmcuDQoNClll cywgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIG5ldyBjb3JlIHN0YXRlbWVudCAic3RydWN0dXJlIiBv ciBzb21ldGhpbmcNCnNpbWlsYXIsIHdoaWNoIGNvdWxkIGJlIHVzZWQgdG8gZGVmaW5lIHRoZSBz Y2hlbWEgZm9yIGluc3RhbmNlcyB0aGF0DQphcmUgbm90IHRpZWQgdG8gYW55IGRhdGFzdG9yZXMs IG9wZXJhdGlvbnMsIG9yIG5vdGlmaWNhdGlvbnMuICBUaGUNCnNlbWFudGljcyBvZiB0aGVzZSBz dHJ1Y3R1cmVzIG11c3QgYmUgZGVmaW5lZCBpbiB0aGUgZGVzY3JpcHRpb24NCnN0YXRlbWVudC4g IFRoZSBjb3JlIHN0YXRlbWVudCAiYXVnbWVudCIgc2hvdWxkIGJlIGV4dGVuZGVkIHNvIHRoYXQg aXQNCmNhbiBiZSB1c2VkIHRvIGF1Z21lbnQgc3VjaCBzdHJ1Y3R1cmVzLg0KDQpCdXQgdGhpcyBy ZXF1aXJlcyBhIG5ldyB2ZXJzaW9uIG9mIFlBTkcuDQoNCg0KL21hcnRpbg0K From nobody Tue Jan 17 12:24:52 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E480129480 for ; Tue, 17 Jan 2017 12:24:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1wM3SHBxTvTB for ; Tue, 17 Jan 2017 12:24:50 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0101.outbound.protection.outlook.com [104.47.37.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A417812946E for ; Tue, 17 Jan 2017 12:24:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Re2Koq2ehx7QiT7BuxeXn3q+WcZwibN5KHpRmIXth0E=; b=HkoJLi+nNwLMvNMpXj77WD0jIIf0b8BtzqA+Uboqsr1FqcF6diyYEEnRI5hUGT52ai4+kBeja/+Mum16SqCMWx3L6MxM4xYMVD7tbVLYtKYdUxrYX/VXZfDhOIZurjqzYnvKGAvyLWD/kE910t4H1E484D4L7V7FgwEw5kSCQpY= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 20:24:48 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Tue, 17 Jan 2017 20:24:48 +0000 From: Kent Watsen To: Martin Bjorklund Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22AA= Date: Tue, 17 Jan 2017 20:24:47 +0000 Message-ID: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> References: <20170116.141405.521276088073036158.mbj@tail-f.com> In-Reply-To: <20170116.141405.521276088073036158.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 39bde30d-db6e-4ad6-1748-08d43f16e210 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:r2pFThoHW4Fjbu1NXLm/2+4nURW24T34ffKtplSB1tICb4Xa7ykIUcGIn9uwXTeVAOjqdeLKFUK0h2hPtXurDn2VIEmjy6nT0vWDzQiNbK9t5Yd3uWM2HOQ+BDe4bDV8qWI8lf/Hy5lJ0jUln09D/XyZFxQxuYDZ7P7btuHAmnOdu3kSmqxo9OBd2vGrIjPkXND1UHvX3yWTwTTMei/tlpgs/dBw+lWlz1wnZ9pbHf52/lq3Bzej7vsE/fj0dnvr0CxE2znSaJOR4sxcnooiZz75QEau80fiq7HdsVC1kbwHIo/X79WquScCfJ2qRKCRBsLeRapAxl+h4DZDBasW38GenmiQ/wLHMdZ/WO3z1SE4TqDpVRwabVdVwE/VdgbSsr0C+DOg0YqVjg5L+abd68VZGh0ARn2Hp1yVjco74ivpPkESFCeIj035SeJ2IVVt+GLJkaVCXdcp+rKe0X9cng== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(189002)(199003)(83506001)(3280700002)(68736007)(5660300001)(305945005)(3660700001)(33656002)(25786008)(83716003)(77096006)(7736002)(6486002)(6306002)(53936002)(50986999)(66066001)(99286003)(36756003)(229853002)(86362001)(110136003)(106116001)(106356001)(105586002)(92566002)(2906002)(97736004)(189998001)(82746002)(101416001)(8936002)(38730400001)(4326007)(2950100002)(6916009)(3846002)(8676002)(76176999)(6116002)(6436002)(102836003)(122556002)(54356999)(81156014)(2900100001)(4001350100001)(81166006)(6506006)(6512007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <06B95E070FA88E4993875C8E9FE137AB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 20:24:47.8529 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 20:24:51 -0000 DQo+IFllcywgSSB3b3VsZCBsaWtlIHRvIHNlZSBhIG5ldyBjb3JlIHN0YXRlbWVudCAic3RydWN0 dXJlIiBvciANCj4gc29tZXRoaW5nIHNpbWlsYXIsIHdoaWNoIGNvdWxkIGJlIHVzZWQgdG8gZGVm aW5lIHRoZSBzY2hlbWEgDQo+IGZvciBpbnN0YW5jZXMgdGhhdCBhcmUgbm90IHRpZWQgdG8gYW55 IGRhdGFzdG9yZXMsIG9wZXJhdGlvbnMsDQo+IG9yIG5vdGlmaWNhdGlvbnMuICBUaGUgc2VtYW50 aWNzIG9mIHRoZXNlIHN0cnVjdHVyZXMgbXVzdCBiZQ0KPiBkZWZpbmVkIGluIHRoZSBkZXNjcmlw dGlvbiBzdGF0ZW1lbnQuICBUaGUgY29yZSBzdGF0ZW1lbnQgDQo+ICJhdWdtZW50IiBzaG91bGQg YmUgZXh0ZW5kZWQgc28gdGhhdCBpdCBjYW4gYmUgdXNlZCB0byBhdWdtZW50DQo+IHN1Y2ggc3Ry dWN0dXJlcy4NCg0KSeKAmW0gbm90IHN1cmUgaWYgYSBjb3JlIHN0YXRlbWVudCBpcyBiZXN0LCBi dXQgdGhpcyBjYW4gYmUgaGFzaGVkDQpvdXQgbGF0ZXIuLi4NCg0KDQo+IEJ1dCB0aGlzIHJlcXVp cmVzIGEgbmV3IHZlcnNpb24gb2YgWUFORy4NCg0KSW5kZWVkLCBhbmQgdGh1cyBJIGp1c3QgYWRk ZWQgYW4gZW50cnkgZm9yIFlBTkctbmV4dDoNCiAgaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13 Zy95YW5nLW5leHQvaXNzdWVzLzgNCg0KDQpCdXQgdGhlIHplcm90b3VjaCBkcmFmdCBjYW7igJl0 IHdhaXQgdGhhdCBsb25nLCB3aGF0IHNob3VsZCBpdCANCmRvIGluIHRoZSBtZWFud2hpbGU/ICAg V291bGQgaXQgYmUgYWNjZXB0YWJsZSB0byBzdGF0ZSBpbiB0aGUNCmRyYWZ0IGFuZCBhbHNvIGlu IHRoZSBZQU5HIG1vZHVsZSBpdHNlbGYgdGhhdCB0aGUgWUFORyBtb2R1bGUNCk1VU1QgTk9UIGV2 ZXIgYmUgaW1wbGVtZW50ZWQgYnkgYSBOQy9SQyBzZXJ2ZXI/DQoNCg0KVGhhbmtzLA0KS2VudA0K DQoNCg0K From nobody Tue Jan 17 13:50:31 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 767BF129495 for ; Tue, 17 Jan 2017 13:50:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o0gsrZWkVbHs for ; Tue, 17 Jan 2017 13:50:29 -0800 (PST) Received: from mail-qt0-x22a.google.com (mail-qt0-x22a.google.com [IPv6:2607:f8b0:400d:c0d::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E98FF1295CB for ; Tue, 17 Jan 2017 13:50:28 -0800 (PST) Received: by mail-qt0-x22a.google.com with SMTP id k15so182581504qtg.3 for ; Tue, 17 Jan 2017 13:50:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xvK7f7hDuPJvoszpnKe4oddqH3WEE9nCGg+nyCUdU84=; b=qUh3Zpn49ZQ+ZoOEc/ECq3O+z0YpWcuT3gLdr0S7tJsdJAInPEMJxii1Gi8SPiWOMP 13C3lwdN7X8GuQYec2PGJIHfaEuJGQdMhM702dC5ncMO4BWO5SwKbsH/JsFQ8Ou6DDZs ssXVpt0Dslm1YOwwT7WfaHRXHqaYUbKp7tfhHRbs8gBWkxLkUXmAE9Y409bCvAuO91/5 bR5CjKqifswCiFNwfwVDwMsYQuZyR9OKvB2jWJPZF7SrBnaSIHGwOv1yRf99CIKFrpWZ F1q2ZRNun+1IrI0JC/M2vlxT4I4sweJ7MYqMPq3qsTCkYq7YQ/y/RyENPpbyyuQapZfv zHbA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xvK7f7hDuPJvoszpnKe4oddqH3WEE9nCGg+nyCUdU84=; b=OKW1iE6s+md+o45a4yKAVZU3UWQJEtYSJ8NK6phmPeNAAwHs2K6fprsV3BrI2fZNho ya8t031Gzt5yzD/YaPhl2fG7dSLELQkRih6Gr7uyj13PmFHTmIHbASqkWQHtXTgaBKhI NJa6MthVhRdEo829v4txS0cVazCTfE1XHeGwx4Y6WcDTZEKOa3rxWnI9XbjnXOjcZjmk EzdqEzifTmLqeehghpmXWwjeyp28ALUkmEA6It+C1smGBhVLAcrNAyWAHkJ3LlIa59jN FZzUsotgLARfpNFQ29f6XeUdA6eTlXn9huxsmcQ1KcDSZQeXhYF1sOR1WKyLBS0N0CR1 63Bg== X-Gm-Message-State: AIkVDXKPZ/d3a/QmTmkAWVC6sczpZ26yD5StPyfZPqhpwsiPnkcejbCe+vspA/7GGb0ANwmyEt4LUzH46xwmOA== X-Received: by 10.237.59.203 with SMTP id s11mr38367177qte.46.1484689828052; Tue, 17 Jan 2017 13:50:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 17 Jan 2017 13:50:27 -0800 (PST) In-Reply-To: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> References: <20170116.141405.521276088073036158.mbj@tail-f.com> <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> From: Andy Bierman Date: Tue, 17 Jan 2017 13:50:27 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=94eb2c1907accd969b0546514954 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 21:50:30 -0000 --94eb2c1907accd969b0546514954 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 17, 2017 at 12:24 PM, Kent Watsen wrote: > > > Yes, I would like to see a new core statement "structure" or > > something similar, which could be used to define the schema > > for instances that are not tied to any datastores, operations, > > or notifications. The semantics of these structures must be > > defined in the description statement. The core statement > > "augment" should be extended so that it can be used to augment > > such structures. > > I=E2=80=99m not sure if a core statement is best, but this can be hashed > out later... > > > > But this requires a new version of YANG. > > Indeed, and thus I just added an entry for YANG-next: > https://github.com/netmod-wg/yang-next/issues/8 > > > But the zerotouch draft can=E2=80=99t wait that long, what should it > do in the meanwhile? Would it be acceptable to state in the > draft and also in the YANG module itself that the YANG module > MUST NOT ever be implemented by a NC/RC server? > > The term MUST NOT has requirements for use which are not met here. IMO it is sufficient to say the module is not intended for implementation in a NC/RC server. If the data-structure extension is used then the module looks empty to a NC/RC server so not sure why this is even an issue. > > Thanks, > Kent > > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --94eb2c1907accd969b0546514954 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 17, 2017 at 12:24 PM, Kent Watsen <kwatsen@juniper.net> wrote:

> Yes, I would like to see a new core statement "structure" or=
> something similar, which could be used to define the schema
> for instances that are not tied to any datastores, operations,
> or notifications.=C2=A0 The semantics of these structures must be
> defined in the description statement.=C2=A0 The core statement
> "augment" should be extended so that it can be used to augme= nt
> such structures.

I=E2=80=99m not sure if a core statement is best, but this can be hashed out later...

=C2=A0
> But this requires a new version of YANG.

Indeed, and thus I just added an entry for YANG-next:
=C2=A0 https://github.com/netmod-wg/yang-next/is= sues/8


But the zerotouch draft can=E2=80=99t wait that long, what should it
do in the meanwhile?=C2=A0 =C2=A0Would it be acceptable to state in the
draft and also in the YANG module itself that the YANG module
MUST NOT ever be implemented by a NC/RC server?



The term MUST NOT has r= equirements for use which are not met here.
IMO it is sufficient = to say the module is not intended for implementation
in a NC/RC s= erver.

If the data-structure extension is used the= n the module looks empty to a NC/RC server
so not sure why this i= s even an issue.

=C2=A0

Thanks,
Kent




Andy

=C2=A0

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

--94eb2c1907accd969b0546514954-- From nobody Tue Jan 17 15:01:11 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2CC41295D4 for ; Tue, 17 Jan 2017 15:01:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nbYqjG0txLfo for ; Tue, 17 Jan 2017 15:01:08 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0129.outbound.protection.outlook.com [104.47.40.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3438B1295E3 for ; Tue, 17 Jan 2017 15:01:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=qu2yTWwixBY2eB0xmud+z6Su6opKh5bttCV0VdUB/Cg=; b=Rkf858QiQFP8bQwovxvmP4FxWWOclj3zvMgnLJqmD3oAwOMOyyx6p/87Tm4nlBXbmrpfhM8h/yEZbtLQyOTsqbfF5JhvjjSC7eGLHhkavwJJauStZM080gukom7FO4kJDbat1/IyBHba1mc7PzNwCCju7CkO2m619tNlwR3ohdU= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Tue, 17 Jan 2017 23:01:06 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Tue, 17 Jan 2017 23:01:06 +0000 From: Kent Watsen To: Andy Bierman Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22ACAAGvCgP//v+qA Date: Tue, 17 Jan 2017 23:01:06 +0000 Message-ID: References: <20170116.141405.521276088073036158.mbj@tail-f.com> <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 0d5ef5be-045c-4d21-59b6-08d43f2cb805 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:n+FdzkWMD0RtvpQrvmUPnLSTmYT5erVMWuZSk/1cPPVXvgobk/7j6lWaxUljfcW8z67Wd9aME2k78KjLHstwhrhwt73Kc/AQYKnN/zfUvVLSYoQ9SyXrAqLhLQf6m0rcRn5W218QgSMHMfkzk2oFzPuDFc8bizBneFXLNCS0QXPtWl7zSdLM0oc72bgAOEjG+fOkH+AAmakHSREDWEwLqnPo6DTPO8WiKLpgSXHM1WVgn2qTUMbCO7D+FIVMK26Q8e+wpJvgYrF6iE347MGc6izXHsC02xVpt/bl0wwOy1ZJBNPF3BFGFmmTKhJYujRUOzBjCFcx5y3ZIDsDD7rEpzzr5KJQGrTaYEUbKft3cIYnONUnKoiN6w0QhHBrgN8eF3cpCG36DdfQoTwDq5jaPq7kOMT+s+MIIxNhkHk7o+o2hSiz5IHZ4IezRGdTFtwrHxTod1Oo6DoFutpboSxuuA== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01901B3451 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39840400002)(39860400002)(39410400002)(39850400002)(199003)(24454002)(377454003)(189002)(53936002)(36756003)(92566002)(4326007)(93886004)(4001350100001)(2906002)(99286003)(54906002)(2900100001)(77096006)(81166006)(6436002)(6486002)(25786008)(81156014)(82746002)(229853002)(122556002)(38730400001)(66066001)(8936002)(97736004)(6506006)(189998001)(83506001)(68736007)(105586002)(106356001)(305945005)(110136003)(5660300001)(3280700002)(83716003)(101416001)(106116001)(2950100002)(6916009)(8676002)(33656002)(50986999)(7736002)(102836003)(3846002)(6512007)(76176999)(6116002)(86362001)(3660700001)(54356999)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Jan 2017 23:01:06.3821 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:01:10 -0000 DQoNCk9uIDEvMTcvMTcsIDQ6NTAgUE0sICJBbmR5IEJpZXJtYW4iIDxhbmR5QHl1bWF3b3Jrcy5j b20+IHdyb3RlOg0KDQoNCj4gVGhlIHRlcm0gTVVTVCBOT1QgaGFzIHJlcXVpcmVtZW50cyBmb3Ig dXNlIHdoaWNoIGFyZSBub3QgbWV0IA0KPiBoZXJlLiBJTU8gaXQgaXMgc3VmZmljaWVudCB0byBz YXkgdGhlIG1vZHVsZSBpcyBub3QgaW50ZW5kZWQNCj4gZm9yIGltcGxlbWVudGF0aW9uIGluIGEg TkMvUkMgc2VydmVyLg0KDQpPa2F5DQoNCg0KPiBJZiB0aGUgZGF0YS1zdHJ1Y3R1cmUgZXh0ZW5z aW9uIGlzIHVzZWQgdGhlbiB0aGUgbW9kdWxlIGxvb2tzDQo+IGVtcHR5IHRvIGEgTkMvUkMgc2Vy dmVyIHNvIG5vdCBzdXJlIHdoeSB0aGlzIGlzIGV2ZW4gYW4gaXNzdWUuDQoNCkJlY2F1c2UgdGhl IGRhdGEtc3RydWN0dXJlIGV4dGVuc2lvbiAoYXNzdW1pbmcgd2UgZmluYWxpemUgb24NCnRoYXQp IGRvZXNu4oCZdCBleGlzdCB5ZXQsIHNvIEkgbmVlZCAoSSBndWVzcykgYW4gaW50ZXJpbSBzb2x1 dGlvbi4NCg0KQW5vdGhlciBvcHRpb24gaXMgdG8g4oCccXVpY2tseeKAnSBydW4gYSBkcmFmdCB0 aHJvdWdoIHRoZSBORVRNT0QgV0cNCnRvIOKAnHVwZGF0ZeKAnSBSRkMgNzk1MC4gIFdlIGNvdWxk IHRyeSwgYnV0IG5vIG1hdHRlciBob3cgZmFzdCB3ZSBnbywNCml0IHdvdWxkIHN1cmVseSBkZWxh eSB0aGUgemVyb3RvdWNoIHNvbWUuLi4NCg0KS2VudA0KDQoNCg0KDQoNCg0KDQo= From nobody Tue Jan 17 15:06:18 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55ED71295D4 for ; Tue, 17 Jan 2017 15:06:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q_MiLpMdGi9C for ; Tue, 17 Jan 2017 15:06:15 -0800 (PST) Received: from mail-wm0-x22c.google.com (mail-wm0-x22c.google.com [IPv6:2a00:1450:400c:c09::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 95B7D1295DF for ; Tue, 17 Jan 2017 15:06:14 -0800 (PST) Received: by mail-wm0-x22c.google.com with SMTP id c206so247568470wme.0 for ; Tue, 17 Jan 2017 15:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version:thread-index :content-language:disposition-notification-to; bh=iDuta49WUAqvviCIWfnNT6MQdyqLVnkadYOGdSr7SFg=; b=HyWH7MTH6krUeoZiLT1IyFLzjb3ycYCwOLwy3iiDk6FIALccPVG9VpqPIJFrYYH2vO YOP377Rtw6poN/xcbcwdFGIt0xWUALW1VUpcvBzxnQJyzYxhAK35he4Pcu49ui5sJPTn hocMViUO8eTBpK0iao24BBzetPnIs3qJZ2RLGKJkZ8KHhNp6dbdvw/5ddi3qb6OLqwhq gobgKmtsZd8RJajwaevj1w/EaDEX+JKw+/CZL+6woDNqyimQuq1hhwDsr6IEB+DExQL2 aKiDKTg1MAfog7xv5A/JLXNbl/Q89Xf39zdE1Uh+U+Sq9cNFNISyM9lO7FpmXboYRV12 rjbw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :thread-index:content-language:disposition-notification-to; bh=iDuta49WUAqvviCIWfnNT6MQdyqLVnkadYOGdSr7SFg=; b=s2bmbo8AgyrYOSxTb/DmyWj3St8rcuoaB+bsyVXG6KR827e/ij5h7EsDsWmQ7keH5L 5Yx3UCUmfd4Rd+4OChuK/hLyM5zLDqpqfAbuSCzd5/G+XjUGrZ1m0TdlGzGZsw+BLN25 Yor0DNlPMB2ENaksyEjduQjOfbZCNiQOLjckATroHVsJ3NySuDh1u1XSv5ZwY4wcPsvj C0ZT9aBkF5XvTu5M0p8w8ofD8WbeEzaUl9b6z6Lw4Zec5G77cQwHIyuJp9rQPX6+P6sX XCl5d1qT23cmxNUW2b8UDUuN+QeO/7ajWN4fdyKarACYwcZ18qiTkuIPneujkjIQBc/S shzA== X-Gm-Message-State: AIkVDXI7p3ADyOYSmHuK4yUmTmFXuI/DBlu7NomeTR4ERvNC2RJZZ2CFP1tisJ45u+P/iw== X-Received: by 10.223.176.93 with SMTP id g29mr73728wra.7.1484694372971; Tue, 17 Jan 2017 15:06:12 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B340FF2.dip0.t-ipconnect.de. [91.52.15.242]) by smtp.gmail.com with ESMTPSA id o132sm40201256wmo.17.2017.01.17.15.06.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Jan 2017 15:06:12 -0800 (PST) From: "Mehmet Ersue" To: "'Netconf'" Date: Wed, 18 Jan 2017 00:06:14 +0100 Message-ID: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_03B9_01D2711E.AFBDE120" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhA== Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0204.587EA364.0037,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Subject: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2017 23:06:17 -0000 This is a multipart message in MIME format. ------=_NextPart_000_03B9_01D2711E.AFBDE120 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear NETCONF WG, looking at the feedback on the three options Eric Voit summarized in his mail below but also related discussion on this topic, NETCONF co-chairs came to the conclusion that option (iii) for updating/enhancing RFC5277 did not get any proponents. On the other hand we see a huge support and attraction for the new notification/subscription capabilities and extensions discussed and provided by the Subscriptions and Events team. We think that the addition of new notification capabilities in concert with the drafts from the Subscriptions and Events team provide rich features that implementations will want to support in the future. The key features in preparation are transport independence, multiple dynamic and/or configured subscriptions in a transport session. The documents the Subscriptions and Events team are currently working on are: - A document which defines the protocol-neutral notification framework, i.e., explains the concepts of subscriptions, filters, control plane notifications, replay, etc. And also defines the associated YANG data model, RPCs, etc. This is currently covered in 5277bis document which would need to be renamed. - A document which defines how notifications are sent over NETCONF (generalizing section 3.7 of RFC 5277) and how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), - A document which defines how notifications are sent over RESTCONF (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-restconf-notif), - A document which defines the subscription and push mechanism for YANG datastores allowing subscriber applications to request updates from a YANG datastore (draft-ietf-netconf-yang-push). A) NETCONF co-chairs think that the Subscriptions and Events team should continue its valuable work and propose to change our current charter to add the development of notifications and subscription capabilities with the listed documents and focus above as a starting point. WG members are asked to state their opinion on the proposed plan. Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you have a strong objection to this plan and explain your concern with valid arguments. Please also state clearly if you support this plan. B) NETCONF co-chairs further propose that NETCONF WG should use its energy in the future to complete and improve the new notification and subscription RFCs and stop maintaining RFC 5277 for issues other than errata. Note that it is required that RFC 5277 and all new work needs to gracefully co-exist in any deployment. Please state your opinion on the maillist by January 27, 2017 EOB PT, whether you think RFC 5277 should be obsoleted during the publication of the new draft set or not. Many Thanks in advance for your valuable comments. Mehmet & Mahesh From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Tuesday, December 20, 2016 4:33 PM To: netconf@ietf.org; netconf-chairs@ietf.org Subject: 3 Options for Subscription & Event Notification draft structure To summarize previous threads, key benefits of 5277bis over RFC 5277 include: (1) transport independence (2) configured subscriptions (3) many subscriptions per transport session (4) modify and delete subscription RPCs (5) control plane notifications (6) data plane notification including subscription-id (7) negotiation (see Yves' thread from yesterday) (8) control plane reuse with draft-ietf-netconf-yang-push. Those of us working 5277bis had been planning on supporting existing 5277 implementations via a separate backwards compatibility section. But as we have gone forward, we see no meaningful technical overlaps. I.e., there are no RPC or notifications shared between the 5277 and 5277bis solutions. Any compatibility mode section would be fully standalone. Considering that people can just refer to 5277 if they need it, and considering 5277 & 5277bis could easily run in parallel on different transport sessions, building a standalone backwards compatibility section seems both confusing and redundant. This leaves three options: (i.) OBSOLETE 5277 by replacing it with 5277bis (ii.) Support 5277bis without Obsoleting 5277 (iii.) Write a new UPDATE draft for 5277 NETCONF only transport The benefits and issues of each are as follows: (i.) OBSOLETE 5277 by replacing it with 5277bis * Supports all requirements (1) through (8). * IETF does not continue protocol maintenance of 5277. * Implementations can still choose 5277 or 5277bis, even though IETF recommends 5277bis. * Implementations provide backwards compatibility through concurrent, parallel support of both specifications. * Although obsoleted, the IETF does not deprecate 5277 so that current implementations may stay with existing 5277. * Need to change the NETCONF WG charter to show that 5277 is being replaced rather than enhanced. (ii.) Support 5277bis without Obsoleting 5277 * Technically identical to (i). * Implementations free to choose 5277 or 5277bis, with no guidance on which the WG recommends. * This could be confusing to customers as NETCONF WG will be advocating competing technologies for the place of overlap. -- i.e., NETCONF over XML with a single subscription. * Establishes competing technology futures where one direction would suffice. (iii.) Write a new UPDATE draft for 5277 NETCONF only transport * Supports a subset of requirements: * Cannot support (1) or (8) * Supporting (2), (3), (4), (5), (6), & (7) possible, but would require the creation of replicated/competing mechanisms with (8). * Doubles the development effort if the yang-push control plane is also required. * WG would need to build guidelines on when to use 5277bis or this new UPDATE draft (assuming the WG wanted to proceed with the transport independent 5277bis.) * No identified author / champion for this path. (Because business drivers being driven by other than NETCONF/XML.) * Update draft itself wouldn't require a NETCONF charter update. Based on this list, the people working in on the Subscription & Event Notification weekly calls have a preference for (i.) followed by (ii.). Do you have a preference or additional questions not addressed here or in the earlier threads? Thanks, Eric ------=_NextPart_000_03B9_01D2711E.AFBDE120 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF = WG,

 

looking at the feedback = on the three options Eric Voit summarized in his mail below but also = related discussion on this topic, NETCONF co-chairs came to the = conclusion that option (iii) for updating/enhancing RFC5277 did not get = any proponents. On the other hand we see a huge support and attraction = for the new notification/subscription capabilities and extensions = discussed and provided by the Subscriptions and Events = team.

 

We think that the = addition of new notification capabilities in concert with the drafts = from the Subscriptions and Events team provide rich features that = implementations will want to support in the future. The key features in = preparation are transport independence, multiple dynamic and/or = configured subscriptions in a transport session.    =   

 

The documents the = Subscriptions and Events team are currently working on = are:

- A document which defines the protocol-neutral = notification framework, i.e., explains the concepts of subscriptions, = filters, control plane notifications, replay, etc.  And also = defines the associated YANG data model, RPCs, etc. This is currently = covered in 5277bis document which would need to be = renamed.

- A document which defines how notifications are = sent over NETCONF (generalizing section 3.7 of RFC 5277) and how YANG = notifications are encoded in XML and JSON = (draft-ietf-netconf-netconf-event-notifications),

- A document which = defines how notifications are sent over RESTCONF (generalizing section 6 = of RESTCONF RFC) and HTTP2.  Also defines how YANG notifications = are encoded in XML and JSON = (draft-ietf-netconf-restconf-notif),

- A document which = defines the subscription and push mechanism for YANG datastores allowing = subscriber applications to request updates from a YANG datastore = (draft-ietf-netconf-yang-push).

 

A) NETCONF co-chairs = think that the Subscriptions and Events team should continue its = valuable work and propose to change our current charter to add the = development of notifications and subscription capabilities with the = listed documents and focus above as a starting point. WG members are = asked to state their opinion on the proposed plan. =

Please let us know on NETCONF maillist by = January 27, 2017 EOB PT, if you have a strong objection to this plan and = explain your concern with valid arguments. Please also state clearly if = you support this plan.

 

B) NETCONF co-chairs = further propose that NETCONF WG should use its energy in the future to = complete and improve the new notification and subscription RFCs and stop = maintaining RFC 5277 for issues other than errata.  Note that it is = required that RFC 5277 and all new work needs to gracefully co-exist in = any deployment.  

Please state your opinion on the maillist by = January 27, 2017 EOB PT, whether you think RFC 5277 should be obsoleted = during the publication of the new draft set or = not.

 

Many Thanks in advance = for your valuable comments. 

 

Mehmet & = Mahesh

 

From: Eric Voit (evoit) = [mailto:evoit@cisco.com]
Sent: Tuesday, December 20, 2016 = 4:33 PM
To: netconf@ietf.org; = netconf-chairs@ietf.org
Subject: 3 Options for Subscription = & Event Notification draft structure

 

To = summarize previous threads, key benefits of 5277bis over RFC 5277 = include:

  (1) transport = independence

  (2) configured = subscriptions

  (3) many = subscriptions per transport session

  (4) modify and delete subscription = RPCs

  (5) control plane = notifications

  (6) data = plane notification including subscription-id

  (7) negotiation (see Yves’ thread from = yesterday)

  (8) control = plane reuse with draft-ietf-netconf-yang-push.

 

Those = of us working 5277bis had been planning on supporting existing 5277 = implementations via a separate backwards compatibility section.  = But as we have gone forward, we see no meaningful technical overlaps. =  I.e., there are no RPC or notifications shared between the 5277 = and 5277bis solutions.  Any compatibility mode section would be = fully standalone.  Considering that people can just refer to 5277 = if they need it, and considering 5277 & 5277bis could easily run in = parallel on different transport sessions, building a standalone = backwards compatibility section seems both confusing and redundant. =  

 

This leaves three options:

  (i.) OBSOLETE 5277 by replacing it with = 5277bis

  (ii.) Support = 5277bis without Obsoleting 5277

  (iii.) Write a new UPDATE draft for = 5277 NETCONF only transport

 

The = benefits and issues of each are as follows:

 

(i.) OBSOLETE 5277 by replacing it with 5277bis =   

  • Supports all = requirements (1) through (8).
  • IETF does not continue = protocol maintenance of 5277.
    • Implementations can = still choose 5277 or 5277bis, even though IETF recommends = 5277bis.
    • Implementations = provide backwards compatibility through concurrent, parallel support of = both specifications.
    • Although obsoleted, = the IETF does not deprecate 5277 so that current implementations may = stay with existing 5277.
  • Need to change the = NETCONF WG charter to show that 5277 is being replaced rather than = enhanced.

 

(ii.) Support 5277bis without Obsoleting = 5277

  • Technically identical to (i).
  • Implementations free to choose 5277 or 5277bis, with no guidance = on which the WG recommends. 
    • This could be = confusing to customers as NETCONF WG will be advocating competing = technologies for the place of overlap.  -- i.e., NETCONF over XML = with a single subscription.
  • Establishes competing = technology futures where one direction would = suffice.

 

(iii.) Write a new UPDATE draft for 5277 NETCONF = only transport

  • Supports a subset of = requirements:
    • Cannot support (1) or = (8)
    • Supporting (2), (3), = (4), (5), (6), & (7) possible, but would require the creation of = replicated/competing mechanisms with (8). 
  • Doubles the development effort if the yang-push control plane is = also required.
  • WG would need to build = guidelines on when to use 5277bis or this new UPDATE draft (assuming the = WG wanted to proceed with the transport independent = 5277bis.)
  • No identified author / = champion for this path.  (Because business drivers being driven by = other than NETCONF/XML.)
  • Update draft itself = wouldn’t require a NETCONF charter update.

 

Based on = this list, the people working in on the Subscription & Event = Notification weekly calls have a preference for (i.) followed by = (ii.).  Do you have a preference or additional questions not = addressed here or in the earlier threads?

 

Thanks,

Eric =

 

------=_NextPart_000_03B9_01D2711E.AFBDE120-- From nobody Tue Jan 17 23:53:17 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B011293F9 for ; Tue, 17 Jan 2017 23:53:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 JiFi364921DT for ; Tue, 17 Jan 2017 23:53:14 -0800 (PST) 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 21BCC129585 for ; Tue, 17 Jan 2017 23:53:14 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 54DD6781; Wed, 18 Jan 2017 08:53:12 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id MFwnPXDag3Cm; Wed, 18 Jan 2017 08:53:10 +0100 (CET) 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, 18 Jan 2017 08:53:12 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id EAB4A200A3; Wed, 18 Jan 2017 08:53:11 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id LhHoXluWYb1I; Wed, 18 Jan 2017 08:53:11 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 8514720090; Wed, 18 Jan 2017 08:53:11 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 59BC23E28C57; Wed, 18 Jan 2017 08:53:15 +0100 (CET) Date: Wed, 18 Jan 2017 08:53:14 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20170118075314.GA4786@elstar.local> Mail-Followup-To: Mehmet Ersue , 'Netconf' References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: 'Netconf' Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 07:53:16 -0000 On Wed, Jan 18, 2017 at 12:06:14AM +0100, Mehmet Ersue wrote: > > > The documents the Subscriptions and Events team are currently working on > are: > > - A document which defines the protocol-neutral notification framework, > i.e., explains the concepts of subscriptions, filters, control plane > notifications, replay, etc. And also defines the associated YANG data > model, RPCs, etc. This is currently covered in 5277bis document which would > need to be renamed. I think 'control plane notification' is a really bad term for what it does and the sooner we find a better term the better it is. I actually think that no term is needed. > - A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), The encoding of YANG defined notifications into XML and JSON is defined in RFC 7950 and RFC 7951. NETCONF does not support JSON. > - A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG > notifications are encoded in XML and JSON > (draft-ietf-netconf-restconf-notif), The encoding of YANG defined notifications into XML and JSON is defined in RFC 7950 and RFC 7951. > - A document which defines the subscription and push mechanism for YANG > datastores allowing subscriber applications to request updates from a YANG > datastore (draft-ietf-netconf-yang-push). Perhaps you mean the right thing but from the writing this is not clear. Perhaps you actually mean the following four documents: a) protocol-neutral extended notification framework b) using extended notifications with NETCONF c) using extended notifications with RESTCONF d) a YANG data model for extended notifications Such a set of documents makes sense to me. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Jan 18 00:53:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FFCD129430 for ; Wed, 18 Jan 2017 00:53:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.199 X-Spam-Level: X-Spam-Status: No, score=-10.199 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=-3.199] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h8VUesN0M811 for ; Wed, 18 Jan 2017 00:53:16 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5399128B44 for ; Wed, 18 Jan 2017 00:53:15 -0800 (PST) Received: from [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4] (unknown [IPv6:2001:718:1a02:1:ded:9860:a06f:ffc4]) by mail.nic.cz (Postfix) with ESMTPSA id 81DCE6202F; Wed, 18 Jan 2017 09:53:14 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1484729594; bh=oDlsAneB1WtTFLHmfJ11XEjYnqgz+k/vlnHQpxZJpvA=; h=From:Date:To; b=QAAnvyiKfxab1F0mOzv3adJce7au5kDYi74OeoUiyByHyVVb1sUp1Do39hbQVIIl7 X+fHSHrkHqpG3mX924xREqgjutoDIRsDl1kFmwp59lcUnmIvHj1CHpqOKGQUJJ1Y2n 2GgKc2EABAhaevP8Iu/ohVAVXep+1X51y8k6NUCE= Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\)) From: Ladislav Lhotka In-Reply-To: Date: Wed, 18 Jan 2017 09:53:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20170116.141405.521276088073036158.mbj@tail-f.com> <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> To: Andy Bierman X-Mailer: Apple Mail (2.3259) X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Cc: Netconf Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 08:53:18 -0000 > On 17 Jan 2017, at 22:50, Andy Bierman wrote: >=20 >=20 >=20 > On Tue, Jan 17, 2017 at 12:24 PM, Kent Watsen = wrote: >=20 > > Yes, I would like to see a new core statement "structure" or > > something similar, which could be used to define the schema > > for instances that are not tied to any datastores, operations, > > or notifications. The semantics of these structures must be > > defined in the description statement. The core statement > > "augment" should be extended so that it can be used to augment > > such structures. >=20 > I=E2=80=99m not sure if a core statement is best, but this can be = hashed > out later... >=20 > =20 > > But this requires a new version of YANG. >=20 > Indeed, and thus I just added an entry for YANG-next: > https://github.com/netmod-wg/yang-next/issues/8 >=20 >=20 > But the zerotouch draft can=E2=80=99t wait that long, what should it > do in the meanwhile? Would it be acceptable to state in the > draft and also in the YANG module itself that the YANG module > MUST NOT ever be implemented by a NC/RC server? >=20 >=20 >=20 > The term MUST NOT has requirements for use which are not met here. > IMO it is sufficient to say the module is not intended for = implementation > in a NC/RC server. It depends on the purpose that the module is used for. It doesn't work = very well if it is intended to be normative ("some data MUST be valid = according to this module") because validity, XPath context and other = things are defined in terms of specific datastores. It is also often = impossible to decide whether it describes configuration or state data = (some YANG rules depend on it). So using YANG in this way is not really supported by the spec and it is = not guaranteed that everybody extrapolates the rules in the same way. = Creativity in interpretation of standards IMO isn't very good. Lada >=20 > If the data-structure extension is used then the module looks empty to = a NC/RC server > so not sure why this is even an issue. >=20 > =20 >=20 > Thanks, > Kent >=20 >=20 >=20 >=20 > Andy >=20 > =20 >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From Milan.Lenco@pantheon.tech Wed Jan 18 06:39:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931CE129855 for ; Wed, 18 Jan 2017 06:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OoxfrchzyM1l for ; Wed, 18 Jan 2017 06:38:56 -0800 (PST) Received: from amalka.pantheon.sk (amalka.pantheon.sk [46.229.239.144]) by ietfa.amsl.com (Postfix) with ESMTP id 933A0129851 for ; Wed, 18 Jan 2017 06:38:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by amalka.pantheon.sk (Postfix) with ESMTP id 3D0A824729 for ; Wed, 18 Jan 2017 15:38:55 +0100 (CET) X-Virus-Scanned: amavisd-new at pantheon.sk Received: from amalka.pantheon.sk ([127.0.0.1]) by localhost (amalka.pantheon.sk [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K76dQjf4wUop for ; Wed, 18 Jan 2017 15:38:53 +0100 (CET) Received: from XMBX1.pantheon.local (fw.pantheon.sk [46.229.239.141]) by amalka.pantheon.sk (Postfix) with ESMTPS for ; Wed, 18 Jan 2017 15:38:53 +0100 (CET) Received: from XMBX3.pantheon.local (10.10.4.8) by XMBX1.pantheon.local (10.10.4.5) with Microsoft SMTP Server (TLS) id 15.0.1236.3; Wed, 18 Jan 2017 15:38:52 +0100 Received: from XMBX3.pantheon.local ([10.10.4.8]) by XMBX3.pantheon.local ([10.10.4.8]) with mapi id 15.00.1236.000; Wed, 18 Jan 2017 15:38:52 +0100 From: =?iso-8859-2?Q?Milan_Len=E8o?= To: "netconf@ietf.org" Thread-Topic: NACM of implicitly created nodes Thread-Index: AQHScZJYAj7hHvyPFUW6/eUn2ZVQjA== Date: Wed, 18 Jan 2017 14:38:52 +0000 Message-ID: <1484750332352.34705@pantheon.tech> Accept-Language: sk-SK, en-US Content-Language: sk-SK X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.12.0.154] Content-Type: multipart/alternative; boundary="_000_148475033235234705pantheontech_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] NACM of implicitly created nodes X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 14:40:49 -0000 --_000_148475033235234705pantheontech_ Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable Hi, I am currently working on implementation of NACM for NETCONF and I would li= ke to ask you for clarification on access control for implicitly created no= des. Namely, if in order to create a new container/list, it is necessary for the= user to have permission to create direct ancestors with default values (th= at will effectively start to exist from that point) and child non-presence = containers (created automatically as per YANG 1.1: RFC 7950, section 6.4.1)= . Similarly for the delete operation that includes previously implicitly cr= eated nodes which, however, haven't been touched by the user. If the answer is "no", then my follow up question is, if changing leaf with= default value to the same value should be then treated as target for data = access validation, even though the effective change is none, since the exis= tence of that leaf became explicit. Similarly, if explicitly creating non-p= resence container that existed before only because of the rule from YANG 1.= 1 should be considered as starting point for the access control of that con= tainer. Thanks, Milan Len=E8o MilanLen=E8o Software Developer S=EDdlo / Mlynsk=E9 Nivy 56 / 821 05 Bratislava / Slovakia R&D centrum / Janka Kr=E1=B5a 9 / 974 01 Bansk=E1 Bystrica / Slovakia / Milan.Lenco@pantheon.tech reception: +421 2 206 65 114 / www.pantheon.tech [logo] --_000_148475033235234705pantheontech_ Content-Type: text/html; charset="iso-8859-2" Content-Transfer-Encoding: quoted-printable

Hi,


I am currently working on implementation of NACM for NETCONF and I would= like to ask you for clarification on access control for implicit= ly created nodes.


Namely, if in order to create a new container/list, it is necessary for = the user to have permission to create direct ancestors with default va= lues (that will effectively start to exist from that point) and child non-p= resence containers (created automatically as per YANG 1.1: RFC 7950, section 6.4.1). Similarly for the delete o= peration that includes previously implicitly created nodes which, = ;however, haven't been touched by the user.


If the answer is "no", then my follow up question is, if chang= ing leaf with default value to the same value should be then treated as tar= get for data access validation, even though the effective change is none, s= ince the existence of that leaf became explicit. Similarly, if explicitly creating non-presence container that existed befo= re only because of the rule from YANG 1.1 should be considered as starting = point for the access control of that container.


Thanks,

Milan Len=E8o

 

MilanLen=E8o

Softwa= re Developer


S=EDdlo /&n= bsp;Mlynsk=E9 Nivy 56 / 8= 21 05 Bratislava / / Janka Kr=E1=B5a 9 /  974 01 Bansk=E1 Bystrica = / Sl= ovakia
/ Milan.Lenco= @pantheon.tech
reception: +421 2 206 65 114 / www.pantheon.tech

3D"logo"

 

--_000_148475033235234705pantheontech_-- From nobody Wed Jan 18 07:30:19 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E335212945C for ; Wed, 18 Jan 2017 07:30:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 wMj6VgdcnsMG for ; Wed, 18 Jan 2017 07:30:14 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 03CF012940B for ; Wed, 18 Jan 2017 07:30:13 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id ABD501AE0455; Wed, 18 Jan 2017 16:30:09 +0100 (CET) Date: Wed, 18 Jan 2017 16:30:08 +0100 (CET) Message-Id: <20170118.163008.1385302774802307987.mbj@tail-f.com> To: lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 15:30:18 -0000 TGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiB3cm90ZToNCj4gDQo+ID4gT24gMTcgSmFu IDIwMTcsIGF0IDIyOjUwLCBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3JvdGU6 DQo+ID4gDQo+ID4gDQo+ID4gDQo+ID4gT24gVHVlLCBKYW4gMTcsIDIwMTcgYXQgMTI6MjQgUE0s IEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0Pg0KPiA+IHdyb3RlOg0KPiA+IA0KPiA+ ID4gWWVzLCBJIHdvdWxkIGxpa2UgdG8gc2VlIGEgbmV3IGNvcmUgc3RhdGVtZW50ICJzdHJ1Y3R1 cmUiIG9yDQo+ID4gPiBzb21ldGhpbmcgc2ltaWxhciwgd2hpY2ggY291bGQgYmUgdXNlZCB0byBk ZWZpbmUgdGhlIHNjaGVtYQ0KPiA+ID4gZm9yIGluc3RhbmNlcyB0aGF0IGFyZSBub3QgdGllZCB0 byBhbnkgZGF0YXN0b3Jlcywgb3BlcmF0aW9ucywNCj4gPiA+IG9yIG5vdGlmaWNhdGlvbnMuICBU aGUgc2VtYW50aWNzIG9mIHRoZXNlIHN0cnVjdHVyZXMgbXVzdCBiZQ0KPiA+ID4gZGVmaW5lZCBp biB0aGUgZGVzY3JpcHRpb24gc3RhdGVtZW50LiAgVGhlIGNvcmUgc3RhdGVtZW50DQo+ID4gPiAi YXVnbWVudCIgc2hvdWxkIGJlIGV4dGVuZGVkIHNvIHRoYXQgaXQgY2FuIGJlIHVzZWQgdG8gYXVn bWVudA0KPiA+ID4gc3VjaCBzdHJ1Y3R1cmVzLg0KPiA+IA0KPiA+IEnigJltIG5vdCBzdXJlIGlm IGEgY29yZSBzdGF0ZW1lbnQgaXMgYmVzdCwgYnV0IHRoaXMgY2FuIGJlIGhhc2hlZA0KPiA+IG91 dCBsYXRlci4uLg0KDQpJZiBpdCBpcyBub3QgYSBjb3JlIHN0YXRlbWVudCwgImF1Z21lbnQiIHdv bid0IHdvcmsuICBCdXQgb2YgY291cnNlLA0Kd2UgY2FuIGRlZmluZSBleHRlbnNpb25zICJzdHJ1 Y3R1cmUiIGFuZCAiYXVnbWVudC1zdHJ1Y3R1cmUiLg0KDQo+ID4gPiBCdXQgdGhpcyByZXF1aXJl cyBhIG5ldyB2ZXJzaW9uIG9mIFlBTkcuDQoNClllcy4NCg0KPiA+IEluZGVlZCwgYW5kIHRodXMg SSBqdXN0IGFkZGVkIGFuIGVudHJ5IGZvciBZQU5HLW5leHQ6DQo+ID4gICBodHRwczovL2dpdGh1 Yi5jb20vbmV0bW9kLXdnL3lhbmctbmV4dC9pc3N1ZXMvOA0KPiA+IA0KPiA+IA0KPiA+IEJ1dCB0 aGUgemVyb3RvdWNoIGRyYWZ0IGNhbuKAmXQgd2FpdCB0aGF0IGxvbmcsIHdoYXQgc2hvdWxkIGl0 DQo+ID4gZG8gaW4gdGhlIG1lYW53aGlsZT8gICBXb3VsZCBpdCBiZSBhY2NlcHRhYmxlIHRvIHN0 YXRlIGluIHRoZQ0KPiA+IGRyYWZ0IGFuZCBhbHNvIGluIHRoZSBZQU5HIG1vZHVsZSBpdHNlbGYg dGhhdCB0aGUgWUFORyBtb2R1bGUNCj4gPiBNVVNUIE5PVCBldmVyIGJlIGltcGxlbWVudGVkIGJ5 IGEgTkMvUkMgc2VydmVyPw0KPiA+IA0KPiA+IA0KPiA+IA0KPiA+IFRoZSB0ZXJtIE1VU1QgTk9U IGhhcyByZXF1aXJlbWVudHMgZm9yIHVzZSB3aGljaCBhcmUgbm90IG1ldCBoZXJlLg0KPiA+IElN TyBpdCBpcyBzdWZmaWNpZW50IHRvIHNheSB0aGUgbW9kdWxlIGlzIG5vdCBpbnRlbmRlZCBmb3IN Cj4gPiBpbXBsZW1lbnRhdGlvbg0KPiA+IGluIGEgTkMvUkMgc2VydmVyLg0KPiANCj4gSXQgZGVw ZW5kcyBvbiB0aGUgcHVycG9zZSB0aGF0IHRoZSBtb2R1bGUgaXMgdXNlZCBmb3IuIEl0IGRvZXNu J3Qgd29yaw0KPiB2ZXJ5IHdlbGwgaWYgaXQgaXMgaW50ZW5kZWQgdG8gYmUgbm9ybWF0aXZlICgi c29tZSBkYXRhIE1VU1QgYmUgdmFsaWQNCj4gYWNjb3JkaW5nIHRvIHRoaXMgbW9kdWxlIikgYmVj YXVzZSB2YWxpZGl0eSwgWFBhdGggY29udGV4dCBhbmQgb3RoZXINCj4gdGhpbmdzIGFyZSBkZWZp bmVkIGluIHRlcm1zIG9mIHNwZWNpZmljIGRhdGFzdG9yZXMuIEl0IGlzIGFsc28gb2Z0ZW4NCj4g aW1wb3NzaWJsZSB0byBkZWNpZGUgd2hldGhlciBpdCBkZXNjcmliZXMgY29uZmlndXJhdGlvbiBv ciBzdGF0ZSBkYXRhDQo+IChzb21lIFlBTkcgcnVsZXMgZGVwZW5kIG9uIGl0KS4NCj4gDQo+IFNv IHVzaW5nIFlBTkcgaW4gdGhpcyB3YXkgaXMgbm90IHJlYWxseSBzdXBwb3J0ZWQgYnkgdGhlIHNw ZWMgYW5kIGl0DQo+IGlzIG5vdCBndWFyYW50ZWVkIHRoYXQgZXZlcnlib2R5IGV4dHJhcG9sYXRl cyB0aGUgcnVsZXMgaW4gdGhlIHNhbWUNCj4gd2F5LiBDcmVhdGl2aXR5IGluIGludGVycHJldGF0 aW9uIG9mIHN0YW5kYXJkcyBJTU8gaXNuJ3QgdmVyeSBnb29kLg0KDQorMQ0KDQoNClR3byBhbHRl cm5hdGl2ZXM6DQoNCiAgbyAgRGVmaW5lIHlldCBhbm90aGVyIG9uZS1vZmYgc29sdXRpb24gZm9y IHplcm90b3VjaCwgaS5lLiwgYW4NCiAgICAgZXh0ZW5zaW9uIGNhbGxlZCAgJ3plcm90b3VjaC1h cnRpZmFjdCcgb3Igd2hhdGV2ZXIuDQoNCiAgbyAgRGVmaW5lIGEgZ2VuZXJpYyBleHRlbnNpb24g InN0cnVjdHVyZSIgaW4gYSBzZXBhcmF0ZSBkcmFmdCwNCiAgICAgbWF5YmUgd2l0aCBhbiAiYXVn bWVudC1zdHJ1Y3R1cmUiIGV4dGVuc2lvbi4gIERvY3VtZW50IHRoYXQNCiAgICAgdGhpcyBpcyBp bnRlbmRlZCBhcyBhbiBpbnRlcmltIHNvbHV0aW9uIHVudGlsIFlBTkcgaXMgdXBkYXRlZC4NCg0K DQoNCi9tYXJ0aW4NCg== From nobody Wed Jan 18 10:27:09 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9432D129553 for ; Wed, 18 Jan 2017 10:27:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XqYTJLccW03N for ; Wed, 18 Jan 2017 10:27:06 -0800 (PST) Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0114.outbound.protection.outlook.com [104.47.34.114]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6674912954F for ; Wed, 18 Jan 2017 10:27:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jvPXsKd18HqqOygfOXUDY/IqacQy9vE5hUvgDnueERc=; b=fblvU4TohfsELWFb6NtPESVke5b6UPRd3bezj9UBzI2rde0NXstaL2POijvbiW4goXBR6P6NU0h5iNrH0rHuzy6jB8txXikPSJlcyVytgh9TX4aPgUXtbphr4vldu+HRkZnO30Hcx9kWe5lFNoDEcqoDKa6y9TzGmyJ/1O3mo1c= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 18:27:04 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 18:27:04 +0000 From: Kent Watsen To: Martin Bjorklund , "lhotka@nic.cz" Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22ACAAGvCgIAAuS4AgABu5AD//92dgA== Date: Wed, 18 Jan 2017 18:27:04 +0000 Message-ID: <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> References: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> <20170118.163008.1385302774802307987.mbj@tail-f.com> In-Reply-To: <20170118.163008.1385302774802307987.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 54a9ab2f-7b65-48a3-5563-08d43fcf9a4d x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:OOQe3llC+wXE8fDkWAtJ7TotR3bf1/xHhg+yxLNrGiASTlhx9QP2RFqUd05GoYgYeGfULFSg452mxYryEFUaLbdHjQX4nJfHJL5yb5idIzR1H3syP8L9mIjRzMblPGzzxvRzzzWJk3FiTKsWZ+HsaOarmji2UW0wSXL+pOJw0V1oJRpzJy2F94GNe/Xpa3QDXI2CboQOjotVvlxab1cGUKse4bild3fWCs62oNojA/jxkMLI0b/RUYaKV+K5fgw4swlxRyNsupv0nkmm4NMJxuz+wHUTdQnHpG5g2mSrXmu7NWsJMLr/obzhYrEa2phsoV2IVKUl9ZUbF9jF3pJq2V0bE5ejyH+3jcuXbdZhzFC4BLGJs+P/todHz96nDbJ+HR2oGfCEv1I89NBRIpx6Xf0HcQOc3GLi2J6iuqwcTDgjae4joAq30SCB10RvUsl93pqaauzB9YAmKmgukiGQ/g== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123562025)(20161123555025)(20161123564025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39860400002)(39450400003)(39410400002)(39840400002)(199003)(189002)(229853002)(5660300001)(105586002)(106116001)(83716003)(6116002)(2906002)(102836003)(4326007)(3846002)(2900100001)(6512007)(6436002)(83506001)(2950100002)(6506006)(2501003)(82746002)(25786008)(38730400001)(99286003)(122556002)(77096006)(53936002)(106356001)(6486002)(101416001)(3280700002)(305945005)(54356999)(76176999)(33656002)(50986999)(86362001)(36756003)(97736004)(5001770100001)(3660700001)(7736002)(66066001)(92566002)(81166006)(81156014)(4001350100001)(8936002)(8676002)(68736007)(93886004)(189998001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <31927E54061813408E17A5952CC1127F@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 18:27:04.3980 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 18:27:07 -0000 SGkgTWFydGluLA0KDQo+Pj4gQW5keSB3cml0ZXM6IA0KPj4+IElNTyBpdCBpcyBzdWZmaWNpZW50 IHRvIHNheSB0aGUgbW9kdWxlIGlzIG5vdCBpbnRlbmRlZCBmb3INCj4+PiBpbXBsZW1lbnRhdGlv biBpbiBhIE5DL1JDIHNlcnZlci4NCj4+IA0KPj4gTGFkYSB3cml0ZXM6DQo+PiBJdCBkZXBlbmRz IG9uIHRoZSBwdXJwb3NlIHRoYXQgdGhlIG1vZHVsZSBpcyB1c2VkIGZvci4gSXQgZG9lc24ndCB3 b3JrDQo+PiB2ZXJ5IHdlbGwgaWYgaXQgaXMgaW50ZW5kZWQgdG8gYmUgbm9ybWF0aXZlICgic29t ZSBkYXRhIE1VU1QgYmUgdmFsaWQNCj4+IGFjY29yZGluZyB0byB0aGlzIG1vZHVsZSIpIGJlY2F1 c2UgdmFsaWRpdHksIFhQYXRoIGNvbnRleHQgYW5kIG90aGVyDQo+PiB0aGluZ3MgYXJlIGRlZmlu ZWQgaW4gdGVybXMgb2Ygc3BlY2lmaWMgZGF0YXN0b3Jlcy4gSXQgaXMgYWxzbyBvZnRlbg0KPj4g aW1wb3NzaWJsZSB0byBkZWNpZGUgd2hldGhlciBpdCBkZXNjcmliZXMgY29uZmlndXJhdGlvbiBv ciBzdGF0ZSBkYXRhDQo+PiAoc29tZSBZQU5HIHJ1bGVzIGRlcGVuZCBvbiBpdCkuDQo+PiANCj4+ IFNvIHVzaW5nIFlBTkcgaW4gdGhpcyB3YXkgaXMgbm90IHJlYWxseSBzdXBwb3J0ZWQgYnkgdGhl IHNwZWMgYW5kIGl0DQo+PiBpcyBub3QgZ3VhcmFudGVlZCB0aGF0IGV2ZXJ5Ym9keSBleHRyYXBv bGF0ZXMgdGhlIHJ1bGVzIGluIHRoZSBzYW1lDQo+PiB3YXkuIENyZWF0aXZpdHkgaW4gaW50ZXJw cmV0YXRpb24gb2Ygc3RhbmRhcmRzIElNTyBpc24ndCB2ZXJ5IGdvb2QuDQo+DQo+IE1hcnRpbiB3 cml0ZXM6DQo+DQo+ICsxDQo+DQo+IFR3byBhbHRlcm5hdGl2ZXM6DQo+DQo+ICBvICBEZWZpbmUg eWV0IGFub3RoZXIgb25lLW9mZiBzb2x1dGlvbiBmb3IgemVyb3RvdWNoLCBpLmUuLCBhbg0KPiAg ICAgZXh0ZW5zaW9uIGNhbGxlZCAnemVyb3RvdWNoLWFydGlmYWN0JyBvciB3aGF0ZXZlci4NCj4N Cj4gIG8gIERlZmluZSBhIGdlbmVyaWMgZXh0ZW5zaW9uICJzdHJ1Y3R1cmUiIGluIGEgc2VwYXJh dGUgZHJhZnQsDQo+ICAgICBtYXliZSB3aXRoIGFuICJhdWdtZW50LXN0cnVjdHVyZSIgZXh0ZW5z aW9uLiAgRG9jdW1lbnQgdGhhdA0KPiAgICAgdGhpcyBpcyBpbnRlbmRlZCBhcyBhbiBpbnRlcmlt IHNvbHV0aW9uIHVudGlsIFlBTkcgaXMgdXBkYXRlZC4NCg0KDQpXaGVuIHlvdSBzYXkg4oCcYWx0 ZXJuYXRpdmVz4oCdLCBhcmUgdGhlc2UgYWx0ZXJuYXRpdmVzIHRvIEFuZHnigJlzIA0Kc3VnZ2Vz dGlvbiBhYm92ZSBhcyB3ZWxsIChlLmcuLCBhIHNpbXBsZSBub3RlKS4gIFllcywgTGFkYeKAmXMN CmNvbW1lbnRzIGFyZSB2YWxpZCwgYnV0IHRoZXnigJlyZSBlcXVhbGx5IHZhbGlkIGV2ZW4gd2hl biB1c2luZw0KeW91ciB0d28gc3VnZ2VzdGlvbnMgdG9vLCByaWdodD8NCg0KS2VudA0KDQoNCg== From nobody Wed Jan 18 11:19:30 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D4123129579 for ; Wed, 18 Jan 2017 11:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 9JUriSdCVkJq for ; Wed, 18 Jan 2017 11:19:27 -0800 (PST) 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 41CE6129574 for ; Wed, 18 Jan 2017 11:19:27 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0CD7375C; Wed, 18 Jan 2017 20:19:26 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id g3kr87a0nutS; Wed, 18 Jan 2017 20:19:23 +0100 (CET) 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, 18 Jan 2017 20:19:25 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D58D200A5; Wed, 18 Jan 2017 20:19:25 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id m4DStA1uz8hK; Wed, 18 Jan 2017 20:19:25 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 02DD7200A3; Wed, 18 Jan 2017 20:19:25 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id EF4693E29A47; Wed, 18 Jan 2017 20:19:28 +0100 (CET) Date: Wed, 18 Jan 2017 20:19:28 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170118191928.GC5811@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "lhotka@nic.cz" , "netconf@ietf.org" References: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:19:29 -0000 On Wed, Jan 18, 2017 at 06:27:04PM +0000, Kent Watsen wrote: > Hi Martin, > > >>> Andy writes: > >>> IMO it is sufficient to say the module is not intended for > >>> implementation in a NC/RC server. > >> > >> Lada writes: > >> It depends on the purpose that the module is used for. It doesn't work > >> very well if it is intended to be normative ("some data MUST be valid > >> according to this module") because validity, XPath context and other > >> things are defined in terms of specific datastores. It is also often > >> impossible to decide whether it describes configuration or state data > >> (some YANG rules depend on it). > >> > >> So using YANG in this way is not really supported by the spec and it > >> is not guaranteed that everybody extrapolates the rules in the same > >> way. Creativity in interpretation of standards IMO isn't very good. > > > > Martin writes: > > > > +1 > > > > Two alternatives: > > > > o Define yet another one-off solution for zerotouch, i.e., an > > extension called 'zerotouch-artifact' or whatever. > > > > o Define a generic extension "structure" in a separate draft, > > maybe with an "augment-structure" extension. Document that > > this is intended as an interim solution until YANG is updated. > > > When you say “alternativesâ€, are these alternatives to Andy’s > suggestion above as well (e.g., a simple note). Yes, Lada’s > comments are valid, but they’re equally valid even when using > your two suggestions too, right? > What is wrong with reusing the RESTCONF hack? /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 Jan 18 11:34:51 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D67D12987F for ; Wed, 18 Jan 2017 11:34:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id StAMJekSc8DZ for ; Wed, 18 Jan 2017 11:34:48 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAD9129879 for ; Wed, 18 Jan 2017 11:34:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5452; q=dns/txt; s=iport; t=1484768088; x=1485977688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=zVf7zV3hTsva3NtsIjo+55noLu4RmBVseWH/9qVUzVE=; b=BmtbGB5NLkY4Igjwu9Hey/ZECLJbKMNaxSaXnruDZUg9Blzq8FgLEUTB heY7y9aMsnfcyAFBoMxyID4cfLNNxomm7wvli1JrAwTa+5Rgyb6oqN7ze gOvm0iRQP/tfDxe2Rrz12xRqYDuA4QB4fpEMsgJaRoaPaXYzXkvZs1i+W U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AjAQADw39Y/4sNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgyoPAQEBAQEfYIEJB4NKigiSApMdgg+CC4YiAhqBaT8YAQIBAQE?= =?us-ascii?q?BAQEBYyiEaQEBAQMBIxFDAgULAgEIDgIIAgIJFgcCAgIwFRABAQQBDQWIewiwF?= =?us-ascii?q?4IlijkBAQEBAQEBAQEBAQEBAQEBAQEBAQEdgQuHRYJphBsRARsBgwYtgjEFlTO?= =?us-ascii?q?GDgGRYYF3hQ6JaI5IhCYBHzhxUxVKAYIWgkSBSHOGU4EhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,250,1477958400"; d="scan'208";a="373398548" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Jan 2017 19:34:28 +0000 Received: from XCH-RTP-008.cisco.com (xch-rtp-008.cisco.com [64.101.220.148]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0IJYSCu021824 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 18 Jan 2017 19:34:28 GMT Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-008.cisco.com (64.101.220.148) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 18 Jan 2017 14:34:27 -0500 Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1210.000; Wed, 18 Jan 2017 14:34:27 -0500 From: "Einar Nilsen-Nygaard (einarnn)" To: Juergen Schoenwaelder , Mehmet Ersue Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAAdJYIAABh86wA= Date: Wed, 18 Jan 2017 19:34:27 +0000 Message-ID: <9945CC82-4AC3-490F-99BD-68361D6EFD1D@cisco.com> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> In-Reply-To: <20170118075314.GA4786@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Apple Mail (2.3259) x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.61.172.120] Content-Type: text/plain; charset="utf-8" Content-ID: <332D1732AD700F4A89D2E4B9A6474821@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: Netconf Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:34:50 -0000 V2l0aCByZXNwZWN0IHRvIE1laG1ldOKAmXMgb3JpZ2luYWwgZW1haWw6DQoNCj4gQSkgTkVUQ09O RiBjby1jaGFpcnMgdGhpbmsgdGhhdCB0aGUgU3Vic2NyaXB0aW9ucyBhbmQgRXZlbnRzIHRlYW0g c2hvdWxkIGNvbnRpbnVlIGl0cyB2YWx1YWJsZSB3b3JrIGFuZCBwcm9wb3NlIHRvIGNoYW5nZSBv dXIgY3VycmVudCBjaGFydGVyIHRvIGFkZCB0aGUgZGV2ZWxvcG1lbnQgb2Ygbm90aWZpY2F0aW9u cyBhbmQgc3Vic2NyaXB0aW9uIGNhcGFiaWxpdGllcyB3aXRoIHRoZSBsaXN0ZWQgZG9jdW1lbnRz IGFuZCBmb2N1cyBhYm92ZSBhcyBhIHN0YXJ0aW5nIHBvaW50LiBXRyBtZW1iZXJzIGFyZSBhc2tl ZCB0byBzdGF0ZSB0aGVpciBvcGluaW9uIG9uIHRoZSBwcm9wb3NlZCBwbGFuLiANCj4gUGxlYXNl IGxldCB1cyBrbm93IG9uIE5FVENPTkYgbWFpbGxpc3QgYnkgSmFudWFyeSAyNywgMjAxNyBFT0Ig UFQsIGlmIHlvdSBoYXZlIGEgc3Ryb25nIG9iamVjdGlvbiB0byB0aGlzIHBsYW4gYW5kIGV4cGxh aW4geW91ciBjb25jZXJuIHdpdGggdmFsaWQgYXJndW1lbnRzLiBQbGVhc2UgYWxzbyBzdGF0ZSBj bGVhcmx5IGlmIHlvdSBzdXBwb3J0IHRoaXMgcGxhbi4NCg0KDQpJIHN1cHBvcnQgdGhpcyBwbGFu Lg0KDQo+IEIpIE5FVENPTkYgY28tY2hhaXJzIGZ1cnRoZXIgcHJvcG9zZSB0aGF0IE5FVENPTkYg V0cgc2hvdWxkIHVzZSBpdHMgZW5lcmd5IGluIHRoZSBmdXR1cmUgdG8gY29tcGxldGUgYW5kIGlt cHJvdmUgdGhlIG5ldyBub3RpZmljYXRpb24gYW5kIHN1YnNjcmlwdGlvbiBSRkNzIGFuZCBzdG9w IG1haW50YWluaW5nIFJGQyA1Mjc3IGZvciBpc3N1ZXMgb3RoZXIgdGhhbiBlcnJhdGEuICBOb3Rl IHRoYXQgaXQgaXMgcmVxdWlyZWQgdGhhdCBSRkMgNTI3NyBhbmQgYWxsIG5ldyB3b3JrIG5lZWRz IHRvIGdyYWNlZnVsbHkgY28tZXhpc3QgaW4gYW55IGRlcGxveW1lbnQuICANCj4gUGxlYXNlIHN0 YXRlIHlvdXIgb3BpbmlvbiBvbiB0aGUgbWFpbGxpc3QgYnkgSmFudWFyeSAyNywgMjAxNyBFT0Ig UFQsIHdoZXRoZXIgeW91IHRoaW5rIFJGQyA1Mjc3IHNob3VsZCBiZSBvYnNvbGV0ZWQgZHVyaW5n IHRoZSBwdWJsaWNhdGlvbiBvZiB0aGUgbmV3IGRyYWZ0IHNldCBvciBub3QuDQoNCg0KSSB0aGlu ayBpdCBtYWtlcyBzZW5zZSB0byBzdG9wIG1haW50YWluaW5nIDUyNzcgZm9yIGlzc3VlcyBvdGhl ciB0aGFuIGVycmF0YSwgYW5kIHRoYXQgb25jZSB0aGUgbmV3IHdvcmsgaXMgY29tcGxldGUsIG1v dmluZyBmb3J3YXJkIHNob3VsZCBiZSBlbmNvdXJhZ2VkLCB3aXRoIGV2ZW50dWFsIG9ic29sZXRp b24gb2YgNTI3Ny4gQ29tcGxldGVseSBhZ3JlZWQgb24gZ3JhY2VmdWwgY28tZXhpc3RlbmNlLg0K DQpBIGNvdXBsZSBvZiBjb21tZW50cyBiZWxvdyBhcyB3ZWxsLg0KDQoNCj4gT24gMTggSmFuIDIw MTcsIGF0IDA3OjUzLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNv YnMtdW5pdmVyc2l0eS5kZT4gd3JvdGU6DQo+IA0KPiBPbiBXZWQsIEphbiAxOCwgMjAxNyBhdCAx MjowNjoxNEFNICswMTAwLCBNZWhtZXQgRXJzdWUgd3JvdGU6DQo+PiANCj4+IA0KPj4gVGhlIGRv Y3VtZW50cyB0aGUgU3Vic2NyaXB0aW9ucyBhbmQgRXZlbnRzIHRlYW0gYXJlIGN1cnJlbnRseSB3 b3JraW5nIG9uDQo+PiBhcmU6DQo+PiANCj4+IC0gQSBkb2N1bWVudCB3aGljaCBkZWZpbmVzIHRo ZSBwcm90b2NvbC1uZXV0cmFsIG5vdGlmaWNhdGlvbiBmcmFtZXdvcmssDQo+PiBpLmUuLCBleHBs YWlucyB0aGUgY29uY2VwdHMgb2Ygc3Vic2NyaXB0aW9ucywgZmlsdGVycywgY29udHJvbCBwbGFu ZQ0KPj4gbm90aWZpY2F0aW9ucywgcmVwbGF5LCBldGMuICBBbmQgYWxzbyBkZWZpbmVzIHRoZSBh c3NvY2lhdGVkIFlBTkcgZGF0YQ0KPj4gbW9kZWwsIFJQQ3MsIGV0Yy4gVGhpcyBpcyBjdXJyZW50 bHkgY292ZXJlZCBpbiA1Mjc3YmlzIGRvY3VtZW50IHdoaWNoIHdvdWxkDQo+PiBuZWVkIHRvIGJl IHJlbmFtZWQuDQo+IA0KPiBJIHRoaW5rICdjb250cm9sIHBsYW5lIG5vdGlmaWNhdGlvbicgaXMg YSByZWFsbHkgYmFkIHRlcm0gZm9yIHdoYXQgaXQNCj4gZG9lcyBhbmQgdGhlIHNvb25lciB3ZSBm aW5kIGEgYmV0dGVyIHRlcm0gdGhlIGJldHRlciBpdCBpcy4gSSBhY3R1YWxseQ0KPiB0aGluayB0 aGF0IG5vIHRlcm0gaXMgbmVlZGVkLg0KDQpJIGFncmVlIHRoYXQg4oCcY29udHJvbCBwbGFuZeKA nSBzaG91bGQgYmUgdGFrZW4gb3V0IGZyb20gdGhlIHRleHQgYW5kIG5vIHJlcGxhY2VtZW50IG1h ZGUuDQoNCj4+IC0gQSBkb2N1bWVudCB3aGljaCBkZWZpbmVzIGhvdyBub3RpZmljYXRpb25zIGFy ZSBzZW50IG92ZXIgTkVUQ09ORg0KPj4gKGdlbmVyYWxpemluZyBzZWN0aW9uIDMuNyBvZiBSRkMg NTI3NykgYW5kIGhvdyBZQU5HIG5vdGlmaWNhdGlvbnMgYXJlDQo+PiBlbmNvZGVkIGluIFhNTCBh bmQgSlNPTiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQtbm90aWZpY2F0aW9ucyks DQo+IA0KPiBUaGUgZW5jb2Rpbmcgb2YgWUFORyBkZWZpbmVkIG5vdGlmaWNhdGlvbnMgaW50byBY TUwgYW5kIEpTT04gaXMgZGVmaW5lZA0KPiBpbiBSRkMgNzk1MCBhbmQgUkZDIDc5NTEuIE5FVENP TkYgZG9lcyBub3Qgc3VwcG9ydCBKU09OLg0KDQpBZ3JlZWQgdGhhdCB0aGVyZSBhcmUgZXhpc3Rp bmcgZGVmaW5pdGlvbnMgdGhhdCBzaG91bGQgYmUgbGV2ZXJhZ2VkLiBIb3dldmVyLCB0aGVyZSBt YXkgYmUgc29tZSBhZGRpdGlvbnMgdG8gaG93IG5vdGlmaWNhdGlvbnMgYXJlIGdlbmVyYXRlZCB0 aGUgcmVxdWlyZSBlbGFib3JhdGlvbi4NCg0KPj4gLSBBIGRvY3VtZW50IHdoaWNoIGRlZmluZXMg aG93IG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQgb3ZlciBSRVNUQ09ORg0KPj4gKGdlbmVyYWxpemlu ZyBzZWN0aW9uIDYgb2YgUkVTVENPTkYgUkZDKSBhbmQgSFRUUDIuICBBbHNvIGRlZmluZXMgaG93 IFlBTkcNCj4+IG5vdGlmaWNhdGlvbnMgYXJlIGVuY29kZWQgaW4gWE1MIGFuZCBKU09ODQo+PiAo ZHJhZnQtaWV0Zi1uZXRjb25mLXJlc3Rjb25mLW5vdGlmKSwNCj4gDQo+IFRoZSBlbmNvZGluZyBv ZglZQU5HIGRlZmluZWQgbm90aWZpY2F0aW9ucyBpbnRvCVhNTCBhbmQJSlNPTiBpcwlkZWZpbmVk DQo+IGluIFJGQyA3OTUwIGFuZAlSRkMgNzk1MS4NCg0KU2FtZSBjb21tZW50IGFzIGFib3ZlLg0K DQo+PiAtIEEgZG9jdW1lbnQgd2hpY2ggZGVmaW5lcyB0aGUgc3Vic2NyaXB0aW9uIGFuZCBwdXNo IG1lY2hhbmlzbSBmb3IgWUFORw0KPj4gZGF0YXN0b3JlcyBhbGxvd2luZyBzdWJzY3JpYmVyIGFw cGxpY2F0aW9ucyB0byByZXF1ZXN0IHVwZGF0ZXMgZnJvbSBhIFlBTkcNCj4+IGRhdGFzdG9yZSAo ZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmctcHVzaCkuDQoNClRoaXMgZG9jdW1lbnQgaXMgcmVxdWly ZWQgYWxzby4gSWYgKGQpIGJlbG93IGlzIGludGVuZGVkIHRvIGVuY29tcGFzcyB0aGlzIGFzIHdl bGwsIHRoZW4gZmluZS4NCg0KPiBQZXJoYXBzIHlvdSBtZWFuIHRoZSByaWdodCB0aGluZyBidXQg ZnJvbSB0aGUgd3JpdGluZyB0aGlzIGlzIG5vdA0KPiBjbGVhci4gUGVyaGFwcyB5b3UgYWN0dWFs bHkgbWVhbiB0aGUgZm9sbG93aW5nIGZvdXIgZG9jdW1lbnRzOg0KPiANCj4gYSkgcHJvdG9jb2wt bmV1dHJhbCBleHRlbmRlZCBub3RpZmljYXRpb24gZnJhbWV3b3JrDQo+IA0KPiBiKSB1c2luZyBl eHRlbmRlZCBub3RpZmljYXRpb25zIHdpdGggTkVUQ09ORg0KPiANCj4gYykgdXNpbmcgZXh0ZW5k ZWQgbm90aWZpY2F0aW9ucyB3aXRoIFJFU1RDT05GDQo+IA0KPiBkKSBhIFlBTkcgZGF0YSBtb2Rl bCBmb3IgZXh0ZW5kZWQgbm90aWZpY2F0aW9ucw0KPiANCj4gU3VjaCBhIHNldCBvZiBkb2N1bWVu dHMgbWFrZXMgc2Vuc2UgdG8gbWUuDQoNCkFncmVlZCB3aXRoIGNhdmVhdCBhcyBub3RlZCBhYm92 ZSBvbiB3aGF0IChkKSBlbmNvbXBhc3Nlcy4NCg0KQ2hlZXJzLA0KDQpFaW5hcg0KDQo= From nobody Wed Jan 18 11:52:15 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81E621298BC for ; Wed, 18 Jan 2017 11:52:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wt31NvJWTDc8 for ; Wed, 18 Jan 2017 11:52:02 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0115.outbound.protection.outlook.com [104.47.37.115]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E594F1298BB for ; Wed, 18 Jan 2017 11:52:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=CaO0bznmDrON2+1py7llXKAukSqw21QxdmXng9RJxjs=; b=HliV62JveTdaPJXseXZlFtaH917saMcVxDfsiE8VJE1EjXSjNOpUX9b+HRzlVj1jGzO5P74pgmhWWyWXTdfxHaBC763UNnG/WaxFwO5OJy67Avu5H48PbzZrWiSmJSeUgtFUKvl0pruLXqy8gY5yK34vwUJmjdhQGSQdc8azE0w= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 19:52:00 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 19:52:00 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22ACAAGvCgIAAuS4AgABu5AD//92dgIAAYncA//+1RIA= Date: Wed, 18 Jan 2017 19:52:00 +0000 Message-ID: <0EC12A2F-03D7-46AE-A348-9FC10FD077E3@juniper.net> References: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> In-Reply-To: <20170118191928.GC5811@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 1d782b87-e8d7-4310-4cfe-08d43fdb7800 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1442; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1442; 7:9dr1kZxzRpK91O/td3ly/6Tj2EvodNXqQiEEQvSrZW9JKO2/azA48dQXG0WTu2QHbfpSYWkq1Ete3FWDi08gV7XRoa1Tv8nxo1+Zg+g+mvdE6Td7gPNntOO/umFwM5loIK9ifvp2o0wrzlejyHL9M5Ufh7Wiovm3EkDWAR+fNpv95vIx+/g55MPMCmQFH9o1ud+Tbx094fqr+QyhD0HdqGzTtgsYmj5uT/oi+ei7+v1Q1kq/do9t+ffZb3kpiXvk8J7qtJPrVrC+SznX7LINXDllUUhaERKsYmUXd3UIULn+kF/MhvML5S7hH/L64olVHfLwu7w16jfNyARlvjgUfv78KL9KtTvuMiWoTxBaL2LSKCBu/EwECzuVx4VwJMyCoqvs3a47owBPyxWDZehZaink4PZ8JqAMLTEtClvkRJCIqThMsFO2ZsL6loH95afPUrXy1GZh4W3giqxSMhsBmg== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1442; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1442; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39840400002)(39860400002)(39450400003)(39410400002)(199003)(189002)(189998001)(93886004)(110136003)(76176999)(50986999)(305945005)(25786008)(66066001)(101416001)(68736007)(3280700002)(5660300001)(6436002)(7736002)(54906002)(99286003)(54356999)(106356001)(77096006)(33656002)(106116001)(82746002)(38730400001)(36756003)(122556002)(3846002)(2900100001)(6512007)(92566002)(6486002)(83506001)(4326007)(102836003)(6506006)(6116002)(81166006)(53936002)(3660700001)(86362001)(8936002)(6916009)(2906002)(105586002)(4001350100001)(8676002)(83716003)(97736004)(2950100002)(229853002)(81156014)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1442; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1E8F7CCD208DBA4BAE3709783C834081@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 19:52:00.8384 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1442 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 19:52:06 -0000 DQpIaSBKdWVyZ2VuLA0KDQoNCj4gV2hhdCBpcyB3cm9uZyB3aXRoIHJldXNpbmcgdGhlIFJFU1RD T05GIGhhY2s/DQoNCg0KMSkgY29weS9wYXN0ZSBvciByZWZlcmVuY2U/ICBpZiByZWZlcmVuY2Us IHRoZW46DQoNCiAgIGEpIGl04oCZcyBub3QgdG9vIGJhZCBmb3IgdGhlIHplcm90b3VjaCBkcmFm dCwgYXMgaXQgYWxyZWFkeQ0KICAgICAgaGFzIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byB0aGUg UkVTVENPTkYgZHJhZnQuDQoNCiAgIGIpIGJ1dCBpdOKAmXMgbm90IGdvb2QgZm9yIHRoZSBhbmlt YS12b3VjaGVyIGRyYWZ0LCBhcyBpdCANCiAgICAgIGN1cnJlbnRseSBoYXMgbm8gcmVmZXJlbmNl IHRvIHRoZSBSRVNUQ09ORiBkcmFmdC4NCg0KDQoyKSBpdCBhcHBlYXJzIHRoYXQgdGhlIGRlZmlu aXRpb25zIGluIHRoZSBSRVNUQ09ORiBkcmFmdA0KICAgYXJlIGJvdW5kIHRvIHdoZW4gdXNpbmcg dGhlICJhcHBsaWNhdGlvbi95YW5nLWRhdGEreG1sIg0KICAgbWVkaWEgdHlwZS4gIEV2ZW4gaWYg bm90IHRlY2huaWNhbGx5IHRydWUsIGl04oCZcyBzdGlsbA0KICAgZ29pbmcgdG8gY29uZnVzZSBz b21lIHBlb3BsZS4NCg0KDQozKSBJ4oCZbSBub3Qgc3VyZSBpZiB0aGUgUkVTVENPTkYgc29sdXRp b24gaXMgZXZlbiB2YWxpZC4NCiAgIFRoYXQgaXMsIEnigJl2ZSBuZXZlciBrbm93biBleHRlbnNp b25zIHRvIGJlIHVzZWQgdG8gZGVmaW5lDQogICB0aGUgc2NoZW1hIGZvciBpbnN0YW5jZSBkYXRh OyBJ4oCZdmUgb25seSBzZWVuIHRoZW0gdG8NCiAgIGRlZmluZSBZQU5HIHN0YXRlbWVudHMuDQoN Cg0KVGhhbmtzLA0KS2VudA0KDQoNCg== From nobody Wed Jan 18 12:46:42 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 895651294E0 for ; Wed, 18 Jan 2017 12:46:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 IZYJeQx7_bN9 for ; Wed, 18 Jan 2017 12:46:32 -0800 (PST) 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 308D112940D for ; Wed, 18 Jan 2017 12:46:32 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 066C46D1; Wed, 18 Jan 2017 21:46:31 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 52xz9_kMj6gG; Wed, 18 Jan 2017 21:46:28 +0100 (CET) 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, 18 Jan 2017 21:46:30 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id ADF5A200A5; Wed, 18 Jan 2017 21:46:30 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Yzu2hcfa0mTU; Wed, 18 Jan 2017 21:46:30 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3B3FC200A3; Wed, 18 Jan 2017 21:46:30 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 992C03E29D51; Wed, 18 Jan 2017 21:46:33 +0100 (CET) Date: Wed, 18 Jan 2017 21:46:33 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170118204633.GA6080@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "lhotka@nic.cz" , "netconf@ietf.org" References: <3713983E-FA82-4A4F-A84D-8E8D86DDF18F@juniper.net> <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> <0EC12A2F-03D7-46AE-A348-9FC10FD077E3@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <0EC12A2F-03D7-46AE-A348-9FC10FD077E3@juniper.net> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 20:46:36 -0000 On Wed, Jan 18, 2017 at 07:52:00PM +0000, Kent Watsen wrote: > > Hi Juergen, > > > > What is wrong with reusing the RESTCONF hack? > > > 1) copy/paste or reference? if reference, then: > > a) it’s not too bad for the zerotouch draft, as it already > has a normative reference to the RESTCONF draft. > > b) but it’s not good for the anima-voucher draft, as it > currently has no reference to the RESTCONF draft. > So what? There is always going to be a references, unless you define something yourself to reinvent the wheel. > 2) it appears that the definitions in the RESTCONF draft > are bound to when using the "application/yang-data+xml" > media type. Even if not technically true, it’s still > going to confuse some people. I do not see this in the description of the yang-data extension definition. > 3) I’m not sure if the RESTCONF solution is even valid. > That is, I’ve never known extensions to be used to define > the schema for instance data; I’ve only seen them to > define YANG statements. If this is true, you have to stop and wait until YANG has built-in support for this. /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 Jan 18 13:41:47 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3961D1294FA for ; Wed, 18 Jan 2017 13:41:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 PmpxMK5sA_Lr for ; Wed, 18 Jan 2017 13:41:45 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EB5D129437 for ; Wed, 18 Jan 2017 13:41:45 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id 70FFC1AE0455; Wed, 18 Jan 2017 22:41:44 +0100 (CET) Date: Wed, 18 Jan 2017 22:41:44 +0100 (CET) Message-Id: <20170118.224144.1071069280674363799.mbj@tail-f.com> To: kwatsen@juniper.net From: Martin Bjorklund In-Reply-To: <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:41:46 -0000 S2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KPiBIaSBNYXJ0aW4sDQo+ IA0KPiA+Pj4gQW5keSB3cml0ZXM6IA0KPiA+Pj4gSU1PIGl0IGlzIHN1ZmZpY2llbnQgdG8gc2F5 IHRoZSBtb2R1bGUgaXMgbm90IGludGVuZGVkIGZvcg0KPiA+Pj4gaW1wbGVtZW50YXRpb24gaW4g YSBOQy9SQyBzZXJ2ZXIuDQo+ID4+IA0KPiA+PiBMYWRhIHdyaXRlczoNCj4gPj4gSXQgZGVwZW5k cyBvbiB0aGUgcHVycG9zZSB0aGF0IHRoZSBtb2R1bGUgaXMgdXNlZCBmb3IuIEl0IGRvZXNuJ3Qg d29yaw0KPiA+PiB2ZXJ5IHdlbGwgaWYgaXQgaXMgaW50ZW5kZWQgdG8gYmUgbm9ybWF0aXZlICgi c29tZSBkYXRhIE1VU1QgYmUgdmFsaWQNCj4gPj4gYWNjb3JkaW5nIHRvIHRoaXMgbW9kdWxlIikg YmVjYXVzZSB2YWxpZGl0eSwgWFBhdGggY29udGV4dCBhbmQgb3RoZXINCj4gPj4gdGhpbmdzIGFy ZSBkZWZpbmVkIGluIHRlcm1zIG9mIHNwZWNpZmljIGRhdGFzdG9yZXMuIEl0IGlzIGFsc28gb2Z0 ZW4NCj4gPj4gaW1wb3NzaWJsZSB0byBkZWNpZGUgd2hldGhlciBpdCBkZXNjcmliZXMgY29uZmln dXJhdGlvbiBvciBzdGF0ZSBkYXRhDQo+ID4+IChzb21lIFlBTkcgcnVsZXMgZGVwZW5kIG9uIGl0 KS4NCj4gPj4gDQo+ID4+IFNvIHVzaW5nIFlBTkcgaW4gdGhpcyB3YXkgaXMgbm90IHJlYWxseSBz dXBwb3J0ZWQgYnkgdGhlIHNwZWMgYW5kIGl0DQo+ID4+IGlzIG5vdCBndWFyYW50ZWVkIHRoYXQg ZXZlcnlib2R5IGV4dHJhcG9sYXRlcyB0aGUgcnVsZXMgaW4gdGhlIHNhbWUNCj4gPj4gd2F5LiBD cmVhdGl2aXR5IGluIGludGVycHJldGF0aW9uIG9mIHN0YW5kYXJkcyBJTU8gaXNuJ3QgdmVyeSBn b29kLg0KPiA+DQo+ID4gTWFydGluIHdyaXRlczoNCj4gPg0KPiA+ICsxDQo+ID4NCj4gPiBUd28g YWx0ZXJuYXRpdmVzOg0KPiA+DQo+ID4gIG8gIERlZmluZSB5ZXQgYW5vdGhlciBvbmUtb2ZmIHNv bHV0aW9uIGZvciB6ZXJvdG91Y2gsIGkuZS4sIGFuDQo+ID4gICAgIGV4dGVuc2lvbiBjYWxsZWQg J3plcm90b3VjaC1hcnRpZmFjdCcgb3Igd2hhdGV2ZXIuDQo+ID4NCj4gPiAgbyAgRGVmaW5lIGEg Z2VuZXJpYyBleHRlbnNpb24gInN0cnVjdHVyZSIgaW4gYSBzZXBhcmF0ZSBkcmFmdCwNCj4gPiAg ICAgbWF5YmUgd2l0aCBhbiAiYXVnbWVudC1zdHJ1Y3R1cmUiIGV4dGVuc2lvbi4gIERvY3VtZW50 IHRoYXQNCj4gPiAgICAgdGhpcyBpcyBpbnRlbmRlZCBhcyBhbiBpbnRlcmltIHNvbHV0aW9uIHVu dGlsIFlBTkcgaXMgdXBkYXRlZC4NCj4gDQo+IA0KPiBXaGVuIHlvdSBzYXkg4oCcYWx0ZXJuYXRp dmVz4oCdLCBhcmUgdGhlc2UgYWx0ZXJuYXRpdmVzIHRvIEFuZHnigJlzIA0KPiBzdWdnZXN0aW9u IGFib3ZlIGFzIHdlbGwgKGUuZy4sIGEgc2ltcGxlIG5vdGUpLg0KDQpObywgc29ycnkgaWYgSSB3 YXNuJ3QgY2xlYXIuICBNeSArMSB3YXMgdG8gTGFkYSdzIHN0YXRlbWVudCB0aGF0IGENCnNpbXBs ZSBub3RlIGlzIG5vdCByZWFsbHkgc3VwcG9ydGVkLiAgSSBwcm9wb3NlIHR3byBhbHRlcm5hdGl2 ZXMNCmluc3RlYWQuDQoNCg0KPiBZZXMsIExhZGHigJlzDQo+IGNvbW1lbnRzIGFyZSB2YWxpZCwg YnV0IHRoZXnigJlyZSBlcXVhbGx5IHZhbGlkIGV2ZW4gd2hlbiB1c2luZw0KPiB5b3VyIHR3byBz dWdnZXN0aW9ucyB0b28sIHJpZ2h0Pw0KDQpOby4gIFRoZXJlIGFyZSBubyByZXN0cmljdGlvbnMg b24gdGhlIHNlbWFudGljcyBvZiBhbiBleHRlbnNpb24NCnN0YXRlbWVudCBzcGVjaWZpZWQgaW4g UkZDIDc5NTAuDQoNCg0KL21hcnRpbg0K From nobody Wed Jan 18 13:46:48 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55C731294C9; Wed, 18 Jan 2017 13:46:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xNaKCmO7z2EX; Wed, 18 Jan 2017 13:46:42 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0122.outbound.protection.outlook.com [104.47.33.122]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54E9D1294E6; Wed, 18 Jan 2017 13:46:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iW6jsQv4C5pzHT4vE7S7e/Ocaj+fUApSPpq9dOHJ9uc=; b=HcZBdGyIHwfbt/tRReaI3rguPcvGQU3HsvOu10qVBrdReKI3r1/5Y/ROA4n0pOUgFO0qN6EinYyjeXpiHFF+YvDwaNCPnOrFof3vwpouW748i1NxP+pgWCfDBBb8ixPLGDY1lmQZg6HCwR85VjgdCMbbZQm++Gm8DU2eP9CDO9g= Received: from BY2PR05CA026.namprd05.prod.outlook.com (10.141.250.16) by CY1PR0501MB1292.namprd05.prod.outlook.com (10.160.225.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:38 +0000 Received: from BN1AFFO11FD032.protection.gbl (2a01:111:f400:7c10::142) by BY2PR05CA026.outlook.office365.com (2a01:111:e400:2c5f::16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:37 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD032.mail.protection.outlook.com (10.58.52.186) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:36 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:24:41 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILOeQ6015351; Wed, 18 Jan 2017 13:24:41 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILKbOB039223; Wed, 18 Jan 2017 16:20:38 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201701182120.v0ILKbOB039223@idle.juniper.net> To: Juergen Schoenwaelder In-Reply-To: <20170113085137.GA23063@elstar.local> Date: Wed, 18 Jan 2017 16:20:37 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39860400002)(39840400002)(39450400003)(2980300002)(199003)(189002)(626004)(6916009)(8936002)(54906002)(2950100002)(2810700001)(1076002)(7696004)(38730400001)(110136003)(229853002)(5660300001)(48376002)(47776003)(81166006)(8676002)(81156014)(50466002)(86362001)(189998001)(77096006)(2906002)(92566002)(8276002)(69596002)(5003940100001)(4326007)(50986999)(54356999)(97736004)(106466001)(105596002)(53936002)(7126002)(53416004)(305945005)(356003)(76506005)(68736007); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1292; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD032; 1:inCefVsGkLhwVsRow2xJzZ2HJvEkXfD0CIgSYuvZKHNRZ409nMk5dAj/Y9gwgvkCvlaIdMM5X7UPJ2ZBeSpawaXVsKYBGMo7AkYerzul2DiFSU0NZJLxes0sMDCI6o1PjzISazmBxTVGFWi3OE1oM7I8qTSGuCSTD6g1DWMbDCDJHGfpFGDIdwyRe3eV0BFzzps62wQf/+fB28bSNoVnMIljxXfxKJIBTOTewUPTrV6VFVUgntvqVK/cNb+XndBeiyJwPQVf5T4YVqgeFpJKrt814BCno+BKdR8JxwD8EzuB4zXrKjidlmS7uKqD3qQYsp3y7T2Xq+hNdsGtX8FB6kGsIylCeN74r+S3kE36J42GJGAKsACoLhfZVdRBhztHLUS0EOiZ7W9n6ckULnhJ9Wjq9znOSVueRqZ4ZrbJKgOPHCBIBOORilEYB/31bx7CQFKowTbfMcr68izTzfsXnIN22bxHJGPFtX8EwlN3CphHUE58b1DPBYwlKthBKLoOHKpYqCT18SJg+xrJTaiKqhP5ApZlsyYyDbTiWiDiN12aVIeyjG85wzIQlJ7v0dr2 X-MS-Office365-Filtering-Correlation-Id: 61983c56-bf0f-4799-d46a-08d43feb7a8b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:CY1PR0501MB1292; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 3:A04Iqfc/CrHm03sMDVGK6p7Wjb8WO8tphQislLMe+/K6gcX/jlbVHexUHNQg7wDcHL+oF+AzjdcmvnR+BX4es2sm77mILgzpY8ou/n+Dd/0td/SRjFMxzJ6bllVwqXS28yqhzdkhzOIjA4hmJQtmFNnEI2sxlySzD38UvvxUpX+T2lILQZgorkagAq5pgcMsXNBlo4Gz5AtgzbU5R+iW3E+BEs65vFsFTn6XsSbpfKS8dCP76M3i1LAXvQnEUGBB4Ou5uqITVpTcgBMaPbHp9ZWlFAPnvL5PqkBGD9nKXfiE9BxfA7cMxr+zAjkySauQDtac8G8mSy34SSarZv/52/plHNlnbRDmXMFFOWrYacI0385qoY+gAnL8g+jXLzJZ X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 25:qHkkFLYE4RwOIm8IyjKQGW0I/9jPG7pidR5mEve8I2J49ja1oYXJazy7sWHav+6S+uGfSCzYiX0UTtciO+yWEKNoDsqm+/TNsQWSFQQZ2tbx2fVXcEfDQ2xQysEAfq/wV46GeiCslodXGrtiDOAkn08ij2gaXzMSVDAL5Vt4DHqKHWOvPOAeY6Nbakt2evS/CBDoFkcd2wwrPzy70Slh0oVUoFR6kfB3b3w2I2PLNMCpTxWw+oPVYgneZypfETi92hI1iQ1AMQbgjls2PhxVF6GsfXy9pYZM6JSZTpgSq199F66aLqVshqXiomkpPnpobAYBQq/nnRgJWNTkdN+sViiYWvPEqTvOSuUPFfa8Vb/QPRlHxm1v4LAYTohQTLPSzI6g82vvmZVri13W8dEXxwSmzpbgLVri3VtXytmb9EdXJjqo4baUsn3lrXykGRhaD8lw5GwcazTnTUpM74U13IVBcMWETX7rN7y6bdxA6AMKme2UY1tvrwNzkZBoRujvDtECJMr19+ND5alYAGGPrnriRwMmEN7WTUhPnSfJJoBlCac9ReZpJdrT2KXv5kmi1IM/PKykbV5n+7/yg1VS0KUHbhb5PRYAmP8IIlrjDAueX7/iVAxeCOJTPGuLrgGtHmY5KFZ+1kgy3gUhEFYEQZCi7Wp7I06/kg/XnwOGBZdpMJoX075Sou3KmGMShHjPracl/6c2AHlUao3Sm8agYZGKA9+o9QfR6u+PyWv/08jD6pDLNrQCpE4ns4xEOeyw+zesXkf/cwkjqArlqR4PbqktE4wlwdfk5Hr+xXzIsFo= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 31:2Y2A5dLcSvfYdJcEuPO0d4ry+xk+qQuWzlU/O6jNZe/P0wROdeKBqoRZpTKFTRWVZp8Prm6ndeJLItH9yeh3UlT5ux07zPoV7N5DSp9qfiMfBo1g/m55k86CrEcMODIZ8TjAQR9/bKV2B2wk4E3sFgtxo+H9/sqXiNeVQZBuSqhzxrD5ol5LiZWpzmmui9TBUMXd2h8t5xM9fQrvwK6YCSNadSTjpKkAOj0DzgdjyetFNP+MM1oQtHyhpl1JVbbVOegnL3l9RcJU9I0K9DyKwA==; 20:OfkztcBhvasZi7+u8Tw+T6LMflz3NTbfwlpiyKL2gF6P2CfWchGk1c2YpC9QQgYeszo9Ez8LIVCQEpksKn1H6/EBOPtULVWkgy7mHDGIsX/qh5BpAuerZHAB/azmN5XS5kUiPY4XbXFu9E1lDfyTwvSb0NDfHdHosphngF1jWmpcXWvsGAfG9PBwPMtPoc5wRlLdTMneEngS4uOZDDf5I3sH+T5X7LA5GXUuuDNRtShgRzLLGtWq0kNMPOTxDKHU/PSd7vmABxmGNadkYAME803cCLzqQk9hEVbDZioI+GoRsk+DL59XH+IeiTwFKgIEG0qL3MKlZaHZat7cjWtbVj2PLlDzHH0IZI5CfdQ34Ozz1HVuopzIJFcD8EPIn0TDAAikFRMoX8zmryKGOvVgn2wUDGT7IMe5aceaEF5DxK2Efp0LZjpUPZlBuL28PcI5DfWFPlJkyY6tkVwOfbsbP+sMZwollMjTnnN33jFLf41QuMbStvmQnC529YwZCUmO X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863)(211171220733660); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(13017025)(13023025)(13024025)(13015025)(13018025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123560025)(20161123564025)(20161123562025)(6072148); SRVR:CY1PR0501MB1292; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1292; X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 4:aSw0oVfq5J+Edaf1NHbiK1Tw2xY+cvp7vjKFfxFIdZldRoffEtqYlzDDTgjojhDJtrEDT7EnWnBQsUErTImKARp/P2e2BEyGOM6z0YWrrfkag9f4St0bSIecIFNLMVV5jCA6ShcTiQ6oSnKlNyKni1hXLZDRhCCBWhVdKNB92E498bFhDsjSZqqw8jmt6vjCSjZZ+6bq1eDmUz5HoKl8S9Fbee7F26i8xG9akpWLl6PqxRpxgXrzvxXljybxTJjDGVDUhCi9xiSQlW0Kw5fIL4ahQmpA0ZtWO2dLTD6cEFQbXp8Z4yGC/cQQ6R0EYPzUQt/MzGCnDBsh0c5PuScf8metka9na9vCdSMOg9jSXXZwrLEtF6kJzWkatdfz5ik76ksDzt/KPklhXoH7ucNc9GVcVrbipQPUUTkxaQ+jfOAFKGDR2IJzZYRHhikbSwXlViBOuBwuavJbyiYNb7Cu6AoNufCzagMVLzxA7v89yu+r225LO04w1bABy3mJPhiX3mNA3pD0y2Fog4wnrFTCrOMFaFRaxYKBOs78dADUBGAQc/BjaNCHTnsN4ZhwtPEFmbv26coIWoPlexJTcPycViozrOJEE8JiZ9FddMZmNhdeK8NGtrfrSi0yvuqhUbM107zyDR05AY1F5750oWT118Eew1C2Jz6pNDFcUeW2nglWSp/mj9M+T4oYcZR+53hGTcfxFAP3cY7HzbG9atZ9u/SWgiwL/dkEHywLlGWI63wdEusAPZ15Q030Ej4bR8qp X-Forefront-PRVS: 01917B1794 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR0501MB1292; 23:xJ3XjSavUXr2zREsYayeTQJhHRt0UTbNOKfns4w?= =?us-ascii?Q?6BA35BybdwUJ15kx0lKht4PPLhWQKDZsX9c4P16YmmeK599Pdz24T6do51ti?= =?us-ascii?Q?xXaJ5c6ceSQdkIYqsJ5mmtNPteouRlAkjHPejiADX9J7EtWX5wZBTJ09Bcc5?= =?us-ascii?Q?e6pVy7e8YG/AtlYOMSuy4nE7pPV/NnO5IybyRujmlvKiJWUp2NOiqft/kDCa?= =?us-ascii?Q?SUwoBRJx5sTmF6IUK2Lm+yBhGLf1pLe3Bq5exnKi5B0HVUQZJ4g5r951fUq2?= =?us-ascii?Q?tDJTKdLCdhOKafEqSUmNiP56XfFUT/RM+ozp4RdJOTv9qMeg6DJpTCvcsorO?= =?us-ascii?Q?BwmwU/Mofwb9YQZf3Lemf0vtA5aeG9sOWsW0teoeu+5lTon46flTH3ZIfkU6?= =?us-ascii?Q?BVXruZxOJTYDVlREzLNnZkYWOkM/f8NtKPnBMxgAkfrMdLiYBTNbhF2zyYTp?= =?us-ascii?Q?HQM7+ulKZxuBw7qN95JYfQ/RNP4t5FGKuGH1zx8wz4/mj9nZ065xIOelL5Qp?= =?us-ascii?Q?uqKJKYwFE7RXzeEqHd73cJY6uYD02kLBahF+DTxDqONAU5jZnbgEV/gBnbnA?= =?us-ascii?Q?q5sIis/oFTQdFjhLJrtLeVeIrdJUSph4QsOQzZtZWHfFwNy45xxgWQQmLz42?= =?us-ascii?Q?fFjFHAD78/7mppBN/mj/5PFD91vA5jPWPi5y837f0pkKomB6Z40+UtpqaSg7?= =?us-ascii?Q?nLe6fb+ujd4S5+tOuYyAryOrGlz3faeOv+AyiPNzHhUfphXPK8J8h0dlH+wC?= =?us-ascii?Q?HAXmTGzSZZ5b2a2Q/s6VNEaePvYf0HwstIQ4fEhXUyuOFraNl6aFoaMT/6Gj?= =?us-ascii?Q?3gj9Ni6bFEhmTLTJnL0vUEtOog8LLdHLsWgVXEa/dB26Q49gkkHhE8CkSRY1?= =?us-ascii?Q?CvwahoiK64TRGqwvsafmPf/S2hcCKDjRqozlQnK5l4nKC0u4vMzWhNC555JY?= =?us-ascii?Q?tzet8JW/0GYOftsKePjnmByRj9XwmVL28yiIVGTNOZhIlolc1bpPTAln4QAC?= =?us-ascii?Q?nPS9eHCxnzNzoe4A/1za/VxKXAdjzTaQScb53rS+z6pUCufhA4Gj+6ZCPXPg?= =?us-ascii?Q?Bgv+k/IX7EmHV1E0X3U6hkOYHG2gxI1gtN9QgpiN2IvIXnzBWSwIGxQ1QnBM?= =?us-ascii?Q?FydpFU70V2WUBzBfQErf8hFVD2AGPg0/3+xTMn7Xxqbp8OCIvbIn9V4eidOc?= =?us-ascii?Q?jrAO5HOwTKZMi303ztgVYPZJQRRjp/dlGcmsC?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 6:2mT/mdqn5s6dq/6irz7x8Wv5HyskWSRgJYWC5d1WqHAye/N3wgG6iPbofjHe2SZWnbFh9Xvc3VFDLRwqQ55l59WkRB2cWeCaBzwyhQnh1Lr3bDpD56QGvNcBoz9+4ibYDk03+56czPO9hb0zgZgE/6zXlVnRwWgYr7z9rw0lUlSOnK5jYYkEfpLwfIeCHtVog2BAuowpn2vEp6tRZSlq0AEYFIBW9v1/K8DVgpK4QkZzsOa4N+5o6wq0TouT/YdsCVA+BCXMV857Fg28N1DEoTRvt2HBnhtlbFA7LyQZmBWOo3MWpOlYCJeFUGXLkxghJivDG4CgAog0EYqTq4+AZfgdDIO+Av3X1rEA4H4ieXzK8QNbiWP7Xv/qrbokhO1+hAc70tnGyVEB+tYhP4TjZ6hrSbhZUTNb1jvGlp98az3++BCUebrmyo0QjHW/X+gOic4T2NBpwp8XQDlaqzQ/yQ==; 5:II4/RuPq59y8rE9RwUzrYGx+g3PS48ms5KdZLVkCz6vrXNvPd1LYzPo4zvOQD3Clni7qbPjnRywdVSeM16aKDPnfK7AjJUA/2lMiGjHB4FFa8zYkWbLbT5+45AnigATc2hyIt8E5bAGdvYgAmQlU6A==; 24:srrBZUAeUowpSLpf3EjMO7aGjirOca0RN1TO4TPoy9fo3nwXMaK/SjXVDbIfgmWuQeuys/puKw4H0HX0dx75Xz40yCMKuCg6dDb1EUy12lE= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; CY1PR0501MB1292; 7:Oc5ou5TNK0FPZs2SUZ5sBuXreK2RqITmkPIhv0TW63RXcux71VaZQ/GK7VR6x+KIpjbHixaAD2SihJGbA4nj41x1I6liQm8yhyAqIEt1JwlE3GAcLHEUrxZSqrF4/iDwwy3uxrZPTkqA3NDWPbfrLWV3AkHHnguT30kSQ4FcWiP6x8dfUDX9WYFZMVUp6E+B+ggz+JiDpeVC5Ck0ab0WZRw9u7/tre37Fm+OIS5GVYd9F0iNwWW/sReTSU+sKHGJgZ/XkGbt7vFYKm4sgvkwP6aYaMYsXabJshrauPCMAiYdMh4f8A6IMc3Gl1MDpFaHklrX5gAKn/oKH2mibFOSy+3P9WqZ3v9Fi/O5OcSaVKInXhpC7klIOTgUwLKURPkiRAZkkGJvYTyT/VjbRCyOp38ep1Wa+IvtEyK+w56nOHO5ugGQ6SoxV6DK/2JNj2PHnrsjmUHRas+9udRVsdMTag== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:36.8343 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1292 Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:46:43 -0000 Juergen Schoenwaelder writes: >For operational state data, it is not entirely clear where and when >validation will occur or if it will occur at all. In fact, if a system >is in a weird state, it might actually be useful for certain purposes >to expose the weird state. And, as Martin pointed out, inconsistencies >may also result from the technical difficulties to take a consistent >snapshort of a system with several concurrent subsystems. For these >reasons, the assumption that a server always returns valid operational >state data is likely not true. Amen. It's more important to give data values that are accurate than to give values that can be validated. The client wants to see what's going on right now; raw, real, and not sugar coated. Consider the case where a list is limited to 1000 entries, but as the device is reporting the list, entries are being created and deleted. The result may be that more than 1000 entries are emitted. But we would not want the device to be forced to stop at 1000 just to avoid breaking the constraints of the data model. The client should be prepared to handle operational data that does not conform to the constraints of the data model. Or more exactly, we should be describing the constraints that may be violated and example scenarios where it might occur. Some constraints (identifiers) should never be violated. Thanks, Phil From nobody Wed Jan 18 13:46:55 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 595731294E6; Wed, 18 Jan 2017 13:46:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1j-LqyD13p5V; Wed, 18 Jan 2017 13:46:44 -0800 (PST) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02on0090.outbound.protection.outlook.com [104.47.37.90]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BAB6129485; Wed, 18 Jan 2017 13:46:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UF0Qa8l2HiHRV3r4cXfMf2Xio4BKWMti1KdQ9NE0kZE=; b=FWvViPYgvvVo/H3/Y4VJYXnVSiKsnWiDlIHocqoAPX02Vwxw3OCoRwJzlWZsiSQ8eqcSJPMVZ1/ylL3zmLwAAPYDRwB8Ywq00DmhFMCmos8dVpK2nkA++7zfwDM25A++/eyqmrLt3ED6y3+3n9iPZE2JwMG6r3DZGOs8xS3Nbqs= Received: from BY2PR05CA025.namprd05.prod.outlook.com (10.141.250.15) by DM5PR05MB2937.namprd05.prod.outlook.com (10.168.176.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:42 +0000 Received: from BN1AFFO11OLC003.protection.gbl (2a01:111:f400:7c10::105) by BY2PR05CA025.outlook.office365.com (2a01:111:e400:2c5f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:41 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11OLC003.mail.protection.outlook.com (10.58.53.74) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:41 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:27:27 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILRQq6015814; Wed, 18 Jan 2017 13:27:26 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILNMdm039284; Wed, 18 Jan 2017 16:23:23 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201701182123.v0ILNMdm039284@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <9A8B650F-E224-42FC-8987-FBF15CA4D614@nic.cz> Date: Wed, 18 Jan 2017 16:23:22 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39410400002)(39850400002)(39450400003)(39840400002)(2980300002)(199003)(189002)(106466001)(50466002)(105596002)(50986999)(81166006)(8676002)(77096006)(1076002)(48376002)(229853002)(8936002)(38730400001)(97736004)(626004)(7126002)(76506005)(5003940100001)(4326007)(92566002)(68736007)(54356999)(53416004)(305945005)(86362001)(81156014)(47776003)(5660300001)(54906002)(69596002)(189998001)(110136003)(356003)(8276002)(2950100002)(6916009)(7696004)(2810700001)(53936002)(2906002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2937; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11OLC003; 1:AuHzWw98UVvI8UPwr3uMSRpxGN+InXVBwJ2bI4BW0a2dXIaAPn9ypet3b6PnfpgnQ9Z9kE4UE3sbedvRsEi+FNdtOk6nRcoXOSJUP4NYhATuWS6kN9JcjpJmZePZ9AQWaKv22p+a4mM3NKBykiERUO3TtGVey+gwBy+lAERjpkkBacEV0pijLXXBqIcBHDrUMSK5tGijhFhSLMJWU0VCaV7KQd34wtwzFK3ARxtI0yMpVOYnuAznwybPH/UWOnUBSGjbRf/cZYoVxnCRz63N543IlJfrkSBQOoHrUS4sVfsK6NW+PQhfejN5IzST253whCfqUc0Jfo7pk9AGQpBCHFNS2dVOxe/s3Lx2MQA4kHehFivwZeXr2iXlsijWKjfQcyV7HHDaONlwS9Qo11tZcvcDsRTAFN++I8I8pI6KgvxYwzf3WdgktCvSET5x9d5dK8QLTJo6TszojTxAFiozdDKhY/9/9en+09DN6UMO6JdA3HJ3lBIdzcIdQOdSLa+OoIqLilBFlne2+MhE6hM1rcGxGxs4J26TcNEwMd4Eioi7zGA7CFq3aSGhooPUdOL3 X-MS-Office365-Filtering-Correlation-Id: c3ebe50f-120a-431f-f455-08d43feb7d58 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2937; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 3:RForVYdLJ1qlrW2e7jXL6HTBSAhfXgw7Myn11ZQ8Lbu8BQGmzZFtpu7U+9UwF3sod8UafKveTRJRYOqhdLcjkZn18hNxm5H9iGqeZ9Coo/UWPtiAYdn2I2CwQ0L4L/+r9YcSQ2DfaEWXOLt9BNU6PgpaU+sJZb2BVLn1qhbPcsT/dHuqmNZ8VDkqNWzZNiIgkt9uoneC/GsAKJmBq/m8as8d/pAR+jwxI34kadMQohlNTZhCh9tN9KV3nE9H0beAGK/SHOeSw8sQl6LRc9SKr3b1kqRVALJxg0liRkQqMGve5TgcVDAvOqFzCxOFu+EGFUPyEinQemBJ1iQfEGKKV2bHYwn+jK6GVWacs6tqa3QxHcYW9lBy3Nj43UO1micJ; 25:mho7XZdai7/wWeHkP1Xga/71thQlNjd5HHqHT2X3ukSs5Slsfwfus+YEj0kBlth1Dr+H0qQ6VSRDK7rrRXU01qc2jzAlIZ2H6T1S+An67zfnjLwTnUy9eGeP0JaiAdNEn1EhqBFnWMOE4WfLStzcryNktXwr1LqXjtNAQkB9FYJWiH2/nTy92hRTXuen6YlryXATEVRTxgNP6WSyQiUDfpZ/SCAuhnG0OP7yNtA8/U1xDlcm3/jMyjDs/zCcnUSeV8MgcWZYW0yJwWZIcfdWZSS2SAO6DmE3p650gYuEqgHE6Dfa+Z4/c9vTr3yl4BZDUl9HMMb0PkmnKIUOcpnN37KyDuqAiwAdEO5sovQyfeGQ65OT9WirSNJQCa3Hmq1sHw8Mdlf7eFbKEDn7W2pfMGD+9wfPnImgdSqyvKfY8+dChPNCoNpak4toPkOQE+g2hjPkXqQyAvVpoLrMn/2gVA== X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 31:bofFXnuVwQz1TmS64ca/iaxNtXMqQSyFX9BIe+IennD3+a3XrHQn08+PK2dDW7z5rLo6KBRvBEW1C+xGjoqoSSdkmTeUM5Kg7wx0kvXG5pMQ+/vTq4RN8tFBDUaAoirIwVDTOX+xvc6cTmCW6b+6x0ziwV8LA4EgTwIOMSstL80SZseJAg2aDxz95Nk5yD5RgTUFFhfdwlIp4ukRXRnEiHi9DOaL278KHNeHUbcGgnPcT6qzfHpcNg7Ydyp0pPaKNLe38XKxdVQIM8ZqZJ96ehH0qqpSe+ZOkepbwsg+gUo=; 20:2WcEZDqYIcrq5WD4rnUJiTrZa3DrVyyo/YyFyugbJaKVR6Tzil4KgbG9B2zMcC/sW0xNeHv+ypdw+r/k/T39IcmIR0CZrROctZsUrMSY85U4srVxs8hq++4heQvMwtTSBJ9+FES96eIHplw3j/ImkCUB+8z7GyN9ErsWAxFCnHHOdMcq1Z4p6nve+UnJtAyi8OCZwtxcCqr+fhmiQFsLVe+XJkxV3Mcv6xdiTFNEoMgxWgEY9nQDQxT/wlVUwBt28MVTzJCJCAG2qkwby5xL1KuEvmB/sTa+CAjmdiXGDS00m2fDp4N7vo2/40FaFqx+yvWeC7BzBqi/V36L5j+dOczG7JtzZV0Fa/YSnSIq6wF5iufucvP6cmKD9iMbfnXbAQp8AYz/dHfPFxY03pui6Ne5nQ3bYGf22FTLH0gO5leASFAfXkBGCpYCeZTmGYwxKQpTKzPs6Wj0Zrv/cBjuTTH6/9cWYv/RDj4E6fMz6AkWnNluqU3mx1nDbPDVxrwH X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13024025)(13015025)(13023025)(13018025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR05MB2937; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2937; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 4:Apdl7/1mejPH9z8EB5DnJSRK+L8uhtnvvySFmW1w4bnM4IxJvW49m5kMU6PkBQNvTcKY6u4jazHg3Hj73O0SZPwc/LENlKtfOC+N7a9z89SedMlG9X9ejRnOG8ffHPMEMxCmFFVlLy3Z+/PGu7Mbjy9zYDa+70VSnvDfBIiY4iS4wOXn2fMeVHGsTZoEKdG85sqvy7Hh+kkBt4enH0tfq/iWehyc3xme5551DpB21kNGw/WPUT7BK8xz2tHC/Qyvo6f2CmwgKaVQQkSRdP/ujJQARkOxfBQ1j1NQw4RJJjWLutgIucEImpq5SXDalKCCjR7nZOwNxI6zrCWXQuAXWT6kWiCVo5zGWCs/OCvPHnolHn4rVij6xtoAxgc7woau9WLzKLEgzk/hmEdwd+imxNN7jWbwW+kFDTln6YJ90q0pvbqdVOpavfZzG85w5oZUPlpOt/bjNkPThd6p50n3djNDpagLi7GeWd0ORX0T6y+krZpGc3uI9LveBH9QnvcSZ0dhitt5LDgKaVkMPwGPWCYGpkoQQ5LN8H4IGIxTDYJ28S90Z8BnkdHtJNAryNrFd4Ah2UdpzfjRyTGfEZXe8YOkQ4o/Enpf/kCJtNymCnDu5idN2ePCv8O+dffMYSpR4obYPZxoqO6GqbbsFFsmI9ak1Aa5+bcgXaQxKfv44l9N6d3v1h2ERVFbsUEZtn1r X-Forefront-PRVS: 01917B1794 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2937; 23:sqScMQl7gZJTq5symCzs3pjrGuJDACI8ekM8nv39k?= =?us-ascii?Q?amZD4n2JCJdUWO11xUTyGRy/V3M037n7uxztkdPjzyMERWrcc8KD5NLX7Qj+?= =?us-ascii?Q?wVCr5MI+V0y89DNuWuAZWc8Dxl2gPcCYQV0dItAU/TJXdBit6wrERohxasNe?= =?us-ascii?Q?eiC+EjipB3KB/yIRm/gOpjJCgksMpfJRkIEFTobamxVPzB08y7gXjyK9ZWgo?= =?us-ascii?Q?wSZGCxLpoanpfdFp3qZrhTC58trefhmNfMDrTcMvc9M1fSksYzxwYUHJzUtl?= =?us-ascii?Q?fG7DeGx/eB7ni3MWCZfQ4mfuAxpxXTsvdwf70Ys7kDrVodzXhuP2lIYhq2WF?= =?us-ascii?Q?qnGLkQky7kOaaKqVIQNI/2Gaq0jGWSFAtWUJhl/jUde8Lu27xPwrk32IN+xJ?= =?us-ascii?Q?Pc08NhBRVonRDxg6efwsnvjqufIfefdPfdT9EE5COIV5hkFFPky3dwS4GUwX?= =?us-ascii?Q?eD0bDWVQXWEajN+EysCwyJ05mms891FodXVhrzs/Glecwsr3hTmEAl1YeIP6?= =?us-ascii?Q?YfczJK7QT3IZDu5TSDEOBGOED7yezfveFrUcv3LcAA74d04WaraB0BFyFqya?= =?us-ascii?Q?eRfEApF/leD08uaBPLnZKy/nV3y9/eKhn1NKS18hpEY11t/hWckjuWoAVZnW?= =?us-ascii?Q?kC+n5rJ4xk8+rcsYEXEeUKJ/HNx1TevEuzqcglGmRMH9Y59NClhWOvy3YWo0?= =?us-ascii?Q?YY9oj1GgPf1ra77aCjdcSFq50pENWcxggk32vvs/Olagn+ku0H4mgyFpqEUQ?= =?us-ascii?Q?oXbLdBFQia88IhkVIMJOdFu5LT1I7z+Mav19szsyFFLByMrsmvC8qBtuK2Yo?= =?us-ascii?Q?L5VZI9iJTQ5Y5YYZQL3pTczEnfuTOl23xiGjWOquifz57Oh5P/6wv+V3H4ZN?= =?us-ascii?Q?PPWK5ihiyLqiNVReLuhuKBygt4S1Q8EL53BPz0DX8o2qBof5DwQ/oxm9SaPh?= =?us-ascii?Q?7RH343rKtx/gXw5zO2zqB4uA/FCsUgprK0gEPz1fW01IzFy4PcpMgZKzphON?= =?us-ascii?Q?6Xtuzd/yZKJHTCM968VCvDQkmLfrHMtyj3IRopKdRAbpvaoTa8zngRZMwagR?= =?us-ascii?Q?HhjtRbqxgLfop7HGHmwZJYYkfZwb7U8VuVlVXPPozAFAcgB3luKYKmrSxacA?= =?us-ascii?Q?5Hv/CLRfBPymmHUNnLvM+Wh1cXRfV9+J8PBuqS7xxneuMU3frjnJgZiWaH+7?= =?us-ascii?Q?XGKy0LlCkUbMCVVKtBHVYFn7EHos+sakTCQ?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 6:M8mDgdASCBDGcZrGkqaekkGZ03dfT9g9vPaHxF2pZNBNnJZyFyfiG7CY5xXRBaVdwhsI4TOtUj7Lrzk20jjKyk5D/brCMkKauo3YlCPHX4bV0Kvp97w0rqFCrAT5ujnVcuTlvAiCFxQtPylRnSzS6qRCEw7Hix1uHxXBGMtyo+mcihvZx71R5oT+tBmVrcmLmTv528UTBcwhy0uT03HwvkJHFJ5J+CoO6mwBrLQCvht/dnEMg+/aZxNAl5yaAw6Y+k57TlVO6+yVtHfWjUXXXq38u76slJydoVqUrQK6fRYTKrs3K6H6zCt8eXv/McK8ZAg+cN3p0wRHo8V04p5720ymtnUUjZCIzUZIM2QNSS1GBxnFsGRUf/IVfRxcMYv4Qa67i2UkGTMmM3zEho8MPF7uvxTf5pyJM4Xdo3lZKDrbgn7oByxzkPFPsdlpqALYSssk2Eahtn4Qgu46VFiH+A==; 5:+lvP7gpAVoGyjfxvlHspdeiy9nb2ZvtGQwe3Uz5AjYDa0nWn+uCrhDUZu5T1zcOmfmIYLaMvcoX9AuqkSxdYcftai4ZHnQzgDz8LXIJUhH/ui5liRme/V3Pue0EJnupVh1gDYQajdUb5hyZVKIMIyQ==; 24:Y1r/84r6Fzh+269wJ1voAeZTDQPbYnniqJ/wGY6lH/vN0qsqQ5Vn36VcNFJEDF1fsmC7SE0YIj50yf9GkozY5aehpshxdV/BlJ4rq6O4aNQ= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2937; 7:LoJ58OB1DCb8t9vKTXPKhfoLc1f4Sae1Jh71ZXE0P2RS+njZSKlc6IVxpHUgXNAe2knL02QCsA8/O7N1TnMsT4+JTsS9bqTYJ+tjEp62tvXFgkCrpGd8Oc1FsNEkgEOS9gMHuMMdbUV+dBrVWAya973u+Wv1hnbH+ZVKR2XgvbZAOg5CYoo2KQRJ335tKnTrcu3Gj93uTLLlL+pSD3Gt5WO0OaOWIhjj+bYY4JWzFKgtyrJd24gMj3qXhvPUNG+f1yovqfIthuDNs5cuNefQgQqOb2BYElYl1zWhPiX7hcg+injIxEkF/ofr/z4m5Gm9RuoMhMJYn0NK8qIpkKSYDxBCeDVAo41oKas8TNgUKK8hv949OWzso+qu6C73mPQORdmfH7se3EsBjeorgy+RTewPfzSudOzmzzk35xYk5p+/ABEz3JyBxqwLIQruXzdC0j5qijeNH+kOEesHdJsZXw== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:41.5340 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2937 Archived-At: Cc: Netconf , netmod@ietf.org Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:46:45 -0000 Ladislav Lhotka writes: >Which doesn't mean that inconsistent (format of) state data is >acceptable. My colleague develops a BGP looking glass, and it is >really a terrible work because he has to do a lot of screen-scraping. >Each time a vendor changes the data format, he has to update his >software. I keep telling him that our nice protocols would save him >from this drudgery. This exact scenario was the motivation for our XML API all those years ago. Your colleague should be happy using a NETCONF/YANG-based solution. Thanks, Phil From nobody Wed Jan 18 13:47:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87B3E129587; Wed, 18 Jan 2017 13:46:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLreQu7rrxlf; Wed, 18 Jan 2017 13:46:48 -0800 (PST) Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0106.outbound.protection.outlook.com [104.47.33.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F0F7A129437; Wed, 18 Jan 2017 13:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=iCieYXPsWf8fopqp1f1IXRFsceRn+jCp00t/WxeZtLY=; b=jA3a1ntJKRXVKFRvft2oRKRbOgvQLYLvGXvgf7ixJfo2TUOewrBnlNtXHKnFNIazR1aA5Eu9WJofZ77bIPUum85t0BSgjxC9NVRTjrVR6VigH003vcfl9pL4kCbau4+XDyIBKYHOoWVNEsKjCZgtsWYQ6Sarxlyr2Evv0kveL0Q= Received: from BY1PR0501CA0040.namprd05.prod.outlook.com (10.162.139.50) by DM5PR05MB2940.namprd05.prod.outlook.com (10.168.176.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 21:46:46 +0000 Received: from BN1AFFO11FD030.protection.gbl (2a01:111:f400:7c10::164) by BY1PR0501CA0040.outlook.office365.com (2a01:111:e400:4821::50) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6 via Frontend Transport; Wed, 18 Jan 2017 21:46:46 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; tail-f.com; dkim=none (message not signed) header.d=none;tail-f.com; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender) Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BN1AFFO11FD030.mail.protection.outlook.com (10.58.52.168) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.803.8 via Frontend Transport; Wed, 18 Jan 2017 21:46:45 +0000 Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 18 Jan 2017 13:30:16 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id v0ILUFug016389; Wed, 18 Jan 2017 13:30:16 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id v0ILQC6h039302; Wed, 18 Jan 2017 16:26:12 -0500 (EST) (envelope-from phil@idle.juniper.net) Message-ID: <201701182126.v0ILQC6h039302@idle.juniper.net> To: Robert Wilton In-Reply-To: <67fae2eb-faa2-7bc3-4763-51a38296233b@cisco.com> Date: Wed, 18 Jan 2017 16:26:12 -0500 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39850400002)(39410400002)(39840400002)(39450400003)(39860400002)(2980300002)(189002)(199003)(1076002)(110136003)(5003940100001)(69596002)(76506005)(54356999)(2810700001)(7696004)(68736007)(50986999)(92566002)(86362001)(53416004)(229853002)(2906002)(4326007)(189998001)(38730400001)(47776003)(2950100002)(8276002)(7126002)(54906002)(356003)(106466001)(6916009)(626004)(5660300001)(81166006)(77096006)(81156014)(8676002)(305945005)(48376002)(97736004)(105596002)(50466002)(8936002)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2940; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BN1AFFO11FD030; 1:S8XP/YqNZrmPrTSlShAMwlrfpHG3UR0tGQx7gC7K6Yi+3H9XErXndx+CKUbiYOk4hDqQxSfA51QTrXkG3BbfOhIQ2nc/ARqhw0kZhAZkEaDFZPhNQqOurQiV4UDNpYOvH6RmVYx76PCQW5lMlCC4xYesi1EDbpic7/CnIcoFurZ3hDGeJu7AC6KGR65Xx4X0kpBebf6msyjGEr41/MY7k7TIk63V2aUkqKX0b6zLkFION6uQFuuvfpWoIwdhc1OB2ivKwIooiDqjazHEZOtlJGkqO5r1QIpMPKrcwrYNgLKH0kOLY5XLLAmehVb+/KKuoh66seZYbNLga2mf0bXi+qmrY6bpNc2jT4B+tyrvC59/bLn/eqIDtdWUxUvv7UMNx7auFC0uyLGpggeN3gSBEGnFu1X0+S5FHMKHs2M81/bj2JWddExwhM5eScFzQeYdWHEmiHTQrCB3wzxKc+93z6LXIrz2aAmruunm8LlABbo8E9KUlGGn+3qVOKsnz9teSrYEGDVwz/8Xmd4zme+Kcel/JcnRHcHxW4UJ54vcoz0UCCcubSF67IciH2BmIJjK X-MS-Office365-Filtering-Correlation-Id: e5d1f461-ba64-411c-66ef-08d43feb7fe1 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:DM5PR05MB2940; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 3:z4vb5s01ZMATQXF+OMXbHisaKS81t4iTPH6ZorWV8qqxF/QAQBBDh/t9uduOubKKH5pA2/U9X0uuemBvcNhtmXUZhNKWZGa+y8j4rrMFxs2mffTek7rVYjcy7MuIHgvHjEb1dxvG/qrYEEvnpjBDCsYIaqNrLyWdsC3s1As7QwfCMBbARJ0DBX9HxePvt/oaAG5UCvtJheaW2F2sSNRmQarqmbIRmlfcdfiTOpTtSSbVmUQjTzCgS75Og0QHspgNguQFuWIeGu8jvgPlQ6PKWru3oOi/7wg6A4zWX0UeVXgWXhks+BT5cG/ZCpLsqScCpgGceWRx8hhQIiEsdZJpnOEatrbBwnqXlvYwnMO2zIiAvz0+br6zyzJyVKVo7ciZ X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 25:lxSGxTqjSYHnI04FFTgBFv5LeTv6eld9XjRQCfH+3AOmDzGfapgisYJnieyTrQY8GHym3A97Kj2wEg2+4fSPUsneSimEI3Eb+pkDrUEwWhpw8yP82d2csXFZ+y2CBJJ4/M4JlbGPAR2xmtDirI91lPwNWC2Dn3Wq2Q8AnH7s4xTxlbzalyMtby2DKN43FN399Bn0pR83uSaiWNnWJilWRnTKvyuGATLaSnSQicaMiSH2RnLXC4KWbRm4Wb4C0Jb6kmEEyC05g3OXv0c/5VUv4xxboMwe27IrNQVi8/RbqG2eaeSO5IRjy/bvXEKVpcPRbwrjslZJl8oHavywOIX7ojT0dCGgfmtPZe7Pmb4EZP8daIo/7y8FfQuwB7xdaDZNvZITzWmqkYQdZx3nZvKAoKFcue6oXavTWWBbsQ8HikTyiw6LqLKwDKMW/THD9og4wJgsaMBjmqI4yr6NoSrGxrImKhQwjIQtw6qb+PGxHkFKBr+c2XyxmiONXa7EdFFrPmpPJOv3QfvY049LDWJaY1DXXX0r+oQOUfGf3B7fiBTfCV02bOP1D48Z8CrEwK57TXyxonYJBSKTc4Tvfg0yLMNCkyJl0TPZg8hCAMD275LnsV5HdjNir2j0vmSmk9k0j0HA0TWNPEuRFi+Jpj3auLNLm8YMzdNzRr+LYXYf2KWNhhcKlCx97MMY7ibnE/l3HC9ncj7SpYWTiYlAf9X1Yh9HEMjTh9+DCex6D2lOpJTcBGnV8aLG8o3sr3P4TuNHpA8QNv5F2tbCT9HJ4uqZ+A856HeT8wqQ+KErNQGU5KEluo48S7TuSEbseLOsvVz6 X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 31:a4UQGICSE6cl/x8ULBXAVU5jWIBhU5CAE4hR2dDGyciv7QJlej4yEd1C2E0ryXF4w+QcuOIB8/mO1B8wu0RDnMzLOSJGLaAljwiSbcL1UHut5f+DVjoju4UYlLf2fCzZS42hdyNmxazWju1ZNEu8ct2GAnZTgTLuWUum0c1fcuMDoIKl3384azyKQxISTWBxUUUEYKODrnqbINrbQKfMe+qVOtRzpBm/6H907srkOUlyBWUfrieG78+7d5S3adSIP8bQJQ3ARcR9Sl2QUrI3mQ==; 20:ndjw2vhkpkiVyaTputuxdsgHn7wD5i7pIaJIFBnpd3USztDIcKD/BGqfGBnbqTBibloV9dnnMiqf8yAf9boqfzalpCTvvHQv1jwKqve+VbnyD+SOTe6VeLBVRnm1LtrwraYPauKbk5sOVceicc/vC3NPO/ZlYP+x6uckyWG8V81uIk9senfHVyuW6iN+LSimoOh+yMQkR/m0VJoiArILt1SNqdfnELsWOCl6jZQPFYwomuAYJgXKzn1DWOusmJoBE04V7R31ZBPrD4X4mFkFbNJlAkBPKt07paEaZifIxZJXCcW3NYK4w/5xha2/RPPPNcDelNy+xZ7keyNE1clKhUB1sURQEpgPRtgwtUpdpqFcDpk4IBU495BAArYlGH7l4LM3s4fVdNg+GvQ2il2iMkqBsJfC6nwFXnjtKYhrMoZ8TZxTo4pLQBRQ8SBIDmrDbv3YQ5bOEFQiogGnIYXA5gWhlVA0M5VnRqtbr0ajA4HALefGihmB3nZaz9Ppf8KN X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(158342451672863); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(13024025)(13015025)(13023025)(13018025)(13017025)(10201501046)(3002001)(6055026)(6041248)(20161123555025)(20161123564025)(20161123562025)(20161123560025)(6072148); SRVR:DM5PR05MB2940; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2940; X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 4:PjB5w0vqLwxUGAHXcCGv5OMjX5DjryQ34jjtL7mLgbMhTujRLnt9/ZejbJCnYihyozlJqM16NFQL5MFJH+e4cCr6SFJ6xvcqIV+NwRyVv63dpW5A3yYih50UYtvBgFIfeCP/kOQDrQePzyr4X+nUXQ3v93f1RV0VrPGppVUS+yz1faR/J9tSp6bYssFBEe3TA6nnJgu4wEfyBKlSjFmNKd/hWyGYbjT/GhVcwoOo3LeLbGemgdyg3pliIkBz7YfvN/ta9dFHgvfQrS/Grtb7XC+weMF6UCtI2fuWXrm90Q3Cz3UHLAC4yWJeznug1C2/KThSokZBbGjgmjTrG/MPZ9KKwGf3LSDqh1H6JOpbou8/o7aAd8s7BedC9IPmTud4lkoDBQ4I82Gxus0x0JJDUsItMEQwDg6cd/phnTFWfMX5PAvYJDJbSH+WGwRtlT/Vgz5lxs+YLPkyWiu4TAzaexL7Eb+4hgtab31sInJ6AV7pYL/KhakvBMiELrkKHALcLzTeqh4r+Cu8fyuL4MZ9F5PepRsAOQ8lLz8d0l/zr2P2hieOksRVibvHj2PXeL8Iawp6r7cMcfujdVTJDpWkTe+vNjPOxtG6Dfz6GJ3kdKgiEdRRERW0uV2kpdwquKz4qFR5Bzpd/lC9tqdo4tgteXP7YtVbeBohMBae2D+LyIlP266b0WOPdmF2YkB4pFA73tLPvPnSbxWWq0dNLJLT1i3wbSpjyVg5aWA+dxfEr0Q= X-Forefront-PRVS: 01917B1794 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; DM5PR05MB2940; 23:zoQRsif4O7bNwGcT9vIH89lcyg7Ib+8wOMbYw/3bX?= =?us-ascii?Q?uFf7yCrdAAfP3fgio2gMPdZPUMN57NaSPYUIQcyn/2ibkt8DNzWdK90Gfquc?= =?us-ascii?Q?483eL6RYIP4O+2TFMMFjdBJPc6YSFoGB/s3fW6TAFZeC7rksJKJOfcxjsuAE?= =?us-ascii?Q?El1esOo3p+QkzskLGmVwt42yeVRctvME3+lqWLn7hir13oIORW3V5b/d/6CR?= =?us-ascii?Q?l3GvzgxwFPBQIBSW9SajfNSR6LLJUsC2ya8FIhsRkiHD3UTOUm+7vRiQGQfN?= =?us-ascii?Q?zxPYt8idfk8r4UWLOuEET8sofmXaqJrVKlXTd1AEg9IKxuyPb/z03V8NZxWa?= =?us-ascii?Q?RZTeRmhd/hS05ObSxrtexQ6Q4IvYlsSVdBIeooeE8swOwbStn7y/F+681KQ/?= =?us-ascii?Q?9H3oC+STQB8aCp3UwdzmETTFjCXQgCw1Ak7VIIa97a4JLeT1omIcxUIMlSGP?= =?us-ascii?Q?vJuoCitsJqv/UJ8dAp1HnEUOdbCUTZyP1ibg0ObjMG6Wfe+v5D5u9jem45LH?= =?us-ascii?Q?7PYJ3mzDvgqphZE0y+fkfOMaXcD3Xu5mHXcP3MBeBC3XsL2D//ANdLfeFvqT?= =?us-ascii?Q?ILwqKYc0eyfIcAGvvTbL57Do10tU2zpcycaInw82ZazFWHyHq9DDsAFneyza?= =?us-ascii?Q?nKiSlqXyYazQU/6dtjptT6fgjCwYokJWX9YkjpR8Ro58+gTjZPmxNlBYmc97?= =?us-ascii?Q?tEE6dEU5+ybG9PRiwuRBiY9eFL/lms4puKAnd/Ud3dvbsb8JauOQ5duwXdr3?= =?us-ascii?Q?dAWX7M5es0/7HE+fgy9hYFJZGV2cVOZptn0dYjmLgVyaj9Qpw0nBAuG1m/n4?= =?us-ascii?Q?iVQ2cz8dYrQJUmwjLxIAQiLVopmn2may1bHTBq1wJXOnyUbfe9iaW4WT1y3I?= =?us-ascii?Q?Qxi2jzfeDhiC23VF7tzbgExy76Ea8zfkqeZuf7zLgqt8toD9WXK12ApF6dpL?= =?us-ascii?Q?1oTJlGuh/neUKA/MhHWMc9pmeaKJ5oA+NOekHYmswN1RTUch8zbJw7y6BSyj?= =?us-ascii?Q?zktmkl03IjDKc4MGOMTXnARlAz6ZPIpOdE4vrw21pWtY1S5WRCvasEQs3cC2?= =?us-ascii?Q?PeFy/9wJZk8PBRBWzH6RTy0H3L64p6gilinBjRJ8jgwQ2vuYbvicqPtJ/2SN?= =?us-ascii?Q?fBqLtcH75WnbEtB7fhsiiJsGn4J0qkaa3baxliDzHotqwjr4DEkr4QhGPC2T?= =?us-ascii?Q?9AmQetrxtk1E4VKs+X9hNPOehSnrBPsN7FY?= X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 6:is4cWJ9Dr8GdndGEYbP+fT4yvwJQymiKA51A22nRHbjqgbuytvNF/tnsAQXhhX5elKA3q0+y0RhYPvKXSH+Bx6OlW8ZjCXC1VscdU5DNgb/rEZF8MhexZhOHn468XUJQ1pAhIedBjX3CAQ+mrVDq8NATj6OZG1CL5nzebxLg3uHbKIIhCEdwdvYUDfkZc2bYla2oer5Lf2pvLo8/HnZF6QCC1inyd7gsep2rQ9W32zMs1+cr8omGLOsgxZrYWHBP59yiRiBgw/mL0OmQfbtZ0gVt/+USrIsLzwI/WvZrxCl5/p3rfVHGoa5L7mPOJJa/sUWHxjsGdY9XiT8f+fW7yDMJRduhhB7Lb8+JzzxIKdGNFWU9LXXMYlu3kCrkINU5hYOZtGsPvKoiHS5dqQQHm17SelwWujBoUkFQJaSC4CqC48xDQWFcAvQPpG6a10VEen7LNl9GlzLHdkKGoszzpw==; 5:vWORmfmWkBpWANm582sZynbK5sZ7EWCYmY0p9hDJP2/abWtyuoR0NMeIq4zcgv2NbGK6gHJHVLVDscnNPlipTDO8DSaydS78aynTkL119zhNGTOEDEGDXQqV9oZQaXEsEVjQAqhwmzL0KY3wJ0+aNw==; 24:n5d8T6UF/071KOvJaydjTEm+iWuDA4vyjkWrPFJVWUJkMitf7mEwD6cTnU9rphzklqylLuDP5lbxKU1tCX9r2/4E5OJ4++D75z5sQ7sqNxs= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1; DM5PR05MB2940; 7:pDYoVbsowoqhdmDAXgpDP+LXoewxST4wMzS6Y2l44XD/mBHYKZXMMkQ5omcP/WQlV2TA1P8hyDdqEEdjgufvzw4IBC9j0qZBGIjJT13RAOKYBQC/sKs97+KElz6aAg5pac7ubZXlg9F3Y6IDGKp4eMLQw+Ki9cd6WCX3t2y2xyhmd3inCgfJvBXFvbLg5rvCYZ8mofaGHQy41YoHqknkD/zpU/2P7m9QUS0fyH1iiFQ8zcTaOXga4VcFQvlhS8Qc6O+vlZYSakc6Ht5qKzMiB5wb/Pjh05C63nYEVdv34DwA4mr0tLLrbxzVkWjTa0Mbp2j6H3rV0XPpBu4jrp5g5uFHvdQlQSyIg0xt1WWuRa6ng19lDDe90QACZeE1sE8Jh/YTgrNT3fNI+0WNy/1hkbqq2JXq1kexsrdre5Uo7mztzBeXQ1YjQuTlPzp1ZJeC7sX1eN8fV8ELqtlHh4lGmg== X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 18 Jan 2017 21:46:45.7681 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18]; Helo=[p-emfe01a-sac.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2940 Archived-At: Cc: "netmod@ietf.org" , Netconf Subject: Re: [Netconf] [netmod] Decision on the Intended Status of the Revised DS Draft WAS:RE: :candidate, :writable-running and RESTCONF edits X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:46:49 -0000 Robert Wilton writes: >> The server is buggy if it is sending data that violates YANG constraints. >> If any of these statements need to be different for config and oper >> then the old style YANG has to be used instead. >You just have a separate state leaf. These are still allowed in a >combined tree. We're trying to avoid a "separate state leaf" solution. That's imho the motivation for this whole exercise. Thanks, Phil From nobody Wed Jan 18 13:50:42 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AA961294E6 for ; Wed, 18 Jan 2017 13:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 mdLsPV24Alxm for ; Wed, 18 Jan 2017 13:50:36 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A1816129437 for ; Wed, 18 Jan 2017 13:50:36 -0800 (PST) Received: from localhost (h-13-76.a165.priv.bahnhof.se [155.4.13.76]) by mail.tail-f.com (Postfix) with ESMTPSA id DE9261AE0455; Wed, 18 Jan 2017 22:50:35 +0100 (CET) Date: Wed, 18 Jan 2017 22:50:35 +0100 (CET) Message-Id: <20170118.225035.2264295466067988883.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170118191928.GC5811@elstar.local> References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 21:50:41 -0000 SnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHku ZGU+IHdyb3RlOg0KPiBPbiBXZWQsIEphbiAxOCwgMjAxNyBhdCAwNjoyNzowNFBNICswMDAwLCBL ZW50IFdhdHNlbiB3cm90ZToNCj4gPiBIaSBNYXJ0aW4sDQo+ID4gDQo+ID4gPj4+IEFuZHkgd3Jp dGVzOiANCj4gPiA+Pj4gSU1PIGl0IGlzIHN1ZmZpY2llbnQgdG8gc2F5IHRoZSBtb2R1bGUgaXMg bm90IGludGVuZGVkIGZvcg0KPiA+ID4+PiBpbXBsZW1lbnRhdGlvbiBpbiBhIE5DL1JDIHNlcnZl ci4NCj4gPiA+PiANCj4gPiA+PiBMYWRhIHdyaXRlczoNCj4gPiA+PiBJdCBkZXBlbmRzIG9uIHRo ZSBwdXJwb3NlIHRoYXQgdGhlIG1vZHVsZSBpcyB1c2VkIGZvci4gSXQgZG9lc24ndCB3b3JrDQo+ ID4gPj4gdmVyeSB3ZWxsIGlmIGl0IGlzIGludGVuZGVkIHRvIGJlIG5vcm1hdGl2ZSAoInNvbWUg ZGF0YSBNVVNUIGJlIHZhbGlkDQo+ID4gPj4gYWNjb3JkaW5nIHRvIHRoaXMgbW9kdWxlIikgYmVj YXVzZSB2YWxpZGl0eSwgWFBhdGggY29udGV4dCBhbmQgb3RoZXINCj4gPiA+PiB0aGluZ3MgYXJl IGRlZmluZWQgaW4gdGVybXMgb2Ygc3BlY2lmaWMgZGF0YXN0b3Jlcy4gSXQgaXMgYWxzbyBvZnRl bg0KPiA+ID4+IGltcG9zc2libGUgdG8gZGVjaWRlIHdoZXRoZXIgaXQgZGVzY3JpYmVzIGNvbmZp Z3VyYXRpb24gb3Igc3RhdGUgZGF0YQ0KPiA+ID4+IChzb21lIFlBTkcgcnVsZXMgZGVwZW5kIG9u IGl0KS4NCj4gPiA+PiANCj4gPiA+PiBTbyB1c2luZyBZQU5HIGluIHRoaXMgd2F5IGlzIG5vdCBy ZWFsbHkgc3VwcG9ydGVkIGJ5IHRoZSBzcGVjIGFuZCBpdA0KPiA+ID4+IGlzIG5vdCBndWFyYW50 ZWVkIHRoYXQgZXZlcnlib2R5IGV4dHJhcG9sYXRlcyB0aGUgcnVsZXMgaW4gdGhlIHNhbWUNCj4g PiA+PiB3YXkuIENyZWF0aXZpdHkgaW4gaW50ZXJwcmV0YXRpb24gb2Ygc3RhbmRhcmRzIElNTyBp c24ndCB2ZXJ5IGdvb2QuDQo+ID4gPg0KPiA+ID4gTWFydGluIHdyaXRlczoNCj4gPiA+DQo+ID4g PiArMQ0KPiA+ID4NCj4gPiA+IFR3byBhbHRlcm5hdGl2ZXM6DQo+ID4gPg0KPiA+ID4gIG8gIERl ZmluZSB5ZXQgYW5vdGhlciBvbmUtb2ZmIHNvbHV0aW9uIGZvciB6ZXJvdG91Y2gsIGkuZS4sIGFu DQo+ID4gPiAgICAgZXh0ZW5zaW9uIGNhbGxlZCAnemVyb3RvdWNoLWFydGlmYWN0JyBvciB3aGF0 ZXZlci4NCj4gPiA+DQo+ID4gPiAgbyAgRGVmaW5lIGEgZ2VuZXJpYyBleHRlbnNpb24gInN0cnVj dHVyZSIgaW4gYSBzZXBhcmF0ZSBkcmFmdCwNCj4gPiA+ICAgICBtYXliZSB3aXRoIGFuICJhdWdt ZW50LXN0cnVjdHVyZSIgZXh0ZW5zaW9uLiAgRG9jdW1lbnQgdGhhdA0KPiA+ID4gICAgIHRoaXMg aXMgaW50ZW5kZWQgYXMgYW4gaW50ZXJpbSBzb2x1dGlvbiB1bnRpbCBZQU5HIGlzIHVwZGF0ZWQu DQo+ID4gDQo+ID4gDQo+ID4gV2hlbiB5b3Ugc2F5IOKAnGFsdGVybmF0aXZlc+KAnSwgYXJlIHRo ZXNlIGFsdGVybmF0aXZlcyB0byBBbmR54oCZcyANCj4gPiBzdWdnZXN0aW9uIGFib3ZlIGFzIHdl bGwgKGUuZy4sIGEgc2ltcGxlIG5vdGUpLiAgWWVzLCBMYWRh4oCZcw0KPiA+IGNvbW1lbnRzIGFy ZSB2YWxpZCwgYnV0IHRoZXnigJlyZSBlcXVhbGx5IHZhbGlkIGV2ZW4gd2hlbiB1c2luZw0KPiA+ IHlvdXIgdHdvIHN1Z2dlc3Rpb25zIHRvbywgcmlnaHQ/DQo+ID4NCj4gDQo+IFdoYXQgaXMgd3Jv bmcgd2l0aCByZXVzaW5nIHRoZSBSRVNUQ09ORiBoYWNrPw0KDQpZZXMgdGhpcyBpcyBhbHNvIGEg cG9zc2liaWxpdHkuICBJdCBqdXN0IGhhcHBlbnMgdG8gYmUgZGVmaW5lZCBpbiBhDQpzb21ld2hh dCB3ZWlyZCBwbGFjZS4uLg0KDQpJIGhhZCB0byByZS1yZWFkIHRoZSBkZWZpbmlpdG9uIG9mIHJj OnlhbmctZGF0YSwgSSB0aG91Z2h0IGl0IHdhcyBtb3JlDQpkZXBlbmRlbnQgb24gcmVzdGNvbmYg dGhhbiBpdCByZWFsbHkgaXMuICBJbiBmYWN0LCBleGNlcHQgZm9yIG9uZQ0Kc2VudGVuY2UgKCop LCBpdCBpcyB2ZXJ5IGdlbmVyaWMgYW5kIGNhbiBiZSB1c2VkIGFzLWlzIGZvciB0aGUNCnplcm90 b3VjaCBhcnRpZmFjdHMuDQoNCigqKSBJdCBzYXlzOg0KDQogIEEgc3BlY2lmaWNhdGlvbiB1c2lu ZyB0aGlzIGV4dGVuc2lvbiBNVVNUIHNwZWNpZnkgdGhlDQogIG1lc3NhZ2UgZW5jb2RpbmcgcnVs ZXMsIGluY2x1ZGluZyB0aGUgY29udGVudCBtZWRpYSB0eXBlLg0KDQpJdCBzZWVtcyB0aGlzIG1l YW5zIHRoYXQgYSBjb250ZW50IG1lZGlhIHR5cGUgaXMgKnJlcXVpcmVkKiBmb3IgKmV2ZXJ5Kg0K dXNhZ2Ugb2YgdGhpcyBleHRlbnNpb24uICBNYXliZSB3ZSBzaG91bGQgaGF2ZSB3cml0dGVuOg0K DQogIEEgc3BlY2lmaWNhdGlvbiB1c2luZyB0aGlzIGV4dGVuc2lvbiBNVVNUIHNwZWNpZnkgdGhl DQogIG1lc3NhZ2UgZW5jb2RpbmcgcnVsZXMsIGluY2x1ZGluZyB0aGUgY29udGVudCBtZWRpYSB0 eXBlLCBpZiBvbmUgaXMNCiAgcmVxdWlyZWQuDQoNCg0KL21hcnRpbg0K From nobody Wed Jan 18 14:29:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA58C129568 for ; Wed, 18 Jan 2017 14:29:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 MkhExMdeqBmd for ; Wed, 18 Jan 2017 14:29:00 -0800 (PST) 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 4CD001295BB for ; Wed, 18 Jan 2017 14:29:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1C8586AB; Wed, 18 Jan 2017 23:28:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Q9zZgwY0pVOl; Wed, 18 Jan 2017 23:28:56 +0100 (CET) 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, 18 Jan 2017 23:28:58 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8F4C200A3; Wed, 18 Jan 2017 23:28:58 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BTVB9QD3WyYK; Wed, 18 Jan 2017 23:28:58 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3F508200A5; Wed, 18 Jan 2017 23:28:58 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id BD9DC3E29E7D; Wed, 18 Jan 2017 23:29:00 +0100 (CET) Date: Wed, 18 Jan 2017 23:29:00 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Message-ID: <20170118222858.GA6215@elstar.local> Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, lhotka@nic.cz, netconf@ietf.org References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> <20170118.225035.2264295466067988883.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170118.225035.2264295466067988883.mbj@tail-f.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 22:29:03 -0000 On Wed, Jan 18, 2017 at 10:50:35PM +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > What is wrong with reusing the RESTCONF hack? > > Yes this is also a possibility. It just happens to be defined in a > somewhat weird place... > > I had to re-read the definiiton of rc:yang-data, I thought it was more > dependent on restconf than it really is. In fact, except for one > sentence (*), it is very generic and can be used as-is for the > zerotouch artifacts. > > (*) It says: > > A specification using this extension MUST specify the > message encoding rules, including the content media type. > > It seems this means that a content media type is *required* for *every* > usage of this extension. Maybe we should have written: > > A specification using this extension MUST specify the > message encoding rules, including the content media type, if one is > required. > I think zerotouch somewhere needs to specify the 'message encoding rules'. In case zerotouch supports multiple encodings, it needs to specify a way (aka 'media type') to distinguish encodings or in case there is only one encoding allowed, the specification needs to say that the content media type is a constant. Perhaps the wording is not optimal, but I do not consider the wording problematic enough to justify a copy and paste action with a subtle wording change. I am concerned about having to deal with N variations of this in the future. /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 Jan 18 14:52:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1888812964B for ; Wed, 18 Jan 2017 14:52:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rpn7lHYzGyaX for ; Wed, 18 Jan 2017 14:52:22 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0111.outbound.protection.outlook.com [104.47.40.111]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 510DF1295C5 for ; Wed, 18 Jan 2017 14:52:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=1vJlRlw/t+hW3wBcjwK5vWxnyhvypibht41qHZexm1s=; b=fdDHHbcNuQO85AQVWv2MkGX21kFzrz3AktNpTG+4QjCi11oJmmFHZt+7ZJ3Fi+BX+SGibi8y71KeqvCHEYx1yyEef+2DOeVLLK8oQt6SV9Ef60jE9NmuFRHH00UX/DHGtnT2Q7YaJFKKPvXF/bcEBINbAWg2IOd4jy9781/Sd3c= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Wed, 18 Jan 2017 22:52:20 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Wed, 18 Jan 2017 22:52:20 +0000 From: Kent Watsen To: Juergen Schoenwaelder , "Martin Bjorklund" Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22ACAAGvCgIAAuS4AgABu5AD//92dgIAAYncAgAAqOICAAAq8AP//srEA Date: Wed, 18 Jan 2017 22:52:20 +0000 Message-ID: References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> <20170118.225035.2264295466067988883.mbj@tail-f.com> <20170118222858.GA6215@elstar.local> In-Reply-To: <20170118222858.GA6215@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 920fc054-b84a-4637-620c-08d43ff4a8d5 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:YrxKDkFohR6U6dYtrLcbVK9glnjlftmNq6xsyk9bQBdCuNTDE3j/Ejq36O1mZyGArUqbABLTlAEZmoKAq1O+TTlAGRKY8UsuwjtIaIhcl/zD/jznHK63+vWPnniUNxEWs2nV6YST6MwHm0QfKuaWA0xGr5vfeBjgkNpoxVrXUSUCoSxsAQQOK8giEDB5ffUT7qfYe3pygLV6Dv3ia5APDefcjNCIUbao4W1lQV1Kg3h+/IAU+TvKr5+/xDS4ik6A5Ur/liuKHrv+hWivi5fV0prLhbZk8wHQyiSGtJKRtUwYVH/c2YX/sMatqqLAswlJNL91/SHtXZY6OPx0f1hKklzACSwLtxkjhbQ01I0RaH4YozzwF/U6fgqmTo8a4L7ZV4nLDon6jca5E+Z72RVd2QngwelE2U66IDbdsprzTI+sFJtdO7taFFWz1jNp/ZoH1jOi1vh7PNbhwcakMTD/Rw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123555025)(20161123560025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 01917B1794 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(189002)(199003)(50986999)(36756003)(305945005)(101416001)(3280700002)(54356999)(76176999)(33656002)(8676002)(8936002)(81156014)(4001350100001)(81166006)(93886004)(68736007)(189998001)(5001770100001)(3660700001)(97736004)(92566002)(7736002)(66066001)(4326007)(6116002)(2906002)(102836003)(6512007)(2900100001)(5660300001)(229853002)(86362001)(105586002)(83716003)(106116001)(83506001)(99286003)(77096006)(106356001)(53936002)(6486002)(122556002)(82746002)(2950100002)(6506006)(6436002)(38730400001)(3846002)(25786008)(54906002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <821FDE1B2A23B94180D44B8202FCEAD8@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Jan 2017 22:52:20.2518 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 22:52:24 -0000 TWFydGluLCBKdWVyZ2VuLA0KDQoNCj4+ICgqKSBJdCBzYXlzOg0KPj4gDQo+PiAgIEEgc3BlY2lm aWNhdGlvbiB1c2luZyB0aGlzIGV4dGVuc2lvbiBNVVNUIHNwZWNpZnkgdGhlDQo+PiAgIG1lc3Nh Z2UgZW5jb2RpbmcgcnVsZXMsIGluY2x1ZGluZyB0aGUgY29udGVudCBtZWRpYSB0eXBlLg0KPj4g DQo+PiBJdCBzZWVtcyB0aGlzIG1lYW5zIHRoYXQgYSBjb250ZW50IG1lZGlhIHR5cGUgaXMgKnJl cXVpcmVkKiBmb3IgKmV2ZXJ5Kg0KPj4gdXNhZ2Ugb2YgdGhpcyBleHRlbnNpb24uICBNYXliZSB3 ZSBzaG91bGQgaGF2ZSB3cml0dGVuOg0KPj4gDQo+PiAgIEEgc3BlY2lmaWNhdGlvbiB1c2luZyB0 aGlzIGV4dGVuc2lvbiBNVVNUIHNwZWNpZnkgdGhlDQo+PiAgIG1lc3NhZ2UgZW5jb2RpbmcgcnVs ZXMsIGluY2x1ZGluZyB0aGUgY29udGVudCBtZWRpYSB0eXBlLCBpZiBvbmUgaXMNCj4+ICAgcmVx dWlyZWQuDQo+Pg0KPg0KPiBJIHRoaW5rIHplcm90b3VjaCBzb21ld2hlcmUgbmVlZHMgdG8gc3Bl Y2lmeSB0aGUgJ21lc3NhZ2UgZW5jb2RpbmcNCj4gcnVsZXMnLiBJbiBjYXNlIHplcm90b3VjaCBz dXBwb3J0cyBtdWx0aXBsZSBlbmNvZGluZ3MsIGl0IG5lZWRzIHRvDQo+IHNwZWNpZnkgYSB3YXkg KGFrYSAnbWVkaWEgdHlwZScpIHRvIGRpc3Rpbmd1aXNoIGVuY29kaW5ncyBvciBpbiBjYXNlDQo+ IHRoZXJlIGlzIG9ubHkgb25lIGVuY29kaW5nIGFsbG93ZWQsIHRoZSBzcGVjaWZpY2F0aW9uIG5l ZWRzIHRvIHNheQ0KPiB0aGF0IHRoZSBjb250ZW50IG1lZGlhIHR5cGUgaXMgYSBjb25zdGFudC4N Cj4NCj4gUGVyaGFwcyB0aGUgd29yZGluZyBpcyBub3Qgb3B0aW1hbCwgYnV0IEkgZG8gbm90IGNv bnNpZGVyIHRoZSB3b3JkaW5nDQo+IHByb2JsZW1hdGljIGVub3VnaCB0byBqdXN0aWZ5IGEgY29w eSBhbmQgcGFzdGUgYWN0aW9uIHdpdGggYSBzdWJ0bGUNCj4gd29yZGluZyBjaGFuZ2UuIEkgYW0g Y29uY2VybmVkIGFib3V0IGhhdmluZyB0byBkZWFsIHdpdGggTiB2YXJpYXRpb25zDQo+IG9mIHRo aXMgaW4gdGhlIGZ1dHVyZS4NCg0KDQpPa2F5LCBJ4oCZbGwgdXNlL3JlZiB0aGUgUkMgZHJhZnQu ICBJ4oCZbGwgYWxzbyBiZSBzdXJlIHRvIGFkZCBhIG5vdGUgZm9yDQp3aHkgaXQgaXMga25vd2lu Z2x5IGF3a3dhcmQgKHBlciB0aGUgZGlzY3Vzc2lvbiBhYm92ZSkuDQoNCkZXSVcsIHRoZSB6ZXJv dG91Y2ggZHJhZnQgZG9lcyBhbGxvdyBtdWx0aXBsZSBlbmNvZGluZ3MsIGZvciBhbGwgaXRzDQpz b3VyY2VzIG9mIGJvb3RzdHJhcHBpbmcgZGF0YSAoZS5nLiwgcmVtb3ZhYmxlIHN0b3JhZ2UsIERO UyBzZXJ2ZXIsDQpESENQIHNlcnZlciwgYm9vdHN0cmFwIHNlcnZlciwgZXRjLikgYnV0LCBpbiBl YWNoIG9mIHRoZXNlIGNhc2VzLCBpdA0KYWxzbyBkZWZpbmVzIGhvdyB0aGUgZW5jb2RpbmcgaXMg aWRlbnRpZmllZC4gIFNvLCBpbiBhIHdheSwgaXQgZG9lcw0Kc3VwcG9ydCDigJxjb250ZW50IG1l ZGlhIHR5cGXigJ0sIGp1c3Qgbm90ICpIVFRQKiBtZWRpYSB0eXBlcy4gIEFzIGFuIA0KZWdyZWdp b3VzIGV4YW1wbGUsIHRoZSByZW1vdmFibGUgc3RvcmFnZSBzb2x1dGlvbiBzYXlzOg0KDQogICAg ICBJbmZvcm1hdGlvbiBUeXBlOiAgTWFwcGVkIHRvIGEgZmlsZSBjb250YWluaW5nIGEgc3RhbmRh cmQgWUFORw0KICAgICAgICAgZW5jb2RpbmcgZm9yIHRoZSBZQU5HIG1vZGVsZWQgZGF0YSBkZXNj cmliZWQgaW4gU2VjdGlvbiA0LjEuICBBDQogICAgICAgICBmaWxlbmFtaW5nIGNvbnZlbnRpb24g U0hPVUxEIGJlIHVzZWQgdG8gaW5kaWNhdGUgZGF0YSBlbmNvZGluZw0KICAgICAgICAgKGUuZy4s IGJvb3QtaW5mby5beG1sfGpzb25dKS4NCg0KT3RoZXIgdGhhbiBtYXliZSBpdCBzaG91bGQgYmUg YSBNVVNULCBkbyB5b3UgdGhpbmsgc29tZXRoaW5nIGxpa2UgdGhpcw0KaXMgaW4gdGhlIHNwaXJp dCBvZiB3aGF04oCZcyBiZWluZyBhc2tlZCBmb3I/DQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0K DQo= From nobody Wed Jan 18 15:05:14 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 731CE1294BF for ; Wed, 18 Jan 2017 15:05:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 Qt2dZiJWKC1M for ; Wed, 18 Jan 2017 15:05:12 -0800 (PST) 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 C0127129422 for ; Wed, 18 Jan 2017 15:05:11 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 90D82702; Thu, 19 Jan 2017 00:05:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9FWBcI_CQoWr; Thu, 19 Jan 2017 00:05:08 +0100 (CET) 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, 19 Jan 2017 00:05:10 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 17EC4200A5; Thu, 19 Jan 2017 00:05:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 5r2xluqYyxT7; Thu, 19 Jan 2017 00:05:09 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7D948200A3; Thu, 19 Jan 2017 00:05:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id C28F23E29F69; Thu, 19 Jan 2017 00:05:12 +0100 (CET) Date: Thu, 19 Jan 2017 00:05:12 +0100 From: Juergen Schoenwaelder To: Kent Watsen Message-ID: <20170118230512.GB6215@elstar.local> Mail-Followup-To: Kent Watsen , Martin Bjorklund , "lhotka@nic.cz" , "netconf@ietf.org" References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> <20170118.225035.2264295466067988883.mbj@tail-f.com> <20170118222858.GA6215@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jan 2017 23:05:13 -0000 On Wed, Jan 18, 2017 at 10:52:20PM +0000, Kent Watsen wrote: > Martin, Juergen, > > > >> (*) It says: > >> > >> A specification using this extension MUST specify the > >> message encoding rules, including the content media type. > >> > >> It seems this means that a content media type is *required* for *every* > >> usage of this extension. Maybe we should have written: > >> > >> A specification using this extension MUST specify the > >> message encoding rules, including the content media type, if one is > >> required. > >> > > > > I think zerotouch somewhere needs to specify the 'message encoding > > rules'. In case zerotouch supports multiple encodings, it needs to > > specify a way (aka 'media type') to distinguish encodings or in case > > there is only one encoding allowed, the specification needs to say > > that the content media type is a constant. > > > > Perhaps the wording is not optimal, but I do not consider the wording > > problematic enough to justify a copy and paste action with a subtle > > wording change. I am concerned about having to deal with N variations > > of this in the future. > > > Okay, I’ll use/ref the RC draft. I’ll also be sure to add a note for > why it is knowingly awkward (per the discussion above). > > FWIW, the zerotouch draft does allow multiple encodings, for all its > sources of bootstrapping data (e.g., removable storage, DNS server, > DHCP server, bootstrap server, etc.) but, in each of these cases, it > also defines how the encoding is identified. So, in a way, it does > support “content media typeâ€, just not *HTTP* media types. As an > egregious example, the removable storage solution says: > > Information Type: Mapped to a file containing a standard YANG > encoding for the YANG modeled data described in Section 4.1. A > filenaming convention SHOULD be used to indicate data encoding > (e.g., boot-info.[xml|json]). > > Other than maybe it should be a MUST, do you think something like this > is in the spirit of what’s being asked for? > I think it carries the idea. But then the wording is somewhat vague or soft (a convention SHOULD be used followed by 'e.g.' with an example leaves some room for interpretation) - can I come up with my own convention for XML and JSON encoded content as I see fit? /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 Jan 18 16:51:28 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3E3A129517 for ; Wed, 18 Jan 2017 16:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yIn5PZrU-ubj for ; Wed, 18 Jan 2017 16:51:21 -0800 (PST) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0093.outbound.protection.outlook.com [104.47.40.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37879129511 for ; Wed, 18 Jan 2017 16:51:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ZTKCL0bGdyr6mslfcgAJrBiMuahauEmTeL2QS8tob98=; b=e0mvbd+P0nwX6NyKJKm4/k7SU7ttyO7SLO9HIOFFjcxBZtwkEF4DjA05fQ86Qqfsf3oMzq90IcFF8FPsOo32szdNp+S1IqYGFWKMPI/py456rJYWgNGFvJBMCy+a07I2j/eGbjWzRTZ9btpUsJUSjuPpdv1aaA7YIFvdYSGV9og= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1441.namprd05.prod.outlook.com (10.160.117.150) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 00:51:19 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 00:51:19 +0000 From: Kent Watsen To: Juergen Schoenwaelder Thread-Topic: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? Thread-Index: AQHSbcbsKW6xkjwQE0ONIdI1kzcSeqE7GUWAgAG22ACAAGvCgIAAuS4AgABu5AD//92dgIAAYncAgAAqOICAAAq8AP//srEAgABXbAD//8nSgA== Date: Thu, 19 Jan 2017 00:51:19 +0000 Message-ID: <62163E3C-6E4F-4C49-8F98-B4D95E391F34@juniper.net> References: <20170118.163008.1385302774802307987.mbj@tail-f.com> <8FE67866-2C08-4187-8770-DA11051E1DF8@juniper.net> <20170118191928.GC5811@elstar.local> <20170118.225035.2264295466067988883.mbj@tail-f.com> <20170118222858.GA6215@elstar.local> <20170118230512.GB6215@elstar.local> In-Reply-To: <20170118230512.GB6215@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: 7654151b-c4b6-4116-0b55-08d4400547f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1441; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1441; 7:jYBl/gsNZbLZzWJSabmM7B4cjV/t7r9NTko3zEj3yVkC+l/YWODw67NtGVeEL8GlGyASp/wnOZRZXXxCdon21vEEQvpoBUwyCVwty/AwsWBvxmHRCSxjxkwn1m6HlqpFwDBwJm5SclOTmW04rZUvblcQFzClpZ7SBlIrKHAff+or3U2oO+gl/yRSor+lqw5W8Al/mPF6jhjLLUbEjVzv0liYCb7lVPDumAshbtjUYGfhpksSp/YfdEVO/GMqHR1A5ljIZAZmk7PmUJ3okX3HazjvES7AYwO21doNRiVsB9vVk73Nz9mnbQsitTyJGgwEqndw6t+/kgZZaBuXnDo1xzL2uiMEylCtP2Yl6Iy21udzmLNXipOjNNrUo/NeEyZ47h+/DfHjh4Elke+MgerbXQHoxHSXC98NrmzgJWspXr5jimiKT8rpFNllqVSRa44FtyaQyG9lz4qIe4PkNzUV2w== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(6041248)(20161123560025)(20161123555025)(20161123562025)(20161123564025)(6072148); SRVR:BN3PR0501MB1441; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1441; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39450400003)(39410400002)(39840400002)(39850400002)(39860400002)(189002)(51914003)(199003)(50986999)(36756003)(305945005)(101416001)(3280700002)(76176999)(54356999)(33656002)(93886004)(8936002)(8676002)(4001350100001)(81166006)(81156014)(68736007)(189998001)(3660700001)(92566002)(7736002)(66066001)(97736004)(4326007)(2906002)(102836003)(6512007)(6116002)(2900100001)(5660300001)(229853002)(86362001)(105586002)(54906002)(83716003)(106116001)(83506001)(99286003)(77096006)(106356001)(6486002)(53936002)(122556002)(82746002)(6916009)(6506006)(2950100002)(6436002)(38730400001)(3846002)(25786008)(110136003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1441; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <99B055C5CB7BD84D83EFC3577D10D3CB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 00:51:19.0494 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1441 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 00:51:26 -0000 SGkgSnVlcmdlbiwNCg0KPj4gT3RoZXIgdGhhbiBtYXliZSBpdCBzaG91bGQgYmUgYSBNVVNULCBk byB5b3UgdGhpbmsgc29tZXRoaW5nIGxpa2UgdGhpcw0KPj4gaXMgaW4gdGhlIHNwaXJpdCBvZiB3 aGF04oCZcyBiZWluZyBhc2tlZCBmb3I/DQo+Pg0KPg0KPiBJIHRoaW5rIGl0IGNhcnJpZXMgdGhl IGlkZWEuIEJ1dCB0aGVuIHRoZSB3b3JkaW5nIGlzIHNvbWV3aGF0IHZhZ3VlIG9yDQo+IHNvZnQg KGEgY29udmVudGlvbiBTSE9VTEQgYmUgdXNlZCBmb2xsb3dlZCBieSAnZS5nLicgd2l0aCBhbiBl eGFtcGxlDQo+IGxlYXZlcyBzb21lIHJvb20gZm9yIGludGVycHJldGF0aW9uKSAtIGNhbiBJIGNv bWUgdXAgd2l0aCBteSBvd24NCj4gY29udmVudGlvbiBmb3IgWE1MIGFuZCBKU09OIGVuY29kZWQg Y29udGVudCBhcyBJIHNlZSBmaXQ/DQoNClVuZGVyc3Rvb2QsIGFuZCB3ZSBjYW4gdGlnaHRlbiB1 cCB0aGUgbGFuZ3VhZ2Ugc29tZS4gIFRoZSBtYWluIHRha2Vhd2F5IGlzIHRoYXQgdGhlIGdpc3Qg b2YgdGhpcyBpcyBva2F5LCBnaXZlbiB0aGUgc3BlY2lmaWMgbGFuZ3VhZ2UgaW4gdGhlIFJFU1RD T05GIGRyYWZ0LiAgVGhhbmtzIGZvciB0aGUgY29uZmlybWF0aW9uIQ0KDQpLZW50DQoNCg0K From nobody Wed Jan 18 23:44:07 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD6E0127058 for ; Wed, 18 Jan 2017 23:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 p2A09IppInLu for ; Wed, 18 Jan 2017 23:44:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8242E120726 for ; Wed, 18 Jan 2017 23:44:04 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 445991AE018A; Thu, 19 Jan 2017 08:44:03 +0100 (CET) Date: Thu, 19 Jan 2017 08:44:01 +0100 (CET) Message-Id: <20170119.084401.1762023248424035269.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170118222858.GA6215@elstar.local> References: <20170118191928.GC5811@elstar.local> <20170118.225035.2264295466067988883.mbj@tail-f.com> <20170118222858.GA6215@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] zerotouch/19: How to encode YANG-modeled artifacts? X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 07:44:06 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 18, 2017 at 10:50:35PM +0100, Martin Bjorklund wrote: > > Juergen Schoenwaelder wrote: > > > What is wrong with reusing the RESTCONF hack? > > > > Yes this is also a possibility. It just happens to be defined in a > > somewhat weird place... > > > > I had to re-read the definiiton of rc:yang-data, I thought it was more > > dependent on restconf than it really is. In fact, except for one > > sentence (*), it is very generic and can be used as-is for the > > zerotouch artifacts. > > > > (*) It says: > > > > A specification using this extension MUST specify the > > message encoding rules, including the content media type. > > > > It seems this means that a content media type is *required* for *every* > > usage of this extension. Maybe we should have written: > > > > A specification using this extension MUST specify the > > message encoding rules, including the content media type, if one is > > required. > > > > I think zerotouch somewhere needs to specify the 'message encoding > rules'. In case zerotouch supports multiple encodings, it needs to > specify a way (aka 'media type') to distinguish encodings or in case > there is only one encoding allowed, the specification needs to say > that the content media type is a constant. > > Perhaps the wording is not optimal, but I do not consider the wording > problematic enough to justify a copy and paste action with a subtle > wording change. I am concerned about having to deal with N variations > of this in the future. I fully agree with you. Until we have something similar built-in (if ever), rc:yang-data should be used. /martin From nobody Thu Jan 19 02:08:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D1A8128B37 for ; Thu, 19 Jan 2017 02:08:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CZqhd_ncOYfr for ; Thu, 19 Jan 2017 02:08:54 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 396EF127ABE for ; Thu, 19 Jan 2017 02:08:54 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 39A551AE018A; Thu, 19 Jan 2017 11:08:53 +0100 (CET) Date: Thu, 19 Jan 2017 11:08:51 +0100 (CET) Message-Id: <20170119.110851.908806806765175703.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de From: Martin Bjorklund In-Reply-To: <20170118075314.GA4786@elstar.local> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 10:08:55 -0000 Juergen Schoenwaelder wrote: > On Wed, Jan 18, 2017 at 12:06:14AM +0100, Mehmet Ersue wrote: > > > > > > The documents the Subscriptions and Events team are currently working on > > are: > > > > - A document which defines the protocol-neutral notification framework, > > i.e., explains the concepts of subscriptions, filters, control plane > > notifications, replay, etc. And also defines the associated YANG data > > model, RPCs, etc. This is currently covered in 5277bis document which would > > need to be renamed. > > I think 'control plane notification' is a really bad term for what it > does and the sooner we find a better term the better it is. I actually > think that no term is needed. > > > - A document which defines how notifications are sent over NETCONF > > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > > encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), > > The encoding of YANG defined notifications into XML and JSON is defined > in RFC 7950 and RFC 7951. NETCONF does not support JSON. > > > - A document which defines how notifications are sent over RESTCONF > > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG > > notifications are encoded in XML and JSON > > (draft-ietf-netconf-restconf-notif), > > The encoding of YANG defined notifications into XML and JSON is defined > in RFC 7950 and RFC 7951. > > > - A document which defines the subscription and push mechanism for YANG > > datastores allowing subscriber applications to request updates from a YANG > > datastore (draft-ietf-netconf-yang-push). > > Perhaps you mean the right thing but from the writing this is not > clear. Perhaps you actually mean the following four documents: > > a) protocol-neutral extended notification framework > > b) using extended notifications with NETCONF > > c) using extended notifications with RESTCONF > > d) a YANG data model for extended notifications > > Such a set of documents makes sense to me. Hmm, this is not what I understood from Mehmet's description. Specifically, in Mehmet's description, the YANG data model is part of the first document. Also, it is not clear to me what is included in the "extended notification framework". Is "push" included there? /martin From nobody Thu Jan 19 06:08:59 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0B7D1270B4 for ; Thu, 19 Jan 2017 06:08:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DgeTYOxn2ywt for ; Thu, 19 Jan 2017 06:08:55 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D3051295D4 for ; Thu, 19 Jan 2017 06:08:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7183; q=dns/txt; s=iport; t=1484834935; x=1486044535; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=SE36PYEPc/ugi3GBj1zE6N8aw0aXj+dyJ+fyOP3TPLs=; b=ShW058/JZP823aKljKIi3ms0iukHXJuXK+H0Hrth6mh7XWp3dkC8akBM F25C6158e9thygtoW8jjsWM2ruFVWzu06Ha7e2AWXOd9HHnOOlkEQBLY0 +LLg1nwhZKNr0LnP5luTcuChTdmUHhcjpS13FkkjtwLbRNET5hurWKUFF 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ATAQAox4BY/4kNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR9ggQkHjVKSA5Mdgg+CDIYiAoF9PxgBAgEBAQEBAQF?= =?us-ascii?q?jKIRpAQEBAwF3BwsCAQgOAwQBAQ4WBAcyFAkIAQEEARIIE4hgCLIMij8BAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBH4ZLhG6ELAEBhX8Fj2mLWwGRW4IAhQ+JaIgchkGEEgE?= =?us-ascii?q?fOIFGFTqEOxwYgUhzhzaBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,254,1477958400"; d="scan'208";a="197051165" Received: from alln-core-4.cisco.com ([173.36.13.137]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Jan 2017 14:08:54 +0000 Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id v0JE8r5k017416 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 14:08:53 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-013.cisco.com (64.101.220.153) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 09:08:52 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 09:08:52 -0500 From: "Eric Voit (evoit)" To: Mehmet Ersue , "netconf@ietf.org" Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhABRJRpQAAAml3A= Date: Thu, 19 Jan 2017 14:08:52 +0000 Message-ID: <7fa6e021b52f4569904709fad6c840e2@XCH-RTP-013.cisco.com> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <3b6015d95dfb48228362e6aa1e40f524@XCH-RTP-013.cisco.com> In-Reply-To: <3b6015d95dfb48228362e6aa1e40f524@XCH-RTP-013.cisco.com> 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: [10.118.56.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 14:08:57 -0000 > From: Mehmet Ersue, January 17, 2017 6:06 PM >=20 > Dear NETCONF WG, >=20 > looking at the feedback on the three options Eric Voit summarized in his = mail > below but also related discussion on this topic, NETCONF co-chairs came t= o the > conclusion that option (iii) for updating/enhancing RFC5277 did not get a= ny > proponents. On the other hand we see a huge support and attraction for th= e > new notification/subscription capabilities and extensions discussed and > provided by the Subscriptions and Events team. >=20 > We think that the addition of new notification capabilities in concert wi= th the > drafts from the Subscriptions and Events team provide rich features that > implementations will want to support in the future. The key features in > preparation are transport independence, multiple dynamic and/or configure= d > subscriptions in a transport session. >=20 > The documents the Subscriptions and Events team are currently working on > are: > - A document which defines the protocol-neutral notification framework, i= .e., > explains the concepts of subscriptions, filters, control plane notificati= ons, > replay, etc. =A0And also defines the associated YANG data model, RPCs, et= c. This is > currently covered in 5277bis document which would need to be renamed. > - A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are enc= oded > in XML and JSON (draft-ietf-netconf-netconf-event-notifications), > - A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2.=A0 Also defines how Y= ANG > notifications are encoded in XML and JSON (draft-ietf-netconf-restconf-no= tif), > - A document which defines the subscription and push mechanism for YANG > datastores allowing subscriber applications to request updates from a YAN= G > datastore (draft-ietf-netconf-yang-push). >=20 > A) NETCONF co-chairs think that the Subscriptions and Events team should > continue its valuable work and propose to change our current charter to a= dd > the development of notifications and subscription capabilities with the l= isted > documents and focus above as a starting point. WG members are asked to st= ate > their opinion on the proposed plan. > Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you > have a strong objection to this plan and explain your concern with valid > arguments. Please also state clearly if you support this plan. I support the charter change proposal described in (A) =20 > B) NETCONF co-chairs further propose that NETCONF WG should use its energ= y > in the future to complete and improve the new notification and subscripti= on > RFCs and stop maintaining RFC 5277 for issues other than errata.=A0 Note = that it > is required that RFC 5277 and all new work needs to gracefully co-exist i= n any > deployment. Please state your opinion on the maillist by January 27, 2017= EOB > PT, whether you think RFC 5277 should be obsoleted during the publication= of > the new draft set or not. I believe it easier to obsolete RFC-5277 simply so that NETCONF is seen as = advocating a single more comprehensive solution/approach for new deployment= s. =20 Eric=20 =20 > Many Thanks in advance for your valuable comments. >=20 > Mehmet & Mahesh >=20 > From: Eric Voit (evoit) [mailto:evoit@cisco.com] > Sent: Tuesday, December 20, 2016 4:33 PM > To: mailto:netconf@ietf.org; mailto:netconf-chairs@ietf.org > Subject: 3 Options for Subscription & Event Notification draft structure >=20 > To summarize previous threads, key benefits of 5277bis over RFC 5277 incl= ude: > =A0 (1) transport independence > =A0 (2) configured subscriptions > =A0 (3) many subscriptions per transport session > =A0 (4) modify and delete subscription RPCs > =A0 (5) control plane notifications > =A0 (6) data plane notification including subscription-id > =A0 (7) negotiation (see Yves' thread from yesterday) > =A0 (8) control plane reuse with draft-ietf-netconf-yang-push. >=20 > Those of us working 5277bis had been planning on supporting existing 5277 > implementations via a separate backwards compatibility section.=A0 But as= we > have gone forward, we see no meaningful technical overlaps. =A0I.e., ther= e are no > RPC or notifications shared between the 5277 and 5277bis solutions.=A0 An= y > compatibility mode section would be fully standalone.=A0 Considering that= people > can just refer to 5277 if they need it, and considering 5277 & 5277bis co= uld > easily run in parallel on different transport sessions, building a standa= lone > backwards compatibility section seems both confusing and redundant. >=20 > This leaves three options: > =A0 (i.) OBSOLETE 5277 by replacing it with 5277bis > =A0=A0(ii.) Support 5277bis=A0without Obsoleting 5277 > =A0=A0(iii.) Write a new UPDATE draft for 5277 NETCONF only transport >=20 > The benefits and issues of each are as follows: >=20 > (i.) OBSOLETE 5277 by replacing it with 5277bis . Supports all requiremen= ts (1) > through (8). > . IETF does not continue protocol maintenance of 5277. > o Implementations can still choose 5277 or 5277bis, even though IETF > recommends 5277bis. > o Implementations provide backwards compatibility through concurrent, > parallel support of both specifications. > o Although obsoleted, the IETF does not deprecate 5277 so that current > implementations may stay with existing 5277. > . Need to change the NETCONF WG charter to show that 5277 is being > replaced rather than enhanced. >=20 > (ii.) Support 5277bis without Obsoleting 5277 . Technically identical to = (i). > . Implementations free to choose 5277 or 5277bis, with no guidance on whi= ch > the WG recommends. o This could be confusing to customers as NETCONF WG > will be advocating competing technologies for the place of overlap. =A0--= i.e., > NETCONF over XML with a single subscription. > . Establishes competing technology futures where one direction would suff= ice. >=20 > (iii.) Write a new UPDATE draft for 5277 NETCONF only transport . Support= s a > subset of requirements: > o Cannot support (1) or (8) > o Supporting (2), (3), (4), (5), (6), & (7) possible, but would require t= he creation > of replicated/competing mechanisms with (8). . Doubles the development > effort if the yang-push control plane is also required. > . WG would need to build guidelines on when to use 5277bis or this new > UPDATE draft (assuming the WG wanted to proceed with the transport > independent 5277bis.) . No identified author / champion for this > path. =A0(Because business drivers being driven by other than NETCONF/XML= .) . > Update draft itself wouldn't require a NETCONF charter update. >=20 > Based on this list, the people working in on the Subscription & Event > Notification weekly calls have a preference for (i.) followed by (ii.).= =A0 Do you > have a preference or additional questions not addressed here or in the ea= rlier > threads? >=20 > Thanks, > Eric From nobody Thu Jan 19 07:12:48 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92A211293F9 for ; Thu, 19 Jan 2017 07:12:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WNhq_-O9Djpt for ; Thu, 19 Jan 2017 07:12:46 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2F591293DF for ; Thu, 19 Jan 2017 07:12:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3784; q=dns/txt; s=iport; t=1484838765; x=1486048365; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=K3AfZeLUeuGc82+0WZALP2OsrASpVp3e26rKSppyNiI=; b=MImv/SpS2uwismeniFkEndHIu+t+Vr7+qKrjhbUz6drIAoQpzJM+c29J 4S4W92ESOrGr3lPttNvVod1Z/IGbqYICafIzq+2eOdDp5CO4k3UieXW9R cMZ+TyQ/t3ZvEE7yYG9Ox2O195YLgCjW6eWgnx+f75+yPwUssfVN6jWD2 g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQDa1oBY/5xdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz8BAQEBAR9ggQkHjVKSA5UsggwfC4UuSgKBfj8YAQIBAQEBAQE?= =?us-ascii?q?BYyiEaQEBAQMBAQE4NAkCBQsCAQgOAgUCAQ0RBQsnCx0IAgQBDQUIiHMIDrIIi?= =?us-ascii?q?kEBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZLg2WBCYQbEQGGAAWbRAGRW5B3km8?= =?us-ascii?q?BHzhyVBU6hG+BSHOHBoEhgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,254,1477958400"; d="scan'208";a="373143590" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Jan 2017 15:12:44 +0000 Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id v0JFCiqX013408 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 19 Jan 2017 15:12:44 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 19 Jan 2017 10:12:44 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Thu, 19 Jan 2017 10:12:43 -0500 From: "Eric Voit (evoit)" To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AQHScjwILH0VYlYKQ0KNB3RPNzgbhKE/12nQ Date: Thu, 19 Jan 2017 15:12:43 +0000 Message-ID: <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> In-Reply-To: <20170119.110851.908806806765175703.mbj@tail-f.com> 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: [10.118.56.226] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:12:47 -0000 > From: Martin Bjorklund, January 19, 2017 5:09 AM > To: j.schoenwaelder@jacobs-university.de > Cc: netconf@ietf.org > Subject: Re: [Netconf] New Notification and Subscription Features WASFW: = 3 > Options for Subscription & Event Notification draft structure >=20 > Juergen Schoenwaelder wrote: > > On Wed, Jan 18, 2017 at 12:06:14AM +0100, Mehmet Ersue wrote: > > > > > > > > > The documents the Subscriptions and Events team are currently > > > working on > > > are: > > > (1)>>> - A document which defines the protocol-neutral notification > > > framework, i.e., explains the concepts of subscriptions, filters, > > > control plane notifications, replay, etc. And also defines the > > > associated YANG data model, RPCs, etc. This is currently covered in > > > 5277bis document which would need to be renamed. > > > > I think 'control plane notification' is a really bad term for what it > > does and the sooner we find a better term the better it is.=20 A better term would be great, maybe "Subscription State Notification"? =20 > > I actually think that no term is needed. I do think some term is helpful. These are the notifications which match 1= :1 with the set of Subscription State model state changes on a Publisher. = See 5277bis, section 2.4. =20 (2)>>> - A document which defines how notifications are sent over NETCONF > > > (generalizing section 3.7 of RFC 5277) and how YANG notifications > > > are encoded in XML and JSON > > > (draft-ietf-netconf-netconf-event-notifications), > > > > The encoding of YANG defined notifications into XML and JSON is > > defined in RFC 7950 and RFC 7951. NETCONF does not support JSON. > > (3)>>> - A document which defines how notifications are sent over RESTCONF > > > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines > > > how YANG notifications are encoded in XML and JSON > > > (draft-ietf-netconf-restconf-notif), > > > > The encoding of YANG defined notifications into XML and JSON > is defined > > in RFC 7950 and RFC 7951 (4)>>> - A document which defines the subscription and push mechanism for > > > YANG datastores allowing subscriber applications to request updates > > > from a YANG datastore (draft-ietf-netconf-yang-push). > > > > Perhaps you mean the right thing but from the writing this is not > > clear. Perhaps you actually mean the following four documents: > > > > a) protocol-neutral extended notification framework > > > > b) using extended notifications with NETCONF > > > > c) using extended notifications with RESTCONF > > > > d) a YANG data model for extended notifications > > > > Such a set of documents makes sense to me. >=20 > Hmm, this is not what I understood from Mehmet's description. > Specifically, in Mehmet's description, the YANG data model is part of the= first > document. The breakdown in Mehmet's email aimed to match contents of the WG drafts. = So yes, the base subscription model is in Mehmet's first document (1). Aug= mentations to the base model for yang-push specifics in Mehmet's fourth doc= ument (4). =20 What we have found missing is a protocol-neutral data plane notification me= ssage. While that could be bundled into Juergen's (a) or Mehmet's (1), it = likely is better to have stand-alone so it isn't exclusively coupled to Sub= scriptions. > Also, it is not clear to me what is included in the "extended notificatio= n > framework". Is "push" included there? My reading is the (d) includes the YANG models currently within (1) and (4)= . Eric > /martin >=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jan 19 07:40:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5936D12945A for ; Thu, 19 Jan 2017 07:40:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 1AU572xkvcdr for ; Thu, 19 Jan 2017 07:40:02 -0800 (PST) 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 315D212896F for ; Thu, 19 Jan 2017 07:40:02 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id F17F16C0; Thu, 19 Jan 2017 16:40:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 0LC55UjmN5fb; Thu, 19 Jan 2017 16:39:58 +0100 (CET) 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, 19 Jan 2017 16:40:00 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id B0FB6200A5; Thu, 19 Jan 2017 16:40:00 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Mkk6oq6QTjWO; Thu, 19 Jan 2017 16:40:00 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5659E200A3; Thu, 19 Jan 2017 16:40:00 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 4FFB73E2B568; Thu, 19 Jan 2017 16:40:03 +0100 (CET) Date: Thu, 19 Jan 2017 16:40:02 +0100 From: Juergen Schoenwaelder To: "Eric Voit (evoit)" Message-ID: <20170119154002.GB8004@elstar.local> Mail-Followup-To: "Eric Voit (evoit)" , Martin Bjorklund , "netconf@ietf.org" References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 15:40:03 -0000 On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote: > > > > > > I think 'control plane notification' is a really bad term for what it > > > does and the sooner we find a better term the better it is. > > A better term would be great, maybe "Subscription State Notification"? > This proposed term is much much better. > I do think some term is helpful. These are the notifications which match 1:1 with the set of Subscription State model state changes on a Publisher. See 5277bis, section 2.4. > Fine with me - as long as the term is specific. /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 Jan 19 10:29:46 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD017129477 for ; Thu, 19 Jan 2017 10:29:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 P8xsh2CuSL1u for ; Thu, 19 Jan 2017 10:29:43 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE9281293DB for ; Thu, 19 Jan 2017 10:29:42 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml702-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZD43185; Thu, 19 Jan 2017 18:29:41 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml702-cah.china.huawei.com (10.201.5.99) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 18:29:40 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 19 Jan 2017 10:29:34 -0800 From: Alexander Clemm To: Juergen Schoenwaelder , "Eric Voit (evoit)" Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAAjbtYAADcHHIAACpzIgAAA9DoAAAtattA= Date: Thu, 19 Jan 2017 18:29:33 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> <20170119154002.GB8004@elstar.local> In-Reply-To: <20170119154002.GB8004@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.91] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020202.58810595.0182, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: da3badadded048b8898501cb2cbf3260 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:29:44 -0000 Hi, The specific notifications under discussions are notifications that inform = a receiver of notifications of changes to subscription state that will impa= ct what notifications the receiver can expect to receive. What sets those = particular notifications apart from other notifications is that you do not = have to explicitly subscribe to them in order to receive them, and that the= notifications are confined to that particular context and not subscribable= to others. Instead, use of a particular feature (in this case, subscribin= g to a set of notifications) makes a user automatically "subscribed" to not= ifications in this context. =20 While "subscription state notification" is in one sense an accurate descrip= tion of what this does, I think a more general term may be more appropriate= , for several reasons: - To capture the different nature of this type of notification vs other not= ifications, e.g. an "interface state notification", which would behave genu= inely differently in terms of how to subscribe to it. =20 - To allow for a generalization of this concept to other areas as well. Th= e question is whether this is intended to be in charter, but it is certainl= y conceivable to use a similar type of notifications for other use cases. = Think, for example, of an ongoing test in which intermediate updates about = test progress would be sent using notifications - but those notifications s= hould go only to the initiator of the test, and the initiator of the test s= hould not have to separately subscribe to test update notifications. =20 What about the term "OAM notifications"? or, to leave out "plane" from "co= ntrol plane notifications" and simply call it "control notifications"? =20 --- Alex -----Original Message----- From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoen= waelder Sent: Thursday, January 19, 2017 7:40 AM To: Eric Voit (evoit) Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 = Options for Subscription & Event Notification draft structure On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote: > > > > > > I think 'control plane notification' is a really bad term for what=20 > > > it does and the sooner we find a better term the better it is. >=20 > A better term would be great, maybe "Subscription State Notification"? = =20 > This proposed term is much much better. > I do think some term is helpful. These are the notifications which match= 1:1 with the set of Subscription State model state changes on a Publisher.= See 5277bis, section 2.4. =20 > Fine with me - as long as the term is specific. /js --=20 Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 _______________________________________________ Netconf mailing list Netconf@ietf.org https://www.ietf.org/mailman/listinfo/netconf From nobody Thu Jan 19 10:39:59 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7B061294BC for ; Thu, 19 Jan 2017 10:39:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 5V2mhk47P25H for ; Thu, 19 Jan 2017 10:39:49 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2FF5129481 for ; Thu, 19 Jan 2017 10:39:48 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml706-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZD43988; Thu, 19 Jan 2017 18:39:46 +0000 (GMT) Received: from DFWEML701-CAH.china.huawei.com (10.193.5.175) by lhreml706-cah.china.huawei.com (10.201.5.182) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 18:39:44 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by dfweml701-cah.china.huawei.com ([10.193.5.175]) with mapi id 14.03.0301.000; Thu, 19 Jan 2017 10:39:37 -0800 From: Alexander Clemm To: Mehmet Ersue , "'Netconf'" Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhABbUPQg Date: Thu, 19 Jan 2017 18:39:36 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2ED53D15@dfweml501-mbb> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> In-Reply-To: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.91] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2ED53D15dfweml501mbb_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020201.588107F2.03AF, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: da3badadded048b8898501cb2cbf3260 Archived-At: Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:39:58 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2ED53D15dfweml501mbb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I support item (A) for the charter change. I also support item (B). Whether RFC 5277 is obsoleted or not, it is clea= rly recognized that 5277 and new work will gracefully coexist in deployment= s. Obsoleting RFC 5277 seems preferable over other alternatives as to not = be ambiguous about which solution approach is advocated as basis for going = forward. --- Alex From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mehmet Ersue Sent: Tuesday, January 17, 2017 3:06 PM To: 'Netconf' Subject: [Netconf] New Notification and Subscription Features WASFW: 3 Opti= ons for Subscription & Event Notification draft structure Dear NETCONF WG, looking at the feedback on the three options Eric Voit summarized in his ma= il below but also related discussion on this topic, NETCONF co-chairs came = to the conclusion that option (iii) for updating/enhancing RFC5277 did not = get any proponents. On the other hand we see a huge support and attraction = for the new notification/subscription capabilities and extensions discussed= and provided by the Subscriptions and Events team. We think that the addition of new notification capabilities in concert with= the drafts from the Subscriptions and Events team provide rich features th= at implementations will want to support in the future. The key features in = preparation are transport independence, multiple dynamic and/or configured = subscriptions in a transport session. The documents the Subscriptions and Events team are currently working on ar= e: - A document which defines the protocol-neutral notification framework, i.e= ., explains the concepts of subscriptions, filters, control plane notificat= ions, replay, etc. And also defines the associated YANG data model, RPCs, = etc. This is currently covered in 5277bis document which would need to be r= enamed. - A document which defines how notifications are sent over NETCONF (general= izing section 3.7 of RFC 5277) and how YANG notifications are encoded in XM= L and JSON (draft-ietf-netconf-netconf-event-notifications), - A document which defines how notifications are sent over RESTCONF (genera= lizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG notific= ations are encoded in XML and JSON (draft-ietf-netconf-restconf-notif), - A document which defines the subscription and push mechanism for YANG dat= astores allowing subscriber applications to request updates from a YANG dat= astore (draft-ietf-netconf-yang-push). A) NETCONF co-chairs think that the Subscriptions and Events team should co= ntinue its valuable work and propose to change our current charter to add t= he development of notifications and subscription capabilities with the list= ed documents and focus above as a starting point. WG members are asked to s= tate their opinion on the proposed plan. Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you h= ave a strong objection to this plan and explain your concern with valid arg= uments. Please also state clearly if you support this plan. B) NETCONF co-chairs further propose that NETCONF WG should use its energy = in the future to complete and improve the new notification and subscription= RFCs and stop maintaining RFC 5277 for issues other than errata. Note tha= t it is required that RFC 5277 and all new work needs to gracefully co-exis= t in any deployment. Please state your opinion on the maillist by January 27, 2017 EOB PT, wheth= er you think RFC 5277 should be obsoleted during the publication of the new= draft set or not. Many Thanks in advance for your valuable comments. Mehmet & Mahesh From: Eric Voit (evoit) [mailto:evoit@cisco.com] Sent: Tuesday, December 20, 2016 4:33 PM To: netconf@ietf.org; netconf-chairs@ietf.org Subject: 3 Options for Subscription & Event Notification draft structure To summarize previous threads, key benefits of 5277bis over RFC 5277 includ= e: (1) transport independence (2) configured subscriptions (3) many subscriptions per transport session (4) modify and delete subscription RPCs (5) control plane notifications (6) data plane notification including subscription-id (7) negotiation (see Yves' thread from yesterday) (8) control plane reuse with draft-ietf-netconf-yang-push. Those of us working 5277bis had been planning on supporting existing 5277 i= mplementations via a separate backwards compatibility section. But as we h= ave gone forward, we see no meaningful technical overlaps. I.e., there are= no RPC or notifications shared between the 5277 and 5277bis solutions. An= y compatibility mode section would be fully standalone. Considering that p= eople can just refer to 5277 if they need it, and considering 5277 & 5277bi= s could easily run in parallel on different transport sessions, building a = standalone backwards compatibility section seems both confusing and redunda= nt. This leaves three options: (i.) OBSOLETE 5277 by replacing it with 5277bis (ii.) Support 5277bis without Obsoleting 5277 (iii.) Write a new UPDATE draft for 5277 NETCONF only transport The benefits and issues of each are as follows: (i.) OBSOLETE 5277 by replacing it with 5277bis * Supports all requirements (1) through (8). * IETF does not continue protocol maintenance of 5277. * Implementations can still choose 5277 or 5277bis, even though IETF= recommends 5277bis. * Implementations provide backwards compatibility through concurrent= , parallel support of both specifications. * Although obsoleted, the IETF does not deprecate 5277 so that curre= nt implementations may stay with existing 5277. * Need to change the NETCONF WG charter to show that 5277 is being repl= aced rather than enhanced. (ii.) Support 5277bis without Obsoleting 5277 * Technically identical to (i). * Implementations free to choose 5277 or 5277bis, with no guidance on w= hich the WG recommends. * This could be confusing to customers as NETCONF WG will be advocat= ing competing technologies for the place of overlap. -- i.e., NETCONF over= XML with a single subscription. * Establishes competing technology futures where one direction would su= ffice. (iii.) Write a new UPDATE draft for 5277 NETCONF only transport * Supports a subset of requirements: * Cannot support (1) or (8) * Supporting (2), (3), (4), (5), (6), & (7) possible, but would requ= ire the creation of replicated/competing mechanisms with (8). * Doubles the development effort if the yang-push control plane is also= required. * WG would need to build guidelines on when to use 5277bis or this new = UPDATE draft (assuming the WG wanted to proceed with the transport independ= ent 5277bis.) * No identified author / champion for this path. (Because business dri= vers being driven by other than NETCONF/XML.) * Update draft itself wouldn't require a NETCONF charter update. Based on this list, the people working in on the Subscription & Event Notif= ication weekly calls have a preference for (i.) followed by (ii.). Do you = have a preference or additional questions not addressed here or in the earl= ier threads? Thanks, Eric --_000_644DA50AFA8C314EA9BDDAC83BD38A2ED53D15dfweml501mbb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I support item (A) for= the charter change. 

 

I also support item (B= ).  Whether RFC 5277 is  obsoleted or not, it is clearly recogniz= ed that 5277 and new work will gracefully coexist in deployments.  Obs= oleting RFC 5277 seems preferable over other alternatives as to not be ambiguous about which solution approach is advocated as basis= for going forward. 

 

--- Alex

 

From: Netconf [mailto:netconf-bounces@ietf.or= g] On Behalf Of Mehmet Ersue
Sent: Tuesday, January 17, 2017 3:06 PM
To: 'Netconf' <netconf@ietf.org>
Subject: [Netconf] New Notification and Subscription Features WASFW:= 3 Options for Subscription & Event Notification draft structure

 

Dear NETCONF WG,<= /o:p>

 

looking at the feedbac= k on the three options Eric Voit summarized in his mail below but also rela= ted discussion on this topic, NETCONF co-chairs came to the conclusion that= option (iii) for updating/enhancing RFC5277 did not get any proponents. On the other hand we see a huge suppor= t and attraction for the new notification/subscription capabilities and ext= ensions discussed and provided by the Subscriptions and Events team.

 

We think that the addi= tion of new notification capabilities in concert with the drafts from the S= ubscriptions and Events team provide rich features that implementations wil= l want to support in the future. The key features in preparation are transport independence, multiple dynamic a= nd/or configured subscriptions in a transport session.     &= nbsp;

 

The documents the Subs= criptions and Events team are currently working on are:

- A document which def= ines the protocol-neutral notification framework, i.e., explains the concep= ts of subscriptions, filters, control plane notifications, replay, etc. &nb= sp;And also defines the associated YANG data model, RPCs, etc. This is currently covered in 5277bis document which woul= d need to be renamed.

- A document which def= ines how notifications are sent over NETCONF (generalizing section 3.7 of R= FC 5277) and how YANG notifications are encoded in XML and JSON (draft-ietf= -netconf-netconf-event-notifications),

- A document which def= ines how notifications are sent over RESTCONF (generalizing section 6 of RE= STCONF RFC) and HTTP2.  Also defines how YANG notifications are encode= d in XML and JSON (draft-ietf-netconf-restconf-notif),

- A document which def= ines the subscription and push mechanism for YANG datastores allowing subsc= riber applications to request updates from a YANG datastore (draft-ietf-net= conf-yang-push).

 

A) NETCONF co-chairs t= hink that the Subscriptions and Events team should continue its valuable wo= rk and propose to change our current charter to add the development of noti= fications and subscription capabilities with the listed documents and focus above as a starting point. WG members = are asked to state their opinion on the proposed plan.

Please let us know on = NETCONF maillist by January 27, 2017 EOB PT, if you have a strong objection= to this plan and explain your concern with valid arguments. Please also st= ate clearly if you support this plan.

 

B) NETCONF co-chairs f= urther propose that NETCONF WG should use its energy in the future to compl= ete and improve the new notification and subscription RFCs and stop maintai= ning RFC 5277 for issues other than errata.  Note that it is required that RFC 5277 and all new work need= s to gracefully co-exist in any deployment.  

Please state your opin= ion on the maillist by January 27, 2017 EOB PT, whether you think RFC 5277 = should be obsoleted during the publication of the new draft set or not.

 

Many Thanks in advance= for your valuable comments. 

 

Mehmet & Mahesh

 

From: Eric Voit (evoit) [mailto:evoit@cisco.com]
Sent: Tuesday, December 20, 2016 4:33 PM
To: netconf@ietf.org; netconf-chairs@ietf.org
Subject: 3 Options for Subscription & Event Notification draft s= tructure

 

To summarize previous threads, key benefits of 52= 77bis over RFC 5277 include:

  (1) transport independence

  (2) configured subscriptions

  (3) many subscriptions per transport sessi= on

  (4) modify and delete subscription RPCs

  (5) control plane notifications=

  (6) data plane notification including subs= cription-id

  (7) negotiation (see Yves’ thread fr= om yesterday)

  (8) control plane reuse with draft-ietf-ne= tconf-yang-push.

 

Those of us working 5277bis had been planning on = supporting existing 5277 implementations via a separate backwards compatibi= lity section.  But as we have gone forward, we see no meaningful techn= ical overlaps.  I.e., there are no RPC or notifications shared between the 5277 and 5277bis solutions.  Any = compatibility mode section would be fully standalone.  Considering tha= t people can just refer to 5277 if they need it, and considering 5277 &= 5277bis could easily run in parallel on different transport sessions, building a standalone backwards compatibility section = seems both confusing and redundant.  

 

This leaves three options:

  (i.) OBSOLETE 5277 by replacing it with 52= 77bis

  (ii.) Support 5277bis without Ob= soleting 5277

  (iii.) Write a new UPDATE draft for 5= 277 NETCONF only transport

 

The benefits and issues of each are as follows:

 

(i.) OBSOLETE 5277 by replacing it with 5277bi= s   

  • Supports all requ= irements (1) through (8).
  • IETF does not continue protocol maintenance of 5277= .
    • Implementations c= an still choose 5277 or 5277bis, even though IETF recommends 5277bis.<= /o:p>
    • Impleme= ntations provide backwards compatibility through concurrent, parallel suppo= rt of both specifications.
    • Although obsoleted, the IETF does not deprecate 52= 77 so that current implementations may stay with existing 5277.<= /li>
  • Need to chan= ge the NETCONF WG charter to show that 5277 is being replaced rather than e= nhanced.

 

(ii.) Support 5277bis without Obsoleting 5277<= o:p>

  • Technically ident= ical to (i).
  • I= mplementations free to choose 5277 or 5277bis, with no guidance on which th= e WG recommends. 
    • This could be con= fusing to customers as NETCONF WG will be advocating competing technologies= for the place of overlap.  -- i.e., NETCONF over XML with a single su= bscription.
  • Establishes = competing technology futures where one direction would suffice.<= /li>

 

(iii.) Write a new UPDATE draft for 5277 NETCO= NF only transport

  • Supports a subset= of requirements:
    • Cannot support (1= ) or (8)
    • Supporting (2), (3), (4), (5), (6), & (7) possible, but would re= quire the creation of replicated/competing mechanisms with (8). 
  • Doubles the = development effort if the yang-push control plane is also required.
  • WG would = need to build guidelines on when to use 5277bis or this new UPDATE draft (a= ssuming the WG wanted to proceed with the transport independent 5277bis.)
  • No = identified author / champion for this path.  (Because business drivers= being driven by other than NETCONF/XML.)
  • Update draft itself wouldn’t = require a NETCONF charter update.

 

Based on this list, the people working in on the = Subscription & Event Notification weekly calls have a preference for (i= .) followed by (ii.).  Do you have a preference or additional question= s not addressed here or in the earlier threads?

 

Thanks,

Eric

 

--_000_644DA50AFA8C314EA9BDDAC83BD38A2ED53D15dfweml501mbb_-- From nobody Thu Jan 19 10:48:47 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBE271294BC for ; Thu, 19 Jan 2017 10:48:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 DQJmkEfXfNz9 for ; Thu, 19 Jan 2017 10:48:43 -0800 (PST) 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 4829D1293DB for ; Thu, 19 Jan 2017 10:48:43 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 1735B6E3; Thu, 19 Jan 2017 19:48:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id ZaVtjrUKadTL; Thu, 19 Jan 2017 19:48:38 +0100 (CET) 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, 19 Jan 2017 19:48:41 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7B148200A5; Thu, 19 Jan 2017 19:48:41 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vvJcJZF2SGAu; Thu, 19 Jan 2017 19:48:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D7F99200A3; Thu, 19 Jan 2017 19:48:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7C70C3E2B8D7; Thu, 19 Jan 2017 19:48:43 +0100 (CET) Date: Thu, 19 Jan 2017 19:48:42 +0100 From: Juergen Schoenwaelder To: Alexander Clemm Message-ID: <20170119184842.GA8407@elstar.local> Mail-Followup-To: Alexander Clemm , "Eric Voit (evoit)" , "netconf@ietf.org" References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> <20170119154002.GB8004@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 18:48:46 -0000 I think we should clearly separate _what_ kind of information notifications carry (and "subscription state notification" seems right on target here) from _how_ subscriptions to notificiations are created / deleted (explicit, implicit, ...) and we should I think avoid trying to find an opaque term like 'OAM notifications' that folds two separate concepts into a single and by itself confusing term. /js On Thu, Jan 19, 2017 at 06:29:33PM +0000, Alexander Clemm wrote: > Hi, > > The specific notifications under discussions are notifications that inform a receiver of notifications of changes to subscription state that will impact what notifications the receiver can expect to receive. What sets those particular notifications apart from other notifications is that you do not have to explicitly subscribe to them in order to receive them, and that the notifications are confined to that particular context and not subscribable to others. Instead, use of a particular feature (in this case, subscribing to a set of notifications) makes a user automatically "subscribed" to notifications in this context. > > While "subscription state notification" is in one sense an accurate description of what this does, I think a more general term may be more appropriate, for several reasons: > - To capture the different nature of this type of notification vs other notifications, e.g. an "interface state notification", which would behave genuinely differently in terms of how to subscribe to it. > - To allow for a generalization of this concept to other areas as well. The question is whether this is intended to be in charter, but it is certainly conceivable to use a similar type of notifications for other use cases. Think, for example, of an ongoing test in which intermediate updates about test progress would be sent using notifications - but those notifications should go only to the initiator of the test, and the initiator of the test should not have to separately subscribe to test update notifications. > > What about the term "OAM notifications"? or, to leave out "plane" from "control plane notifications" and simply call it "control notifications"? > > --- Alex > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen Schoenwaelder > Sent: Thursday, January 19, 2017 7:40 AM > To: Eric Voit (evoit) > Cc: netconf@ietf.org > Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure > > On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote: > > > > > > > > I think 'control plane notification' is a really bad term for what > > > > it does and the sooner we find a better term the better it is. > > > > A better term would be great, maybe "Subscription State Notification"? > > > > This proposed term is much much better. > > > I do think some term is helpful. These are the notifications which match 1:1 with the set of Subscription State model state changes on a Publisher. See 5277bis, section 2.4. > > > > Fine with me - as long as the term is specific. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- 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 Jan 19 11:56:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67F951294D1 for ; Thu, 19 Jan 2017 11:56:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.42 X-Spam-Level: X-Spam-Status: No, score=-7.42 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 hv5AZK0OxzZ3 for ; Thu, 19 Jan 2017 11:56:00 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A382129497 for ; Thu, 19 Jan 2017 11:55:59 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZD49782; Thu, 19 Jan 2017 19:55:57 +0000 (GMT) Received: from DFWEML703-CAH.china.huawei.com (10.193.5.177) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Thu, 19 Jan 2017 19:55:57 +0000 Received: from DFWEML501-MBB.china.huawei.com ([10.193.5.179]) by DFWEML703-CAH.china.huawei.com ([10.193.5.177]) with mapi id 14.03.0301.000; Thu, 19 Jan 2017 11:55:53 -0800 From: Alexander Clemm To: Juergen Schoenwaelder Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAAjbtYAADcHHIAACpzIgAAA9DoAAAtattD//9ngAIAAdYcw Date: Thu, 19 Jan 2017 19:55:52 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2ED53DC8@dfweml501-mbb> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> <20170119154002.GB8004@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> <20170119184842.GA8407@elstar.local> In-Reply-To: <20170119184842.GA8407@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020205.588119CE.0055, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=0.0.0.0, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: da3badadded048b8898501cb2cbf3260 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 19:56:02 -0000 OK, so for the purposes here I am fine with subscription state notification= s. =20 The question remains, however, whether we want to allow for generation of t= his concept and have this in charter. I.e., support the use cases of notif= ications intended for a specific receiver / tied to a specific object or lo= ng-lived operation that has a clear ownership. However, I am thinking of t= he example of the long-running test operation with continuous updates. App= lying something called subscription state notifications in that scenario ap= pears like a stretch, although the same concept would be applicable there. = To keep things simple, perhaps we should just keep ourselves to subscripti= on state notifications; at the same time it might a good opportunity to cap= ture this also while we are discussing the charter change. Anyway, it was = just a thought. =20 --- Alex =20 -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]=20 Sent: Thursday, January 19, 2017 10:49 AM To: Alexander Clemm Cc: Eric Voit (evoit) ; netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 = Options for Subscription & Event Notification draft structure I think we should clearly separate _what_ kind of information notifications= carry (and "subscription state notification" seems right on target here) f= rom _how_ subscriptions to notificiations are created / deleted (explicit, = implicit, ...) and we should I think avoid trying to find an opaque term li= ke 'OAM notifications' that folds two separate concepts into a single and b= y itself confusing term. /js On Thu, Jan 19, 2017 at 06:29:33PM +0000, Alexander Clemm wrote: > Hi, >=20 > The specific notifications under discussions are notifications that infor= m a receiver of notifications of changes to subscription state that will im= pact what notifications the receiver can expect to receive. What sets thos= e particular notifications apart from other notifications is that you do no= t have to explicitly subscribe to them in order to receive them, and that t= he notifications are confined to that particular context and not subscribab= le to others. Instead, use of a particular feature (in this case, subscrib= ing to a set of notifications) makes a user automatically "subscribed" to n= otifications in this context. =20 >=20 > While "subscription state notification" is in one sense an accurate descr= iption of what this does, I think a more general term may be more appropria= te, for several reasons: > - To capture the different nature of this type of notification vs other n= otifications, e.g. an "interface state notification", which would behave ge= nuinely differently in terms of how to subscribe to it. =20 > - To allow for a generalization of this concept to other areas as well. = The question is whether this is intended to be in charter, but it is certai= nly conceivable to use a similar type of notifications for other use cases.= Think, for example, of an ongoing test in which intermediate updates abou= t test progress would be sent using notifications - but those notifications= should go only to the initiator of the test, and the initiator of the test= should not have to separately subscribe to test update notifications. =20 >=20 > What about the term "OAM notifications"? or, to leave out "plane" from "= control plane notifications" and simply call it "control notifications"? =20 >=20 > --- Alex >=20 > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen=20 > Schoenwaelder > Sent: Thursday, January 19, 2017 7:40 AM > To: Eric Voit (evoit) > Cc: netconf@ietf.org > Subject: Re: [Netconf] New Notification and Subscription Features=20 > WASFW: 3 Options for Subscription & Event Notification draft structure >=20 > On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote: > > > > > > > > I think 'control plane notification' is a really bad term for=20 > > > > what it does and the sooner we find a better term the better it is. > >=20 > > A better term would be great, maybe "Subscription State Notification"? = =20 > > >=20 > This proposed term is much much better. >=20 > > I do think some term is helpful. These are the notifications which mat= ch 1:1 with the set of Subscription State model state changes on a Publishe= r. See 5277bis, section 2.4. =20 > > >=20 > Fine with me - as long as the term is specific. >=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 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --=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 Thu Jan 19 12:09:11 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16DED129482 for ; Thu, 19 Jan 2017 12:09:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wUiYd2BsQLLg for ; Thu, 19 Jan 2017 12:09:08 -0800 (PST) Received: from mail-yb0-x236.google.com (mail-yb0-x236.google.com [IPv6:2607:f8b0:4002:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE8F129463 for ; Thu, 19 Jan 2017 12:09:08 -0800 (PST) Received: by mail-yb0-x236.google.com with SMTP id j82so34293395ybg.1 for ; Thu, 19 Jan 2017 12:09:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=8JBs/v9rUXiAlfZ0rM1WkottSGaKGaPmMsCwv+qWN38=; b=BMf+ec07FzXatHf14Hv6CeQC6ODC4Jb7495GHBbn6vQxgvrqrWal6ZDgErT7FMklkL TkimrN5kk/zgztgIUPK3VXfUKq0hM9TTT8CE9dKdDzZNmP58BJejPWLJOUCkJyJnu0su eUumFfydMLnnOZTcNtc4WN9CgISCtnBE7FZR6iBzhelmhrqluMund4yLLYF9BrZYAXFw i86XYABLcEBTP2HBQsD6SXULSM2l5/saO8YBSt8LLOxSMx7vbqix6pSKkcrf08sQyQXT GhYt8vlVd00mhDTQQwYLZG5GpIidIZaofhGCPA84mz1YOafYJRkH9lewqO6HsKX1wobA zgiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=8JBs/v9rUXiAlfZ0rM1WkottSGaKGaPmMsCwv+qWN38=; b=WxDbBp8ZyHrdc5QylDJ/F/4nMr6wv+9k+JIUFzm8Xa4bzR8LEJ2hC9tO6TmHyp1Ckg IBpXHSVdkJ0elp/RmprwEoJjpc2EBmbsrJsKKs0dwRYN8OO2cR/Tdb1PFaKBHUegJPG6 y/vgiuoGSQBhyFPlsy6fd56/6f20k/B2ev/fEsaebZ90n2HsJ2SaXkqhM7ZGTfbncKiN it0zVcu0HiOmjV3tTmqvDSmyioOAaYdAhzJCzU294SgZR3FPs3CLdDXXXME4T6r6Tkpd aFJJvBsMeS40jG4zK81r7eaY7dduliDL/YDuqUhG/a0hOWWZ25+asYy9rDPtF3ywlNLE A4Cg== X-Gm-Message-State: AIkVDXL4fM+wzdZhTIUkl2Ld1VhLlv+7++7+A4P/PnWfXaV1Qmscd1lxMYW+ylNdYU9lofedGTelz8dZ1rm43A== X-Received: by 10.200.34.77 with SMTP id p13mr9380768qtp.35.1484856547408; Thu, 19 Jan 2017 12:09:07 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 19 Jan 2017 12:09:07 -0800 (PST) From: Andy Bierman Date: Thu, 19 Jan 2017 12:09:07 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a113ff8b20d30f30546781bfa Archived-At: Subject: [Netconf] CallHome question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:09:10 -0000 --001a113ff8b20d30f30546781bfa Content-Type: text/plain; charset=UTF-8 Hi, I am implementing CallHome and I do not see any text in sec 3. about dropping a connection if the peer is not doing the right thing. What if the TCP initiator is really another client doing a port scan and connects to the callhome socket? i.e., the initiator starts sending data right away instead of waiting for the callhome client to start an SSH or TLS session. Seems like the connection should get dropped right away instead of ignoring the data. I would also like the RFC to be published soon. I know it is waiting on the normative RESTCONF reference, but it is also waiting on 2 I-Ds as informative references. IMO the server model will not be done very soon and its mention in sec. 4.2 does not impact this draft at all. Andy --001a113ff8b20d30f30546781bfa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am implementing CallHome and I do= not see any text in sec 3.
about dropping a connection if the pe= er is not doing the right thing.
What if the TCP initiator is rea= lly another client doing a port scan
and connects to the callhome= socket? =C2=A0i.e., the initiator starts sending
data right away= instead of waiting for the callhome client to start
an SSH or TL= S session.

Seems like the connection should get dr= opped right away instead of
ignoring the data.

I would also like the RFC to be published soon.
I know it = is waiting on the normative RESTCONF reference,
but it is also wa= iting on 2 I-Ds as informative references.
IMO the server model w= ill not be done very soon and its mention
in sec. 4.2 does not im= pact this draft at all.


Andy
<= div>


--001a113ff8b20d30f30546781bfa-- From nobody Thu Jan 19 12:17:48 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 336E412948E for ; Thu, 19 Jan 2017 12:17:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 dJGfP0xmP42h for ; Thu, 19 Jan 2017 12:17:44 -0800 (PST) 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 40144129401 for ; Thu, 19 Jan 2017 12:17:44 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0FA807D1; Thu, 19 Jan 2017 21:17:43 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id v39Vv86G_Zjx; Thu, 19 Jan 2017 21:17:39 +0100 (CET) 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, 19 Jan 2017 21:17:42 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 402B9200A5; Thu, 19 Jan 2017 21:17:42 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id R7dZbld8D4Qy; Thu, 19 Jan 2017 21:17:40 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 7E203200A3; Thu, 19 Jan 2017 21:17:40 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 697C13E2BB54; Thu, 19 Jan 2017 21:17:43 +0100 (CET) Date: Thu, 19 Jan 2017 21:17:42 +0100 From: Juergen Schoenwaelder To: Alexander Clemm Message-ID: <20170119201742.GA8603@elstar.local> Mail-Followup-To: Alexander Clemm , "Eric Voit (evoit)" , "netconf@ietf.org" References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> <20170119154002.GB8004@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> <20170119184842.GA8407@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53DC8@dfweml501-mbb> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2ED53DC8@dfweml501-mbb> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:17:46 -0000 Alex, I do not think the current charter covers work on long running operations and intermediate updates. There were discussions some months / years ago about this and there are different possible solutions. I do not think the WG is chartered to work on any of these solutions right now. /js On Thu, Jan 19, 2017 at 07:55:52PM +0000, Alexander Clemm wrote: > OK, so for the purposes here I am fine with subscription state notifications. > > The question remains, however, whether we want to allow for generation of this concept and have this in charter. I.e., support the use cases of notifications intended for a specific receiver / tied to a specific object or long-lived operation that has a clear ownership. However, I am thinking of the example of the long-running test operation with continuous updates. Applying something called subscription state notifications in that scenario appears like a stretch, although the same concept would be applicable there. To keep things simple, perhaps we should just keep ourselves to subscription state notifications; at the same time it might a good opportunity to capture this also while we are discussing the charter change. Anyway, it was just a thought. > > --- Alex > > -----Original Message----- > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] > Sent: Thursday, January 19, 2017 10:49 AM > To: Alexander Clemm > Cc: Eric Voit (evoit) ; netconf@ietf.org > Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure > > I think we should clearly separate _what_ kind of information notifications carry (and "subscription state notification" seems right on target here) from _how_ subscriptions to notificiations are created / deleted (explicit, implicit, ...) and we should I think avoid trying to find an opaque term like 'OAM notifications' that folds two separate concepts into a single and by itself confusing term. > > /js > > On Thu, Jan 19, 2017 at 06:29:33PM +0000, Alexander Clemm wrote: > > Hi, > > > > The specific notifications under discussions are notifications that inform a receiver of notifications of changes to subscription state that will impact what notifications the receiver can expect to receive. What sets those particular notifications apart from other notifications is that you do not have to explicitly subscribe to them in order to receive them, and that the notifications are confined to that particular context and not subscribable to others. Instead, use of a particular feature (in this case, subscribing to a set of notifications) makes a user automatically "subscribed" to notifications in this context. > > > > While "subscription state notification" is in one sense an accurate description of what this does, I think a more general term may be more appropriate, for several reasons: > > - To capture the different nature of this type of notification vs other notifications, e.g. an "interface state notification", which would behave genuinely differently in terms of how to subscribe to it. > > - To allow for a generalization of this concept to other areas as well. The question is whether this is intended to be in charter, but it is certainly conceivable to use a similar type of notifications for other use cases. Think, for example, of an ongoing test in which intermediate updates about test progress would be sent using notifications - but those notifications should go only to the initiator of the test, and the initiator of the test should not have to separately subscribe to test update notifications. > > > > What about the term "OAM notifications"? or, to leave out "plane" from "control plane notifications" and simply call it "control notifications"? > > > > --- Alex > > > > -----Original Message----- > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Juergen > > Schoenwaelder > > Sent: Thursday, January 19, 2017 7:40 AM > > To: Eric Voit (evoit) > > Cc: netconf@ietf.org > > Subject: Re: [Netconf] New Notification and Subscription Features > > WASFW: 3 Options for Subscription & Event Notification draft structure > > > > On Thu, Jan 19, 2017 at 03:12:43PM +0000, Eric Voit (evoit) wrote: > > > > > > > > > > I think 'control plane notification' is a really bad term for > > > > > what it does and the sooner we find a better term the better it is. > > > > > > A better term would be great, maybe "Subscription State Notification"? > > > > > > > This proposed term is much much better. > > > > > I do think some term is helpful. These are the notifications which match 1:1 with the set of Subscription State model state changes on a Publisher. See 5277bis, section 2.4. > > > > > > > Fine with me - as long as the term is specific. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > Netconf mailing list > > Netconf@ietf.org > > https://www.ietf.org/mailman/listinfo/netconf > > -- > 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 Thu Jan 19 12:38:56 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 778D7129579 for ; Thu, 19 Jan 2017 12:38:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LBXp58OvkJ0m for ; Thu, 19 Jan 2017 12:38:51 -0800 (PST) Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0139.outbound.protection.outlook.com [104.47.32.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1814E12956F for ; Thu, 19 Jan 2017 12:38:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=66yWwyvr/k1W0Qy8QuXie7sjIcWRtFqK8uH1mML2P4E=; b=cjENWZzkdoguOiGc5wV+//M3OJKGc5V7KIyB3CGhPJXxsAUpS4tOLLCy6ImI03vq/i/f5RFuZWA5ZtqOwIsorWmdX2QzjchLExPzLzb+ZnIyN3PaUBPnIwvHhTXIggLcHsGjJduj1ShNrKNtr1qT9n5WPmzvWllRgKYgvshUqiA= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.860.6; Thu, 19 Jan 2017 20:38:48 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0860.012; Thu, 19 Jan 2017 20:38:48 +0000 From: Kent Watsen To: Andy Bierman , Netconf Thread-Topic: [Netconf] CallHome question Thread-Index: AQHSco/oDebohGDoukCmS8bjsz7ft6E/7x+A Date: Thu, 19 Jan 2017 20:38:47 +0000 Message-ID: <845EBFDD-37F9-46D1-8764-56DE78105C51@juniper.net> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.11] x-ms-office365-filtering-correlation-id: effc234e-1297-4f96-afce-08d440ab2b93 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:v/jx3haMTvFD5Y+hfRd3WoKjUy00FI6RR6bwodroxwQEHwPXd9xfD4V2NjXGIwUcbzVPoPiW9wgCSadaViZUIbJ6eo3AUQlOf642/FWIGTbeseiCUIXRusA+a+x8B2XDIBwsVoK1QV9NC1BQc1fU1SoOVR3qC2DQydLgN9zKlW3A2Tkkpr8SXXbfSBjpq1twgGfYZTXRNslbqlmPSacW1s3QxItxlwMxvOTSHabpxjKxpl/aJrfPviUbBC0HuF9HevLkh4gooSF+TS1WPw1RTD+SAlTkv1kWjG5xyE23XeiByv7sr1YHGk8YgwMPYwc5EwVdVWL4Bs4O0XHBqppIHbL0D8CzRlDzkzvpf9OX+g25QbsdC7VBXkzlG41wk5nWOT/RS4YtKdAZdQDCih37JVGSrEcwMFD4eSdZcm5I+Io2mLCaGStF81VdVLxMmLcXvhY5oD0HpCclXRmNYq5PWw== x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026)(6041248)(20161123560025)(20161123564025)(20161123555025)(20161123562025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0192E812EC x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39410400002)(39850400002)(39450400003)(39840400002)(39860400002)(189002)(199003)(25786008)(6116002)(189998001)(3280700002)(50986999)(6486002)(8676002)(54356999)(81156014)(229853002)(81166006)(8936002)(7736002)(68736007)(38730400001)(33656002)(107886002)(99286003)(6436002)(54896002)(66066001)(3846002)(76176999)(9326002)(2950100002)(102836003)(77096006)(5660300001)(2906002)(101416001)(6306002)(36756003)(106356001)(6506006)(6512007)(4001350100001)(105586002)(2900100001)(106116001)(5001770100001)(83716003)(82746002)(97736004)(16799955002)(3660700001)(92566002)(86362001)(83506001)(53936002)(122556002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_845EBFDD37F946D1876456DE78105C51junipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 19 Jan 2017 20:38:47.9005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Subject: Re: [Netconf] CallHome question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:38:53 -0000 --_000_845EBFDD37F946D1876456DE78105C51junipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwNCg0KPiBJIGFtIGltcGxlbWVudGluZyBDYWxsSG9tZSBhbmQgSSBkbyBub3Qgc2Vl IGFueSB0ZXh0IGluIHNlYyAzLg0KPiBhYm91dCBkcm9wcGluZyBhIGNvbm5lY3Rpb24gaWYgdGhl IHBlZXIgaXMgbm90IGRvaW5nIHRoZSByaWdodCB0aGluZy4NCj4gV2hhdCBpZiB0aGUgVENQIGlu aXRpYXRvciBpcyByZWFsbHkgYW5vdGhlciBjbGllbnQgZG9pbmcgYSBwb3J0IHNjYW4NCj4gYW5k IGNvbm5lY3RzIHRvIHRoZSBjYWxsaG9tZSBzb2NrZXQ/ICBpLmUuLCB0aGUgaW5pdGlhdG9yIHN0 YXJ0cyBzZW5kaW5nDQo+IGRhdGEgcmlnaHQgYXdheSBpbnN0ZWFkIG9mIHdhaXRpbmcgZm9yIHRo ZSBjYWxsaG9tZSBjbGllbnQgdG8gc3RhcnQNCj4gYW4gU1NIIG9yIFRMUyBzZXNzaW9uLg0KPg0K PiBTZWVtcyBsaWtlIHRoZSBjb25uZWN0aW9uIHNob3VsZCBnZXQgZHJvcHBlZCByaWdodCBhd2F5 IGluc3RlYWQgb2YNCj4gaWdub3JpbmcgdGhlIGRhdGEuDQoNCkknbSB1bnN1cmUgaWYgdGhpcyBp cyBhbiBvbWlzc2lvbiBvciBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuICBGb3IgaW5zdGFuY2UsDQpS RkM0MjUzIChTU0gpIGRvZXNuJ3Qgc3BlY2lmeSB3aGF0IGEgc2VydmVyIHNob3VsZCBkbyBpZiB0 aGUgY2xpZW50IGZhaWxzDQp0byBzZW5kIGFueXRoaW5nIGFmdGVyIHRoZSBUQ1Agc2Vzc2lvbiBo YXMgYmVlbiBlc3RhYmxpc2hlZC4gIENsZWFybHkgaXQNCnRpbWVzIG91dCwgYnV0ICp3aGVuKiBp cyBsZWZ0IHVuc3BlY2lmaWVkLg0KDQpTdGVwIEMzIHNheXMgdGhhdCB0aGUgTkMvUkMtY2xpZW50 IGltbWVkaWF0ZWx5IHN0YXJ0cyB0aGUgU1NIL1RMUw0KcHJvdG9jb2wgYWZ0ZXIgVENQIHNlc3Np b24gZXN0YWJsaXNobWVudCwgc28gYW55IHRpbWVvdXRzIG9yIG1hbGZvcm1lZA0KbWVzc2FnZSBo YW5kbGluZyB3b3VsZCBnbyB0byB0aGUgU1NIL1RMUyBsaWJyYXJ5IGJlaW5nIHVzZWQuICAgU3Vy ZWx5DQpzdWNoIG9jY3VycmVuY2VzIGFyZSBjYXVnaHQgYW5kIGNvbnRyb2wgaXMgcmV0dXJuZWQg dG8gdGhlIGFwcCwgd2hpY2ggSSdkDQpleHBlY3QgdG8gY2xvc2UgdGhlIGNvbm5lY3Rpb24uDQoN CkFyZSB5b3Ugc3VnZ2VzdGluZyBhbiBlcnJhdHVtIGJlIGZpbGVkIGZvciB0aGlzPw0KDQo+IEkg d291bGQgYWxzbyBsaWtlIHRoZSBSRkMgdG8gYmUgcHVibGlzaGVkIHNvb24uDQo+IEkga25vdyBp dCBpcyB3YWl0aW5nIG9uIHRoZSBub3JtYXRpdmUgUkVTVENPTkYgcmVmZXJlbmNlLA0KPiBidXQg aXQgaXMgYWxzbyB3YWl0aW5nIG9uIDIgSS1EcyBhcyBpbmZvcm1hdGl2ZSByZWZlcmVuY2VzLg0K PiBJTU8gdGhlIHNlcnZlciBtb2RlbCB3aWxsIG5vdCBiZSBkb25lIHZlcnkgc29vbiBhbmQgaXRz IG1lbnRpb24NCj4gaW4gc2VjLiA0LjIgZG9lcyBub3QgaW1wYWN0IHRoaXMgZHJhZnQgYXQgYWxs Lg0KDQpJJ3ZlIGJlZW4gdG9sZCB0aGF0IEluZm9ybWF0aW9uYWwgcmVmZXJlbmNlcyBkbyBub3Qg YmxvY2sgYSBkcmFmdCBmcm9tDQptb3ZpbmcgdG8gUkZDIHN0YXRlLiAgT24gdGhpcyBwYWdlLCB0 aGUgY2FsbC1ob21lIGRyYWZ0IGlzIGxpc3RlZCBhcw0Kb25seSBiZWluZyBibG9ja2VkIGJ5IHRo ZSBSRVNUQ09ORiBkcmFmdDoNCiAgICAtIGh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2NsdXN0 ZXJfaW5mby5waHA/Y2lkPUMyNzkNCg0KDQpLZW50DQoNCg0K --_000_845EBFDD37F946D1876456DE78105C51junipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <8D863B391D58374FABBB63D81DBC6501@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0 IDUgMyA1IDQgNiAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWws IGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0 b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0 ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0K CWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxT dHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNh bGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3Rl eHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0K CXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBl OmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpl eHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtz aXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2 LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFk Pg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0i cHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij5IaSBBbmR5LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIGFtIGltcGxl bWVudGluZyBDYWxsSG9tZSBhbmQgSSBkbyBub3Qgc2VlIGFueSB0ZXh0IGluIHNlYyAzLjxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBhYm91 dCBkcm9wcGluZyBhIGNvbm5lY3Rpb24gaWYgdGhlIHBlZXIgaXMgbm90IGRvaW5nIHRoZSByaWdo dCB0aGluZy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPiZndDsgV2hhdCBpZiB0aGUgVENQIGluaXRpYXRvciBpcyByZWFsbHkgYW5vdGhlciBjbGll bnQgZG9pbmcgYSBwb3J0IHNjYW48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPiZndDsgYW5kIGNvbm5lY3RzIHRvIHRoZSBjYWxsaG9tZSBzb2NrZXQ/ ICZuYnNwO2kuZS4sIHRoZSBpbml0aWF0b3Igc3RhcnRzIHNlbmRpbmc8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgZGF0YSByaWdodCBhd2F5 IGluc3RlYWQgb2Ygd2FpdGluZyBmb3IgdGhlIGNhbGxob21lIGNsaWVudCB0byBzdGFydDxvOnA+ PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBhbiBT U0ggb3IgVExTIHNlc3Npb24uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj4mZ3Q7PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IFNlZW1zIGxpa2UgdGhlIGNvbm5lY3Rpb24gc2hvdWxk IGdldCBkcm9wcGVkIHJpZ2h0IGF3YXkgaW5zdGVhZCBvZjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+ DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBpZ25vcmluZyB0aGUgZGF0YS48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSdtIHVuc3VyZSBpZiB0aGlzIGlz IGFuIG9taXNzaW9uIG9yIGltcGxlbWVudGF0aW9uIGRldGFpbC4mbmJzcDsgRm9yIGluc3RhbmNl LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UkZDNDI1MyAoU1NIKSBkb2Vz bid0IHNwZWNpZnkgd2hhdCBhIHNlcnZlciBzaG91bGQgZG8gaWYgdGhlIGNsaWVudCBmYWlsczxv OnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+dG8gc2VuZCBhbnl0aGluZyBhZnRl ciB0aGUgVENQIHNlc3Npb24gaGFzIGJlZW4gZXN0YWJsaXNoZWQuJm5ic3A7IENsZWFybHkgaXQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRpbWVzIG91dCwgYnV0ICp3aGVu KiBpcyBsZWZ0IHVuc3BlY2lmaWVkLiZuYnNwOyA8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+U3Rl cCBDMyBzYXlzIHRoYXQgdGhlIE5DL1JDLWNsaWVudCBpbW1lZGlhdGVseSBzdGFydHMgdGhlIFNT SC9UTFM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnByb3RvY29sIGFmdGVy IFRDUCBzZXNzaW9uIGVzdGFibGlzaG1lbnQsIHNvIGFueSB0aW1lb3V0cyBvciBtYWxmb3JtZWQ8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPm1lc3NhZ2UgaGFuZGxpbmcgd291 bGQgZ28gdG8gdGhlIFNTSC9UTFMgbGlicmFyeSBiZWluZyB1c2VkLiZuYnNwOyAmbmJzcDtTdXJl bHk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnN1Y2ggb2NjdXJyZW5jZXMg YXJlIGNhdWdodCBhbmQgY29udHJvbCBpcyByZXR1cm5lZCB0byB0aGUgYXBwLCB3aGljaCBJJ2Q8 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmV4cGVjdCB0byBjbG9zZSB0aGUg Y29ubmVjdGlvbi48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5i c3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QXJlIHlvdSBzdWdnZXN0aW5nIGFu IGVycmF0dW0gYmUgZmlsZWQgZm9yIHRoaXM/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIHdv dWxkIGFsc28gbGlrZSB0aGUgUkZDIHRvIGJlIHB1Ymxpc2hlZCBzb29uLjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmd0OyBJIGtub3cgaXQgaXMg d2FpdGluZyBvbiB0aGUgbm9ybWF0aXZlIFJFU1RDT05GIHJlZmVyZW5jZSw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgYnV0IGl0IGlzIGFs c28gd2FpdGluZyBvbiAyIEktRHMgYXMgaW5mb3JtYXRpdmUgcmVmZXJlbmNlcy48bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZndDsgSU1PIHRoZSBz ZXJ2ZXIgbW9kZWwgd2lsbCBub3QgYmUgZG9uZSB2ZXJ5IHNvb24gYW5kIGl0cyBtZW50aW9uPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mZ3Q7IGlu IHNlYy4gNC4yIGRvZXMgbm90IGltcGFjdCB0aGlzIGRyYWZ0IGF0IGFsbC48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSd2ZSBiZWVuIHRvbGQgdGhhdCBJbmZvcm1hdGlv bmFsIHJlZmVyZW5jZXMgZG8gbm90IGJsb2NrIGEgZHJhZnQgZnJvbTxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+bW92aW5nIHRvIFJGQyBzdGF0ZS4gJm5ic3A7T24gdGhpcyBw YWdlLCB0aGUgY2FsbC1ob21lIGRyYWZ0IGlzIGxpc3RlZCBhcw0KPG86cD48L286cD48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5vbmx5IGJlaW5nIGJsb2NrZWQgYnkgdGhlIFJFU1RDT05GIGRy YWZ0OjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7Jm5ic3A7Jm5i c3A7IC0gaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY2x1c3Rlcl9pbmZvLnBocD9jaWQ9QzI3 OTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PktlbnQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_845EBFDD37F946D1876456DE78105C51junipernet_-- From nobody Thu Jan 19 12:49:18 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EF5CA129593 for ; Thu, 19 Jan 2017 12:49:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNnWVzqySrNT for ; Thu, 19 Jan 2017 12:49:15 -0800 (PST) Received: from mail-yw0-x232.google.com (mail-yw0-x232.google.com [IPv6:2607:f8b0:4002:c05::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E08B212955A for ; Thu, 19 Jan 2017 12:49:14 -0800 (PST) Received: by mail-yw0-x232.google.com with SMTP id u68so10104644ywg.0 for ; Thu, 19 Jan 2017 12:49:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Sz1RgOHOtFbnBOOxk99iqzhcakNkUIffyMuN8fwOB2U=; b=ArE0oynFJOJDn0S/FdT5zxkgqYDu/MN+PAWaf6eUmz+ywzYPB4X67X+XodWWyLXma4 zE6V5nSCG1VZEODBUoHEmlWVljzMVPM149Qctf+g7pK/cdY06zyhOCp9CyDpwtYxqLcJ SonV2IHmqZqhaimOtbA8F51QgTqap0LCn3kgsUK7uxf5+LI/DyxjaNpfsAttZF+17/di QiUVfJnhwnKm0r/o2HogTX1PW6Cfj9Ii3Y2V4Mqbo8yu23RvdxwmXgcx7KuJvCkaFpvH knNRJdy1PwTPqc2c2jO7hUeynuLdNgYLN+dezhbn3x45JMgZIbVEZjqqBBFn7YZiW6ln mElw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Sz1RgOHOtFbnBOOxk99iqzhcakNkUIffyMuN8fwOB2U=; b=KytNFpm04V/RZjyF/ttodf7CU9ImrUFqtfOPPwdn4DEO+WX8jBLkDnt/nrdcR06eVT CeTaWkCX+0RaBY0Lg2Qre0MgBTbHnQgoIUzpk6L+qViyblaTpvXVNWEygS3UG8Rs6yNa KdZLD0EEtxAw4tdqvFU/Sn+YVlnoBnZTdyd+47EVXaKjCYA+I+2zaf+GsQ4ITXkaMQV/ S3qwCxxsHQHYL0kDtQkhJp0fixp8Vu8wV2P4b3HLyDHMYUkS1Vz1D9JlJqSlQw5Ma78A F65bQapJudSYC7YhCjc7vJMy2IKne8BU5JM+WuMLFLSMa/rSlRVdjxzqxwPIhfB0NOqO GDeg== X-Gm-Message-State: AIkVDXJKHxDm+sIBGJ+cuRCovytFPNipzbd62ll+yhTUoY1RHEndy5wXWBf7ZkJeLsZlwoXbCWeTFYqAKck7yQ== X-Received: by 10.55.20.137 with SMTP id 9mr9305912qku.237.1484858954064; Thu, 19 Jan 2017 12:49:14 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Thu, 19 Jan 2017 12:49:13 -0800 (PST) In-Reply-To: <845EBFDD-37F9-46D1-8764-56DE78105C51@juniper.net> References: <845EBFDD-37F9-46D1-8764-56DE78105C51@juniper.net> From: Andy Bierman Date: Thu, 19 Jan 2017 12:49:13 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1144d2267fd00a054678aadb Archived-At: Cc: Netconf Subject: Re: [Netconf] CallHome question X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Jan 2017 20:49:17 -0000 --001a1144d2267fd00a054678aadb Content-Type: text/plain; charset=UTF-8 On Thu, Jan 19, 2017 at 12:38 PM, Kent Watsen wrote: > Hi Andy, > > > > > I am implementing CallHome and I do not see any text in sec 3. > > > about dropping a connection if the peer is not doing the right thing. > > > What if the TCP initiator is really another client doing a port scan > > > and connects to the callhome socket? i.e., the initiator starts sending > > > data right away instead of waiting for the callhome client to start > > > an SSH or TLS session. > > > > > > Seems like the connection should get dropped right away instead of > > > ignoring the data. > > > > I'm unsure if this is an omission or implementation detail. For instance, > > RFC4253 (SSH) doesn't specify what a server should do if the client fails > > to send anything after the TCP session has been established. Clearly it > > times out, but *when* is left unspecified. > > > > Step C3 says that the NC/RC-client immediately starts the SSH/TLS > > protocol after TCP session establishment, so any timeouts or malformed > > message handling would go to the SSH/TLS library being used. Surely > > such occurrences are caught and control is returned to the app, which I'd > > expect to close the connection. > > > > Are you suggesting an erratum be filed for this? > No -- I think after step C3 the client will be expecting a specific response. If this takes care of the client dropping the connection due to an invalid SSH or TLS session startup. In implementation, the client does not need to to a read after the accept() on the callhome socket (as a server would normally do). The client can just start sending on the new connection. > > > > I would also like the RFC to be published soon. > > > I know it is waiting on the normative RESTCONF reference, > > > but it is also waiting on 2 I-Ds as informative references. > > > IMO the server model will not be done very soon and its mention > > > in sec. 4.2 does not impact this draft at all. > > > > I've been told that Informational references do not block a draft from > > moving to RFC state. On this page, the call-home draft is listed as > > only being blocked by the RESTCONF draft: > > - https://www.rfc-editor.org/cluster_info.php?cid=C279 > > > > > OK > Kent > > > > > Andy --001a1144d2267fd00a054678aadb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Thu, Jan 19, 2017 at 12:38 PM, Kent Watsen <kwatsen@juniper.net> wrote:

Hi Andy,

=C2=A0

> I am implementing CallHome and I do not see any= text in sec 3.

> about dropping a connection if the peer is not = doing the right thing.

> What if the TCP initiator is really another cli= ent doing a port scan

> and connects to the callhome socket? =C2=A0i.e.= , the initiator starts sending

> data right away instead of waiting for the call= home client to start

> an SSH or TLS session.

>=C2=A0

> Seems like the connection should get dropped ri= ght away instead of

> ignoring the data.

=C2=A0

I'm unsure if this is an omission or implementat= ion detail.=C2=A0 For instance,

RFC4253 (SSH) doesn't specify what a server shou= ld do if the client fails

to send anything after the TCP session has been esta= blished.=C2=A0 Clearly it

times out, but *when* is left unspecified.=C2=A0 =

=C2=A0

Step C3 says that the NC/RC-client immediately start= s the SSH/TLS

protocol after TCP session establishment, so any tim= eouts or malformed

message handling would go to the SSH/TLS library bei= ng used.=C2=A0 =C2=A0Surely

such occurrences are caught and control is returned = to the app, which I'd

expect to close the connection.

=C2=A0

Are you suggesting an erratum be filed for this?

=

No -- I think after step= C3 the client will be expecting a specific response.
If this tak= es care of the client dropping the connection due
to an invalid S= SH or TLS session startup.

In implementation, the = client does not need to to a read after the accept()
on the callh= ome socket (as a server would normally do).=C2=A0 The client can
= just start sending on the new connection.


Andy

--001a1144d2267fd00a054678aadb-- From nobody Fri Jan 20 07:26:20 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9787129961; Fri, 20 Jan 2017 07:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 OvcE20dWtJn1; Fri, 20 Jan 2017 07:26:09 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B5EF129BDC; Fri, 20 Jan 2017 07:26:09 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [209.87.249.21]) by tuna.sandelman.ca (Postfix) with ESMTP id F11DCE1E4; Fri, 20 Jan 2017 10:46:07 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 03837636BB; Fri, 20 Jan 2017 10:26:08 -0500 (EST) From: Michael Richardson To: anima@ietf.org, 6tisch@ietf.org X-Attribution: mcr X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.5.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Cc: anima-bootstrap , netconf@ietf.org, 6tisch-security@ietf.org Subject: [Netconf] converging on some common terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: anima@ietf.org, 6tisch@ietf.org List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 15:26:11 -0000 --=-=-= Content-Type: text/plain At the 6tisch-security design team call and then on the anima bootstrap call on Tuesday, we discussed merging of terminology as an important step to getting all the bootstrap ideas together. These are the terms which we have concluded on: 1) PLEDGE. replaces Joining Node and "New Node" 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. The "Coordinator" part is considered a seperate, co-located, but optional role. 4) MASA. remains the same. 5) vendor provided interface that MASA uses to talk to remains unnamed. Here are the proposals therefore: ANIMA, dtbootstrap document. was already using PLEDGE. (KEEP IT) PROXY -> JOIN PROXY. REGISTRAR -> officially, "Join Registrar", maybe be shortened in the text to "Registrar" where this is unambiguous. 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Phase two"): Was using Joining Node --> Pledge. Was using Join Assistant --> Join Proxy Was using Joint Coordination Entity (JCE) -> Join Registrar and Coordinator. Adds term MASA. Additional terms which we need to import: 1) "drop ship" 2) "imprint", 3) "enrollment", 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. There also some discussion about the terminology used by 802.15.10: "mesh root" <- has a coordinator role and a registrar role as I understand it. We asked if: Registrar and Coordinator always co-located? We thought so, but there could be exceptions, and it might be out of scope. ACTION ITEMS ============ 1) ANIMA documents to update terms, and be authoritative for terms. 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminology. 3) 6tisch terminology document to include the terms as being imported from ANIMA. 4) netconf: probably just adjust terminology to point at when they terms are the same as ANIMA, or when they are different. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAliCLA8ACgkQgItw+93Q 3WXILggAikWHJ5gI/lcU8OmBhhUolxtusxq/watPkHC4XwQb5rT54dXtQigsGH72 1F+4JMRS9VxunGSqnQPeA+fL9XUubzxvaAmErDe9epnqWTJzol0hM244ceymNkm3 oU40o+ZDRmiIJr4uW7qEjvBKE3Cy6YdGIL34Ybgtt9Gt7I3GYoCv/MFHv9X/yEr2 UhzwPhOqudjSKdx6jokGo7VdlFHqfMZD4T1WUxBL69NW0XvtQzI0BOvNocHHIxg5 Sa9jN6CUsgFTO0Z8BW9a2qO6bcHlnQUS+ikRmF7T4ap0k+Csq4z7ENNii0s2Qcd/ BgH3o369Q8W8UJh+bm30koYMiYTRGQ== =xsrY -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 20 09:16:00 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE13129490; Fri, 20 Jan 2017 09:15:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ou_QbHC1u-wo; Fri, 20 Jan 2017 09:15:44 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C41F8126B6D; Fri, 20 Jan 2017 09:15:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2787; q=dns/txt; s=iport; t=1484932544; x=1486142144; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=4ji28jbCLINaAXd269+Np6Grxx6glkR4+CqK14tdI64=; b=QAnuVK6FVnSUf9/30cKO5FJzQb7PbaPL+RyxM+HX6uarLjJp6GHse1/c 7JNyO11OYHiGVLDfoD92UT8W2Qw0XAHf+SBYn3CInbUV02PTOXIV9RPGD DkWMiCNXOUtFUSmRiLrbLDc+dhZH+SFIJaxL8hPQORH2YjAUMrNHcKXzL 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AUAQC5RIJY/4sNJK1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgz0BAQEBAR+BaQeNVJIDlS6CDIJsgzYCghQ/FAECAQEBAQEBAWM?= =?us-ascii?q?ohGkBAQEEJxM/DAQCAQgRBAEBHwkHMhQJCAIEAQ0FCIh8sS46ikIBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEdhkuEcIotBZU3hhEBkV2CAI53iB6KVQEfOIFFFYZvc4g?= =?us-ascii?q?HgQ0BAQE?= X-IronPort-AV: E=Sophos;i="5.33,259,1477958400"; d="scan'208";a="374460537" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Jan 2017 17:15:43 +0000 Received: from XCH-ALN-005.cisco.com (xch-aln-005.cisco.com [173.36.7.15]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id v0KHFgxQ015963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 20 Jan 2017 17:15:43 GMT Received: from xch-rcd-001.cisco.com (173.37.102.11) by XCH-ALN-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Fri, 20 Jan 2017 11:15:42 -0600 Received: from xch-rcd-001.cisco.com ([173.37.102.11]) by XCH-RCD-001.cisco.com ([173.37.102.11]) with mapi id 15.00.1210.000; Fri, 20 Jan 2017 11:15:42 -0600 From: "Pascal Thubert (pthubert)" To: "anima@ietf.org" , "6tisch@ietf.org" <6tisch@ietf.org> Thread-Topic: [6tisch] converging on some common terminology Thread-Index: AQHSczGM3CVAjZlwgEW6Reon1I50pKFBmpdA Date: Fri, 20 Jan 2017 17:15:27 +0000 Deferred-Delivery: Fri, 20 Jan 2017 17:15:14 +0000 Message-ID: <54870898247e402499d8cfff9dbe6cce@XCH-RCD-001.cisco.com> References: <2978.1484925967@obiwan.sandelman.ca> In-Reply-To: <2978.1484925967@obiwan.sandelman.ca> Accept-Language: fr-FR, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.22.4] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: anima-bootstrap , "netconf@ietf.org" , "6tisch-security@ietf.org" <6tisch-security@ietf.org> Subject: Re: [Netconf] [6tisch] converging on some common terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2017 17:15:45 -0000 Thanks a lot Michael! I do support this convergence which will help people working at the interse= ction of IOT and ANIMA, which hopefully is quite extensive. Take care, Pascal -----Original Message----- From: 6tisch [mailto:6tisch-bounces@ietf.org] On Behalf Of Michael Richards= on Sent: vendredi 20 janvier 2017 16:26 To: anima@ietf.org; 6tisch@ietf.org Cc: anima-bootstrap ; netconf@ietf.org; 6tisch-se= curity@ietf.org Subject: [6tisch] converging on some common terminology At the 6tisch-security design team call and then on the anima bootstrap cal= l on Tuesday, we discussed merging of terminology as an important step to g= etting all the bootstrap ideas together. These are the terms which we have concluded on: 1) PLEDGE. replaces Joining Node and "New Node" 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. The "Coordinator" part is considered a seperate, co-located, but optional role. 4) MASA. remains the same. 5) vendor provided interface that MASA uses to talk to remains unnamed. Here are the proposals therefore: ANIMA, dtbootstrap document. was already using PLEDGE. (KEEP IT) PROXY -> JOIN PROXY. REGISTRAR -> officially, "Join Registrar", maybe be shortened in the text to "Registrar" where this is unambiguous. 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Pha= se two"): Was using Joining Node --> Pledge. Was using Join Assistant --> Join Proxy Was using Joint Coordination Entit= y (JCE) -> Join Registrar and Coordinator. Adds term MASA. Additional terms which we need to import: 1) "drop ship" 2) "imprint", 3) "enrollment", 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. There also some discussion about the terminology used by 802.15.10: "mesh root" <- has a coordinator role and a registrar role as I understand it. We asked if: Registrar and Coordinator always co-located? We thought so, but there could be exceptions, and it might be out of scope. ACTION ITEMS =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D 1) ANIMA documents to update terms, and be authoritative for terms. 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminolo= gy. 3) 6tisch terminology document to include the terms as being imported from = ANIMA. 4) netconf: probably just adjust terminology to point at when they terms ar= e the same as ANIMA, or when they are different. -- Michael Richardson , Sandelman Software Works -=3D = IPv6 IoT consulting =3D- From nobody Sat Jan 21 12:39:07 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0FFF1293FD for ; Sat, 21 Jan 2017 12:39:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.094 X-Spam-Level: X-Spam-Status: No, score=-1.094 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, SUBJ_ALL_CAPS=1.506] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fRjTYbDcIxQ7 for ; Sat, 21 Jan 2017 12:39:04 -0800 (PST) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 987DC127071 for ; Sat, 21 Jan 2017 12:39:04 -0800 (PST) Received: by mail-qt0-x236.google.com with SMTP id v23so74360151qtb.0 for ; Sat, 21 Jan 2017 12:39:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=YtooVfELkczByGhRr2+IdSyvY3DGCH4rDrXNg4LI8wo=; b=NWwm7mga6WHcCz6GF4+9qCPQ1Y8xiAnGnQpIs3hyBKOdk90JOSDw2w6FPjXvOLshnp SfbKQNdqxo6vcRUBVOajg5YddggiCZRYy2jIR6zxBu/L3fzzkcCGUskBGf0GfSnZew4Y oX4zbgSMjlpFJNlnq63F5bBtxkjxMhiLhZPsDh6F3Kd5RTmHnTLcKEGh+bVg7nz1iCDQ Y4J3/R06ltmd19Z5JcLGjoukt+OhFRJCCMcj6PuqZd6c7Dlqn9s8MZV7TPm+0L+cW8XI tmQ/zPTDqDnZB/CciiRYgdv7sEyQDz/IbLeAiEqxgxf5WRv/JV9WFpaMI/0Bu7fHm/+A FG7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=YtooVfELkczByGhRr2+IdSyvY3DGCH4rDrXNg4LI8wo=; b=A3gSbue+0o4yc2QHTi4z/6JcqceGU1tjg+gsXscXPFuLuSZ49K0GJAtE13ERIs/H4E 8/acxjpGImA/XZ7ha4OMCLd+YPKUP6egKOXoC4YTvuSlQEjAc9vVqnUlQoclS5aLi03q FScnnXais0WcN/N72YaaX5YPgCppOPXBnj+pqEwQHZECk+Q0yX00gLN7KMW7VL2UNF/R q8kgwBKS2cZbypHJBAcXzBrPe72fg5QiKF0NFglljTrvHE/VADzsBbdj88IMxuMhVZc1 iuClkukj8aj8wGALzwbF7IiP+5I+HlLsv7lbs/HfziKPygtq7Zj+TaMTL8nEGvsrd5lz Pu8Q== X-Gm-Message-State: AIkVDXLV7YyvRkesFjPZoYOq9A+lLH/+C6g1Q0MHSiWiE6h6sizlucEUxvDk/jiNN2ufmkwZ29A3KcN34q7jDQ== X-Received: by 10.200.34.77 with SMTP id p13mr17703525qtp.35.1485031143575; Sat, 21 Jan 2017 12:39:03 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Sat, 21 Jan 2017 12:39:03 -0800 (PST) From: Andy Bierman Date: Sat, 21 Jan 2017 12:39:03 -0800 Message-ID: To: Netconf Content-Type: multipart/alternative; boundary=001a113ff8b2cb27400546a0c121 Archived-At: Subject: [Netconf] NETCONF 1.2 X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 20:39:06 -0000 --001a113ff8b2cb27400546a0c121 Content-Type: text/plain; charset=UTF-8 Hi, I created a github repo for rfc6241bis https://github.com/netconf-wg/rfc6241bis I think we should gather issues and feature requests for NETCONF 1.2 in case we create a new version of NETCONF someday. Issue List: https://github.com/netconf-wg/rfc6241bis/issues BTW, we changed our server so it complies with issue #1. (You win Robert!) Andy --001a113ff8b2cb27400546a0c121 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I created a github repo for rfc6241= bis

I think w= e should gather issues and feature requests for NETCONF 1.2
in ca= se we create a new version of NETCONF someday.

Iss= ue List:

<= /div>
BTW, we changed our server so it complies with issue #1.
(You win Robert!)


Andy
=
--001a113ff8b2cb27400546a0c121-- From nobody Sat Jan 21 13:43:08 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C2B671293F5; Sat, 21 Jan 2017 13:42:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5ljedaoFkmD; Sat, 21 Jan 2017 13:42:50 -0800 (PST) Received: from mail-pg0-x241.google.com (mail-pg0-x241.google.com [IPv6:2607:f8b0:400e:c05::241]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01F631293FD; Sat, 21 Jan 2017 13:42:49 -0800 (PST) Received: by mail-pg0-x241.google.com with SMTP id t6so9963284pgt.1; Sat, 21 Jan 2017 13:42:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:cc:from:organization:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=2zlio+A7Zjk4w3eOZxGIXHfVQXEPNl/g/dvDott7uKQ=; b=dH1v8N7+UqeV8hlTrvGvohhgq3rvUKiM6o+LyXbZ6n9zoI5SKOiYLMQRlR6mBkqiNo fXDDtiyctE3KMOZ1/tllhHd5arRHWPHcoR64IZe3LRom/DWZ9mfjM4/eUK1hg2pkylhe shjaMENjImTc3+aQH6B9k5CBVxodHB9ZUz+LKS688OaxRYVylzrsPOtkobeNB2Q1RiZ6 UcuMQel4gyypvl0Bm9QLCrGWwfDmHWZT9aRZyydyHDXqhr0GNpIp8M2gn7ceon+IIUVM NbiHjmWjN+l2AJWoKDcc4T9CJZGnEHw1tp4hN2WhNZzsCTrH7hLVn51httqZZAWJf49u FvMA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:cc:from:organization :message-id:date:user-agent:mime-version:in-reply-to :content-transfer-encoding; bh=2zlio+A7Zjk4w3eOZxGIXHfVQXEPNl/g/dvDott7uKQ=; b=We5U8XyIPD0gmJ54ZBpxbVkTwSaBDmQi9TLy64ohPaJjfCjvDDua076htzSTiYN1AL e/VGS9ws7HkxdDVYN5pyD96Q5ZTy7iXZNZbUW6SkECpAGOw69+13J5I3fKloZaqRakhR +BtYO/+EItN9J+EidqkdUO6ff51r9xgxWXHX7NLPIA4jK9H/PTYT7dQDrHrDppzoYolu 2EFftipqfHfMqrZP3AGg7ujaLsb5NZQEDKBfUrrJehcGMODplfHuYZdGYCpETKxevFC4 UNy2GyG/X/2BsK+4ziAbKKlu/1VILhxmPdVcQghXZbjTyu7mWI/Irz0/LtvOgLjRV43d DuBw== X-Gm-Message-State: AIkVDXK4jH43ggHAbD8IHrLkYTjtNlewQIF2SPRa/3WDe+n75++s5MK4KHrGaz8lCCPI8A== X-Received: by 10.84.215.149 with SMTP id l21mr16336372pli.16.1485034969394; Sat, 21 Jan 2017 13:42:49 -0800 (PST) Received: from [192.168.178.21] (84.25.255.123.static.snap.net.nz. [123.255.25.84]) by smtp.gmail.com with ESMTPSA id o126sm26102154pga.34.2017.01.21.13.42.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 21 Jan 2017 13:42:48 -0800 (PST) To: anima@ietf.org, 6tisch@ietf.org References: <2978.1484925967@obiwan.sandelman.ca> From: Brian E Carpenter Organization: University of Auckland Message-ID: <676ffd6f-7e9a-5879-a08e-41b1c3b72ad9@gmail.com> Date: Sun, 22 Jan 2017 10:42:42 +1300 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <2978.1484925967@obiwan.sandelman.ca> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Archived-At: Cc: anima-bootstrap , netconf@ietf.org, 6tisch-security@ietf.org Subject: Re: [Netconf] [Anima-bootstrap] converging on some common terminology X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2017 21:42:51 -0000 So, we should adopt this terminology for the GRASP objectives, I guess. We also need to make them correspond to the latest thinking in other ways too. Any more comments on draft-carpenter-anima-ani-objectives before we update it? Regards Brian On 21/01/2017 04:26, Michael Richardson wrote: > > At the 6tisch-security design team call and then on the anima bootstrap call > on Tuesday, we discussed merging of terminology as an important step to > getting all the bootstrap ideas together. > > These are the terms which we have concluded on: > > 1) PLEDGE. replaces Joining Node and "New Node" > 2) JOIN PROXY. replaces Join Assistant and bare "Proxy" > 3) JOIN REGISTRAR (and Coordinator). Replaces bare "Registrar", and JCE. > The "Coordinator" part is considered a seperate, > co-located, but optional role. > > 4) MASA. remains the same. > 5) vendor provided interface that MASA uses to talk to remains unnamed. > > Here are the proposals therefore: > > ANIMA, dtbootstrap document. > was already using PLEDGE. (KEEP IT) > PROXY -> JOIN PROXY. > REGISTRAR -> officially, "Join Registrar", maybe be shortened > in the text to "Registrar" where this is unambiguous. > > 6tisch-dtsecurity ("Phase one") and 6tisch-minimal security ("One-Touch/Phase two"): > > Was using Joining Node --> Pledge. > Was using Join Assistant --> Join Proxy > Was using Joint Coordination Entity (JCE) -> Join Registrar and Coordinator. > Adds term MASA. > > Additional terms which we need to import: > > 1) "drop ship" > 2) "imprint", > 3) "enrollment", > 4) "audit token", "ownership token" <- from draft-ietf-anima-voucher. > > There also some discussion about the terminology used by 802.15.10: > "mesh root" <- has a coordinator role and a registrar role as I > understand it. > > We asked if: Registrar and Coordinator always co-located? > We thought so, but there could be exceptions, and it might be out of scope. > > > ACTION ITEMS > ============ > 1) ANIMA documents to update terms, and be authoritative for terms. > 2) 6tisch documents to update terms, pointing at ANIMA and 6tisch terminology. > 3) 6tisch terminology document to include the terms as being imported from ANIMA. > 4) netconf: probably just adjust terminology to point at when they terms are > the same as ANIMA, or when they are different. > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > > > _______________________________________________ > Anima-bootstrap mailing list > Anima-bootstrap@ietf.org > https://www.ietf.org/mailman/listinfo/anima-bootstrap > From nobody Tue Jan 24 22:54:25 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 537D3129841 for ; Tue, 24 Jan 2017 22:54:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HLCi9H8LGLCB for ; Tue, 24 Jan 2017 22:54:20 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7A791297C3 for ; Tue, 24 Jan 2017 22:54:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=44076; q=dns/txt; s=iport; t=1485327259; x=1486536859; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=YxHEUpzztuHqKbxuBRXqLYmiqv8y6raUblBQYOpLe5A=; b=dukxvWvAzZPf6JB+tuIg+zkD+A8rN51B3OSZ7fWLNtOfovVv77pPVQQA VnZAe0kWSPHLmzlMunKfAE5SG5nEEhzITJqqk2xqoMvXNFl28Xm96Ef5W GdiCixEViS7VI8hnOuhJoJGlVCzX7LrjC/jeEemFYCbFnrpXKsPSQoC/t I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DFAQBcS4hY/5NdJa1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBBwEBAQEBgm85DQEBAQEBH2CBCQeDTYoIkWgfiAaLGYIPgg2GIgIaggk/GAE?= =?us-ascii?q?CAQEBAQEBAWIohGkBAQEEI1QSAgEIDgMEAQEOEwECBAMCAgIfERQJCAEBBAESG?= =?us-ascii?q?4hmAxiuHIIlK4cTDYMXAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYhQCIJiglGBWwE?= =?us-ascii?q?BUYJQLoIxBYkJkg04AYk4hC2EC4F3gVmDNoloiCKCAIRChBQBHziBSBU7EAGEK?= =?us-ascii?q?xwZgUhzhUuBIYENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,282,1477958400"; d="scan'208,217";a="376809624" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2017 06:54:06 +0000 Received: from XCH-RTP-003.cisco.com (xch-rtp-003.cisco.com [64.101.220.143]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0P6s5ev003146 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 06:54:06 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-003.cisco.com (64.101.220.143) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 01:54:05 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1210.000; Wed, 25 Jan 2017 01:54:05 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Mehmet Ersue , "'Netconf'" Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAFqYGyA Date: Wed, 25 Jan 2017 06:54:05 +0000 Message-ID: <118F8063-E90B-4292-827C-D88E1A067E95@cisco.com> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> In-Reply-To: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.116.231] Content-Type: multipart/alternative; boundary="_000_118F8063E90B4292827CD88E1A067E95ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 06:54:22 -0000 --_000_118F8063E90B4292827CD88E1A067E95ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGVsbG8sDQoNCkkgc3VwcG9ydCB0aGUgcHJvcG9zZWQgY2hhcnRlciBjaGFuZ2UgKEEpDQpJIGFs c28gc3VwcG9ydCAoQikuIEkgdGhpbmsgaXQgaXMgaW1wb3J0YW50IHRvIHByb3ZpZGUgY2xlYXIg Z3VpZGFuY2Ugd2l0aCByZXNwZWN0IHRvIHdoYXQgc29sdXRpb24gc2hvdWxkIGJlIHByZWZlcnJl ZCBpbiBuZXcgaW1wbGVtZW50YXRpb25zLiBJIHRoaW5rIHRoYXQgb2Jzb2xldGluZyA1Mjc3IGFj aGlldmVzIHRoaXMuDQoNClRoYW5rcywNCg0KQWxiZXJ0bw0KDQoNCk9uIDEvMTcvMTcsIDM6MDYg UE0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBNZWhtZXQgRXJzdWUiIDxuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc8bWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIG1l cnN1ZUBnbWFpbC5jb208bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20+PiB3cm90ZToNCg0KRGVhciBO RVRDT05GIFdHLA0KDQpsb29raW5nIGF0IHRoZSBmZWVkYmFjayBvbiB0aGUgdGhyZWUgb3B0aW9u cyBFcmljIFZvaXQgc3VtbWFyaXplZCBpbiBoaXMgbWFpbCBiZWxvdyBidXQgYWxzbyByZWxhdGVk IGRpc2N1c3Npb24gb24gdGhpcyB0b3BpYywgTkVUQ09ORiBjby1jaGFpcnMgY2FtZSB0byB0aGUg Y29uY2x1c2lvbiB0aGF0IG9wdGlvbiAoaWlpKSBmb3IgdXBkYXRpbmcvZW5oYW5jaW5nIFJGQzUy NzcgZGlkIG5vdCBnZXQgYW55IHByb3BvbmVudHMuIE9uIHRoZSBvdGhlciBoYW5kIHdlIHNlZSBh IGh1Z2Ugc3VwcG9ydCBhbmQgYXR0cmFjdGlvbiBmb3IgdGhlIG5ldyBub3RpZmljYXRpb24vc3Vi c2NyaXB0aW9uIGNhcGFiaWxpdGllcyBhbmQgZXh0ZW5zaW9ucyBkaXNjdXNzZWQgYW5kIHByb3Zp ZGVkIGJ5IHRoZSBTdWJzY3JpcHRpb25zIGFuZCBFdmVudHMgdGVhbS4NCg0KV2UgdGhpbmsgdGhh dCB0aGUgYWRkaXRpb24gb2YgbmV3IG5vdGlmaWNhdGlvbiBjYXBhYmlsaXRpZXMgaW4gY29uY2Vy dCB3aXRoIHRoZSBkcmFmdHMgZnJvbSB0aGUgU3Vic2NyaXB0aW9ucyBhbmQgRXZlbnRzIHRlYW0g cHJvdmlkZSByaWNoIGZlYXR1cmVzIHRoYXQgaW1wbGVtZW50YXRpb25zIHdpbGwgd2FudCB0byBz dXBwb3J0IGluIHRoZSBmdXR1cmUuIFRoZSBrZXkgZmVhdHVyZXMgaW4gcHJlcGFyYXRpb24gYXJl IHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UsIG11bHRpcGxlIGR5bmFtaWMgYW5kL29yIGNvbmZpZ3Vy ZWQgc3Vic2NyaXB0aW9ucyBpbiBhIHRyYW5zcG9ydCBzZXNzaW9uLg0KDQpUaGUgZG9jdW1lbnRz IHRoZSBTdWJzY3JpcHRpb25zIGFuZCBFdmVudHMgdGVhbSBhcmUgY3VycmVudGx5IHdvcmtpbmcg b24gYXJlOg0KLSBBIGRvY3VtZW50IHdoaWNoIGRlZmluZXMgdGhlIHByb3RvY29sLW5ldXRyYWwg bm90aWZpY2F0aW9uIGZyYW1ld29yaywgaS5lLiwgZXhwbGFpbnMgdGhlIGNvbmNlcHRzIG9mIHN1 YnNjcmlwdGlvbnMsIGZpbHRlcnMsIGNvbnRyb2wgcGxhbmUgbm90aWZpY2F0aW9ucywgcmVwbGF5 LCBldGMuICBBbmQgYWxzbyBkZWZpbmVzIHRoZSBhc3NvY2lhdGVkIFlBTkcgZGF0YSBtb2RlbCwg UlBDcywgZXRjLiBUaGlzIGlzIGN1cnJlbnRseSBjb3ZlcmVkIGluIDUyNzdiaXMgZG9jdW1lbnQg d2hpY2ggd291bGQgbmVlZCB0byBiZSByZW5hbWVkLg0KLSBBIGRvY3VtZW50IHdoaWNoIGRlZmlu ZXMgaG93IG5vdGlmaWNhdGlvbnMgYXJlIHNlbnQgb3ZlciBORVRDT05GIChnZW5lcmFsaXppbmcg c2VjdGlvbiAzLjcgb2YgUkZDIDUyNzcpIGFuZCBob3cgWUFORyBub3RpZmljYXRpb25zIGFyZSBl bmNvZGVkIGluIFhNTCBhbmQgSlNPTiAoZHJhZnQtaWV0Zi1uZXRjb25mLW5ldGNvbmYtZXZlbnQt bm90aWZpY2F0aW9ucyksDQotIEEgZG9jdW1lbnQgd2hpY2ggZGVmaW5lcyBob3cgbm90aWZpY2F0 aW9ucyBhcmUgc2VudCBvdmVyIFJFU1RDT05GIChnZW5lcmFsaXppbmcgc2VjdGlvbiA2IG9mIFJF U1RDT05GIFJGQykgYW5kIEhUVFAyLiAgQWxzbyBkZWZpbmVzIGhvdyBZQU5HIG5vdGlmaWNhdGlv bnMgYXJlIGVuY29kZWQgaW4gWE1MIGFuZCBKU09OIChkcmFmdC1pZXRmLW5ldGNvbmYtcmVzdGNv bmYtbm90aWYpLA0KLSBBIGRvY3VtZW50IHdoaWNoIGRlZmluZXMgdGhlIHN1YnNjcmlwdGlvbiBh bmQgcHVzaCBtZWNoYW5pc20gZm9yIFlBTkcgZGF0YXN0b3JlcyBhbGxvd2luZyBzdWJzY3JpYmVy IGFwcGxpY2F0aW9ucyB0byByZXF1ZXN0IHVwZGF0ZXMgZnJvbSBhIFlBTkcgZGF0YXN0b3JlIChk cmFmdC1pZXRmLW5ldGNvbmYteWFuZy1wdXNoKS4NCg0KQSkgTkVUQ09ORiBjby1jaGFpcnMgdGhp bmsgdGhhdCB0aGUgU3Vic2NyaXB0aW9ucyBhbmQgRXZlbnRzIHRlYW0gc2hvdWxkIGNvbnRpbnVl IGl0cyB2YWx1YWJsZSB3b3JrIGFuZCBwcm9wb3NlIHRvIGNoYW5nZSBvdXIgY3VycmVudCBjaGFy dGVyIHRvIGFkZCB0aGUgZGV2ZWxvcG1lbnQgb2Ygbm90aWZpY2F0aW9ucyBhbmQgc3Vic2NyaXB0 aW9uIGNhcGFiaWxpdGllcyB3aXRoIHRoZSBsaXN0ZWQgZG9jdW1lbnRzIGFuZCBmb2N1cyBhYm92 ZSBhcyBhIHN0YXJ0aW5nIHBvaW50LiBXRyBtZW1iZXJzIGFyZSBhc2tlZCB0byBzdGF0ZSB0aGVp ciBvcGluaW9uIG9uIHRoZSBwcm9wb3NlZCBwbGFuLg0KUGxlYXNlIGxldCB1cyBrbm93IG9uIE5F VENPTkYgbWFpbGxpc3QgYnkgSmFudWFyeSAyNywgMjAxNyBFT0IgUFQsIGlmIHlvdSBoYXZlIGEg c3Ryb25nIG9iamVjdGlvbiB0byB0aGlzIHBsYW4gYW5kIGV4cGxhaW4geW91ciBjb25jZXJuIHdp dGggdmFsaWQgYXJndW1lbnRzLiBQbGVhc2UgYWxzbyBzdGF0ZSBjbGVhcmx5IGlmIHlvdSBzdXBw b3J0IHRoaXMgcGxhbi4NCg0KQikgTkVUQ09ORiBjby1jaGFpcnMgZnVydGhlciBwcm9wb3NlIHRo YXQgTkVUQ09ORiBXRyBzaG91bGQgdXNlIGl0cyBlbmVyZ3kgaW4gdGhlIGZ1dHVyZSB0byBjb21w bGV0ZSBhbmQgaW1wcm92ZSB0aGUgbmV3IG5vdGlmaWNhdGlvbiBhbmQgc3Vic2NyaXB0aW9uIFJG Q3MgYW5kIHN0b3AgbWFpbnRhaW5pbmcgUkZDIDUyNzcgZm9yIGlzc3VlcyBvdGhlciB0aGFuIGVy cmF0YS4gIE5vdGUgdGhhdCBpdCBpcyByZXF1aXJlZCB0aGF0IFJGQyA1Mjc3IGFuZCBhbGwgbmV3 IHdvcmsgbmVlZHMgdG8gZ3JhY2VmdWxseSBjby1leGlzdCBpbiBhbnkgZGVwbG95bWVudC4NClBs ZWFzZSBzdGF0ZSB5b3VyIG9waW5pb24gb24gdGhlIG1haWxsaXN0IGJ5IEphbnVhcnkgMjcsIDIw MTcgRU9CIFBULCB3aGV0aGVyIHlvdSB0aGluayBSRkMgNTI3NyBzaG91bGQgYmUgb2Jzb2xldGVk IGR1cmluZyB0aGUgcHVibGljYXRpb24gb2YgdGhlIG5ldyBkcmFmdCBzZXQgb3Igbm90Lg0KDQpN YW55IFRoYW5rcyBpbiBhZHZhbmNlIGZvciB5b3VyIHZhbHVhYmxlIGNvbW1lbnRzLg0KDQpNZWht ZXQgJiBNYWhlc2gNCg0KRnJvbTogRXJpYyBWb2l0IChldm9pdCkgW21haWx0bzpldm9pdEBjaXNj by5jb21dDQpTZW50OiBUdWVzZGF5LCBEZWNlbWJlciAyMCwgMjAxNiA0OjMzIFBNDQpUbzogbmV0 Y29uZkBpZXRmLm9yZzsgbmV0Y29uZi1jaGFpcnNAaWV0Zi5vcmcNClN1YmplY3Q6IDMgT3B0aW9u cyBmb3IgU3Vic2NyaXB0aW9uICYgRXZlbnQgTm90aWZpY2F0aW9uIGRyYWZ0IHN0cnVjdHVyZQ0K DQoNClRvIHN1bW1hcml6ZSBwcmV2aW91cyB0aHJlYWRzLCBrZXkgYmVuZWZpdHMgb2YgNTI3N2Jp cyBvdmVyIFJGQyA1Mjc3IGluY2x1ZGU6DQoNCiAgKDEpIHRyYW5zcG9ydCBpbmRlcGVuZGVuY2UN Cg0KICAoMikgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zDQoNCiAgKDMpIG1hbnkgc3Vic2NyaXB0 aW9ucyBwZXIgdHJhbnNwb3J0IHNlc3Npb24NCg0KICAoNCkgbW9kaWZ5IGFuZCBkZWxldGUgc3Vi c2NyaXB0aW9uIFJQQ3MNCg0KICAoNSkgY29udHJvbCBwbGFuZSBub3RpZmljYXRpb25zDQoNCiAg KDYpIGRhdGEgcGxhbmUgbm90aWZpY2F0aW9uIGluY2x1ZGluZyBzdWJzY3JpcHRpb24taWQNCg0K ICAoNykgbmVnb3RpYXRpb24gKHNlZSBZdmVz4oCZIHRocmVhZCBmcm9tIHllc3RlcmRheSkNCg0K ICAoOCkgY29udHJvbCBwbGFuZSByZXVzZSB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5nLXB1 c2guDQoNCg0KDQpUaG9zZSBvZiB1cyB3b3JraW5nIDUyNzdiaXMgaGFkIGJlZW4gcGxhbm5pbmcg b24gc3VwcG9ydGluZyBleGlzdGluZyA1Mjc3IGltcGxlbWVudGF0aW9ucyB2aWEgYSBzZXBhcmF0 ZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBzZWN0aW9uLiAgQnV0IGFzIHdlIGhhdmUgZ29uZSBm b3J3YXJkLCB3ZSBzZWUgbm8gbWVhbmluZ2Z1bCB0ZWNobmljYWwgb3ZlcmxhcHMuICBJLmUuLCB0 aGVyZSBhcmUgbm8gUlBDIG9yIG5vdGlmaWNhdGlvbnMgc2hhcmVkIGJldHdlZW4gdGhlIDUyNzcg YW5kIDUyNzdiaXMgc29sdXRpb25zLiAgQW55IGNvbXBhdGliaWxpdHkgbW9kZSBzZWN0aW9uIHdv dWxkIGJlIGZ1bGx5IHN0YW5kYWxvbmUuICBDb25zaWRlcmluZyB0aGF0IHBlb3BsZSBjYW4ganVz dCByZWZlciB0byA1Mjc3IGlmIHRoZXkgbmVlZCBpdCwgYW5kIGNvbnNpZGVyaW5nIDUyNzcgJiA1 Mjc3YmlzIGNvdWxkIGVhc2lseSBydW4gaW4gcGFyYWxsZWwgb24gZGlmZmVyZW50IHRyYW5zcG9y dCBzZXNzaW9ucywgYnVpbGRpbmcgYSBzdGFuZGFsb25lIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5 IHNlY3Rpb24gc2VlbXMgYm90aCBjb25mdXNpbmcgYW5kIHJlZHVuZGFudC4NCg0KDQoNClRoaXMg bGVhdmVzIHRocmVlIG9wdGlvbnM6DQoNCiAgKGkuKSBPQlNPTEVURSA1Mjc3IGJ5IHJlcGxhY2lu ZyBpdCB3aXRoIDUyNzdiaXMNCg0KICAoaWkuKSBTdXBwb3J0IDUyNzdiaXMgd2l0aG91dCBPYnNv bGV0aW5nIDUyNzcNCg0KICAoaWlpLikgV3JpdGUgYSBuZXcgVVBEQVRFIGRyYWZ0IGZvciA1Mjc3 IE5FVENPTkYgb25seSB0cmFuc3BvcnQNCg0KDQoNClRoZSBiZW5lZml0cyBhbmQgaXNzdWVzIG9m IGVhY2ggYXJlIGFzIGZvbGxvd3M6DQoNCg0KDQooaS4pIE9CU09MRVRFIDUyNzcgYnkgcmVwbGFj aW5nIGl0IHdpdGggNTI3N2Jpcw0KDQogICogICBTdXBwb3J0cyBhbGwgcmVxdWlyZW1lbnRzICgx KSB0aHJvdWdoICg4KS4NCiAgKiAgIElFVEYgZG9lcyBub3QgY29udGludWUgcHJvdG9jb2wgbWFp bnRlbmFuY2Ugb2YgNTI3Ny4NCg0KICAgICAqICAgSW1wbGVtZW50YXRpb25zIGNhbiBzdGlsbCBj aG9vc2UgNTI3NyBvciA1Mjc3YmlzLCBldmVuIHRob3VnaCBJRVRGIHJlY29tbWVuZHMgNTI3N2Jp cy4NCiAgICAgKiAgIEltcGxlbWVudGF0aW9ucyBwcm92aWRlIGJhY2t3YXJkcyBjb21wYXRpYmls aXR5IHRocm91Z2ggY29uY3VycmVudCwgcGFyYWxsZWwgc3VwcG9ydCBvZiBib3RoIHNwZWNpZmlj YXRpb25zLg0KICAgICAqICAgQWx0aG91Z2ggb2Jzb2xldGVkLCB0aGUgSUVURiBkb2VzIG5vdCBk ZXByZWNhdGUgNTI3NyBzbyB0aGF0IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG1heSBzdGF5IHdp dGggZXhpc3RpbmcgNTI3Ny4NCg0KICAqICAgTmVlZCB0byBjaGFuZ2UgdGhlIE5FVENPTkYgV0cg Y2hhcnRlciB0byBzaG93IHRoYXQgNTI3NyBpcyBiZWluZyByZXBsYWNlZCByYXRoZXIgdGhhbiBl bmhhbmNlZC4NCg0KDQoNCihpaS4pIFN1cHBvcnQgNTI3N2JpcyB3aXRob3V0IE9ic29sZXRpbmcg NTI3Nw0KDQogICogICBUZWNobmljYWxseSBpZGVudGljYWwgdG8gKGkpLg0KICAqICAgSW1wbGVt ZW50YXRpb25zIGZyZWUgdG8gY2hvb3NlIDUyNzcgb3IgNTI3N2Jpcywgd2l0aCBubyBndWlkYW5j ZSBvbiB3aGljaCB0aGUgV0cgcmVjb21tZW5kcy4NCg0KICAgICAqICAgVGhpcyBjb3VsZCBiZSBj b25mdXNpbmcgdG8gY3VzdG9tZXJzIGFzIE5FVENPTkYgV0cgd2lsbCBiZSBhZHZvY2F0aW5nIGNv bXBldGluZyB0ZWNobm9sb2dpZXMgZm9yIHRoZSBwbGFjZSBvZiBvdmVybGFwLiAgLS0gaS5lLiwg TkVUQ09ORiBvdmVyIFhNTCB3aXRoIGEgc2luZ2xlIHN1YnNjcmlwdGlvbi4NCg0KICAqICAgRXN0 YWJsaXNoZXMgY29tcGV0aW5nIHRlY2hub2xvZ3kgZnV0dXJlcyB3aGVyZSBvbmUgZGlyZWN0aW9u IHdvdWxkIHN1ZmZpY2UuDQoNCg0KDQooaWlpLikgV3JpdGUgYSBuZXcgVVBEQVRFIGRyYWZ0IGZv ciA1Mjc3IE5FVENPTkYgb25seSB0cmFuc3BvcnQNCg0KICAqICAgU3VwcG9ydHMgYSBzdWJzZXQg b2YgcmVxdWlyZW1lbnRzOg0KDQogICAgICogICBDYW5ub3Qgc3VwcG9ydCAoMSkgb3IgKDgpDQog ICAgICogICBTdXBwb3J0aW5nICgyKSwgKDMpLCAoNCksICg1KSwgKDYpLCAmICg3KSBwb3NzaWJs ZSwgYnV0IHdvdWxkIHJlcXVpcmUgdGhlIGNyZWF0aW9uIG9mIHJlcGxpY2F0ZWQvY29tcGV0aW5n IG1lY2hhbmlzbXMgd2l0aCAoOCkuDQoNCiAgKiAgIERvdWJsZXMgdGhlIGRldmVsb3BtZW50IGVm Zm9ydCBpZiB0aGUgeWFuZy1wdXNoIGNvbnRyb2wgcGxhbmUgaXMgYWxzbyByZXF1aXJlZC4NCiAg KiAgIFdHIHdvdWxkIG5lZWQgdG8gYnVpbGQgZ3VpZGVsaW5lcyBvbiB3aGVuIHRvIHVzZSA1Mjc3 YmlzIG9yIHRoaXMgbmV3IFVQREFURSBkcmFmdCAoYXNzdW1pbmcgdGhlIFdHIHdhbnRlZCB0byBw cm9jZWVkIHdpdGggdGhlIHRyYW5zcG9ydCBpbmRlcGVuZGVudCA1Mjc3YmlzLikNCiAgKiAgIE5v IGlkZW50aWZpZWQgYXV0aG9yIC8gY2hhbXBpb24gZm9yIHRoaXMgcGF0aC4gIChCZWNhdXNlIGJ1 c2luZXNzIGRyaXZlcnMgYmVpbmcgZHJpdmVuIGJ5IG90aGVyIHRoYW4gTkVUQ09ORi9YTUwuKQ0K ICAqICAgVXBkYXRlIGRyYWZ0IGl0c2VsZiB3b3VsZG7igJl0IHJlcXVpcmUgYSBORVRDT05GIGNo YXJ0ZXIgdXBkYXRlLg0KDQoNCkJhc2VkIG9uIHRoaXMgbGlzdCwgdGhlIHBlb3BsZSB3b3JraW5n IGluIG9uIHRoZSBTdWJzY3JpcHRpb24gJiBFdmVudCBOb3RpZmljYXRpb24gd2Vla2x5IGNhbGxz IGhhdmUgYSBwcmVmZXJlbmNlIGZvciAoaS4pIGZvbGxvd2VkIGJ5IChpaS4pLiAgRG8geW91IGhh dmUgYSBwcmVmZXJlbmNlIG9yIGFkZGl0aW9uYWwgcXVlc3Rpb25zIG5vdCBhZGRyZXNzZWQgaGVy ZSBvciBpbiB0aGUgZWFybGllciB0aHJlYWRzPw0KDQoNCg0KVGhhbmtzLA0KDQpFcmljDQoNCg== --_000_118F8063E90B4292827CD88E1A067E95ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <8727EDCF681CBF4D92B82A3A502B748D@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6V2luZ2RpbmdzOw0K CXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls eToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBmb250 LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAz IDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1h bCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsN Cglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjNDMTsN Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxp bmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFpblRl eHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHls ZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFu LlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQgQ2hhciI7DQoJbXNv LXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IjsNCglmb250 LWZhbWlseTpDYWxpYnJpO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25v cm1hbDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDph dXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJ bWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVz IE5ldyBSb21hbiI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1h aWxTdHlsZTIxDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkNhbGli cmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLkVtYWlsU3R5bGUyMg0KCXttc28tc3R5bGUt dHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOiMwMDAwQ0M7fQ0K c3Bhbi5FbWFpbFN0eWxlMjMNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1p bHk6Q2FsaWJyaTsNCgljb2xvcjojMDAwMENDO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6 d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsN Cgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9y OnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJ Zm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4w aW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjEN Cgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLyogTGlzdCBEZWZpbml0aW9ucyAqLw0KQGxpc3QgbDAN Cgl7bXNvLWxpc3QtaWQ6NTgyNTczNDA4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlkczotNTc0NTc3 NzcwO30NCkBsaXN0IGwwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDA6bGV2 ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpv Ow0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZhbWlseToiVGlt ZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMDpsZXZlbDMNCgl7bXNvLWxldmVsLW51bWJlci1mb3Jt YXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS41 aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpA bGlzdCBsMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250 LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDUNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1m b250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDgN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsMQ0KCXttc28tbGlzdC1pZDo3NDE2MzUyNTk7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi03Mzg5MjgxMzI7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsMTpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGwxOmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0 IGwxOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1s ZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBs aXN0IGwxOmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOQ0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1z by1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwyDQoJe21zby1saXN0LWlkOjc2MjM4MDc1NDsNCglt c28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTI4NTAzMTM4MiA2 NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5ODY4OSA2NzY5ODY5MSA2NzY5ODY5MyA2NzY5 ODY4OSA2NzY5ODY5MSA2NzY5ODY5Mzt9DQpAbGlzdCBsMjpsZXZlbDENCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRl bnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMjpsZXZlbDINCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxl dmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRl eHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCkBsaXN0IGwy OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGwyOmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZl bC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1p bHk6U3ltYm9sO30NCkBsaXN0IGwyOmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCglt c28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZv bnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDI6bGV2ZWw2DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDI6bGV2ZWw3DQoJ e21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJ bXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDI6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpAbGlzdCBsMjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFt aWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1pZDoxMDAxNjY2OTQ5Ow0KCW1z by1saXN0LXRlbXBsYXRlLWlkczotMTE1NjY3NDIxODt9DQpAbGlzdCBsMzpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGwzOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7 DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDM6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv grc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw0DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6 bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw3DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpTeW1ib2w7fQ0KQGxpc3QgbDM6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3Qg bDM6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQNCgl7bXNvLWxpc3QtaWQ6 MTA3MTM4NTIwMzsNCgltc28tbGlzdC10eXBlOmh5YnJpZDsNCgltc28tbGlzdC10ZW1wbGF0ZS1p ZHM6NTg2NTc5MjE0IDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4Njkx IDY3Njk4NjkzIDY3Njk4Njg5IDY3Njk4NjkxIDY3Njk4NjkzO30NCkBsaXN0IGw0OmxldmVsMQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0K CW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVm dDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw0 OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5l dyI7fQ0KQGxpc3QgbDQ6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDQ6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5v bmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVp bjsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWw1DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWIt c3RvcDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVu dDotLjI1aW47DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsNDpsZXZlbDYN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsNDpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJv bDt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVs LW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWls eToiQ291cmllciBOZXciO30NCkBsaXN0IGw0OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpu b25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1ib3R0b206MGluO30N CnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBi Z2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIjOTU0Rjcy Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5IZWxs byw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBzdXBwb3J0IHRoZSBwcm9wb3NlZCBjaGFydGVy IGNoYW5nZSAoQSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkkgYWxzbyBz dXBwb3J0IChCKS4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8gcHJvdmlkZSBjbGVhciBndWlk YW5jZSB3aXRoIHJlc3BlY3QgdG8gd2hhdCBzb2x1dGlvbiBzaG91bGQgYmUgcHJlZmVycmVkIGlu IG5ldyBpbXBsZW1lbnRhdGlvbnMuIEkgdGhpbmsgdGhhdCBvYnNvbGV0aW5nIDUyNzcgYWNoaWV2 ZXMgdGhpcy48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhhbmtzLDxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5BbGJlcnRvPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNC NUM0REYgNC41cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdDttYXJnaW4tbGVmdDozLjc1cHQ7 bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9u IDEvMTcvMTcsIDM6MDYgUE0sICZxdW90O05ldGNvbmYgb24gYmVoYWxmIG9mIE1laG1ldCBFcnN1 ZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0 Y29uZi1ib3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzpt ZXJzdWVAZ21haWwuY29tIj5tZXJzdWVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5E ZWFyIE5FVENPTkYgV0csPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5sb29r aW5nIGF0IHRoZSBmZWVkYmFjayBvbiB0aGUgdGhyZWUgb3B0aW9ucyBFcmljIFZvaXQgc3VtbWFy aXplZCBpbiBoaXMgbWFpbCBiZWxvdyBidXQgYWxzbyByZWxhdGVkIGRpc2N1c3Npb24gb24gdGhp cyB0b3BpYywgTkVUQ09ORiBjby1jaGFpcnMgY2FtZSB0byB0aGUgY29uY2x1c2lvbiB0aGF0IG9w dGlvbiAoaWlpKSBmb3IgdXBkYXRpbmcvZW5oYW5jaW5nDQogUkZDNTI3NyBkaWQgbm90IGdldCBh bnkgcHJvcG9uZW50cy4gT24gdGhlIG90aGVyIGhhbmQgd2Ugc2VlIGEgaHVnZSBzdXBwb3J0IGFu ZCBhdHRyYWN0aW9uIGZvciB0aGUgbmV3IG5vdGlmaWNhdGlvbi9zdWJzY3JpcHRpb24gY2FwYWJp bGl0aWVzIGFuZCBleHRlbnNpb25zIGRpc2N1c3NlZCBhbmQgcHJvdmlkZWQgYnkgdGhlIFN1YnNj cmlwdGlvbnMgYW5kIEV2ZW50cyB0ZWFtLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj4mbmJzcDs8L3NwYW4+PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAw MDBDQyI+V2UgdGhpbmsgdGhhdCB0aGUgYWRkaXRpb24gb2YgbmV3IG5vdGlmaWNhdGlvbiBjYXBh YmlsaXRpZXMgaW4gY29uY2VydCB3aXRoIHRoZSBkcmFmdHMgZnJvbSB0aGUgU3Vic2NyaXB0aW9u cyBhbmQgRXZlbnRzIHRlYW0gcHJvdmlkZSByaWNoIGZlYXR1cmVzIHRoYXQgaW1wbGVtZW50YXRp b25zIHdpbGwgd2FudCB0byBzdXBwb3J0IGluIHRoZSBmdXR1cmUuIFRoZQ0KIGtleSBmZWF0dXJl cyBpbiBwcmVwYXJhdGlvbiBhcmUgdHJhbnNwb3J0IGluZGVwZW5kZW5jZSwgbXVsdGlwbGUgZHlu YW1pYyBhbmQvb3IgY29uZmlndXJlZCBzdWJzY3JpcHRpb25zIGluIGEgdHJhbnNwb3J0IHNlc3Np b24uICZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDAwQ0MiPlRoZSBkb2N1bWVudHMgdGhlIFN1YnNjcmlwdGlvbnMgYW5kIEV2ZW50cyB0ZWFt IGFyZSBjdXJyZW50bHkgd29ya2luZyBvbiBhcmU6PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPi0gQSBkb2N1bWVu dCB3aGljaCBkZWZpbmVzIHRoZSBwcm90b2NvbC1uZXV0cmFsIG5vdGlmaWNhdGlvbiBmcmFtZXdv cmssIGkuZS4sIGV4cGxhaW5zIHRoZSBjb25jZXB0cyBvZiBzdWJzY3JpcHRpb25zLCBmaWx0ZXJz LCBjb250cm9sIHBsYW5lIG5vdGlmaWNhdGlvbnMsIHJlcGxheSwgZXRjLiAmbmJzcDtBbmQgYWxz byBkZWZpbmVzIHRoZSBhc3NvY2lhdGVkIFlBTkcgZGF0YQ0KIG1vZGVsLCBSUENzLCBldGMuIFRo aXMgaXMgY3VycmVudGx5IGNvdmVyZWQgaW4gNTI3N2JpcyBkb2N1bWVudCB3aGljaCB3b3VsZCBu ZWVkIHRvIGJlIHJlbmFtZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPi0gQSBkb2N1bWVudCB3aGljaCBkZWZp bmVzIGhvdyBub3RpZmljYXRpb25zIGFyZSBzZW50IG92ZXIgTkVUQ09ORiAoZ2VuZXJhbGl6aW5n IHNlY3Rpb24gMy43IG9mIFJGQyA1Mjc3KSBhbmQgaG93IFlBTkcgbm90aWZpY2F0aW9ucyBhcmUg ZW5jb2RlZCBpbiBYTUwgYW5kIEpTT04gKGRyYWZ0LWlldGYtbmV0Y29uZi1uZXRjb25mLWV2ZW50 LW5vdGlmaWNhdGlvbnMpLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj4tIEEgZG9jdW1lbnQgd2hpY2ggZGVmaW5l cyBob3cgbm90aWZpY2F0aW9ucyBhcmUgc2VudCBvdmVyIFJFU1RDT05GIChnZW5lcmFsaXppbmcg c2VjdGlvbiA2IG9mIFJFU1RDT05GIFJGQykgYW5kIEhUVFAyLiZuYnNwOyBBbHNvIGRlZmluZXMg aG93IFlBTkcgbm90aWZpY2F0aW9ucyBhcmUgZW5jb2RlZCBpbiBYTUwgYW5kIEpTT04gKGRyYWZ0 LWlldGYtbmV0Y29uZi1yZXN0Y29uZi1ub3RpZiksPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPi0gQSBkb2N1bWVu dCB3aGljaCBkZWZpbmVzIHRoZSBzdWJzY3JpcHRpb24gYW5kIHB1c2ggbWVjaGFuaXNtIGZvciBZ QU5HIGRhdGFzdG9yZXMgYWxsb3dpbmcgc3Vic2NyaWJlciBhcHBsaWNhdGlvbnMgdG8gcmVxdWVz dCB1cGRhdGVzIGZyb20gYSBZQU5HIGRhdGFzdG9yZSAoZHJhZnQtaWV0Zi1uZXRjb25mLXlhbmct cHVzaCkuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImNvbG9yOiMwMDAwQ0MiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5BKSBORVRDT05GIGNv LWNoYWlycyB0aGluayB0aGF0IHRoZSBTdWJzY3JpcHRpb25zIGFuZCBFdmVudHMgdGVhbSBzaG91 bGQgY29udGludWUgaXRzIHZhbHVhYmxlIHdvcmsgYW5kIHByb3Bvc2UgdG8gY2hhbmdlIG91ciBj dXJyZW50IGNoYXJ0ZXIgdG8gYWRkIHRoZSBkZXZlbG9wbWVudCBvZiBub3RpZmljYXRpb25zIGFu ZCBzdWJzY3JpcHRpb24gY2FwYWJpbGl0aWVzDQogd2l0aCB0aGUgbGlzdGVkIGRvY3VtZW50cyBh bmQgZm9jdXMgYWJvdmUgYXMgYSBzdGFydGluZyBwb2ludC4gV0cgbWVtYmVycyBhcmUgYXNrZWQg dG8gc3RhdGUgdGhlaXIgb3BpbmlvbiBvbiB0aGUgcHJvcG9zZWQgcGxhbi4NCjwvc3Bhbj48bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAw MENDIj5QbGVhc2UgbGV0IHVzIGtub3cgb24gTkVUQ09ORiBtYWlsbGlzdCBieSBKYW51YXJ5IDI3 LCAyMDE3IEVPQiBQVCwgaWYgeW91IGhhdmUgYSBzdHJvbmcgb2JqZWN0aW9uIHRvIHRoaXMgcGxh biBhbmQgZXhwbGFpbiB5b3VyIGNvbmNlcm4gd2l0aCB2YWxpZCBhcmd1bWVudHMuIFBsZWFzZSBh bHNvIHN0YXRlIGNsZWFybHkgaWYgeW91IHN1cHBvcnQgdGhpcyBwbGFuLjwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMEND Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iY29sb3I6IzAwMDBDQyI+QikgTkVUQ09ORiBjby1jaGFpcnMgZnVydGhlciBwcm9w b3NlIHRoYXQgTkVUQ09ORiBXRyBzaG91bGQgdXNlIGl0cyBlbmVyZ3kgaW4gdGhlIGZ1dHVyZSB0 byBjb21wbGV0ZSBhbmQgaW1wcm92ZSB0aGUgbmV3IG5vdGlmaWNhdGlvbiBhbmQgc3Vic2NyaXB0 aW9uIFJGQ3MgYW5kIHN0b3AgbWFpbnRhaW5pbmcgUkZDIDUyNzcgZm9yIGlzc3VlcyBvdGhlciB0 aGFuDQogZXJyYXRhLiZuYnNwOyBOb3RlIHRoYXQgaXQgaXMgcmVxdWlyZWQgdGhhdCBSRkMgNTI3 NyBhbmQgYWxsIG5ldyB3b3JrIG5lZWRzIHRvIGdyYWNlZnVsbHkgY28tZXhpc3QgaW4gYW55IGRl cGxveW1lbnQuICZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJjb2xvcjojMDAwMENDIj5QbGVhc2Ugc3RhdGUgeW91ciBvcGluaW9u IG9uIHRoZSBtYWlsbGlzdCBieSBKYW51YXJ5IDI3LCAyMDE3IEVPQiBQVCwgd2hldGhlciB5b3Ug dGhpbmsgUkZDIDUyNzcgc2hvdWxkIGJlIG9ic29sZXRlZCBkdXJpbmcgdGhlIHB1YmxpY2F0aW9u IG9mIHRoZSBuZXcgZHJhZnQgc2V0IG9yIG5vdC48L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFu PjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9y OiMwMDAwQ0MiPk1hbnkgVGhhbmtzIGluIGFkdmFuY2UgZm9yIHlvdXIgdmFsdWFibGUgY29tbWVu dHMuJm5ic3A7DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImNvbG9yOiMwMDAwQ0MiPk1laG1ldCAm YW1wOyBNYWhlc2g8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iY29sb3I6IzAwMDBDQyI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K PGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAx LjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PkZyb206PC9iPiBFcmljIFZvaXQgKGV2b2l0KSBbbWFpbHRvOmV2b2l0QGNpc2NvLmNvbV0gPGJy Pg0KPGI+U2VudDo8L2I+IFR1ZXNkYXksIERlY2VtYmVyIDIwLCAyMDE2IDQ6MzMgUE08YnI+DQo8 Yj5Ubzo8L2I+IG5ldGNvbmZAaWV0Zi5vcmc7IG5ldGNvbmYtY2hhaXJzQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IDMgT3B0aW9ucyBmb3IgU3Vic2NyaXB0aW9uICZhbXA7IEV2ZW50IE5v dGlmaWNhdGlvbiBkcmFmdCBzdHJ1Y3R1cmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPlRvIHN1bW1hcml6ZSBwcmV2aW91cyB0aHJlYWRzLCBrZXkgYmVuZWZpdHMg b2YgNTI3N2JpcyBvdmVyIFJGQyA1Mjc3IGluY2x1ZGU6PG86cD48L286cD48L3A+DQo8cCBjbGFz cz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKDEpIHRyYW5zcG9ydCBpbmRlcGVuZGVuY2U8bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAoMikgY29uZmlndXJlZCBz dWJzY3JpcHRpb25zPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJz cDsgKDMpIG1hbnkgc3Vic2NyaXB0aW9ucyBwZXIgdHJhbnNwb3J0IHNlc3Npb248bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAoNCkgbW9kaWZ5IGFuZCBkZWxl dGUgc3Vic2NyaXB0aW9uIFJQQ3M8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRl eHQiPiZuYnNwOyAoNSkgY29udHJvbCBwbGFuZSBub3RpZmljYXRpb25zPG86cD48L286cD48L3A+ DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKDYpIGRhdGEgcGxhbmUgbm90aWZpY2F0 aW9uIGluY2x1ZGluZyBzdWJzY3JpcHRpb24taWQ8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOyAoNykgbmVnb3RpYXRpb24gKHNlZSBZdmVz4oCZIHRocmVhZCBm cm9tIHllc3RlcmRheSk8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZu YnNwOyAoOCkgY29udHJvbCBwbGFuZSByZXVzZSB3aXRoIGRyYWZ0LWlldGYtbmV0Y29uZi15YW5n LXB1c2guPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRob3NlIG9mIHVzIHdvcmtpbmcg NTI3N2JpcyBoYWQgYmVlbiBwbGFubmluZyBvbiBzdXBwb3J0aW5nIGV4aXN0aW5nIDUyNzcgaW1w bGVtZW50YXRpb25zIHZpYSBhIHNlcGFyYXRlIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHNlY3Rp b24uJm5ic3A7IEJ1dCBhcyB3ZSBoYXZlIGdvbmUgZm9yd2FyZCwgd2Ugc2VlIG5vIG1lYW5pbmdm dWwgdGVjaG5pY2FsIG92ZXJsYXBzLiAmbmJzcDtJLmUuLCB0aGVyZSBhcmUgbm8gUlBDDQogb3Ig bm90aWZpY2F0aW9ucyBzaGFyZWQgYmV0d2VlbiB0aGUgNTI3NyBhbmQgNTI3N2JpcyBzb2x1dGlv bnMuJm5ic3A7IEFueSBjb21wYXRpYmlsaXR5IG1vZGUgc2VjdGlvbiB3b3VsZCBiZSBmdWxseSBz dGFuZGFsb25lLiZuYnNwOyBDb25zaWRlcmluZyB0aGF0IHBlb3BsZSBjYW4ganVzdCByZWZlciB0 byA1Mjc3IGlmIHRoZXkgbmVlZCBpdCwgYW5kIGNvbnNpZGVyaW5nIDUyNzcgJmFtcDsgNTI3N2Jp cyBjb3VsZCBlYXNpbHkgcnVuIGluIHBhcmFsbGVsIG9uIGRpZmZlcmVudA0KIHRyYW5zcG9ydCBz ZXNzaW9ucywgYnVpbGRpbmcgYSBzdGFuZGFsb25lIGJhY2t3YXJkcyBjb21wYXRpYmlsaXR5IHNl Y3Rpb24gc2VlbXMgYm90aCBjb25mdXNpbmcgYW5kIHJlZHVuZGFudC4gJm5ic3A7PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxw IGNsYXNzPSJNc29QbGFpblRleHQiPlRoaXMgbGVhdmVzIHRocmVlIG9wdGlvbnM6PG86cD48L286 cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKGkuKSBPQlNPTEVURSA1Mjc3 IGJ5IHJlcGxhY2luZyBpdCB3aXRoIDUyNzdiaXMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0i TXNvUGxhaW5UZXh0Ij4mbmJzcDsmbmJzcDsoaWkuKSBTdXBwb3J0IDUyNzdiaXMmbmJzcDt3aXRo b3V0IE9ic29sZXRpbmcgNTI3NzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+Jm5ic3A7Jm5ic3A7KGlpaS4pIFdyaXRlIGEgbmV3IFVQREFURSBkcmFmdCBmb3IgNTI3NyBO RVRDT05GIG9ubHkgdHJhbnNwb3J0DQo8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp blRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhl IGJlbmVmaXRzIGFuZCBpc3N1ZXMgb2YgZWFjaCBhcmUgYXMgZm9sbG93czo8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh c3M9Ik1zb1BsYWluVGV4dCI+PHU+KGkuKSBPQlNPTEVURSA1Mjc3IGJ5IHJlcGxhY2luZyBpdCB3 aXRoIDUyNzdiaXMgJm5ic3A7Jm5ic3A7PC91PjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJt YXJnaW4tdG9wOjBpbiIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9 Im1zby1saXN0OmwyIGxldmVsMSBsZm8zIj5TdXBwb3J0cyBhbGwgcmVxdWlyZW1lbnRzICgxKSB0 aHJvdWdoICg4KS48bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsMiBsZXZlbDEgbGZvMyI+SUVURiBkb2VzIG5vdCBjb250aW51ZSBwcm90b2NvbCBt YWludGVuYW5jZSBvZiA1Mjc3Lg0KPG86cD48L286cD48L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1h cmdpbi10b3A6MGluIiB0eXBlPSJkaXNjIj4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5 cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwyIGxl dmVsMiBsZm8zIj5JbXBsZW1lbnRhdGlvbnMgY2FuIHN0aWxsIGNob29zZSA1Mjc3IG9yIDUyNzdi aXMsIGV2ZW4gdGhvdWdoIElFVEYgcmVjb21tZW5kcyA1Mjc3YmlzLjxvOnA+PC9vOnA+PC9saT48 bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0OmwyIGxldmVsMiBsZm8zIj5JbXBs ZW1lbnRhdGlvbnMgcHJvdmlkZSBiYWNrd2FyZHMgY29tcGF0aWJpbGl0eSB0aHJvdWdoIGNvbmN1 cnJlbnQsIHBhcmFsbGVsIHN1cHBvcnQgb2YgYm90aCBzcGVjaWZpY2F0aW9ucy48bzpwPjwvbzpw PjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsMiBsZXZlbDIgbGZv MyI+QWx0aG91Z2ggb2Jzb2xldGVkLCB0aGUgSUVURiBkb2VzIG5vdCBkZXByZWNhdGUgNTI3NyBz byB0aGF0IGN1cnJlbnQgaW1wbGVtZW50YXRpb25zIG1heSBzdGF5IHdpdGggZXhpc3RpbmcgNTI3 Ny48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGlu IiB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDIg bGV2ZWwxIGxmbzMiPk5lZWQgdG8gY2hhbmdlIHRoZSBORVRDT05GIFdHIGNoYXJ0ZXIgdG8gc2hv dyB0aGF0IDUyNzcgaXMgYmVpbmcgcmVwbGFjZWQgcmF0aGVyIHRoYW4gZW5oYW5jZWQuPG86cD48 L286cD48L2xpPjwvdWw+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjx1PihpaS4pIFN1cHBvcnQgNTI3N2JpcyB3 aXRob3V0IE9ic29sZXRpbmcgNTI3NzwvdT48bzpwPjwvbzpwPjwvcD4NCjx1bCBzdHlsZT0ibWFy Z2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+VGVjaG5pY2FsbHkgaWRlbnRpY2FsIHRvIChpKS4NCjxv OnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxl dmVsMSBsZm82Ij5JbXBsZW1lbnRhdGlvbnMgZnJlZSB0byBjaG9vc2UgNTI3NyBvciA1Mjc3Ymlz LCB3aXRoIG5vIGd1aWRhbmNlIG9uIHdoaWNoIHRoZSBXRyByZWNvbW1lbmRzLiZuYnNwOw0KPG86 cD48L286cD48L2xpPjwvdWw+DQo8dWwgc3R5bGU9Im1hcmdpbi10b3A6MGluIiB0eXBlPSJkaXNj Ij4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMiBsZm82Ij5UaGlzIGNvdWxkIGJl IGNvbmZ1c2luZyB0byBjdXN0b21lcnMgYXMgTkVUQ09ORiBXRyB3aWxsIGJlIGFkdm9jYXRpbmcg Y29tcGV0aW5nIHRlY2hub2xvZ2llcyBmb3IgdGhlIHBsYWNlIG9mIG92ZXJsYXAuICZuYnNwOy0t IGkuZS4sIE5FVENPTkYgb3ZlciBYTUwgd2l0aCBhIHNpbmdsZSBzdWJzY3JpcHRpb24uPG86cD48 L286cD48L2xpPjwvdWw+DQo8L3VsPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0i ZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBs Zm82Ij5Fc3RhYmxpc2hlcyBjb21wZXRpbmcgdGVjaG5vbG9neSBmdXR1cmVzIHdoZXJlIG9uZSBk aXJlY3Rpb24gd291bGQgc3VmZmljZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJN c29QbGFpblRleHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4 dCI+PHU+KGlpaS4pIFdyaXRlIGEgbmV3IFVQREFURSBkcmFmdCBmb3IgNTI3NyBORVRDT05GIG9u bHkgdHJhbnNwb3J0PC91PjxvOnA+PC9vOnA+PC9wPg0KPHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBp biIgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1saXN0Omw0 IGxldmVsMSBsZm82Ij5TdXBwb3J0cyBhIHN1YnNldCBvZiByZXF1aXJlbWVudHM6DQo8bzpwPjwv bzpwPjwvbGk+PC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2MiPg0K PHVsIHN0eWxlPSJtYXJnaW4tdG9wOjBpbiIgdHlwZT0iY2lyY2xlIj4NCjxsaSBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwyIGxmbzYiPkNhbm5vdCBzdXBwb3J0ICgx KSBvciAoOCk8bzpwPjwvbzpwPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28t bGlzdDpsNCBsZXZlbDIgbGZvNiI+U3VwcG9ydGluZyAoMiksICgzKSwgKDQpLCAoNSksICg2KSwg JmFtcDsgKDcpIHBvc3NpYmxlLCBidXQgd291bGQgcmVxdWlyZSB0aGUgY3JlYXRpb24gb2YgcmVw bGljYXRlZC9jb21wZXRpbmcgbWVjaGFuaXNtcyB3aXRoICg4KS4mbmJzcDsNCjxvOnA+PC9vOnA+ PC9saT48L3VsPg0KPC91bD4NCjx1bCBzdHlsZT0ibWFyZ2luLXRvcDowaW4iIHR5cGU9ImRpc2Mi Pg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbGlzdDpsNCBsZXZlbDEgbGZvNiI+ RG91YmxlcyB0aGUgZGV2ZWxvcG1lbnQgZWZmb3J0IGlmIHRoZSB5YW5nLXB1c2ggY29udHJvbCBw bGFuZSBpcyBhbHNvIHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1saXN0Omw0IGxldmVsMSBsZm82Ij5XRyB3b3VsZCBuZWVkIHRvIGJ1aWxk IGd1aWRlbGluZXMgb24gd2hlbiB0byB1c2UgNTI3N2JpcyBvciB0aGlzIG5ldyBVUERBVEUgZHJh ZnQgKGFzc3VtaW5nIHRoZSBXRyB3YW50ZWQgdG8gcHJvY2VlZCB3aXRoIHRoZSB0cmFuc3BvcnQg aW5kZXBlbmRlbnQgNTI3N2Jpcy4pPG86cD48L286cD48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFs IiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzYiPk5vIGlkZW50aWZpZWQgYXV0aG9yIC8g Y2hhbXBpb24gZm9yIHRoaXMgcGF0aC4gJm5ic3A7KEJlY2F1c2UgYnVzaW5lc3MgZHJpdmVycyBi ZWluZyBkcml2ZW4gYnkgb3RoZXIgdGhhbiBORVRDT05GL1hNTC4pPG86cD48L286cD48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzYiPlVwZGF0 ZSBkcmFmdCBpdHNlbGYgd291bGRu4oCZdCByZXF1aXJlIGEgTkVUQ09ORiBjaGFydGVyIHVwZGF0 ZS48bzpwPjwvbzpwPjwvbGk+PC91bD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOzxvOnA+ PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QmFzZWQgb24gdGhpcyBsaXN0LCB0 aGUgcGVvcGxlIHdvcmtpbmcgaW4gb24gdGhlIFN1YnNjcmlwdGlvbiAmYW1wOyBFdmVudCBOb3Rp ZmljYXRpb24gd2Vla2x5IGNhbGxzIGhhdmUgYSBwcmVmZXJlbmNlIGZvciAoaS4pIGZvbGxvd2Vk IGJ5IChpaS4pLiZuYnNwOyBEbyB5b3UgaGF2ZSBhIHByZWZlcmVuY2Ugb3IgYWRkaXRpb25hbCBx dWVzdGlvbnMgbm90IGFkZHJlc3NlZCBoZXJlIG9yIGluIHRoZSBlYXJsaWVyIHRocmVhZHM/PG86 cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDs8bzpwPjwvbzpwPjwv cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29QbGFpblRleHQiPkVyaWMgPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPC9ib2R5 Pg0KPC9odG1sPg0K --_000_118F8063E90B4292827CD88E1A067E95ciscocom_-- From nobody Tue Jan 24 22:58:57 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D2A051297C3 for ; Tue, 24 Jan 2017 22:58:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.721 X-Spam-Level: X-Spam-Status: No, score=-17.721 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mcSuwSjnU0ZC for ; Tue, 24 Jan 2017 22:58:55 -0800 (PST) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2A0A1129698 for ; Tue, 24 Jan 2017 22:58:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8434; q=dns/txt; s=iport; t=1485327534; x=1486537134; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=PvDCQ+9wnI00FqLFO9/QEV9AkBG9ZKU2MBc+6G4x1JQ=; b=E+q/J66npq0qBzYEQpJmStGF7Vck70LgsImzvkm0P7blMvEyAbfLWgfk 9bxEDO8PLd6XF7f8g8m2e0szXd45ttGU+NPN+jguH7FNGtL1ZDMWsdqT1 +O7qK5kOEnca79C4KTI9rP5MPQoVM3UNKyXSkzpU9nbmFVErf29eQJ9yr c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BEAQBxS4hY/5ldJa1bAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYM1AQEBAQEfYIEJB4NNigiSB5Uugg0fC4UuSgIaggk/GAECAQE?= =?us-ascii?q?BAQEBAWIohGkBAQEEAQEhEToJAgwCAgIBCBABAwEBAQECAggBFgQDAgICGQwLF?= =?us-ascii?q?AEICAIEAQ0FiRwOrg6CJYpiAQEBAQEBAQEBAQEBAQEBAQEBAQEBHQWBBodFgWG?= =?us-ascii?q?BCYRgCiaCPy6CMQWJCZJFAYdegVpFh3OBd4FZjR6IIopWAR84gUgVOxABhGCBS?= =?us-ascii?q?HOGbIENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,282,1477958400"; d="scan'208";a="197583103" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2017 06:58:53 +0000 Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v0P6wr2d017110 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 06:58:54 GMT Received: from xch-rtp-003.cisco.com (64.101.220.143) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 01:58:52 -0500 Received: from xch-rtp-003.cisco.com ([64.101.220.143]) by XCH-RTP-003.cisco.com ([64.101.220.143]) with mapi id 15.00.1210.000; Wed, 25 Jan 2017 01:58:53 -0500 From: "Alberto Gonzalez Prieto (albertgo)" To: Alexander Clemm , Juergen Schoenwaelder Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAAdJYIAADcHHYAACpzHgAAA9DsAAAXrmYAAAKs3AAACWIQAAQHeroA= Date: Wed, 25 Jan 2017 06:58:52 +0000 Message-ID: References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170118075314.GA4786@elstar.local> <20170119.110851.908806806765175703.mbj@tail-f.com> <3733c5053b0146baa777c06f6b3ea656@XCH-RTP-013.cisco.com> <20170119154002.GB8004@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53CE9@dfweml501-mbb> <20170119184842.GA8407@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2ED53DC8@dfweml501-mbb> In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2ED53DC8@dfweml501-mbb> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1d.0.161209 x-ms-exchange-messagesentrepresentingtype: 1 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.24.116.231] Content-Type: text/plain; charset="utf-8" Content-ID: <2E06E7B9DF7A9140A27CFDA11DA625CD@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 06:58:57 -0000 SGVsbG8sDQoNCkkgYW0gT0sgd2l0aCDigJxzdWJzY3JpcHRpb24gc3RhdGUgbm90aWZpY2F0aW9u c+KAnS4gDQpJIHRoaW5rIGl0IGlzIGltcG9ydGFudCB0byBoYXZlIGEgdGVybSB0aGF0IGRpZmZl cmVudGlhdGVzIHRoZXNlIG5vdGlmaWNhdGlvbnMgZm9yIGNvbmNlcHR1YWxseSwgdGhleSBhcmUg ZGlmZmVyZW50IGZyb20g4oCcZXZlbnQgbm90aWZpY2F0aW9uc+KAnS4NCg0KVGhhbmtzLA0KDQpB bGJlcnRvDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOZXRjb25mIDxuZXRj b25mLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhh bmRlci5jbGVtbUBodWF3ZWkuY29tPg0KRGF0ZTogVGh1cnNkYXksIEphbnVhcnkgMTksIDIwMTcg YXQgMTE6NTUgQU0NClRvOiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBq YWNvYnMtdW5pdmVyc2l0eS5kZT4NCkNjOiAibmV0Y29uZkBpZXRmLm9yZyIgPG5ldGNvbmZAaWV0 Zi5vcmc+DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIE5ldyBOb3RpZmljYXRpb24gYW5kIFN1YnNj cmlwdGlvbiBGZWF0dXJlcyBXQVNGVzogMyBPcHRpb25zIGZvciBTdWJzY3JpcHRpb24gJiBFdmVu dCBOb3RpZmljYXRpb24gZHJhZnQgc3RydWN0dXJlDQoNCiAgICBPSywgc28gZm9yIHRoZSBwdXJw b3NlcyBoZXJlIEkgYW0gZmluZSB3aXRoIHN1YnNjcmlwdGlvbiBzdGF0ZSBub3RpZmljYXRpb25z LiAgDQogICAgDQogICAgVGhlIHF1ZXN0aW9uIHJlbWFpbnMsIGhvd2V2ZXIsIHdoZXRoZXIgd2Ug d2FudCB0byBhbGxvdyBmb3IgZ2VuZXJhdGlvbiBvZiB0aGlzIGNvbmNlcHQgYW5kIGhhdmUgdGhp cyBpbiBjaGFydGVyLiAgSS5lLiwgc3VwcG9ydCB0aGUgdXNlIGNhc2VzIG9mIG5vdGlmaWNhdGlv bnMgaW50ZW5kZWQgZm9yIGEgc3BlY2lmaWMgcmVjZWl2ZXIgLyB0aWVkIHRvIGEgc3BlY2lmaWMg b2JqZWN0IG9yIGxvbmctbGl2ZWQgb3BlcmF0aW9uIHRoYXQgaGFzIGEgY2xlYXIgb3duZXJzaGlw LiAgSG93ZXZlciwgSSBhbSB0aGlua2luZyBvZiB0aGUgZXhhbXBsZSBvZiB0aGUgbG9uZy1ydW5u aW5nIHRlc3Qgb3BlcmF0aW9uIHdpdGggY29udGludW91cyB1cGRhdGVzLiAgQXBwbHlpbmcgc29t ZXRoaW5nIGNhbGxlZCBzdWJzY3JpcHRpb24gc3RhdGUgbm90aWZpY2F0aW9ucyBpbiB0aGF0IHNj ZW5hcmlvIGFwcGVhcnMgbGlrZSBhIHN0cmV0Y2gsIGFsdGhvdWdoIHRoZSBzYW1lIGNvbmNlcHQg d291bGQgYmUgYXBwbGljYWJsZSB0aGVyZS4gIFRvIGtlZXAgdGhpbmdzIHNpbXBsZSwgcGVyaGFw cyB3ZSBzaG91bGQganVzdCBrZWVwIG91cnNlbHZlcyB0byBzdWJzY3JpcHRpb24gc3RhdGUgbm90 aWZpY2F0aW9uczsgYXQgdGhlIHNhbWUgdGltZSBpdCBtaWdodCBhIGdvb2Qgb3Bwb3J0dW5pdHkg dG8gY2FwdHVyZSB0aGlzIGFsc28gd2hpbGUgd2UgYXJlIGRpc2N1c3NpbmcgdGhlIGNoYXJ0ZXIg Y2hhbmdlLiAgQW55d2F5LCBpdCB3YXMganVzdCBhIHRob3VnaHQuICAgDQogICAgDQogICAgLS0t IEFsZXggIA0KICAgIA0KICAgIC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQogICAgRnJvbTog SnVlcmdlbiBTY2hvZW53YWVsZGVyIFttYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2 ZXJzaXR5LmRlXSANCiAgICBTZW50OiBUaHVyc2RheSwgSmFudWFyeSAxOSwgMjAxNyAxMDo0OSBB TQ0KICAgIFRvOiBBbGV4YW5kZXIgQ2xlbW0gPGFsZXhhbmRlci5jbGVtbUBodWF3ZWkuY29tPg0K ICAgIENjOiBFcmljIFZvaXQgKGV2b2l0KSA8ZXZvaXRAY2lzY28uY29tPjsgbmV0Y29uZkBpZXRm Lm9yZw0KICAgIFN1YmplY3Q6IFJlOiBbTmV0Y29uZl0gTmV3IE5vdGlmaWNhdGlvbiBhbmQgU3Vi c2NyaXB0aW9uIEZlYXR1cmVzIFdBU0ZXOiAzIE9wdGlvbnMgZm9yIFN1YnNjcmlwdGlvbiAmIEV2 ZW50IE5vdGlmaWNhdGlvbiBkcmFmdCBzdHJ1Y3R1cmUNCiAgICANCiAgICBJIHRoaW5rIHdlIHNo b3VsZCBjbGVhcmx5IHNlcGFyYXRlIF93aGF0XyBraW5kIG9mIGluZm9ybWF0aW9uIG5vdGlmaWNh dGlvbnMgY2FycnkgKGFuZCAic3Vic2NyaXB0aW9uIHN0YXRlIG5vdGlmaWNhdGlvbiIgc2VlbXMg cmlnaHQgb24gdGFyZ2V0IGhlcmUpIGZyb20gX2hvd18gc3Vic2NyaXB0aW9ucyB0byBub3RpZmlj aWF0aW9ucyBhcmUgY3JlYXRlZCAvIGRlbGV0ZWQgKGV4cGxpY2l0LCBpbXBsaWNpdCwgLi4uKSBh bmQgd2Ugc2hvdWxkIEkgdGhpbmsgYXZvaWQgdHJ5aW5nIHRvIGZpbmQgYW4gb3BhcXVlIHRlcm0g bGlrZSAnT0FNIG5vdGlmaWNhdGlvbnMnIHRoYXQgZm9sZHMgdHdvIHNlcGFyYXRlIGNvbmNlcHRz IGludG8gYSBzaW5nbGUgYW5kIGJ5IGl0c2VsZiBjb25mdXNpbmcgdGVybS4NCiAgICANCiAgICAv anMNCiAgICANCiAgICBPbiBUaHUsIEphbiAxOSwgMjAxNyBhdCAwNjoyOTozM1BNICswMDAwLCBB bGV4YW5kZXIgQ2xlbW0gd3JvdGU6DQogICAgPiBIaSwNCiAgICA+IA0KICAgID4gVGhlIHNwZWNp ZmljIG5vdGlmaWNhdGlvbnMgdW5kZXIgZGlzY3Vzc2lvbnMgYXJlIG5vdGlmaWNhdGlvbnMgdGhh dCBpbmZvcm0gYSByZWNlaXZlciBvZiBub3RpZmljYXRpb25zIG9mIGNoYW5nZXMgdG8gc3Vic2Ny aXB0aW9uIHN0YXRlIHRoYXQgd2lsbCBpbXBhY3Qgd2hhdCBub3RpZmljYXRpb25zIHRoZSByZWNl aXZlciBjYW4gZXhwZWN0IHRvIHJlY2VpdmUuICBXaGF0IHNldHMgdGhvc2UgcGFydGljdWxhciBu b3RpZmljYXRpb25zIGFwYXJ0IGZyb20gb3RoZXIgbm90aWZpY2F0aW9ucyBpcyB0aGF0IHlvdSBk byBub3QgaGF2ZSB0byBleHBsaWNpdGx5IHN1YnNjcmliZSB0byB0aGVtIGluIG9yZGVyIHRvIHJl Y2VpdmUgdGhlbSwgYW5kIHRoYXQgdGhlIG5vdGlmaWNhdGlvbnMgYXJlIGNvbmZpbmVkIHRvIHRo YXQgcGFydGljdWxhciBjb250ZXh0IGFuZCBub3Qgc3Vic2NyaWJhYmxlIHRvIG90aGVycy4gIElu c3RlYWQsIHVzZSBvZiBhIHBhcnRpY3VsYXIgZmVhdHVyZSAoaW4gdGhpcyBjYXNlLCBzdWJzY3Jp YmluZyB0byBhIHNldCBvZiBub3RpZmljYXRpb25zKSBtYWtlcyBhIHVzZXIgYXV0b21hdGljYWxs eSAic3Vic2NyaWJlZCIgdG8gbm90aWZpY2F0aW9ucyBpbiB0aGlzIGNvbnRleHQuICANCiAgICA+ IA0KICAgID4gV2hpbGUgInN1YnNjcmlwdGlvbiBzdGF0ZSBub3RpZmljYXRpb24iIGlzIGluIG9u ZSBzZW5zZSBhbiBhY2N1cmF0ZSBkZXNjcmlwdGlvbiBvZiB3aGF0IHRoaXMgZG9lcywgSSB0aGlu ayBhIG1vcmUgZ2VuZXJhbCB0ZXJtIG1heSBiZSBtb3JlIGFwcHJvcHJpYXRlLCBmb3Igc2V2ZXJh bCByZWFzb25zOg0KICAgID4gLSBUbyBjYXB0dXJlIHRoZSBkaWZmZXJlbnQgbmF0dXJlIG9mIHRo aXMgdHlwZSBvZiBub3RpZmljYXRpb24gdnMgb3RoZXIgbm90aWZpY2F0aW9ucywgZS5nLiBhbiAi aW50ZXJmYWNlIHN0YXRlIG5vdGlmaWNhdGlvbiIsIHdoaWNoIHdvdWxkIGJlaGF2ZSBnZW51aW5l bHkgZGlmZmVyZW50bHkgaW4gdGVybXMgb2YgaG93IHRvIHN1YnNjcmliZSB0byBpdC4gIA0KICAg ID4gLSBUbyBhbGxvdyBmb3IgYSBnZW5lcmFsaXphdGlvbiBvZiB0aGlzIGNvbmNlcHQgdG8gb3Ro ZXIgYXJlYXMgYXMgd2VsbC4gIFRoZSBxdWVzdGlvbiBpcyB3aGV0aGVyIHRoaXMgaXMgaW50ZW5k ZWQgdG8gYmUgaW4gY2hhcnRlciwgYnV0IGl0IGlzIGNlcnRhaW5seSBjb25jZWl2YWJsZSB0byB1 c2UgYSBzaW1pbGFyIHR5cGUgb2Ygbm90aWZpY2F0aW9ucyBmb3Igb3RoZXIgdXNlIGNhc2VzLiAg VGhpbmssIGZvciBleGFtcGxlLCBvZiBhbiBvbmdvaW5nIHRlc3QgaW4gd2hpY2ggaW50ZXJtZWRp YXRlIHVwZGF0ZXMgYWJvdXQgdGVzdCBwcm9ncmVzcyB3b3VsZCBiZSBzZW50IHVzaW5nIG5vdGlm aWNhdGlvbnMgLSBidXQgdGhvc2Ugbm90aWZpY2F0aW9ucyBzaG91bGQgZ28gb25seSB0byB0aGUg aW5pdGlhdG9yIG9mIHRoZSB0ZXN0LCBhbmQgdGhlIGluaXRpYXRvciBvZiB0aGUgdGVzdCBzaG91 bGQgbm90IGhhdmUgdG8gc2VwYXJhdGVseSBzdWJzY3JpYmUgdG8gdGVzdCB1cGRhdGUgbm90aWZp Y2F0aW9ucy4gIA0KICAgID4gDQogICAgPiBXaGF0IGFib3V0IHRoZSB0ZXJtICJPQU0gbm90aWZp Y2F0aW9ucyI/ICBvciwgdG8gbGVhdmUgb3V0ICJwbGFuZSIgZnJvbSAiY29udHJvbCBwbGFuZSBu b3RpZmljYXRpb25zIiBhbmQgc2ltcGx5IGNhbGwgaXQgImNvbnRyb2wgbm90aWZpY2F0aW9ucyI/ ICANCiAgICA+IA0KICAgID4gLS0tIEFsZXgNCiAgICA+IA0KICAgID4gLS0tLS1PcmlnaW5hbCBN ZXNzYWdlLS0tLS0NCiAgICA+IEZyb206IE5ldGNvbmYgW21haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBKdWVyZ2VuIA0KICAgID4gU2Nob2Vud2FlbGRlcg0KICAg ID4gU2VudDogVGh1cnNkYXksIEphbnVhcnkgMTksIDIwMTcgNzo0MCBBTQ0KICAgID4gVG86IEVy aWMgVm9pdCAoZXZvaXQpIDxldm9pdEBjaXNjby5jb20+DQogICAgPiBDYzogbmV0Y29uZkBpZXRm Lm9yZw0KICAgID4gU3ViamVjdDogUmU6IFtOZXRjb25mXSBOZXcgTm90aWZpY2F0aW9uIGFuZCBT dWJzY3JpcHRpb24gRmVhdHVyZXMgDQogICAgPiBXQVNGVzogMyBPcHRpb25zIGZvciBTdWJzY3Jp cHRpb24gJiBFdmVudCBOb3RpZmljYXRpb24gZHJhZnQgc3RydWN0dXJlDQogICAgPiANCiAgICA+ IE9uIFRodSwgSmFuIDE5LCAyMDE3IGF0IDAzOjEyOjQzUE0gKzAwMDAsIEVyaWMgVm9pdCAoZXZv aXQpIHdyb3RlOg0KICAgID4gPiA+ID4NCiAgICA+ID4gPiA+IEkgdGhpbmsgJ2NvbnRyb2wgcGxh bmUgbm90aWZpY2F0aW9uJyBpcyBhIHJlYWxseSBiYWQgdGVybSBmb3IgDQogICAgPiA+ID4gPiB3 aGF0IGl0IGRvZXMgYW5kIHRoZSBzb29uZXIgd2UgZmluZCBhIGJldHRlciB0ZXJtIHRoZSBiZXR0 ZXIgaXQgaXMuDQogICAgPiA+IA0KICAgID4gPiBBIGJldHRlciB0ZXJtIHdvdWxkIGJlIGdyZWF0 LCBtYXliZSAiU3Vic2NyaXB0aW9uIFN0YXRlIE5vdGlmaWNhdGlvbiI/ICAgDQogICAgPiA+DQog ICAgPiANCiAgICA+IFRoaXMgcHJvcG9zZWQgdGVybSBpcyBtdWNoIG11Y2ggYmV0dGVyLg0KICAg ID4gDQogICAgPiA+IEkgZG8gdGhpbmsgc29tZSB0ZXJtIGlzIGhlbHBmdWwuICBUaGVzZSBhcmUg dGhlIG5vdGlmaWNhdGlvbnMgd2hpY2ggbWF0Y2ggMToxIHdpdGggdGhlIHNldCBvZiBTdWJzY3Jp cHRpb24gU3RhdGUgbW9kZWwgc3RhdGUgY2hhbmdlcyBvbiBhIFB1Ymxpc2hlci4gIFNlZSA1Mjc3 YmlzLCBzZWN0aW9uIDIuNC4gIA0KICAgID4gPg0KICAgID4gDQogICAgPiBGaW5lIHdpdGggbWUg LSBhcyBsb25nIGFzIHRoZSB0ZXJtIGlzIHNwZWNpZmljLg0KICAgID4gDQogICAgPiAvanMNCiAg ICA+IA0KICAgID4gLS0gDQogICAgPiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEph Y29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KICAgID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KICAgID4g RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+DQogICAgPiANCiAgICA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQogICAgPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KICAgID4gTmV0Y29u ZkBpZXRmLm9yZw0KICAgID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u ZXRjb25mDQogICAgDQogICAgLS0gDQogICAgSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAg ICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCiAgICBQaG9uZTogKzQ5IDQyMSAyMDAg MzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQogICAg RmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNvYnMtdW5pdmVy c2l0eS5kZS8+DQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCiAgICBOZXRjb25mIG1haWxpbmcgbGlzdA0KICAgIE5ldGNvbmZAaWV0Zi5v cmcNCiAgICBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCiAg ICANCg0K From nobody Wed Jan 25 10:23:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 624F0129ACE for ; Wed, 25 Jan 2017 10:23:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -17.72 X-Spam-Level: X-Spam-Status: No, score=-17.72 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mMBR16pkk8Oe for ; Wed, 25 Jan 2017 10:23:19 -0800 (PST) Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2D500129AC8 for ; Wed, 25 Jan 2017 10:23:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55912; q=dns/txt; s=iport; t=1485368599; x=1486578199; h=from:to:subject:date:message-id:mime-version; bh=XINgaSDvkaekVCLiJA2V7D4P20TwsuMZGuPDedv5TvA=; b=lbCh2lPBgKKTBh8EdH58sUGH9dWAXxvpxDDwU8EgBngU4gkcNzh9w8kl f+oUc+hE6XyOI7jvOilAwZ8CCpVVvy7qwW8rbvcfJA7qKtxKto1+iC9uW T+S9Ej5Sv2ZxPzmY+Ukr3GwKcpOKujE4QPaUWHoLN+CUUECJG1XPsXs8a s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BBAQB17IhY/5NdJa1DGhkBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJvRgEBAQEBH2CBCQeDTYoIlSSQBIIPgg0shhKCAj8YAQIBAQE?= =?us-ascii?q?BAQEBYiiFEwpBHQEtCwgBAwYCBDAmAQQBGokUDi2uSoIlg1SHFgEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBGQWGS4YrgVCBDn2BfjqCXwWbTgGGZIsFggCFEIloknkBHzi?= =?us-ascii?q?BSBU7hDwcgWFzAQSHGoENAQEB?= X-IronPort-AV: E=Sophos;i="5.33,285,1477958400"; d="scan'208,217";a="376326194" Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 25 Jan 2017 18:23:18 +0000 Received: from XCH-RTP-015.cisco.com (xch-rtp-015.cisco.com [64.101.220.155]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id v0PINHLC002653 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 25 Jan 2017 18:23:17 GMT Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-015.cisco.com (64.101.220.155) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 25 Jan 2017 13:23:16 -0500 Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1210.000; Wed, 25 Jan 2017 13:23:16 -0500 From: "Eric Voit (evoit)" To: "'netconf@ietf.org'" , "'netconf-subscriptions-dt@voit.org'" Thread-Topic: Minutes 25-Jan: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts Thread-Index: AdJ3OA8kIfBqT7DcQf29gMg8zJiLKw== Date: Wed, 25 Jan 2017 18:23:16 +0000 Message-ID: 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: [10.118.56.226] Content-Type: multipart/alternative; boundary="_000_c816b6cc54b84984ada9a7ae3f8a35a3XCHRTP013ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [Netconf] Minutes 25-Jan: NETCONF/RESTCONF/HTTP2 Subscription & Event drafts X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2017 18:23:21 -0000 --_000_c816b6cc54b84984ada9a7ae3f8a35a3XCHRTP013ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 TWludXRlcyBwb3N0ZWQgYXQ6DQpodHRwczovL2dpdGh1Yi5jb20vbmV0Y29uZi13Zy95YW5nLXB1 c2gvd2lraS9NaW51dGVzLTIwMTctMDEtMjUNCg0KwrcgICAgICAgIEFzIGFsd2F5cywgb3VyIERl emlnblRNIFRlYW0gaXMgYSBnYXRoZXJpbmcgb2YgaW5kaXZpZHVhbHMgcHJvdmlkaW5nIGluZm9y bWFsIGlucHV0IHRvIE5FVENPTkYuIFdlIGFzayBORVRDT05GIFdHIHRvIGNvbW1lbnQgb24gb3Vy IGRpc2N1c3Npb24gcmVzdWx0cyBhcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29uc2Vuc3Vz LiBQbGVhc2UgYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1ZGVkIGRp cmVjdGx5IGluIHRoZXNlIG1lZXRpbmdzLg0KDQoNCk1lZXRpbmcgTWF0ZXJpYWxzDQoNCkF0dGVu ZGluZw0KDQpXZWJFeCBSZWNvcmRpbmc8aHR0cHM6Ly9jaXNjby53ZWJleC5jb20vY2lzY29zYWxl cy9sc3IucGhwP1JDSUQ9M2E2NzMxMzljYTk4NGM1ZDg3NmYyMjI0OTZiMzZhOTM+DQpwYXNzd29y ZDogV2NzRW1EeDMNCg0KQW5keSBCaWVybWFuLCBBbGV4YW5kZXIgQ2xlbW0sIEFtYmlrYSBUcmlw YXRoeSwgRWluYXIgTmlsc2VuLU55Z2FhcmQsIEVyaWMgVm9pdCwgVGltIEplbmtpbnMsIEJhbGF6 cyBMZW5neWVsLCBNZWhtZXQgRXJzdWUsIEFsYmVydG8gR29uemFsZXoNCg0KRXJyb3IgQ29kZXMN Cg0KICAqICAgUHJlc2VudGVkIGxpc3Qgb2YgcG90ZW50aWFsIGVycm9ycyBmb3IgUlBDcyAmIE5v dGlmaWNhdGlvbnMNCiAgICAgKiAgIERvbid0IHdhbnQgdG8gb3ZlcmxvYWQgUlBDIGVycm9yLiBQ ZXJoYXBzIHdlIGNvdWxkIHBsYWNlIHRoaXMgaW5mb3JtYXRpb24gaW4gRXJyb3IgQXBwIFRhZyBz dHJpbmdzIGluc3RlYWQgb2YgcmV0dXJuZWQgZGF0YS4gVGFrZSB0aGlzIHRvIHRoZSBtYWlsaW5n IGxpc3QgdG8gZGV0ZXJtaW5lIHRoZSByaWdodCB3YXkgdG8gY29tbXVuaWNhdGUgdGhlc2UgdHlw ZXMgb2YgZXJyb3JzLg0KICAgICAqICAgTm8gY2hhbmdlcyB0byB0aGUgYXNzZXJ0ZWQgbGlzdCBv ZiBlcnJvciB0eXBlcyBvdGhlciB0aGFuIGV2ZXJ5b25lIGFncmVlaW5nIHRoYXQgd2FybmluZ3Mg d291bGQgbm90IGJlIHByb3ZpZGVkLg0KDQpOZXcgU2NoZW1hIEFubm90YXRpb25zIERyYWZ0PGh0 dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXNjaGVt YS1hbm5vdGF0aW9uLz4NCg0KICAqICAgQmFsYXpzIHByZXNlbnRlZDogSW5zdGFuY2UgdnMgRXh0 ZW5zaW9uIHZzIERldmlhdGlvbg0KICAgICAqICAgU2luY2UgZHJhZnQgcmVsZWFzZSwgTkVUTU9E IG1lbWJlcnMgaGF2ZSBwb2ludGVkIG91dCB0aGF0IGRldmlhdGlvbnMgY2FuIGJlIHVzZWQgZm9y IHRoaXMgZnVuY3Rpb24gKGluY2x1ZGluZyBhdHRyaWJ1dGVzKQ0KICAgICAqICAgRmFpbGluZyBv ZiBZQU5HIGNvbXBpbGVyIGhlcmUgaXMgYSBub3QgYSByZXN1bHQgb2YgZHJhd2JhY2tzIGluIFlB TkcgbGFuZ3VhZ2VzDQogICogICBHcm91cCBpcyBzcGxpdCBiZXR3ZWVuIERldmlhdGlvbnMsIGFu ZCBJbnN0YW5jZSBkYXRhLiBXaWxsIHJlc29sdmUgb24gTkVUTU9EIG1haWxlci4NCiAgKiAgIFZv dGUgZm9yIHlvdXIgZmF2b3JpdGUgb24gTkVUTU9EDQoNCkNoYXJ0ZXIgdm90ZSB1bmRlcndheSBv biBORVRDT05GDQoNCiAgKiAgIEF0IHRoaXMgcG9pbnQsIG5vIHZvdGVzIGFnYWluc3QgdGhlIGNo YXJ0ZXIgY2hhbmdlLCB2b3RpbmcgY2xvc2VzIEphbiAyN3RoLg0KICAgICAqICAgTWVobWV0IHdp bGwgZmxvYXQgc29tZSBjaGFydGVyIHRleHQgaWYgdGhpbmdzIGNsb3NlIHRoaXMgd2F5Lg0KICAq ICAgTm90aWZpY2F0aW9ucyAyLjAgd2lsbCBiZSBwaWNrZWQgYmFjayB1cCBhZnRlciB0aGUgdm90 ZSByZXN1bHQgKGlmIGNoYXJ0ZXIgY2hhbmdlIGlzIGFjY2VwdGVkKS4NCiAgICAgKiAgIFBlcmhh cHMgYSB0b3BpYyBmb3Igb3V0IG1lZXRpbmcgaW4gdHdvIHdlZWtzLg0KDQpGdXR1cmVzOiBQb3Rl bnRpYWwgU3Vic2NyaXB0aW9uIFBhcmFtZXRlcnMNCg0KICAqICAgRG8gd2Ugd2FudCB0byBhZGQg ImNoYW5nZXMgb25seSIgb3B0aW9uIGZvciBwZXJpb2RpYyBzdWJzY3JpcHRpb25zIGZvciB0aGlz IGRyYWZ0LCByYXRoZXIgdGhhbiBhIGZ1dHVyZXM/DQogICogICBTZW50aW1lbnQgaXMgaW4tZmF2 b3IuIEhvd2V2ZXIgdGhlcmUgYXJlIGNvbXBsZXhpdGllcyB3ZSBzdGlsbCBuZWVkIHRvIGFkZHJl c3MgYmVmb3JlIHdlIGFkZCB0byB0aGUgZHJhZnQ6DQogICAgICogICBEbyB3ZSBzZW5kIHRoZSBm dWxsIHNjaGVtYSB0cmVlIGFsd2F5cyB3aXRoIG5vIGxlYWZzIGhhdmUgY2hhbmdlZCBhdCB0aGUg ZW5kIG9mIHRoZSBwZXJpb2Q/DQogICAgICogICBEbyB3ZSBzZW5kIHBhdGNoIG1lY2hhbmlzbXMg b24gdGhlIHNjaGVtYSB0cmVlPw0KICAgICAqICAgRG8gd2Ugd2FudCB0byBzZW5kIG51bGwgbm90 aWZpY2F0aW9uIHVwZGF0ZXMgaWYgbm90aGluZyBoYXMgY2hhbmdlZCBhY3Jvc3MgdGhlIGVudGly ZSBzdWJzY3JpcHRpb24/DQogICAgICAgICogICBJZiBudWxsIG5vdGlmaWNhdGlvbnMgYXJlIG5v dCBzZW50LCB0aGVuIHRoZSBiZWhhdmlvciB3aWxsIGJlIHF1aXRlIGNsb3NlIHRvIG9uLWNoYW5n ZSBpbiB0ZXJtcyBvZiB0cmFuc2FjdGlvbiB2b2x1bWVzIGJldHdlZW4gZGV2aWNlcy4NCg0KDQo= --_000_c816b6cc54b84984ada9a7ae3f8a35a3XCHRTP013ciscocom_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 V2luZ2RpbmdzOw0KCXBhbm9zZS0xOjUgMCAwIDAgMCAwIDAgMCAwIDA7fQ0KQGZvbnQtZmFjZQ0K CXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMg MiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1 IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJTZWdvZSBVSSI7 DQoJcGFub3NlLTE6MiAxMSA1IDIgNCAyIDQgMiAyIDM7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMg Ki8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBp bjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpoMg0KCXttc28tc3R5bGUtcHJpb3JpdHk6 OTsNCgltc28tc3R5bGUtbGluazoiSGVhZGluZyAyIENoYXIiOw0KCW1zby1tYXJnaW4tdG9wLWFs dDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87 DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxOC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRp bWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0KaDMNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNv LXN0eWxlLWxpbms6IkhlYWRpbmcgMyBDaGFyIjsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTMuNXB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg Um9tYW4iLHNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5 Ojk5Ow0KCWNvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNv UGxhaW5UZXh0LCBsaS5Nc29QbGFpblRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxl LXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdp bjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KcC5Nc29MaXN0UGFyYWdyYXBoLCBsaS5N c29MaXN0UGFyYWdyYXBoLCBkaXYuTXNvTGlzdFBhcmFncmFwaA0KCXttc28tc3R5bGUtcHJpb3Jp dHk6MzQ7DQoJbWFyZ2luLXRvcDowaW47DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltYXJnaW4tYm90 dG9tOjBpbjsNCgltYXJnaW4tbGVmdDouNWluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglm b250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmO30N CnNwYW4uSGVhZGluZzJDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIZWFkaW5nIDIgQ2hhciI7DQoJ bXNvLXN0eWxlLXByaW9yaXR5Ojk7DQoJbXNvLXN0eWxlLWxpbms6IkhlYWRpbmcgMiI7DQoJZm9u dC13ZWlnaHQ6Ym9sZDt9DQpzcGFuLkhlYWRpbmczQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSGVh ZGluZyAzIENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5Ow0KCW1zby1zdHlsZS1saW5rOiJI ZWFkaW5nIDMiOw0KCWZvbnQtd2VpZ2h0OmJvbGQ7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3Jt YWwwLCBkaXYubXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1h cmdpbi10b3AtYWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250 LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQpwLm0tNTA3MTY1MTcyOTg5MTMxNDY4 Nm1zb2xpc3RwYXJhZ3JhcGgsIGxpLm0tNTA3MTY1MTcyOTg5MTMxNDY4Nm1zb2xpc3RwYXJhZ3Jh cGgsIGRpdi5tLTUwNzE2NTE3Mjk4OTEzMTQ2ODZtc29saXN0cGFyYWdyYXBoDQoJe21zby1zdHls ZS1uYW1lOm1fLTUwNzE2NTE3Mjk4OTEzMTQ2ODZtc29saXN0cGFyYWdyYXBoOw0KCW1zby1tYXJn aW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiIsc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNv LXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7 DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUyMw0KCXttc28tc3R5bGUtdHlwZTpw ZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCgljb2xvcjojMUY0 OTdEO30NCnNwYW4uRW1haWxTdHlsZTI0DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5h cHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29udmVydGVkLXNw YWNlO30NCnNwYW4uRW1haWxTdHlsZTI2DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh bi5FbWFpbFN0eWxlMjcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUy OA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fu cy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4uRW1haWxTdHlsZTI5DQoJe21zby1z dHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0K CWNvbG9yOiMxRjQ5N0Q7fQ0Kc3Bhbi5FbWFpbFN0eWxlMzANCgl7bXNvLXN0eWxlLXR5cGU6cGVy c29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93 dGV4dDt9DQpzcGFuLlBsYWluVGV4dENoYXINCgl7bXNvLXN0eWxlLW5hbWU6IlBsYWluIFRleHQg Q2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJQbGFpbiBU ZXh0IjsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQouTXNvQ2hwRGVmYXVs dA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBw YWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4w aW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9 DQovKiBMaXN0IERlZmluaXRpb25zICovDQpAbGlzdCBsMA0KCXttc28tbGlzdC1pZDozNjQ2OTQ0 NzsNCgltc28tbGlzdC10ZW1wbGF0ZS1pZHM6LTE2NjE1ODM2MDt9DQpAbGlzdCBsMDpsZXZlbDEN Cgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsN Cgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3Qg bDA6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw0DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDA6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6 bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw4DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDA6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQu NWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1 aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7 fQ0KQGxpc3QgbDENCgl7bXNvLWxpc3QtaWQ6MTM4NDI0NzQzOw0KCW1zby1saXN0LXR5cGU6aHli cmlkOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxMTY2NTcxNjYgNjc2OTg2ODkgNjc2OTg2OTEg Njc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2OTg2OTMgNjc2OTg2ODkgNjc2OTg2OTEgNjc2 OTg2OTM7fQ0KQGxpc3QgbDE6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250 LWZhbWlseTpTeW1ib2w7fQ0KQGxpc3QgbDE6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9y bWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25l Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpAbGlzdCBsMTpsZXZlbDMNCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2 ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMTpsZXZl bDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+C tzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlz dCBsMTpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseToiQ291cmll ciBOZXciO30NCkBsaXN0IGwxOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxs ZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDpub25lOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3Rv cDpub25lOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGwxOmxldmVsOA0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6bm9uZTsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0KQGxpc3QgbDE6bGV2 ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOm5vbmU7DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlv bjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDINCgl7bXNvLWxpc3QtaWQ6MzQ5MTgyNjc4Ow0KCW1zby1saXN0LXRlbXBsYXRlLWlk czoxNzQwMTM5NTM0O30NCkBsaXN0IGwyOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDI6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2 ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28tYmlkaS1mb250LWZh bWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsMjpsZXZlbDMNCgl7bXNvLWxldmVsLW51 bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFi LXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5k ZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldp bmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVs bGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47DQoJ bXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCglt c28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlz dCBsMjpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZl bC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDYNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMjpsZXZlbDcNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsMjpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC4waW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs MjpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsMw0KCXttc28tbGlzdC1p ZDo4MjQ4NTQ1MDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOi0zNzk1NDQ4NzY7fQ0KQGxpc3Qg bDM6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsMzpsZXZlbDINCgl7bXNvLWxl dmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVs LXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i O30NCkBsaXN0IGwzOmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJ bXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2 ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNp LWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxl dmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6 74KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0 aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNQ0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGwzOmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVs OA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwzOmxldmVsOQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw0DQoJe21zby1saXN0LWlkOjkzNjk4NjczOTsNCgltc28tbGlz dC10ZW1wbGF0ZS1pZHM6OTA4NzQ5NDc0O30NCkBsaXN0IGw0OmxldmVsMQ0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10 YWItc3RvcDouNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpT eW1ib2w7fQ0KQGxpc3QgbDQ6bGV2ZWwyDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDpvOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCgltc28t YmlkaS1mb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQpAbGlzdCBsNDpsZXZlbDMNCgl7 bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCglt c28tbGV2ZWwtdGFiLXN0b3A6MS41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0 Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZv bnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0 b3A6Mi4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50 Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5Oldpbmdk aW5nczt9DQpAbGlzdCBsNDpsZXZlbDUNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0 Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi41aW47DQoJbXNv LWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28t YW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBs NDpsZXZlbDYNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10 ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6My4waW47DQoJbXNvLWxldmVsLW51bWJlci1w b3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6 MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDcNCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNDpsZXZlbDgNCgl7bXNvLWxldmVsLW51bWJlci1m b3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6 NC4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5n czt9DQpAbGlzdCBsNDpsZXZlbDkNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0K CW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6NC41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpAbGlzdCBsNQ0K CXttc28tbGlzdC1pZDoxMDY5ODg0MzIxOw0KCW1zby1saXN0LXRlbXBsYXRlLWlkczoxOTkyOTE3 MDY7fQ0KQGxpc3QgbDU6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxl dmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5z aS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNTpsZXZl bDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Om87 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iO30NCkBsaXN0IGw1OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw1OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVs NQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNg0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw1OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw1OmxldmVsOQ0K CXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0K CW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxl ZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJ Zm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2DQoJe21zby1saXN0LWlkOjE1NTQyNjk0 NjY7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjE3MTkxNzgyMTg7fQ0KQGxpc3QgbDY6bGV2ZWwx DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjps ZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0K CWZvbnQtZmFtaWx5OlN5bWJvbDt9DQpAbGlzdCBsNjpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJl ci1mb3JtYXQ6cm9tYW4tbG93ZXI7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246cmlnaHQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluO30NCkBsaXN0 IGw2OmxldmVsMw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVs LXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVy LXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6 ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNA0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1z by1sZXZlbC10YWItc3RvcDoyLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7 DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9u dC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVy LWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3Rv cDoyLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6 LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rp bmdzO30NCkBsaXN0IGw2OmxldmVsNg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7 DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28t bGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1h bnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2 OmxldmVsNw0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRl eHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBv c2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZTox MC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsOA0KCXttc28t bGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1s ZXZlbC10YWItc3RvcDo0LjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw2OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZv cm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0 LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4y NWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2Rpbmdz O30NCkBsaXN0IGw3DQoJe21zby1saXN0LWlkOjE2MTMxMjQ3MDY7DQoJbXNvLWxpc3QtdGVtcGxh dGUtaWRzOi01MjMyMTg2MDg7fQ0KQGxpc3QgbDc6bGV2ZWwxDQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgrc7DQoJbXNvLWxldmVsLXRhYi1zdG9w Oi41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0u MjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OlN5bWJvbDt9 DQpAbGlzdCBsNzpsZXZlbDINCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1z by1sZXZlbC10ZXh0Om87DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciOw0KCW1zby1iaWRpLWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCkBsaXN0IGw3OmxldmVsMw0KCXttc28tbGV2 ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZl bC10YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4 dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p bHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjBp bjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWlu Ow0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30N CkBsaXN0IGw3OmxldmVsNQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDoyLjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsNw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDozLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGw3OmxldmVsOA0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpi dWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjBpbjsN Cgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0K CW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBs aXN0IGw3OmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGw4DQoJe21zby1s aXN0LWlkOjE4OTI3Njk1NjU7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRzOjc0MzYxNTI2Njt9DQpA bGlzdCBsODpsZXZlbDENCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1s ZXZlbC10ZXh0Ou+CtzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVt YmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQt c2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6U3ltYm9sO30NCkBsaXN0IGw4OmxldmVsMg0KCXtt c28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ6bzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0K CXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQt ZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBS b21hbiI7fQ0KQGxpc3QgbDg6bGV2ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxl dDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1z by1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNv LWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3Qg bDg6bGV2ZWw0DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwt dGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXIt cG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXpl OjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw1DQoJe21z by1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNv LWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsN Cgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250 LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXIt Zm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9w OjMuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDot LjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGlu Z3M7fQ0KQGxpc3QgbDg6bGV2ZWw3DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsN Cgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1s ZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFu c2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6 bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4 dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9z aXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEw LjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDg6bGV2ZWw5DQoJe21zby1s ZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxl dmVsLXRhYi1zdG9wOjQuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0 ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZh bWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDkNCgl7bXNvLWxpc3QtaWQ6MjAwOTIwNzgwMDsNCglt c28tbGlzdC10ZW1wbGF0ZS1pZHM6MjAzMDIxODc5Njt9DQpAbGlzdCBsOTpsZXZlbDENCgl7bXNv LWxldmVsLW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CtzsNCgltc28t bGV2ZWwtdGFiLXN0b3A6LjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJ dGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1m YW1pbHk6U3ltYm9sO30NCkBsaXN0IGw5OmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpyb21hbi1sb3dlcjsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51 bWJlci1wb3NpdGlvbjpyaWdodDsNCgl0ZXh0LWluZGVudDotLjI1aW47fQ0KQGxpc3QgbDk6bGV2 ZWwzDQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrv gqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjEuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRp b246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBw dDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw0DQoJe21zby1sZXZl bC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVs LXRhYi1zdG9wOjIuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0 LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWls eTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDk6bGV2ZWw2DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuMGluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw3 DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7 DQoJbXNvLWxldmVsLXRhYi1zdG9wOjMuNWluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246 bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsN Cglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw4DQoJe21zby1sZXZlbC1u dW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRh Yi1zdG9wOjQuMGluOw0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWlu ZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpX aW5nZGluZ3M7fQ0KQGxpc3QgbDk6bGV2ZWw5DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1 bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuNWluOw0K CW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJ bXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxp c3QgbDEwDQoJe21zby1saXN0LWlkOjIwNzIxMTg3MDg7DQoJbXNvLWxpc3QtdGVtcGxhdGUtaWRz Oi0xODc1MDQ1NjI7fQ0KQGxpc3QgbDEwOmxldmVsMQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1h dDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674K3Ow0KCW1zby1sZXZlbC10YWItc3RvcDouNWlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpTeW1ib2w7fQ0KQGxp c3QgbDEwOmxldmVsMg0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxl dmVsLXRleHQ6bzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6MS4waW47DQoJbXNvLWxldmVsLW51bWJl ci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNp emU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNvLWJpZGktZm9udC1m YW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KQGxpc3QgbDEwOmxldmVsMw0KCXttc28tbGV2ZWwt bnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10 YWItc3RvcDoxLjVpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1p bmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6 V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDQNCgl7bXNvLWxldmVsLW51bWJlci1mb3JtYXQ6 YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwtdGFiLXN0b3A6Mi4waW47 DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQtaW5kZW50Oi0uMjVpbjsN Cgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OldpbmdkaW5nczt9DQpA bGlzdCBsMTA6bGV2ZWw1DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0OmJ1bGxldDsNCgltc28t bGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjIuNWluOw0KCW1zby1sZXZlbC1u dW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47DQoJbXNvLWFuc2ktZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0KQGxpc3QgbDEwOmxldmVs Ng0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNvLWxldmVsLXRleHQ674Kn Ow0KCW1zby1sZXZlbC10YWItc3RvcDozLjBpbjsNCgltc28tbGV2ZWwtbnVtYmVyLXBvc2l0aW9u OmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZvbnQtc2l6ZToxMC4wcHQ7 DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCkBsaXN0IGwxMDpsZXZlbDcNCgl7bXNvLWxldmVs LW51bWJlci1mb3JtYXQ6YnVsbGV0Ow0KCW1zby1sZXZlbC10ZXh0Ou+CpzsNCgltc28tbGV2ZWwt dGFiLXN0b3A6My41aW47DQoJbXNvLWxldmVsLW51bWJlci1wb3NpdGlvbjpsZWZ0Ow0KCXRleHQt aW5kZW50Oi0uMjVpbjsNCgltc28tYW5zaS1mb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5 OldpbmdkaW5nczt9DQpAbGlzdCBsMTA6bGV2ZWw4DQoJe21zby1sZXZlbC1udW1iZXItZm9ybWF0 OmJ1bGxldDsNCgltc28tbGV2ZWwtdGV4dDrvgqc7DQoJbXNvLWxldmVsLXRhYi1zdG9wOjQuMGlu Ow0KCW1zby1sZXZlbC1udW1iZXItcG9zaXRpb246bGVmdDsNCgl0ZXh0LWluZGVudDotLjI1aW47 DQoJbXNvLWFuc2ktZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseTpXaW5nZGluZ3M7fQ0K QGxpc3QgbDEwOmxldmVsOQ0KCXttc28tbGV2ZWwtbnVtYmVyLWZvcm1hdDpidWxsZXQ7DQoJbXNv LWxldmVsLXRleHQ674KnOw0KCW1zby1sZXZlbC10YWItc3RvcDo0LjVpbjsNCgltc28tbGV2ZWwt bnVtYmVyLXBvc2l0aW9uOmxlZnQ7DQoJdGV4dC1pbmRlbnQ6LS4yNWluOw0KCW1zby1hbnNpLWZv bnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6V2luZ2RpbmdzO30NCm9sDQoJe21hcmdpbi1i b3R0b206MGluO30NCnVsDQoJe21hcmdpbi1ib3R0b206MGluO30NCi0tPjwvc3R5bGU+PCEtLVtp ZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4 PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8 bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0i MSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT4NCjwvaGVhZD4NCjxib2R5 IGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9Ildv cmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+TWludXRlcyBwb3N0ZWQgYXQ6PC9zcGFu PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LHNhbnMtc2VyaWYiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlm O2NvbG9yOiMxRjQ5N0QiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRjb25mLXdnL3lh bmctcHVzaC93aWtpL01pbnV0ZXMtMjAxNy0wMS0yNSI+aHR0cHM6Ly9naXRodWIuY29tL25ldGNv bmYtd2cveWFuZy1wdXNoL3dpa2kvTWludXRlcy0yMDE3LTAxLTI1PC9hPjwvc3Bhbj48c3BhbiBz dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZiI+DQo8c3BhbiBz dHlsZT0iY29sb3I6IzFGNDk3RCI+Jm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29MaXN0UGFyYWdyYXBoIiBzdHlsZT0idGV4dC1pbmRlbnQ6LS4y NWluO21zby1saXN0OmwxIGxldmVsMSBsZm8xO2JhY2tncm91bmQ6d2hpdGUiPg0KPCFbaWYgIXN1 cHBvcnRMaXN0c10+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6U3lt Ym9sO2NvbG9yOmJsYWNrIj48c3BhbiBzdHlsZT0ibXNvLWxpc3Q6SWdub3JlIj7CtzxzcGFuIHN0 eWxlPSJmb250OjcuMHB0ICZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+PC9zcGFuPjwvc3Bhbj48IVtl bmRpZl0+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJp YWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjpibGFjayI+QXMgYWx3YXlzLCBvdXIgRGV6aWduPHN1 cD5UTTwvc3VwPiBUZWFtIGlzIGEgZ2F0aGVyaW5nIG9mIGluZGl2aWR1YWxzIHByb3ZpZGluZyBp bmZvcm1hbCBpbnB1dCB0byBORVRDT05GLiBXZSBhc2sgTkVUQ09ORiBXRyB0byBjb21tZW50IG9u IG91ciBkaXNjdXNzaW9uDQogcmVzdWx0cyBhcyBhIHByZXBhcmF0aW9uIGZvciB0aGUgV0cgY29u c2Vuc3VzLiBQbGVhc2UgYXBwcm9hY2ggRXJpYyBWb2l0IGlmIHlvdSB3YW50IHRvIGJlIGluY2x1 ZGVkIGRpcmVjdGx5IGluIHRoZXNlIG1lZXRpbmdzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8dGFibGUgY2xhc3M9Ik1zb05vcm1hbFRhYmxl IiBib3JkZXI9IjAiIGNlbGxzcGFjaW5nPSIwIiBjZWxscGFkZGluZz0iMCIgd2lkdGg9IjE0MDAi IHN0eWxlPSJ3aWR0aDo1MjUuMHB0O2JhY2tncm91bmQ6d2hpdGU7Ym9yZGVyLWNvbGxhcHNlOmNv bGxhcHNlIj4NCjx0aGVhZD4NCjx0cj4NCjx0ZCBzdHlsZT0iYm9yZGVyOnNvbGlkICNEREREREQg MS4wcHQ7cGFkZGluZzo0LjVwdCA5Ljc1cHQgNC41cHQgOS43NXB0Ij4NCjxwIGNsYXNzPSJNc29O b3JtYWwiIGFsaWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFs aWduOmNlbnRlciI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5NZWV0aW5nIE1hdGVyaWFsczwvc3Bhbj48 L2I+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzMzMzMzMyI+PG86cD48L286cD48L3NwYW4+PC9iPjwvcD4NCjwvdGQ+DQo8 dGQgc3R5bGU9ImJvcmRlcjpzb2xpZCAjREREREREIDEuMHB0O2JvcmRlci1sZWZ0Om5vbmU7cGFk ZGluZzo0LjVwdCA5Ljc1cHQgNC41cHQgOS43NXB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFs aWduPSJjZW50ZXIiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdDt0ZXh0LWFsaWduOmNlbnRl ciI+DQo8Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZjtjb2xvcjojMzMzMzMzIj5BdHRlbmRpbmc8bzpwPjwvbzpwPjwvc3Bhbj48L2I+PC9w Pg0KPC90ZD4NCjwvdHI+DQo8L3RoZWFkPg0KPHRib2R5Pg0KPHRyIHN0eWxlPSJib3gtc2l6aW5n OiBib3JkZXItYm94Ij4NCjx0ZCBzdHlsZT0iYm9yZGVyOnNvbGlkICNEREREREQgMS4wcHQ7Ym9y ZGVyLXRvcDpub25lO3BhZGRpbmc6NC41cHQgOS43NXB0IDQuNXB0IDkuNzVwdDtib3gtc2l6aW5n OiBib3JkZXItYm94Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9t OjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNh bnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+PGEgaHJlZj0iaHR0cHM6Ly9jaXNjby53ZWJleC5jb20v Y2lzY29zYWxlcy9sc3IucGhwP1JDSUQ9M2E2NzMxMzljYTk4NGM1ZDg3NmYyMjI0OTZiMzZhOTMi PjxzcGFuIHN0eWxlPSJjb2xvcjojNDA3OEMwO3RleHQtZGVjb3JhdGlvbjpub25lIj5XZWJFeA0K IFJlY29yZGluZzwvc3Bhbj48L2E+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+ Jm5ic3A7PG86cD48L286cD48L3NwYW4+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+cGFzc3dvcmQ6IFdj c0VtRHgzPG86cD48L286cD48L3NwYW4+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0iYm9yZGVyLXRv cDpub25lO2JvcmRlci1sZWZ0Om5vbmU7Ym9yZGVyLWJvdHRvbTpzb2xpZCAjREREREREIDEuMHB0 O2JvcmRlci1yaWdodDpzb2xpZCAjREREREREIDEuMHB0O3BhZGRpbmc6NC41cHQgOS43NXB0IDQu NXB0IDkuNzVwdDtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi IHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZx dW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzMzMzMzMyI+QW5keSBCaWVybWFu LCBBbGV4YW5kZXIgQ2xlbW0sIEFtYmlrYSBUcmlwYXRoeSwgRWluYXIgTmlsc2VuLU55Z2FhcmQs IEVyaWMgVm9pdCwgVGltIEplbmtpbnMsIEJhbGF6cyBMZW5neWVsLCBNZWhtZXQgRXJzdWUsIEFs YmVydG8gR29uemFsZXo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJv ZHk+DQo8L3RhYmxlPg0KPGgzIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6LjI1aW47bWFyZ2lu LXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjEyLjBwdDttYXJnaW4tbGVmdDowaW47YmFja2dyb3Vu ZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94O2ZvbnQtdmFyaWFudC1saWdhdHVyZXM6IG5v cm1hbDtmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO29ycGhhbnM6IDI7dGV4dC1hbGlnbjpzdGFy dDt3aWRvd3M6IDI7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow cHgiPg0KPHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxNS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7U2Vn b2UgVUkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMzMzMzMzIj5FcnJvciBDb2RlczxvOnA+PC9v OnA+PC9zcGFuPjwvaDM+DQo8dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIg c3R5bGU9ImNvbG9yOiMzMzMzMzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1i b3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDQgbGV2ZWwxIGxmbzg7YmFja2dyb3VuZDp3aGl0ZTti b3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtT ZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5QcmVzZW50ZWQgbGlzdCBvZiBwb3RlbnRpYWwgZXJy b3JzIGZvciBSUENzICZhbXA7IE5vdGlmaWNhdGlvbnM8bzpwPjwvbzpwPjwvc3Bhbj4NCjx1bCB0 eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMz O21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0Omw0IGxldmVsMiBsZm84O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJv eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZiI+RG9uJ3Qgd2FudCB0byBvdmVybG9hZCBSUEMgZXJyb3IuIFBlcmhhcHMgd2UgY291bGQg cGxhY2UgdGhpcyBpbmZvcm1hdGlvbiBpbiBFcnJvciBBcHAgVGFnIHN0cmluZ3MgaW5zdGVhZCBv ZiByZXR1cm5lZCBkYXRhLiBUYWtlIHRoaXMgdG8gdGhlIG1haWxpbmcgbGlzdCB0byBkZXRlcm1p bmUgdGhlIHJpZ2h0IHdheSB0byBjb21tdW5pY2F0ZSB0aGVzZSB0eXBlcw0KIG9mIGVycm9ycy48 bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6 IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1s aXN0Omw0IGxldmVsMiBsZm84O2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJv eCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1z ZXJpZiI+Tm8gY2hhbmdlcyB0byB0aGUgYXNzZXJ0ZWQgbGlzdCBvZiBlcnJvciB0eXBlcyBvdGhl ciB0aGFuIGV2ZXJ5b25lIGFncmVlaW5nIHRoYXQgd2FybmluZ3Mgd291bGQgbm90IGJlIHByb3Zp ZGVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PC91bD4NCjwvbGk+PC91bD4NCjxoMyBzdHlsZT0i bXNvLW1hcmdpbi10b3AtYWx0Oi4yNWluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTox Mi4wcHQ7bWFyZ2luLWxlZnQ6MGluO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVy LWJveDtmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7Zm9udC12YXJpYW50LWNhcHM6IG5v cm1hbDtvcnBoYW5zOiAyO3RleHQtYWxpZ246c3RhcnQ7d2lkb3dzOiAyOy13ZWJraXQtdGV4dC1z dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTUuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWY7Y29s b3I6IzMzMzMzMyI+TmV3PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7 PC9zcGFuPjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxl bmd5ZWwtbmV0bW9kLXNjaGVtYS1hbm5vdGF0aW9uLyI+PHNwYW4gc3R5bGU9ImNvbG9yOiM0MDc4 QzA7dGV4dC1kZWNvcmF0aW9uOm5vbmUiPlNjaGVtYQ0KIEFubm90YXRpb25zIERyYWZ0PC9zcGFu PjwvYT48bzpwPjwvbzpwPjwvc3Bhbj48L2gzPg0KPHVsIHR5cGU9ImRpc2MiPg0KPGxpIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm85O2JhY2tn cm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+QmFsYXpzIHByZXNlbnRlZDog SW5zdGFuY2UgdnMgRXh0ZW5zaW9uIHZzIERldmlhdGlvbjxvOnA+PC9vOnA+PC9zcGFuPg0KPHVs IHR5cGU9ImNpcmNsZSI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMz MzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDMgbGV2ZWwyIGxmbzk7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXIt Ym94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5z LXNlcmlmIj5TaW5jZSBkcmFmdCByZWxlYXNlLCBORVRNT0QgbWVtYmVycyBoYXZlIHBvaW50ZWQg b3V0IHRoYXQgZGV2aWF0aW9ucyBjYW4gYmUgdXNlZCBmb3IgdGhpcyBmdW5jdGlvbiAoaW5jbHVk aW5nIGF0dHJpYnV0ZXMpPG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0bzttc28tbGlzdDpsMyBsZXZlbDIgbGZvOTtiYWNrZ3JvdW5kOndoaXRlO2JveC1z aXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29l IFVJJnF1b3Q7LHNhbnMtc2VyaWYiPkZhaWxpbmcgb2YgWUFORyBjb21waWxlciBoZXJlIGlzIGEg bm90IGEgcmVzdWx0IG9mIGRyYXdiYWNrcyBpbiBZQU5HIGxhbmd1YWdlczxvOnA+PC9vOnA+PC9z cGFuPjwvbGk+PC91bD4NCjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj MzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNvLWxp c3Q6bDMgbGV2ZWwxIGxmbzk7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94 Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNl cmlmIj5Hcm91cCBpcyBzcGxpdCBiZXR3ZWVuIERldmlhdGlvbnMsIGFuZCBJbnN0YW5jZSBkYXRh LiBXaWxsIHJlc29sdmUgb24gTkVUTU9EIG1haWxlci48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0 O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwzIGxldmVsMSBsZm85O2JhY2tn cm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+Vm90ZSBmb3IgeW91ciBmYXZv cml0ZSBvbiBORVRNT0Q8bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8aDMgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDouMjVpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIu MHB0O21hcmdpbi1sZWZ0OjBpbjtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1i b3g7Zm9udC12YXJpYW50LWxpZ2F0dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3Jt YWw7b3JwaGFuczogMjt0ZXh0LWFsaWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ry b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXpl OjE1LjBwdDtmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9y OiMzMzMzMzMiPkNoYXJ0ZXIgdm90ZSB1bmRlcndheSBvbiBORVRDT05GPG86cD48L286cD48L3Nw YW4+PC9oMz4NCjx1bCB0eXBlPSJkaXNjIj4NCjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i Y29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1h bHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDEgbGZvMTA7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6 aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBV SSZxdW90OyxzYW5zLXNlcmlmIj5BdCB0aGlzIHBvaW50LCBubyB2b3RlcyBhZ2FpbnN0IHRoZSBj aGFydGVyIGNoYW5nZSwgdm90aW5nIGNsb3NlcyBKYW4gMjd0aC48bzpwPjwvbzpwPjwvc3Bhbj4N Cjx1bCB0eXBlPSJjaXJjbGUiPg0KPGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJjb2xvcjoj MzMzMzMzO21zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRv O21zby1saXN0OmwyIGxldmVsMiBsZm8xMDtiYWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJv cmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7 LHNhbnMtc2VyaWYiPk1laG1ldCB3aWxsIGZsb2F0IHNvbWUgY2hhcnRlciB0ZXh0IGlmIHRoaW5n cyBjbG9zZSB0aGlzIHdheS48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2xpPjxsaSBj bGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttYXJnaW4tdG9wOjMuMHB0O21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvO21zby1saXN0OmwyIGxldmVsMSBsZm8xMDtiYWNrZ3Jv dW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3giPg0KPHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OiZxdW90O1NlZ29lIFVJJnF1b3Q7LHNhbnMtc2VyaWYiPk5vdGlmaWNhdGlvbnMgMi4wIHdp bGwgYmUgcGlja2VkIGJhY2sgdXAgYWZ0ZXIgdGhlIHZvdGUgcmVzdWx0IChpZiBjaGFydGVyIGNo YW5nZSBpcyBhY2NlcHRlZCkuPG86cD48L286cD48L3NwYW4+DQo8dWwgdHlwZT0iY2lyY2xlIj4N CjxsaSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsMiBsZXZlbDIg bGZvMTA7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5QZXJoYXBz IGEgdG9waWMgZm9yIG91dCBtZWV0aW5nIGluIHR3byB3ZWVrcy48bzpwPjwvbzpwPjwvc3Bhbj48 L2xpPjwvdWw+DQo8L2xpPjwvdWw+DQo8aDMgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDouMjVp bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206MTIuMHB0O21hcmdpbi1sZWZ0OjBpbjti YWNrZ3JvdW5kOndoaXRlO2JveC1zaXppbmc6IGJvcmRlci1ib3g7Zm9udC12YXJpYW50LWxpZ2F0 dXJlczogbm9ybWFsO2ZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7b3JwaGFuczogMjt0ZXh0LWFs aWduOnN0YXJ0O3dpZG93czogMjstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z cGFjaW5nOjBweCI+DQo8c3BhbiBzdHlsZT0iZm9udC1zaXplOjE1LjBwdDtmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMzMzMzMzMiPkZ1dHVyZXM6IFBv dGVudGlhbCBTdWJzY3JpcHRpb24gUGFyYW1ldGVyczxvOnA+PC9vOnA+PC9zcGFuPjwvaDM+DQo8 dWwgdHlwZT0iZGlzYyI+DQo8bGkgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMz MzM7bXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87bXNv LWxpc3Q6bDkgbGV2ZWwxIGxmbzExO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemluZzogYm9yZGVy LWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkmcXVvdDssc2Fu cy1zZXJpZiI+RG8gd2Ugd2FudCB0byBhZGQgJnF1b3Q7Y2hhbmdlcyBvbmx5JnF1b3Q7IG9wdGlv biBmb3IgcGVyaW9kaWMgc3Vic2NyaXB0aW9ucyBmb3IgdGhpcyBkcmFmdCwgcmF0aGVyIHRoYW4g YSBmdXR1cmVzPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdpbi1ib3R0b20tYWx0 OmF1dG87bXNvLWxpc3Q6bDkgbGV2ZWwxIGxmbzExO2JhY2tncm91bmQ6d2hpdGU7Ym94LXNpemlu ZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7U2Vnb2UgVUkm cXVvdDssc2Fucy1zZXJpZiI+U2VudGltZW50IGlzIGluLWZhdm9yLiBIb3dldmVyIHRoZXJlIGFy ZSBjb21wbGV4aXRpZXMgd2Ugc3RpbGwgbmVlZCB0byBhZGRyZXNzIGJlZm9yZSB3ZSBhZGQgdG8g dGhlIGRyYWZ0OjxvOnA+PC9vOnA+PC9zcGFuPg0KPG9sIHN0YXJ0PSIxIiB0eXBlPSJpIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDIgbGZv MTE7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5EbyB3ZSBzZW5k IHRoZSBmdWxsIHNjaGVtYSB0cmVlIGFsd2F5cyB3aXRoIG5vIGxlYWZzIGhhdmUgY2hhbmdlZCBh dCB0aGUgZW5kIG9mIHRoZSBwZXJpb2Q/PG86cD48L286cD48L3NwYW4+PC9saT48bGkgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9ImNvbG9yOiMzMzMzMzM7bWFyZ2luLXRvcDozLjBwdDttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDIgbGZvMTE7YmFja2dyb3VuZDp3 aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5EbyB3ZSBzZW5kIHBhdGNoIG1lY2hhbmlz bXMgb24gdGhlIHNjaGVtYSB0cmVlPzxvOnA+PC9vOnA+PC9zcGFuPjwvbGk+PGxpIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJjb2xvcjojMzMzMzMzO21hcmdpbi10b3A6My4wcHQ7bXNvLW1hcmdp bi1ib3R0b20tYWx0OmF1dG87bXNvLWxpc3Q6bDkgbGV2ZWwyIGxmbzExO2JhY2tncm91bmQ6d2hp dGU7Ym94LXNpemluZzogYm9yZGVyLWJveCI+DQo8c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7U2Vnb2UgVUkmcXVvdDssc2Fucy1zZXJpZiI+RG8gd2Ugd2FudCB0byBzZW5kIG51bGwgbm90 aWZpY2F0aW9uIHVwZGF0ZXMgaWYgbm90aGluZyBoYXMgY2hhbmdlZCBhY3Jvc3MgdGhlIGVudGly ZSBzdWJzY3JpcHRpb24/PG86cD48L286cD48L3NwYW4+DQo8dWwgdHlwZT0ic3F1YXJlIj4NCjxs aSBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0iY29sb3I6IzMzMzMzMzttc28tbWFyZ2luLXRvcC1h bHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0bzttc28tbGlzdDpsOSBsZXZlbDMgbGZv MTE7YmFja2dyb3VuZDp3aGl0ZTtib3gtc2l6aW5nOiBib3JkZXItYm94Ij4NCjxzcGFuIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtTZWdvZSBVSSZxdW90OyxzYW5zLXNlcmlmIj5JZiBudWxsIG5v dGlmaWNhdGlvbnMgYXJlIG5vdCBzZW50LCB0aGVuIHRoZSBiZWhhdmlvciB3aWxsIGJlIHF1aXRl IGNsb3NlIHRvIG9uLWNoYW5nZSBpbiB0ZXJtcyBvZiB0cmFuc2FjdGlvbiB2b2x1bWVzIGJldHdl ZW4gZGV2aWNlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2xpPjwvdWw+DQo8L2xpPjwvb2w+DQo8L2xp PjwvdWw+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_c816b6cc54b84984ada9a7ae3f8a35a3XCHRTP013ciscocom_-- From nobody Thu Jan 26 00:02:22 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8006C1294D1 for ; Thu, 26 Jan 2017 00:02:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.1 X-Spam-Level: X-Spam-Status: No, score=-5.1 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 CAn28UeuIqS5 for ; Thu, 26 Jan 2017 00:02:13 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 888221294C6 for ; Thu, 26 Jan 2017 00:02:13 -0800 (PST) Received: from localhost (unknown [173.38.220.36]) by mail.tail-f.com (Postfix) with ESMTPSA id 9E2FD1AE03D6; Thu, 26 Jan 2017 09:02:12 +0100 (CET) Date: Thu, 26 Jan 2017 09:02:10 +0100 (CET) Message-Id: <20170126.090210.1305302868536296710.mbj@tail-f.com> To: mersue@gmail.com From: Martin Bjorklund In-Reply-To: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Jan 2017 08:02:19 -0000 "Mehmet Ersue" wrote: > Dear NETCONF WG, > > > > looking at the feedback on the three options Eric Voit summarized in his > mail below but also related discussion on this topic, NETCONF co-chairs came > to the conclusion that option (iii) for updating/enhancing RFC5277 did not > get any proponents. On the other hand we see a huge support and attraction > for the new notification/subscription capabilities and extensions discussed > and provided by the Subscriptions and Events team. > > > > We think that the addition of new notification capabilities in concert with > the drafts from the Subscriptions and Events team provide rich features that > implementations will want to support in the future. The key features in > preparation are transport independence, multiple dynamic and/or configured > subscriptions in a transport session. > > > > The documents the Subscriptions and Events team are currently working on > are: > > - A document which defines the protocol-neutral notification framework, > i.e., explains the concepts of subscriptions, filters, control plane > notifications, replay, etc. And also defines the associated YANG data > model, RPCs, etc. This is currently covered in 5277bis document which would > need to be renamed. > > - A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), > > - A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG > notifications are encoded in XML and JSON > (draft-ietf-netconf-restconf-notif), > > - A document which defines the subscription and push mechanism for YANG > datastores allowing subscriber applications to request updates from a YANG > datastore (draft-ietf-netconf-yang-push). > > > > A) NETCONF co-chairs think that the Subscriptions and Events team should > continue its valuable work and propose to change our current charter to add > the development of notifications and subscription capabilities with the > listed documents and focus above as a starting point. WG members are asked > to state their opinion on the proposed plan. I think this is fine, but *if* this happens to coincide with a rfc6241bis document, I would be nice to move the contents of the second of these documents (i.e., how notifications are sent over NETCONF) into rfc6241bis. As has been stated before, bumping the protocol version to 1.2 would allow us to change the "notification" element contents. I also agree w/ Jurgen that the second and third documents should not contain the XML and JSON encoding of YANG-defined notifications. Thus, I assume that these two documents will be very short. > Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if you > have a strong objection to this plan and explain your concern with valid > arguments. Please also state clearly if you support this plan. > > > > B) NETCONF co-chairs further propose that NETCONF WG should use its energy > in the future to complete and improve the new notification and subscription > RFCs and stop maintaining RFC 5277 for issues other than errata. Note that > it is required that RFC 5277 and all new work needs to gracefully co-exist > in any deployment. > > Please state your opinion on the maillist by January 27, 2017 EOB PT, > whether you think RFC 5277 should be obsoleted during the publication of the > new draft set or not. I think 5277 should be obsoleted by these new drafts. /martin From nobody Tue Jan 31 13:01:06 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC27129A9D for ; Tue, 31 Jan 2017 13:01:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cAtP0TAlhSd1 for ; Tue, 31 Jan 2017 13:01:02 -0800 (PST) Received: from mail-wm0-x235.google.com (mail-wm0-x235.google.com [IPv6:2a00:1450:400c:c09::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D5B129596 for ; Tue, 31 Jan 2017 13:01:01 -0800 (PST) Received: by mail-wm0-x235.google.com with SMTP id c85so7115212wmi.1 for ; Tue, 31 Jan 2017 13:01:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:thread-index:content-language :disposition-notification-to; bh=HuI9fnfLlh9XamUDdNFHkRqm+eHRwDtIMDxhuLgKZrc=; b=JM9xN0F5auP78nJd9yLzg/FUgHx9FpfsAeV7npZA0GyP762ZZpVpVyr9RM3YNHXaBl S0VuZskHjVLrYSGlIWFo+CMk0dVvmHsySvvry8fF2bfYH0dUQh2Vk17zqxmMH3R5UDnJ 1M3cCOkxqPI7BRPBxGFTMQFh3azfceuM4AqiQsnBZckNuzoONAovKSQFAWBB3C8+jyOg iSsHCMHEeUcVJleND0jfceFNVuycc+8ZqCxiUv8GHHSLS5mTgfU0p8h29chlE9yCb7v1 itZIfRBoFgEJCPa01opTlwVw6Yl85+3TlP3/nBexddGgMSsnoKHy0fMX7VWuIWkdGYI/ NxeQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:thread-index:content-language :disposition-notification-to; bh=HuI9fnfLlh9XamUDdNFHkRqm+eHRwDtIMDxhuLgKZrc=; b=EGBJX2sLQLt0bkDpXTNlJWUrg0ejS7rvNYiyfhzmmyPPD1JYJ3qWKDI+mVF+GdY+Ly A9tEXIGicJYU8uhViaC5l2gH9yuFnTH8qahqcdtJ/n9ddikgLHwzAHTpyWfNL5K1Gp25 vkStK4yOP/0yK2BO2uulUhOlmMk+wWKZuZk4wA575P66H5xBWhTBBfHEsRG8FeJNSIq0 BHBPszlmcHEIxOBnmpVrh6PDoDHwetvttPsZGNCcnH8WD7GjlkUWzbhp2zI3Dt2h4nvF R+gcm4ZqyTVJbfHOoL3VQJlp0TqPd3nkwGSrb5mDKF6hIZeVvZTEIWJX2Sxi3oumL97B XrOA== X-Gm-Message-State: AIkVDXKXbVHFXL4pxnqtMfglrXXtmf0pm3f9XBRV1XsqbInVCgXe14z9EhEBw3TYZfKlTA== X-Received: by 10.223.142.208 with SMTP id q74mr25375759wrb.101.1485896460017; Tue, 31 Jan 2017 13:01:00 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341584.dip0.t-ipconnect.de. [91.52.21.132]) by smtp.gmail.com with ESMTPSA id p7sm30190573wrc.2.2017.01.31.13.00.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 13:00:59 -0800 (PST) From: "Mehmet Ersue" To: "'Martin Bjorklund'" References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170126.090210.1305302868536296710.mbj@tail-f.com> In-Reply-To: <20170126.090210.1305302868536296710.mbj@tail-f.com> Date: Tue, 31 Jan 2017 22:01:02 +0100 Message-ID: <028a01d27c05$2200bc80$66023580$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_028B_01D27C0D.83C99150" X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFS4MIRVdlex3JBc/CEOVVIhbfBQAKmZxwsoj0McbA= Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0205.5890FB0B.0014,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:01:05 -0000 This is a multipart message in MIME format. ------=_NextPart_000_028B_01D27C0D.83C99150 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Dear NETCONF WG, the WG seems to agree that we should continue the work the Subscriptions and Events team is doing and change the current charter to add the development of notifications and subscription capabilities. There is also support for obsoleting RFC 5277 during the publication of the new draft set. The co-chairs will provide a draft charter text for WG's review soon. That said, we need some discussion and a conclusion on the required document set. The original document set proposed was: a) A document which defines the protocol-neutral notification framework, i.e., explains the concepts of subscriptions, filters, control plane notifications, replay, etc. And also defines the associated YANG data model, RPCs, etc. This is currently covered in 5277bis document which would need to be renamed. b) A document which defines how notifications are sent over NETCONF (generalizing section 3.7 of RFC 5277) and how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), c) A document which defines how notifications are sent over RESTCONF (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG notifications are encoded in XML and JSON (draft-ietf-netconf-restconf-notif), d) A document which defines the subscription and push mechanism for YANG datastores allowing subscriber applications to request updates from a YANG datastore (draft-ietf-netconf-yang-push). This proposal was aiming to address the requirements Mahesh and I have read on NETCONF and NETMOD maillists and discussed with Eric: - Provide the protocol-neutral notification framework in a separate document. - Improve YANG specification RFC 7950 to be (as good as possible and required) protocol-independent and remove XML and JSON notification encoding sections for NETCONF. This was also the discussion result between NETCONF and NETMOD co-chairs. - Provide protocol-specific details e.g. how notifications are sent and the notification encodings in separate documents. This part could be for sure put into 6241bis and RESTCONF-bis. Though Eric and the co-chairs were favoring to have separate documents. That said I see Martin's comments below as valid. > > I think this is fine, but *if* this happens to coincide with a rfc6241bis document, I would be nice to move the contents of the second of these documents (i.e., > > how notifications are sent over NETCONF) into rfc6241bis. As has been stated before, bumping the protocol version to 1.2 would allow us to change the > > "notification" element contents. @All: Please comment on the documents a)-d) above. Especially on the questions: - whether the XML and JSON notification encoding sections should be removed from 7950 and put into NETCONF WG documents as well as - whether the documents b) and c) are good to separate or they should be put into 6241bis and RESTCONF-bis documents. Thanks. Best Regards, Mehmet -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com] Sent: Thursday, January 26, 2017 9:02 AM To: mersue@gmail.com Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure "Mehmet Ersue" < mersue@gmail.com> wrote: > Dear NETCONF WG, > > > > looking at the feedback on the three options Eric Voit summarized in > his mail below but also related discussion on this topic, NETCONF > co-chairs came to the conclusion that option (iii) for > updating/enhancing RFC5277 did not get any proponents. On the other > hand we see a huge support and attraction for the new > notification/subscription capabilities and extensions discussed and provided by the Subscriptions and Events team. > > > > We think that the addition of new notification capabilities in concert > with the drafts from the Subscriptions and Events team provide rich > features that implementations will want to support in the future. The > key features in preparation are transport independence, multiple dynamic and/or configured > subscriptions in a transport session. > > > > The documents the Subscriptions and Events team are currently working > on > are: > > - A document which defines the protocol-neutral notification > framework, i.e., explains the concepts of subscriptions, filters, > control plane notifications, replay, etc. And also defines the > associated YANG data model, RPCs, etc. This is currently covered in > 5277bis document which would need to be renamed. > > - A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > encoded in XML and JSON > (draft-ietf-netconf-netconf-event-notifications), > > - A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how > YANG notifications are encoded in XML and JSON > (draft-ietf-netconf-restconf-notif), > > - A document which defines the subscription and push mechanism for > YANG datastores allowing subscriber applications to request updates > from a YANG datastore (draft-ietf-netconf-yang-push). > > > > A) NETCONF co-chairs think that the Subscriptions and Events team > should continue its valuable work and propose to change our current > charter to add the development of notifications and subscription > capabilities with the listed documents and focus above as a starting > point. WG members are asked to state their opinion on the proposed plan. I think this is fine, but *if* this happens to coincide with a rfc6241bis document, I would be nice to move the contents of the second of these documents (i.e., how notifications are sent over NETCONF) into rfc6241bis. As has been stated before, bumping the protocol version to 1.2 would allow us to change the "notification" element contents. I also agree w/ Jurgen that the second and third documents should not contain the XML and JSON encoding of YANG-defined notifications. Thus, I assume that these two documents will be very short. > Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if > you have a strong objection to this plan and explain your concern with > valid arguments. Please also state clearly if you support this plan. > > > > B) NETCONF co-chairs further propose that NETCONF WG should use its > energy in the future to complete and improve the new notification and > subscription RFCs and stop maintaining RFC 5277 for issues other than > errata. Note that it is required that RFC 5277 and all new work needs > to gracefully co-exist in any deployment. > > Please state your opinion on the maillist by January 27, 2017 EOB PT, > whether you think RFC 5277 should be obsoleted during the publication > of the new draft set or not. I think 5277 should be obsoleted by these new drafts. /martin ------=_NextPart_000_028B_01D27C0D.83C99150 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear NETCONF = WG,

 

the WG seems to agree = that we should continue the work = the Subscriptions and Events team is doing and change the current = charter to add the development of notifications and subscription = capabilities. There is also support for obsoleting RFC 5277 during the = publication of the new draft set. The co-chairs will provide a draft = charter text for WG’s review soon.

 

That said, we need some = discussion and a conclusion on the required document = set.

The original document set proposed = was:

a) A document which defines the protocol-neutral = notification framework, i.e., explains the concepts of subscriptions, = filters, control plane notifications, replay, etc.  And also defines the associated YANG data model, = RPCs, etc. This is currently covered in 5277bis document which would = need to be renamed.

b) A document which defines how notifications = are sent over NETCONF (generalizing section 3.7 of RFC 5277) and how = YANG notifications are encoded in XML and JSON = (draft-ietf-netconf-netconf-event-notifications),

c) A document which = defines how notifications are sent over RESTCONF (generalizing section 6 = of RESTCONF RFC) and HTTP2.  = Also defines how YANG notifications are encoded in XML and JSON = (draft-ietf-netconf-restconf-notif),

d) A document which = defines the subscription and push mechanism for YANG datastores allowing = subscriber applications to request updates from a YANG datastore = (draft-ietf-netconf-yang-push).

 

This proposal was = aiming to address the requirements Mahesh and I have read on NETCONF and = NETMOD maillists and discussed with Eric:

- Provide the = protocol-neutral notification framework in a separate = document.

- Improve YANG specification RFC 7950 to be (as = good as possible and required) protocol-independent and remove XML and = JSON notification encoding sections for NETCONF. This was also the = discussion result between NETCONF and NETMOD = co-chairs.

- Provide protocol-specific details e.g. how = notifications are sent and the notification encodings in separate = documents. This part could be for sure put into 6241bis and = RESTCONF-bis. Though Eric and the co-chairs were favoring to have = separate documents.

 

That said I see Martin’s comments below as = valid.

> > I think = this is fine, but *if* this happens to coincide with a rfc6241bis = document, I would be nice to move the contents of the second of these = documents (i.e.,

> > how = notifications are sent over NETCONF) into rfc6241bis.  As has been = stated before, bumping the protocol version to 1.2 would allow us to = change the

> > = "notification" element contents.

 

@All: Please comment = on the documents a)-d) above. Especially on the = questions:

- whether the XML and JSON notification encoding = sections should be removed from 7950 and put into NETCONF WG documents = as well as

- whether the documents b) and c) are good to = separate or they should be put into 6241bis and RESTCONF-bis documents. =

Thanks.

 

Best Regards,

Mehmet

 

-----Original Message-----
From: Martin = Bjorklund [mailto:mbj@tail-f.com]
Sent: Thursday, January 26, 2017 = 9:02 AM
To: mersue@gmail.com
Cc: netconf@ietf.org
Subject: Re: = [Netconf] New Notification and Subscription Features WASFW: 3 Options = for Subscription & Event Notification draft structure

 

"Mehmet Ersue" <mersue@gmail.com> wrote:

> Dear NETCONF = WG,

>

> 

>

> = looking at the feedback on the three options Eric Voit summarized in =

> his mail below but also = related discussion on this topic, NETCONF

> co-chairs came to the conclusion that option = (iii) for

> updating/enhancing = RFC5277 did not get any proponents. On the other

> hand we see a huge support and attraction for = the new

> = notification/subscription capabilities and extensions discussed and = provided by the Subscriptions and Events team.

>

> 

>

> We = think that the addition of new notification capabilities in concert =

> with the drafts from the = Subscriptions and Events team provide rich

> features that implementations will want to = support in the future. The

> = key features in preparation are transport independence, multiple dynamic = and/or configured

> = subscriptions in a transport session.      =

>

> 

>

> = The documents the Subscriptions and Events team are currently working =

> on

> are:

>

> - = A document which defines the protocol-neutral notification =

> framework, i.e., explains = the concepts of subscriptions, filters,

> control plane notifications, replay, = etc.  And also defines the

> associated YANG data model, RPCs, etc. This is = currently covered in

> 5277bis = document which would need to be renamed.

>

> - = A document which defines how notifications are sent over NETCONF =

> (generalizing section 3.7 of = RFC 5277) and how YANG notifications are

> encoded in XML and JSON

> = (draft-ietf-netconf-netconf-event-notifications),

>

> - = A document which defines how notifications are sent over RESTCONF =

> (generalizing section 6 of = RESTCONF RFC) and HTTP2.  Also defines how

> YANG notifications are encoded in XML and JSON =

> = (draft-ietf-netconf-restconf-notif),

>

> - = A document which defines the subscription and push mechanism for =

> YANG datastores allowing = subscriber applications to request updates

> from a YANG datastore = (draft-ietf-netconf-yang-push).

>

> 

>

> A) = NETCONF co-chairs think that the Subscriptions and Events team =

> should continue its valuable = work and propose to change our current

> charter to add the development of = notifications and subscription

> capabilities with the listed documents and = focus above as a starting

> = point. WG members are asked to state their opinion on the proposed = plan.

 

I think this is fine, but *if* this happens to = coincide with a rfc6241bis document, I would be nice to move the = contents of the second of these documents (i.e., how notifications are = sent over

NETCONF) into = rfc6241bis.  As has been stated before, bumping the protocol = version to 1.2 would allow us to change the = "notification"

element = contents.

 

I also agree w/ Jurgen that the second and third = documents should not contain the XML and JSON encoding of YANG-defined = notifications.

Thus, I assume that = these two documents will be very short.

 

> = Please let us know on NETCONF maillist by January 27, 2017 EOB PT, if =

> you have a strong objection = to this plan and explain your concern with

> valid arguments. Please also state clearly if = you support this plan.

> =

> 

>

> B) = NETCONF co-chairs further propose that NETCONF WG should use its =

> energy in the future to = complete and improve the new notification and

> subscription RFCs and stop maintaining RFC = 5277 for issues other than

> = errata.  Note that it is required that RFC 5277 and all new work = needs

> to gracefully co-exist = in any deployment.

> =

> Please state your opinion on = the maillist by January 27, 2017 EOB PT,

> whether you think RFC 5277 should be obsoleted = during the publication

> of = the new draft set or not.

 

I = think 5277 should be obsoleted by these new drafts.

 

 

/martin

------=_NextPart_000_028B_01D27C0D.83C99150-- From nobody Tue Jan 31 13:16:23 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD4C129AD0 for ; Tue, 31 Jan 2017 13:16:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.399 X-Spam-Level: X-Spam-Status: No, score=-7.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199] autolearn=ham autolearn_force=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 C8yGnE-7qRnX for ; Tue, 31 Jan 2017 13:16:20 -0800 (PST) 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 DFC0E129ACD for ; Tue, 31 Jan 2017 13:16:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id B8BC574F; Tue, 31 Jan 2017 22:16:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id KCX0nL0qalRs; Tue, 31 Jan 2017 22:16:16 +0100 (CET) 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, 31 Jan 2017 22:16:18 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FD20200AC; Tue, 31 Jan 2017 22:16:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id b9kRtNKGyhRW; Tue, 31 Jan 2017 22:16:17 +0100 (CET) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 85A3D200AB; Tue, 31 Jan 2017 22:16:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id A9A493E60F0A; Tue, 31 Jan 2017 22:16:19 +0100 (CET) Date: Tue, 31 Jan 2017 22:16:19 +0100 From: Juergen Schoenwaelder To: Mehmet Ersue Message-ID: <20170131211619.GA78666@elstar.local> Mail-Followup-To: Mehmet Ersue , 'Martin Bjorklund' , netconf@ietf.org References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170126.090210.1305302868536296710.mbj@tail-f.com> <028a01d27c05$2200bc80$66023580$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <028a01d27c05$2200bc80$66023580$@gmail.com> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list Reply-To: Juergen Schoenwaelder List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 21:16:22 -0000 On Tue, Jan 31, 2017 at 10:01:02PM +0100, Mehmet Ersue wrote: > The original document set proposed was: > > a) A document which defines the protocol-neutral notification framework, > i.e., explains the concepts of subscriptions, filters, control plane > notifications, replay, etc. And also defines the associated YANG data > model, RPCs, etc. This is currently covered in 5277bis document which would > need to be renamed. > > b) A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > encoded in XML and JSON (draft-ietf-netconf-netconf-event-notifications), > > c) A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how YANG > notifications are encoded in XML and JSON > (draft-ietf-netconf-restconf-notif), > > d) A document which defines the subscription and push mechanism for YANG > datastores allowing subscriber applications to request updates from a YANG > datastore (draft-ietf-netconf-yang-push). > > > > This proposal was aiming to address the requirements Mahesh and I have read > on NETCONF and NETMOD maillists and discussed with Eric: > > - Provide the protocol-neutral notification framework in a separate > document. > > - Improve YANG specification RFC 7950 to be (as good as possible and > required) protocol-independent and remove XML and JSON notification encoding > sections for NETCONF. This was also the discussion result between NETCONF > and NETMOD co-chairs. > > - Provide protocol-specific details e.g. how notifications are sent and the > notification encodings in separate documents. This part could be for sure > put into 6241bis and RESTCONF-bis. Though Eric and the co-chairs were > favoring to have separate documents. > > > > That said I see Martin's comments below as valid. > > > > I think this is fine, but *if* this happens to coincide with a > rfc6241bis document, I would be nice to move the contents of the second of > these documents (i.e., > > > > how notifications are sent over NETCONF) into rfc6241bis. As has been > stated before, bumping the protocol version to 1.2 would allow us to change > the > > > > "notification" element contents. > > > > @All: Please comment on the documents a)-d) above. Especially on the > questions: > > - whether the XML and JSON notification encoding sections should be removed > from 7950 and put into NETCONF WG documents as well as > > - whether the documents b) and c) are good to separate or they should be put > into 6241bis and RESTCONF-bis documents. > Since when has RFC 7950 JSON notification encoding sections? This email is confusing on multiple ends. /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 Jan 31 14:18:10 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F41A129B9A for ; Tue, 31 Jan 2017 14:18:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 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, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vS8i-DEHNRCH for ; Tue, 31 Jan 2017 14:18:07 -0800 (PST) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 77615129618 for ; Tue, 31 Jan 2017 14:18:07 -0800 (PST) Received: by mail-wm0-x229.google.com with SMTP id c85so10117293wmi.1 for ; Tue, 31 Jan 2017 14:18:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=CvR9OdDQwCuEsVI0hLmvcRMtWm0E5RF2uCJxiwLQccg=; b=XCWdeiNXekdgitgiTgyU6yibtJ+jBmasFYQeFXlYyAk3k6BlNVetbepnY3ocxDs4FI I+oex2+W27eBtqazIsnSkzw+hUDC5ppOdtcokhPbs8Ldw+Jx3qamup6hDqaIbv3rSTBN sDHzama/vyrPs6znPHZ8i8NAsZvrJJrI8LmIbwN6XqQFlN7zy0tPE15wB9UgfefDFqA2 ds9PwgjCZnPm/xYsuX4qYA3j4Jeqxj8p83AmgvGUargY2ZLZfAu0t6qwmwVvyLYJEqil khCbqySb46NHQ2HpG0cl39IaemqZdpglloatwwucAPQnQhkyCPlzX3fwZwnw+zwuFPam POhQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language:disposition-notification-to; bh=CvR9OdDQwCuEsVI0hLmvcRMtWm0E5RF2uCJxiwLQccg=; b=gqwbDL+E0HhXE2LKoY29cQeM+TMkHhpVTa2c4ggf0CCyOMg2SZ9FpTgyBHQIWTd2WS t8qu4BuXZNNCDlJA4koZvHY2F206tFG1xZMSYkrQUyCVLXlOHyZuvTQhE1D9pCtOs4rY pyTTUx7MS4w2buZRE4pP2OOhSIxLI5oJuCgfo6xUu3dZMmZMV0qK4GYxnmRDadRCwXi8 8v0UOfi5NA071yKbBYo7GRSMOFWfi86pYjauOJlVg7cxFNAcsnJTYH/Lpl1uFaQUtmLD KQ42lZsfdT1Hx47xa717maLuaeR8+CYPcGX69+3lYu+PSZj+d6dxx45+n9UK3RyrOJ4J XcIg== X-Gm-Message-State: AIkVDXIZ19P2/IT9Ygdh53U2gCDYIy4340wvryajRCfv+hclCjPmrZpT7YvvJwahbxt5tQ== X-Received: by 10.28.185.77 with SMTP id j74mr101390wmf.76.1485901085827; Tue, 31 Jan 2017 14:18:05 -0800 (PST) Received: from DESKTOPFLHJVQJ (p5B341584.dip0.t-ipconnect.de. [91.52.21.132]) by smtp.gmail.com with ESMTPSA id 8sm34747476wmg.1.2017.01.31.14.18.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 31 Jan 2017 14:18:05 -0800 (PST) From: "Mehmet Ersue" To: "'Juergen Schoenwaelder'" References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170126.090210.1305302868536296710.mbj@tail-f.com> <028a01d27c05$2200bc80$66023580$@gmail.com> <20170131211619.GA78666@elstar.local> In-Reply-To: <20170131211619.GA78666@elstar.local> Date: Tue, 31 Jan 2017 23:18:07 +0100 Message-ID: <02c701d27c0f$e6be23a0$b43a6ae0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 16.0 Thread-Index: AQFS4MIRVdlex3JBc/CEOVVIhbfBQAKmZxwsArU7t7sCIa3ekqIWcwKA Content-Language: de X-AVK-Virus-Check: AVA 25.10096;BF82DA0 X-AVK-Spam-Check: 1; str=0001.0A0C0203.58910D1D.0018,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0; AE713 Archived-At: Cc: netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:18:09 -0000 Thanks. It should read: @All: Please comment on the documents a)-d) below. Especially on the questions: - whether the XML notification encoding section should be removed from 7950 and put into NETCONF WG documents as well as - whether the documents b) and c) are good to separate or the protocol-specific content should be put into 6241bis and RESTCONF-bis documents. Mehmet -----Original Message----- From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] Sent: Tuesday, January 31, 2017 10:16 PM To: Mehmet Ersue Cc: 'Martin Bjorklund' ; netconf@ietf.org Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure On Tue, Jan 31, 2017 at 10:01:02PM +0100, Mehmet Ersue wrote: > The original document set proposed was: > > a) A document which defines the protocol-neutral notification > framework, i.e., explains the concepts of subscriptions, filters, > control plane notifications, replay, etc. And also defines the > associated YANG data model, RPCs, etc. This is currently covered in > 5277bis document which would need to be renamed. > > b) A document which defines how notifications are sent over NETCONF > (generalizing section 3.7 of RFC 5277) and how YANG notifications are > encoded in XML and JSON > (draft-ietf-netconf-netconf-event-notifications), > > c) A document which defines how notifications are sent over RESTCONF > (generalizing section 6 of RESTCONF RFC) and HTTP2. Also defines how > YANG notifications are encoded in XML and JSON > (draft-ietf-netconf-restconf-notif), > > d) A document which defines the subscription and push mechanism for > YANG datastores allowing subscriber applications to request updates > from a YANG datastore (draft-ietf-netconf-yang-push). > > > > This proposal was aiming to address the requirements Mahesh and I have > read on NETCONF and NETMOD maillists and discussed with Eric: > > - Provide the protocol-neutral notification framework in a separate > document. > > - Improve YANG specification RFC 7950 to be (as good as possible and > required) protocol-independent and remove XML and JSON notification > encoding sections for NETCONF. This was also the discussion result > between NETCONF and NETMOD co-chairs. > > - Provide protocol-specific details e.g. how notifications are sent > and the notification encodings in separate documents. This part could > be for sure put into 6241bis and RESTCONF-bis. Though Eric and the > co-chairs were favoring to have separate documents. > > > > That said I see Martin's comments below as valid. > > > > I think this is fine, but *if* this happens to coincide with a > rfc6241bis document, I would be nice to move the contents of the > second of these documents (i.e., > > > > how notifications are sent over NETCONF) into rfc6241bis. As has > > > been > stated before, bumping the protocol version to 1.2 would allow us to > change the > > > > "notification" element contents. > > > > @All: Please comment on the documents a)-d) above. Especially on the > questions: > > - whether the XML and JSON notification encoding sections should be > removed from 7950 and put into NETCONF WG documents as well as > > - whether the documents b) and c) are good to separate or they should > be put into 6241bis and RESTCONF-bis documents. > Since when has RFC 7950 JSON notification encoding sections? This email is confusing on multiple ends. /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 Jan 31 14:20:30 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 545D41299A7 for ; Tue, 31 Jan 2017 14:20:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.058 X-Spam-Level: X-Spam-Status: No, score=-3.058 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-1.156, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Fb-6J0th1cd for ; Tue, 31 Jan 2017 14:20:27 -0800 (PST) Received: from NAM02-BL2-obe.outbound.protection.outlook.com (mail-bl2nam02on0097.outbound.protection.outlook.com [104.47.38.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86AA112962B for ; Tue, 31 Jan 2017 14:20:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4oM5jH8p3CTZI+f5WrjTWNDHDA2IvcHKGIFfRBpVy5Y=; b=WLqQ3UM+lq4VYr75sGLQzdMl0vmvunYNtfCcrnv554NpojCbqErue9IFm2NJEo7E+59GfsjS719d1qUGUmxhqycwXPnbPrWAC1ww+C2WmdsIWfVqPUK4QOw5xqGLVFRKT7/np/mdlBRqfp4GmX79uwpg6iRoCRu87PSkbU/UoE0= Received: from BN3PR0501MB1442.namprd05.prod.outlook.com (10.160.117.151) by BN3PR0501MB1443.namprd05.prod.outlook.com (10.160.117.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.874.6; Tue, 31 Jan 2017 22:20:24 +0000 Received: from BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) by BN3PR0501MB1442.namprd05.prod.outlook.com ([10.160.117.151]) with mapi id 15.01.0874.020; Tue, 31 Jan 2017 22:20:23 +0000 From: Kent Watsen To: Juergen Schoenwaelder , Mehmet Ersue Thread-Topic: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure Thread-Index: AdJxFT6mLH0VYlYKQ0KNB3RPNzgbhAGlT/8AARaooQAAAIikgP//vhSA Date: Tue, 31 Jan 2017 22:20:23 +0000 Message-ID: <7B81B250-3246-44AF-B9E4-D24E8D2FB4DA@juniper.net> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170126.090210.1305302868536296710.mbj@tail-f.com> <028a01d27c05$2200bc80$66023580$@gmail.com> <20170131211619.GA78666@elstar.local> In-Reply-To: <20170131211619.GA78666@elstar.local> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.1e.0.170107 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.14] x-ms-office365-filtering-correlation-id: f4e757e7-2885-44ad-d4d6-08d44a2759eb x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401079); SRVR:BN3PR0501MB1443; x-microsoft-exchange-diagnostics: 1; BN3PR0501MB1443; 7:eQ2ajR2M73TMIQ18velVFoZRZB56c3g+hR/X86GBYF0MreTV+DHJ8xzQt5wXCxrG0IMfvTs6OCFgTMNwMEoVngZqbndmYkeYAjESekY6i6YJ3swq911wuN5Y3/19JFMLswoMy/gsa0u8nCw8qLdsTY3eQkJkJ9VZOsZGpLDTJz6Q/bE9F3G5SoPjeqZlmFNFDM4JkRK84P4ti55QF2Oc2RRnhI4Yf+qekwnBatuPGtK9jYG8gXRV+cJJ1MFAl1AWp7SHnT0M55Y/TkHQFSCimkkiRYWg7OWqixhx64X5y/2eKOrJcjy4FXEow1CGtDBYbJNO6ezuWeZF9xLPd3tglSyUDjqiNW99PaoS2/OKwRYQ48rv4e5M9pmE8udiT5nSFb4Ant6EoKAgesYMIWJgNW8ZHRhrLqLyiIQ/1iXV0q2g9q7mKWShbe0dd2vpuC3aeqfa3fORxQOhCyydu8tPvMzWfEWmPXaai7ER5lxv08HZgln5Rq1PZBgGHwzXewpDsloAtCYuGsRD/1vRPl3Sk8kVcs37YDOekX/z3+JkbigyWopCTyiQjIG9YzHxhumJ x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040375)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026)(6041248)(20161123564025)(20161123562025)(20161123560025)(20161123555025)(6072148); SRVR:BN3PR0501MB1443; BCL:0; PCL:0; RULEID:; SRVR:BN3PR0501MB1443; x-forefront-prvs: 0204F0BDE2 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(39860400002)(39840400002)(39850400002)(39410400002)(39450400003)(199003)(189002)(33656002)(99286003)(122556002)(25786008)(93886004)(4326007)(5001770100001)(97736004)(5660300001)(102836003)(6116002)(3846002)(4001350100001)(6436002)(39060400001)(2906002)(6506006)(101416001)(66066001)(189998001)(2950100002)(3280700002)(76176999)(38730400001)(77096006)(6486002)(68736007)(54356999)(92566002)(7736002)(8676002)(53936002)(83716003)(86362001)(81156014)(3660700001)(305945005)(50986999)(82746002)(81166006)(36756003)(6512007)(83506001)(8936002)(106356001)(15650500001)(229853002)(105586002)(2900100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:BN3PR0501MB1443; H:BN3PR0501MB1442.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <782F65E31B688E48A963CB08C61D055D@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Jan 2017 22:20:23.6546 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3PR0501MB1443 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:20:29 -0000 DQo+IFNpbmNlIHdoZW4gaGFzIFJGQyA3OTUwIEpTT04gbm90aWZpY2F0aW9uIGVuY29kaW5nIHNl Y3Rpb25zPyBUaGlzDQo+IGVtYWlsIGlzIGNvbmZ1c2luZyBvbiBtdWx0aXBsZSBlbmRzLg0KDQpU cnVlLCBSRkMgNzk1MCBkb2Vzbid0IGhhdmUgYW55IEpTT04gZW5jb2Rpbmcgc2VjdGlvbnMsIHNv IHRoZXJlIGlzIG5vdGhpbmcgdG8gYmUgZG9uZSBvbiB0aGF0IGZyb250LiAgIEFsc28sIHdoaWxl IEkgYWdyZWUgdGhhdCB0aGUgWE1MIGVuY29kaW5nIHNlY3Rpb25zIHNob3VsZCBiZSBtb3ZlIG91 dCBvZiBSRkMgNzk1MCwgSSB2aWV3IHRoaXMgcHVyZWx5IGFzIGEgTkVUTU9EIFdHIGFjdGl2aXR5 IChub3QgYSBORVRDT05GIFdHIGFjdGl2aXR5KSBhbmQgaGVuY2UgZG9lc24ndCBuZWVkIHRvIGJl IGRpc2N1c3NlZCBoZXJlLg0KDQpXaGF0IEkgdGhpbmsgc2hvdWxkIGJlIGRpc2N1c3NlZCBoZXJl IGlzIG1vdmluZyBhbGwgdGhlIE5FVENPTkYtaXNtcyBpbiBSRkMgNzk1MCB0byB0aGUgTkVUQ09O RiBXRyBpbmNsdWRpbmcsIGJ1dCBub3QgbGltaXRlZCB0bywgYWxsIHRoZSBORVRDT05GIFhNTCBF bmNvZGluZyBSdWxlcyBzZWN0aW9ucy4gIA0KDQpSRkMgNzk1MCBhbHNvIGNvbnRhaW5zIGEgbGFy Z2UgbnVtYmVyIG9mIE5FVENPTkYgdXNhZ2UgZXhhbXBsZXMuICBJIHRoaW5rIHRoZSBORVRNT0Qg V0cgbmVlZHMgdG8gZGlzY3VzcyBpZiB0aGVzZSBzaG91bGQgdG8gYmUgbW92ZWQgdG8gdGhlIE5F VENPTkYgV0cgYWxzbywgb3IgaWYgaXQncyB0aGUgYmV0dGVyIHRvIGNvbnZlcnQgaGFsZiB0aGUg ZXhhbXBsZXMgdG8gUkVTVENPTkYgc28gUkZDIDc1OTAgc2hvd3MgaW1wYXJ0aWFsaXR5LiAgVGhv dWdoIHRoaXMgaXMgYSBORVRNT0QgaXNzdWUgdG8gZGlzY3VzcywgaXQgY2xlYXJseSBtaWdodCBp bXBhY3QgTkVUQ09ORiwgaGVuY2Ugd2h5IEknbSBtZW50aW9uaW5nIGl0IGhlcmUgbm93Lg0KDQpT ZXBhcmF0ZWx5LCBpbiBhZGRpdGlvbiB0byBtb3ZpbmcgbWF0ZXJpYWwgZnJvbSBORVRNT0QgZHJh ZnRzIHRvIE5FVENPTkYgZHJhZnRzLCBJIHRoaW5rIHRoZXJlIHNob3VsZCBiZSBhIGRpc2N1c3Np b24gYWJvdXQgbW92aW5nIG1hdGVyaWFsIHRoZSBvdGhlciBkaXJlY3Rpb24gYXMgd2VsbC4gIEZv ciBpbnN0YW5jZSwgSSB0aGluayB0aGVzZSB0ZXJtcyBkZWZpbmVkIGluIFJGQyA2MjQxIG1pZ2h0 IGJlIGJldHRlciBwbGFjZWQgaW4gdGhlIGRhdGFzdG9yZXMgZHJhZnQ6DQoNCiAgbyBjb25maWd1 cmF0aW9uIGRhdGENCiAgbyBjb25maWd1cmF0aW9uIGRhdGFzdG9yZQ0KICBvIGRhdGFzdG9yZQ0K ICBvIHN0YXRlIGRhdGENCg0KDQpUaG91Z2h0cz8NCg0KS2VudCAvLyBhIE5FVENPTkYgY29udHJp YnV0b3INCg0KDQoNCg0K From nobody Tue Jan 31 14:27:53 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 300E8129BED for ; Tue, 31 Jan 2017 14:27:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XIHwHfJmXXW0 for ; Tue, 31 Jan 2017 14:27:50 -0800 (PST) Received: from mail-qk0-x22d.google.com (mail-qk0-x22d.google.com [IPv6:2607:f8b0:400d:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E83D129BD9 for ; Tue, 31 Jan 2017 14:27:50 -0800 (PST) Received: by mail-qk0-x22d.google.com with SMTP id s140so180999916qke.0 for ; Tue, 31 Jan 2017 14:27:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=tR4S5m6U7Grrp80VaYHA57FHf9a562G83uFwfPArRJ8=; b=1tSr0w/jUrBZB1G0zPw/AOgyXj3T3MGbebn9mE3/oaVjJwAU1Msob3HfqMad0CHZH1 xkJGQKdQUpyDiUVjjMNY7W4cOt0OGMwcWbY5L2nfRirJs6KDkPJAdwIsyWhVJgDD0qfD s1w2ys6RZvmuDUEc5a+PuFQ5L+lyK7XwIPyA4t6G/bhpaXQWX1KI4lkWJrFhenada9vh RWAcjHyGLdqlncOAwHR2oKdjk3PwXjM/fqRJEGOPIywE/w5KoemxBHCmnOPy9/zPvy/y 2LWKZtsWQduzgPavDasdnl98qU7Pn8bWzMkr2mM+Fpqns6xGD6JDG0/Y4hnv7mm6FK0j I1GQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=tR4S5m6U7Grrp80VaYHA57FHf9a562G83uFwfPArRJ8=; b=UQbkg3vWic6tPFrQ7gc6saskvZWEeCpkaUJ0dmr8W0zrDFmrEI0fUqE7aawY9Z9qfk I8u31/b8MhF4IwCNu6Bsq2KHqBZVN1imXckKNrCLEUPElT4H3sp1ZSkdX3SGCKIypAd7 n0BEjJg0zJZvQOmQ1xecPqYpfIjUY9Al2h/FL45c6fIaFYOnLY3IOp1DvNTr0iqFfaYv f2Emi5BzyyQXS3P9NAokzUJyuBfFANTvH86fRLtwsH8bszrsLG/a7YDdYIsnheA8lgED 31wwqUd5xDQn2VyNVMq1mGMstY1HOBz5ANZBhm7A0nHERGZCSZ0/TOoOl/09jllvNOrL tGeQ== X-Gm-Message-State: AIkVDXIKjTRjX6C0EfJpuvKWx6w8q+3XedIZzX/ZGnUFhhO15DNmdC2qKNCMGnZGcw94cJi3hk7G4J5p54TUSw== X-Received: by 10.55.21.133 with SMTP id 5mr14474059qkv.71.1485901669434; Tue, 31 Jan 2017 14:27:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 31 Jan 2017 14:27:48 -0800 (PST) In-Reply-To: <7B81B250-3246-44AF-B9E4-D24E8D2FB4DA@juniper.net> References: <03b801d27116$4df5a890$e9e0f9b0$@gmail.com> <20170126.090210.1305302868536296710.mbj@tail-f.com> <028a01d27c05$2200bc80$66023580$@gmail.com> <20170131211619.GA78666@elstar.local> <7B81B250-3246-44AF-B9E4-D24E8D2FB4DA@juniper.net> From: Andy Bierman Date: Tue, 31 Jan 2017 14:27:48 -0800 Message-ID: To: Kent Watsen Content-Type: multipart/alternative; boundary=001a1147eec02da5d605476b71c0 Archived-At: Cc: "netconf@ietf.org" Subject: Re: [Netconf] New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:27:52 -0000 --001a1147eec02da5d605476b71c0 Content-Type: text/plain; charset=UTF-8 Hi, I am not in favor of refactoring RFCs just to move content around. If/when NETCONF 1.2 gets done, then the NETCONF bits in RFC 7950 should get moved to that document. The NETCONF specific text is unfortunate, but not causing harm to interoperability. On Tue, Jan 31, 2017 at 2:20 PM, Kent Watsen wrote: > > > Since when has RFC 7950 JSON notification encoding sections? This > > email is confusing on multiple ends. > > True, RFC 7950 doesn't have any JSON encoding sections, so there is > nothing to be done on that front. Also, while I agree that the XML > encoding sections should be move out of RFC 7950, I view this purely as a > NETMOD WG activity (not a NETCONF WG activity) and hence doesn't need to be > discussed here. > > What I think should be discussed here is moving all the NETCONF-isms in > RFC 7950 to the NETCONF WG including, but not limited to, all the NETCONF > XML Encoding Rules sections. > > RFC 7950 also contains a large number of NETCONF usage examples. I think > the NETMOD WG needs to discuss if these should to be moved to the NETCONF > WG also, or if it's the better to convert half the examples to RESTCONF so > RFC 7590 shows impartiality. Though this is a NETMOD issue to discuss, it > clearly might impact NETCONF, hence why I'm mentioning it here now. > > Separately, in addition to moving material from NETMOD drafts to NETCONF > drafts, I think there should be a discussion about moving material the > other direction as well. For instance, I think these terms defined in RFC > 6241 might be better placed in the datastores draft: > > o configuration data > o configuration datastore > o datastore > o state data > > > Thoughts? > > Kent // a NETCONF contributor > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a1147eec02da5d605476b71c0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I am not in favor of refactoring RF= Cs just to move content around.
If/when NETCONF 1.2 gets done, th= en the NETCONF bits in RFC 7950 should
get moved to that document= . The NETCONF specific text is unfortunate,
but not causing harm = to interoperability. =C2=A0





On Tue, Jan 31, 2017 at 2:20 PM, Kent Watsen <<= a href=3D"mailto:kwatsen@juniper.net" target=3D"_blank">kwatsen@juniper.net= > wrote:

> Since when has RFC 7950 JSON notification encoding sections? This
> email is confusing on multiple ends.

True, RFC 7950 doesn't have any JSON encoding sections, so there is not= hing to be done on that front.=C2=A0 =C2=A0Also, while I agree that the XML= encoding sections should be move out of RFC 7950, I view this purely as a = NETMOD WG activity (not a NETCONF WG activity) and hence doesn't need t= o be discussed here.

What I think should be discussed here is moving all the NETCONF-isms in RFC= 7950 to the NETCONF WG including, but not limited to, all the NETCONF XML = Encoding Rules sections.

RFC 7950 also contains a large number of NETCONF usage examples.=C2=A0 I th= ink the NETMOD WG needs to discuss if these should to be moved to the NETCO= NF WG also, or if it's the better to convert half the examples to RESTC= ONF so RFC 7590 shows impartiality.=C2=A0 Though this is a NETMOD issue to = discuss, it clearly might impact NETCONF, hence why I'm mentioning it h= ere now.

Separately, in addition to moving material from NETMOD drafts to NETCONF dr= afts, I think there should be a discussion about moving material the other = direction as well.=C2=A0 For instance, I think these terms defined in RFC 6= 241 might be better placed in the datastores draft:

=C2=A0 o configuration data
=C2=A0 o configuration datastore
=C2=A0 o datastore
=C2=A0 o state data


Thoughts?

Kent // a NETCONF contributor




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

--001a1147eec02da5d605476b71c0-- From nobody Tue Jan 31 14:55:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 351DD12A016 for ; Tue, 31 Jan 2017 14:55:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.419 X-Spam-Level: X-Spam-Status: No, score=-7.419 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-3.199, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 BqfLkj7I0Hmh for ; Tue, 31 Jan 2017 14:54:59 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 491B5129BDE for ; Tue, 31 Jan 2017 14:54:58 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CZU59768; Tue, 31 Jan 2017 22:54:55 +0000 (GMT) Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml707-cah.china.huawei.com (10.201.5.199) with Microsoft SMTP Server (TLS) id 14.3.301.0; Tue, 31 Jan 2017 22:54:54 +0000 Received: from SJCEML703-CHM.china.huawei.com ([169.254.5.69]) by SJCEML702-CHM.china.huawei.com ([169.254.4.133]) with mapi id 14.03.0235.001; Tue, 31 Jan 2017 14:54:47 -0800 From: Alexander Clemm To: Andy Bierman , Mehmet Ersue Thread-Topic: YACM? (RE: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft) Thread-Index: AdJ8FJvmcDpHrd8AS+q8fGd7IJMaVQ== Date: Tue, 31 Jan 2017 22:54:45 +0000 Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43A@SJCEML703-CHM.china.huawei.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.213.48.145] Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43ASJCEML703CHMchi_" MIME-Version: 1.0 X-CFilter-Loop: Reflected X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A090203.589115C0.0050, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.5.69, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32 X-Mirapoint-Loop-Id: 0fa61cb2f5dfed1ed954846187d66b03 Archived-At: Cc: Netconf Subject: [Netconf] YACM? (RE: WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 22:55:03 -0000 --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43ASJCEML703CHMchi_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgQW5keSwgYW5kIFdvcmtpbmcgR3JvdXAsDQoNCkxvb2tpbmcgYXQgdGhlIDY1MzZiaXMgZHJh ZnQsIG9uZSBjb21tZW50IEkgaGF2ZSBpcyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciB0byBkZWVt cGhhc2l6ZSB0aGUgc3BlY2lmaWMgcHJvdG9jb2xzIHVzZWQgdG8gYWNjZXNzIHRoZSBZQU5HLWRl ZmluZWQgZGF0YS4gIFJhdGhlciwgSSB0aGluayB0aGUgQWNjZXNzIENvbnRyb2wgTW9kZWwgc2hv dWxkIGJlIGRlZmluZWQgaW4gdGVybXMgb2YgdGhlIGRhdGEgdGhhdCBpcyBiZWluZyBhY2Nlc3Nl ZCwgYW5kIHRoZSBvcGVyYXRpb25zIHRoYXQgY2xpZW50cyBhcmUgYXV0aG9yaXplZCB0byBjYXJy eSBvdXQgYWdhaW5zdCB0aGF0IGRhdGEuICBJbiBhZGRpdGlvbiwgdGhlcmUgbWF5IGJlIGltcGxp Y2F0aW9ucyB0byBiZSBkaXNjdXNzZWQgZnJvbSB0aGUgcmV2aXNlZCBkYXRhc3RvcmVzIGRyYWZ0 LiAgUmVhbGx5LCB0aGlzIHNob3VsZCBiZSBhYm91dCBkZWZpbmluZyBhbiBBY2Nlc3MgQ29udHJv bCBNb2RlbCBmb3Igb3BlcmF0aW9ucyBjYXJyaWVkIG91dCBhZ2FpbnN0IGEgWUFORyBkYXRhc3Rv cmUsIGluZGVwZW5kZW50IG9mIHRoZSBzcGVjaWZpYyBwcm90b2NvbCB1c2VkIGZvciB0aG9zZSBv cGVyYXRpb25zLg0KDQpJIGJlbGlldmUgb25lIG9mIHRoZSBpbnRlbnRpb25zIGJlaGluZCB0aGUg ZHJhZnQgaXMgdG8gbWFrZSBpdCBsZXNzIE5ldGNvbmYtZGVwZW5kZW50LCBidXQganVzdCBleHRl bmRpbmcgaXQgdG8gUmVzdGNvbmYgbWF5IG5vdCBiZSBlbm91Z2gg4oCTIHRoZXJlIG1heSBiZSBv dGhlciB0cmFuc3BvcnRzL21lY2hhbmlzbXMgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGFjY2VzcyBZ QU5HLWRlZmluZWQgZGF0YSBhbmQgZGF0YXN0b3JlcyBhbmQgTkFDTSBzaG91bGQgYXBwbHkgdGhl cmUgYXMgd2VsbC4gIEl0IGlzIGZpbmUgdG8gZXhwbGFpbiBob3cgTkFDTSB3aWxsIGJlIGFwcGxp ZWQgaW4gdGhlIHBhcnRpY3VsYXIgaW5zdGFuY2VzIG9mIFJlc3Rjb25mIGFuZCBOZXRjb25mLCBi dXQgc3RpbGwgcG9pbnQgb3V0IHRoYXQgYWNjZXNzIG1ldGhvZCBpbmRlcGVuZGVuY2UuDQoNCkZv ciBleGFtcGxlLCB0aGUgYWJzdHJhY3Qgc3RhdGVzOg0KVGhlcmUgaXMgYSBuZWVkDQogICBmb3Ig c3RhbmRhcmQgbWVjaGFuaXNtcyB0byByZXN0cmljdCBORVRDT05GIG9yIFJFU1RDT05GIHByb3Rv Y29sDQogICBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNlcnMgdG8gYSBwcmUtY29uZmlndXJlZCBz dWJzZXQgb2YgYWxsDQogICBhdmFpbGFibGUgTkVUQ09ORiBvciBSRVNUQ09ORiBwcm90b2NvbCBv cGVyYXRpb25zIGFuZCBjb250ZW50LiAgVGhpcw0KICAgZG9jdW1lbnQgZGVmaW5lcyBzdWNoIGFu IGFjY2VzcyBjb250cm9sIG1vZGVsLg0KDQpJIHRoaW5rIHRoaXMgbWlnaHQgYmUgYmV0dGVyIHJl cGhyYXNlZCBzb21ldGhpbmcgbGlrZQ0KICAgVGhlcmUgaXMgYSBuZWVkDQogICBmb3Igc3RhbmRh cmQgbWVjaGFuaXNtcyB0byByZXN0cmljdCBhY2Nlc3MgZm9yIHBhcnRpY3VsYXIgdXNlcnMgdG8g YSBwcmUtY29uZmlndXJlZCBzdWJzZXQgb2YgYWxsDQogICBhdmFpbGFibGUgY29udGVudCBpbiBZ QU5HIGRhdGFzdG9yZXMgYW5kIGF2YWlsYWJsZSBvcGVyYXRpb25zLCBhY2Nlc3NlZCB2aWEgbWVj aGFuaXNtcyB0aGF0IGluY2x1ZGUNCiAgWUFORyBORVRDT05GIG9yIFJFU1RDT05GIHByb3RvY29s IG9wZXJhdGlvbnMuICBUaGlzDQogICBkb2N1bWVudCBkZWZpbmVzIHN1Y2ggYW4gYWNjZXNzIGNv bnRyb2wgbW9kZWwuDQoNClBlcmhhcHMgTkFDTSBzaG91bGQgcmVhbGx5IGJlIHJlbmFtZWQgdG8g WUFDTTstKSAgSSBrbm93LCB0aGUgZHJhZnQgaXMgaW4gdGhlIE5ldGNvbmYgV0csIG5vdCBOZXRt b2QsIHNvIHdoeSBzaG91bGQgaXQgbm90IGJlIHNwZWNpZmljIHRvIE5ldGNvbmYgYW5kIFJlc3Rj b25mLCBidXQgc3RpbGzigKYNCg0KQ2hlZXJzDQotLS0gQWxleA0KDQoNCkZyb206IE5ldGNvbmYg W21haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBBbmR5IEJpZXJt YW4NClNlbnQ6IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDE3IDEwOjI3IEFNDQpUbzogTWVobWV0 IEVyc3VlIDxtZXJzdWVAZ21haWwuY29tPg0KQ2M6IE5ldGNvbmYgPG5ldGNvbmZAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW05ldGNvbmZdIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRyYWZ0LWJpZXJt YW4tbmV0Y29uZi1yZmM2NTM2YmlzIFdBUzpGVzogbmV3IE5BQ00gZHJhZnQNCg0KDQoNCk9uIFdl ZCwgSmFuIDQsIDIwMTcgYXQgODozMCBBTSwgTWVobWV0IEVyc3VlIDxtZXJzdWVAZ21haWwuY29t PG1haWx0bzptZXJzdWVAZ21haWwuY29tPj4gd3JvdGU6DQpEZWFyIEFsbCwNCg0Kd2UgYXNzdW1l IG5vdyB0aGUgV0cgc3VwcG9ydCBmb3IgdGhlIGFkb3B0aW9uIG9mDQpkcmFmdC1iaWVybWFuLW5l dGNvbmYtcmZjNjUzNmJpcy4NCkF1dGhvcnMgcGxlYXNlIHN1Ym1pdCBhcyBkcmFmdC1pZXRmLW5l dGNvbmYtcmZjNjUzNmJpcy0wMC4gVGhhbmtzLg0KDQpkb25lDQoNCg0KTWVobWV0ICYgTWFoZXNo DQoNCg0KQW5keQ0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBOZXRjb25m IFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNA aWV0Zi5vcmc+XSBPbiBCZWhhbGYgT2YgTWVobWV0IEVyc3VlDQpTZW50OiBXZWRuZXNkYXksIERl Y2VtYmVyIDE0LCAyMDE2IDEwOjIwIFBNDQpUbzogJ05ldGNvbmYnIDxuZXRjb25mQGlldGYub3Jn PG1haWx0bzpuZXRjb25mQGlldGYub3JnPj4NClN1YmplY3Q6IFtOZXRjb25mXSBXRyBBZG9wdGlv biBDYWxsIGZvciBkcmFmdC1iaWVybWFuLW5ldGNvbmYtcmZjNjUzNmJpcw0KV0FTOkZXOiBuZXcg TkFDTSBkcmFmdA0KDQpEZWFyIE5FVENPTkYgV0csDQoNCmZvciB0aGUgcG90ZW50aWFsIHRvcGlj cyB0byBhZGQgd2Ugb25seSBnb3QgY29tbWVudHMgZnJvbSBNYXJ0aW4uIFdlIGFzc3VtZQ0Kbm93 IHRoZXJlIGFyZSBubyBvdGhlciBjb21tZW50cy4NCg0KVGhpcyBpcyBhIDIrIHdlZWsgV0cgYWRv cHRpb24gY2FsbCBmb3IgZHJhZnQtYmllcm1hbi1uZXRjb25mLXJmYzY1MzZiaXMgdG8NCmFkb3B0 IGFzIE5FVENPTkYgV0cgaXRlbS4NCg0KUGxlYXNlIHN0YXRlIHlvdXIgb3BpbmlvbiBvbiB0aGUg bWFpbCBsaXN0IGJ5IERlY2VtYmVyIDMwLCAyMDE2IHdpdGgNCiJ5ZXMvc3VwcG9ydCIgb3IgIm5v IHN1cHBvcnQiLg0KDQpJZiB5b3Ugc3VwcG9ydCwgcGxlYXNlIGxldCB1cyBrbm93IHdoYXQgeW91 IHdvdWxkIGxpa2UgdG8gYWRkcmVzcw0KYWRkaXRpb25hbGx5Lg0KSWYgeW91IGRvbid0IHN1cHBv cnQsIHBsZWFzZSBlbGFib3JhdGUgeW91ciByZWFzb25zLg0KDQpUaGFuayB5b3UsDQpNZWhtZXQg JiBNYWhlc2gNCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogTWFydGluIEJq b3JrbHVuZCBbbWFpbHRvOm1iakB0YWlsLWYuY29tPG1haWx0bzptYmpAdGFpbC1mLmNvbT5dDQpT ZW50OiBXZWRuZXNkYXksIERlY2VtYmVyIDcsIDIwMTYgOToyMCBBTQ0KVG86IG1lcnN1ZUBnbWFp bC5jb208bWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20+DQpDYzogYW5keUB5dW1hd29ya3MuY29tPG1h aWx0bzphbmR5QHl1bWF3b3Jrcy5jb20+OyBuZXRjb25mQGlldGYub3JnPG1haWx0bzpuZXRjb25m QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBuZXcgTkFDTSBkcmFmdA0KDQpNZWht ZXRFcnN1ZSA8bWVyc3VlQGdtYWlsLmNvbTxtYWlsdG86bWVyc3VlQGdtYWlsLmNvbT4gPG1haWx0 bzptZXJzdWVAZ21haWwuY29tPG1haWx0bzptZXJzdWVAZ21haWwuY29tPj4gPiB3cm90ZToNCj4g SGkgQW5keSwgTWFydGluLA0KPg0KPiB0aGFuayB5b3UgZm9yIHRoZSBpbml0aWFsIGRyYWZ0Lg0K Pg0KPiBXZSBkaXNjdXNzZWQgaW4gSUVURiA5NyBkaWZmZXJlbnQgaXNzdWVzIGFuZCB0aGUgYWRk aXRpb25hbCBzZWN0aW9ucw0KPiB3ZSBjb3VsZCBhZGQuDQoNCk9rLiAgQnV0IGRvIHdlIGhhdmUg dG8gcmVzb2x2ZSBhbGwgaXNzdWVzIGJlZm9yZSBhZG9wdGluZyB0aGlzIGRvY3VtZW50PyAgSQ0K dGhpbmsgdGhlIGN1cnJlbnQgZG9jdW1lbnQgaXMgcmVhZHkgZm9yIGFkb3B0aW9uLCBhbmQgdGhl biB0aGUgV0cgY2FuIHdvcmsNCm9uIGZpeGluZyBhbnkgb3BlbiBpc3N1ZXMuDQoNCj4gSUlSQyB0 aGUgbGlzdCB3YXM6DQo+IC0gc2NoZW1hLW1vdW50IHJlbGF0ZWQgdGV4dCBpbnRvIHNjaGVtYS1t b3VudCBvciB0aGUgTkFDTSBkcmFmdCwNCg0KSSB0aGluayBzY2hlbWEgbW91bnQgbmVlZHMgdG8g ZGlzY3VzcyBob3cgaXQgd29ya3Mgd2l0aCBOQUNNLiAgVGhpcyBzaG91bGQNCmJlIGFuIG9wZW4g aXNzdWUgaW4gc2NoZW1hIG1vdW50Lg0KDQo+IC0gYXNzaWduaW5nIHByaW9yaXRpZXMgdG8gY2xp ZW50cywNCg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgYSBOQUNNIGlzc3VlLg0KDQo+IC0gYWNj ZXNzIGNvbnRyb2wgb24gZHluYW1pYyBkYXRhc3RvcmVzIChlLmcuIEkyUlMpLA0KDQpUaGUgdGV4 dCBpbiAzLjIgcHJvYmFibHkgbmVlZCB0byBiZSByZWxheGVkIGEgYml0IHRvIGFsbG93IE5BQ00g dG8gYmUNCmFwcGxpZWQgdG8gb3RoZXIgZGF0YXN0b3Jlcy4NCg0KPiAtIHRoZSBpc3N1ZSBmcm9t IFJGQyA2NTM2IHdpdGggcGFyZW50L2NoaWxkIHJlbGF0aW9uc2hpcHMgd2hpY2ggaXMNCj4gaW1w b3J0YW50IGZvciBSRVNUQ09ORi4NCg0KQ2FuIHlvdSBlbGFib3JhdGUgb24gdGhpcz8NCg0KDQov bWFydGluDQoNCg0KDQo+DQo+IEkgd291bGQgbGlrZSB0byBzdWdnZXN0IHRvIGhhdmUgYSBkaXNj dXNzaW9uIG9uIHRoZXNlIGlzc3VlcyBhbmQNCj4gdW5kZXJzdGFuZCB3aGV0aGVyIHRoZXkgc2hv dWxkIGJlIGluY2x1ZGVkLg0KPg0KPiBNZWhtZXQNCj4NCj4gT24gV2VkLCBOb3YgMzAsIDIwMTYg YXQgMjoxMCBBTSwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb208bWFpbHRvOmFuZHlA eXVtYXdvcmtzLmNvbT4NCjxtYWlsdG86YW5keUB5dW1hd29ya3MuY29tPG1haWx0bzphbmR5QHl1 bWF3b3Jrcy5jb20+PiA+IHdyb3RlOg0KPg0KPiA+IEhpLA0KPiA+DQo+ID4gQSBuZXcgdmVyc2lv biBvZiBkcmFmdC1iaWVybWFuLW5ldGNvbmYtcmZjNjUzNmJpcyBoYXMgYmVlbiBwb3N0ZWQ6DQo+ ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYmllcm1hbi1uZXRjb25mLXJmYzY1MzZi aXMtMDEudHh0DQo+ID4NCj4gPg0KPiA+IFdlIHdvdWxkIGxpa2UgdGhpcyBkcmFmdCB0byBiZSBh ZG9wdGVkIGFzIHRoZSBzdGFydGluZyBwb2ludCBmb3INCj4gPiBpdGVtICM1IGluIHRoZSBjdXJy ZW50IE5FVENPTkYgY2hhcnRlci4NCj4gPg0KPiA+DQo+ID4NCj4gPiBBbmR5IGFuZCBNYXJ0aW4N Cj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj4gPiBOZXRjb25mIG1haWxpbmcgbGlzdA0KPiA+IE5ldGNvbmZAaWV0Zi5vcmc8bWFp bHRvOk5ldGNvbmZAaWV0Zi5vcmc+IDxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZzxtYWlsdG86TmV0 Y29uZkBpZXRmLm9yZz4+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRjb25mDQo+ID4NCj4gPg0KPg0KPg0KPiAtLQ0KPiBDaGVlcnMsDQo+IE1laG1ldA0KDQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBt YWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5vcmc8bWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmc+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCg0KX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYgbWFpbGluZyBs aXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGlldGYub3JnPg0KaHR0cHM6Ly93 d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRjb25mDQoNCg== --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43ASJCEML703CHMchi_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9 DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglj b2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFu Lk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpw dXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCglt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJ Y29sb3I6IzFGNDk3RDt9DQpzcGFuLkVtYWlsU3R5bGUxOA0KCXttc28tc3R5bGUtdHlwZTpwZXJz b25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9y OndpbmRvd3RleHQ7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFt ZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1z by1zdHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIg TmV3Ijt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglm b250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj5IaSBBbmR5LCBhbmQgV29ya2luZyBHcm91cCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86 cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5z LXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkxvb2tpbmcgYXQgdGhlIDY1MzZiaXMgZHJhZnQsIG9uZSBj b21tZW50IEkgaGF2ZSBpcyB0aGF0IHdlIHNob3VsZCBjb25zaWRlciB0byBkZWVtcGhhc2l6ZSB0 aGUgc3BlY2lmaWMgcHJvdG9jb2xzIHVzZWQgdG8gYWNjZXNzIHRoZSBZQU5HLWRlZmluZWQgZGF0 YS4mbmJzcDsgUmF0aGVyLA0KIEkgdGhpbmsgdGhlIEFjY2VzcyBDb250cm9sIE1vZGVsIHNob3Vs ZCBiZSBkZWZpbmVkIGluIHRlcm1zIG9mIHRoZSBkYXRhIHRoYXQgaXMgYmVpbmcgYWNjZXNzZWQs IGFuZCB0aGUgb3BlcmF0aW9ucyB0aGF0IGNsaWVudHMgYXJlIGF1dGhvcml6ZWQgdG8gY2Fycnkg b3V0IGFnYWluc3QgdGhhdCBkYXRhLiZuYnNwOyBJbiBhZGRpdGlvbiwgdGhlcmUgbWF5IGJlIGlt cGxpY2F0aW9ucyB0byBiZSBkaXNjdXNzZWQgZnJvbSB0aGUgcmV2aXNlZCBkYXRhc3RvcmVzDQog ZHJhZnQuJm5ic3A7IFJlYWxseSwgdGhpcyBzaG91bGQgYmUgYWJvdXQgZGVmaW5pbmcgYW4gQWNj ZXNzIENvbnRyb2wgTW9kZWwgZm9yIG9wZXJhdGlvbnMgY2FycmllZCBvdXQgYWdhaW5zdCBhIFlB TkcgZGF0YXN0b3JlLCBpbmRlcGVuZGVudCBvZiB0aGUgc3BlY2lmaWMgcHJvdG9jb2wgdXNlZCBm b3IgdGhvc2Ugb3BlcmF0aW9ucy4mbmJzcDsNCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+SSBiZWxpZXZlIG9uZSBvZiB0aGUgaW50ZW50aW9ucyBiZWhpbmQgdGhl IGRyYWZ0IGlzIHRvIG1ha2UgaXQgbGVzcyBOZXRjb25mLWRlcGVuZGVudCwgYnV0IGp1c3QgZXh0 ZW5kaW5nIGl0IHRvIFJlc3Rjb25mIG1heSBub3QgYmUgZW5vdWdoIOKAkyB0aGVyZSBtYXkgYmUg b3RoZXINCiB0cmFuc3BvcnRzL21lY2hhbmlzbXMgdGhhdCBjb3VsZCBiZSB1c2VkIHRvIGFjY2Vz cyBZQU5HLWRlZmluZWQgZGF0YSBhbmQgZGF0YXN0b3JlcyBhbmQgTkFDTSBzaG91bGQgYXBwbHkg dGhlcmUgYXMgd2VsbC4mbmJzcDsgSXQgaXMgZmluZSB0byBleHBsYWluIGhvdyBOQUNNIHdpbGwg YmUgYXBwbGllZCBpbiB0aGUgcGFydGljdWxhciBpbnN0YW5jZXMgb2YgUmVzdGNvbmYgYW5kIE5l dGNvbmYsIGJ1dCBzdGlsbCBwb2ludCBvdXQgdGhhdCBhY2Nlc3MgbWV0aG9kDQogaW5kZXBlbmRl bmNlLiZuYnNwOyA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1 b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkZv ciBleGFtcGxlLCB0aGUgYWJzdHJhY3Qgc3RhdGVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7Q291cmllciBOZXcmcXVvdDsiPlRoZXJlIGlzIGEgbmVlZDxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q291cmllciBOZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyBmb3Igc3RhbmRhcmQgbWVj aGFuaXNtcyB0byByZXN0cmljdCBORVRDT05GIG9yIFJFU1RDT05GIHByb3RvY29sPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7IGFjY2Vz cyBmb3IgcGFydGljdWxhciB1c2VycyB0byBhIHByZS1jb25maWd1cmVkIHN1YnNldCBvZiBhbGw8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF TiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz cDsgYXZhaWxhYmxlIE5FVENPTkYgb3IgUkVTVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucyBhbmQg Y29udGVudC4mbmJzcDsgVGhpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOIj4mbmJzcDsmbmJzcDsgZG9jdW1lbnQgZGVmaW5lcyBzdWNo IGFuIGFjY2VzcyBjb250cm9sIG1vZGVsLjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFG NDk3RCI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj5JIHRoaW5r IHRoaXMgbWlnaHQgYmUgYmV0dGVyIHJlcGhyYXNlZCBzb21ldGhpbmcgbGlrZQ0KPG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxl PSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7 VGhlcmUgaXMgYSBuZWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gbGFuZz0iRU4iIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZx dW90OyI+Jm5ic3A7Jm5ic3A7IGZvciBzdGFuZGFyZCBtZWNoYW5pc21zIHRvIHJlc3RyaWN0IGFj Y2VzcyBmb3IgcGFydGljdWxhciB1c2VycyB0byBhIHByZS1jb25maWd1cmVkIHN1YnNldCBvZiBh bGw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTiIgc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsm bmJzcDsgYXZhaWxhYmxlIGNvbnRlbnQgaW4gWUFORyBkYXRhc3RvcmVzIGFuZCBhdmFpbGFibGUg b3BlcmF0aW9ucywgYWNjZXNzZWQgdmlhIG1lY2hhbmlzbXMgdGhhdCBpbmNsdWRlDQo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTiIgc3R5 bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDtZQU5H IE5FVENPTkYgb3IgUkVTVENPTkYgcHJvdG9jb2wgb3BlcmF0aW9ucy4mbmJzcDsgVGhpczxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOIj4m bmJzcDsmbmJzcDsgZG9jdW1lbnQgZGVmaW5lcyBzdWNoIGFuIGFjY2VzcyBjb250cm9sIG1vZGVs LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1z ZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTom cXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3RCI+UGVyaGFwcyBOQUNN IHNob3VsZCByZWFsbHkgYmUgcmVuYW1lZCB0byBZQUNNOy0pJm5ic3A7IEkga25vdywgdGhlIGRy YWZ0IGlzIGluIHRoZSBOZXRjb25mIFdHLCBub3QgTmV0bW9kLCBzbyB3aHkgc2hvdWxkIGl0IG5v dCBiZSBzcGVjaWZpYyB0byBOZXRjb25mIGFuZCBSZXN0Y29uZiwNCiBidXQgc3RpbGzigKY8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMxRjQ5N0QiPkNoZWVyczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGlicmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjoj MUY0OTdEIj4tLS0gQWxleDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw dDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7Y29sb3I6IzFGNDk3 RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+ PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZx dW90OyxzYW5zLXNlcmlmIj5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj4gTmV0Y29u ZiBbbWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZ10NCjxiPk9uIEJlaGFsZiBPZiA8L2I+ QW5keSBCaWVybWFuPGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKYW51YXJ5IDA1LCAyMDE3 IDEwOjI3IEFNPGJyPg0KPGI+VG86PC9iPiBNZWhtZXQgRXJzdWUgJmx0O21lcnN1ZUBnbWFpbC5j b20mZ3Q7PGJyPg0KPGI+Q2M6PC9iPiBOZXRjb25mICZsdDtuZXRjb25mQGlldGYub3JnJmd0Ozxi cj4NCjxiPlN1YmplY3Q6PC9iPiBSZTogW05ldGNvbmZdIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRy YWZ0LWJpZXJtYW4tbmV0Y29uZi1yZmM2NTM2YmlzIFdBUzpGVzogbmV3IE5BQ00gZHJhZnQ8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PbiBXZWQsIEphbiA0LCAyMDE3IGF0IDg6MzAgQU0sIE1l aG1ldCBFcnN1ZSAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20iIHRhcmdldD0i X2JsYW5rIj5tZXJzdWVAZ21haWwuY29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8 YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAx LjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1y aWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIu MHB0Ij5EZWFyIEFsbCw8YnI+DQo8YnI+DQp3ZSBhc3N1bWUgbm93IHRoZSBXRyBzdXBwb3J0IGZv ciB0aGUgYWRvcHRpb24gb2Y8YnI+DQpkcmFmdC1iaWVybWFuLW5ldGNvbmYtcmZjNjUzNmJpcy48 YnI+DQpBdXRob3JzIHBsZWFzZSBzdWJtaXQgYXMgZHJhZnQtaWV0Zi1uZXRjb25mLXJmYzY1MzZi aXMtMDAuIFRoYW5rcy48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPmRvbmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9j a3F1b3RlIHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0 O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4wcHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0 OjBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NZWhtZXQgJmFtcDsgTWFoZXNoPG86cD48L286 cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m bmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFu ZHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu YnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9yZGVyOm5v bmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4gMGluIDYu MHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PGJyPg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBOZXRjb25m IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29u Zi1ib3VuY2VzQGlldGYub3JnPC9hPl0gT24gQmVoYWxmIE9mIE1laG1ldCBFcnN1ZTxicj4NClNl bnQ6IFdlZG5lc2RheSwgRGVjZW1iZXIgMTQsIDIwMTYgMTA6MjAgUE08YnI+DQpUbzogJ05ldGNv bmYnICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZkBpZXRmLm9yZyI+bmV0Y29uZkBpZXRmLm9y ZzwvYT4mZ3Q7PGJyPg0KU3ViamVjdDogW05ldGNvbmZdIFdHIEFkb3B0aW9uIENhbGwgZm9yIGRy YWZ0LWJpZXJtYW4tbmV0Y29uZi1yZmM2NTM2YmlzPGJyPg0KV0FTOkZXOiBuZXcgTkFDTSBkcmFm dDxicj4NCjxicj4NCkRlYXIgTkVUQ09ORiBXRyw8YnI+DQo8YnI+DQpmb3IgdGhlIHBvdGVudGlh bCB0b3BpY3MgdG8gYWRkIHdlIG9ubHkgZ290IGNvbW1lbnRzIGZyb20gTWFydGluLiBXZSBhc3N1 bWU8YnI+DQpub3cgdGhlcmUgYXJlIG5vIG90aGVyIGNvbW1lbnRzLjxicj4NCjxicj4NClRoaXMg aXMgYSAyJiM0Mzsgd2VlayBXRyBhZG9wdGlvbiBjYWxsIGZvciBkcmFmdC1iaWVybWFuLW5ldGNv bmYtcmZjNjUzNmJpcyB0bzxicj4NCmFkb3B0IGFzIE5FVENPTkYgV0cgaXRlbS48YnI+DQo8YnI+ DQpQbGVhc2Ugc3RhdGUgeW91ciBvcGluaW9uIG9uIHRoZSBtYWlsIGxpc3QgYnkgRGVjZW1iZXIg MzAsIDIwMTYgd2l0aDxicj4NCiZxdW90O3llcy9zdXBwb3J0JnF1b3Q7IG9yICZxdW90O25vIHN1 cHBvcnQmcXVvdDsuPGJyPg0KPGJyPg0KSWYgeW91IHN1cHBvcnQsIHBsZWFzZSBsZXQgdXMga25v dyB3aGF0IHlvdSB3b3VsZCBsaWtlIHRvIGFkZHJlc3M8YnI+DQphZGRpdGlvbmFsbHkuPGJyPg0K SWYgeW91IGRvbid0IHN1cHBvcnQsIHBsZWFzZSBlbGFib3JhdGUgeW91ciByZWFzb25zLjxicj4N Cjxicj4NClRoYW5rIHlvdSw8YnI+DQpNZWhtZXQgJmFtcDsgTWFoZXNoPGJyPg0KPGJyPg0KPGJy Pg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08YnI+DQpGcm9tOiBNYXJ0aW4gQmpvcmtsdW5k IFttYWlsdG86PGEgaHJlZj0ibWFpbHRvOm1iakB0YWlsLWYuY29tIj5tYmpAdGFpbC1mLmNvbTwv YT5dPGJyPg0KU2VudDogV2VkbmVzZGF5LCBEZWNlbWJlciA3LCAyMDE2IDk6MjAgQU08YnI+DQpU bzogPGEgaHJlZj0ibWFpbHRvOm1lcnN1ZUBnbWFpbC5jb20iPm1lcnN1ZUBnbWFpbC5jb208L2E+ PGJyPg0KQ2M6IDxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdv cmtzLmNvbTwvYT47IDxhIGhyZWY9Im1haWx0bzpuZXRjb25mQGlldGYub3JnIj4NCm5ldGNvbmZA aWV0Zi5vcmc8L2E+PGJyPg0KU3ViamVjdDogUmU6IFtOZXRjb25mXSBuZXcgTkFDTSBkcmFmdDxi cj4NCjxicj4NCk1laG1ldEVyc3VlICZsdDs8YSBocmVmPSJtYWlsdG86bWVyc3VlQGdtYWlsLmNv bSI+bWVyc3VlQGdtYWlsLmNvbTwvYT4gJmx0O21haWx0bzo8YSBocmVmPSJtYWlsdG86bWVyc3Vl QGdtYWlsLmNvbSI+bWVyc3VlQGdtYWlsLmNvbTwvYT4mZ3Q7ICZndDsgd3JvdGU6PGJyPg0KJmd0 OyBIaSBBbmR5LCBNYXJ0aW4sPGJyPg0KJmd0Ozxicj4NCiZndDsgdGhhbmsgeW91IGZvciB0aGUg aW5pdGlhbCBkcmFmdC48YnI+DQomZ3Q7PGJyPg0KJmd0OyBXZSBkaXNjdXNzZWQgaW4gSUVURiA5 NyBkaWZmZXJlbnQgaXNzdWVzIGFuZCB0aGUgYWRkaXRpb25hbCBzZWN0aW9uczxicj4NCiZndDsg d2UgY291bGQgYWRkLjxicj4NCjxicj4NCk9rLiZuYnNwOyBCdXQgZG8gd2UgaGF2ZSB0byByZXNv bHZlIGFsbCBpc3N1ZXMgYmVmb3JlIGFkb3B0aW5nIHRoaXMgZG9jdW1lbnQ/Jm5ic3A7IEk8YnI+ DQp0aGluayB0aGUgY3VycmVudCBkb2N1bWVudCBpcyByZWFkeSBmb3IgYWRvcHRpb24sIGFuZCB0 aGVuIHRoZSBXRyBjYW4gd29yazxicj4NCm9uIGZpeGluZyBhbnkgb3BlbiBpc3N1ZXMuPGJyPg0K PGJyPg0KJmd0OyBJSVJDIHRoZSBsaXN0IHdhczo8YnI+DQomZ3Q7IC0gc2NoZW1hLW1vdW50IHJl bGF0ZWQgdGV4dCBpbnRvIHNjaGVtYS1tb3VudCBvciB0aGUgTkFDTSBkcmFmdCw8YnI+DQo8YnI+ DQpJIHRoaW5rIHNjaGVtYSBtb3VudCBuZWVkcyB0byBkaXNjdXNzIGhvdyBpdCB3b3JrcyB3aXRo IE5BQ00uJm5ic3A7IFRoaXMgc2hvdWxkPGJyPg0KYmUgYW4gb3BlbiBpc3N1ZSBpbiBzY2hlbWEg bW91bnQuPGJyPg0KPGJyPg0KJmd0OyAtIGFzc2lnbmluZyBwcmlvcml0aWVzIHRvIGNsaWVudHMs PGJyPg0KPGJyPg0KSSBkb24ndCBiZWxpZXZlIHRoaXMgaXMgYSBOQUNNIGlzc3VlLjxicj4NCjxi cj4NCiZndDsgLSBhY2Nlc3MgY29udHJvbCBvbiBkeW5hbWljIGRhdGFzdG9yZXMgKGUuZy4gSTJS UyksPGJyPg0KPGJyPg0KVGhlIHRleHQgaW4gMy4yIHByb2JhYmx5IG5lZWQgdG8gYmUgcmVsYXhl ZCBhIGJpdCB0byBhbGxvdyBOQUNNIHRvIGJlPGJyPg0KYXBwbGllZCB0byBvdGhlciBkYXRhc3Rv cmVzLjxicj4NCjxicj4NCiZndDsgLSB0aGUgaXNzdWUgZnJvbSBSRkMgNjUzNiB3aXRoIHBhcmVu dC9jaGlsZCByZWxhdGlvbnNoaXBzIHdoaWNoIGlzPGJyPg0KJmd0OyBpbXBvcnRhbnQgZm9yIFJF U1RDT05GLjxicj4NCjxicj4NCkNhbiB5b3UgZWxhYm9yYXRlIG9uIHRoaXM/PGJyPg0KPGJyPg0K PGJyPg0KL21hcnRpbjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDs8YnI+DQomZ3Q7IEkgd291 bGQgbGlrZSB0byBzdWdnZXN0IHRvIGhhdmUgYSBkaXNjdXNzaW9uIG9uIHRoZXNlIGlzc3VlcyBh bmQ8YnI+DQomZ3Q7IHVuZGVyc3RhbmQgd2hldGhlciB0aGV5IHNob3VsZCBiZSBpbmNsdWRlZC48 YnI+DQomZ3Q7PGJyPg0KJmd0OyBNZWhtZXQ8YnI+DQomZ3Q7PGJyPg0KJmd0OyBPbiBXZWQsIE5v diAzMCwgMjAxNiBhdCAyOjEwIEFNLCBBbmR5IEJpZXJtYW4gJmx0OzxhIGhyZWY9Im1haWx0bzph bmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwvYT48YnI+DQombHQ7bWFpbHRv OjxhIGhyZWY9Im1haWx0bzphbmR5QHl1bWF3b3Jrcy5jb20iPmFuZHlAeXVtYXdvcmtzLmNvbTwv YT4mZ3Q7ICZndDsgd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDsgQSBuZXcgdmVyc2lvbiBvZiBkcmFmdC1iaWVybWFuLW5ldGNv bmYtcmZjNjUzNmJpcyBoYXMgYmVlbiBwb3N0ZWQ6PGJyPg0KJmd0OyAmZ3Q7IDxhIGhyZWY9Imh0 dHBzOi8vd3d3LmlldGYub3JnL2lkL2RyYWZ0LWJpZXJtYW4tbmV0Y29uZi1yZmM2NTM2YmlzLTAx LnR4dCIgdGFyZ2V0PSJfYmxhbmsiPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvaWQvZHJhZnQtYmll cm1hbi1uZXRjb25mLXJmYzY1MzZiaXMtMDEudHh0PC9hPjxicj4NCiZndDsgJmd0Ozxicj4NCiZn dDsgJmd0Ozxicj4NCiZndDsgJmd0OyBXZSB3b3VsZCBsaWtlIHRoaXMgZHJhZnQgdG8gYmUgYWRv cHRlZCBhcyB0aGUgc3RhcnRpbmcgcG9pbnQgZm9yPGJyPg0KJmd0OyAmZ3Q7IGl0ZW0gIzUgaW4g dGhlIGN1cnJlbnQgTkVUQ09ORiBjaGFydGVyLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 Ozxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyBBbmR5IGFuZCBNYXJ0aW48YnI+DQomZ3Q7 ICZndDs8YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDsgX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7ICZndDsgTmV0Y29uZiBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7ICZndDsgPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5l dGNvbmZAaWV0Zi5vcmc8L2E+ICZsdDttYWlsdG86PGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0 Zi5vcmciPk5ldGNvbmZAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCiZndDsgJmd0OyA8YSBocmVmPSJo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYiIHRhcmdldD0iX2Js YW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7 IC0tPGJyPg0KJmd0OyBDaGVlcnMsPGJyPg0KJmd0OyBNZWhtZXQ8YnI+DQo8YnI+DQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCk5ldGNvbmYgbWFp bGluZyBsaXN0PGJyPg0KPGEgaHJlZj0ibWFpbHRvOk5ldGNvbmZAaWV0Zi5vcmciPk5ldGNvbmZA aWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9uZXRjb25mIiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9uZXRjb25mPC9hPjxicj4NCjxicj4NCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KTmV0Y29uZiBtYWlsaW5nIGxpc3Q8YnI+ DQo8YSBocmVmPSJtYWlsdG86TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48 YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNv bmYiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L25ldGNvbmY8L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43ASJCEML703CHMchi_-- From nobody Tue Jan 31 15:57:10 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34E9B129660 for ; Tue, 31 Jan 2017 15:57:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MAq9GFAc5NoX for ; Tue, 31 Jan 2017 15:57:06 -0800 (PST) Received: from mail-qk0-x22a.google.com (mail-qk0-x22a.google.com [IPv6:2607:f8b0:400d:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 09A00129657 for ; Tue, 31 Jan 2017 15:57:06 -0800 (PST) Received: by mail-qk0-x22a.google.com with SMTP id u25so182176987qki.2 for ; Tue, 31 Jan 2017 15:57:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kd/GamqCQ+hXQRv0OGJg6Ot21JiQBkaxp/nXyXAmIGE=; b=erf29uq2qaUpapGEXk2m3B/xNqhcHqplZ6MeZNo0DAGAcJI1SGmywNKXeB6p4bakn3 ZVqbS0LYOMt3rTPamk9IAfe7/zWQgUgLp+UkgNDBcUNP38VEK4QjskmVcY/0qMuHBLk/ KxVu1wv1Wp8zpBMvEASdn55nSvX8gfPZ1zjxX7B6KkmwBEGpod9y333XPgtIdkYtQEgW +8H3/A4FiuzpNr5g1Uf+3830CFxuV3wYAzP0Lh0AcUrYNv9Av+zifmudHGbsDZ/0BWhL 64cmqKuhgI9VkqmPS27hCjNIQvlD+8MOsloD5OCniBVl+wetzkgRXwRHqEog8/017VBm aoUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Kd/GamqCQ+hXQRv0OGJg6Ot21JiQBkaxp/nXyXAmIGE=; b=I9Q88N3w82SUElvl7DcTRYUpysS3QGm+trk5D2A56ALFKTcNKOWS3/pH4Rnh55oVmp VN991T0cSj6OgArVn36tcGgV0dq6KKdE60wONvdwMKG9br0XTR5i6Yp5jrWV8GM51bn1 WF2EEvwKAD2GRZBfbk8gUxaiVDJ2vNE9VhJoGtWoULlt7B8gO3Wjcr4Ldjwsf7Apjh9F NG4eo1FfJjODk4iUS0QEGDoWp8z1pzdEzYfXaV2ceUgd6MVcG1AB0knKBr9dZiYMWnxl zXPWaZar4vECiyoVJvWNQGx/sTT8+cRmr65y0i5y0+s3FTBlpmj0ySRnk/2kcIEI8SwD eztg== X-Gm-Message-State: AIkVDXKPoDQ2LE6xXaXfJjnnsAQ6j9QsJU4c/X3HrFD4VTe8A1hBMlK0ezK38U/Vk1YyUu54uwusb1p+TasEow== X-Received: by 10.55.21.133 with SMTP id 5mr14825121qkv.71.1485907025138; Tue, 31 Jan 2017 15:57:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.12.145.66 with HTTP; Tue, 31 Jan 2017 15:57:04 -0800 (PST) In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43A@SJCEML703-CHM.china.huawei.com> References: <644DA50AFA8C314EA9BDDAC83BD38A2E0DF7D43A@SJCEML703-CHM.china.huawei.com> From: Andy Bierman Date: Tue, 31 Jan 2017 15:57:04 -0800 Message-ID: To: Alexander Clemm Content-Type: multipart/alternative; boundary=001a1147eec0672f8805476cb048 Archived-At: Cc: Netconf Subject: Re: [Netconf] YACM? (RE: WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft) X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 Jan 2017 23:57:09 -0000 --001a1147eec0672f8805476cb048 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Tue, Jan 31, 2017 at 2:54 PM, Alexander Clemm wrote: > Hi Andy, and Working Group, > > > > Looking at the 6536bis draft, one comment I have is that we should > consider to deemphasize the specific protocols used to access the > YANG-defined data. Rather, I think the Access Control Model should be > defined in terms of the data that is being accessed, and the operations > that clients are authorized to carry out against that data. In addition, > there may be implications to be discussed from the revised datastores > draft. Really, this should be about defining an Access Control Model for > operations carried out against a YANG datastore, independent of the > specific protocol used for those operations. > > > > I believe one of the intentions behind the draft is to make it less > Netconf-dependent, but just extending it to Restconf may not be enough = =E2=80=93 > there may be other transports/mechanisms that could be used to access > YANG-defined data and datastores and NACM should apply there as well. It > is fine to explain how NACM will be applied in the particular instances o= f > Restconf and Netconf, but still point out that access method independence= . > Good points. It would be nice to be done with NACM even if we are not done inventing YANG-based protocols. There is an inherent conflict between generic operations and interoperability for a specific protocol. e.g., we can change to say 'an edit operation' but now it is no longer clear what NETCONF requires for each operation. It might be possible to define NACM using a generic protocol interaction model, and then have a separate (short) section that maps each protocol to the generic model. We can define codepoints for the CRUD-XN model and assign procedures to the codepoints. The draft does that already but there is no generic model, just straight mappings to NETCONF and RESTCONF. > > > For example, the abstract states: > > There is a need > > for standard mechanisms to restrict NETCONF or RESTCONF protocol > > access for particular users to a pre-configured subset of all > > available NETCONF or RESTCONF protocol operations and content. This > > document defines such an access control model. > > > > I think this might be better rephrased something like > > There is a need > > for standard mechanisms to restrict access for particular users to a > pre-configured subset of all > > available content in YANG datastores and available operations, accesse= d > via mechanisms that include > > YANG NETCONF or RESTCONF protocol operations. This > > document defines such an access control model. > > > > Perhaps NACM should really be renamed to YACM;-) I know, the draft is in > the Netconf WG, not Netmod, so why should it not be specific to Netconf a= nd > Restconf, but still=E2=80=A6 > > hmm - that might be a better name as we adjust to the fact that YANG is no longer coupled to NETCONF. > > > Cheers > > --- Alex > > > Andy > > > *From:* Netconf [mailto:netconf-bounces@ietf.org] *On Behalf Of *Andy > Bierman > *Sent:* Thursday, January 05, 2017 10:27 AM > *To:* Mehmet Ersue > *Cc:* Netconf > *Subject:* Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc65= 36bis > WAS:FW: new NACM draft > > > > > > > > On Wed, Jan 4, 2017 at 8:30 AM, Mehmet Ersue wrote: > > Dear All, > > we assume now the WG support for the adoption of > draft-bierman-netconf-rfc6536bis. > Authors please submit as draft-ietf-netconf-rfc6536bis-00. Thanks. > > > > done > > > > > > Mehmet & Mahesh > > > > > > Andy > > > > > -----Original Message----- > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mehmet Ersue > Sent: Wednesday, December 14, 2016 10:20 PM > To: 'Netconf' > Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis > WAS:FW: new NACM draft > > Dear NETCONF WG, > > for the potential topics to add we only got comments from Martin. We assu= me > now there are no other comments. > > This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bis t= o > adopt as NETCONF WG item. > > Please state your opinion on the mail list by December 30, 2016 with > "yes/support" or "no support". > > If you support, please let us know what you would like to address > additionally. > If you don't support, please elaborate your reasons. > > Thank you, > Mehmet & Mahesh > > > -----Original Message----- > From: Martin Bjorklund [mailto:mbj@tail-f.com] > Sent: Wednesday, December 7, 2016 9:20 AM > To: mersue@gmail.com > Cc: andy@yumaworks.com; netconf@ietf.org > Subject: Re: [Netconf] new NACM draft > > MehmetErsue > wrote: > > Hi Andy, Martin, > > > > thank you for the initial draft. > > > > We discussed in IETF 97 different issues and the additional sections > > we could add. > > Ok. But do we have to resolve all issues before adopting this document? = I > think the current document is ready for adoption, and then the WG can wor= k > on fixing any open issues. > > > IIRC the list was: > > - schema-mount related text into schema-mount or the NACM draft, > > I think schema mount needs to discuss how it works with NACM. This shoul= d > be an open issue in schema mount. > > > - assigning priorities to clients, > > I don't believe this is a NACM issue. > > > - access control on dynamic datastores (e.g. I2RS), > > The text in 3.2 probably need to be relaxed a bit to allow NACM to be > applied to other datastores. > > > - the issue from RFC 6536 with parent/child relationships which is > > important for RESTCONF. > > Can you elaborate on this? > > > /martin > > > > > > > I would like to suggest to have a discussion on these issues and > > understand whether they should be included. > > > > Mehmet > > > > On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman > wrote: > > > > > Hi, > > > > > > A new version of draft-bierman-netconf-rfc6536bis has been posted: > > > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt > > > > > > > > > We would like this draft to be adopted as the starting point for > > > item #5 in the current NETCONF charter. > > > > > > > > > > > > Andy and Martin > > > > > > > > > _______________________________________________ > > > Netconf mailing list > > > Netconf@ietf.org > > > https://www.ietf.org/mailman/listinfo/netconf > > > > > > > > > > > > -- > > Cheers, > > Mehmet > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > --001a1147eec0672f8805476cb048 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Tue, Jan 31, 2017 at 2:54 PM, Alexander Clemm <= alexander.c= lemm@huawei.com> wrote:

Hi Andy, and Working Group,=

=C2=A0

Looking at the 6536bis draft, one com= ment I have is that we should consider to deemphasize the specific protocol= s used to access the YANG-defined data.=C2=A0 Rather, I think the Access Control Model should be defined in terms of the data th= at is being accessed, and the operations that clients are authorized to car= ry out against that data.=C2=A0 In addition, there may be implications to b= e discussed from the revised datastores draft.=C2=A0 Really, this should be about defining an Access Control Model= for operations carried out against a YANG datastore, independent of the sp= ecific protocol used for those operations.=C2=A0

=C2=A0

I believe one of the intentions behin= d the draft is to make it less Netconf-dependent, but just extending it to = Restconf may not be enough =E2=80=93 there may be other transports/mechanisms that could be used to access YANG-defined data and d= atastores and NACM should apply there as well.=C2=A0 It is fine to explain = how NACM will be applied in the particular instances of Restconf and Netcon= f, but still point out that access method independence.=C2=A0



Good points.
It would be nice to be done with NAC= M even if we are not done inventing YANG-based protocols.
There i= s an inherent conflict between generic operations and interoperability for = a specific protocol.

e.g., we can change <edit-= config> to say 'an edit operation' but now it is no longer clear=
what NETCONF requires for each operation.

It might be possible to define NACM using a generic protocol interaction= model,
and then have a separate (short) section that maps each p= rotocol to the generic model.
We can define codepoints for the CR= UD-XN model and assign procedures to the codepoints.
The draft do= es that already but there is no generic model, just straight mappings
=
to NETCONF and RESTCONF.

=C2=A0
<= div class=3D"m_3221784398672944834WordSection1">

=C2=A0

For example, the abstract states:<= /u>

There is a need

=C2=A0=C2=A0 for standard mechanisms to restrict NETCONF or RES= TCONF protocol

=C2=A0=C2=A0 access for particular users to a pre-configured su= bset of all

=C2=A0=C2=A0 available NETCONF or RESTCONF protocol operations = and content.=C2=A0 This

=C2=A0=C2=A0 document defines such= an access control model.

=C2=A0

I think this might be better rephrase= d something like

=C2=A0=C2=A0=C2=A0There is a need

=C2=A0=C2=A0 for standard mechanisms to restrict access for par= ticular users to a pre-configured subset of all

=C2=A0=C2=A0 available content in YANG datastores and available= operations, accessed via mechanisms that include

=C2=A0=C2=A0YANG NETCONF or RESTCONF protocol operations.=C2=A0= This

=C2=A0=C2=A0 document defines such= an access control model.

=C2=A0

Perhaps NACM should really be renamed= to YACM;-)=C2=A0 I know, the draft is in the Netconf WG, not Netmod, so wh= y should it not be specific to Netconf and Restconf, but still=E2=80=A6


hmm - that might be a better name as we adjust to= the fact that
YANG is no longer coupled to NETCONF.
=C2=A0

=C2=A0

Cheers

--- Alex

=C2=A0

<= /blockquote>

Andy
=C2=A0

=C2=A0

From: Netconf [mailto:netconf-bounces@ietf.o= rg] On Behalf Of Andy Bierman
Sent: Thursday, January 05, 2017 10:27 AM
To: Mehmet Ersue <mersue@gmail.com>
Cc: Netconf <netconf@ietf.org>
Subject: Re: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536bis WAS:FW: new NACM draft

=C2=A0

=C2=A0

=C2=A0

On Wed, Jan 4, 2017 at 8:30 AM, Mehmet Ersue <mersue@gmail.com>= wrote:

Dear All,

we assume now the WG support for the adoption of
draft-bierman-netconf-rfc6536bis.
Authors please submit as draft-ietf-netconf-rfc6536bis-00. Thanks.<= /u>

=C2=A0

done

=C2=A0

=C2=A0

Mehmet & Mahesh

=C2=A0

=C2=A0

Andy

=C2=A0


-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mehmet Ersue
Sent: Wednesday, December 14, 2016 10:20 PM
To: 'Netconf' <netconf@ietf.org>
Subject: [Netconf] WG Adoption Call for draft-bierman-netconf-rfc6536b= is
WAS:FW: new NACM draft

Dear NETCONF WG,

for the potential topics to add we only got comments from Martin. We assume=
now there are no other comments.

This is a 2+ week WG adoption call for draft-bierman-netconf-rfc6536bi= s to
adopt as NETCONF WG item.

Please state your opinion on the mail list by December 30, 2016 with
"yes/support" or "no support".

If you support, please let us know what you would like to address
additionally.
If you don't support, please elaborate your reasons.

Thank you,
Mehmet & Mahesh


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com]
Sent: Wednesday, December 7, 2016 9:20 AM
To: mersue@gmail.com<= /a>
Cc: andy@yumaworks.= com; netconf@ietf.org
Subject: Re: [Netconf] new NACM draft

MehmetErsue <mersu= e@gmail.com <mailto:mersue@gmail.com> > wrote:
> Hi Andy, Martin,
>
> thank you for the initial draft.
>
> We discussed in IETF 97 different issues and the additional sections > we could add.

Ok.=C2=A0 But do we have to resolve all issues before adopting this documen= t?=C2=A0 I
think the current document is ready for adoption, and then the WG can work<= br> on fixing any open issues.

> IIRC the list was:
> - schema-mount related text into schema-mount or the NACM draft,

I think schema mount needs to discuss how it works with NACM.=C2=A0 This sh= ould
be an open issue in schema mount.

> - assigning priorities to clients,

I don't believe this is a NACM issue.

> - access control on dynamic datastores (e.g. I2RS),

The text in 3.2 probably need to be relaxed a bit to allow NACM to be
applied to other datastores.

> - the issue from RFC 6536 with parent/child relationships which is
> important for RESTCONF.

Can you elaborate on this?


/martin



>
> I would like to suggest to have a discussion on these issues and
> understand whether they should be included.
>
> Mehmet
>
> On Wed, Nov 30, 2016 at 2:10 AM, Andy Bierman <andy@yumaworks.com
<mailto:andy@yum= aworks.com> > wrote:
>
> > Hi,
> >
> > A new version of draft-bierman-netconf-rfc6536bis has been p= osted:
> > https://www.ietf.org/id/draft-bierman-netconf-rfc6536bis-01.txt
> >
> >
> > We would like this draft to be adopted as the starting point for<= br> > > item #5 in the current NETCONF charter.
> >
> >
> >
> > Andy and Martin
> >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@iet= f.org <mailto:= Netconf@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> >
>
>
> --
> Cheers,
> Mehmet

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

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

=C2=A0


--001a1147eec0672f8805476cb048-- From nobody Tue Jan 31 17:45:04 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9D5B1296DF; Tue, 31 Jan 2017 17:45:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.4 X-Spam-Level: X-Spam-Status: No, score=-7.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.199, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 xIpTn1nT6Kmo; Tue, 31 Jan 2017 17:45:01 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F0491296DC; Tue, 31 Jan 2017 17:45:01 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 52CD8B81C39; Tue, 31 Jan 2017 17:45:01 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20170201014501.52CD8B81C39@rfc-editor.org> Date: Tue, 31 Jan 2017 17:45:01 -0800 (PST) Archived-At: Cc: drafts-update-ref@iana.org, netconf@ietf.org, rfc-editor@rfc-editor.org Subject: [Netconf] RFC 8040 on RESTCONF Protocol X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 01:45:03 -0000 A new Request for Comments is now available in online RFC libraries. RFC 8040 Title: RESTCONF Protocol Author: A. Bierman, M. Bjorklund, K. Watsen Status: Standards Track Stream: IETF Date: January 2017 Mailbox: andy@yumaworks.com, mbj@tail-f.com, kwatsen@juniper.net Pages: 137 Characters: 238832 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-netconf-restconf-18.txt URL: https://www.rfc-editor.org/info/rfc8040 DOI: 10.17487/RFC8040 This document describes an HTTP-based protocol that provides a programmatic interface for accessing data defined in YANG, using the datastore concepts defined in the Network Configuration Protocol (NETCONF). This document is a product of the Network Configuration Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jan 31 23:30:47 2017 Return-Path: X-Original-To: netconf@ietfa.amsl.com Delivered-To: netconf@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A604129416 for ; Tue, 31 Jan 2017 23:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 PIT-op3NugIx for ; Tue, 31 Jan 2017 23:30:44 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E5C5D1293FC for ; Tue, 31 Jan 2017 23:30:43 -0800 (PST) Received: from localhost (unknown [195.113.220.115]) by trail.lhotka.name (Postfix) with ESMTPSA id 68789182138D for ; Wed, 1 Feb 2017 08:30:28 +0100 (CET) From: Ladislav Lhotka To: Netconf In-Reply-To: <20170201014501.52CD8B81C39@rfc-editor.org> References: <20170201014501.52CD8B81C39@rfc-editor.org> Date: Wed, 01 Feb 2017 08:30:41 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: Re: [Netconf] RFC 8040 on RESTCONF Protocol X-BeenThere: netconf@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Network Configuration WG mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Feb 2017 07:30:46 -0000 Congratulations to the authors for this remarkable piece of work! Lada rfc-editor@rfc-editor.org writes: > A new Request for Comments is now available in online RFC libraries. > > > RFC 8040 > > Title: RESTCONF Protocol > Author: A. Bierman, > M. Bjorklund, > K. Watsen > Status: Standards Track > Stream: IETF > Date: January 2017 > Mailbox: andy@yumaworks.com, > mbj@tail-f.com, > kwatsen@juniper.net > Pages: 137 > Characters: 238832 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-netconf-restconf-18.txt > > URL: https://www.rfc-editor.org/info/rfc8040 > > DOI: 10.17487/RFC8040 > > This document describes an HTTP-based protocol that provides a > programmatic interface for accessing data defined in YANG, using the > datastore concepts defined in the Network Configuration Protocol > (NETCONF). > > This document is a product of the Network Configuration Working Group of the IETF. > > This is now a Proposed Standard. > > STANDARDS TRACK: This document specifies an Internet Standards Track > protocol for the Internet community, and requests discussion and suggestions > for improvements. Please refer to the current edition of the Official > Internet Protocol Standards (https://www.rfc-editor.org/standards) for the > standardization state and status of this protocol. Distribution of this > memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see https://www.rfc-editor.org/search > For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk > > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67